From internet-drafts@ietf.org Wed Jan 4 00:15:58 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF2621F868B; Wed, 4 Jan 2012 00:15:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONHyqVDEJgxa; Wed, 4 Jan 2012 00:15:57 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 695ED21F8639; Wed, 4 Jan 2012 00:15:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120104081557.23741.87139.idtracker@ietfa.amsl.com> Date: Wed, 04 Jan 2012 00:15:57 -0800 Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-protocol-14.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 08:15:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS-based Authentication of Named Ent= ities Working Group of the IETF. Title : Using Secure DNS to Associate Certificates with Domain N= ames For TLS Author(s) : Paul Hoffman Jakob Schlyter Filename : draft-ietf-dane-protocol-14.txt Pages : 24 Date : 2012-01-04 TLS and DTLS use PKIX certificates for authenticating the server. Users want their applications to verify that the certificate provided by the TLS server is in fact associated with the domain name they expect. TLSA provides bindings of keys to domains that are asserted not by external entities, but by the entities that operate the DNS. This document describes how to use secure DNS to associate the TLS server's certificate with the intended domain name. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dane-protocol-14.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dane-protocol-14.txt From jakob@kirei.se Wed Jan 4 00:22:58 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A58F21F86BC for ; Wed, 4 Jan 2012 00:22:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XjBz-KDmfDOb for ; Wed, 4 Jan 2012 00:22:57 -0800 (PST) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id F2CBF21F85CB for ; Wed, 4 Jan 2012 00:22:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:content-type:mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to:x-mailer; bh=4VkLcwF2O3/NlPqEn83U95K6G368aOgEKwUDXRT4wDc=; b=RSB3SEjsDZhBZvVr9n/BlIKIQ9YC6RPMrEUjYS6shcgqZ63YoiYELHXwzejGE/tAmPVeP7ce053mf ciUe4NXdxFtkyZqZz1L1Njae/K2TkKudJwm9HrgfBkk0Yf5HbSac+nPrdth3VHQQSaYnZjo3fdnUL3 ogsyWOCtrEq1HkAw= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS for ; Wed, 4 Jan 2012 09:22:10 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Apple Message framework v1251.1) From: Jakob Schlyter In-Reply-To: <20120104081557.23741.87139.idtracker@ietfa.amsl.com> Date: Wed, 4 Jan 2012 09:22:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <68E91C69-A7DB-40BE-BA60-DCDBA1F8EB28@kirei.se> References: <20120104081557.23741.87139.idtracker@ietfa.amsl.com> To: IETF DANE WG list X-Mailer: Apple Mail (2.1251.1) Subject: Re: [dane] I-D Action: draft-ietf-dane-protocol-14.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 08:22:58 -0000 On 4 jan 2012, at 09:15, internet-drafts@ietf.org wrote: > 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. >=20 > Title : Using Secure DNS to Associate Certificates = with Domain Names For TLS > Author(s) : Paul Hoffman > Jakob Schlyter > Filename : draft-ietf-dane-protocol-14.txt > Pages : 24 > Date : 2012-01-04 -14 (aka "the happy new year release") includes the following changes: - clarification on DNSSEC validation requirements - first cut at integrating new text on "Creating TLSA Records" from = Ond=C5=99ej Mikle - revised pseudo code (please check this carefully!) jakob & paul From ilari.liusvaara@elisanet.fi Wed Jan 4 01:54:40 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DDFB21F8715 for ; Wed, 4 Jan 2012 01:54:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6EF4m+Fb-P83 for ; Wed, 4 Jan 2012 01:54:39 -0800 (PST) Received: from emh06.mail.saunalahti.fi (emh06.mail.saunalahti.fi [62.142.5.116]) by ietfa.amsl.com (Postfix) with ESMTP id 43CFB21F8623 for ; Wed, 4 Jan 2012 01:54:39 -0800 (PST) Received: from saunalahti-vams (vs3-12.mail.saunalahti.fi [62.142.5.96]) by emh06-2.mail.saunalahti.fi (Postfix) with SMTP id 928AEC7EB4; Wed, 4 Jan 2012 11:54:37 +0200 (EET) Received: from emh04.mail.saunalahti.fi ([62.142.5.110]) by vs3-12.mail.saunalahti.fi ([62.142.5.96]) with SMTP (gateway) id A05BF088A3A; Wed, 04 Jan 2012 11:54:37 +0200 Received: from LK-Perkele-VI (a88-112-55-20.elisa-laajakaista.fi [88.112.55.20]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id 6F64A41BEC; Wed, 4 Jan 2012 11:54:34 +0200 (EET) Date: Wed, 4 Jan 2012 11:54:34 +0200 From: Ilari Liusvaara To: Jakob Schlyter Message-ID: <20120104095434.GA14537@LK-Perkele-VI.localdomain> References: <20120104081557.23741.87139.idtracker@ietfa.amsl.com> <68E91C69-A7DB-40BE-BA60-DCDBA1F8EB28@kirei.se> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <68E91C69-A7DB-40BE-BA60-DCDBA1F8EB28@kirei.se> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Ilari Liusvaara X-Antivirus: VAMS Cc: IETF DANE WG list Subject: Re: [dane] I-D Action: draft-ietf-dane-protocol-14.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 09:54:40 -0000 On Wed, Jan 04, 2012 at 09:22:04AM +0100, Jakob Schlyter wrote: > On 4 jan 2012, at 09:15, internet-drafts@ietf.org wrote: > > -14 (aka "the happy new year release") includes the following changes: <...> > - revised pseudo code (please check this carefully!) The "if (R.certUsage == 0) {" block in pseudocode seems to open 5 blocks but close only 4 (the innermost block is seems to be missing '}'). -Ilari From jakob@kirei.se Wed Jan 4 05:18:50 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51D3B21F870C for ; Wed, 4 Jan 2012 05:18:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id erJpP5wtZkgG for ; Wed, 4 Jan 2012 05:18:49 -0800 (PST) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id 81D4F21F870A for ; Wed, 4 Jan 2012 05:18:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=rtJ+8I0YTRF9CVEP5x17Px8wLxh0d9DCF4UDHGiiBOI=; b=YQHVVTa6h6Ft3ef9q8Q4ou1PYec08KP+UCXD0HPlV0vi/VH0DB2tGku+9jfZJdB7Rzaa1mHv6zTOJ jW3Ux+a4nHPtkTAIvbR+ekcE6UvetFNSWLaokYCs7JNFjheFZfiGk0e7NMfrWFKLe5gNhmE/nFT3zQ MWCUHfPsjTo6WsTc= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Wed, 4 Jan 2012 14:18:16 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: <20120104095434.GA14537@LK-Perkele-VI.localdomain> Date: Wed, 4 Jan 2012 14:18:08 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <20120104081557.23741.87139.idtracker@ietfa.amsl.com> <68E91C69-A7DB-40BE-BA60-DCDBA1F8EB28@kirei.se> <20120104095434.GA14537@LK-Perkele-VI.localdomain> To: Ilari Liusvaara X-Mailer: Apple Mail (2.1251.1) Cc: IETF DANE WG list Subject: Re: [dane] I-D Action: draft-ietf-dane-protocol-14.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 13:18:50 -0000 On 4 jan 2012, at 10:54, Ilari Liusvaara wrote: > On Wed, Jan 04, 2012 at 09:22:04AM +0100, Jakob Schlyter wrote: >> On 4 jan 2012, at 09:15, internet-drafts@ietf.org wrote: >> >> -14 (aka "the happy new year release") includes the following changes: > <...> >> - revised pseudo code (please check this carefully!) > > The "if (R.certUsage == 0) {" block in pseudocode seems to open 5 > blocks but close only 4 (the innermost block is seems to be missing > '}'). Thanks, fixed in next rev. jakob From paul.hoffman@vpnc.org Wed Jan 4 06:46:25 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B66021F86BE for ; Wed, 4 Jan 2012 06:46:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYwuDi2Tn8CC for ; Wed, 4 Jan 2012 06:46:25 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id E1D9C21F86AE for ; Wed, 4 Jan 2012 06:46:24 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q04EkNmM023841 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 4 Jan 2012 07:46:24 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Jan 2012 06:46:25 -0800 Message-Id: <59E1FDB4-B832-415A-BEE3-8E85CC55E337@vpnc.org> To: IETF DANE WG list Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: [dane] Pseudocode review X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 14:46:25 -0000 Greetings again. As Jakob indicated, we would *really* like to have a = careful review of the pseudocode now instead of waiting for WG Last = Call. TLSA has rules spread in many part of the body text, and the = pseudocode is supposed to pull every rule into one place, correctly. = Many developers like pseudocode, and will tend to focus on this = non-normative appendix rather than the body text. Ilari already found = one small error (thanks!), and we would like developer-like folks on the = list to poke harder at the section so that we are somewhat confident = that everyone understands what the protocol is doing. --Paul Hoffman From bortzmeyer@nic.fr Thu Jan 5 00:55:51 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9132521F8757 for ; Thu, 5 Jan 2012 00:55:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZgwJpY9biu6M for ; Thu, 5 Jan 2012 00:55:51 -0800 (PST) Received: from mx2.nic.fr (mx2.nic.fr [IPv6:2001:660:3003:2::4:11]) by ietfa.amsl.com (Postfix) with ESMTP id ED14521F8751 for ; Thu, 5 Jan 2012 00:55:50 -0800 (PST) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id B36DB1C0119; Thu, 5 Jan 2012 09:55:49 +0100 (CET) Received: by mx2.nic.fr (Postfix, from userid 500) id 9F6631C01A0; Thu, 5 Jan 2012 09:55:49 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [IPv6:2001:67c:2218:9::4:163]) by mx2.nic.fr (Postfix) with ESMTP id 83E2D1C0119; Thu, 5 Jan 2012 09:55:49 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [IPv6:2001:67c:2219:8::6:69]) by relay2.nic.fr (Postfix) with ESMTP id E6035B3805C; Thu, 5 Jan 2012 09:55:48 +0100 (CET) Date: Thu, 5 Jan 2012 09:55:49 +0100 From: Stephane Bortzmeyer To: Paul Hoffman Message-ID: <20120105085549.GA6998@nic.fr> References: <59E1FDB4-B832-415A-BEE3-8E85CC55E337@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <59E1FDB4-B832-415A-BEE3-8E85CC55E337@vpnc.org> X-Operating-System: Debian GNU/Linux wheezy/sid X-Kernel: Linux 3.1.0-1-686-pae i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.21 (2010-09-15) X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=1.1.5 X-PMX-Version: 5.4.6.353000, Antispam-Engine: 2.6.1.350677, Antispam-Data: 2012.1.5.84815 X-PerlMx-Spam: Gauge=IIIIIII, Probability=8%, Report='BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, BODY_SIZE_800_899 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CD 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __TO_MALFORMED_2 0, __URI_NO_PATH 0, __URI_NO_WWW 0, __USER_AGENT 0' Cc: IETF DANE WG list Subject: Re: [dane] Pseudocode review X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 08:55:51 -0000 On Wed, Jan 04, 2012 at 06:46:25AM -0800, Paul Hoffman wrote a message of 8 lines which said: > we would *really* like to have a careful review of the pseudocode > now instead of waiting for WG Last Call. I've read it (carefully, I believe), I think I have understand it and I did not notice mistakes. After "This appendix is non-normative. If the steps below disagree with the text earlier in the document, the steps earlier in the document should be considered correct and this text incorrect.", I suggest to add: For instance, pay attention to the fact that, like most pseudo-codes, it is more strict than the normative text. For instance, it forces an order on the evaluation of criteria (X.509 before TLSA when certificateUsage == 0) which is not mandatory. From paul.hoffman@vpnc.org Thu Jan 5 07:48:16 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7857621F87B5 for ; Thu, 5 Jan 2012 07:48:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNvXYNlf48cU for ; Thu, 5 Jan 2012 07:48:16 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id DFC5721F8679 for ; Thu, 5 Jan 2012 07:48:15 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q05FmCKq078350 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 5 Jan 2012 08:48:13 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20120105085549.GA6998@nic.fr> Date: Thu, 5 Jan 2012 07:48:13 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <730E49C4-CA7F-4B6D-9FAC-D85A284B51B7@vpnc.org> References: <59E1FDB4-B832-415A-BEE3-8E85CC55E337@vpnc.org> <20120105085549.GA6998@nic.fr> To: Stephane Bortzmeyer X-Mailer: Apple Mail (2.1251.1) Cc: IETF DANE WG list Subject: Re: [dane] Pseudocode review X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 15:48:16 -0000 On Jan 5, 2012, at 12:55 AM, Stephane Bortzmeyer wrote: > On Wed, Jan 04, 2012 at 06:46:25AM -0800, > Paul Hoffman wrote=20 > a message of 8 lines which said: >=20 >> we would *really* like to have a careful review of the pseudocode >> now instead of waiting for WG Last Call.=20 >=20 > I've read it (carefully, I believe), I think I have understand it and > I did not notice mistakes. Whew! It would be nice to hear that from at least a few others (and it = would be fine to hear about mistakes as well). > After "This appendix is non-normative. If the steps below disagree > with the text earlier in the document, the steps earlier in the > document should be considered correct and this text incorrect.", I > suggest to add: >=20 > For instance, pay attention to the fact that, like most pseudo-codes, > it is more strict than the normative text. For instance, it forces an > order on the evaluation of criteria (X.509 before TLSA when > certificateUsage =3D=3D 0) which is not mandatory. Good suggestion, yes. --Paul Hoffman From cloos@jhcloos.com Thu Jan 5 12:19:17 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 309D921F880C for ; Thu, 5 Jan 2012 12:19:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.284 X-Spam-Level: X-Spam-Status: No, score=-0.284 tagged_above=-999 required=5 tests=[AWL=2.317, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tvonndLSaXlo for ; Thu, 5 Jan 2012 12:19:16 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by ietfa.amsl.com (Postfix) with ESMTP id 30A2921F8688 for ; Thu, 5 Jan 2012 12:19:15 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 5415540179; Thu, 5 Jan 2012 20:18:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1325794753; bh=cbLpccTGYIceC8Tv4qjUZYC4xZStdZZGyvNnkYsA8gs=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=mkHzWDS84VuKlc03uCSaP40irEVeRAhaNED+v/zJT6YEkoiOMeP7GHZ11hudxtazx VPvnQz2qVjxd/bRclmObWZCObexxJltLdmYR55Cb8XSWUcQ5Y0uH3Ta91HRyrc5ib3 NMG0XEr2WG0oUicrH1TQkXa6FnX19cgqctvNkGes= Received: by carbon.jhcloos.org (Postfix, from userid 500) id D59AF36004C; Thu, 5 Jan 2012 20:18:35 +0000 (UTC) From: James Cloos To: Paul Hoffman In-Reply-To: <730E49C4-CA7F-4B6D-9FAC-D85A284B51B7@vpnc.org> (Paul Hoffman's message of "Thu, 5 Jan 2012 07:48:13 -0800") References: <59E1FDB4-B832-415A-BEE3-8E85CC55E337@vpnc.org> <20120105085549.GA6998@nic.fr> <730E49C4-CA7F-4B6D-9FAC-D85A284B51B7@vpnc.org> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.92 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2011 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Thu, 05 Jan 2012 15:18:35 -0500 Message-ID: Lines: 14 MIME-Version: 1.0 Content-Type: text/plain Cc: IETF DANE WG list Subject: Re: [dane] Pseudocode review X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 20:19:17 -0000 >>>>> "PH" == Paul Hoffman writes: >> I've read it (carefully, I believe), I think I have understand it and >> I did not notice mistakes. PH> Whew! It would be nice to hear that from at least a few others (and PH> it would be fine to hear about mistakes as well). Other than the already-reported missing }, I agree that it looks correct and should be easy for anyone coding a tlsa-aware client to understand. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From trac+dane@trac.tools.ietf.org Thu Jan 5 13:22:37 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB0E21F889F for ; Thu, 5 Jan 2012 13:22:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUoiMXOqJU23 for ; Thu, 5 Jan 2012 13:22:36 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 6117E21F8842 for ; Thu, 5 Jan 2012 13:22:35 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RiulU-0000w5-HX; Thu, 05 Jan 2012 16:22:24 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: paul@xelerance.com, matt@mattmccutchen.net, warren@kumari.net X-Trac-Project: dane Date: Thu, 05 Jan 2012 21:22:23 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/23#comment:3 Message-ID: <076.95d844f2caf75153c09899178d75b5bc@trac.tools.ietf.org> References: <061.05db8c262c83655cb47a8699cab6c2ac@trac.tools.ietf.org> X-Trac-Ticket-ID: 23 In-Reply-To: <061.05db8c262c83655cb47a8699cab6c2ac@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: paul@xelerance.com, matt@mattmccutchen.net, warren@kumari.net, dane@ietf.org X-SA-Exim-Mail-From: trac+dane@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: dane@ietf.org Subject: Re: [dane] #23: Asserting DANE exclusivity for an entire domain X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 21:22:37 -0000 #23: Asserting DANE exclusivity for an entire domain Changes (by warren@…): * keywords: => revisit * status: new => closed * resolution: => wontfix Comment: As per: http://www.ietf.org/mail-archive/web/dane/current/msg03972.html (December 20th, 2011) and the minutes from IETF82 - http://www.ietf.org/proceedings/82/minutes/dane.txt "This is being deferred to a separate document. We are making the issue as closed, will tag it with a keyword ("revisit") so we can find it easily again if we want additional work in the future :-P" -- -------------------------+---------------------- Reporter: matt@… | Owner: Type: enhancement | Status: closed Priority: major | Milestone: Component: protocol | Version: Severity: - | Resolution: wontfix Keywords: revisit | -------------------------+---------------------- Ticket URL: dane From trac+dane@trac.tools.ietf.org Thu Jan 5 13:26:39 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7845021F889F for ; Thu, 5 Jan 2012 13:26:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2+5cWBKk+zSN for ; Thu, 5 Jan 2012 13:26:39 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id EC8DC21F889D for ; Thu, 5 Jan 2012 13:26:38 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RiupW-0001li-1P; Thu, 05 Jan 2012 16:26:34 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-dane-protocol@tools.ietf.org, warren@kumari.net X-Trac-Project: dane Date: Thu, 05 Jan 2012 21:26:34 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/38#comment:1 Message-ID: <076.520baefa8578b530d0eea4231d6c28a2@trac.tools.ietf.org> References: <061.a82f8aa3c92f33e7b664930cf373f215@trac.tools.ietf.org> X-Trac-Ticket-ID: 38 In-Reply-To: <061.a82f8aa3c92f33e7b664930cf373f215@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dane-protocol@tools.ietf.org, warren@kumari.net, dane@ietf.org X-SA-Exim-Mail-From: trac+dane@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120105212638.EC8DC21F889D@ietfa.amsl.com> Resent-Date: Thu, 5 Jan 2012 13:26:38 -0800 (PST) Resent-From: trac+dane@trac.tools.ietf.org Cc: dane@ietf.org Subject: Re: [dane] #38: Dane and EAP-FAST X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 21:26:39 -0000 #38: Dane and EAP-FAST Changes (by warren@…): * status: new => closed * resolution: => wontfix Comment: As per the IETF82 Minutes: http://www.ietf.org/proceedings/82/minutes/dane.txt and onlist at: http://www.ietf.org/mail- archive/web/dane/current/msg03972.html Issue # 38 Idea: Enable support for DANE within EAP-FAST Proposal: Do nothing in the protocol specification. * No objects to this proposal * CONCLUSION: Do nothing in the protocol document A new draft covering this is an option if someone feels like writing it. Text for issue tracker: "This issue is being closed, marked as "wontfix"" -- -------------------------+----------------------------------------- Reporter: ietf@… | Owner: draft-ietf-dane-protocol@… Type: enhancement | Status: closed Priority: major | Milestone: Component: protocol | Version: Severity: - | Resolution: wontfix Keywords: | -------------------------+----------------------------------------- Ticket URL: dane From trac+dane@trac.tools.ietf.org Thu Jan 5 13:30:56 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF05621F88C4 for ; Thu, 5 Jan 2012 13:30:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9oz0kFLgiwZ for ; Thu, 5 Jan 2012 13:30:56 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 2F9B721F88C3 for ; Thu, 5 Jan 2012 13:30:55 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1Riuth-0007Cf-1q; Thu, 05 Jan 2012 16:30:53 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: warren@kumari.net X-Trac-Project: dane Date: Thu, 05 Jan 2012 21:30:53 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/8#comment:1 Message-ID: <070.69edf0ff4fbd78ac19e591af2f49ae54@trac.tools.ietf.org> References: <055.78f597ee767dc129da149cf83ff60b86@trac.tools.ietf.org> X-Trac-Ticket-ID: 8 In-Reply-To: <055.78f597ee767dc129da149cf83ff60b86@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: warren@kumari.net, dane@ietf.org X-SA-Exim-Mail-From: trac+dane@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: dane@ietf.org Subject: Re: [dane] #8: How do we handle the "Last Hop Problem" X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 21:30:56 -0000 #8: How do we handle the "Last Hop Problem" Changes (by warren@…): * status: new => closed * resolution: => fixed Comment: As per the IETF82 minutes (http://www.ietf.org/proceedings/82/minutes/dane.txt ) (and subsequently onlist (http://www.ietf.org/mail-archive/web/dane/current/msg03975.html )) text was added. Text added to satisfy #8: Clients that validate the DNSSEC signatures themselves SHOULD use standard DNSSEC validation procedures. Clients that do not validate the DNSSEC signatures themselves MUST use a secure transport (e.g., TSIG [RFC2845], SIG(0) [RFC2931], or IPsec [RFC6071]) between themselves and the entity performing the signature validation. -- -----------------------------------+--------------------- Reporter: mlepinsk@… | Owner: Type: defect | Status: closed Priority: major | Milestone: Component: protocol | Version: Severity: Candidate WG Document | Resolution: fixed Keywords: | -----------------------------------+--------------------- Ticket URL: dane From ondrej.mikle@nic.cz Thu Jan 5 13:32:06 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0287721F88C3 for ; Thu, 5 Jan 2012 13:32:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ola4dRRGlpWi for ; Thu, 5 Jan 2012 13:32:05 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 35A5121F88C1 for ; Thu, 5 Jan 2012 13:32:05 -0800 (PST) Received: from [172.30.151.65] (ip-84-42-137-177.net.upcbroadband.cz [84.42.137.177]) by mail.nic.cz (Postfix) with ESMTPSA id C7E4F2A29A1 for ; Thu, 5 Jan 2012 22:32:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1325799123; bh=q7+6u3itACclfaVVSVukOtcWpxiZFVlnvUsNY0zMOig=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=n/qcwa8DArDBBFu/14JLtMw84RYhunFk/0aKu9WbCzsQ3gs/vLRKnu/WQlU1aZWyf CvK0o1tTbVlgs+cDiOOT9y/iECRM1NgLT2wnNyjBwQFWbCGZPlcHsMaAf4KO/MdwvN ByvFousePOyzOIkiostAUL0ot2f3CFAFx4cpRih4= Message-ID: <4F0616D2.4040308@nic.cz> Date: Thu, 05 Jan 2012 22:32:02 +0100 From: Ondrej Mikle User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: dane@ietf.org References: <59E1FDB4-B832-415A-BEE3-8E85CC55E337@vpnc.org> <20120105085549.GA6998@nic.fr> <730E49C4-CA7F-4B6D-9FAC-D85A284B51B7@vpnc.org> In-Reply-To: <730E49C4-CA7F-4B6D-9FAC-D85A284B51B7@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: Re: [dane] Pseudocode review X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 21:32:06 -0000 On 01/05/12 16:48, Paul Hoffman wrote: > Whew! It would be nice to hear that from at least a few others (and it would be fine to hear about mistakes as well). I've re-read it a few times and I think it's very well written. I didn't find anything that wasn't mentioned already. >> After "This appendix is non-normative. If the steps below disagree >> with the text earlier in the document, the steps earlier in the >> document should be considered correct and this text incorrect.", I >> suggest to add: >> >> For instance, pay attention to the fact that, like most pseudo-codes, >> it is more strict than the normative text. For instance, it forces an >> order on the evaluation of criteria (X.509 before TLSA when >> certificateUsage == 0) which is not mandatory. > > > Good suggestion, yes. Seconded. (Some of the nested if's could be rewritten as "if (X and Y)" to avoid explicit PKIX/TLSA evaluation order, but it would hurt clarity of pseudocode.) Ondrej Mikle From trac+dane@trac.tools.ietf.org Thu Jan 5 13:32:45 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7FCF21F88C3 for ; Thu, 5 Jan 2012 13:32:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8IGyxfIfPzsM for ; Thu, 5 Jan 2012 13:32:45 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 2F53721F8503 for ; Thu, 5 Jan 2012 13:32:44 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RiuvT-0002an-VA; Thu, 05 Jan 2012 16:32:43 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: warren@kumari.net X-Trac-Project: dane Date: Thu, 05 Jan 2012 21:32:43 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/10#comment:1 Message-ID: <070.317727f90a0492bfd639eda43a164a89@trac.tools.ietf.org> References: <055.05021bd058afd665b11c749a0eaf492d@trac.tools.ietf.org> X-Trac-Ticket-ID: 10 In-Reply-To: <055.05021bd058afd665b11c749a0eaf492d@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: warren@kumari.net, dane@ietf.org X-SA-Exim-Mail-From: trac+dane@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: dane@ietf.org Subject: Re: [dane] #10: Considerations related to the comprimise of an intermediate CA X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 21:32:45 -0000 #10: Considerations related to the comprimise of an intermediate CA Changes (by warren@…): * status: new => closed * resolution: => fixed Comment: As discussed at the IETF82 meeting (http://www.ietf.org/proceedings/82/minutes/dane.txt ) and then taken to the list (http://www.ietf.org/mail-archive/web/dane/current/msg03975.html ) text was added to the document to address this. Text added to satisfy #10: If a server's certificate is revoked, or if an intermediate CA in a chain between the end entity and a trust anchor has its certificate revoked, a TLSA record with a certificate type of 2 that matches the revoked certificate would in essence override the revocation because the client would treat that revoked certificate as a trust anchor and thus not check its revocation status. Because of this, domain administrators need to be responsible for being sure that the key or certificate used in TLSA records with a certificate type of 2 are in fact able to be used as reliable trust anchors. -- ------------------------+--------------------- Reporter: mlepinsk@… | Owner: Type: defect | Status: closed Priority: minor | Milestone: Component: protocol | Version: Severity: - | Resolution: fixed Keywords: | ------------------------+--------------------- Ticket URL: dane From warren@kumari.net Sun Jan 8 10:26:50 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88F6821F856E for ; Sun, 8 Jan 2012 10:26:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.541 X-Spam-Level: X-Spam-Status: No, score=-106.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rtVTFP8muY7N for ; Sun, 8 Jan 2012 10:26:50 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 0897121F8472 for ; Sun, 8 Jan 2012 10:26:49 -0800 (PST) Received: from [192.168.0.12] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 38CA31B403ED for ; Sun, 8 Jan 2012 13:26:48 -0500 (EST) From: Warren Kumari Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Sun, 8 Jan 2012 13:26:47 -0500 Message-Id: <239A4A6A-D5CF-4D22-88E5-E04D7B992067@kumari.net> To: IETF DANE WG list Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [dane] Does the WG want to meet in Paris? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2012 18:26:50 -0000 Hello all, I think that we are *almost* done with the protocol document, and with = some effort will be done before Paris. Does the WG want to meet or = should we skip it this time? I personally think we can skip this round (we will done / basically done = on the protocol doc and (IMO) are unlikely to have S/MIME / IPsec docs = ready for discussion) and meeting time is a valuable / scare resource, = but whatever the WG wants=85 W --- Don't be impressed with unintelligible stuff said condescendingly . -- Radia Perlman. Warren Kumari warren@kumari.net From warren@kumari.net Sun Jan 8 10:49:23 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1955921F849C for ; Sun, 8 Jan 2012 10:49:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.545 X-Spam-Level: X-Spam-Status: No, score=-106.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G35W-OekmcjC for ; Sun, 8 Jan 2012 10:49:22 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 87F2921F85C5 for ; Sun, 8 Jan 2012 10:49:22 -0800 (PST) Received: from [192.168.0.12] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id EB9451B407FC for ; Sun, 8 Jan 2012 13:49:21 -0500 (EST) From: Warren Kumari Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 8 Jan 2012 13:49:24 -0500 Message-Id: To: IETF DANE WG list Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [dane] Opening Issue #37. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2012 18:49:23 -0000 Hi all, As threatened, I am opening DANE Issue #37 (We specifically waited till = after the vacation to open it so that folk were around). In order to jog you memory, here is an extract from the minutes (and to = remind folk that the issue morphed over time, please see the list): = --------------------------------------------------------------------------= ---------------------------- Issue #37 Idea: Add a usage to assert a self-signed server certificate directly Proposal: Make no change to the core specification. This use-case can be = covered via usage 2. *** Alex Mayrhofer : I think this would make things easier for some people = using self-signed certs Richard Barnes: We could add an example to the document showing how to = use usage 2 to address this use-case EKR: Doesn't what Richard says require PKIX validation Richard: Yes, there does need to be PKIX validation for usage 2, you = can't just do byte-wise comparison EKR: This sounds a lot more complicated Alex M: I kind of agree with EKR. Let's go with direct certificate = association to make this as simple as possible. This is a usability = issue. Steve Kent: There is code for PKIX validation that is currently = available. This code can just be re-used to do usage 2 of DANE. PHB: This is all a lot more critical if there is no choice about the = exclusivity Richard B: There is a requirement in the use-cases that you should be = able to do this with a minimum of key management. The current document = text does not require two key pairs (it just requires two certificates). Jim Schaad: I am lost as to why this needs to be a separate certificate? Richard B: The question is whether existing software stacks can do this = usage 2 with only one certificate. There was some lack of clarity on the = list with regards to what can be done with existing software stacks. Bill Manning : I think this is a useful thing to have in the stack, = regardless of whether we actually decide to deploy this. Code points are = not scarce. Paul Wouters: There will be a case (eg bare public key cert_type) that = will not have anything of a PKIX TA. Make sure that's clear to implement Richard B: If we support bare public keys in the future, we will = probably need a new usage. *** CONCLUSION: After hum, there is no clear results, we will open a big = discussion of this on the list. = --------------------------------------------------------------------------= - I would like us to discuss this issue (and try avoid going down any = rabbit holes (like rat holes, but more surreal)) and come to consensus = by Jan 23rd (around 2 weeks). Thank you for your time and consideration, W --- Don't be impressed with unintelligible stuff said condescendingly . -- Radia Perlman. Warren Kumari warren@kumari.net From trac+dane@trac.tools.ietf.org Sun Jan 8 17:37:20 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6F221F8558 for ; Sun, 8 Jan 2012 17:37:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-W2bTb+oo66 for ; Sun, 8 Jan 2012 17:37:20 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 1B75221F8536 for ; Sun, 8 Jan 2012 17:37:19 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1Rk4Ah-0003un-SA; Sun, 08 Jan 2012 20:37:11 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: warren@kumari.net, matt@mattmccutchen.net X-Trac-Project: dane Date: Mon, 09 Jan 2012 01:37:11 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/6#comment:5 Message-ID: <070.09df3d86278d10106ff2fbe42fa15b44@trac.tools.ietf.org> References: <055.1026e2cada5be186d7270ba0ee6f1627@trac.tools.ietf.org> X-Trac-Ticket-ID: 6 In-Reply-To: <055.1026e2cada5be186d7270ba0ee6f1627@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: warren@kumari.net, matt@mattmccutchen.net, dane@ietf.org X-SA-Exim-Mail-From: trac+dane@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: dane@ietf.org Subject: Re: [dane] #6: Downgrade attacks : What to do if DANE fails X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 01:37:20 -0000 #6: Downgrade attacks : What to do if DANE fails Changes (by warren@…): * status: reopened => closed * resolution: => fixed Comment: "Do we state that a client MUST fail the TLS handshake if it cannot get a secure or verified insecure response to the TLSA query?" The document now covers this, and so I am closing this issue. Section 4.4 ( http://tools.ietf.org/html/draft-ietf-dane- protocol-14#section-4.4 ) W -- --------------------------------+--------------------- Reporter: mlepinsk@… | Owner: Type: defect | Status: closed Priority: major | Milestone: Component: protocol | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+--------------------- Ticket URL: dane From warren@kumari.net Sun Jan 8 17:45:50 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A26F21F84F8 for ; Sun, 8 Jan 2012 17:45:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.549 X-Spam-Level: X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4vIvk2LAL72k for ; Sun, 8 Jan 2012 17:45:49 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id D892521F84F6 for ; Sun, 8 Jan 2012 17:45:49 -0800 (PST) Received: from [192.168.0.12] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id CF4041B4050A for ; Sun, 8 Jan 2012 20:45:48 -0500 (EST) From: Warren Kumari Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 8 Jan 2012 20:45:46 -0500 Message-Id: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> To: IETF DANE WG list Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 01:45:50 -0000 Hi all, http://trac.tools.ietf.org/wg/dane/trac/ticket/28 I believe that this should be a simple issue for us to open, discuss, = reach consensus on and close. AFAICT, we mainly just need to choose something. W --- Don't be impressed with unintelligible stuff said condescendingly . -- Radia Perlman. Warren Kumari warren@kumari.net From warren@kumari.net Sun Jan 8 17:53:55 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F67D21F8508 for ; Sun, 8 Jan 2012 17:53:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.552 X-Spam-Level: X-Spam-Status: No, score=-106.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TjpgjH0X1JdK for ; Sun, 8 Jan 2012 17:53:54 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id C74EF21F8504 for ; Sun, 8 Jan 2012 17:53:54 -0800 (PST) Received: from [192.168.0.12] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 4CD901B403ED for ; Sun, 8 Jan 2012 20:53:54 -0500 (EST) From: Warren Kumari Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Sun, 8 Jan 2012 20:53:53 -0500 Message-Id: <8A3B478E-6D5F-4DF7-80FC-895B5C47675B@kumari.net> To: IETF DANE WG list Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [dane] Opening Issue #35 - Behavior for a supported algorithm that is not considered "strong" by the client. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 01:53:55 -0000 Hi all, This will make it 3 open issues being discussed -- = http://trac.tools.ietf.org/wg/dane/trac/ticket/35 I think that we are close to knowing what we want to do here (and the = questions don't seem particularly controversial) so I am asking for your = help and co-operation to try get this (final) question put to bed=85 Lets see if we can stay on topic and work together to come to consensus=85= Planning on calling this on Jan 23rd. Thanks, W --- Don't be impressed with unintelligible stuff said condescendingly . -- Radia Perlman. Warren Kumari warren@kumari.net From paul.hoffman@vpnc.org Sun Jan 8 17:56:42 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 837EE21F85E4 for ; Sun, 8 Jan 2012 17:56:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GmoCfVp31nbz for ; Sun, 8 Jan 2012 17:56:42 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id DA8F421F8508 for ; Sun, 8 Jan 2012 17:56:41 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q091ueiZ032058 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 8 Jan 2012 18:56:41 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Paul Hoffman In-Reply-To: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> Date: Sun, 8 Jan 2012 17:56:40 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> To: IETF DANE WG list X-Mailer: Apple Mail (2.1251.1) Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 01:56:42 -0000 I propose (b) from the ticket. That is, run down the SRV chain fully and = then use the final result as the input to the TLSA processing. BTW, whatever we choose will get analyzed in IETF Last Call be a group = of people who know more about SRV processing than we do, so if we pick = the "wrong" one now, it will be easy to fix after IETF LC. --Paul Hoffman= From paul.hoffman@vpnc.org Sun Jan 8 18:00:35 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34CBF21F85C0 for ; Sun, 8 Jan 2012 18:00:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2yNBK91TMKN for ; Sun, 8 Jan 2012 18:00:34 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id B252121F85E4 for ; Sun, 8 Jan 2012 18:00:34 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0920X4P032178 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 8 Jan 2012 19:00:34 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1251.1) From: Paul Hoffman In-Reply-To: <8A3B478E-6D5F-4DF7-80FC-895B5C47675B@kumari.net> Date: Sun, 8 Jan 2012 18:00:33 -0800 Content-Transfer-Encoding: 7bit Message-Id: <026B2D43-F056-44B5-BCEA-825CC57B0BD7@vpnc.org> References: <8A3B478E-6D5F-4DF7-80FC-895B5C47675B@kumari.net> To: IETF DANE WG list X-Mailer: Apple Mail (2.1251.1) Subject: Re: [dane] Opening Issue #35 - Behavior for a supported algorithm that is not considered "strong" by the client. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 02:00:35 -0000 At the end of section 4.4, we currently say: If a certificate association contains a certificate usage, selector, or matching type that is not understood by the TLS client, that certificate association MUST be marked as unusable. If the comparison data for a certificate is malformed, the certificate association MUST be marked as unusable. I propose that we add: If a certificate association contains a matching type or certificate for association that uses a cryptographic algorithm that is considered too weak for the TLS client's policy, the certificate association MUST be marked as unusable. --Paul Hoffman From bmanning@karoshi.com Sun Jan 8 20:37:59 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACF2E21F8644 for ; Sun, 8 Jan 2012 20:37:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k07bgG-+SSfz for ; Sun, 8 Jan 2012 20:37:59 -0800 (PST) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id 2336721F8643 for ; Sun, 8 Jan 2012 20:37:59 -0800 (PST) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id q094buSA016820; Mon, 9 Jan 2012 04:37:57 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id q094brbD016819; Mon, 9 Jan 2012 04:37:53 GMT Date: Mon, 9 Jan 2012 04:37:53 +0000 From: bmanning@vacation.karoshi.com To: Paul Hoffman Message-ID: <20120109043753.GA14630@vacation.karoshi.com.> References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: IETF DANE WG list Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 04:37:59 -0000 On Sun, Jan 08, 2012 at 05:56:40PM -0800, Paul Hoffman wrote: > I propose (b) from the ticket. That is, run down the SRV chain fully and then use the final result as the input to the TLSA processing. this makes the most sense. /bill From peter@denic.de Mon Jan 9 00:19:34 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91D5221F8494 for ; Mon, 9 Jan 2012 00:19:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6Krz2dmOQb9 for ; Mon, 9 Jan 2012 00:19:34 -0800 (PST) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::4]) by ietfa.amsl.com (Postfix) with ESMTP id 0978421F846C for ; Mon, 9 Jan 2012 00:19:33 -0800 (PST) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1RkAS1-00011O-P7; Mon, 09 Jan 2012 09:19:29 +0100 Received: from localhost by x27.adm.denic.de with local id 1RkAS1-0002vp-II; Mon, 09 Jan 2012 09:19:29 +0100 Date: Mon, 9 Jan 2012 09:19:29 +0100 From: Peter Koch To: IETF DANE WG list Message-ID: <20120109081929.GT13424@x27.adm.denic.de> Mail-Followup-To: IETF DANE WG list References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 08:19:34 -0000 On Sun, Jan 08, 2012 at 05:56:40PM -0800, Paul Hoffman wrote: > I propose (b) from the ticket. That is, run down the SRV chain fully and then use the final result as the input to the TLSA processing. (b) [target/port of SRV is fed into TLSA processing] is the only choice that makes sense to me in the long run. -Peter From jakob@kirei.se Mon Jan 9 03:35:03 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8A7921F86EC for ; Mon, 9 Jan 2012 03:35:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cRBRH7Su54nk for ; Mon, 9 Jan 2012 03:34:59 -0800 (PST) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id 09B9021F852C for ; Mon, 9 Jan 2012 03:34:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=bAv5b49uTMIvGGhBBEByiPmDA0ZNhPZ8kJt/nv9L/y4=; b=h1L74oLgJHVt2jtq5BQ1T/Xsz4qlrlUmCT5aCzSJn104bJCHwl8nyEa4aEuWbvi7hm83fkzfqUFsM T4OTv2WKrHGFhXYRS96mCogObmbjcr3AJzHuqpk7woRGZjYFigeSyIZCE9O2QN6xAHtM4zmcZLVUj1 hpC3mGUS63kx32SU= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Mon, 9 Jan 2012 12:34:25 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: Date: Mon, 9 Jan 2012 12:34:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> To: Paul Hoffman X-Mailer: Apple Mail (2.1251.1) Cc: IETF DANE WG list Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 11:35:03 -0000 On 9 jan 2012, at 02:56, Paul Hoffman wrote: > I propose (b) from the ticket. That is, run down the SRV chain fully = and then use the final result as the input to the TLSA processing. +1. Thinking about how this could actually work in a large distributed = environment (think Google Apps), this is the reasonable choice. I know = other drafts has chosen a different path, but that has/will lead to = scalability problems (think about what happens when Google want to roll = the key for aspmx.l.google.com). Btw, this also applies to MX. IMHO, the TLSA record is for the _server_ = endpoint, not the service endpoint. jakob From rbarnes@bbn.com Mon Jan 9 05:13:50 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8C0721F8762 for ; Mon, 9 Jan 2012 05:13:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8W7lEq4cndq0 for ; Mon, 9 Jan 2012 05:13:46 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 92C4B21F8760 for ; Mon, 9 Jan 2012 05:13:46 -0800 (PST) Received: from [128.89.255.38] (port=60084 helo=[192.168.1.3]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RkF2k-0005PO-Uc; Mon, 09 Jan 2012 08:13:43 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Mon, 9 Jan 2012 08:13:41 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7A4B9C55-52C3-4A93-9DA7-62F98CF2A6A5@bbn.com> References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> To: Jakob Schlyter X-Mailer: Apple Mail (2.1084) Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 13:13:50 -0000 Neither option in the ticket is correct. This is an application layer = issue, not a DANE issue. The client should look up the DANE record for the name it's trying to = authenticate, which is defined by the application layer's needs. For = example, in the example in the ticket, the application might do TLSA to = bob.com if the SRV record is signed with DNSSEC, and to alice.com if = not. (c.f., draft-ietf-xmpp-dna) DANE simply defines an algorithm mapping (name,transport,port) tuples to = certs. We do not have to cover every case of how you get those inputs = or how you decide which ones to use. That's what application-layer = protocols are for. Suggest closing this with no action, or by adding explanatory examples = of the many ways you can end up with a name/transport/port tuple. --Richard On Jan 9, 2012, at 6:34 AM, Jakob Schlyter wrote: > On 9 jan 2012, at 02:56, Paul Hoffman wrote: >=20 >> I propose (b) from the ticket. That is, run down the SRV chain fully = and then use the final result as the input to the TLSA processing. >=20 > +1. >=20 > Thinking about how this could actually work in a large distributed = environment (think Google Apps), this is the reasonable choice. I know = other drafts has chosen a different path, but that has/will lead to = scalability problems (think about what happens when Google want to roll = the key for aspmx.l.google.com). >=20 > Btw, this also applies to MX. IMHO, the TLSA record is for the = _server_ endpoint, not the service endpoint. >=20 > jakob >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From paul.hoffman@vpnc.org Mon Jan 9 07:13:51 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABFB221F87FF for ; Mon, 9 Jan 2012 07:13:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6zcY+EDX8Xn for ; Mon, 9 Jan 2012 07:13:46 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 81DFA21F8797 for ; Mon, 9 Jan 2012 07:13:46 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q09FDeuw059897 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 9 Jan 2012 08:13:40 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <7A4B9C55-52C3-4A93-9DA7-62F98CF2A6A5@bbn.com> Date: Mon, 9 Jan 2012 07:13:40 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <03EDD353-7C2F-4E2E-911A-117673C94FAF@vpnc.org> References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> <7A4B9C55-52C3-4A93-9DA7-62F98CF2A6A5@bbn.com> To: "Richard L. Barnes" X-Mailer: Apple Mail (2.1251.1) Cc: IETF DANE WG list Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 15:13:51 -0000 On Jan 9, 2012, at 5:13 AM, Richard L. Barnes wrote: > Neither option in the ticket is correct. This is an application layer = issue, not a DANE issue. DANE is run by applications. > The client should look up the DANE record for the name it's trying to = authenticate, which is defined by the application layer's needs. Applications running TLS are not "trying to authenticate names": they = are trying to bind a certificate to the name that they used to get to = the TLS service. > For example, in the example in the ticket, the application might do = TLSA to bob.com if the SRV record is signed with DNSSEC, and to = alice.com if not. (c.f., draft-ietf-xmpp-dna) That expired draft does not seem to be coming to consensus in the XMPP = WG. Discussion there a year ago indicates that some people there have = the same opinions as some people here.=20 > DANE simply defines an algorithm mapping (name,transport,port) tuples = to certs. We do not have to cover every case of how you get those = inputs or how you decide which ones to use. That's what = application-layer protocols are for. That's one view. Another is "well-used IETF protocols that make the = algorithm mapping not straight-forward should be covered". > Suggest closing this with no action, or by adding explanatory examples = of the many ways you can end up with a name/transport/port tuple. By the use of the plural "examples", it sounds like you want multiple, = non-interoperable methods. I hope that is not what this WG wants. --Paul Hoffman From ogud@ogud.com Mon Jan 9 08:10:31 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C793121F86DE for ; Mon, 9 Jan 2012 08:10:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCgRwOD6sGYJ for ; Mon, 9 Jan 2012 08:10:31 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 170FD21F86CC for ; Mon, 9 Jan 2012 08:10:31 -0800 (PST) Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id q09GABOt017571 for ; Mon, 9 Jan 2012 11:10:12 -0500 (EST) (envelope-from ogud@ogud.com) Message-ID: <4F0B1162.1080304@ogud.com> Date: Mon, 09 Jan 2012 11:10:10 -0500 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: dane@ietf.org References: <8A3B478E-6D5F-4DF7-80FC-895B5C47675B@kumari.net> <026B2D43-F056-44B5-BCEA-825CC57B0BD7@vpnc.org> In-Reply-To: <026B2D43-F056-44B5-BCEA-825CC57B0BD7@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Subject: Re: [dane] Opening Issue #35 - Behavior for a supported algorithm that is not considered "strong" by the client. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 16:10:32 -0000 On 08/01/2012 21:00, Paul Hoffman wrote: > At the end of section 4.4, we currently say: > If a certificate association contains a certificate usage, selector, > or matching type that is not understood by the TLS client, that > certificate association MUST be marked as unusable. If the > comparison data for a certificate is malformed, the certificate > association MUST be marked as unusable. > > I propose that we add: > If a certificate association contains a matching type or certificate > for association that uses a cryptographic algorithm that is > considered too weak for the TLS client's policy, the certificate > association MUST be marked as unusable. > > --Paul Hoffman > +1 In general to the text, but can we convert this to a list for readability? Something like: (rough draft) If a certificate association contains one or more of the following conditions: - certification usage, select or machining type that is not understood - uses a cryptographic algorithm considered too weak by policy - comparison data for the certificate is malformed the client MUST mark that certificate association as unusable. Olafur Olafur From rbarnes@bbn.com Mon Jan 9 08:11:32 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E697321F86DA for ; Mon, 9 Jan 2012 08:11:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DzTaZDI+2r2f for ; Mon, 9 Jan 2012 08:11:28 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 424B721F86CC for ; Mon, 9 Jan 2012 08:11:28 -0800 (PST) Received: from [128.89.255.38] (port=61833 helo=[192.168.1.3]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RkHol-000A2Y-8g; Mon, 09 Jan 2012 11:11:27 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <03EDD353-7C2F-4E2E-911A-117673C94FAF@vpnc.org> Date: Mon, 9 Jan 2012 11:11:26 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> <7A4B9C55-52C3-4A93-9DA7-62F98CF2A6A5@bbn.com> <03EDD353-7C2F-4E2E-911A-117673C94FAF@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1084) Cc: IETF DANE WG list Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 16:11:33 -0000 >> Neither option in the ticket is correct. This is an application = layer issue, not a DANE issue. >=20 > DANE is run by applications. So is TLS. Does TLS define what names have to be in a certificate? No, = RFC 2818 does, for example, or RFC 6121. =20 >> For example, in the example in the ticket, the application might do = TLSA to bob.com if the SRV record is signed with DNSSEC, and to = alice.com if not. (c.f., draft-ietf-xmpp-dna) >=20 > That expired draft does not seem to be coming to consensus in the XMPP = WG. Discussion there a year ago indicates that some people there have = the same opinions as some people here.=20 Nonetheless, there is a desire in the group to deal with secure = delegation through SRV, which will impact which name you require a = server to authenticate. =20 >> DANE simply defines an algorithm mapping (name,transport,port) tuples = to certs. We do not have to cover every case of how you get those = inputs or how you decide which ones to use. That's what = application-layer protocols are for. >=20 > That's one view. Another is "well-used IETF protocols that make the = algorithm mapping not straight-forward should be covered". Another view is "That's a rat-hole I don't want to dive into." :) >> Suggest closing this with no action, or by adding explanatory = examples of the many ways you can end up with a name/transport/port = tuple. >=20 > By the use of the plural "examples", it sounds like you want multiple, = non-interoperable methods. I hope that is not what this WG wants. Not that I want, but that there *exist* many ways that an application = figures out which names to authenticate. Just to pick a few examples = off the top of my head: -- HTTP uses names in URLs -- XMPP uses SRV -- SMTP/POP/IMAP use MX -- LoST/HELD/possibly-ALTO use NAPTR If this group wants to address all these cases, they'll have to consider = what happens in each of these cases, including secure/insecure cases, = chained delegation cases, etc. But keep in mind that "non-interoperable" in this case *doesn't* = *matter*, because you're talking about completely separate applications. = So there's no harm in not addressing the above cases, as long as any = given application can figure out (interoperably) which = host/transport/port it should plug into the DANE library. I would suggest that if there is a concrete recommendation to be made = here, then it's of the following character: " An application protocol using DANE MUST specify which names, protocols, = and ports an implementation uses to locate DANE records. Protocols that = have requirements that servers authenticate particular names = (independent of DANE) SHOULD use those names to locate DANE records. = For example, XMPP [RFC6121] requires that the server that is the target = of an SRV record present a certificate containing the source name of the = SRV. In this case, clients should also use the source record to locate = DANE records.=20 " From mamille2@cisco.com Mon Jan 9 08:16:26 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1988021F874C for ; Mon, 9 Jan 2012 08:16:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yN603Sj7ZhSB for ; Mon, 9 Jan 2012 08:16:21 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id DCB1421F8734 for ; Mon, 9 Jan 2012 08:16:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=6959; q=dns/txt; s=iport; t=1326125781; x=1327335381; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=+pEhRdwrMSViqzfdi6uGKulmTzKd7rzamp0LRyR3QRs=; b=eXs8wnNfl5/u7T36/3pb14sFQ/3hcbvfcKZz2t0bJ80EOof4v3mTm8J/ Ge9REXsd/W95/onFR4WbgEjlcQV8swIbQ4JpqroxBHKyNouOD8MndPl1N JIyMqd66EHNFBGaBnQM0hsmn4G1yUNPqKUGQMkXC57KHnCD6vU6lg0H2w s=; X-Files: smime.p7s : 2214 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIMSC0+rRDoI/2dsb2JhbABErFKBBYFyAQEBAwESAWYFCwtGAlUGEyKHWJgIAZ5Biy5jBIg5hXKGXpJZ X-IronPort-AV: E=Sophos;i="4.71,480,1320624000"; d="p7s'?scan'208";a="22780139" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 09 Jan 2012 16:16:20 +0000 Received: from dhcp-64-101-72-218.cisco.com (dhcp-64-101-72-218.cisco.com [64.101.72.218]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q09GGKWm017216; Mon, 9 Jan 2012 16:16:20 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-33--73759038; protocol="application/pkcs7-signature"; micalg=sha1 From: Matt Miller In-Reply-To: Date: Mon, 9 Jan 2012 09:16:31 -0700 Message-Id: References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> <7A4B9C55-52C3-4A93-9DA7-62F98CF2A6A5@bbn.com> <03EDD353-7C2F-4E2E-911A-117673C94FAF@vpnc.org> To: IETF DANE WG list X-Mailer: Apple Mail (2.1084) Cc: Paul Hoffman Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 16:16:26 -0000 --Apple-Mail-33--73759038 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jan 9, 2012, at 09:11, Richard L. Barnes wrote: >>> Neither option in the ticket is correct. This is an application = layer issue, not a DANE issue. >>=20 >> DANE is run by applications. >=20 > So is TLS. Does TLS define what names have to be in a certificate? = No, RFC 2818 does, for example, or RFC 6121. =20 >=20 >=20 >>> For example, in the example in the ticket, the application might do = TLSA to bob.com if the SRV record is signed with DNSSEC, and to = alice.com if not. (c.f., draft-ietf-xmpp-dna) >>=20 >> That expired draft does not seem to be coming to consensus in the = XMPP WG. Discussion there a year ago indicates that some people there = have the same opinions as some people here.=20 >=20 > Nonetheless, there is a desire in the group to deal with secure = delegation through SRV, which will impact which name you require a = server to authenticate. =20 >=20 I would say that draft-ietf-xmpp-dna expired not for lack of interest, = but because there have been bigger issues for the XMPP WG to address. = There is still a desire (need) to handle secure delegation in XMPP. >=20 >>> DANE simply defines an algorithm mapping (name,transport,port) = tuples to certs. We do not have to cover every case of how you get = those inputs or how you decide which ones to use. That's what = application-layer protocols are for. >>=20 >> That's one view. Another is "well-used IETF protocols that make the = algorithm mapping not straight-forward should be covered". >=20 > Another view is "That's a rat-hole I don't want to dive into." :) >=20 >=20 >>> Suggest closing this with no action, or by adding explanatory = examples of the many ways you can end up with a name/transport/port = tuple. >>=20 >> By the use of the plural "examples", it sounds like you want = multiple, non-interoperable methods. I hope that is not what this WG = wants. >=20 > Not that I want, but that there *exist* many ways that an application = figures out which names to authenticate. Just to pick a few examples = off the top of my head: > -- HTTP uses names in URLs > -- XMPP uses SRV > -- SMTP/POP/IMAP use MX > -- LoST/HELD/possibly-ALTO use NAPTR >=20 > If this group wants to address all these cases, they'll have to = consider what happens in each of these cases, including secure/insecure = cases, chained delegation cases, etc. >=20 > But keep in mind that "non-interoperable" in this case *doesn't* = *matter*, because you're talking about completely separate applications. = So there's no harm in not addressing the above cases, as long as any = given application can figure out (interoperably) which = host/transport/port it should plug into the DANE library. >=20 ^ This ^ > I would suggest that if there is a concrete recommendation to be made = here, then it's of the following character: > " > An application protocol using DANE MUST specify which names, = protocols, and ports an implementation uses to locate DANE records. = Protocols that have requirements that servers authenticate particular = names (independent of DANE) SHOULD use those names to locate DANE = records. For example, XMPP [RFC6121] requires that the server that is = the target of an SRV record present a certificate containing the source = name of the SRV. In this case, clients should also use the source = record to locate DANE records.=20 > " >=20 I think this text addresses it best, in my opinion. - m&m Matt Miller - Collaboration Software Group - Cisco Systems, Inc. --Apple-Mail-33--73759038 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNTCCBTEw ggMZoAMCAQICAwmYMjANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEyMTQxNzQ3MTlaFw0x MjEyMTMxNzQ3MTlaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjgf4wgfswDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMB0GA1UdEQQWMBSBEm1hbWlsbGUyQGNpc2NvLmNvbTAN BgkqhkiG9w0BAQUFAAOCAgEAoa/WVlTWG/rbVIFlG1tCdJrbVvIWNfUNSgojunKsoaVGCoIh7T1+ SgWe8sV+r7s5bVlq66iGxTm/qoKMHM9i4aNGlwWDkXqLHoCKbY4qKPGKnn7PaoA6DWQ5u7ZKBkn9 N2fY8iLxiAy/hLnjtRLlbSr2yBX0DbO1K0ORLDwfO2MUf1j2Cou+qVvEmyEe7cUq37iOOsNbtghT xjn+RE7WJiHcR9deAkfI1xXi7UZcFME+k6nhdnX/qWFFLox0fJJCzX1H8DTzRIjA+ciNLWSG+TRx s7fAn+YZisJdkGxMcWlHZxSu+ybPjc9T7zCyf4+yFHigdOMNxiQ2k/E9WTJ84xIis2TG3E9Nba9B PMb6cgjiqGxiFpKKHj9/5A3wDIHZ8dof+M7YFGnHzwF9i72ZEoaO3hMEhAg9LhqGtQtEZohbTZL2 FOeT+8VjUHSOKhEYurQjWrHDj+ZyDjzhOE/KMwqSWokZhoy0s+VQ05BrVlbXd5DJaB/Hem0MdDUc /6IjqtI6f8O/HLQFAVUQgtW50bfCjDOAB/SaEKzygblcAHxSKDbduRQaRst6cIHEy4eQxvxrHIhg b2KWZ00jS+7NUnAMOyzIJTcZfV5mkCb8UjMHq9NSChwpBFuDzpXxjU20xJGDvbVWNDwfbITCczph p4uuhLITzvhHKaUNwxoqx0oxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYD VQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRo b3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCZgyMAkGBSsOAwIaBQCg ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDEwOTE2MTYz MlowIwYJKoZIhvcNAQkEMRYEFFOLnZhkSwVHKsYEkhrt9Lqq9N5kMIGRBgkrBgEEAYI3EAQxgYMw gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0 QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq hkiG9w0BAQEFAASCAQCKfR5hK027AwwC+J8wWfj4OssLKE4SZK+0jXGIEdipntIvFuYKlaF9pRbS vGn6cYGiw3SW0xvyKmf0/VB1KwplMYesnqWieZ+nP1Pb7ZCxiJZZTovAYPm/cqd0rTI7F4nACdhy OLPRuKVqnWoVeen3xh7FBEVLVg1tNVyB1MVo6N2YkED4P2uDINnIYFtWA0qBsl7wBm7xxtVOkbfV FeX0tddhlI9ShD5dYeElOn2FwAjvNUNBSubipI4W0z4z+/KtQcqTGQ4gXy8bhqDcnTJmPVWKpy7q ZFo0LBx6XIZ8GZeeKlJiLd+qiSh1sbbnakXSjmYDCs27BrJynbKmYLVYAAAAAAAA --Apple-Mail-33--73759038-- From stpeter@stpeter.im Mon Jan 9 08:44:37 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAB5121F858D for ; Mon, 9 Jan 2012 08:44:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKmDfL0LXI0x for ; Mon, 9 Jan 2012 08:44:33 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8909721F8552 for ; Mon, 9 Jan 2012 08:44:33 -0800 (PST) Received: from dhcp-64-101-72-243.cisco.com (unknown [64.101.72.243]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9F3E740058; Mon, 9 Jan 2012 09:53:27 -0700 (MST) Message-ID: <4F0B1969.5020106@stpeter.im> Date: Mon, 09 Jan 2012 09:44:25 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Matt Miller References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> <7A4B9C55-52C3-4A93-9DA7-62F98CF2A6A5@bbn.com> <03EDD353-7C2F-4E2E-911A-117673C94FAF@vpnc.org> In-Reply-To: X-Enigmail-Version: 1.3.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 16:44:37 -0000 On 1/9/12 9:16 AM, Matt Miller wrote: > > On Jan 9, 2012, at 09:11, Richard L. Barnes wrote: > >> I would suggest that if there is a concrete recommendation to be >> made here, then it's of the following character: " An application >> protocol using DANE MUST specify which names, protocols, and ports >> an implementation uses to locate DANE records. Protocols that have >> requirements that servers authenticate particular names >> (independent of DANE) SHOULD use those names to locate DANE >> records. For example, XMPP [RFC6121] requires that the server that >> is the target of an SRV record present a certificate containing the >> source name of the SRV. In this case, clients should also use the >> source record to locate DANE records. " > > I think this text addresses it best, in my opinion. WFM (other than s/6121/6120/). Peter -- Peter Saint-Andre http://stpeter.im/ From paul.hoffman@vpnc.org Mon Jan 9 09:39:48 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C469B11E80E8 for ; Mon, 9 Jan 2012 09:39:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8xA6Kk4RErP for ; Mon, 9 Jan 2012 09:39:46 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 580FB11E80BD for ; Mon, 9 Jan 2012 09:39:43 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q09HdgdU065921 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 9 Jan 2012 10:39:42 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Paul Hoffman In-Reply-To: Date: Mon, 9 Jan 2012 09:39:42 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> <7A4B9C55-52C3-4A93-9DA7-62F98CF2A6A5@bbn.com> <03EDD353-7C2F-4E2E-911A-117673C94FAF@vpnc.org> To: IETF DANE WG list X-Mailer: Apple Mail (2.1251.1) Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 17:39:49 -0000 On Jan 9, 2012, at 8:11 AM, Richard L. Barnes wrote: > I would suggest that if there is a concrete recommendation to be made = here, then it's of the following character: > " > An application protocol using DANE MUST specify which names, = protocols, and ports an implementation uses to locate DANE records. = Protocols that have requirements that servers authenticate particular = names (independent of DANE) SHOULD use those names to locate DANE = records. For example, XMPP [RFC6121] requires that the server that is = the target of an SRV record present a certificate containing the source = name of the SRV. In this case, clients should also use the source = record to locate DANE records.=20 > " The first sentence means that DANE cannot be used for any protocol. I = know that's not what you mean, but this kind of sloppy wording doesn't = help. Counter-proposal with hopefully clearer words: Clients of protocols that have requirements that servers authenticate = themselves in TLS particular names MUST use those names to locate TLSA = records. For example, XMPP [RFC6120] requires that the server that is = the target of an SRV record present a certificate containing the source = name of the SRV; thus, SMTP clients would use the source record to = locate TLSA records. If a protocol does not have a requirement for = authenticating particular names, or has a requirement that includes many = different names, the client MUST use the "reference identity" as defined = in [RFC6125]. --Paul Hoffman From sm@resistor.net Mon Jan 9 11:53:17 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDBA01F0C38 for ; Mon, 9 Jan 2012 11:53:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9c85DR53B48 for ; Mon, 9 Jan 2012 11:53:17 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 29AB51F0C36 for ; Mon, 9 Jan 2012 11:53:16 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q09Jr6Yl029784 for ; Mon, 9 Jan 2012 11:53:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1326138792; i=@resistor.net; bh=8oJyzpHxfce9BR7Pg7oUW00YX55/NuDFkOgOffpcNkM=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=noxwIqFEqxLOGK4uuidzyZMO4M1J6DPwPeLDPhEwMO7OakWXPJAvYfByx5Rbcpyqd WI2dRfUAiKBk0S0lD5GsF6/8RqPcb6z7eyhODEoH9TNzYzaklCml8+pfTtG/tJNw0Z CW0Gg5Ga5XXnP1Ka6fpSE2RNXWjoYj3qs1d798b4= Message-Id: <6.2.5.6.2.20120109111158.0afa4898@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 09 Jan 2012 11:17:05 -0800 To: IETF DANE WG list From: SM In-Reply-To: References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> <7A4B9C55-52C3-4A93-9DA7-62F98CF2A6A5@bbn.com> <03EDD353-7C2F-4E2E-911A-117673C94FAF@vpnc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 19:53:17 -0000 At 09:39 09-01-2012, Paul Hoffman wrote: >The first sentence means that DANE cannot be used for any protocol. >I know that's not what you mean, but this kind of sloppy wording doesn't help. Yes. >Counter-proposal with hopefully clearer words: > >Clients of protocols that have requirements that servers >authenticate themselves in TLS particular names MUST use those names >to locate TLSA records. For example, XMPP [RFC6120] requires that >the server that is the target of an SRV record present a certificate >containing the source name of the SRV; thus, SMTP clients would use >the source record to locate TLSA records. If a protocol does not >have a requirement for authenticating particular names, or has a >requirement that includes many different names, the client MUST use >the "reference identity" as defined in [RFC6125]. It is still not that clear as the requirements have to be interpreted. I suggest going for the intent the WG can agree upon for now and fine tune later. Regards, -sm From cloos@jhcloos.com Mon Jan 9 12:45:47 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8A31F0C36 for ; Mon, 9 Jan 2012 12:45:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.442 X-Spam-Level: X-Spam-Status: No, score=-1.442 tagged_above=-999 required=5 tests=[AWL=1.158, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uf14bwA823YR for ; Mon, 9 Jan 2012 12:45:46 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by ietfa.amsl.com (Postfix) with ESMTP id 84BD111E8079 for ; Mon, 9 Jan 2012 12:45:46 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 5132E40182; Mon, 9 Jan 2012 20:45:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1326141944; bh=fT/EY9LBJFe/bFCTZpEx6E47iaSin2rGaFVft77nL4A=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=vPdHBDEyiOkVJCNTjIachTwkfafgLm9mDhIMnTHGlQ1sBrUEtXm78GPGmk1MwEYoj +AuE6v+wjnJtK5yeObo3f7WGzMQYPAMXpCcP88H2ugYPZzLTjjTcKWn3Z0XDZfmgDv 0tf9LuhHYmfT+Bx+V0htxRkMV+2EMgYcd/m+LIfU= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 5552636004C; Mon, 9 Jan 2012 20:44:07 +0000 (UTC) From: James Cloos To: Paul Hoffman In-Reply-To: (Paul Hoffman's message of "Mon, 9 Jan 2012 09:39:42 -0800") References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> <7A4B9C55-52C3-4A93-9DA7-62F98CF2A6A5@bbn.com> <03EDD353-7C2F-4E2E-911A-117673C94FAF@vpnc.org> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.92 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2011 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Mon, 09 Jan 2012 15:44:07 -0500 Message-ID: Lines: 39 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:120109:paul.hoffman@vpnc.org::mNCoyCWSJ2qQg7yr:000000000000000000000000000000000000000AgFcT X-Hashcash: 1:30:120109:dane@ietf.org::jQYhTdk9+4EfVT0V:0006d0te Cc: IETF DANE WG list Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 20:45:47 -0000 >>>>> "PH" == Paul Hoffman writes: PH> Counter-proposal with hopefully clearer words: PH> thus, SMTP clients would use the source record to locate TLSA PH> records. Smtp should not be an example for this idea. Smtp clients SHOULD use the hostname associated with the A/AAAA lookup for TLSA lookups. It may be reasonable, though, to include some text specifying that the whole DNS chain should be verified in order to trust the TLSA RR. Ie, given: example.com. IN MX mail.example.net and: mail.example.net IN AAAA 2002:0A0B:0C0D::19 _25._tcp.mail.example.net IN TLSA 1 0 1 abcdef... then when sending mail to foo@example.com the client mta SHOULD trust _25._tcp.mail.example.net IN TLSA only as much as it can trust example.com IN MX. That probably should apply equally for sip SRV lookups. It seems, from the thread here, that rfc 6120 defines different semantics for xmpp. Perhaps the best choice, then, is to say that the clients should do a tlsa lookup on the name they expect the server to specify during tls negotiation, and that the whole dns chain from whatever the user presents to the TLSA and A/AAAA RRs should verify. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From paul.hoffman@vpnc.org Mon Jan 9 13:30:39 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7D521F85E7 for ; Mon, 9 Jan 2012 13:30:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AkcCg9QzgF7t for ; Mon, 9 Jan 2012 13:30:38 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 065ED21F85C2 for ; Mon, 9 Jan 2012 13:30:37 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q09LUX8L074076 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 9 Jan 2012 14:30:33 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Paul Hoffman In-Reply-To: Date: Mon, 9 Jan 2012 13:30:33 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> <7A4B9C55-52C3-4A93-9DA7-62F98CF2A6A5@bbn.com> <03EDD353-7C2F-4E2E-911A-117673C94FAF@vpnc.org> To: IETF DANE WG list X-Mailer: Apple Mail (2.1251.1) Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 21:30:39 -0000 OK, that was clearer, but not clear enough. And using a term that RFC = 6125 says it is going to define but doesn't actually do so was probably = a mistake. :-) It would probably be better to explain the semantics as = we define the protocol. New proposal: Add to the end of Section 1.1: The TLSA record is used to make a certificate association between for a = triple of domain name and transport protocol and port number where a TLS = based service is assumed to exist. The triple is used to perform the = lookup described in Section 3. The triple used for TLSA lookup may be = different than what the application started with, such as if the = application protocol uses SRV or MX records to find a server. Similarly, = the certificate association returned in TLSA may have a domain name that = is different than the domain name used in the TLSA query, depending on = the application protocol's rules for TLS server identification. Add to the Security Considerations: The security properties of the TLSA record apply only to the triple of = domain name and transport protocol and port number that was looked up. = If TLSA is used with an application protocol that uses redirection to = find a server (such as SMTP and XMPP), TLSA can only be used if every = step of the redirection chain is protected by DNSSEC and processing = stops for any step where the response is not secure. --Paul Hoffman From ondrej.mikle@nic.cz Mon Jan 9 13:49:13 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C15B511E807A for ; Mon, 9 Jan 2012 13:49:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Fj3lF25LeqZ for ; Mon, 9 Jan 2012 13:49:13 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id EE6B011E8079 for ; Mon, 9 Jan 2012 13:49:12 -0800 (PST) Received: from [172.30.151.65] (ip-84-42-137-177.net.upcbroadband.cz [84.42.137.177]) by mail.nic.cz (Postfix) with ESMTPSA id E27122A0D41 for ; Mon, 9 Jan 2012 22:49:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1326145750; bh=U/cyhKLOySJ4Ka3/elRQcNLoq5lInYPgvOWUzgV+ahI=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=ZI4dhbYHOJJSYpGqIvRwOafiK+1h+ZeAhd7P8Qk/N3AxVUuL9lMv9co3XV6vR8huv FJa7P8wuE3UBhT260kR4KwUf3GLbGdNbhIGmInBE85OPuSxaWerNPGwVGqp9/wnZAy x6xMwOjMjP3WNfXD/bWmeFHMKXdgl7FetJgGiQf4= Message-ID: <4F0B60D4.2090109@nic.cz> Date: Mon, 09 Jan 2012 22:49:08 +0100 From: Ondrej Mikle User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: dane@ietf.org References: <59E1FDB4-B832-415A-BEE3-8E85CC55E337@vpnc.org> <20120105085549.GA6998@nic.fr> In-Reply-To: <20120105085549.GA6998@nic.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: Re: [dane] Pseudocode review X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 21:49:13 -0000 While writing update to "Creating TLSA records" I noticed an additional detail that might be added to paragraph proposed by Stephane: On 01/05/12 09:55, Stephane Bortzmeyer wrote: > For instance, pay attention to the fact that, like most pseudo-codes, > it is more strict than the normative text. For instance, it forces an > order on the evaluation of criteria (X.509 before TLSA when > certificateUsage == 0) which is not mandatory. At the end of the paragraph, I suggest to add sentence: "In practical deployment it might be actually beneficial to switch the pseudocode order and evaluate TLSA criteria before PKIX validation in order to minimize delay due to network operations like revocation checks." Reason is simple: TLSA check is fast compared to OCSP/CRL check, AIA chasing and other chain-building methods proposed in RFC 4158. BTW there is a rather interesting treatment of current PKIX validation libraries in "What exactly are the benefits of libpkix over the old certificate path" threads of http://news.gmane.org/gmane.comp.mozilla.crypto mailinglist archive (Jan 4-Jan 6 2012 messages). Ondrej Mikle From bortzmeyer@nic.fr Tue Jan 10 00:48:23 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F12FB21F8631 for ; Tue, 10 Jan 2012 00:48:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0jBZ9IwEkXet for ; Tue, 10 Jan 2012 00:48:22 -0800 (PST) Received: from mx2.nic.fr (mx2.nic.fr [IPv6:2001:660:3003:2::4:11]) by ietfa.amsl.com (Postfix) with ESMTP id 3738421F85D6 for ; Tue, 10 Jan 2012 00:48:22 -0800 (PST) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 0C2581C0026; Tue, 10 Jan 2012 09:48:21 +0100 (CET) Received: by mx2.nic.fr (Postfix, from userid 500) id EB4201C0091; Tue, 10 Jan 2012 09:48:20 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [IPv6:2001:67c:2218:9::4:163]) by mx2.nic.fr (Postfix) with ESMTP id E1C9B1C0026; Tue, 10 Jan 2012 09:48:20 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [IPv6:2001:67c:2219:8::6:69]) by relay2.nic.fr (Postfix) with ESMTP id 20245B3805C; Tue, 10 Jan 2012 09:48:20 +0100 (CET) Date: Tue, 10 Jan 2012 09:48:20 +0100 From: Stephane Bortzmeyer To: Ondrej Mikle Message-ID: <20120110084820.GA22769@nic.fr> References: <59E1FDB4-B832-415A-BEE3-8E85CC55E337@vpnc.org> <20120105085549.GA6998@nic.fr> <730E49C4-CA7F-4B6D-9FAC-D85A284B51B7@vpnc.org> <4F0616D2.4040308@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F0616D2.4040308@nic.cz> X-Operating-System: Debian GNU/Linux wheezy/sid X-Kernel: Linux 3.1.0-1-686-pae i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.21 (2010-09-15) X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=1.1.5 X-PMX-Version: 5.4.6.353000, Antispam-Engine: 2.6.1.350677, Antispam-Data: 2012.1.10.83615 X-PerlMx-Spam: Gauge=IIIIIII, Probability=8%, Report='BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, BODY_SIZE_700_799 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CD 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __TO_MALFORMED_2 0, __URI_NO_PATH 0, __URI_NO_WWW 0, __USER_AGENT 0' Cc: dane@ietf.org Subject: Re: [dane] Pseudocode review X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 08:48:23 -0000 On Thu, Jan 05, 2012 at 10:32:02PM +0100, Ondrej Mikle wrote a message of 29 lines which said: > (Some of the nested if's could be rewritten as "if (X and Y)" to > avoid explicit PKIX/TLSA evaluation order, but it would hurt clarity > of pseudocode.) -1 Clarity depends on your taste. Personally, I find (X and Y) clearer than (if X (if Y... When people ask for pseudo-code, they typically mean "procedural pseudo-code" while "functional pseudo-code" would be better. Functional pseudo-code can be both a good specification *and* an executable implementation, unlike procedural pseudo-code. Let's replace Fortran pseudo-code by Haskell pseudo-code in RFCs :-) From jakob@kirei.se Tue Jan 10 02:58:09 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B38021F8499 for ; Tue, 10 Jan 2012 02:58:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PVrSE78ylqVg for ; Tue, 10 Jan 2012 02:58:08 -0800 (PST) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id 3290321F86D6 for ; Tue, 10 Jan 2012 02:58:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=qHtnzMF23Mq8X8i9mffWrlth+CqGrgDsBgMC72ZDmdg=; b=1f52UNb1mN8IG0LKOv/l9APTVZT6/5yKiJg/8XT+Ot1R/4B+CXPvFJxu07dOZ/PsPHlv1OTcU5LMk VLRlklqnGwLRNGuPQ4CPBvNkvOGhn0RRPT/cZArEmTWZfrtCrcq0b5b0oSVwAqm87Z0UfS4LRV+YA0 fmngltipO1bMWXO4= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Tue, 10 Jan 2012 11:57:35 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: Date: Tue, 10 Jan 2012 11:57:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> <7A4B9C55-52C3-4A93-9DA7-62F98CF2A6A5@bbn.com> <03EDD353-7C2F-4E2E-911A-117673C94FAF@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1251.1) Cc: IETF DANE WG list Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 10:58:09 -0000 On 9 jan 2012, at 22:30, Paul Hoffman wrote: > Add to the end of Section 1.1: > The TLSA record is used to make a certificate association between for = a triple of domain name and transport protocol and port number where a = TLS based service is assumed to exist. The triple is used to perform the = lookup described in Section 3. The triple used for TLSA lookup may be = different than what the application started with, such as if the = application protocol uses SRV or MX records to find a server. Similarly, = the certificate association returned in TLSA may have a domain name that = is different than the domain name used in the TLSA query, depending on = the application protocol's rules for TLS server identification. >=20 > Add to the Security Considerations: > The security properties of the TLSA record apply only to the triple of = domain name and transport protocol and port number that was looked up. = If TLSA is used with an application protocol that uses redirection to = find a server (such as SMTP and XMPP), TLSA can only be used if every = step of the redirection chain is protected by DNSSEC and processing = stops for any step where the response is not secure. +1 jakob From pieter.lexis@os3.nl Tue Jan 10 05:10:30 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ACB921F8602 for ; Tue, 10 Jan 2012 05:10:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrMgBrpNEUrq for ; Tue, 10 Jan 2012 05:10:29 -0800 (PST) Received: from mail.serv.os3.nl (mail.serv.os3.nl [IPv6:2001:610:158:960::25]) by ietfa.amsl.com (Postfix) with ESMTP id 3949E21F84E1 for ; Tue, 10 Jan 2012 05:09:51 -0800 (PST) Received: from smtp.os3.nl (smtp.os3.nl [IPv6:2001:610:158:960::119]) by mail.serv.os3.nl (Postfix) with ESMTP id 6A19E17AA17 for ; Tue, 10 Jan 2012 14:09:42 +0100 (CET) Received: from [IPv6:2001:610:158:1020:d5a1:bace:1631:a814] (unknown [IPv6:2001:610:158:1020:d5a1:bace:1631:a814]) by smtp.os3.nl (Postfix) with ESMTPSA id 2E1CC17AA0E for ; Tue, 10 Jan 2012 14:09:42 +0100 (CET) Message-ID: <4F0C3895.4030200@os3.nl> Date: Tue, 10 Jan 2012 14:09:41 +0100 From: Pieter Lexis User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111109 Thunderbird/3.1.16 MIME-Version: 1.0 To: dane@ietf.org References: <20120104081557.23741.87139.idtracker@ietfa.amsl.com> In-Reply-To: <20120104081557.23741.87139.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dane] I-D Action: draft-ietf-dane-protocol-14.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 13:10:30 -0000 Hi *, On 01/04/2012 09:15 AM, internet-drafts@ietf.org wrote: > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-dane-protocol-14.txt There is a typo in Appendix A.1.1. on page 17, In the first (non-listing) paragraph: Thes reissued certificates are ..... Should be: These reissued certificates are ..... -- Pieter Lexis From ondrej.sury@nic.cz Tue Jan 10 06:59:26 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4588521F8495 for ; Tue, 10 Jan 2012 06:59:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E1B4zthgQJzJ for ; Tue, 10 Jan 2012 06:59:20 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id A3B6321F873B for ; Tue, 10 Jan 2012 06:59:20 -0800 (PST) Received: from kimac.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id B1EF32A302F; Tue, 10 Jan 2012 15:59:19 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1326207559; bh=W8WrxySUhPwUSWaANPE/UljHbSTkzvB3dJraFJ59XRM=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Tsa7gK2X9XllFdimMdYfpNhxtJFw0nbIpkqOcmUFV5bb7M+BOZn2Lyk9dh13X7JlH 7O/domRDDih9SA2wumg4akLXicujD4K3uRgxtIXjVmtMmFmnqyvoVKH6U+I9g6xm9a z5hRsfTqWEDPaPvDITc4XelDAAqY16Df3GL+unQo= Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <4F0B1162.1080304@ogud.com> Date: Tue, 10 Jan 2012 15:59:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3C2FA271-6A49-4A7B-A871-AE19FF3318DC@nic.cz> References: <8A3B478E-6D5F-4DF7-80FC-895B5C47675B@kumari.net> <026B2D43-F056-44B5-BCEA-825CC57B0BD7@vpnc.org> <4F0B1162.1080304@ogud.com> To: Olafur Gudmundsson X-Mailer: Apple Mail (2.1251.1) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane@ietf.org Subject: Re: [dane] Opening Issue #35 - Behavior for a supported algorithm that is not considered "strong" by the client. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 14:59:26 -0000 On 9. 1. 2012, at 17:10, Olafur Gudmundsson wrote: > On 08/01/2012 21:00, Paul Hoffman wrote: >> At the end of section 4.4, we currently say: >> If a certificate association contains a certificate usage, = selector, >> or matching type that is not understood by the TLS client, that >> certificate association MUST be marked as unusable. If the >> comparison data for a certificate is malformed, the certificate >> association MUST be marked as unusable. >>=20 >> I propose that we add: >> If a certificate association contains a matching type or = certificate >> for association that uses a cryptographic algorithm that is >> considered too weak for the TLS client's policy, the certificate >> association MUST be marked as unusable. +1 here >> --Paul Hoffman >>=20 > +1 In general to the text, but can we convert this to a list for = readability? >=20 > Something like: (rough draft) > If a certificate association contains one or more of the following = conditions: > - certification usage, select or machining type that is not = understood > - uses a cryptographic algorithm considered too weak by policy > - comparison data for the certificate is malformed > the client MUST mark that certificate association as unusable. Also +1 here O. -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From ondrej.sury@nic.cz Tue Jan 10 07:08:02 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5432821F879C for ; Tue, 10 Jan 2012 07:08:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXT5sie90Iv2 for ; Tue, 10 Jan 2012 07:08:01 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 8A05721F8798 for ; Tue, 10 Jan 2012 07:08:01 -0800 (PST) Received: from kimac.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id BCAF62A2FB3 for ; Tue, 10 Jan 2012 16:08:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1326208080; bh=FULMP57qY/2KzWhrSPqE/V2ShpABdXRBAe7gCdUvK/U=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=Hy4/VCe/0EjqbXyiNsUYbCuoTVdzkOfFhZM0OlVo4vZEgw10Zcwt8llW0oiny175p ApAlhBTP0QxmQ7aJ/Tm2L1PLaVyQmAJN8KklgrUz13JZVcCeh5+ZKswuq6iFkoa90i mWM56vR1yhxohDlYunLVYRJ/yFrA9mB6jVyxElgA= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Apple Message framework v1251.1) From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: Date: Tue, 10 Jan 2012 16:07:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> <7A4B9C55-52C3-4A93-9DA7-62F98CF2A6A5@bbn.com> <03EDD353-7C2F-4E2E-911A-117673C94FAF@vpnc.org> To: IETF DANE WG list X-Mailer: Apple Mail (2.1251.1) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 15:08:02 -0000 LGTM On 9. 1. 2012, at 22:30, Paul Hoffman wrote: > OK, that was clearer, but not clear enough. And using a term that RFC = 6125 says it is going to define but doesn't actually do so was probably = a mistake. :-) It would probably be better to explain the semantics as = we define the protocol. New proposal: >=20 > Add to the end of Section 1.1: > The TLSA record is used to make a certificate association between for = a triple of domain name and transport protocol and port number where a = TLS based service is assumed to exist. The triple is used to perform the = lookup described in Section 3. The triple used for TLSA lookup may be = different than what the application started with, such as if the = application protocol uses SRV or MX records to find a server. Similarly, = the certificate association returned in TLSA may have a domain name that = is different than the domain name used in the TLSA query, depending on = the application protocol's rules for TLS server identification. >=20 > Add to the Security Considerations: > The security properties of the TLSA record apply only to the triple of = domain name and transport protocol and port number that was looked up. = If TLSA is used with an application protocol that uses redirection to = find a server (such as SMTP and XMPP), TLSA can only be used if every = step of the redirection chain is protected by DNSSEC and processing = stops for any step where the response is not secure. -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From paul.hoffman@vpnc.org Tue Jan 10 07:43:25 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF70021F871B for ; Tue, 10 Jan 2012 07:43:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79jIL0J1WJoO for ; Tue, 10 Jan 2012 07:43:25 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id A22E021F8613 for ; Tue, 10 Jan 2012 07:43:24 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0AFhNfV014525 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 10 Jan 2012 08:43:24 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Paul Hoffman In-Reply-To: Date: Tue, 10 Jan 2012 07:43:23 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <689C663D-4898-4C2D-858C-BE01CA38B666@vpnc.org> References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> <7A4B9C55-52C3-4A93-9DA7-62F98CF2A6A5@bbn.com> <03EDD353-7C2F-4E2E-911A-117673C94FAF@vpnc.org> To: IETF DANE WG list X-Mailer: Apple Mail (2.1251.1) Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 15:43:26 -0000 In thinking about it more, I realized I over-stated the security = problem. There is no problem for SMTP, but there is one for XMPP. The = problem is that XMPP specifies that the identity in the TLS server's = certificate must be that of the *beginning* of the chain, not of the = server itself. This allows XMPP to have insecure redirections through = SRV; as along as the client ends up at the correct server, even = insecurely, TLS will bind the server to the original identity. SMTP (and = probably other protocols) don't try to make this binding. > Add to the end of Section 1.1: > The TLSA record is used to make a certificate association between for = a triple of domain name and transport protocol and port number where a = TLS based service is assumed to exist. The triple is used to perform the = lookup described in Section 3. The triple used for TLSA lookup may be = different than what the application started with, such as if the = application protocol uses SRV or MX records to find a server. Similarly, = the certificate association returned in TLSA may have a domain name that = is different than the domain name used in the TLSA query, depending on = the application protocol's rules for TLS server identification. >=20 > Add to the Security Considerations: > The security properties of the TLSA record apply only to the triple of = domain name and transport protocol and port number that was looked up. = If TLSA is used with an application protocol that uses redirection to = find a server (such as SMTP and XMPP), TLSA can only be used if every = step of the redirection chain is protected by DNSSEC and processing = stops for any step where the response is not secure. More accurate wording for the last sentence would be: If TLSA is used with an application protocol such as XMPP that uses = redirection to find a server and requires that the TLS server's identity = match a host earlier in the redirection chain, TLSA can only be used if = every step of the redirection chain is protected by DNSSEC and = processing stops for any step where the response is not secure. --Paul Hoffman From rbarnes@bbn.com Tue Jan 10 08:09:48 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02B9221F84B6 for ; Tue, 10 Jan 2012 08:09:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmV56eRjy67A for ; Tue, 10 Jan 2012 08:09:47 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id B8EF121F84A1 for ; Tue, 10 Jan 2012 08:09:46 -0800 (PST) Received: from [128.89.255.85] (port=64957 helo=[10.50.111.48]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RkeGf-0000f5-VM; Tue, 10 Jan 2012 11:09:46 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <689C663D-4898-4C2D-858C-BE01CA38B666@vpnc.org> Date: Tue, 10 Jan 2012 11:09:45 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> <7A4B9C55-52C3-4A93-9DA7-62F98CF2A6A5@bbn.com> <03EDD353-7C2F-4E2E-911A-117673C94FAF@vpnc.org> <689C663D-4898-4C2D-858C-BE01CA38B666@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1084) Cc: IETF DANE WG list Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 16:09:48 -0000 > In thinking about it more, I realized I over-stated the security = problem. There is no problem for SMTP, but there is one for XMPP. The = problem is that XMPP specifies that the identity in the TLS server's = certificate must be that of the *beginning* of the chain, not of the = server itself. This allows XMPP to have insecure redirections through = SRV; as along as the client ends up at the correct server, even = insecurely, TLS will bind the server to the original identity. SMTP (and = probably other protocols) don't try to make this binding. Of course, if this were true, it would leave SMTP open to poisoning = attacks against MX records. But SMTP actually does do the same thing as = XMPP, just not normatively. XMPP [RFC6120] " The identities to be checked are set as follows: o The initiating entity sets the source domain of its reference identifiers to the 'to' address it communicates in the initial stream header; i.e., this is the identity it expects the receiving entity to provide in a PKIX certificate. " SMTP [RFC3207] " The decision of whether or not to believe the authenticity of the other party in a TLS negotiation is a local matter. However, some general rules for the decisions are: - A SMTP client would probably only want to authenticate an SMTP server whose server certificate has a domain name that is the domain name that the client thought it was connecting to. " >> Add to the end of Section 1.1: >> The TLSA record is used to make a certificate association between for = a triple of domain name and transport protocol and port number where a = TLS based service is assumed to exist. The triple is used to perform the = lookup described in Section 3. The triple used for TLSA lookup may be = different than what the application started with, such as if the = application protocol uses SRV or MX records to find a server. Similarly, = the certificate association returned in TLSA may have a domain name that = is different than the domain name used in the TLSA query, depending on = the application protocol's rules for TLS server identification. Editorial: An association needs to be between two things. And it's bad = to assume, especially in protocol design :) " The TLSA record is used to make an association between a certificate and = a (domain name, transport protocol, port number) triple where a TLS = service may exist. " >> Add to the Security Considerations: >> The security properties of the TLSA record apply only to the triple = of domain name and transport protocol and port number that was looked = up. If TLSA is used with an application protocol that uses redirection = to find a server (such as SMTP and XMPP), TLSA can only be used if every = step of the redirection chain is protected by DNSSEC and processing = stops for any step where the response is not secure. >=20 > More accurate wording for the last sentence would be: >=20 > If TLSA is used with an application protocol such as XMPP that uses = redirection to find a server and requires that the TLS server's identity = match a host earlier in the redirection chain, TLSA can only be used if = every step of the redirection chain is protected by DNSSEC and = processing stops for any step where the response is not secure. This seems like it would make deployability much harder than just saying = "use the name you're looking for". Wouldn't the same considerations = apply to, say, CNAME? And that applies regardless of the protocol. So = you're left only allowing DANE in a perfect world of universal DNSSEC. By contrast, each implementation knows what name(s) it's trying to = authenticate because it's going strcmp() to the names in the certificate = (since current security mechanisms are based on name matching). Just = let it use those name(s) for finding TLSA. That's all my proposed text = did. Revised proposed text follows, based on the above. Seems like it should = go in Section 3, actually. " The TLSA record is used to make an association between a certificate and = a (domain name, transport protocol, port number) triple where a TLS = service may exist. =20 Applications using DANE need to choose carefully which domain names they = use to locate TLSA records, since these domains are trusted to provide = certificate association information; obtaining TLSA information from the = wrong source can lead to clients accepting bogus certificates. = Applications that are seeking to authenticate a specific domain name = MUST use that name to locate DANE records. For example:=20 o An HTTPS client connecting to an HTTP URI would use the name in the = URI [RFC2818] o An SMTP client connecting to an SMTP server would use the name for = the mail domain is is seeking to reach (i.e., the domain used to locate = the MX record) [RFC3207] o An XMPP server connecting to another XMPP server would use the 'to' = address in the initial stream header [RFC6120] This requirement holds even if the ultimate service is redirected to = another domain, for example, via CNAME, MX, SRV, or NAPTR records. = Applications MAY also locate DANE records using the target names of = these redirection records, if and only if the redirection records are = protected by DNSSEC. If a chain of redirections exists, then all = records in the chain MUST be DNSSEC-protected. =20 " --Richard From warren@kumari.net Tue Jan 10 09:04:10 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8721A21F8772 for ; Tue, 10 Jan 2012 09:04:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.105 X-Spam-Level: X-Spam-Status: No, score=-106.105 tagged_above=-999 required=5 tests=[AWL=-0.406, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CytpjVOFSOEQ for ; Tue, 10 Jan 2012 09:04:09 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id C90FF21F875D for ; Tue, 10 Jan 2012 09:04:08 -0800 (PST) Received: from dhcp-172-19-119-228.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 857411B402A0; Tue, 10 Jan 2012 12:03:57 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Warren Kumari In-Reply-To: <3C2FA271-6A49-4A7B-A871-AE19FF3318DC@nic.cz> Date: Tue, 10 Jan 2012 12:03:52 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8A3B478E-6D5F-4DF7-80FC-895B5C47675B@kumari.net> <026B2D43-F056-44B5-BCEA-825CC57B0BD7@vpnc.org> <4F0B1162.1080304@ogud.com> <3C2FA271-6A49-4A7B-A871-AE19FF3318DC@nic.cz> To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= X-Mailer: Apple Mail (2.1084) Cc: dane@ietf.org Subject: Re: [dane] Opening Issue #35 - Behavior for a supported algorithm that is not considered "strong" by the client. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 17:04:10 -0000 [ No hats ]=20 On Jan 10, 2012, at 9:59 AM, Ond=C5=99ej Sur=C3=BD wrote: >=20 > On 9. 1. 2012, at 17:10, Olafur Gudmundsson wrote: >=20 >> On 08/01/2012 21:00, Paul Hoffman wrote: >>> At the end of section 4.4, we currently say: >>> If a certificate association contains a certificate usage, = selector, >>> or matching type that is not understood by the TLS client, that >>> certificate association MUST be marked as unusable. If the >>> comparison data for a certificate is malformed, the certificate >>> association MUST be marked as unusable. >>>=20 >>> I propose that we add: >>> If a certificate association contains a matching type or = certificate >>> for association that uses a cryptographic algorithm that is >>> considered too weak for the TLS client's policy, the certificate >>> association MUST be marked as unusable. >=20 > +1 here +1. >=20 >>> --Paul Hoffman >>>=20 >> +1 In general to the text, but can we convert this to a list for = readability? >>=20 >> Something like: (rough draft) >> If a certificate association contains one or more of the following = conditions: >> - certification usage, select or machining type that is not = understood >> - uses a cryptographic algorithm considered too weak by policy >> - comparison data for the certificate is malformed >> the client MUST mark that certificate association as unusable. >=20 >=20 > Also +1 here +0 (I don't care either way -- I slightly prefer the text as provided, = but not enough to count.) W >=20 > O. > -- > Ond=C5=99ej Sur=C3=BD > vedouc=C3=AD v=C3=BDzkumu/Head of R&D department > ------------------------------------------- > CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC > Americka 23, 120 00 Praha 2, Czech Republic > mailto:ondrej.sury@nic.cz http://nic.cz/ > tel:+420.222745110 fax:+420.222745112 > ------------------------------------------- >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From jakob@kirei.se Tue Jan 10 10:42:53 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A25B21F86D3 for ; Tue, 10 Jan 2012 10:42:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJrbCW0weMIT for ; Tue, 10 Jan 2012 10:42:52 -0800 (PST) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id 482F921F86A3 for ; Tue, 10 Jan 2012 10:42:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=UUv0e6W/FKj3PqtGxXMe+PfZFlTzWUVTgdQf0Pk05PQ=; b=T1M1J51U3w6jL0w6TFB//uQJFZZ8wqGb2Cp1H7e3JVe+VkrbN/p08GqIbkLVVO+ksbgBDbREFjmeZ Gt6g3iomccdwV0n4XXqKLPJ0U6Mgw0ZN5lOBqfUlyXzxeoucIAI0vVvPh7ZsOecoTHdj9am3Q/2RzL 7HXle74HkMlQs/ps= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Tue, 10 Jan 2012 19:42:48 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: Date: Tue, 10 Jan 2012 19:42:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <536F7502-9FCA-484B-8771-E0C7BA6BF14A@kirei.se> References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> <7A4B9C55-52C3-4A93-9DA7-62F98CF2A6A5@bbn.com> <03EDD353-7C2F-4E2E-911A-117673C94FAF@vpnc.org> <689C663D-4898-4C2D-858C-BE01CA38B666@vpnc.org> To: "Richard L. Barnes" X-Mailer: Apple Mail (2.1251.1) Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 18:42:53 -0000 On 10 jan 2012, at 17:09, Richard L. Barnes wrote: > SMTP [RFC3207] > " > The decision of whether or not to believe the authenticity of the > other party in a TLS negotiation is a local matter. However, some > general rules for the decisions are: >=20 > - A SMTP client would probably only want to authenticate an SMTP > server whose server certificate has a domain name that is the > domain name that the client thought it was connecting to. "the domain name that the client thought it was connecting to" could be = interpreted as the domain name found at the right hand side of the MX = record. For SMTP as deployed today, this makes sense - e.g., MX for = kirei.se points to mail.kirei.se, and the TLS cert is CN=3Dmail.kirei.se = (not CN=3Dkirei.se or the like). jakob From paul.hoffman@vpnc.org Tue Jan 10 10:55:13 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C883C21F8616 for ; Tue, 10 Jan 2012 10:55:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nO09I5vtzT7V for ; Tue, 10 Jan 2012 10:55:13 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 449B821F85F8 for ; Tue, 10 Jan 2012 10:55:13 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0AIt8wM023584 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 10 Jan 2012 11:55:08 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Tue, 10 Jan 2012 10:55:07 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> <7A4B9C55-52C3-4A93-9DA7-62F98CF2A6A5@bbn.com> <03EDD353-7C2F-4E2E-911A-117673C94FAF@vpnc.org> <689C663D-4898-4C2D-858C-BE01CA38B666@vpnc.org> To: "Richard L. Barnes" X-Mailer: Apple Mail (2.1251.1) Cc: IETF DANE WG list Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 18:55:13 -0000 Personally, I would like this WG to not to re-open the entire discussion = that led to RFC 6120, including all of the special cases and different = security assumptions and so on. The resulting RFC is dense, confusing in = many places, and much less helpful than any of us expected when the = document started. It was a useful discussion, but mostly to show that = what is "obvious" about host identity to one person is completely wrong = to another. Richard: you have a set of views that seems driven by the model that = XMPP chose. That's great, and I think my current wording completely = covers the XMPP case and does not penalize XMPP at all. You also have a = view about how HTTP and SMTP and ... "should" do it, but your view is = not universally shared; as far as I can tell, no one's is. To me, it is inappropriate to use DANE as a wedge to enforce a = particular view of server identity on any application protocol and to = say "unless you change your protocol, you can't use DANE". If the = protocol developers have not been moved to make changes by the = publication of RFC 6120 (and I believe they have not), trying to exert = pressure via DANE (which is supposed to be useful) is wrong. --Paul Hoffman From stpeter@stpeter.im Tue Jan 10 11:00:23 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 613EC21F85EE for ; Tue, 10 Jan 2012 11:00:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqwl5z+jCMBJ for ; Tue, 10 Jan 2012 11:00:22 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD5321F85DD for ; Tue, 10 Jan 2012 11:00:22 -0800 (PST) Received: from dhcp-64-101-72-124.cisco.com (unknown [64.101.72.124]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2CA8B40058; Tue, 10 Jan 2012 12:09:15 -0700 (MST) Message-ID: <4F0C8ABF.1090807@stpeter.im> Date: Tue, 10 Jan 2012 12:00:15 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Paul Hoffman References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> <7A4B9C55-52C3-4A93-9DA7-62F98CF2A6A5@bbn.com> <03EDD353-7C2F-4E2E-911A-117673C94FAF@vpnc.org> <689C663D-4898-4C2D-858C-BE01CA38B666@vpnc.org> In-Reply-To: X-Enigmail-Version: 1.3.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IETF DANE WG list Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 19:00:23 -0000 On 1/10/12 11:55 AM, Paul Hoffman wrote: > Personally, I would like this WG to not to re-open the entire > discussion that led to RFC 6120, I think you mean RFC 6125. 6120 is the core XMPP spec. 6125 is the "certid" spec. > including all of the special cases > and different security assumptions and so on. The resulting RFC is > dense, confusing in many places, and much less helpful than any of us > expected when the document started. It was a useful discussion, but > mostly to show that what is "obvious" about host identity to one > person is completely wrong to another. Which is why RFC 6125 ended up being so long. What seems simple isn't always so. Peter -- Peter Saint-Andre http://stpeter.im/ From paul.hoffman@vpnc.org Tue Jan 10 11:26:29 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 212CC21F87D8 for ; Tue, 10 Jan 2012 11:26:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sIQHcZRmVNJB for ; Tue, 10 Jan 2012 11:26:28 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9224B21F85E7 for ; Tue, 10 Jan 2012 11:26:28 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0AJQMSi024837 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 10 Jan 2012 12:26:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4F0C8ABF.1090807@stpeter.im> Date: Tue, 10 Jan 2012 11:26:22 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6FA8A8B2-0E5E-4524-9C0D-488C699A926C@vpnc.org> References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> <7A4B9C55-52C3-4A93-9DA7-62F98CF2A6A5@bbn.com> <03EDD353-7C2F-4E2E-911A-117673C94FAF@vpnc.org> <689C663D-4898-4C2D-858C-BE01CA38B666@vpnc.org> <4F0C8ABF.1090807@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1251.1) Cc: IETF DANE WG list Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 19:26:29 -0000 On Jan 10, 2012, at 11:00 AM, Peter Saint-Andre wrote: > On 1/10/12 11:55 AM, Paul Hoffman wrote: >> Personally, I would like this WG to not to re-open the entire >> discussion that led to RFC 6120,=20 >=20 > I think you mean RFC 6125. 6120 is the core XMPP spec. 6125 is the > "certid" spec. Completely correct, yes. We need more diffuse RFC numbers. :-) >> including all of the special cases >> and different security assumptions and so on. The resulting RFC is >> dense, confusing in many places, and much less helpful than any of us >> expected when the document started. It was a useful discussion, but >> mostly to show that what is "obvious" about host identity to one >> person is completely wrong to another. >=20 > Which is why RFC 6125 ended up being so long. What seems simple isn't > always so. In this specific case, RFC 6125 shows both that the topic is not simple = *and* that different application protocol developers want to handle = things differently. --Paul Hoffman From cloos@jhcloos.com Tue Jan 10 13:11:07 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BAEE21F8615 for ; Tue, 10 Jan 2012 13:11:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.828 X-Spam-Level: X-Spam-Status: No, score=-1.828 tagged_above=-999 required=5 tests=[AWL=0.772, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7mO8nSxWwzyW for ; Tue, 10 Jan 2012 13:11:06 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by ietfa.amsl.com (Postfix) with ESMTP id 3F3FE21F860E for ; Tue, 10 Jan 2012 13:11:06 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 01AE15817D; Tue, 10 Jan 2012 21:10:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1326229864; bh=PcWvGp43+TYWaKJYAHTjW7SlBLewUrS7U9X/W8wOUBs=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=yh8eKrv1zZ3RWql9pvOB8CcFQSg50BolwMpxfkycTrVXoGU2zLvcycFbTP9D6KmyU K0YXMhVrUR9RsnHvBa5CGgbtG/HA85Mx+WB+NBfaun+nBzxMdcfDwsuz2POoxWBEf3 DQyL8/gh+z5twduNL5tzpLb3UBmrz08wHhGnJn1A= Received: by carbon.jhcloos.org (Postfix, from userid 500) id E05AA36004C; Tue, 10 Jan 2012 20:56:03 +0000 (UTC) From: James Cloos To: IETF DANE WG list In-Reply-To: <536F7502-9FCA-484B-8771-E0C7BA6BF14A@kirei.se> (Jakob Schlyter's message of "Tue, 10 Jan 2012 19:42:46 +0100") References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> <7A4B9C55-52C3-4A93-9DA7-62F98CF2A6A5@bbn.com> <03EDD353-7C2F-4E2E-911A-117673C94FAF@vpnc.org> <689C663D-4898-4C2D-858C-BE01CA38B666@vpnc.org> <536F7502-9FCA-484B-8771-E0C7BA6BF14A@kirei.se> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.92 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2011 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Tue, 10 Jan 2012 15:56:03 -0500 Message-ID: Lines: 16 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:120110:dane@ietf.org::jrjB+GDRuBD+KUpk:000lXx72 X-Hashcash: 1:30:120110:jakob@kirei.se::LO2fGDKmNiXdUSXk:00ABFlL X-Hashcash: 1:30:120110:rbarnes@bbn.com::fIe30H76YAh9Tvns:0fFNua X-Hashcash: 1:30:120110:paul.hoffman@vpnc.org::Frcq6zq27SHLo7Fm:0000000000000000000000000000000000000002CGvS Cc: Paul Hoffman Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 21:11:07 -0000 >>>>> "JS" == Jakob Schlyter writes: JS> "the domain name that the client thought it was connecting to" could JS> be interpreted as the domain name found at the right hand side of the JS> MX record. For SMTP as deployed today, this makes sense - e.g., MX for JS> kirei.se points to mail.kirei.se, and the TLS cert is CN=mail.kirei.se JS> (not CN=kirei.se or the like). Exactly. And frequently the MX (legitimately) points to a hostname in an entirely different domain. In fact, that may be more common than not. For smtp, the tlsa MUST to be /after/ the MX lookup. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From hallam@gmail.com Tue Jan 10 13:39:48 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8849321F84A3 for ; Tue, 10 Jan 2012 13:39:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XvjWL5lrXej for ; Tue, 10 Jan 2012 13:39:47 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id A1A3521F84A1 for ; Tue, 10 Jan 2012 13:39:47 -0800 (PST) Received: by obcuz6 with SMTP id uz6so45760obc.31 for ; Tue, 10 Jan 2012 13:39:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1kla19vyKy4WN7FZrBDg7ullxqEOrWCM1A6F01puAtY=; b=EO4Merv1pVj2wSg9ckKpB/DP7pL5psBMcAsqXIUr+G6YwOk8fp8nURynNZfYUBLgwm gwJezo3R8sx6k/SCukacfOrgZNUKK0vgNCSMaf+3mCVRXHcbXZJutafD8XYwWgNum7J2 JDR2zYfn7D1UQ/iy1sXhgHcg3HjRgyKQy0Wro= MIME-Version: 1.0 Received: by 10.182.111.69 with SMTP id ig5mr20082372obb.9.1326231587302; Tue, 10 Jan 2012 13:39:47 -0800 (PST) Received: by 10.182.45.134 with HTTP; Tue, 10 Jan 2012 13:39:47 -0800 (PST) In-Reply-To: References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> <7A4B9C55-52C3-4A93-9DA7-62F98CF2A6A5@bbn.com> <03EDD353-7C2F-4E2E-911A-117673C94FAF@vpnc.org> <689C663D-4898-4C2D-858C-BE01CA38B666@vpnc.org> Date: Tue, 10 Jan 2012 16:39:47 -0500 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=14dae9340b2ba6af4904b6335a08 Cc: IETF DANE WG list Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 21:39:48 -0000 --14dae9340b2ba6af4904b6335a08 Content-Type: text/plain; charset=ISO-8859-1 +1 What I think is appropriate is to state where DANE appears in the chain and I think that as currently specified it very obviously binds to a host and not to a service. If someone wanted to use DANE RR to secure an Internet service the prefix should be something like '_http._tcp.' _http._tcp.example.com We definitely need to have a mechanism to allow applications to resolve Internet services instead of the host and port scheme. But that does not mean that hosts and ports should go away any more than DNS made IP addresses obsolete. Whatever service mechanism is eventually decided will eventually resolve to host and port and then IP address and port number which will ultimately be resolved into a sequence of router destination ports. This should not be a choice left to the application, it should be a specified part of the Internet architecture. But the DANE group is definitely not the place to design that mechanism and nor is DNSEXT. On Tue, Jan 10, 2012 at 1:55 PM, Paul Hoffman wrote: > Personally, I would like this WG to not to re-open the entire discussion > that led to RFC 6120, including all of the special cases and different > security assumptions and so on. The resulting RFC is dense, confusing in > many places, and much less helpful than any of us expected when the > document started. It was a useful discussion, but mostly to show that what > is "obvious" about host identity to one person is completely wrong to > another. > > Richard: you have a set of views that seems driven by the model that XMPP > chose. That's great, and I think my current wording completely covers the > XMPP case and does not penalize XMPP at all. You also have a view about how > HTTP and SMTP and ... "should" do it, but your view is not universally > shared; as far as I can tell, no one's is. > > To me, it is inappropriate to use DANE as a wedge to enforce a particular > view of server identity on any application protocol and to say "unless you > change your protocol, you can't use DANE". If the protocol developers have > not been moved to make changes by the publication of RFC 6120 (and I > believe they have not), trying to exert pressure via DANE (which is > supposed to be useful) is wrong. > > --Paul Hoffman > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > -- Website: http://hallambaker.com/ --14dae9340b2ba6af4904b6335a08 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1

What I think is appropriate is to state where DANE ap= pears in the chain and I think that as currently specified it very obviousl= y binds to a host and not to a service.

If someone= wanted to use DANE RR to secure an Internet service the prefix should be s= omething like '_http._tcp.'



We definitely need to have a= mechanism to allow applications to resolve Internet services instead of th= e host and port scheme. But that does not mean that hosts and ports should = go away any more than DNS made IP addresses obsolete.

Whatever service mechanism is eventually decided will e= ventually resolve to host and port and then IP address and port number whic= h will ultimately be resolved into a sequence of router destination ports.<= /div>

This should not be a choice left to the application, it= should be a specified part of the Internet architecture. But the DANE grou= p is definitely not the place to design that mechanism and nor is DNSEXT.


On Tue, Jan 10, 2012 at 1= :55 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
Personally, I would like this WG to not to re-open the entire discussion th= at led to RFC 6120, including all of the special cases and different securi= ty assumptions and so on. The resulting RFC is dense, confusing in many pla= ces, and much less helpful than any of us expected when the document starte= d. It was a useful discussion, but mostly to show that what is "obviou= s" about host identity to one person is completely wrong to another.
Richard: you have a set of views that seems driven by the model that XMPP c= hose. That's great, and I think my current wording completely covers th= e XMPP case and does not penalize XMPP at all. You also have a view about h= ow HTTP and SMTP and ... "should" do it, but your view is not uni= versally shared; as far as I can tell, no one's is.

To me, it is inappropriate to use DANE as a wedge to enforce a particular v= iew of server identity on any application protocol and to say "unless = you change your protocol, you can't use DANE". If the protocol dev= elopers have not been moved to make changes by the publication of RFC 6120 = (and I believe they have not), trying to exert pressure via DANE (which is = supposed to be useful) is wrong.

--Paul Hoffman

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



--
= Website: http://hallambaker.com/
--14dae9340b2ba6af4904b6335a08-- From mrex@sap.com Tue Jan 10 17:31:05 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6381121F8655 for ; Tue, 10 Jan 2012 17:31:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.78 X-Spam-Level: X-Spam-Status: No, score=-9.78 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSXnH9oW+kSJ for ; Tue, 10 Jan 2012 17:31:04 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 25D6C21F864B for ; Tue, 10 Jan 2012 17:31:03 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q0B1V1M5026232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Jan 2012 02:31:01 +0100 (MET) From: Martin Rex Message-Id: <201201110131.q0B1V1Xu022258@fs4113.wdf.sap.corp> To: paul.hoffman@vpnc.org (Paul Hoffman) Date: Wed, 11 Jan 2012 02:31:01 +0100 (MET) In-Reply-To: <689C663D-4898-4C2D-858C-BE01CA38B666@vpnc.org> from "Paul Hoffman" at Jan 10, 12 07:43:23 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 01:31:05 -0000 Paul Hoffman wrote: > > There is no problem for SMTP, but there is one for XMPP. > > The problem is that XMPP specifies that the identity in the TLS > server's certificate must be that of the *beginning* of the chain, > not of the server itself. You got this backwards. SMTP server-to-server authentication security is fubar (beyond repair), whereas the XMPP scheme described in rfc6125, to require the server to present a certificate for the domain it is *SERVING*, rather than for the hostname of the server where the service is running on is the sensible and secure approach. > > This allows XMPP to have insecure redirections through SRV; as along as > the client ends up at the correct server, even insecurely, TLS will bind > the server to the original identity. Correct. The insecurity of the DNS SRV lookup is supposed to not impair the authentication of the XMPP *service* to the user. Authenticating the particular server hostname on which the admin has installed a particular instance of a service is a bad idea in absence of a secure directory or secure naming service. > > SMTP (and probably other protocols) don't try to make this binding. SMTP-AUTH between servers is de-facto an optional optimistic anonymous encryption. > > More accurate wording for the last sentence would be: > > If TLSA is used with an application protocol such as XMPP that uses > redirection to find a server and requires that the TLS server's identity > match a host earlier in the redirection chain, TLSA can only be used > if every step of the redirection chain is protected by DNSSEC and > processing stops for any step where the response is not secure. Again, this is backwards. XMPP redirection is safe with insecure SRV records. SMTP-AUTH with MX redirection is always insecure and defining the additional DNSSEC validations that would have to be performed to make those MX indirections trustworthy is non-trivial. Reason why server-to-server SMTP-AUTH is a security disaster: - necessity to fallback to SMTP without TLS for millions of domains - unavailability of STARTTLS for many large (Fre)email providers (@hotmail.com, @live.com, @gmx.de, @web.de) - use of TLS server certs with hostnames that are completely unrelated to the actual mail domain that is serviced (e.g. @gmail.com: gmail.com IN MX 5 gmail-smtp-in.l.google.com) The lack of support for virtual hosting in the base SSLv3 and TLS protocol is probably one of the reasons why SMTP-AUTH got it wrong and why so few sites on the internet are configured for HTTPS access. -Martin From paul.hoffman@vpnc.org Tue Jan 10 17:48:19 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 586F311E80C2 for ; Tue, 10 Jan 2012 17:48:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xn9GDURDHy6q for ; Tue, 10 Jan 2012 17:48:19 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id DCD5111E80BD for ; Tue, 10 Jan 2012 17:48:18 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0B1mH7T061122 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 10 Jan 2012 18:48:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Paul Hoffman In-Reply-To: <201201110131.q0B1V1Xu022258@fs4113.wdf.sap.corp> Date: Tue, 10 Jan 2012 17:48:17 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201201110131.q0B1V1Xu022258@fs4113.wdf.sap.corp> To: IETF DANE WG list X-Mailer: Apple Mail (2.1251.1) Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 01:48:19 -0000 On Jan 10, 2012, at 5:31 PM, Martin Rex wrote: >> If TLSA is used with an application protocol such as XMPP that uses >> redirection to find a server and requires that the TLS server's = identity >> match a host earlier in the redirection chain, TLSA can only be used >> if every step of the redirection chain is protected by DNSSEC and >> processing stops for any step where the response is not secure. >=20 > Again, this is backwards. >=20 > XMPP redirection is safe with insecure SRV records. ...in the current XMPP model. Note that the sentence above starts "If = TLSA is used with...". XMPP assumes a certificate that chains to a trust = anchor who will do the identification. TLSA breaks that model: the DANE = certificate association might be to a type 2 certificate, which would = open an attack on XMPP if the redirection chain is not fully protected. = Agree? --Paul Hoffman From rbarnes@bbn.com Tue Jan 10 18:44:29 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3037F21F8483 for ; Tue, 10 Jan 2012 18:44:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ho6yXDqHverz for ; Tue, 10 Jan 2012 18:44:28 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 894E121F8480 for ; Tue, 10 Jan 2012 18:44:28 -0800 (PST) Received: from [128.89.255.135] (port=49761 helo=[192.168.1.3]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RkoAt-000A74-Ev; Tue, 10 Jan 2012 21:44:27 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Richard L. Barnes In-Reply-To: Date: Tue, 10 Jan 2012 21:44:26 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> <7A4B9C55-52C3-4A93-9DA7-62F98CF2A6A5@bbn.com> <03EDD353-7C2F-4E2E-911A-117673C94FAF@vpnc.org> <689C663D-4898-4C2D-858C-BE01CA38B666@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1084) Cc: IETF DANE WG list Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 02:44:29 -0000 After talking with Paul offline, I've come to realize that where we = differ is basically with regard to how we regard the risk of DNS = spoofing. =20 The state of the art in SMTP and HTTP seems to be to follow CNAMEs and = MXs and allow matching against the target domains, which makes = deployment simpler, but leaves clients vulnerable to DNS poisoning = against those records. If a DANE client follows this pattern (looking = up records based on target), it doesn't face any *new* risks, but the = old spoofing risk persists. The state of the art in XMPP is to regard SRVs as untrustworthy and = require matching against the source domains, which makes deployment more = challenging but protects against DNS poisoning. If a DANE client = follows this pattern (looking up records based on source or = DNSSEC-protected target), then it has no spoofing risk. All of which brings me back to my original point -- let the application = decide. HTTP and SMTP entities can use the target name for = TLSA/matching, and XMPP entities can use the source name. Let each = application use the name it's trying to authenticate My latest = suggested text actually says pretty much that, except for the last = paragraph, which I'm willing to compromise on in light of the above.=20 Revised proposed text, with the MUSTs softened to SHOULD/RECOMMENDED and = the second paragraph changed to be more of a cautionary note: " A TLSA record is used to make an association between a certificate and a = (domain name, transport protocol, port number) triple where a TLS = service may exist. =20 Applications using TLSA need to choose carefully which domain names they = use to locate TLSA records, since these domains are trusted to provide = certificate association information; obtaining TLSA information from the = wrong source can lead to clients accepting bogus certificates. = Applications that are seeking to authenticate a specific domain name = SHOULD use that name to locate TLSA records. For example:=20 o An HTTPS client connecting to an HTTP URI would use the name in the = URI [RFC2818] o An SMTP client connecting to an SMTP server would use the name for = the mail domain it is seeking to reach [RFC3207] o An XMPP server connecting to another XMPP server would use the 'to' = address in the initial stream header [RFC6120] In some cases, the name that an application seeks to authenticate is = obtained by the client via a chain of DNS redirection records (e.g., MX, = SRV, NAPTR). When this is the case, it should be noted that if these = redirection records are not protected with DNSSEC, then face the risk = that a spoofed redirection record will cause them to accept bogus = certificates. Thus, if applications encounter redirection chains in = which one or more records are not DNSSEC-protected, then it is = RECOMMENDED that the application locate TLSA records only using the = source domain or target domains of DNSSEC-protected records.=20 " On Jan 10, 2012, at 1:55 PM, Paul Hoffman wrote: > Personally, I would like this WG to not to re-open the entire = discussion that led to RFC 6120, including all of the special cases and = different security assumptions and so on. The resulting RFC is dense, = confusing in many places, and much less helpful than any of us expected = when the document started. It was a useful discussion, but mostly to = show that what is "obvious" about host identity to one person is = completely wrong to another. >=20 > Richard: you have a set of views that seems driven by the model that = XMPP chose. That's great, and I think my current wording completely = covers the XMPP case and does not penalize XMPP at all. You also have a = view about how HTTP and SMTP and ... "should" do it, but your view is = not universally shared; as far as I can tell, no one's is. >=20 > To me, it is inappropriate to use DANE as a wedge to enforce a = particular view of server identity on any application protocol and to = say "unless you change your protocol, you can't use DANE". If the = protocol developers have not been moved to make changes by the = publication of RFC 6120 (and I believe they have not), trying to exert = pressure via DANE (which is supposed to be useful) is wrong. >=20 > --Paul Hoffman >=20 From mrex@sap.com Tue Jan 10 18:50:45 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5448C21F84FD for ; Tue, 10 Jan 2012 18:50:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.951 X-Spam-Level: X-Spam-Status: No, score=-9.951 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9vZngrMlKzI for ; Tue, 10 Jan 2012 18:50:44 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8F70521F84F1 for ; Tue, 10 Jan 2012 18:50:44 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q0B2ogEI015840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Jan 2012 03:50:42 +0100 (MET) From: Martin Rex Message-Id: <201201110250.q0B2ofwJ026718@fs4113.wdf.sap.corp> To: paul.hoffman@vpnc.org (Paul Hoffman) Date: Wed, 11 Jan 2012 03:50:41 +0100 (MET) In-Reply-To: from "Paul Hoffman" at Jan 10, 12 05:48:17 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 02:50:45 -0000 Paul Hoffman wrote: > > On Jan 10, 2012, at 5:31 PM, Martin Rex wrote: > > > >> If TLSA is used with an application protocol such as XMPP that uses > >> redirection to find a server and requires that the TLS server's identity > >> match a host earlier in the redirection chain, TLSA can only be used > >> if every step of the redirection chain is protected by DNSSEC and > >> processing stops for any step where the response is not secure. > > > > Again, this is backwards. > > > > XMPP redirection is safe with insecure SRV records. > > ...in the current XMPP model. Note that the sentence above starts > "If TLSA is used with...". XMPP assumes a certificate that chains > to a trust anchor who will do the identification. > TLSA breaks that model: the DANE certificate association might be > to a type 2 certificate, which would open an attack on XMPP if the > redirection chain is not fully protected. Agree? No, I believe the type (0,1,2) does not matter here. What we need to authenticate is the "Service" rather than the "Server Hostname" (where that service happens to run on at the moment). For use with SRV records, we might have to make the TLSA record match the left part of the SRV record (with the symbolic service name), rather than the right part (with the numeric port number), in order to provide a secure association for service names through DANE(TLSA) for services/protocols that use DNS SRV to locate where exactly (XMPP) service instances can be reached. -Martin From mrex@sap.com Tue Jan 10 19:30:09 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5871121F855E for ; Tue, 10 Jan 2012 19:30:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.974 X-Spam-Level: X-Spam-Status: No, score=-9.974 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4MNajAi5EZSV for ; Tue, 10 Jan 2012 19:30:08 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4AF21F854B for ; Tue, 10 Jan 2012 19:30:08 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q0B3TxMk016307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Jan 2012 04:30:00 +0100 (MET) From: Martin Rex Message-Id: <201201110329.q0B3Tx2j029031@fs4113.wdf.sap.corp> To: rbarnes@bbn.com (Richard L.Barnes) Date: Wed, 11 Jan 2012 04:29:59 +0100 (MET) In-Reply-To: from "Richard L.Barnes" at Jan 10, 12 09:44:26 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: paul.hoffman@vpnc.org, dane@ietf.org Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 03:30:09 -0000 Your message looks inconsistent to me. Richard L.Barnes wrote: > > The state of the art in SMTP and HTTP seems to be to follow CNAMEs > and MXs and allow matching against the target domains, which makes > deployment simpler, but leaves clients vulnerable to DNS poisoning > against those records. Correct and fairly useless practice in SMTP-AUTH (about MX) Incorrect for HTTP(S) (about CNAME). > > o An HTTPS client connecting to an HTTP URI would use the name > in the URI [RFC2818] Correct for HTTP(S). Example: ;; QUESTION SECTION: ;www.google.com. IN A ;; ANSWER SECTION: www.google.com. 604800 IN CNAME www.l.google.com. www.l.google.com. 300 IN A 173.194.69.103 www.l.google.com. 300 IN A 173.194.69.99 www.l.google.com. 300 IN A 173.194.69.147 www.l.google.com. 300 IN A 173.194.69.105 www.l.google.com. 300 IN A 173.194.69.104 www.l.google.com. 300 IN A 173.194.69.106 Traditional HTTP(S) clients will be matching the URL "http://www.google.com" to the Server certificate containing "www.google.com", and ignore (and maybe not even notice) the CNAME indirection within DNS: www.google.com --> www.l.google.com -Martin From jakob@kirei.se Tue Jan 10 22:52:59 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 706A121F8693 for ; Tue, 10 Jan 2012 22:52:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tacrk8K2NEbg for ; Tue, 10 Jan 2012 22:52:58 -0800 (PST) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id C90AC21F8531 for ; Tue, 10 Jan 2012 22:52:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=zaLBypZ8e18715PcI1WBUJpAs96fReIOLsj7rdUUhaw=; b=aqrCgEkvHQokQTWbgpn5Dj4ALAfkoBoYPnVq1SBMEmUziudgwxmICeFklvcrpZHGXTiHvneTOJprS efyu64JDYr17QrJOunoscYlN3Pu3zBATvkThjXJWzLUNnDLWeXDpCpvsyOEwoMKPAOxuRqwZXYfCW1 e3X8kruc8aE4lr+U= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Wed, 11 Jan 2012 07:52:54 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: Date: Wed, 11 Jan 2012 07:52:52 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7FF9DCF4-01D7-42FA-9077-051D42B87988@kirei.se> References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> <7A4B9C55-52C3-4A93-9DA7-62F98CF2A6A5@bbn.com> <03EDD353-7C2F-4E2E-911A-117673C94FAF@vpnc.org> <689C663D-4898-4C2D-858C-BE01CA38B666@vpnc.org> To: Richard L. Barnes X-Mailer: Apple Mail (2.1251.1) Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 06:52:59 -0000 On 11 jan 2012, at 03:44, Richard L. Barnes wrote: > The state of the art in SMTP and HTTP seems to be to follow CNAMEs and = MXs and allow matching against the target domains, which makes = deployment simpler, but leaves clients vulnerable to DNS poisoning = against those records. If a DANE client follows this pattern (looking = up records based on target), it doesn't face any *new* risks, but the = old spoofing risk persists. I suggest we remove the CNAME example, since (as Martin Rex pointed out) = is wrong. > o An HTTPS client connecting to an HTTP URI would use the name in the = URI [RFC2818] This, on the other hand, is true (as it does not mention CNAME). > o An SMTP client connecting to an SMTP server would use the name for = the mail domain it is seeking to reach [RFC3207] Writing "An SMTP client connecting to an SMTP server would use the = domain name for the SMTP server it is seeking to reach [RFC3207]" would = be better IMHO. jakob From jakob@kirei.se Tue Jan 10 22:52:59 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7010821F8673 for ; Tue, 10 Jan 2012 22:52:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-JxZhtZmtFn for ; Tue, 10 Jan 2012 22:52:58 -0800 (PST) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id C913F21F865E for ; Tue, 10 Jan 2012 22:52:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=l/i1knHuIotSkuyKK+OHqjV6COQLJlpwQjblQ1xEQE8=; b=uXs2M+yglvGI8PUVunNG6LFaYD1Ky73W8aBgwU8o/+1vrqBonfWUlTAYXPHrMHGXgY+CNkwpB0bgQ 1n6W4grzEI0Sbm7IYgRcvItWU19pgQA9HDg51UxzmGBBmXYZ3lmq+AAHabzcbmE8f2y5Umt2Rm+tt9 ULHJNYpoc9hVdrJQ= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Wed, 11 Jan 2012 07:52:55 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Jakob Schlyter In-Reply-To: Date: Wed, 11 Jan 2012 07:52:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <204EA36F-BF4F-40BF-8A21-307801C2A47B@kirei.se> References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> <7A4B9C55-52C3-4A93-9DA7-62F98CF2A6A5@bbn.com> <03EDD353-7C2F-4E2E-911A-117673C94FAF@vpnc.org> <689C663D-4898-4C2D-858C-BE01CA38B666@vpnc.org> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1251.1) Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 06:52:59 -0000 On 10 jan 2012, at 22:39, Phillip Hallam-Baker wrote: > What I think is appropriate is to state where DANE appears in the = chain and I think that as currently specified it very obviously binds to = a host and not to a service. Actually, because the TLSA record appears together with a port number = and transport using it with a service name would never make sense, as = part of the TLSA domain name (port/transport) is found via a mapping = function such as SRV/NAPTR. If one would argue for looking up a service name using TLSA, one has to = first look up possible ports/transports using SRV/NAPTR, then combine = these host specific attributes with the service name. The TLSA domain = name to look up would be a strange mess between service properties (the = name) and server properties (port/transport). > If someone wanted to use DANE RR to secure an Internet service the = prefix should be something like '_http._tcp.' >=20 > _http._tcp.example.com Yes, and looking up TLSA using a service would be another draft. jakob From oej@edvina.net Wed Jan 11 00:03:51 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9824D21F8846 for ; Wed, 11 Jan 2012 00:03:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.803 X-Spam-Level: X-Spam-Status: No, score=-1.803 tagged_above=-999 required=5 tests=[AWL=0.796, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xHDM+j+dpti for ; Wed, 11 Jan 2012 00:03:51 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 4E22C21F8851 for ; Wed, 11 Jan 2012 00:03:40 -0800 (PST) Received: from [192.168.40.4] (unknown [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 65F93754A8A2; Wed, 11 Jan 2012 08:03:37 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: "Olle E. Johansson" In-Reply-To: Date: Wed, 11 Jan 2012 09:03:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> <7A4B9C55-52C3-4A93-9DA7-62F98CF2A6A5@bbn.com> <03EDD353-7C2F-4E2E-911A-117673C94FAF@vpnc.org> <689C663D-4898-4C2D-858C-BE01CA38B666@vpnc.org> To: Richard L. Barnes X-Mailer: Apple Mail (2.1251.1) Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 08:03:51 -0000 11 jan 2012 kl. 03:44 skrev Richard L. Barnes: > " > A TLSA record is used to make an association between a certificate and = a (domain name, transport protocol, port number) triple where a TLS = service may exist. =20 >=20 > Applications using TLSA need to choose carefully which domain names = they use to locate TLSA records, since these domains are trusted to = provide certificate association information; obtaining TLSA information = from the wrong source can lead to clients accepting bogus certificates. = Applications that are seeking to authenticate a specific domain name = SHOULD use that name to locate TLSA records. For example:=20 > o An HTTPS client connecting to an HTTP URI would use the name in the = URI [RFC2818] > o An SMTP client connecting to an SMTP server would use the name for = the mail domain it is seeking to reach [RFC3207] > o An XMPP server connecting to another XMPP server would use the 'to' = address in the initial stream header [RFC6120] >=20 > In some cases, the name that an application seeks to authenticate is = obtained by the client via a chain of DNS redirection records (e.g., MX, = SRV, NAPTR). When this is the case, it should be noted that if these = redirection records are not protected with DNSSEC, then face the risk = that a spoofed redirection record will cause them to accept bogus = certificates. Thus, if applications encounter redirection chains in = which one or more records are not DNSSEC-protected, then it is = RECOMMENDED that the application locate TLSA records only using the = source domain or target domains of DNSSEC-protected records.=20 > " >=20 In SIP, there's an RFC on how to match a certificate with a SIP URI.=20 http://tools.ietf.org/html/rfc5922 Basically we match the target SIP uri domain with=20 a) the subject ALT NAMEs b) if no subject alt names exist, the subject We do not match the SRV records name with the certificate. Just FYI.=20 /O= From oej@edvina.net Wed Jan 11 00:10:16 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE7821F8772 for ; Wed, 11 Jan 2012 00:10:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[AWL=0.398, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wR5hL8xeL1ap for ; Wed, 11 Jan 2012 00:10:16 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id AC0BF21F8763 for ; Wed, 11 Jan 2012 00:10:09 -0800 (PST) Received: from [192.168.40.4] (unknown [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 289FC754A8CC; Wed, 11 Jan 2012 08:10:09 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: "Olle E. Johansson" In-Reply-To: Date: Wed, 11 Jan 2012 09:10:09 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> <7A4B9C55-52C3-4A93-9DA7-62F98CF2A6A5@bbn.com> <03EDD353-7C2F-4E2E-911A-117673C94FAF@vpnc.org> <689C663D-4898-4C2D-858C-BE01CA38B666@vpnc.org> To: Richard L. Barnes X-Mailer: Apple Mail (2.1251.1) Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 08:10:17 -0000 11 jan 2012 kl. 09:03 skrev Olle E. Johansson: >=20 > 11 jan 2012 kl. 03:44 skrev Richard L. Barnes: >=20 >> " >> A TLSA record is used to make an association between a certificate = and a (domain name, transport protocol, port number) triple where a TLS = service may exist. =20 >>=20 >> Applications using TLSA need to choose carefully which domain names = they use to locate TLSA records, since these domains are trusted to = provide certificate association information; obtaining TLSA information = from the wrong source can lead to clients accepting bogus certificates. = Applications that are seeking to authenticate a specific domain name = SHOULD use that name to locate TLSA records. For example:=20 >> o An HTTPS client connecting to an HTTP URI would use the name in the = URI [RFC2818] >> o An SMTP client connecting to an SMTP server would use the name for = the mail domain it is seeking to reach [RFC3207] >> o An XMPP server connecting to another XMPP server would use the 'to' = address in the initial stream header [RFC6120] >>=20 >> In some cases, the name that an application seeks to authenticate is = obtained by the client via a chain of DNS redirection records (e.g., MX, = SRV, NAPTR). When this is the case, it should be noted that if these = redirection records are not protected with DNSSEC, then face the risk = that a spoofed redirection record will cause them to accept bogus = certificates. Thus, if applications encounter redirection chains in = which one or more records are not DNSSEC-protected, then it is = RECOMMENDED that the application locate TLSA records only using the = source domain or target domains of DNSSEC-protected records.=20 >> " >>=20 >=20 > In SIP, there's an RFC on how to match a certificate with a SIP URI.=20= > http://tools.ietf.org/html/rfc5922 >=20 > Basically we match the target SIP uri domain with=20 > a) the subject ALT NAMEs > b) if no subject alt names exist, the subject >=20 > We do not match the SRV records name with the certificate. To comment my own posting :-) The RFC adds a preference for matching SA URI records, not host names. /O= From ogud@ogud.com Wed Jan 11 06:56:51 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A714221F860F for ; Wed, 11 Jan 2012 06:56:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7tMGdz+iJlj for ; Wed, 11 Jan 2012 06:56:50 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 708DA21F8559 for ; Wed, 11 Jan 2012 06:56:50 -0800 (PST) Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id q0BEulQ9034814 for ; Wed, 11 Jan 2012 09:56:48 -0500 (EST) (envelope-from ogud@ogud.com) Message-ID: <4F0DA32D.7070206@ogud.com> Date: Wed, 11 Jan 2012 09:56:45 -0500 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: dane@ietf.org References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> <7A4B9C55-52C3-4A93-9DA7-62F98CF2A6A5@bbn.com> <03EDD353-7C2F-4E2E-911A-117673C94FAF@vpnc.org> <689C663D-4898-4C2D-858C-BE01CA38B666@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 14:56:51 -0000 On 10/01/2012 21:44, Richard L. Barnes wrote: > After talking with Paul offline, I've come to realize that where we differ is basically with regard to how we regard the risk of DNS spoofing. > > The state of the art in SMTP and HTTP seems to be to follow CNAMEs and MXs and allow matching against the target domains, which makes deployment simpler, but leaves clients vulnerable to DNS poisoning against those records. If a DANE client follows this pattern (looking up records based on target), it doesn't face any *new* risks, but the old spoofing risk persists. > > The state of the art in XMPP is to regard SRVs as untrustworthy and require matching against the source domains, which makes deployment more challenging but protects against DNS poisoning. If a DANE client follows this pattern (looking up records based on source or DNSSEC-protected target), then it has no spoofing risk. > > All of which brings me back to my original point -- let the application decide. HTTP and SMTP entities can use the target name for TLSA/matching, and XMPP entities can use the source name. Let each application use the name it's trying to authenticate My latest suggested text actually says pretty much that, except for the last paragraph, which I'm willing to compromise on in light of the above. > > Revised proposed text, with the MUSTs softened to SHOULD/RECOMMENDED and the second paragraph changed to be more of a cautionary note: > " > A TLSA record is used to make an association between a certificate and a (domain name, transport protocol, port number) triple where a TLS service may exist. > > Applications using TLSA need to choose carefully which domain names they use to locate TLSA records, since these domains are trusted to provide certificate association information; obtaining TLSA information from the wrong source can lead to clients accepting bogus certificates. Applications that are seeking to authenticate a specific domain name SHOULD use that name to locate TLSA records. For example: > o An HTTPS client connecting to an HTTP URI would use the name in the URI [RFC2818] > o An SMTP client connecting to an SMTP server would use the name for the mail domain it is seeking to reach [RFC3207] > o An XMPP server connecting to another XMPP server would use the 'to' address in the initial stream header [RFC6120] > > In some cases, the name that an application seeks to authenticate is obtained by the client via a chain of DNS redirection records (e.g., MX, SRV, NAPTR). When this is the case, it should be noted that if these redirection records are not protected with DNSSEC, then face the risk that a spoofed redirection record will cause them to accept bogus certificates. Thus, if applications encounter redirection chains in which one or more records are not DNSSEC-protected, then it is RECOMMENDED that the application locate TLSA records only using the source domain or target domains of DNSSEC-protected records. > " > Richard, My first reaction in reading you posts was that you are off the deep end. After going through the latest draft and your suggested text I think you have exposed an underspecification in the draft that needs to be addressed. Your text does not address the underlying problem. Using the example in the tix: http://trac.tools.ietf.org/wg/dane/trac/ticket/28 In case a) _port._tcp._jabber._tcp.jabber.alice.com IN TLSA the zone with the SRV record and TLSA is MUST be signed thus no spoofing possible, if the DNS tree and record validate. In case b) _xmpp-client._tcp.jabber.alice.com IN SRV 5 0 5222 jabber.bob.com. The target zone (bob.com) MUST be signed or the DANE client will NOT accept the TLSA record from it. The question is is the zone with the SRV/URI/??? record (alice.com) signed, the current draft is silent on that. Case c) is from DNS consistency point is the same as a). In reading the document it DOES NOT say that records used to navigate to the TLSA RRset MUST also be validated. This causes inconsistency as depending on the DNS traversal to the TLSA record. If the traversal is via NS/CNAME/DNAME records the TLSA RRset will only be marked as validated if all links in the navigation chain validate. In the case of MX/SRV/NAPTR records there are multiple queries involved, and naive TLSA implementation may say "I got validated TLSA that is good enough for me", opening up the spoofing hole that Richard worries about. My proposal is to add text that explicitly covers records in the DNS traversal and specify that any record that "points" to the TLSA RRset MUST also be validated. Olafur From suresh@tislabs.com Wed Jan 11 09:04:10 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABC5C21F887A for ; Wed, 11 Jan 2012 09:04:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmsqPOP6xuyv for ; Wed, 11 Jan 2012 09:04:10 -0800 (PST) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) by ietfa.amsl.com (Postfix) with ESMTP id C27E621F886F for ; Wed, 11 Jan 2012 09:04:09 -0800 (PST) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 5599228B003A; Wed, 11 Jan 2012 12:04:09 -0500 (EST) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 3F1F81F8032; Wed, 11 Jan 2012 12:04:09 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Suresh Krishnaswamy In-Reply-To: <68E91C69-A7DB-40BE-BA60-DCDBA1F8EB28@kirei.se> Date: Wed, 11 Jan 2012 12:04:09 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7645ADDE-1976-4F21-AB12-05DC40D425DC@tislabs.com> References: <20120104081557.23741.87139.idtracker@ietfa.amsl.com> <68E91C69-A7DB-40BE-BA60-DCDBA1F8EB28@kirei.se> To: Jakob Schlyter X-Mailer: Apple Mail (2.1084) Cc: IETF DANE WG list Subject: Re: [dane] I-D Action: draft-ietf-dane-protocol-14.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 17:04:10 -0000 On Jan 4, 2012, at 3:22 AM, Jakob Schlyter wrote: > On 4 jan 2012, at 09:15, internet-drafts@ietf.org wrote: >=20 >> 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. >>=20 >> Title : Using Secure DNS to Associate Certificates = with Domain Names For TLS >> Author(s) : Paul Hoffman >> Jakob Schlyter >> Filename : draft-ietf-dane-protocol-14.txt >> Pages : 24 >> Date : 2012-01-04 >=20 > -14 (aka "the happy new year release") includes the following changes: >=20 > - clarification on DNSSEC validation requirements > - first cut at integrating new text on "Creating TLSA Records" from = Ond=C5=99ej Mikle > - revised pseudo code (please check this carefully!) >=20 >=20 Section 1, 3rd para starting "[DANEUSECASES] also lists many = requirements, most of which ... "=20 - Why "most of", and not "all of"?=20 Section 4.4, 2nd para starting "The TLS session that is to be set = up....". - We should give specific guidance to application developers that states = that TLSA records MUST NOT be cached by *applications* beyond the TTL = (RRSIG expiration?) of the TLSA resource record set. Section 4.4, 6th para starting "If an application receives ...." - Although we say in a preceeding bullet item that "if the DNSSEC = validation state on the response to the request for the TLSA RRset is = bogus, this MUST cause TLS not to be started..", I think we should also = say what an application must do if it could not validate the = non-existence of TLSA records. That is, suppose we receive zero usable = certificate associations, but no proof to assert non-existence we should = fail-close. Section 4.4, 7th para starting "Clients that validate the DNSSEC = signatures ..." - I'm a bit uneasy over the suggestion that it is okay for an = intermediary resolver to be able to introduce new certificates to the = client as long as the client communicates with it over a secure channel. = I'm probably okay with usage types 0 and 1 being used at the client side = when validation is not performed locally, but I'd really want a way (at = the client side) to be able to disable usage type 2 in certain = environments. If nothing else, I think we need to say something about = this in the security considerations section. Section 5, 2nd para: - I agree with the the observation that "some of these might be = excessively glib". Should we make this a little more clear? For folks = coming fresh to this section perhaps saying how the requirements are met = would help. For instance: Multiple Ports: The TLSA records for different application services = running on a single host can be distinguished through the service name = and port number prefixed to the host name (see section 3). No Downgrade: Section 4.4 specifies the conditions under which a client = can process and act upon TLSA records. Specifically, if the DNSSEC = status for the TLSA resource record set is determined to be bogus, TLS = is not attempted at all.=20 Encapsulation: ?? Predicatability: The (non-normative) appendix sections provide = operational considerations and implementation guidance in order to = enable application developers to form a consistent interpretation of the = recommended DANE client behavior.=20 Opportunistic Security: If a client conformant to this specification can = reliably determine the presence of a TLSA record, it will attempt to use = this information. Conversely, if a client can reliably determine the = absence of any TLSA record, it will fallback to processing TLS in the = normal fashion. This is discussed in section 4.4. Combination: Multiple TLSA records can be published for a given host = name, thus enabling the client to construct multiple TLSA certificate = associations that reflect different DANE assertions. [No support is = provided to combine two TLSA certificate associations in a single = operation].=20 Roll-over: Section 4.4 states {SK: subject to my note above} that = applications must not cache TLSA records beyond their TTL expiration. = This ensures that clients will not latch on to assertions made by older = TLSA records, and will be able to transition between using one DANE = mechanism to another. Simple Key Management: The SubjectPublicKeyInfo selector in the TLSA = record provides a mode that enables a domain holder to only have to = maintain a single long-lived public/private key, without the need to = manage certificates. Section A.1.2.2 outlines the usefulness and the = potential downsides to using this mode. Minimal Dependencies: This TLSA specification relies on DNSSEC to = protect the origin authenticity and integrity of the TLSA resource = record set. Additionally if DNSSEC validation is not performed on the = system that wishes to use TLSA certificate bindings, this specification = requires that the "last mile" be over some secure transport. There are = no other deployment dependencies for this approach. Minimal Options: The operating modes map precisely to the DANE use cases = and requirements. DNSSEC use is mandatory in that this specification = encourages applications to use TLSA records that are only shown to be = validated. {SK: In section 8 we say that "client treatment of any = information included in the trust anchor is a matter of local policy". = What configuration knobs do we foresee?} Wildcards: [covered in a limited manner in the TLSA request syntax; see = Appendix A.] Redirection: [covered in the TLSA request syntax; see Appendix A.] Section 8. - See my point above on using cert usage type 2 when validation is not = done locally. - I think we do need to say something related to cert usage 2 and its = removal of dependencies on the PKI infrastructure. That is, in cases = where the CA was following good (ideal?) practices but the DNS = administrator was not, an attacker who is able to compromise the DNS = name server will not only be able to take you to a different machine = that claims to be the webserver, but will also give you a TLS connection = that you (or your application) will believe. =20 B.2 Pseudo code - For consistency, we should probably use {R.matchingType, = R.selectorType, R.cert} - All calls to Match() should probably specify R.cert as the last = parameter Suresh From peter.sylvester@edelweb.fr Wed Jan 11 10:00:26 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E32B721F85E1 for ; Wed, 11 Jan 2012 10:00:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1RYvsS3o9Rh for ; Wed, 11 Jan 2012 10:00:26 -0800 (PST) Received: from mx1.on-x.com (mx1.on-x.com [92.103.215.13]) by ietfa.amsl.com (Postfix) with ESMTP id ED94F21F8606 for ; Wed, 11 Jan 2012 10:00:25 -0800 (PST) Received: from varuna.puteaux.on-x (varuna.puteaux.on-x [192.168.10.6]) by mx1.on-x.com (Postfix) with ESMTP id 850947ED9 for ; Wed, 11 Jan 2012 19:00:24 +0100 (CET) Received: from smtps.on-x.com (mintaka.puteaux.on-x [192.168.14.11]) by varuna.puteaux.on-x (Postfix) with ESMTP id 85AC872F8C6 for ; Wed, 11 Jan 2012 18:31:07 +0100 (CET) Received: from [192.168.18.180] (unknown [192.168.18.180]) by smtps.on-x.com (Postfix) with ESMTPSA id 7732523634F for ; Wed, 11 Jan 2012 12:59:55 -0500 (EST) Message-ID: <4F0DCE51.5090705@edelweb.fr> Date: Wed, 11 Jan 2012 19:00:49 +0100 From: Peter Sylvester User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: dane@ietf.org References: <20120104081557.23741.87139.idtracker@ietfa.amsl.com> <68E91C69-A7DB-40BE-BA60-DCDBA1F8EB28@kirei.se> <7645ADDE-1976-4F21-AB12-05DC40D425DC@tislabs.com> In-Reply-To: <7645ADDE-1976-4F21-AB12-05DC40D425DC@tislabs.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dane] I-D Action: draft-ietf-dane-protocol-14.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 18:00:27 -0000 The introduction does not seem to be worded nicely to me. I think the authors should make an effort to avoid the necessecity of external information, hidden assumptions which may not be the same for everybody, and use a more precise and non-ambiguous wording, well, I may simply live on another planet. The first response from the server in TLS may contain a certificate. - what does mean "first" and "response"? - I am not sure that one should start with this sentence at all. "In TLS, a server may present its identity by means of a certificate." "In order for the TLS client to authenticate that it is talking to the expected server, the client must - determine whether the identity present in the certificate is associated to the intended domain name, and Note: extracting a domain name and comparing it is not exactly the same as comparing a domain name with the identities in the cert. example wild-card names in the cert. - validate the authenticity using a certificate chain starting/rooted with a client's trust anchor. This description (or the existing text) does not talk about certification authorities; This the first sentence of the second paragraph Some people want a different way to authenticate the association of the server's certificate with the intended domain name without trusting an external certificate authority (CA). can only be understood under certain assumptions. A client may already only trust its own CA, and not anyone else for example. The easiest way to do this is to use the DNS. 'to do this' is related to the 'making an authoritive binding'. "It makes sense to publish such an authoritive binding through the DNS." The word "authoritive" may easily be confused with "can be authenticated" IMO. 1.1 A certificate association is formed from a piece of information identifying a certificate with the domain name where the data is found. Which "data are found.?" and what means "where"? Well, data="piece of information" one does not find things in th DNS, it is a cloud type service that responds to queries. One can find things in the responses. the entire certificate in the normal format is used. There is no such thing as a "normal format". 1.2: Because the certificate association was retrieved based on a DNS query, the domain name in the query is by definition associated with the certificate. That doesn't seem a correct sentence: It is only some information which will be used to form an association with the DNS name in the query? Doesn't that sentence belong to 1.1? regards Peter Sylvester From paul.hoffman@vpnc.org Wed Jan 11 12:43:59 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1A4321F86D5 for ; Wed, 11 Jan 2012 12:43:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HANttB7QV5z for ; Wed, 11 Jan 2012 12:43:59 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id CF7D921F8585 for ; Wed, 11 Jan 2012 12:43:58 -0800 (PST) Received: from sn87.proper.com (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0BKhunb068976 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 11 Jan 2012 13:43:57 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <7645ADDE-1976-4F21-AB12-05DC40D425DC@tislabs.com> Date: Wed, 11 Jan 2012 12:43:56 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <553913ED-9608-42DA-BC18-D06B39AD3BAE@vpnc.org> References: <20120104081557.23741.87139.idtracker@ietfa.amsl.com> <68E91C69-A7DB-40BE-BA60-DCDBA1F8EB28@kirei.se> <7645ADDE-1976-4F21-AB12-05DC40D425DC@tislabs.com> To: Suresh Krishnaswamy X-Mailer: Apple Mail (2.1251.1) Cc: IETF DANE WG list Subject: Re: [dane] I-D Action: draft-ietf-dane-protocol-14.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 20:43:59 -0000 On Jan 11, 2012, at 9:04 AM, Suresh Krishnaswamy wrote: > Section 1, 3rd para starting "[DANEUSECASES] also lists many = requirements, most of which ... "=20 >=20 > - Why "most of", and not "all of"?=20 Because we don't think it actually meets all the use cases listed. > Section 4.4, 2nd para starting "The TLS session that is to be set = up....". >=20 > - We should give specific guidance to application developers that = states that TLSA records MUST NOT be cached by *applications* beyond the = TTL (RRSIG expiration?) of the TLSA resource record set. We already say "The matching or chaining MUST be done within the life of = the TTL on the TLSA record." Is that not sufficient? Do we really want = to start partially describing to an application how to be a good caching = resolver? > Section 4.4, 6th para starting "If an application receives ...." >=20 > - Although we say in a preceeding bullet item that "if the DNSSEC = validation state on the response to the request for the TLSA RRset is = bogus, this MUST cause TLS not to be started..", I think we should also = say what an application must do if it could not validate the = non-existence of TLSA records. That is, suppose we receive zero usable = certificate associations, but no proof to assert non-existence we should = fail-close. Under which circumstances is an inability to validate the non-existence = of TLSA records *not* either bogus or insecure? > Section 4.4, 7th para starting "Clients that validate the DNSSEC = signatures ..." >=20 > - I'm a bit uneasy over the suggestion that it is okay for an = intermediary resolver to be able to introduce new certificates to the = client as long as the client communicates with it over a secure channel. = I'm probably okay with usage types 0 and 1 being used at the client side = when validation is not performed locally, but I'd really want a way (at = the client side) to be able to disable usage type 2 in certain = environments. If nothing else, I think we need to say something about = this in the security considerations section. How is this any different than the trusted-but-lying intermediary = resolver lying about any other DNS record? > Section 5, 2nd para: >=20 > - I agree with the the observation that "some of these might be = excessively glib". Should we make this a little more clear? For folks = coming fresh to this section perhaps saying how the requirements are met = would help. For instance: >=20 > Multiple Ports: The TLSA records for different application services = running on a single host can be distinguished through the service name = and port number prefixed to the host name (see section 3). >=20 > No Downgrade: Section 4.4 specifies the conditions under which a = client can process and act upon TLSA records. Specifically, if the = DNSSEC status for the TLSA resource record set is determined to be = bogus, TLS is not attempted at all.=20 >=20 > Encapsulation: ?? >=20 > Predicatability: The (non-normative) appendix sections provide = operational considerations and implementation guidance in order to = enable application developers to form a consistent interpretation of the = recommended DANE client behavior.=20 >=20 > Opportunistic Security: If a client conformant to this specification = can reliably determine the presence of a TLSA record, it will attempt to = use this information. Conversely, if a client can reliably determine the = absence of any TLSA record, it will fallback to processing TLS in the = normal fashion. This is discussed in section 4.4. >=20 > Combination: Multiple TLSA records can be published for a given host = name, thus enabling the client to construct multiple TLSA certificate = associations that reflect different DANE assertions. [No support is = provided to combine two TLSA certificate associations in a single = operation].=20 >=20 > Roll-over: Section 4.4 states {SK: subject to my note above} that = applications must not cache TLSA records beyond their TTL expiration. = This ensures that clients will not latch on to assertions made by older = TLSA records, and will be able to transition between using one DANE = mechanism to another. >=20 > Simple Key Management: The SubjectPublicKeyInfo selector in the TLSA = record provides a mode that enables a domain holder to only have to = maintain a single long-lived public/private key, without the need to = manage certificates. Section A.1.2.2 outlines the usefulness and the = potential downsides to using this mode. >=20 > Minimal Dependencies: This TLSA specification relies on DNSSEC to = protect the origin authenticity and integrity of the TLSA resource = record set. Additionally if DNSSEC validation is not performed on the = system that wishes to use TLSA certificate bindings, this specification = requires that the "last mile" be over some secure transport. There are = no other deployment dependencies for this approach. >=20 > Minimal Options: The operating modes map precisely to the DANE use = cases and requirements. DNSSEC use is mandatory in that this = specification encourages applications to use TLSA records that are only = shown to be validated. {SK: In section 8 we say that "client treatment = of any information included in the trust anchor is a matter of local = policy". What configuration knobs do we foresee?} >=20 > Wildcards: [covered in a limited manner in the TLSA request syntax; = see Appendix A.] >=20 > Redirection: [covered in the TLSA request syntax; see Appendix A.] These are great, thanks! > Section 8. >=20 > - See my point above on using cert usage type 2 when validation is not = done locally. Define "locally". Seriously. What if the app asks the operating system = to do the validation and fetching: is that local or not? The OS can be a = trusted-but-lying intermediary just as easily as a server is. > - I think we do need to say something related to cert usage 2 and its = removal of dependencies on the PKI infrastructure. That is, in cases = where the CA was following good (ideal?) practices but the DNS = administrator was not, an attacker who is able to compromise the DNS = name server will not only be able to take you to a different machine = that claims to be the webserver, but will also give you a TLS connection = that you (or your application) will believe. =20 What useful can we say here? The above doesn't give an implementer or a = user any useful warning. > B.2 Pseudo code >=20 > - For consistency, we should probably use {R.matchingType, = R.selectorType, R.cert} Good suggestion. > - All calls to Match() should probably specify R.cert as the last = parameter Indeed. --Paul Hoffman From mrex@sap.com Wed Jan 11 13:06:05 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF2011E80A5 for ; Wed, 11 Jan 2012 13:06:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.993 X-Spam-Level: X-Spam-Status: No, score=-9.993 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPKN5PNII5CQ for ; Wed, 11 Jan 2012 13:06:04 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 5D3D711E8079 for ; Wed, 11 Jan 2012 13:06:04 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q0BL61h3002597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Jan 2012 22:06:01 +0100 (MET) From: Martin Rex Message-Id: <201201112106.q0BL60n0028752@fs4113.wdf.sap.corp> To: paul.hoffman@vpnc.org (Paul Hoffman) Date: Wed, 11 Jan 2012 22:06:00 +0100 (MET) In-Reply-To: <553913ED-9608-42DA-BC18-D06B39AD3BAE@vpnc.org> from "Paul Hoffman" at Jan 11, 12 12:43:56 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] I-D Action: draft-ietf-dane-protocol-14.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 21:06:05 -0000 Paul Hoffman wrote: > >Suresh Krishnaswamy wrote: >> >> Section 4.4, 2nd para starting "The TLS session that is to be set up....". >> >> - We should give specific guidance to application developers that >> states that TLSA records MUST NOT be cached by *applications* beyond >> the TTL (RRSIG expiration?) of the TLSA resource record set. > > We already say "The matching or chaining MUST be done within the life > of the TTL on the TLSA record." Is that not sufficient? Do we really > want to start partially describing to an application how to be a good > caching resolver? I think that "MUST be done within the life to the TTL" is inappropriate and potentially misleading (about the resulting security properties). The TTL mechanism is a loose control for the caching of DNS records, but it is *NOT* a security feature. The TTL is neither covered nor verified by DNSSEC. Within the remaining validity of the RRSIG, an attacker can replay previous DNS replies with arbitrary TTL values. -Martin From suresh@tislabs.com Wed Jan 11 14:07:14 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C33D21F84F3 for ; Wed, 11 Jan 2012 14:07:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WNo8GiexgtA7 for ; Wed, 11 Jan 2012 14:07:13 -0800 (PST) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC0621F84E4 for ; Wed, 11 Jan 2012 14:07:13 -0800 (PST) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 1C5F328B003A; Wed, 11 Jan 2012 17:07:11 -0500 (EST) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 063A11F8032; Wed, 11 Jan 2012 17:07:11 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Suresh Krishnaswamy In-Reply-To: <553913ED-9608-42DA-BC18-D06B39AD3BAE@vpnc.org> Date: Wed, 11 Jan 2012 17:07:10 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120104081557.23741.87139.idtracker@ietfa.amsl.com> <68E91C69-A7DB-40BE-BA60-DCDBA1F8EB28@kirei.se> <7645ADDE-1976-4F21-AB12-05DC40D425DC@tislabs.com> <553913ED-9608-42DA-BC18-D06B39AD3BAE@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1084) Cc: IETF DANE WG list Subject: Re: [dane] I-D Action: draft-ietf-dane-protocol-14.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 22:07:14 -0000 On Jan 11, 2012, at 3:43 PM, Paul Hoffman wrote: > On Jan 11, 2012, at 9:04 AM, Suresh Krishnaswamy wrote: >=20 >> Section 1, 3rd para starting "[DANEUSECASES] also lists many = requirements, most of which ... "=20 >>=20 >> - Why "most of", and not "all of"?=20 >=20 > Because we don't think it actually meets all the use cases listed. Use-cases are different from requirements, I think. If we mean = use-cases, we should say so and perhaps point to the specific use cases = that we don't meet. >=20 >> Section 4.4, 2nd para starting "The TLS session that is to be set = up....". >>=20 >> - We should give specific guidance to application developers that = states that TLSA records MUST NOT be cached by *applications* beyond the = TTL (RRSIG expiration?) of the TLSA resource record set. >=20 > We already say "The matching or chaining MUST be done within the life = of the TTL on the TLSA record." Is that not sufficient? Do we really = want to start partially describing to an application how to be a good = caching resolver? >=20 If we feel that it's important to mention TTL at all I think it's also = useful to clearly state any implementation advice relating to it. >> Section 4.4, 6th para starting "If an application receives ...." >>=20 >> - Although we say in a preceeding bullet item that "if the DNSSEC = validation state on the response to the request for the TLSA RRset is = bogus, this MUST cause TLS not to be started..", I think we should also = say what an application must do if it could not validate the = non-existence of TLSA records. That is, suppose we receive zero usable = certificate associations, but no proof to assert non-existence we should = fail-close. >=20 > Under which circumstances is an inability to validate the = non-existence of TLSA records *not* either bogus or insecure? The set of bullet points in section 4.4 relate to the positive answer = scenario, i.e. when TLSA records are available. The following para = begins with "If an application receives zero usable certificate = associations, it processes TLS in the normal fashion...". Providing = clarity on negative answer processing will help, I think. >=20 >> Section 4.4, 7th para starting "Clients that validate the DNSSEC = signatures ..." >>=20 >> - I'm a bit uneasy over the suggestion that it is okay for an = intermediary resolver to be able to introduce new certificates to the = client as long as the client communicates with it over a secure channel. = I'm probably okay with usage types 0 and 1 being used at the client side = when validation is not performed locally, but I'd really want a way (at = the client side) to be able to disable usage type 2 in certain = environments. If nothing else, I think we need to say something about = this in the security considerations section. >=20 > How is this any different than the trusted-but-lying intermediary = resolver lying about any other DNS record? >=20 The difference is that I may be forced to talk to an untrusted-and-lying = intermediary resolver that only wants to talk over a secure channel. = Simply having a secure channel to a lying recursive name server does not = mean I place more trust on it. >=20 >> Section 8. >>=20 >> - See my point above on using cert usage type 2 when validation is = not done locally. >=20 > Define "locally". Seriously. What if the app asks the operating system = to do the validation and fetching: is that local or not? The OS can be a = trusted-but-lying intermediary just as easily as a server is. >=20 I think the user has a basic level of trust on the OS and the hardware = on which it runs. You'd probably be willing to trust an answer that you = received from your local validating resolver than one from a validating = recursive nameserver provided by your favorite coffee shop. "Local" is = saying where our trust boundary lies. >> - I think we do need to say something related to cert usage 2 and its = removal of dependencies on the PKI infrastructure. That is, in cases = where the CA was following good (ideal?) practices but the DNS = administrator was not, an attacker who is able to compromise the DNS = name server will not only be able to take you to a different machine = that claims to be the webserver, but will also give you a TLS connection = that you (or your application) will believe. =20 >=20 > What useful can we say here? The above doesn't give an implementer or = a user any useful warning. >=20 We're mentioning the trade-off, that's all. Also, I forgot to mention the other operational/availability trade-off: = this approach relies on our ability to validate DNSSEC responses, so if = DNSSEC validation this is impeded in anyway (middle boxes, broken = environments etc) we will lose our ability to do any TLS since we will = fail-close. Suresh= From richard@highwayman.com Fri Jan 13 03:35:22 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73C0821F8545 for ; Fri, 13 Jan 2012 03:35:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2H3MNU0T0F-f for ; Fri, 13 Jan 2012 03:35:21 -0800 (PST) Received: from anchor-post-1.mail.demon.net (anchor-post-1.mail.demon.net [195.173.77.132]) by ietfa.amsl.com (Postfix) with ESMTP id 25A1921F84E2 for ; Fri, 13 Jan 2012 03:35:21 -0800 (PST) Received: from happyday.demon.co.uk ([80.177.121.10] helo=happyday.al.cl.cam.ac.uk) by anchor-post-1.mail.demon.net with esmtp (Exim 4.69) id 1RlfPk-0005Ls-gd for dane@ietf.org; Fri, 13 Jan 2012 11:35:20 +0000 Message-ID: Date: Fri, 13 Jan 2012 11:34:06 +0000 To: dane@ietf.org From: Richard Clayton MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailer: Turnpike Integrated Version 5.03 M Subject: [dane] Call for Papers: Securing and Trusting Internet Names, SATIN 2012 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Richard Clayton List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 11:35:22 -0000 The usual apologies if you see multiple copies of this CFP, but the inhabitants of this mailing list are more likely than most to wish to submit papers! Call for Papers: Securing and Trusting Internet Names, SATIN 2012 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D When: Thu/Fri 22/23 March 2012 NB: ** NEW ** we are expecting to run the Spring DNS-OARC meeting on Wed 21 March Also note that IETF 83 is in Paris, France the following week Where: National Physical Laboratory (NPL) Teddington, London, UK Timetable: Submissions due: Sun 23 Jan 2011, 11:59 PST Notification of Acceptance: Wed 23 Feb 2011 Final Papers Due: Mon 15 Mar 2011 ** NEW ** Requests for a short (7 day) extension to the submission deadline will be entertained by the Program Chair. However, title, authors and abstract MUST be submitted to the website by the original 23 Jan deadline ** NEW ** Workshop Organizers =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Program Chair Richard Clayton NPL and University of Cambridge Program Committee Nevil Brownlee University of Auckland Ben Laurie Google Anne-Marie Eklund L=F6winder .SE (The Internet Infrastructure Foundation) Dan Massey Colorado State University Douglas Maughan Department of Homeland Security Andrew W Moore University of Cambridge Jose Nazario Arbor Networks Roberto Perdisci University of Georgia Dave Piscitello ICANN Paul Vixie ISC Nicholas Weaver ICSI & UC Berkeley Jonathan Williams NPL Overview =3D=3D=3D=3D=3D=3D=3D=3D The domain name system, on which the Internet entirely relies, has always been inherently insecure. Spoofing of IP source addresses means that any wide area UDP protocol (such as DNS) can be forged. Cache poisoning attacks can be made less likely but not prevented altogether. ISPs, or others who can intercept traffic, can redirect end users to sites of their choosing. Users can choose (or have forced upon them) DNS services that suppress access to sites for policy reasons. DNSSEC, which addresses some of these issues, has been under development for years - but is finally ready for use; although some of the finer details are still being worked out. However, even at the current scale of deployment, implementation issues are creating unexpected levels of traffic, and that is before the bad guys make any contribution. Meanwhile DNSCURVE is being promoted as a lightweight method of securing the links to and between name servers, which addresses some, but by no means all, of the security issues. DNSSEC is also being seen by some as a distributed, secure, key distribution system, which could support new applications, or replace existing mechanisms for establishing trust in the identity of endpoints. The IETF's DANE working group is already addressing these issues. Others merely see DNSSEC as a way of defeating marketers who want to inject targeted advertising into browser sessions. But how effective will these ideas be if we continue with our existing APIs and stub resolvers? There are significant issues with DNS besides just its integrity. DNS services can be used to amplify denial-of-service attacks to create very substantial traffic flows. Malware has also been using the DNS for rendezvous arrangements, and has avoided countermeasures by exploiting the DNS system through "fluxing" and other techniques. There are also signs of a "tragedy of the commons" as legitimate companies fill the DNS with large numbers of names, or set low TTLs, to give a performance "edge". Meanwhile, some applications pre-fetch DNS answers, with little heed to the impact on the infrastructure. This latter technique raises privacy issues, as indeed does the proposal to 'leak' partial identities of requestors who contact recursive resolvers, with the aim of providing different answers to machines in different blocks of address space. All of this makes DNS, once amongst the most boring of topics, into one of the more exciting. The first running of this workshop in April 2011 was a big success, and this second event will be equally significant. Topics =3D=3D=3D=3D=3D=3D SATIN aims to provide a forum for academic work on the security of the DNS alongside industry presentations on practical experiences in providing name services. This workshop will expose the academics to the real problems that industry is encountering, and show industry what academia has to offer them. To improve the flow of information (and as was most successful at the first SATIN workshop) presentations will be restricted to 15 minutes with 15 minutes of general discussion to follow. Submissions must be made under either an "academic" or "industry" label (relating entirely to the content rather than the affiliations of any author), because the two types will be judged by different standards. Academic work will be viewed as an "extended abstract" and should aim to meet the general standard for acceptance into normal conferences in the field. However, since this is a workshop, early results and initial ideas are welcomed. Industry submissions should be relevant, insightful, and technical, and should provide information that cannot be gleaned from reading sales brochures or manuals. In all cases, real-world operational, implementation, and experimental results will be preferred, and these results should inform the DNS protocol development process wherever relevant or possible. Topics of interest include but are not limited to: Attacks on naming services DNSSEC DNSCURVE Alternative methods of securing name services APIs for DNS resolvers Using DNS as a platform for other applications Denial of service and the DNS Malware and the DNS DNS caching on the modern Internet Privacy and the DNS Application behaviour and the DNS Security economics of naming services Passive DNS Operational experience Measurement studies New threats and challenges Questions regarding whether a topic would be suitable are welcome and should be sent to the program chair, richard.clayton AT npl.co.uk Submissions =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D All submissions must be in IEEE two column format and no longer than eight (8) 8.5'' x 11'' pages, including figures, tables, and references. That means that the text must be set in two columns in 10 point type on 12 point (single-spaced) leading, with the text block being no more than 7.2'' wide by 9.6'' deep. Author names and affiliations should appear on the title page. The use of LaTeX and the IEEEtrans.cls file to create submissions is very strongly encouraged: http://conferences.npl.co.uk/satin/format.html Submissions must be submitted in PDF format via the SATIN 2012 website: http://conferences.npl.co.uk/satin/submit.html Simultaneous submission of the same work to multiple venues, submission of previously published work, or plagiarism, is dishonest and/or fraudulent and action may be taken if this occurs. Note, however, that we expect that many papers accepted for SATIN will eventually be extended as full papers suitable for presentation at other conferences. About the National Physical Laboratory =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The National Physical Laboratory (NPL) is one of the UK's leading science and research facilities. It is a world-leading centre of excellence in developing and applying the most accurate standards, science and technology available. NPL occupies a unique position as the UK's National Measurement Institute and sits at the intersection between scientific discovery and real world application. Its expertise and original research have underpinned quality of life, innovation and competitiveness for UK citizens and business for more than a century. NPL is collaborating with the University of Cambridge in a three year programme to develop robust and accurate measurements of Internet security mechanisms. Measuring and understanding the deployment of DNSSEC and other trust mechanisms for Internet names is a key part of this ongoing programme. More at: http://conferences.npl.co.uk/satin/ --=20 Dr Richard Clayton tel: +44 1223 763570, mobile: +44 7887 794090 Computer Laboratory, University of Cambridge, CB3 0FD National Physical Laboratory, Hampton Road, Teddington, TW11 0LW From stephen.farrell@cs.tcd.ie Fri Jan 13 10:26:34 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF87121F84E1; Fri, 13 Jan 2012 10:26:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.507 X-Spam-Level: X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9hw88tmRiJ4y; Fri, 13 Jan 2012 10:26:34 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 48C5821F849D; Fri, 13 Jan 2012 10:26:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 66CB1171CC3; Fri, 13 Jan 2012 18:26:19 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1326479178; bh=3R2RTxtYEZE96C 1vaPyq8mMqTa5543cjo2S9hxXqPb8=; b=2iWKMAG/oVVEKOMcLDwf0qsQ59fyCo UnnPfLOn3Vc2D9jN0f8R60XiRTS0VgYS4fSp/mAoTW3pqiQhZP3f6qiB3vtJLlDO efY5gyGovQ10Py9L4DLbWyTCfpQmOr4f/7ik9V6ZYRwGg2UKqNm/FBjB+4t8SGwv BEaiAlERvAW/mvxP9MK3q0l6QUC6ZbySmcUBDW0qnQXul/NxnnnpYw8StIX985t1 2/8tmSu3tRPyBbwPpCxPokZ7MlhYhZJBsidBpigmyJXE8WB9DAMfKnFQevczDcny o3KFA2jvsl/E1f+7GMFGDj+6UkhgnNtkDOvw5fM9d7mzDjaem7wUzlEg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id vhvCUBUgTFFA; Fri, 13 Jan 2012 18:26:18 +0000 (GMT) Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id D8F19171CC2; Fri, 13 Jan 2012 18:26:18 +0000 (GMT) Message-ID: <4F10774A.4030003@cs.tcd.ie> Date: Fri, 13 Jan 2012 18:26:18 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "saag@ietf.org" , pkix , "tls@ietf.org" , dane References: <20120113182358.143B621F8579@ietfa.amsl.com> In-Reply-To: <20120113182358.143B621F8579@ietfa.amsl.com> X-Forwarded-Message-Id: <20120113182358.143B621F8579@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [dane] Fwd: New Non-WG Mailing List: therightkey X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 18:26:34 -0000 FYI please sign up if interested but wait a few days to give folks a chance to sign up before starting in on discussion. Stephen & Sean. -------- Original Message -------- Subject: New Non-WG Mailing List: therightkey Date: Fri, 13 Jan 2012 10:23:58 -0800 (PST) From: IETF Secretariat To: IETF Announcement list CC: therightkey@ietf.org, turners@ieca.com, stephen.farrell@cs.tcd.ie A new IETF non-working group email list has been created. List address: therightkey@ietf.org Archive: http://www.ietf.org/mail-archive/web/therightkey/ To subscribe: https://www.ietf.org/mailman/listinfo/therightkey Purpose: A number of people are interested in discussing proposals that have been developed in response to recent attacks on the Internet security infrastructure, in particular those that affected sites using TLS and other protocols relying on PKI. This list is intended for discussion of those proposals and how they might result in potential work items for the IETF. One short-term outcome may be the holding of a non-wg-forming BoF at IETF-83. For additional information, please contact the list administrators. From Jeff.Hodges@KingsMountain.com Fri Jan 13 14:04:13 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0959211E8081 for ; Fri, 13 Jan 2012 14:04:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.02 X-Spam-Level: X-Spam-Status: No, score=-100.02 tagged_above=-999 required=5 tests=[AWL=0.475, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJL+blpQUYq0 for ; Fri, 13 Jan 2012 14:04:12 -0800 (PST) Received: from oproxy1-pub.bluehost.com (oproxy1.bluehost.com [IPv6:2605:dc00:100:2::a1]) by ietfa.amsl.com (Postfix) with SMTP id 65FB221F8541 for ; Fri, 13 Jan 2012 14:04:12 -0800 (PST) Received: (qmail 16918 invoked by uid 0); 13 Jan 2012 22:04:11 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy1.bluehost.com with SMTP; 13 Jan 2012 22:04:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=K5fLWk9NdcjZ1wMxoZ7a/vmj2xkxoDzn7PpB5ok02iA=; b=Mqm3PJic+5lIyaHAzT1cYeBbxaZcyMPGnFl7i59gmkvQ8FuL/Bx6eKiLG5iMYte7kl5i3+kkeL7M14pyQcH9sibLLKQBIOBFftjyEV8LUdDTQK1tR4Qw7peR0pX24FA3; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.137.162]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1RlpEJ-00033q-32; Fri, 13 Jan 2012 15:04:11 -0700 Message-ID: <4F10AA5B.8050503@KingsMountain.com> Date: Fri, 13 Jan 2012 14:04:11 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: pkix , dane , "saag@ietf.org" , "tls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [dane] Fwd: New Non-WG Mailing List: therightkey X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 22:04:13 -0000 > On Fri, Jan 13, 2012 at 1:26 PM, Stephen Farrell > wrote: >> Archive: http://www.ietf.org/mail-archive/web/therightkey/ > > This link is dead. Typo, or not yet available? works for me! see also: https://www.ietf.org/mailman/listinfo/therightkey HtH, =JeffH From ynir@checkpoint.com Sat Jan 14 01:03:54 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A26121F85BB; Sat, 14 Jan 2012 01:03:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1689OwFduWb; Sat, 14 Jan 2012 01:03:53 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 6B76221F85AF; Sat, 14 Jan 2012 01:03:52 -0800 (PST) X-CheckPoint: {4F11425B-0-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q0E93o71011172; Sat, 14 Jan 2012 11:03:51 +0200 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sat, 14 Jan 2012 11:03:50 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Sat, 14 Jan 2012 11:03:49 +0200 From: Yoav Nir To: =JeffH Date: Sat, 14 Jan 2012 11:03:50 +0200 Thread-Topic: [dane] Fwd: New Non-WG Mailing List: therightkey Thread-Index: AczSm25ntan/4oQoRnu1dXwzszgw8A== Message-ID: <4218085B-5136-4ADF-AD00-50DB3C7EB72F@checkpoint.com> References: <4F10AA5B.8050503@KingsMountain.com> In-Reply-To: <4F10AA5B.8050503@KingsMountain.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: pkix , "saag@ietf.org" , "tls@ietf.org" , dane Subject: Re: [dane] Fwd: New Non-WG Mailing List: therightkey X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2012 09:03:54 -0000 On Jan 14, 2012, at 12:04 AM, =3DJeffH wrote: >> On Fri, Jan 13, 2012 at 1:26 PM, Stephen Farrell >> wrote: >>> Archive: http://www.ietf.org/mail-archive/web/therightkey/ >>=20 >> This link is dead. Typo, or not yet available? >=20 > works for me! +1 From bortzmeyer@nic.fr Mon Jan 16 01:23:15 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 432AD21F855D for ; Mon, 16 Jan 2012 01:23:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mhag5aprsuU1 for ; Mon, 16 Jan 2012 01:23:14 -0800 (PST) Received: from mx2.nic.fr (mx2.nic.fr [IPv6:2001:660:3003:2::4:11]) by ietfa.amsl.com (Postfix) with ESMTP id 8127521F854F for ; Mon, 16 Jan 2012 01:23:14 -0800 (PST) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 470C91C0117; Mon, 16 Jan 2012 10:23:11 +0100 (CET) Received: by mx2.nic.fr (Postfix, from userid 500) id 322D41C011A; Mon, 16 Jan 2012 10:23:11 +0100 (CET) Received: from relay1.nic.fr (relay1.nic.fr [IPv6:2001:67c:2218:9::4:162]) by mx2.nic.fr (Postfix) with ESMTP id 213F31C0117; Mon, 16 Jan 2012 10:23:11 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [IPv6:2001:67c:2219:8::6:69]) by relay1.nic.fr (Postfix) with ESMTP id 1FE6E4C007D; Mon, 16 Jan 2012 10:23:11 +0100 (CET) Date: Mon, 16 Jan 2012 10:23:11 +0100 From: Stephane Bortzmeyer To: Paul Hoffman Message-ID: <20120116092310.GA26883@nic.fr> References: <20120104081557.23741.87139.idtracker@ietfa.amsl.com> <68E91C69-A7DB-40BE-BA60-DCDBA1F8EB28@kirei.se> <7645ADDE-1976-4F21-AB12-05DC40D425DC@tislabs.com> <553913ED-9608-42DA-BC18-D06B39AD3BAE@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <553913ED-9608-42DA-BC18-D06B39AD3BAE@vpnc.org> X-Operating-System: Debian GNU/Linux wheezy/sid X-Kernel: Linux 3.1.0-1-686-pae i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.21 (2010-09-15) X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=1.1.5 X-PMX-Version: 5.4.6.353000, Antispam-Engine: 2.6.1.350677, Antispam-Data: 2012.1.16.91214 X-PerlMx-Spam: Gauge=IIIIIII, Probability=8%, Report='MULTIPLE_RCPTS 0.1, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, BODY_SIZE_900_999 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CD 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MULTIPLE_RCPTS_CC_X2 0, __SANE_MSGID 0, __TO_MALFORMED_2 0, __URI_NO_PATH 0, __URI_NO_WWW 0, __USER_AGENT 0' Cc: IETF DANE WG list Subject: Re: [dane] I-D Action: draft-ietf-dane-protocol-14.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 09:23:15 -0000 On Wed, Jan 11, 2012 at 12:43:56PM -0800, Paul Hoffman wrote a message of 83 lines which said: > I think we should also say what an application must do if it could > not validate the non-existence of TLSA records. That is, suppose we > receive zero usable certificate associations, but no proof to assert > non-existence we should fail-close. > > Under which circumstances is an inability to validate the > non-existence of TLSA records *not* either bogus or insecure? Don't know if it is the problem but, currently, an application cannot easily distinguish "insecure because the domain is not signed / has no DS above" and "insecure because the resolver I use does not validate". IMHO, it changes nothing for DANE (in both cases, the TLSA records MUST be ignored) but it can be a problem for some persons (when you publish proper and valid TLSA records, you can never be sure they will be used). From bortzmeyer@nic.fr Mon Jan 16 01:44:22 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B80C921F858F for ; Mon, 16 Jan 2012 01:44:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALYXGofliSuK for ; Mon, 16 Jan 2012 01:44:22 -0800 (PST) Received: from mx2.nic.fr (mx2.nic.fr [IPv6:2001:660:3003:2::4:11]) by ietfa.amsl.com (Postfix) with ESMTP id A339621F858E for ; Mon, 16 Jan 2012 01:44:21 -0800 (PST) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id DA4C91C0111; Mon, 16 Jan 2012 10:44:20 +0100 (CET) Received: by mx2.nic.fr (Postfix, from userid 500) id C3D121C0117; Mon, 16 Jan 2012 10:44:20 +0100 (CET) Received: from relay1.nic.fr (relay1.nic.fr [IPv6:2001:67c:2218:9::4:162]) by mx2.nic.fr (Postfix) with ESMTP id BA69C1C0111; Mon, 16 Jan 2012 10:44:20 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [IPv6:2001:67c:2219:8::6:69]) by relay1.nic.fr (Postfix) with ESMTP id B8CE54C007D; Mon, 16 Jan 2012 10:44:20 +0100 (CET) Date: Mon, 16 Jan 2012 10:44:20 +0100 From: Stephane Bortzmeyer To: Jakob Schlyter Message-ID: <20120116094420.GB26883@nic.fr> References: <7A4B9C55-52C3-4A93-9DA7-62F98CF2A6A5@bbn.com> <03EDD353-7C2F-4E2E-911A-117673C94FAF@vpnc.org> <689C663D-4898-4C2D-858C-BE01CA38B666@vpnc.org> <536F7502-9FCA-484B-8771-E0C7BA6BF14A@kirei.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <536F7502-9FCA-484B-8771-E0C7BA6BF14A@kirei.se> X-Operating-System: Debian GNU/Linux wheezy/sid X-Kernel: Linux 3.1.0-1-686-pae i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.21 (2010-09-15) X-Bogosity: No, tests=bogofilter, spamicity=0.000001, version=1.1.5 X-PMX-Version: 5.4.6.353000, Antispam-Engine: 2.6.1.350677, Antispam-Data: 2012.1.16.93015 X-PerlMx-Spam: Gauge=IIIIIII, Probability=8%, Report='MULTIPLE_RCPTS 0.1, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, BODY_SIZE_800_899 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CD 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MULTIPLE_RCPTS_CC_X2 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __TO_MALFORMED_2 0, __URI_NO_PATH 0, __URI_NO_WWW 0, __USER_AGENT 0' Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 09:44:22 -0000 On Tue, Jan 10, 2012 at 07:42:46PM +0100, Jakob Schlyter wrote a message of 20 lines which said: > "the domain name that the client thought it was connecting to" could > be interpreted as the domain name found at the right hand side of > the MX record. For SMTP as deployed today, this makes sense - e.g., > MX for kirei.se points to mail.kirei.se, and the TLS cert is > CN=mail.kirei.se (not CN=kirei.se or the like). Today, almost no MTA tries to authenticate the peer is connects to. If they were to start doing it, we would quickly discover that: 1) Noone really understands the host/service matching rule of X.509 for SMTP. (And RFC 6125 does not help.) 2) They are not implemented properly. So, I'm afraid we have very little practical experience about validation of names in SMTP-over-TLS. From miekg@atoom.net Mon Jan 16 02:12:43 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 012C721F845B for ; Mon, 16 Jan 2012 02:12:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.385 X-Spam-Level: X-Spam-Status: No, score=-2.385 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wGqdQqmKQINf for ; Mon, 16 Jan 2012 02:12:42 -0800 (PST) Received: from elektron.atoom.net (cl-201.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:c8::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5C57E21F845A for ; Mon, 16 Jan 2012 02:12:42 -0800 (PST) Received: by elektron.atoom.net (Postfix, from userid 1000) id 6266340209; Mon, 16 Jan 2012 11:12:40 +0100 (CET) Date: Mon, 16 Jan 2012 11:12:40 +0100 From: Miek Gieben To: dane@ietf.org Message-ID: <20120116101240.GC3140@miek.nl> Mail-Followup-To: dane@ietf.org References: <59E1FDB4-B832-415A-BEE3-8E85CC55E337@vpnc.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YD3LsXFS42OYHhNZ" Content-Disposition: inline In-Reply-To: <59E1FDB4-B832-415A-BEE3-8E85CC55E337@vpnc.org> User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Subject: Re: [dane] Pseudocode review X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 10:12:43 -0000 --YD3LsXFS42OYHhNZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [ Quoting at 06:46 on Jan 4 in "[dane] Pseudocode = re..." ] > and will tend to focus on this non-normative appendix rather than the body > text. Ilari already found one small error (thanks!), and we would like > developer-like folks on the list to poke harder at the section so that we= are > somewhat confident that everyone understands what the protocol is doing. To pseudo code looks good to me. But I do have a question, the line: if (Match(matchingType, Select(selectorType, C), R)) { Finish(2) } Isn't this better? if (Match(R.matchingType, Select(R.selectorType, C), R)) { Finish(2) } It wasn't immediately clear to me where matchingType and selectType came =66rom (when just reading the pseudo code). Kind regards, Miek Gieben --YD3LsXFS42OYHhNZ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk8T+BgACgkQJYuFzziA0PbwLgCeKSP5u5tsKd79kYZCtsLltBVy evYAnRFzb6qVvcajOuuZa8qL5sps/4JL =tUE5 -----END PGP SIGNATURE----- --YD3LsXFS42OYHhNZ-- From diego@tid.es Mon Jan 16 05:43:46 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A76C621F85DD; Mon, 16 Jan 2012 05:43:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.073 X-Spam-Level: X-Spam-Status: No, score=-4.073 tagged_above=-999 required=5 tests=[AWL=-0.074, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Puj19AxAmwpa; Mon, 16 Jan 2012 05:43:46 -0800 (PST) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2F821F85CF; Mon, 16 Jan 2012 05:43:45 -0800 (PST) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXW00APH8SR29@tid.hi.inet>; Mon, 16 Jan 2012 14:43:39 +0100 (MET) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 4F.04.02643.B89241F4; Mon, 16 Jan 2012 14:43:39 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LXW00APE8SR29@tid.hi.inet>; Mon, 16 Jan 2012 14:43:39 +0100 (MET) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad1.hi.inet ([192.168.0.1]) with mapi; Mon, 16 Jan 2012 14:43:39 +0100 Date: Mon, 16 Jan 2012 14:43:38 +0100 From: DIEGO LOPEZ GARCIA To: "therightkey@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US Thread-topic: EFF's Sovereign Keys Thread-index: AczUVNpyTMTOa4BtTAeY+91PStdUMQ== acceptlanguage: en-US X-AuditID: 0a5f4e69-b7f6b6d000000a53-fa-4f14298b4425 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphleLIzCtJLcpLzFFi42Lhivcz1O3WFPE3uHJXzmLP8YmsFjsuXWG1 +HjhJ4sDs8eSJT+ZAhijuGxSUnMyy1KL9O0SuDLuTrzGUtDCUbH/0SHmBsYX7F2MnBwSAiYS bw5dYYKwxSQu3FvPBmILCWxjlPi617KLkQvIfsoocfvxY1YIp5FRYv+2NywgVSwCqhJr/l8G 62YTUJdoOfoNLC4sICux6+slsLiIgKFE99xXYDazgJ/E3fuTmEFsXgFLid1357FD2IISPybf A+rlAKpRl5gyJReiXFyiufUmC4StKDFtUQMjiM0IdOj3U2ugxitJtD+Yyg7SKiKgJ3FtdyBE iajEnfb1jBB/CUgs2XOeGcIWlXj5+B/rBEbRWUgWz0JYPAvJ4llIFi9gZFnFKFacVJSZnlGS m5iZk25gpJeRqZeZl1qyiRESJZk7GJfvVDnEKMDBqMTD+7BQ2F+INbGsuDL3EKMkB5OSKK+p hoi/EF9SfkplRmJxRnxRaU5q8SFGCQ5mJRHeNn2gct6UxMqq1KJ8mJQMB4eSBO9rkDbBotT0 1Iq0zBxgKoBJM3FwgrTzALWvAqnhLS5IzC3OTIfIn2KUlBLnjQBJCIAkMkrz4HpfMYoDHSkM 0cYDTFpwXa+ABjIBDcxpFQIZWJKIkJJqYDQuCawK2xky6UWkvX/DruqTufEbsy/Fp34vNJiu 9mWWzflWqYZ93F9tF03s2cizfdoF/w0yTE3Z7j6FaYprCpbfsxeMDQq2qe/awvIxLVfq0K/8 8g9XmJXF+wyz1k6TPpFhs/r52rW/LheEfgx1mPG0sk3E8lP8q1KdpEsmoV73w5faLrmwToml OCPRUIu5qDgRAAAU/CAXAwAA Cc: "domainrep@ietf.org" , "dane@ietf.org" Subject: [dane] EFF's Sovereign Keys X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 13:43:46 -0000 SGksDQoNCkhhdmUgeW91IHBlb3BsZSBoZWFyZCBvZiB0aGlzPw0KDQpodHRwczovL3d3dy5lZmYu b3JnL3NvdmVyZWlnbi1rZXlzDQoNCkl0IGxvb2tzIHZlcnkgbXVjaCBjb25uZWN0ZWQgdG8gdGhl IGRlY2xhcmF0aW9uIG9mIHRoZXJpZ2h0a2V5LCBhbmQgY2VydGFpbmx5IHJlbGF0ZWQgdG8gREFO RSBhbmQgUkVQVVRFLg0KDQpCZSBnb29kZSwNCg0KLS0NCiJFc3RhIHZleiBubyBmYWxsYXJlbW9z LCBEb2N0b3IgSW5maWVybm8iDQoNCkRyIERpZWdvIFIuIExvcGV6DQpUZWxlZm9uaWNhIEkrRA0K DQplLW1haWw6IGRpZWdvQHRpZC5lcw0KVGVsOiAgICArMzQgOTEzIDEyOSAwNDENCk1vYmlsZTog KzM0IDY4MiAwNTEgMDkxDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KDQoNCkVzdGUgbWVuc2FqZSBzZSBkaXJpZ2UgZXhjbHVzaXZhbWVudGUgYSBzdSBkZXN0aW5h dGFyaW8uIFB1ZWRlIGNvbnN1bHRhciBudWVzdHJhIHBvbMOtdGljYSBkZSBlbnbDrW8geSByZWNl cGNpw7NuIGRlIGNvcnJlbyBlbGVjdHLDs25pY28gZW4gZWwgZW5sYWNlIHNpdHVhZG8gbcOhcyBh YmFqby4NClRoaXMgbWVzc2FnZSBpcyBpbnRlbmRlZCBleGNsdXNpdmVseSBmb3IgaXRzIGFkZHJl c3NlZS4gV2Ugb25seSBzZW5kIGFuZCByZWNlaXZlIGVtYWlsIG9uIHRoZSBiYXNpcyBvZiB0aGUg dGVybXMgc2V0IG91dCBhdA0KaHR0cDovL3d3dy50aWQuZXMvRVMvUEFHSU5BUy9kaXNjbGFpbWVy LmFzcHgNCg== From paul.hoffman@vpnc.org Mon Jan 16 08:12:38 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 637FB21F85BE for ; Mon, 16 Jan 2012 08:12:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RbVuRVBQtuIC for ; Mon, 16 Jan 2012 08:12:38 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id CF71F21F8576 for ; Mon, 16 Jan 2012 08:12:37 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q0GGCXTd028023 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 16 Jan 2012 09:12:33 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20120116092310.GA26883@nic.fr> Date: Mon, 16 Jan 2012 08:12:35 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120104081557.23741.87139.idtracker@ietfa.amsl.com> <68E91C69-A7DB-40BE-BA60-DCDBA1F8EB28@kirei.se> <7645ADDE-1976-4F21-AB12-05DC40D425DC@tislabs.com> <553913ED-9608-42DA-BC18-D06B39AD3BAE@vpnc.org> <20120116092310.GA26883@nic.fr> To: Stephane Bortzmeyer X-Mailer: Apple Mail (2.1251.1) Cc: IETF DANE WG list Subject: Re: [dane] I-D Action: draft-ietf-dane-protocol-14.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 16:12:38 -0000 On Jan 16, 2012, at 1:23 AM, Stephane Bortzmeyer wrote: > On Wed, Jan 11, 2012 at 12:43:56PM -0800, > Paul Hoffman wrote=20 > a message of 83 lines which said: > [[ Suresh Krishnaswamy asked: ]] >> I think we should also say what an application must do if it could >> not validate the non-existence of TLSA records. That is, suppose we >> receive zero usable certificate associations, but no proof to assert >> non-existence we should fail-close. >>=20 >> Under which circumstances is an inability to validate the >> non-existence of TLSA records *not* either bogus or insecure? >=20 > Don't know if it is the problem but, currently, an application cannot > easily distinguish "insecure because the domain is not signed / has no > DS above" and "insecure because the resolver I use does not > validate". IMHO, it changes nothing for DANE (in both cases, the TLSA > records MUST be ignored) but it can be a problem for some persons > (when you publish proper and valid TLSA records, you can never be sure > they will be used). I don't think it is a problem for us. The DANE WG should not be = redefining "insecure" for DNSSEC into two sub-categories. We are given a = definition for "insecure" and we need to use that. --Paul Hoffman From paul.hoffman@vpnc.org Mon Jan 16 08:14:54 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA5C21F8576 for ; Mon, 16 Jan 2012 08:14:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f9mSD4EXP-au for ; Mon, 16 Jan 2012 08:14:54 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id D5E7121F868A for ; Mon, 16 Jan 2012 08:14:53 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q0GGEqKZ028146 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 16 Jan 2012 09:14:53 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20120116101240.GC3140@miek.nl> Date: Mon, 16 Jan 2012 08:14:55 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <59E1FDB4-B832-415A-BEE3-8E85CC55E337@vpnc.org> <20120116101240.GC3140@miek.nl> To: Miek Gieben X-Mailer: Apple Mail (2.1251.1) Cc: dane@ietf.org Subject: Re: [dane] Pseudocode review X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 16:14:54 -0000 On Jan 16, 2012, at 2:12 AM, Miek Gieben wrote: > [ Quoting at 06:46 on Jan 4 in "[dane] = Pseudocode re..." ] >> and will tend to focus on this non-normative appendix rather than the = body >> text. Ilari already found one small error (thanks!), and we would = like >> developer-like folks on the list to poke harder at the section so = that we are >> somewhat confident that everyone understands what the protocol is = doing. >=20 > To pseudo code looks good to me. >=20 > But I do have a question, the line: >=20 > if (Match(matchingType, Select(selectorType, C), R)) { > Finish(2) > } >=20 > Isn't this better? >=20 > if (Match(R.matchingType, Select(R.selectorType, C), R)) { > Finish(2) > } >=20 > It wasn't immediately clear to me where matchingType and selectType = came > from (when just reading the pseudo code). Yes. Based on earlier suggestions, the next draft will have: if ((C passes PKIX validation in H) and Match(R.matchingType, Select(R.selectorType, C), R.cert)) = { Finish(2) --Paul Hoffman From paul.hoffman@vpnc.org Mon Jan 16 08:15:52 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01DCC21F868A for ; Mon, 16 Jan 2012 08:15:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ym5jmIzj+mb2 for ; Mon, 16 Jan 2012 08:15:51 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8633321F8576 for ; Mon, 16 Jan 2012 08:15:51 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q0GGEqKa028146 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 16 Jan 2012 09:15:51 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Paul Hoffman In-Reply-To: Date: Mon, 16 Jan 2012 08:15:53 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: IETF DANE WG list X-Mailer: Apple Mail (2.1251.1) Subject: Re: [dane] EFF's Sovereign Keys X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 16:15:52 -0000 This is not appropriate for the DANE WG list. It is being actively = discussed on the "therightkey" list instead. --Paul Hoffman From rbarnes@bbn.com Mon Jan 16 11:57:33 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88C2E21F86B0 for ; Mon, 16 Jan 2012 11:57:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.7 X-Spam-Level: X-Spam-Status: No, score=-102.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOMvhKKRXc95 for ; Mon, 16 Jan 2012 11:57:32 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6E54E21F86A9 for ; Mon, 16 Jan 2012 11:57:20 -0800 (PST) Received: from [192.1.255.164] (port=49644 helo=col-dhcp-192-1-255-164.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RmsgB-0002va-3v; Mon, 16 Jan 2012 14:57:19 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <4F0DA32D.7070206@ogud.com> Date: Mon, 16 Jan 2012 14:57:18 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> <7A4B9C55-52C3-4A93-9DA7-62F98CF2A6A5@bbn.com> <03EDD353-7C2F-4E2E-911A-117673C94FAF@vpnc.org> <689C663D-4898-4C2D-858C-BE01CA38B666@vpnc.org> <4F0DA32D.7070206@ogud.com> To: Olafur Gudmundsson X-Mailer: Apple Mail (2.1084) Cc: dane@ietf.org Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 19:57:33 -0000 >>=20 >>=20 >=20 >=20 > Richard, > My first reaction in reading you posts was that you are off the > deep end. > After going through the latest draft and your suggested text I think = you have exposed an underspecification in the draft that needs to > be addressed. > Your text does not address the underlying problem. >=20 > Using the example in the tix: > http://trac.tools.ietf.org/wg/dane/trac/ticket/28 >=20 > In case a) > _port._tcp._jabber._tcp.jabber.alice.com IN TLSA > the zone with the SRV record and TLSA is MUST be signed thus > no spoofing possible, if the DNS tree and record validate. >=20 > In case b) > _xmpp-client._tcp.jabber.alice.com IN SRV 5 0 5222 jabber.bob.com. >=20 > The target zone (bob.com) MUST be signed or the DANE client will > NOT accept the TLSA record from it. > The question is is the zone with the SRV/URI/??? > record (alice.com) signed, the current draft is silent on that. >=20 > Case c) is from DNS consistency point is the same as a). >=20 > In reading the document it DOES NOT say that records used to navigate = to the TLSA RRset MUST also be validated. > This causes inconsistency as depending on the DNS traversal to the > TLSA record. >=20 > If the traversal is via NS/CNAME/DNAME records the TLSA RRset will > only be marked as validated if all links in the navigation > chain validate. >=20 > In the case of MX/SRV/NAPTR records there are multiple queries = involved, > and naive TLSA implementation may say "I got validated TLSA that is > good enough for me", opening up the spoofing hole that Richard worries = about. >=20 > My proposal is to add text that explicitly covers records in the DNS = traversal and specify that any record that "points" to the TLSA RRset = MUST also be validated. >=20 > Olafur Hey Olafur, It actually sounds to me like we're more or less on the same page. I = think the distinction that's missing here is between application-layer = redirection, which finds the right name for a service, and DNS-layer = redirection, which finds the records for a name. The discussion above = applies to application-layer redirection, with which I wrongly included = CNAME earlier in the discussion. If I were to summarize your = recommendations above: 1. Application-layer redirection records (MX/SRV/NAPTR/URI/etc) used to = determine the name of a service MAY be DNSSEC-protected. If they are = not, then the client SHOULD use the source name (before redirection); = otherwise it faces spoofing risks. 2. DNS-layer redirection records (NS/CNAME/DNAME) encountered in the = process of a TLSA query MUST all have DNSSEC state "secure". With that in mind, revised proposed text: " A TLSA record is used to make an association between a certificate and a = (domain name, transport protocol, port number) triple where a TLS = service may exist. The resolution of TLSA records under a particular = domain name MUST be secured with DNSSEC at all steps, including any = DNS-layer redirection records, such as NS, CNAME, or DNAME records. Applications using TLSA need to choose carefully which domain names they = use to locate TLSA records, since these domains are trusted to provide = certificate association information; obtaining TLSA information from the = wrong source can lead to clients accepting bogus certificates. = Applications that are seeking to authenticate a specific domain name = SHOULD use that name to locate TLSA records. For example:=20 o An HTTPS client connecting to an HTTP URI would use the name in the = URI [RFC2818] o An SMTP client connecting to an SMTP server would use the name for = the mail domain it is seeking to reach [RFC3207] o An XMPP server connecting to another XMPP server would use the 'to' = address in the initial stream header [RFC6120] In some cases, the name that an application seeks to authenticate is = obtained by the client via a chain of redirection records (e.g., MX, = SRV, NAPTR). When this is the case, it should be noted that if these = redirection records are not protected with DNSSEC, then face the risk = that a spoofed redirection record will cause them to accept bogus = certificates. Thus, if applications encounter redirection chains in = which one or more records are not DNSSEC-protected, then it is = RECOMMENDED that the application locate TLSA records using only (1) the = source domain of any redirection, or (2) target domains of = DNSSEC-protected redirection records. " From lconroy@insensate.co.uk Mon Jan 16 12:28:46 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4746A21F86A8 for ; Mon, 16 Jan 2012 12:28:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LW7vFBD6DZya for ; Mon, 16 Jan 2012 12:28:45 -0800 (PST) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by ietfa.amsl.com (Postfix) with ESMTP id 7230921F869D for ; Mon, 16 Jan 2012 12:28:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id A54EB3F52F1; Mon, 16 Jan 2012 20:28:44 +0000 (GMT) X-Virus-Scanned: amavisd-new at insensate.co.uk Received: from insensate.co.uk ([127.0.0.1]) by localhost (psyche.insensate.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvRnrwbuZZLM; Mon, 16 Jan 2012 20:28:44 +0000 (GMT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id E1BB13F52E5; Mon, 16 Jan 2012 20:28:43 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Lawrence Conroy In-Reply-To: Date: Mon, 16 Jan 2012 20:28:43 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <3868F318-8669-4B97-AFFE-46E0029A4903@insensate.co.uk> References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> <7A4B9C55-52C3-4A93-9DA7-62F98CF2A6A5@bbn.com> <03EDD353-7C2F-4E2E-911A-117673C94FAF@vpnc.org> <689C663D-4898-4C2D-858C-BE01CA38B666@vpnc.org> <4F0DA32D.7070206@ogud.com> To: Richard L. Barnes X-Mailer: Apple Mail (2.1084) Cc: dane@ietf.org Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 20:28:46 -0000 On 16 Jan 2012, at 19:57, Richard L. Barnes wrote: ... > In some cases, the name that an application seeks to authenticate is = obtained by the client via a chain of redirection records (e.g., MX, = SRV, NAPTR). When this is the case, it should be noted that if these = redirection records are not protected with DNSSEC, then face the risk = that a spoofed redirection record will cause them to accept bogus = certificates. Thus, if applications encounter redirection chains in = which one or more records are not DNSSEC-protected, then it is = RECOMMENDED that the application locate TLSA records using only (1) the = source domain of any redirection, or (2) target domains of = DNSSEC-protected redirection records. > " To which I reply: Hi Richard, folks, Your proposed text seems OK-ish (to this tyro), but ... The sentence starting "When this is the case " is long and nested, so = might do with a slight re-structure or breaking out the nesting? Also, it's missing a word or two, IMHO, after "then" -- maybe use "then = clients face"? BTW, perhaps mention SIP in the list of applications above this = paragraph (RFC3263 uses both NAPTR and SRV so it's germane to your = point). Finally, shouldn't the XMPP example say "the domain of the 'to' = address"? all the best, Lawrence From rbarnes@bbn.com Mon Jan 16 12:55:28 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4036221F86D1 for ; Mon, 16 Jan 2012 12:55:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.7 X-Spam-Level: X-Spam-Status: No, score=-102.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6O4fXGPhqzpQ for ; Mon, 16 Jan 2012 12:55:27 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 9E46621F86D0 for ; Mon, 16 Jan 2012 12:55:27 -0800 (PST) Received: from [192.1.255.164] (port=49887 helo=col-dhcp-192-1-255-164.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RmtaK-0005s8-AM; Mon, 16 Jan 2012 15:55:20 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <3868F318-8669-4B97-AFFE-46E0029A4903@insensate.co.uk> Date: Mon, 16 Jan 2012 15:55:16 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> <7A4B9C55-52C3-4A93-9DA7-62F98CF2A6A5@bbn.com> <03EDD353-7C2F-4E2E-911A-117673C94FAF@vpnc.org> <689C663D-4898-4C2D-858C-BE01CA38B666@vpnc.org> <4F0DA32D.7070206@ogud.com> <3868F318-8669-4B97-AFFE-46E0029A4903@insensate.co.uk> To: Lawrence Conroy X-Mailer: Apple Mail (2.1084) Cc: dane@ietf.org Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 20:55:28 -0000 Hey Lawrence, Thanks for the feedback. > ... >> In some cases, the name that an application seeks to authenticate is = obtained by the client via a chain of redirection records (e.g., MX, = SRV, NAPTR). When this is the case, it should be noted that if these = redirection records are not protected with DNSSEC, then face the risk = that a spoofed redirection record will cause them to accept bogus = certificates. Thus, if applications encounter redirection chains in = which one or more records are not DNSSEC-protected, then it is = RECOMMENDED that the application locate TLSA records using only (1) the = source domain of any redirection, or (2) target domains of = DNSSEC-protected redirection records. >> " >=20 > To which I reply: > Hi Richard, folks, > Your proposed text seems OK-ish (to this tyro), but ... > The sentence starting "When this is the case " is long and nested, so = might do with a slight re-structure or breaking out the nesting? > Also, it's missing a word or two, IMHO, after "then" -- maybe use = "then clients face"? Good point, thanks. Revised below. > BTW, perhaps mention SIP in the list of applications above this = paragraph (RFC3263 uses both NAPTR and SRV so it's germane to your = point). Could do. Do you have a good reference to text in 3261/3263 that says = what name to look for in a SIPS handshake? > Finally, shouldn't the XMPP example say "the domain of the 'to' = address"? I was actually just quoting RFC 6120: " o The initiating entity sets the source domain of its reference identifiers to the 'to' address it communicates in the initial stream header; i.e., this is the identity it expects the receiving entity to provide in a PKIX certificate. " But now that you mention it, that text only covers one half of the = mutual authentication. Revised below. Revised suggested text: " A TLSA record is used to make an association between a certificate and a = (domain name, transport protocol, port number) triple where a TLS = service may exist. The resolution of TLSA records under a particular = domain name MUST be secured with DNSSEC at all steps, including any = DNS-layer redirection records, such as NS, CNAME, or DNAME records. Applications using TLSA need to choose carefully which domain names they = use to locate TLSA records, since these domains are trusted to provide = certificate association information; obtaining TLSA information from the = wrong source can lead to clients accepting bogus certificates. = Applications that are seeking to authenticate a specific domain name = SHOULD use that name to locate TLSA records. For example:=20 o An HTTPS client connecting to an HTTP URI would use the name in the = URI [RFC2818] o An SMTP client connecting to an SMTP server would use the name for the = mail domain it is seeking to reach [RFC3207] o An XMPP server initiating a connection to another XMPP server would = use the 'to' address in the initial stream header [RFC6120] In some cases, the name that an application seeks to authenticate is = obtained by the client via a chain of redirection records (e.g., MX, = SRV, NAPTR). If a client accepts redirection records that are not = protected with DNSSEC, then it faces the risk that a spoofed redirection = record will cause it to accept bogus certificates. Thus, if a client = encounters a redirection chain in which one or more records are not = DNSSEC-protected, then it is RECOMMENDED that the application locate = TLSA records using only (1) the source domain of the redirection chain, = or (2) target domains connected to the source entirely by = DNSSEC-protected records. "= From paul.hoffman@vpnc.org Mon Jan 16 13:12:32 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8425B21F86D3 for ; Mon, 16 Jan 2012 13:12:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.62 X-Spam-Level: X-Spam-Status: No, score=-100.62 tagged_above=-999 required=5 tests=[AWL=-1.920, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPt4cjdvwVUr for ; Mon, 16 Jan 2012 13:12:32 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 02E1621F86CB for ; Mon, 16 Jan 2012 13:12:31 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q0GLCEEI039335 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 16 Jan 2012 14:12:15 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Mon, 16 Jan 2012 13:12:16 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <63313B7F-BEA9-46C9-9E86-4E2597988F04@vpnc.org> References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> <7A4B9C55-52C3-4A93-9DA7-62F98CF2A6A5@bbn.com> <03EDD353-7C2F-4E2E-911A-117673C94FAF@vpnc.org> <689C663D-4898-4C2D-858C-BE01CA38B666@vpnc.org> <4F0DA32D.7070206@ogud.com> <3868F318-8669-4B97-AFFE-46E0029A4903@insensate.co.uk> To: "Richard L. Barnes" X-Mailer: Apple Mail (2.1251.1) Cc: IETF DANE WG list Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 21:12:32 -0000 Not that I want you to make your convoluted wording even more = complicated, but it is still unclear. On Jan 16, 2012, at 12:55 PM, Richard L. Barnes wrote: > Revised suggested text: > " > A TLSA record is used to make an association between a certificate and = a (domain name, transport protocol, port number) triple where a TLS = service may exist. The resolution of TLSA records under a particular = domain name MUST be secured with DNSSEC at all steps, including any = DNS-layer redirection records, such as NS, CNAME, or DNAME records. What the heck does the second sentence mean? Why are NS records = considered "DNS-layer redirection records"? How does an application know = whether a DNAME record was used in resolution? I propose that you are well down the rabbit hole. The earlier text I = proposed covers exactly what the first sentence above says it should. --Paul Hoffman From lconroy@insensate.co.uk Mon Jan 16 13:24:54 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D887821F86A9 for ; Mon, 16 Jan 2012 13:24:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.65 X-Spam-Level: X-Spam-Status: No, score=-0.65 tagged_above=-999 required=5 tests=[AWL=-1.950, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nS2HzmrK9uW2 for ; Mon, 16 Jan 2012 13:24:54 -0800 (PST) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by ietfa.amsl.com (Postfix) with ESMTP id 02AF321F86A3 for ; Mon, 16 Jan 2012 13:24:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 582863F5A00; Mon, 16 Jan 2012 21:24:53 +0000 (GMT) X-Virus-Scanned: amavisd-new at insensate.co.uk Received: from insensate.co.uk ([127.0.0.1]) by localhost (psyche.insensate.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JdShv1RwBo5D; Mon, 16 Jan 2012 21:24:52 +0000 (GMT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id BBD693F59F5; Mon, 16 Jan 2012 21:24:52 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Lawrence Conroy In-Reply-To: <63313B7F-BEA9-46C9-9E86-4E2597988F04@vpnc.org> Date: Mon, 16 Jan 2012 21:24:52 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <92349541-ABC0-49CB-A032-1BE0407401FB@insensate.co.uk> References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> <7A4B9C55-52C3-4A93-9DA7-62F98CF2A6A5@bbn.com> <03EDD353-7C2F-4E2E-911A-117673C94FAF@vpnc.org> <689C663D-4898-4C2D-858C-BE01CA38B666@vpnc.org> <4F0DA32D.7070206@ogud.com> <3868F318-8669-4B97-AFFE-46E0029A4903@insensate.co.uk> <63313B7F-BEA9-46C9-9E86-4E2597988F04@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1084) Cc: IETF DANE WG list Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 21:24:54 -0000 Hi there Paul, folks, unless you're addressing the never-ending topic of DNS API (outside = DNSEXT), where did Application come from? To an outsider, Richard's text says that resolution of TLSA records must = handle DNAME/CNAME and so on. The application may not know that, = depending on the API, but something sure should. One might argue that = this is stating the bleedin' obvious, but it might be useful to spell it = out -- implementers may not think this through. As for NS being redirections, well ... you can host parent and child = domains on the same server set, if you like a whole world of obscure = pain. Otherwise, the zone cut does reflect a real cut, with potential = for further queries -- purely within DNS level processing. The = application won't see that, but I don't think Richard's text doesn't say = that. Does it? all the best, Lawrence On 16 Jan 2012, at 21:12, Paul Hoffman wrote: > Not that I want you to make your convoluted wording even more = complicated, but it is still unclear. >=20 > On Jan 16, 2012, at 12:55 PM, Richard L. Barnes wrote: >=20 >> Revised suggested text: >> " >> A TLSA record is used to make an association between a certificate = and a (domain name, transport protocol, port number) triple where a TLS = service may exist. The resolution of TLSA records under a particular = domain name MUST be secured with DNSSEC at all steps, including any = DNS-layer redirection records, such as NS, CNAME, or DNAME records. >=20 > What the heck does the second sentence mean? Why are NS records = considered "DNS-layer redirection records"? How does an application know = whether a DNAME record was used in resolution? >=20 > I propose that you are well down the rabbit hole. The earlier text I = proposed covers exactly what the first sentence above says it should. >=20 > --Paul Hoffman >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From paul.hoffman@vpnc.org Mon Jan 16 13:51:50 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56C8221F86BE for ; Mon, 16 Jan 2012 13:51:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BI9p2QHqfrEQ for ; Mon, 16 Jan 2012 13:51:49 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id DBF2121F8694 for ; Mon, 16 Jan 2012 13:51:47 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q0GLpieE040506 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 16 Jan 2012 14:51:45 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <92349541-ABC0-49CB-A032-1BE0407401FB@insensate.co.uk> Date: Mon, 16 Jan 2012 13:51:46 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3704341F-E614-44A1-A4C2-194655B2136B@vpnc.org> References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> <7A4B9C55-52C3-4A93-9DA7-62F98CF2A6A5@bbn.com> <03EDD353-7C2F-4E2E-911A-117673C94FAF@vpnc.org> <689C663D-4898-4C2D-858C-BE01CA38B666@vpnc.org> <4F0DA32D.7070206@ogud.com> <3868F318-8669-4B97-AFFE-46E0029A4903@insensate.co.uk> <63313B7F-BEA9-46C9-9E86-4E2597988F04@vpnc.org> <92349541-ABC0-49CB-A032-1BE0407401FB@insensate.co.uk> To: Lawrence Conroy X-Mailer: Apple Mail (2.1251.1) Cc: IETF DANE WG list Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 21:51:50 -0000 On Jan 16, 2012, at 1:24 PM, Lawrence Conroy wrote: > Hi there Paul, folks, > unless you're addressing the never-ending topic of DNS API (outside = DNSEXT), where did Application come from? The document talks about how applications make certificate associations. = Issue #28 is specifically about application protocols that require an = application to go through at least one round trip in the DNS to get the = name of the host they want to contact. > To an outsider, Richard's text says that resolution of TLSA records = must handle DNAME/CNAME and so on. The application may not know that, = depending on the API, but something sure should. One might argue that = this is stating the bleedin' obvious, but it might be useful to spell it = out -- implementers may not think this through. I was, in fact, asking Richard to spell it out. My purpose is to show = how far down the rabbit hole he has gone with his proposal. > As for NS being redirections, well ... you can host parent and child = domains on the same server set, if you like a whole world of obscure = pain. Otherwise, the zone cut does reflect a real cut, with potential = for further queries -- purely within DNS level processing. The = application won't see that, but I don't think Richard's text doesn't say = that. Does it? Richard's most recent proposal equates NS records with CNAME and DNAME = records, calling them all "DNS-layer redirection". Many of us would find = that equating difficult to understand. I suspect he was just being = sloppy and didn't really mean it, but I want to be sure. --Paul Hoffman From ogud@ogud.com Mon Jan 16 14:10:35 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D347F21F869D for ; Mon, 16 Jan 2012 14:10:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lba8eISSA16y for ; Mon, 16 Jan 2012 14:10:35 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id B8F9621F868C for ; Mon, 16 Jan 2012 14:10:34 -0800 (PST) Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id q0GMAOUk079531; Mon, 16 Jan 2012 17:10:25 -0500 (EST) (envelope-from ogud@ogud.com) Message-ID: <4F14A04E.8040104@ogud.com> Date: Mon, 16 Jan 2012 17:10:22 -0500 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Richard L. Barnes" References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> <7A4B9C55-52C3-4A93-9DA7-62F98CF2A6A5@bbn.com> <03EDD353-7C2F-4E2E-911A-117673C94FAF@vpnc.org> <689C663D-4898-4C2D-858C-BE01CA38B666@vpnc.org> <4F0DA32D.7070206@ogud.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: dane@ietf.org Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 22:10:35 -0000 Richard we are close but there nits we do not agree on. see in-line below. On 16/01/2012 14:57, Richard L. Barnes wrote: >>> >>> >> >> >> Richard, >> My first reaction in reading you posts was that you are off the >> deep end. >> After going through the latest draft and your suggested text I think you have exposed an underspecification in the draft that needs to >> be addressed. >> Your text does not address the underlying problem. >> >> Using the example in the tix: >> http://trac.tools.ietf.org/wg/dane/trac/ticket/28 >> >> In case a) >> _port._tcp._jabber._tcp.jabber.alice.com IN TLSA >> the zone with the SRV record and TLSA is MUST be signed thus >> no spoofing possible, if the DNS tree and record validate. >> >> In case b) >> _xmpp-client._tcp.jabber.alice.com IN SRV 5 0 5222 jabber.bob.com. >> >> The target zone (bob.com) MUST be signed or the DANE client will >> NOT accept the TLSA record from it. >> The question is is the zone with the SRV/URI/??? >> record (alice.com) signed, the current draft is silent on that. >> >> Case c) is from DNS consistency point is the same as a). >> >> In reading the document it DOES NOT say that records used to navigate to the TLSA RRset MUST also be validated. >> This causes inconsistency as depending on the DNS traversal to the >> TLSA record. >> >> If the traversal is via NS/CNAME/DNAME records the TLSA RRset will >> only be marked as validated if all links in the navigation >> chain validate. >> >> In the case of MX/SRV/NAPTR records there are multiple queries involved, >> and naive TLSA implementation may say "I got validated TLSA that is >> good enough for me", opening up the spoofing hole that Richard worries about. >> >> My proposal is to add text that explicitly covers records in the DNS traversal and specify that any record that "points" to the TLSA RRset MUST also be validated. >> >> Olafur > > Hey Olafur, > > It actually sounds to me like we're more or less on the same page. I think the distinction that's missing here is between application-layer redirection, which finds the right name for a service, and DNS-layer redirection, which finds the records for a name. The discussion above applies to application-layer redirection, with which I wrongly included CNAME earlier in the discussion. If I were to summarize your recommendations above: > > 1. Application-layer redirection records (MX/SRV/NAPTR/URI/etc) used to determine the name of a service MAY be DNSSEC-protected. If they are not, then the client SHOULD use the source name (before redirection); otherwise it faces spoofing risks. s/MAY/MUST/ If the source name is not DNSSEC protected why follow application-layer redirection records that can be spoofed? > 2. DNS-layer redirection records (NS/CNAME/DNAME) encountered in the process of a TLSA query MUST all have DNSSEC state "secure". > There is only one case: All records used to navigate to the TLSA record MUST be validated as well as the TLSA record. Olafur From rbarnes@bbn.com Mon Jan 16 14:21:59 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACCF321F86A9 for ; Mon, 16 Jan 2012 14:21:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.65 X-Spam-Level: X-Spam-Status: No, score=-104.65 tagged_above=-999 required=5 tests=[AWL=1.950, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4-LsrkrUhoz for ; Mon, 16 Jan 2012 14:21:59 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2E82F21F86A4 for ; Mon, 16 Jan 2012 14:21:59 -0800 (PST) Received: from [192.1.255.164] (port=50231 helo=col-dhcp-192-1-255-164.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RmuwA-00075p-Fm; Mon, 16 Jan 2012 17:21:58 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <4F14A04E.8040104@ogud.com> Date: Mon, 16 Jan 2012 17:21:57 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> <7A4B9C55-52C3-4A93-9DA7-62F98CF2A6A5@bbn.com> <03EDD353-7C2F-4E2E-911A-117673C94FAF@vpnc.org> <689C663D-4898-4C2D-858C-BE01CA38B666@vpnc.org> <4F0DA32D.7070206@ogud.com> <4F14A04E.8040104@ogud.com> To: Olafur Gudmundsson X-Mailer: Apple Mail (2.1084) Cc: dane@ietf.org Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 22:21:59 -0000 >> 1. Application-layer redirection records (MX/SRV/NAPTR/URI/etc) used = to determine the name of a service MAY be DNSSEC-protected. If they are = not, then the client SHOULD use the source name (before redirection); = otherwise it faces spoofing risks. > s/MAY/MUST/ > If the source name is not DNSSEC protected why follow = application-layer redirection records that can be spoofed? Well, the source name is the name *before* you go to the DNS. So the = idea of a "DNSSEC-protected source name" doesn't really parse. For = example, suppose you get the following SRV without DNSSEC: _foo._tcp.alice.com SRV foo.bob.com 1234 The source is "alice.com" or "_foo._tcp.alice.com" and the target is = "foo.bob.com". If you're going to look up TLSA under alice.com (with = DNSSEC on NS, CNAME, etc.), then there's no risk. OTOH, if you look up = TLSA under foo.bob.com (even with DNSSEC), then you could be screwed by = a spoofed SRV. >> 2. DNS-layer redirection records (NS/CNAME/DNAME) encountered in the = process of a TLSA query MUST all have DNSSEC state "secure". >>=20 >=20 > There is only one case: All records used to navigate to the TLSA = record MUST be validated as well as the TLSA record. That's basically what I'm saying -- if you get something non-DNSSEC, = ignore it and only use what you found securely. The difference between = this and Paul's proposed text is that Paul doesn't even allow you to use = what you got securely; he would terminate processing entirely if = anything non-secure was found. --Richard From cloos@jhcloos.com Mon Jan 16 14:34:25 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9F021F86C8 for ; Mon, 16 Jan 2012 14:34:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.844 X-Spam-Level: X-Spam-Status: No, score=-1.844 tagged_above=-999 required=5 tests=[AWL=0.756, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lPDPhh+jEguJ for ; Mon, 16 Jan 2012 14:34:24 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by ietfa.amsl.com (Postfix) with ESMTP id C810C21F85FF for ; Mon, 16 Jan 2012 14:34:23 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id A663040105; Mon, 16 Jan 2012 22:33:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1326753260; bh=eQi1ZOPNxmrVDs3pvlL5hnDU7V13hsaD2ZfAbHEpJNg=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=L75OP+FSljTOeiE+JxXGwPw+7i+DK/tB6C0Qd6sSVIdDrJbXTcmZIJ77IF7/l/vpE FVlyl4/U3JK8+RXe3YO/ThBP//yk2OQ2A1JWOP9heqHnjtjjW1J/d/H27degNY8DfH w90n2HGm98IXz0k6alYZ9IK6VMRlZ3pDbmeSQa/s= Received: by carbon.jhcloos.org (Postfix, from userid 500) id BB80536004C; Mon, 16 Jan 2012 22:25:53 +0000 (UTC) From: James Cloos To: dane@ietf.org In-Reply-To: (Richard L. Barnes's message of "Mon, 16 Jan 2012 14:57:18 -0500") References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> <7A4B9C55-52C3-4A93-9DA7-62F98CF2A6A5@bbn.com> <03EDD353-7C2F-4E2E-911A-117673C94FAF@vpnc.org> <689C663D-4898-4C2D-858C-BE01CA38B666@vpnc.org> <4F0DA32D.7070206@ogud.com> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.92 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2011 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Mon, 16 Jan 2012 17:25:53 -0500 Message-ID: Lines: 38 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:120116:dane@ietf.org::+c3AEQChvGfIRGRZ:000YE6GZ X-Hashcash: 1:30:120116:rbarnes@bbn.com::wUDmgnNZ/Dbv4PaZ:0RyC2t X-Hashcash: 1:30:120116:ogud@ogud.com::Z+pBg67hsbcOU6Tb:000Eh2NW Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 22:34:25 -0000 >>>>> "RLB" == Richard L Barnes writes: RLB> o An SMTP client connecting to an SMTP server would use the RLB> name for the mail domain it is seeking to reach [RFC3207] That is still wrong. An MX should not have to have certs -- or alternate names in one cert -- for every domain for hostname for which it accepts incoming mail. The overhead is excessive and unworkable. Not to mention that there is, in general, no "tcp port 25" associated with the right-hand-side of the email address. The TLSA lookup MUST be on the result of the MX lookup. It simply cannot be done any other way. The client should note whether the MX lookup is verified secure (including the case where there is no MX RR) and take that into consideration when determining the security of the email delivery. Given an email address such as foo@example.org, a TLSA-like lookup for, say, _smtp._tcp.example.org. MIGHT be an acceptable, additional check. But if done the client should not expect the cert to include example.org in its CN or alternate name unless example.org. MX pointed to a server w/in example.org. We should not try to make things work worse than they do now. It is perfectly reasonable and secure for an MX with one name to accept mail for several seemingly unrelated domains and sub-domains. A secure MX lookup combined with secure TLSA and A/AAAA lookups and a matching TLS certificate *is* sufficiently secure. MTAs probably SHOULD keep note of secure destinations and complain when that security is lost. But expecting MXs to certify every zone for which they accept incoming mail will not work. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From mrex@sap.com Mon Jan 16 15:16:50 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A03C21F86BB for ; Mon, 16 Jan 2012 15:16:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.01 X-Spam-Level: X-Spam-Status: No, score=-10.01 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJqiSri7VjXF for ; Mon, 16 Jan 2012 15:16:49 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3A86E21F86AF for ; Mon, 16 Jan 2012 15:16:48 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q0GNGjbY029170 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 17 Jan 2012 00:16:45 +0100 (MET) From: Martin Rex Message-Id: <201201162316.q0GNGjjT000216@fs4113.wdf.sap.corp> To: cloos@jhcloos.com (James Cloos) Date: Tue, 17 Jan 2012 00:16:45 +0100 (MET) In-Reply-To: from "James Cloos" at Jan 16, 12 05:25:53 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 23:16:50 -0000 James Cloos wrote: > > >>>>> "RLB" == Richard L Barnes writes: > > RLB> o An SMTP client connecting to an SMTP server would use the > RLB> name for the mail domain it is seeking to reach [RFC3207] > > That is still wrong. An MX should not have to have certs -- or > alternate names in one cert -- for every domain for hostname for > which it accepts incoming mail. The overhead is excessive and > unworkable. Not to mention that there is, in general, no "tcp > port 25" associated with the right-hand-side of the email address. > > The TLSA lookup MUST be on the result of the MX lookup. It > simply cannot be done any other way. I'm just the opposite. The TLSA lookup MUST be on the SOURCE (=EMail domain), doing it any other way is going to be a real security problem. When the SMTP client intends to deliver EMail to johndoe@niceguy.tv then checking whether the server someserver.evilattacker.tv has a server certificate for someserver.evilattacker.tv is a pretty useless check, and entirely unrelated to the original problem "which transport agent to trust for an EMail to @niceguy.tv" then there are two conceivable reasonable checks: a) traditional PKIX-style: check whether the server determined by A/MX lookups has been officially authorized to serve/receive EMail for @niceguy.tv b) DANE-style: check whether a _smtp._tcp.niceguy.tv TLSA record exits that authorizes the certificate presented by the server as authorized to serve/receive EMail for @niceguy.tv There is another unrelated problem: (Local) Smart Mail Relays. The server endpoint identification of Smart Mail Relays is an entirely different story, because it is independent from the EMail address of the target recipient, and the configuration parameter that is used to name the smart relay needs to be extended with a parameter that can be used to match the certificate of the Smart Mail Relay. > > We should not try to make things work worse than they do now. The current scheme for mta->mta SMTP-AUTH is a complete lack of authentication. That part can not get any worse. -Martin From rbarnes@bbn.com Mon Jan 16 15:28:43 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8BE21F86DF for ; Mon, 16 Jan 2012 15:28:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.299 X-Spam-Level: X-Spam-Status: No, score=-105.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vT90guHxPqdb for ; Mon, 16 Jan 2012 15:28:42 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3E76121F85EF for ; Mon, 16 Jan 2012 15:28:40 -0800 (PST) Received: from [192.1.255.164] (port=50412 helo=col-dhcp-192-1-255-164.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Rmvyh-0007hV-5g; Mon, 16 Jan 2012 18:28:39 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Mon, 16 Jan 2012 18:28:37 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> <7A4B9C55-52C3-4A93-9DA7-62F98CF2A6A5@bbn.com> <03EDD353-7C2F-4E2E-911A-117673C94FAF@vpnc.org> <689C663D-4898-4C2D-858C-BE01CA38B666@vpnc.org> <4F0DA32D.7070206@ogud.com> To: James Cloos X-Mailer: Apple Mail (2.1084) Cc: dane@ietf.org Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 23:28:43 -0000 >>>>>> "RLB" =3D=3D Richard L Barnes writes: >=20 > RLB> o An SMTP client connecting to an SMTP server would use the > RLB> name for the mail domain it is seeking to reach [RFC3207] >=20 > That is still wrong. An MX should not have to have certs -- or > alternate names in one cert -- for every domain for hostname for > which it accepts incoming mail. The overhead is excessive and > unworkable. Not to mention that there is, in general, no "tcp > port 25" associated with the right-hand-side of the email address. The above quote is almost direct from RFC 3207, so if there's = brokenness, look there. =20 > The TLSA lookup MUST be on the result of the MX lookup. It > simply cannot be done any other way. You can do that, but if there's not DNSSEC on the MX, then you're = vulnerable to spoofing on the MX. Just sayin'. --Richard= From cloos@jhcloos.com Mon Jan 16 16:13:05 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C83421F86A5 for ; Mon, 16 Jan 2012 16:13:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.952 X-Spam-Level: X-Spam-Status: No, score=-1.952 tagged_above=-999 required=5 tests=[AWL=0.648, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DwOwUDnne+OZ for ; Mon, 16 Jan 2012 16:13:04 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by ietfa.amsl.com (Postfix) with ESMTP id 4B2BD21F860B for ; Mon, 16 Jan 2012 16:13:04 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 595AD400A4; Tue, 17 Jan 2012 00:12:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1326759182; bh=zaVvpKSyDyNADMx+tpq5IVH4SqH5OCPnwW9V8MOlDEE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=wZM+sSXjE0uKOrSytZmvtveJNfaKGQGpS9CqnQb1CpPIK2pf841lNyQ9ECUKjLHk4 et9LTicrUcXvLZsjyahmEwscqKWRNpByvVKIHiZXNqE7N7GcSlF+cp1qzqoTnRdm91 XTqL4CtBmJbuD2dbbraXLXnuO6jIDXBbS4lJ+boY= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 79EF436004C; Tue, 17 Jan 2012 00:00:32 +0000 (UTC) From: James Cloos To: dane@ietf.org In-Reply-To: <201201162316.q0GNGjjT000216@fs4113.wdf.sap.corp> (Martin Rex's message of "Tue, 17 Jan 2012 00:16:45 +0100 (MET)") References: <201201162316.q0GNGjjT000216@fs4113.wdf.sap.corp> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.92 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2011 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Mon, 16 Jan 2012 19:00:32 -0500 Message-ID: Lines: 34 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:120117:dane@ietf.org::LhbeBz9gGlxXqV8X:000oezly X-Hashcash: 1:30:120117:mrex@sap.com::3k4dFLe9cWi+igIW:00007jgyT Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 00:13:05 -0000 >>>>> "MR" == Martin Rex writes: MR> The TLSA lookup MUST be on the SOURCE (=EMail domain), doing it any MR> other way is going to be a real security problem. As I wrote, that will not work in practice. Secure delivery from MTA to MTA does require that all of the DNS lookups are secure. If the MX lookup is verified (if there is no MX for the given right-hand-side, a verified does-not-exist result will do) secure, and the TLSA and A/AAAA lookups on the result of the MX lookup are also verified secure, and the TLS cert matches the TLSA RR, and the TLS crypto is done right, then that MTA->MTA delivery is full-path secure. Every step is secure and verified; therefore that step of delivery is secure and verified. Putting the TLSA lookup before the MX lookup does not add any security. One may even argue that it harms security, since it allows an attacker to get the full list of target email domains from an MTA simply by asking the MTA for its cert. I don't know whether I'd make the argument that that might harm security, but one could and I'm sure that some will. The zone matching the r-h-s needs to be protected by dnssec either way, as must the zone containing the result of the MX lookup. The TLSA RR is keyed to a port number, not a service name. [I need to leave for food; I'll send this now rather than come back to it after.] -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From cloos@jhcloos.com Mon Jan 16 16:14:17 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4149821F860B for ; Mon, 16 Jan 2012 16:14:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.033 X-Spam-Level: X-Spam-Status: No, score=-2.033 tagged_above=-999 required=5 tests=[AWL=0.567, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ud74i2nlWYI4 for ; Mon, 16 Jan 2012 16:14:16 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by ietfa.amsl.com (Postfix) with ESMTP id A113721F85BB for ; Mon, 16 Jan 2012 16:14:16 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id F33B2400A4; Tue, 17 Jan 2012 00:13:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1326759256; bh=V264rcnALLL5uSEODCWa74O2FNB+rEfzVGmLK4ppWUQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=jd0YpL2Aak/V3ph1o/56fMoo1Fn+G50DvvD/iVdCAliQE5f3e3euapfb4oQ3FDPrq npUZkB0c/e6H+8or0SM0cPA4bS3AAfSYL1zD7x4ZxWt7kcMeSrH+JYlGGX4igUPUJj uVdzpKsyvDvFp6UZkqemCAxqjWqY5InsVkF9e1j8= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 0A88436004E; Tue, 17 Jan 2012 00:02:58 +0000 (UTC) From: James Cloos To: "Richard L. Barnes" In-Reply-To: (Richard L. Barnes's message of "Mon, 16 Jan 2012 18:28:37 -0500") References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> <7A4B9C55-52C3-4A93-9DA7-62F98CF2A6A5@bbn.com> <03EDD353-7C2F-4E2E-911A-117673C94FAF@vpnc.org> <689C663D-4898-4C2D-858C-BE01CA38B666@vpnc.org> <4F0DA32D.7070206@ogud.com> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.92 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2011 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Mon, 16 Jan 2012 19:02:58 -0500 Message-ID: Lines: 12 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:120117:rbarnes@bbn.com::j0Qx5dnLOp3Oir2H:01dbRH X-Hashcash: 1:30:120117:dane@ietf.org::FOuI9uxf8kZoCtmt:000VGAXd X-Hashcash: 1:30:120117:ogud@ogud.com::VSeyZ2IrbjxeuaH3:000wCuzP Cc: dane@ietf.org Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 00:14:17 -0000 >>>>> "RLB" == Richard L Barnes writes: RLB> You can do that, but if there's not DNSSEC on the MX, then you're RLB> vulnerable to spoofing on the MX. Just sayin'. If there is no dnssec on the MX, there also would be no dnssec on any tlsa-like lookup on email address and the whole thing is insecure anyway. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From mrex@sap.com Mon Jan 16 16:32:53 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 064B221F86BE for ; Mon, 16 Jan 2012 16:32:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.025 X-Spam-Level: X-Spam-Status: No, score=-10.025 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NeZxcL3j4ygy for ; Mon, 16 Jan 2012 16:32:52 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7B921F86BB for ; Mon, 16 Jan 2012 16:32:51 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q0H0WhBS004947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 17 Jan 2012 01:32:48 +0100 (MET) From: Martin Rex Message-Id: <201201170032.q0H0Wg3A004508@fs4113.wdf.sap.corp> To: cloos@jhcloos.com (James Cloos) Date: Tue, 17 Jan 2012 01:32:42 +0100 (MET) In-Reply-To: from "James Cloos" at Jan 16, 12 07:00:32 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 00:32:53 -0000 James Cloos wrote: > >Martin Rex wrote: >> >> The TLSA lookup MUST be on the SOURCE (=EMail domain), doing it any >> other way is going to be a real security problem. > > Secure delivery from MTA to MTA does require that all of the DNS lookups > are secure. That is a non-starter. We really need to make SMTP authentication work long before we get 100% DNSSEC coverage (which may never happen). HTTP(S) has no dependency on DNSSEC and XMPP has no depedency on DNSSEC, they can both work with PKIX alone. The SMTP authentication should be fixed independently of DNSSEC. > > The TLSA RR is keyed to a port number, not a service name. Yes, but only if there is no DNS-based service indirection. I would strongly recommend to use symbolic service names for TLSA lookup whenever service discovery is being used (MX for SMTP, SRV for XMPP). MX is a kind of subset of SRV because it can not change the tcp port (25). And since XMPP uses SRV already, I would really appreciate when the use of a symbolic service name for TLSA lookups would be defined/standardized in the current protocol document (for SRV and MX). -Martin From fanf2@hermes.cam.ac.uk Mon Jan 16 16:35:15 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0A3921F86CF for ; Mon, 16 Jan 2012 16:35:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.134 X-Spam-Level: X-Spam-Status: No, score=-6.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kRUvYkJJi6fp for ; Mon, 16 Jan 2012 16:35:15 -0800 (PST) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id ED83B21F86BE for ; Mon, 16 Jan 2012 16:35:14 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:38594) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1Rmx10-0001E2-rY (Exim 4.72) (return-path ); Tue, 17 Jan 2012 00:35:06 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Rmx10-00054R-HG (Exim 4.67) (return-path ); Tue, 17 Jan 2012 00:35:06 +0000 Date: Tue, 17 Jan 2012 00:35:06 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: "Richard L. Barnes" In-Reply-To: Message-ID: References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> <7A4B9C55-52C3-4A93-9DA7-62F98CF2A6A5@bbn.com> <03EDD353-7C2F-4E2E-911A-117673C94FAF@vpnc.org> <689C663D-4898-4C2D-858C-BE01CA38B666@vpnc.org> <4F0DA32D.7070206@ogud.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dane@ietf.org Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 00:35:16 -0000 Richard L. Barnes wrote: > >>>>>> "RLB" == Richard L Barnes writes: > > > > RLB> o An SMTP client connecting to an SMTP server would use the > > RLB> name for the mail domain it is seeking to reach [RFC3207] > > > > That is still wrong. An MX should not have to have certs -- or > > alternate names in one cert -- for every domain for hostname for > > which it accepts incoming mail. The overhead is excessive and > > unworkable. Not to mention that there is, in general, no "tcp > > port 25" associated with the right-hand-side of the email address. > > The above quote is almost direct from RFC 3207, so if there's > brokenness, look there. I think the text you are referring to is: - A SMTP client would probably only want to authenticate an SMTP server whose server certificate has a domain name that is the domain name that the client thought it was connecting to. RFC 3207 does not make a clear distinction between host name and mail domain, nor between mx owner and mx target. The consensus (arising from several discussions on this topic over the years) is that SMTP server authentication should be based on the server host name (i.e. MX target) rather than the mail domain. Tony. -- f.anthony.n.finch http://dotat.at/ South Utsire: Mainly southwesterly 3 or 4. Slight or moderate. Fair. Good. From fanf2@hermes.cam.ac.uk Mon Jan 16 16:36:41 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A777A21F86CF for ; Mon, 16 Jan 2012 16:36:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.227 X-Spam-Level: X-Spam-Status: No, score=-6.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hp8ZtPMTSIQG for ; Mon, 16 Jan 2012 16:36:41 -0800 (PST) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by ietfa.amsl.com (Postfix) with ESMTP id 1BFA121F86BE for ; Mon, 16 Jan 2012 16:36:41 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:32978) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1Rmx2V-0001Mg-Du (Exim 4.72) (return-path ); Tue, 17 Jan 2012 00:36:39 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Rmx2V-0005JO-8e (Exim 4.67) (return-path ); Tue, 17 Jan 2012 00:36:39 +0000 Date: Tue, 17 Jan 2012 00:36:39 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Martin Rex In-Reply-To: <201201170032.q0H0Wg3A004508@fs4113.wdf.sap.corp> Message-ID: References: <201201170032.q0H0Wg3A004508@fs4113.wdf.sap.corp> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dane@ietf.org Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 00:36:41 -0000 Martin Rex wrote: > > That is a non-starter. We really need to make SMTP authentication > work long before we get 100% DNSSEC coverage (which may never happen). This isn't the right working group for that discussion. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty, Forth: Southwest 4 or 5, occasionally 6, backing south 6 or 7 later. Slight or moderate. Fair. Moderate or good. From mrex@sap.com Mon Jan 16 16:50:03 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40AFD21F84E0 for ; Mon, 16 Jan 2012 16:50:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.038 X-Spam-Level: X-Spam-Status: No, score=-10.038 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mz0ZSmDMXsmv for ; Mon, 16 Jan 2012 16:50:02 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 17BFC21F84DC for ; Mon, 16 Jan 2012 16:50:01 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q0H0nr15029138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 17 Jan 2012 01:49:53 +0100 (MET) From: Martin Rex Message-Id: <201201170049.q0H0nqX3005806@fs4113.wdf.sap.corp> To: dot@dotat.at (Tony Finch) Date: Tue, 17 Jan 2012 01:49:52 +0100 (MET) In-Reply-To: from "Tony Finch" at Jan 17, 12 00:35:06 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 00:50:03 -0000 Tony Finch wrote: > > Richard L. Barnes wrote: > > >>>>>> "RLB" == Richard L Barnes writes: > > > > > > RLB> o An SMTP client connecting to an SMTP server would use the > > > RLB> name for the mail domain it is seeking to reach [RFC3207] > > > > > > That is still wrong. An MX should not have to have certs -- or > > > alternate names in one cert -- for every domain for hostname for > > > which it accepts incoming mail. The overhead is excessive and > > > unworkable. Not to mention that there is, in general, no "tcp > > > port 25" associated with the right-hand-side of the email address. > > > > The above quote is almost direct from RFC 3207, so if there's > > brokenness, look there. > > I think the text you are referring to is: > > - A SMTP client would probably only want to authenticate an SMTP > server whose server certificate has a domain name that is the > domain name that the client thought it was connecting to. > > RFC 3207 does not make a clear distinction between host name and mail > domain, nor between mx owner and mx target. "domain name" in that 3207 text very clearly refers to the EMail address, because it is described as a tail match. If it was meant to be a server name match, that match would be an exact match (rfc2818 3.1 server endpoint identification) plus there would be a requirement for DNSSEC on the MX lookup. > > The consensus (arising from several discussions on this topic over the > years) is that SMTP server authentication should be based on the server > host name (i.e. MX target) rather than the mail domain. That is completely bogus and needs to be discontinued. -Martin From marka@isc.org Mon Jan 16 18:42:28 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EDDA21F8598 for ; Mon, 16 Jan 2012 18:42:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HiNetwZKyv2z for ; Mon, 16 Jan 2012 18:42:27 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id ACF1221F858E for ; Mon, 16 Jan 2012 18:42:27 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 194F5C9422; Tue, 17 Jan 2012 02:42:14 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:7db4:152d:79c6:de25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id C577C216C6B; Tue, 17 Jan 2012 02:42:13 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 9F0141B7A8AE; Tue, 17 Jan 2012 13:42:11 +1100 (EST) To: mrex@sap.com From: Mark Andrews References: <201201170049.q0H0nqX3005806@fs4113.wdf.sap.corp> In-reply-to: Your message of "Tue, 17 Jan 2012 01:49:52 BST." <201201170049.q0H0nqX3005806@fs4113.wdf.sap.corp> Date: Tue, 17 Jan 2012 13:42:11 +1100 Message-Id: <20120117024211.9F0141B7A8AE@drugs.dv.isc.org> Cc: dane@ietf.org Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 02:42:28 -0000 In message <201201170049.q0H0nqX3005806@fs4113.wdf.sap.corp>, Martin Rex writes : > Tony Finch wrote: > > > > Richard L. Barnes wrote: > > > >>>>>> "RLB" == Richard L Barnes writes: > > > > > > > > RLB> o An SMTP client connecting to an SMTP server would use the > > > > RLB> name for the mail domain it is seeking to reach [RFC3207] > > > > > > > > That is still wrong. An MX should not have to have certs -- or > > > > alternate names in one cert -- for every domain for hostname for > > > > which it accepts incoming mail. The overhead is excessive and > > > > unworkable. Not to mention that there is, in general, no "tcp > > > > port 25" associated with the right-hand-side of the email address. > > > > > > The above quote is almost direct from RFC 3207, so if there's > > > brokenness, look there. > > > > I think the text you are referring to is: > > > > - A SMTP client would probably only want to authenticate an SMTP > > server whose server certificate has a domain name that is the > > domain name that the client thought it was connecting to. > > > > RFC 3207 does not make a clear distinction between host name and mail > > domain, nor between mx owner and mx target. > > "domain name" in that 3207 text very clearly refers to the EMail address, > because it is described as a tail match. > > If it was meant to be a server name match, that match would be an > exact match (rfc2818 3.1 server endpoint identification) plus there > would be a requirement for DNSSEC on the MX lookup. No. It is because MX records are out-of-scope for RFC3207. RFC3207 describes what happens *after* a connection has been made not before. If I have a MX record that says "connect to mail.server.example.net" and I lookup the addresses for mail.server.example.net then I expect to connect to mail.server.example.net. If I have a client is configured to forward all mail to another server as is done with smart host configurations or submission the server you need to verify is the smart host / submission server not the target of a MX record nor the RHS of the email address. This logic goes all the way back to RFC 821. 3.5. OPENING AND CLOSING At the time the transmission channel is opened there is an exchange to ensure that the hosts are communicating with the hosts they think they are. Mark > > The consensus (arising from several discussions on this topic over the > > years) is that SMTP server authentication should be based on the server > > host name (i.e. MX target) rather than the mail domain. > > > That is completely bogus and needs to be discontinued. > > > -Martin > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From mrex@sap.com Mon Jan 16 19:00:14 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 356D321F85CE for ; Mon, 16 Jan 2012 19:00:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.05 X-Spam-Level: X-Spam-Status: No, score=-10.05 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k71CHzxnlj0y for ; Mon, 16 Jan 2012 19:00:13 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 5485C21F85CD for ; Mon, 16 Jan 2012 19:00:13 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q0H30APe012474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 17 Jan 2012 04:00:10 +0100 (MET) From: Martin Rex Message-Id: <201201170300.q0H3093u013188@fs4113.wdf.sap.corp> To: marka@isc.org (Mark Andrews) Date: Tue, 17 Jan 2012 04:00:09 +0100 (MET) In-Reply-To: <20120117024211.9F0141B7A8AE@drugs.dv.isc.org> from "Mark Andrews" at Jan 17, 12 01:42:11 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 03:00:14 -0000 Mark Andrews wrote: > > Martin Rex writes: > > > > Tony Finch wrote: > > > > > > I think the text you are referring to is: > > > > > > - A SMTP client would probably only want to authenticate an SMTP > > > server whose server certificate has a domain name that is the > > > domain name that the client thought it was connecting to. > > > > > > RFC 3207 does not make a clear distinction between host name and mail > > > domain, nor between mx owner and mx target. > > > > "domain name" in that 3207 text very clearly refers to the EMail address, > > because it is described as a tail match. > > > > If it was meant to be a server name match, that match would be an > > exact match (rfc2818 3.1 server endpoint identification) plus there > > would be a requirement for DNSSEC on the MX lookup. > > No. It is because MX records are out-of-scope for RFC3207. RFC3207 > describes what happens *after* a connection has been made not before. If MX-records are out-of-scope, then there is only the EMail address left for which the above text suggests a tail match. > > If I have a MX record that says "connect to mail.server.example.net" > and I lookup the addresses for mail.server.example.net then I expect > to connect to mail.server.example.net. This is clearly bogus if you want security, rather than only sprinkling magic encryption pixie dust on the connection. > > If I have a client is configured to forward all mail to another > server as is done with smart host configurations or submission the > server you need to verify is the smart host / submission server not > the target of a MX record nor the RHS of the email address. As I wrote in a previous EMail, the local(!) configuration that provides the hostname of the smart relay will have to provide the reference for matching the identity of the smart relay (because this is unrelated to the EMail address). But for delivering EMails to their target domain, matching the certificate of the server to the target of the MX record just doesn't make sense security-wise (notwithstanding that this is what is being done if SMTP is delivering EMail insecurely in rfc821 fashion). -Martin From marka@isc.org Mon Jan 16 20:59:00 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B286C21F84DD for ; Mon, 16 Jan 2012 20:59:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sASnaVOZWk5Q for ; Mon, 16 Jan 2012 20:58:59 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 9B55421F852A for ; Mon, 16 Jan 2012 20:58:59 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id F36AE5F9891; Tue, 17 Jan 2012 04:58:43 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:7db4:152d:79c6:de25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id C70CB216C6A; Tue, 17 Jan 2012 04:58:41 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id A2ED21B7BE0D; Tue, 17 Jan 2012 15:58:37 +1100 (EST) To: mrex@sap.com From: Mark Andrews References: <201201170300.q0H3093u013188@fs4113.wdf.sap.corp> In-reply-to: Your message of "Tue, 17 Jan 2012 04:00:09 BST." <201201170300.q0H3093u013188@fs4113.wdf.sap.corp> Date: Tue, 17 Jan 2012 15:58:37 +1100 Message-Id: <20120117045837.A2ED21B7BE0D@drugs.dv.isc.org> Cc: dane@ietf.org Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 04:59:00 -0000 In message <201201170300.q0H3093u013188@fs4113.wdf.sap.corp>, Martin Rex writes : > Mark Andrews wrote: > > > > Martin Rex writes: > > > > > > Tony Finch wrote: > > > > > > > > I think the text you are referring to is: > > > > > > > > - A SMTP client would probably only want to authenticate an SMTP > > > > server whose server certificate has a domain name that is the > > > > domain name that the client thought it was connecting to. > > > > > > > > RFC 3207 does not make a clear distinction between host name and mail > > > > domain, nor between mx owner and mx target. > > > > > > "domain name" in that 3207 text very clearly refers to the EMail address, > > > because it is described as a tail match. > > > > > > If it was meant to be a server name match, that match would be an > > > exact match (rfc2818 3.1 server endpoint identification) plus there > > > would be a requirement for DNSSEC on the MX lookup. > > > > No. It is because MX records are out-of-scope for RFC3207. RFC3207 > > describes what happens *after* a connection has been made not before. > > If MX-records are out-of-scope, then there is only the EMail address > left for which the above text suggests a tail match. No. You have the server name. How you got the server name is out-of-scope. > > If I have a MX record that says "connect to mail.server.example.net" > > and I lookup the addresses for mail.server.example.net then I expect > > to connect to mail.server.example.net. > > This is clearly bogus if you want security, rather than only > sprinkling magic encryption pixie dust on the connection. RFC3207 is *part* of the solution. DNSSEC is *part* of the solution. There are mail domains where the MX records are signed today that have verifiable CERTs presented when STARTTLS is issued. This isn't pixie dust. This is 2012 reality. Now stop living in 1900's. "*.oz.au MX 0 munnari.oz.au" existed as MX record for many years. It supported gatewaying 100's of thousands of email domains off the Internet to ACSNet. Doing this is *still* a valid use for wildcard MX records. > > If I have a client is configured to forward all mail to another > > server as is done with smart host configurations or submission the > > server you need to verify is the smart host / submission server not > > the target of a MX record nor the RHS of the email address. > > As I wrote in a previous EMail, the local(!) configuration that provides > the hostname of the smart relay will have to provide the reference for > matching the identity of the smart relay (because this is unrelated > to the EMail address). > > > But for delivering EMails to their target domain, matching the > certificate of the server to the target of the MX record just doesn't > make sense security-wise (notwithstanding that this is what is being > done if SMTP is delivering EMail insecurely in rfc821 fashion). > > > -Martin -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From ondrej.sury@nic.cz Tue Jan 17 01:06:44 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58DED21F8587 for ; Tue, 17 Jan 2012 01:06:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3MuQMs3NoaNx for ; Tue, 17 Jan 2012 01:06:39 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id B71CA21F848B for ; Tue, 17 Jan 2012 01:06:38 -0800 (PST) Received: from [IPv6:2001:1488:ac14:1400:95e0:402f:a48c:a3a2] (unknown [IPv6:2001:1488:ac14:1400:95e0:402f:a48c:a3a2]) by mail.nic.cz (Postfix) with ESMTPSA id 80D692A302E; Tue, 17 Jan 2012 10:06:37 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1326791197; bh=yUq5xHrQ3BfasDu8ZQJ/WhTthoN7NjSTtPi28hJeA6w=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=P8Ac6RqciJ17vckYtyaU1JGX/kEogMLeB9zHRNv6obCuS3NHaVdhb6vBO8uSJnfH1 XIIfAHYEgNxynJQhElhwuq4k/LMWCiCtv4YsBv0H7dox3Cje4cOr5NLjxL1woduiG+ lZXTqrcCi+LQQqfdUi3Y0S9qc+xvLaPB9Y6mEB9Q= Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <20120117045837.A2ED21B7BE0D@drugs.dv.isc.org> Date: Tue, 17 Jan 2012 10:06:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <92196005-D2C6-4821-9F86-2B86ECED2C92@nic.cz> References: <201201170300.q0H3093u013188@fs4113.wdf.sap.corp> <20120117045837.A2ED21B7BE0D@drugs.dv.isc.org> To: IETF DANE WG list X-Mailer: Apple Mail (2.1251.1) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Paul Hoffman Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 09:06:44 -0000 Guys, I think this thread is spinning off, so we need to stop here. I still think that Paul's original text: > Add to the end of Section 1.1: > The TLSA record is used to make a certificate association between for = a triple of domain name and transport protocol and port number where a = TLS based service is assumed to exist. The triple is used to perform the = lookup described in Section 3. The triple used for TLSA lookup may be = different than what the application started with, such as if the = application protocol uses SRV or MX records to find a server. Similarly, = the certificate association returned in TLSA may have a domain name that = is different than the domain name used in the TLSA query, depending on = the application protocol's rules for TLS server identification. >=20 > Add to the Security Considerations: > The security properties of the TLSA record apply only to the triple of = domain name and transport protocol and port number that was looked up. = If TLSA is used with an application protocol that uses redirection to = find a server (such as SMTP and XMPP), TLSA can only be used if every = step of the redirection chain is protected by DNSSEC and processing = stops for any step where the response is not secure. is fine as is and Richard's text is overly too complicated. It starts to look like we are solving problems outside the scope of the = working group. We are making association between certificate and domain = name. And the application _already_ know what (server) certificate it = wants too look up. So let's focus back and leave it to other protocol. = It's not our role to say how they MX should be looked up nor how the = jabber client should handle DNS. We just say - look for the TLSA with = name you are going to search in the certificate. Ondrej On 17. 1. 2012, at 5:58, Mark Andrews wrote: >=20 > In message <201201170300.q0H3093u013188@fs4113.wdf.sap.corp>, Martin = Rex writes > : >> Mark Andrews wrote: >>>=20 >>> Martin Rex writes: >>>>=20 >>>> Tony Finch wrote: >>>>>=20 >>>>> I think the text you are referring to is: >>>>>=20 >>>>> - A SMTP client would probably only want to authenticate an = SMTP >>>>> server whose server certificate has a domain name that is the >>>>> domain name that the client thought it was connecting to. >>>>>=20 >>>>> RFC 3207 does not make a clear distinction between host name and = mail >>>>> domain, nor between mx owner and mx target. >>>>=20 >>>> "domain name" in that 3207 text very clearly refers to the EMail = address, >>>> because it is described as a tail match. >>>>=20 >>>> If it was meant to be a server name match, that match would be an >>>> exact match (rfc2818 3.1 server endpoint identification) plus there >>>> would be a requirement for DNSSEC on the MX lookup. >>>=20 >>> No. It is because MX records are out-of-scope for RFC3207. RFC3207 >>> describes what happens *after* a connection has been made not = before. >>=20 >> If MX-records are out-of-scope, then there is only the EMail address >> left for which the above text suggests a tail match. >=20 > No. You have the server name. How you got the server name is = out-of-scope. >=20 >>> If I have a MX record that says "connect to mail.server.example.net" >>> and I lookup the addresses for mail.server.example.net then I expect >>> to connect to mail.server.example.net. >>=20 >> This is clearly bogus if you want security, rather than only >> sprinkling magic encryption pixie dust on the connection. >=20 > RFC3207 is *part* of the solution. DNSSEC is *part* of the solution. >=20 > There are mail domains where the MX records are signed today that > have verifiable CERTs presented when STARTTLS is issued. This isn't > pixie dust. This is 2012 reality. Now stop living in 1900's. >=20 > "*.oz.au MX 0 munnari.oz.au" existed as MX record for many years. > It supported gatewaying 100's of thousands of email domains off the > Internet to ACSNet. Doing this is *still* a valid use for wildcard > MX records. >=20 >>> If I have a client is configured to forward all mail to another >>> server as is done with smart host configurations or submission the >>> server you need to verify is the smart host / submission server not >>> the target of a MX record nor the RHS of the email address. >>=20 >> As I wrote in a previous EMail, the local(!) configuration that = provides >> the hostname of the smart relay will have to provide the reference = for >> matching the identity of the smart relay (because this is unrelated >> to the EMail address). >>=20 >>=20 >> But for delivering EMails to their target domain, matching the >> certificate of the server to the target of the MX record just doesn't >> make sense security-wise (notwithstanding that this is what is being >> done if SMTP is delivering EMail insecurely in rfc821 fashion). >>=20 >>=20 >> -Martin > --=20 > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From rbarnes@bbn.com Tue Jan 17 11:01:58 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 774C221F84CD for ; Tue, 17 Jan 2012 11:01:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.675 X-Spam-Level: X-Spam-Status: No, score=-103.675 tagged_above=-999 required=5 tests=[AWL=-0.975, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sKAlL0LVa7pA for ; Tue, 17 Jan 2012 11:01:58 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 010E021F8498 for ; Tue, 17 Jan 2012 11:01:57 -0800 (PST) Received: from ros-dhcp192-1-51-95.bbn.com ([192.1.51.95]:55544) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RnEI8-000L6A-K5; Tue, 17 Jan 2012 14:01:56 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Richard L. Barnes In-Reply-To: <63313B7F-BEA9-46C9-9E86-4E2597988F04@vpnc.org> Date: Tue, 17 Jan 2012 14:01:56 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <9C838E12-4909-47B1-B5DE-A5D4EF394C9A@bbn.com> References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> <7A4B9C55-52C3-4A93-9DA7-62F98CF2A6A5@bbn.com> <03EDD353-7C2F-4E2E-911A-117673C94FAF@vpnc.org> <689C663D-4898-4C2D-858C-BE01CA38B666@vpnc.org> <4F0DA32D.7070206@ogud.com> <3868F318-8669-4B97-AFFE-46E0029A4903@insensate.co.uk> <63313B7F-BEA9-46C9-9E86-4E2597988F04@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1084) Cc: IETF DANE WG list Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 19:01:58 -0000 >> Revised suggested text: >> " >> A TLSA record is used to make an association between a certificate = and a (domain name, transport protocol, port number) triple where a TLS = service may exist. The resolution of TLSA records under a particular = domain name MUST be secured with DNSSEC at all steps, including any = DNS-layer redirection records, such as NS, CNAME, or DNAME records. >=20 > What the heck does the second sentence mean? Why are NS records = considered "DNS-layer redirection records"? How does an application know = whether a DNAME record was used in resolution? I just took the NS/DNAME/CNAME taxonomy from Olafur's message, because, = well, he knows more about the DNS than me :) And in fact, if you're = using them in resolution of TLSA, then they do all need to be secure. = So something on the host needs to check whether they are. As Lawrence = points out, that can be either the DNS API or the application. > I propose that you are well down the rabbit hole. The earlier text I = proposed covers exactly what the first sentence above says it should. Looking back at it again, I still find that your text unnecessarily = restricts the applicability of DANE. The only major difference between = two proposals is what happens when you get an insecure redirection: Hoffman: Fail Barnes: Locate TLSA using any secure information you did find IOW, your proposal means that DANE can only be deployed in a perfect = world of universal DNSSEC, while mine accommodates some of the messiness = of reality. =20 --Richard From rbarnes@bbn.com Tue Jan 17 11:52:37 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B13A511E8091 for ; Tue, 17 Jan 2012 11:52:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.979 X-Spam-Level: X-Spam-Status: No, score=-104.979 tagged_above=-999 required=5 tests=[AWL=0.720, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MeYq-2rTQ6uD for ; Tue, 17 Jan 2012 11:52:36 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id A20F311E807F for ; Tue, 17 Jan 2012 11:52:36 -0800 (PST) Received: from ros-dhcp192-1-51-95.bbn.com ([192.1.51.95]:56496) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RnF59-000MTN-4p; Tue, 17 Jan 2012 14:52:35 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: "Richard L. Barnes" In-Reply-To: <92196005-D2C6-4821-9F86-2B86ECED2C92@nic.cz> Date: Tue, 17 Jan 2012 14:52:34 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <05FD9960-E050-4420-ACC4-2CFC8D1867EF@bbn.com> References: <201201170300.q0H3093u013188@fs4113.wdf.sap.corp> <20120117045837.A2ED21B7BE0D@drugs.dv.isc.org> <92196005-D2C6-4821-9F86-2B86ECED2C92@nic.cz> To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= X-Mailer: Apple Mail (2.1084) Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 19:52:37 -0000 > I still think that Paul's original text: > > is fine as is and Richard's text is overly too complicated. >=20 > It starts to look like we are solving problems outside the scope of = the working group. We are making association between certificate and = domain name. =20 This is right... > And the application _already_ know what (server) certificate it wants = too look up. =20 ... but the "(server)" here is wrong. All that I'm objecting to is the conflation of names with servers. The = application knows what *name* it wants to authenticate, so let it use = that name, regardless of whether it represents the server directly or = not. Insisting that the *server* name be used leads either to (1) spoofing = vulnerabilities, or (2) a universal requirement for DNSSEC. (1) is bad = for security; (2) is bad for deployment. --Richard > So let's focus back and leave it to other protocol. It's not our role = to say how they MX should be looked up nor how the jabber client should = handle DNS. We just say - look for the TLSA with name you are going to = search in the certificate. >=20 > Ondrej >=20 > On 17. 1. 2012, at 5:58, Mark Andrews wrote: >=20 >>=20 >> In message <201201170300.q0H3093u013188@fs4113.wdf.sap.corp>, Martin = Rex writes >> : >>> Mark Andrews wrote: >>>>=20 >>>> Martin Rex writes: >>>>>=20 >>>>> Tony Finch wrote: >>>>>>=20 >>>>>> I think the text you are referring to is: >>>>>>=20 >>>>>> - A SMTP client would probably only want to authenticate an = SMTP >>>>>> server whose server certificate has a domain name that is the >>>>>> domain name that the client thought it was connecting to. >>>>>>=20 >>>>>> RFC 3207 does not make a clear distinction between host name and = mail >>>>>> domain, nor between mx owner and mx target. >>>>>=20 >>>>> "domain name" in that 3207 text very clearly refers to the EMail = address, >>>>> because it is described as a tail match. >>>>>=20 >>>>> If it was meant to be a server name match, that match would be an >>>>> exact match (rfc2818 3.1 server endpoint identification) plus = there >>>>> would be a requirement for DNSSEC on the MX lookup. >>>>=20 >>>> No. It is because MX records are out-of-scope for RFC3207. = RFC3207 >>>> describes what happens *after* a connection has been made not = before. >>>=20 >>> If MX-records are out-of-scope, then there is only the EMail address >>> left for which the above text suggests a tail match. >>=20 >> No. You have the server name. How you got the server name is = out-of-scope. >>=20 >>>> If I have a MX record that says "connect to = mail.server.example.net" >>>> and I lookup the addresses for mail.server.example.net then I = expect >>>> to connect to mail.server.example.net. >>>=20 >>> This is clearly bogus if you want security, rather than only >>> sprinkling magic encryption pixie dust on the connection. >>=20 >> RFC3207 is *part* of the solution. DNSSEC is *part* of the solution. >>=20 >> There are mail domains where the MX records are signed today that >> have verifiable CERTs presented when STARTTLS is issued. This isn't >> pixie dust. This is 2012 reality. Now stop living in 1900's. >>=20 >> "*.oz.au MX 0 munnari.oz.au" existed as MX record for many years. >> It supported gatewaying 100's of thousands of email domains off the >> Internet to ACSNet. Doing this is *still* a valid use for wildcard >> MX records. >>=20 >>>> If I have a client is configured to forward all mail to another >>>> server as is done with smart host configurations or submission the >>>> server you need to verify is the smart host / submission server not >>>> the target of a MX record nor the RHS of the email address. >>>=20 >>> As I wrote in a previous EMail, the local(!) configuration that = provides >>> the hostname of the smart relay will have to provide the reference = for >>> matching the identity of the smart relay (because this is unrelated >>> to the EMail address). >>>=20 >>>=20 >>> But for delivering EMails to their target domain, matching the >>> certificate of the server to the target of the MX record just = doesn't >>> make sense security-wise (notwithstanding that this is what is being >>> done if SMTP is delivering EMail insecurely in rfc821 fashion). >>>=20 >>>=20 >>> -Martin >> --=20 >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: marka@isc.org >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >=20 > -- > Ond=C5=99ej Sur=C3=BD > vedouc=C3=AD v=C3=BDzkumu/Head of R&D department > ------------------------------------------- > CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC > Americka 23, 120 00 Praha 2, Czech Republic > mailto:ondrej.sury@nic.cz http://nic.cz/ > tel:+420.222745110 fax:+420.222745112 > ------------------------------------------- >=20 From bmanning@karoshi.com Tue Jan 17 12:22:58 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD07E21F86C2 for ; Tue, 17 Jan 2012 12:22:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.67 X-Spam-Level: X-Spam-Status: No, score=-5.67 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WSbVQfdWZWZW for ; Tue, 17 Jan 2012 12:22:58 -0800 (PST) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id 2B94F21F86B9 for ; Tue, 17 Jan 2012 12:22:58 -0800 (PST) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id q0HJdVSA029484 for ; Tue, 17 Jan 2012 19:39:32 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id q0HJdUoB029483 for dane@ietf.org; Tue, 17 Jan 2012 19:39:30 GMT Date: Tue, 17 Jan 2012 19:39:30 +0000 From: bmanning@vacation.karoshi.com To: dane@ietf.org Message-ID: <20120117193930.GA29471@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: [dane] existence proof X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 20:22:58 -0000 are there any zones with DANE (or proto-DANE) RRs in them that are visible? /bill From ogud@ogud.com Tue Jan 17 12:45:43 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA0D721F874F for ; Tue, 17 Jan 2012 12:45:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.65 X-Spam-Level: X-Spam-Status: No, score=-104.65 tagged_above=-999 required=5 tests=[AWL=-1.950, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DsdL-1K2YWiq for ; Tue, 17 Jan 2012 12:45:43 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 90D7121F8734 for ; Tue, 17 Jan 2012 12:45:42 -0800 (PST) Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id q0HKjf0L088634 for ; Tue, 17 Jan 2012 15:45:41 -0500 (EST) (envelope-from ogud@ogud.com) Message-ID: <4F15DDF3.90307@ogud.com> Date: Tue, 17 Jan 2012 15:45:39 -0500 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: dane@ietf.org References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> <7A4B9C55-52C3-4A93-9DA7-62F98CF2A6A5@bbn.com> <03EDD353-7C2F-4E2E-911A-117673C94FAF@vpnc.org> <689C663D-4898-4C2D-858C-BE01CA38B666@vpnc.org> <4F0DA32D.7070206@ogud.com> <3868F318-8669-4B97-AFFE-46E0029A4903@insensate.co.uk> <63313B7F-BEA9-46C9-9E86-4E2597988F04@vpnc.org> <9C838E12-4909-47B1-B5DE-A5D4EF394C9A@bbn.com> In-Reply-To: <9C838E12-4909-47B1-B5DE-A5D4EF394C9A@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 20:45:43 -0000 On 17/01/2012 14:01, Richard L. Barnes wrote: >>> Revised suggested text: >>> " >>> A TLSA record is used to make an association between a certificate and a (domain name, transport protocol, port number) triple where a TLS service may exist. The resolution of TLSA records under a particular domain name MUST be secured with DNSSEC at all steps, including any DNS-layer redirection records, such as NS, CNAME, or DNAME records. >> >> What the heck does the second sentence mean? Why are NS records considered "DNS-layer redirection records"? How does an application know whether a DNAME record was used in resolution? > > I just took the NS/DNAME/CNAME taxonomy from Olafur's message, because, well, he knows more about the DNS than me :) And in fact, if you're using them in resolution of TLSA, then they do all need to be secure. So something on the host needs to check whether they are. As Lawrence points out, that can be either the DNS API or the application. > > >> I propose that you are well down the rabbit hole. The earlier text I proposed covers exactly what the first sentence above says it should. > > Looking back at it again, I still find that your text unnecessarily restricts the applicability of DANE. The only major difference between two proposals is what happens when you get an insecure redirection: > Hoffman: Fail > Barnes: Locate TLSA using any secure information you did find > > IOW, your proposal means that DANE can only be deployed in a perfect world of universal DNSSEC, while mine accommodates some of the messiness of reality. > > --Richard > For the record I agree with Paul, any thing not signed or does not verify ===> hard Failure. Olafur From jakob@kirei.se Tue Jan 17 12:53:05 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55FA921F8779 for ; Tue, 17 Jan 2012 12:53:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yEB4Wy-fITW for ; Tue, 17 Jan 2012 12:53:04 -0800 (PST) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD5D21F8777 for ; Tue, 17 Jan 2012 12:53:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=z4yHx9rHm6sXRP2s5boR8b3wM5F5QutEQ/MTnf5E15c=; b=BkUI93V3DW3HvxunT/EE2+VMh6abqMRTDo8xYfqWjyGgKn+wiS9iHASshxXEkkUil3w2ElGdFU7lQ sVyrXJwRWPENiFfq3G6MirEvHRyXjNP6aR7cURNyPFOymc1AT21TfdRi3wUsIJh1zgkC2JRQgDl/7g F/qgcSvhp+9aGWeM= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Tue, 17 Jan 2012 21:52:58 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: <05FD9960-E050-4420-ACC4-2CFC8D1867EF@bbn.com> Date: Tue, 17 Jan 2012 21:52:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <97A6F009-3D61-4975-AC5F-F478A1BFA3EA@kirei.se> References: <201201170300.q0H3093u013188@fs4113.wdf.sap.corp> <20120117045837.A2ED21B7BE0D@drugs.dv.isc.org> <92196005-D2C6-4821-9F86-2B86ECED2C92@nic.cz> <05FD9960-E050-4420-ACC4-2CFC8D1867EF@bbn.com> To: Richard L. Barnes X-Mailer: Apple Mail (2.1251.1) Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 20:53:05 -0000 On 17 jan 2012, at 20:52, Richard L. Barnes wrote: >> And the application _already_ know what (server) certificate it wants = too look up. =20 >=20 > ... but the "(server)" here is wrong. >=20 > All that I'm objecting to is the conflation of names with servers. = The application knows what *name* it wants to authenticate, so let it = use that name, regardless of whether it represents the server directly = or not. I believe that one would want to look up "stuff" for either (a) = hostname/transport/port or (b) service/protocol/transport, and the = current draft describes (a). - Some protocols does not (currently) use SRV and will be very happy = with (a). Example: _443._tcp.www.kirei.se. IN TLSA - You can do (b) by getting the hostname/transport/protocol triplet from = SRV (or MX), then continue with (a). As a DNS person, this feels good. = Example: _sips._tcp.kirei.se. IN SRV 0 0 5061 sip1.kirei.se. _sips._tcp.kirei.se. IN SRV 0 0 5062 sip2.kirei.se. _5061._tcp.sip1.kirei.se. IN TLSA ... _5062._tcp.sip2.kirei.se. IN TLSA ... - You could also do (b) by first doing SRV (or MX), then lookup the TLSA = record using the _service_ domain name combined with the transport & = port from the SRV (hence requiring all servers serving the service use a = common set of transport and port numbers, see example). That feels = awkward to me as it is combining properties of the service name and the = server hostname, but if that is what people want to do I'm not going to = argue. _sips._tcp.kirei.se. IN SRV 0 0 5061 sip1.kirei.se. _sips._tcp.kirei.se. IN SRV 0 0 5062 sip2.kirei.se. _5061._tcp.kirei.se. IN TLSA ... _5062._tcp.kirei.se. IN TLSA ... And please note that what is matched from the certificate association = once looked up is not in scope here, I'm just talking about the lookup = sequence. I would actually be quite happy if we allowed both = _port._transport.hostname and _protocol._transport.servicename for the = TLSA lookup, but we might be way down the rabbit's hole for something = like that. jakob From mrex@sap.com Tue Jan 17 13:18:37 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 578AA21F85D0 for ; Tue, 17 Jan 2012 13:18:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.061 X-Spam-Level: X-Spam-Status: No, score=-10.061 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zcROT0gfKpNV for ; Tue, 17 Jan 2012 13:18:36 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 51D5D21F85C4 for ; Tue, 17 Jan 2012 13:18:09 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q0HLHbD7019630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 17 Jan 2012 22:17:37 +0100 (MET) From: Martin Rex Message-Id: <201201172117.q0HLHbZe014352@fs4113.wdf.sap.corp> To: jakob@kirei.se (Jakob Schlyter) Date: Tue, 17 Jan 2012 22:17:37 +0100 (MET) In-Reply-To: <97A6F009-3D61-4975-AC5F-F478A1BFA3EA@kirei.se> from "Jakob Schlyter" at Jan 17, 12 09:52:56 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: paul.hoffman@vpnc.org, dane@ietf.org Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 21:18:37 -0000 Jakob Schlyter wrote: > > Richard L. Barnes wrote: > > > > O. wrote: > > > > > > And the application _already_ know what (server) certificate it > > > wants too look up. > > > > ... but the "(server)" here is wrong. > > > > All that I'm objecting to is the conflation of names with servers. > > The application knows what *name* it wants to authenticate, so let > > it use that name, regardless of whether it represents the server > > directly or not. I share Richard's concern here. (He stated it more clearly than I did). > > I believe that one would want to look up "stuff" for either > (a) hostname/transport/port or (b) service/protocol/transport, > and the current draft describes (a). agreed. the current draft describes (a). > > - Some protocols does not (currently) use SRV and will be very happy > with (a). Example: > > _443._tcp.www.kirei.se. IN TLSA And it is independent of whether the server is located as aa) www.kirei.se. IN A 0.1.2.3 ab) www.kirei.se. IN CNAME www.l.kirei.se. www.l.kirei.se. IN A 0.1.2.4 ac) www.kirei.se. IN CNAME www.example.org. www.example.org IN A 0.2.3.4 the certificate will always be matched against www.kirei.se, and there is *NO* dependecy that the address lookup (and any other zones that might be crossed, such as example.org in (ac) are also DNSSEC protected. Security is maintained if they're not DNSSEC protected. Traditional PKIX identification is possible without DANE and without DNSSEC on any zones. > > - You can do (b) by getting the hostname/transport/protocol triplet from SRV (or MX), then continue with (a). As a DNS person, this feels good. Example: > > _sips._tcp.kirei.se. IN SRV 0 0 5061 sip1.kirei.se. > _sips._tcp.kirei.se. IN SRV 0 0 5062 sip2.kirei.se. > _5061._tcp.sip1.kirei.se. IN TLSA ... > _5062._tcp.sip2.kirei.se. IN TLSA ... That looks like a bad idea to me, because it creates additional dependencies (and huge complexity) for protecting all other lookups (besides TLSA) and in particular for other zones that may be walked during one any of the indirections. > > - You could also do (b) by first doing SRV (or MX), then lookup the TLSA > record using the _service_ domain name combined with the transport & port > from the SRV [...] > > _sips._tcp.kirei.se. IN SRV 0 0 5061 sip1.kirei.se. > _sips._tcp.kirei.se. IN SRV 0 0 5062 sip2.kirei.se. > _5061._tcp.kirei.se. IN TLSA ... > _5062._tcp.kirei.se. IN TLSA ... That is not what I had in mind. I rather believe this should be used: _sips._tcp.kirei.se. IN SRV 0 0 5061 sip1.kirei.se. _sips._tcp.kirei.se. IN SRV 0 0 5062 sip2.kirei.se. _sips._tcp.kirei.se. IN TLSA ... IN TLSA ... This would *not* add any additional complexity nor require additonal DNSSEC checks (in particular none for any other DNS zones) to the TLSA lookup and validation, and it can be easily and safely used with normal PKIX validation. For hosting scenarios in particular, you do not have to wait until both you and your hoster have DNSSEC fully deployed, but instead you can start using it with DANE as soon as you have DNSSEC in your zone, and could choose and switch your hoster independent of their DNSSEC deployment. -Martin From mamille2@cisco.com Tue Jan 17 13:27:52 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA4AF21F8636 for ; Tue, 17 Jan 2012 13:27:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ePo6cWptU1R for ; Tue, 17 Jan 2012 13:27:52 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 0353121F8635 for ; Tue, 17 Jan 2012 13:27:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=7211; q=dns/txt; s=iport; t=1326835672; x=1328045272; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=FyULZRP2mNtt/aSTa+JcQjnDMqr/631OxFf0Sm97ZqM=; b=ZJawFqid0GtV4UNhJVukRcwE6LvYsEKMUK3/140QlbBR/H1cnFO0XVU9 5MFkc19xyWGY/j3MOOeKK6rI3RX0xeX/NxOhk7FCXVMswVAtf2Cv6ttav ZvJm/ZWGemJbkYpKoqeJe+wEDuLdOvakaiYDU8VNSkxUnMQAaBVB5Yvfj o=; X-Files: smime.p7s : 2214 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIzmFU+rRDoJ/2dsb2JhbABErEOBBoEFgXIBAQEDARIBNjAFCwsYLgJVGSKHWJkBAZ5EiTgWEgIBAQ0FBBEFAQYBAQYBBSABCwECAQEIAQEBAwcQBQ4mDEQQBQuBOAEBBQIDBwEBAQIBAQEBHAIGAYMFYwSIO4V1hmGSYQ X-IronPort-AV: E=Sophos;i="4.71,525,1320624000"; d="p7s'?scan'208";a="25681733" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 17 Jan 2012 21:27:51 +0000 Received: from dhcp-64-101-72-218.cisco.com (dhcp-64-101-72-218.cisco.com [64.101.72.218]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q0HLRpro030719; Tue, 17 Jan 2012 21:27:51 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-7-636149465; protocol="application/pkcs7-signature"; micalg=sha1 From: Matt Miller In-Reply-To: <201201172117.q0HLHbZe014352@fs4113.wdf.sap.corp> Date: Tue, 17 Jan 2012 14:28:20 -0700 Message-Id: References: <201201172117.q0HLHbZe014352@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1084) Cc: paul.hoffman@vpnc.org, dane@ietf.org Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 21:27:53 -0000 --Apple-Mail-7-636149465 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jan 17, 2012, at 14:17, Martin Rex wrote: > Jakob Schlyter wrote: >>=20 >> Richard L. Barnes wrote: >>>=20 >>> O. wrote: >>>>=20 >>>> And the application _already_ know what (server) certificate it >>>> wants too look up. =20 >>>=20 >>> ... but the "(server)" here is wrong. >>>=20 >>> All that I'm objecting to is the conflation of names with servers. >>> The application knows what *name* it wants to authenticate, so let >>> it use that name, regardless of whether it represents the server >>> directly or not. >=20 >=20 > I share Richard's concern here. (He stated it more clearly than I = did). >=20 >=20 >>=20 >> I believe that one would want to look up "stuff" for either >> (a) hostname/transport/port or (b) service/protocol/transport, >> and the current draft describes (a). >=20 > agreed. the current draft describes (a). >=20 >=20 >>=20 >> - Some protocols does not (currently) use SRV and will be very happy >> with (a). Example: >>=20 >> _443._tcp.www.kirei.se. IN TLSA >=20 > And it is independent of whether the server is located as >=20 > aa) www.kirei.se. IN A 0.1.2.3 >=20 > ab) www.kirei.se. IN CNAME www.l.kirei.se. > www.l.kirei.se. IN A 0.1.2.4 >=20 > ac) www.kirei.se. IN CNAME www.example.org. > www.example.org IN A 0.2.3.4 >=20 > the certificate will always be matched against www.kirei.se, > and there is *NO* dependecy that the address lookup (and any other > zones that might be crossed, such as example.org in (ac) are also > DNSSEC protected. Security is maintained if they're not DNSSEC > protected. Traditional PKIX identification is possible without > DANE and without DNSSEC on any zones. >=20 >=20 >>=20 >> - You can do (b) by getting the hostname/transport/protocol triplet = from SRV (or MX), then continue with (a). As a DNS person, this feels = good. Example: >>=20 >> _sips._tcp.kirei.se. IN SRV 0 0 5061 sip1.kirei.se. >> _sips._tcp.kirei.se. IN SRV 0 0 5062 sip2.kirei.se. >> _5061._tcp.sip1.kirei.se. IN TLSA ... >> _5062._tcp.sip2.kirei.se. IN TLSA ... >=20 >=20 > That looks like a bad idea to me, because it creates additional > dependencies (and huge complexity) for protecting all other lookups > (besides TLSA) and in particular for other zones that may be walked > during one any of the indirections. >=20 >>=20 >> - You could also do (b) by first doing SRV (or MX), then lookup the = TLSA >> record using the _service_ domain name combined with the transport & = port >> from the SRV [...] >>=20 >> _sips._tcp.kirei.se. IN SRV 0 0 5061 sip1.kirei.se. >> _sips._tcp.kirei.se. IN SRV 0 0 5062 sip2.kirei.se. >> _5061._tcp.kirei.se. IN TLSA ... >> _5062._tcp.kirei.se. IN TLSA ... >=20 > That is not what I had in mind. >=20 > I rather believe this should be used: >=20 > _sips._tcp.kirei.se. IN SRV 0 0 5061 sip1.kirei.se. > _sips._tcp.kirei.se. IN SRV 0 0 5062 sip2.kirei.se. > _sips._tcp.kirei.se. IN TLSA ... > IN TLSA ... >=20 > This would *not* add any additional complexity nor require additonal = DNSSEC > checks (in particular none for any other DNS zones) to the TLSA lookup = and > validation, and it can be easily and safely used with normal PKIX = validation. >=20 > For hosting scenarios in particular, you do not have to wait until > both you and your hoster have DNSSEC fully deployed, but instead you = can > start using it with DANE as soon as you have DNSSEC in your zone, > and could choose and switch your hoster independent of their DNSSEC > deployment.=20 I completely agree with Martin; he's put words to my thoughts better = than I have (-: - m&m Matt Miller - Collaboration Software Group - Cisco Systems, Inc. --Apple-Mail-7-636149465 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNTCCBTEw ggMZoAMCAQICAwmYMjANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEyMTQxNzQ3MTlaFw0x MjEyMTMxNzQ3MTlaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjgf4wgfswDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMB0GA1UdEQQWMBSBEm1hbWlsbGUyQGNpc2NvLmNvbTAN BgkqhkiG9w0BAQUFAAOCAgEAoa/WVlTWG/rbVIFlG1tCdJrbVvIWNfUNSgojunKsoaVGCoIh7T1+ SgWe8sV+r7s5bVlq66iGxTm/qoKMHM9i4aNGlwWDkXqLHoCKbY4qKPGKnn7PaoA6DWQ5u7ZKBkn9 N2fY8iLxiAy/hLnjtRLlbSr2yBX0DbO1K0ORLDwfO2MUf1j2Cou+qVvEmyEe7cUq37iOOsNbtghT xjn+RE7WJiHcR9deAkfI1xXi7UZcFME+k6nhdnX/qWFFLox0fJJCzX1H8DTzRIjA+ciNLWSG+TRx s7fAn+YZisJdkGxMcWlHZxSu+ybPjc9T7zCyf4+yFHigdOMNxiQ2k/E9WTJ84xIis2TG3E9Nba9B PMb6cgjiqGxiFpKKHj9/5A3wDIHZ8dof+M7YFGnHzwF9i72ZEoaO3hMEhAg9LhqGtQtEZohbTZL2 FOeT+8VjUHSOKhEYurQjWrHDj+ZyDjzhOE/KMwqSWokZhoy0s+VQ05BrVlbXd5DJaB/Hem0MdDUc /6IjqtI6f8O/HLQFAVUQgtW50bfCjDOAB/SaEKzygblcAHxSKDbduRQaRst6cIHEy4eQxvxrHIhg b2KWZ00jS+7NUnAMOyzIJTcZfV5mkCb8UjMHq9NSChwpBFuDzpXxjU20xJGDvbVWNDwfbITCczph p4uuhLITzvhHKaUNwxoqx0oxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYD VQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRo b3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCZgyMAkGBSsOAwIaBQCg ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDExNzIxMjgy MFowIwYJKoZIhvcNAQkEMRYEFHp8zHZjUf84bBZLDGPlcHQykcnCMIGRBgkrBgEEAYI3EAQxgYMw gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0 QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq hkiG9w0BAQEFAASCAQB4zDx5uO4cdTcIwSMKzxMAGXqi5SxQqgK5l74G4gqW2fIZQhXemCwUJcCn /wJbbVXkEa0zj9eNLryWG8wIdvWlAUrl+LnE/xCnvGeDxvKb8Y1KhKV/a7/r19IGseXiLCRinE40 j1Uw1rJzsb94XZ1laAwfEskVs9rYWL79/RQdVZc6xGTHpIIzocA7s96rGQf6aAiZy7HU++qFUnH3 3b7HVEpf76TowZ39dUQ7qzn86aRQ3v1CTIFimoeYexFQEtUcu+T4eKA5bueX6XAgOK4TAT50wBUi cQIBQHBfem0/kEQGGb+ZCZwwBXq82gJFVx1CDn+AHM3KjzO4gS57bYtXAAAAAAAA --Apple-Mail-7-636149465-- From lconroy@insensate.co.uk Tue Jan 17 16:10:39 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E7D511E8083 for ; Tue, 17 Jan 2012 16:10:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.624 X-Spam-Level: X-Spam-Status: No, score=-1.624 tagged_above=-999 required=5 tests=[AWL=0.975, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0MVeeCl7lFP for ; Tue, 17 Jan 2012 16:10:38 -0800 (PST) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by ietfa.amsl.com (Postfix) with ESMTP id 1861811E8079 for ; Tue, 17 Jan 2012 16:10:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 36A01400AEB; Wed, 18 Jan 2012 00:10:34 +0000 (GMT) X-Virus-Scanned: amavisd-new at insensate.co.uk Received: from insensate.co.uk ([127.0.0.1]) by localhost (psyche.insensate.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOlU+y--psQU; Wed, 18 Jan 2012 00:10:33 +0000 (GMT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 565F5400AE0; Wed, 18 Jan 2012 00:10:33 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Lawrence Conroy In-Reply-To: <97A6F009-3D61-4975-AC5F-F478A1BFA3EA@kirei.se> Date: Wed, 18 Jan 2012 00:10:33 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <71A6F9A3-9E10-4E45-B1BC-20FEB7565657@insensate.co.uk> References: <201201170300.q0H3093u013188@fs4113.wdf.sap.corp> <20120117045837.A2ED21B7BE0D@drugs.dv.isc.org> <92196005-D2C6-4821-9F86-2B86ECED2C92@nic.cz> <05FD9960-E050-4420-ACC4-2CFC8D1867EF@bbn.com> <97A6F009-3D61-4975-AC5F-F478A1BFA3EA@kirei.se> To: Jakob Schlyter X-Mailer: Apple Mail (2.1084) Cc: IETF DANE WG list Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 00:10:39 -0000 On 17 Jan 2012, at 20:52, Jakob Schlyter wrote: > - You could also do (b) by first doing SRV (or MX), then lookup the = TLSA record using the _service_ domain name combined with the transport = & port from the SRV (hence requiring all servers serving the service use = a common set of transport and port numbers, see example). That feels = awkward to me as it is combining properties of the service name and the = server hostname, but if that is what people want to do I'm not going to = argue. >=20 > _sips._tcp.kirei.se. IN SRV 0 0 5061 sip1.kirei.se. > _sips._tcp.kirei.se. IN SRV 0 0 5062 sip2.kirei.se. > _5061._tcp.kirei.se. IN TLSA ... > _5062._tcp.kirei.se. IN TLSA ... To which I reply: Hi Jakob, folks, It CAN be slightly more complex; the example you've given is actually a = fallback. RFC3263 includes NAPTRs as well as SRVs (and a further fallback to A = records and default ports), so I guess that you could have: kirei.se. IN NAPTR 50 50 "s" "SIPS+D2T" "" = _sips._tcp.kirei.se. kirei.se. IN NAPTR 50 60 "s" "SIPS+D2T" "" = _sips._tcp.frobit.se. _sips._tcp.kirei.se. IN SRV 0 0 5061 sip1.kirei.se. _sips._tcp.kirei.se. IN SRV 0 0 5062 sip2.kirei.se. _5061._tcp.kirei.se. IN TLSA ... _5062._tcp.kirei.se. IN TLSA ... and ... _sips._tcp.frobit.se. IN SRV 0 0 5066 sip0.frobit.se. _sips._tcp.frobit.se. IN SRV 0 1 5062 sip2.kirei.se. _5066.frobit. IN TLSA ... (Working out what certs get processed is left as an exercise for the = student ;). The processing and validation to get to the SIP server for kirei.se. = could traverse zones (across and back again, or on to some other zone) = and involve several separate DNS queries. As you (and Olifur and ...) say, the application processing chain = continues only if the application gets validated results to all its DNS = queries. If there are some CNAMES (or DNAMEs) as well, they will be handled at = the DNS level -- the SIP SUA doesn't even need to see the intermediary = records. The DNSSEC processing seems straightforward. We're done, right? This is similar to pretty much any application -- if the DNS queries = return validated results, you're good to go. If ANY of the results in the chain returned to the application is not = validated, then the application has to decide what to do AT THAT POINT = IN ITS PROCESSING. That is up to the application. It is not up to the DNS query processing = to decide. No special processing. SO why are we still having this discussion? all the best from a bemused Lawrence =20= From rbarnes@bbn.com Tue Jan 17 17:11:51 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA8FC21F86B3 for ; Tue, 17 Jan 2012 17:11:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.65 X-Spam-Level: X-Spam-Status: No, score=-104.65 tagged_above=-999 required=5 tests=[AWL=-1.950, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KuP5XFLLtsZa for ; Tue, 17 Jan 2012 17:11:51 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id ED96A21F86B0 for ; Tue, 17 Jan 2012 17:11:50 -0800 (PST) Received: from [128.89.253.15] (port=58702 helo=[192.168.1.3]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RnK44-0001JZ-Pi; Tue, 17 Jan 2012 20:11:49 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <4F15DDF3.90307@ogud.com> Date: Tue, 17 Jan 2012 20:11:48 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <6AFCA86D-81BB-488C-90C8-0CFE736BE664@bbn.com> References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> <7A4B9C55-52C3-4A93-9DA7-62F98CF2A6A5@bbn.com> <03EDD353-7C2F-4E2E-911A-117673C94FAF@vpnc.org> <689C663D-4898-4C2D-858C-BE01CA38B666@vpnc.org> <4F0DA32D.7070206@ogud.com> <3868F318-8669-4B97-AFFE-46E0029A4903@insensate.co.uk> <63313B7F-BEA9-46C9-9E86-4E2597988F04@vpnc.org> <9C838E12-4909-47B1-B5DE-A5D4EF394C9A@bbn.com> <4F15DDF3.90307@ogud.com> To: Olafur Gudmundsson X-Mailer: Apple Mail (2.1084) Cc: dane@ietf.org Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 01:11:51 -0000 The problem with that position is that it makes rules out use cases that = can be done securely without universal DNSSEC. As Lawrence, Martin, and = Matt have all pointed out, this includes things like SIP and XMPP. And = it rules them out for no technical reason. I agree that the proposed text I kept editing got weirder and weirder. = Let me try to propose something again, starting from Paul's text: " The TLSA record is used to make a certificate association between for a = triple of domain name, transport protocol, and port number where a TLS = based service may exist. The triple used for TLSA lookup may be = different than what the application started with, if the application = protocol uses DNSSEC-protected SRV or MX records to find a server. = Similarly, the certificate association returned in TLSA may have a = domain name that is different than the domain name used in the TLSA = query, depending on the application protocol's rules for TLS server = identification. " IMO, this is underspecified, since there's no actual concrete guidance = for what applications should do. But the group seems intolerant of = further specificity, so I'll leave it at that for now. (Editorially, = the above should go in Section 3.) --Richard On Jan 17, 2012, at 3:45 PM, Olafur Gudmundsson wrote: > On 17/01/2012 14:01, Richard L. Barnes wrote: >>>> Revised suggested text: >>>> " >>>> A TLSA record is used to make an association between a certificate = and a (domain name, transport protocol, port number) triple where a TLS = service may exist. The resolution of TLSA records under a particular = domain name MUST be secured with DNSSEC at all steps, including any = DNS-layer redirection records, such as NS, CNAME, or DNAME records. >>>=20 >>> What the heck does the second sentence mean? Why are NS records = considered "DNS-layer redirection records"? How does an application know = whether a DNAME record was used in resolution? >>=20 >> I just took the NS/DNAME/CNAME taxonomy from Olafur's message, = because, well, he knows more about the DNS than me :) And in fact, if = you're using them in resolution of TLSA, then they do all need to be = secure. So something on the host needs to check whether they are. As = Lawrence points out, that can be either the DNS API or the application. >>=20 >>=20 >>> I propose that you are well down the rabbit hole. The earlier text I = proposed covers exactly what the first sentence above says it should. >>=20 >> Looking back at it again, I still find that your text unnecessarily = restricts the applicability of DANE. The only major difference between = two proposals is what happens when you get an insecure redirection: >> Hoffman: Fail >> Barnes: Locate TLSA using any secure information you did find >>=20 >> IOW, your proposal means that DANE can only be deployed in a perfect = world of universal DNSSEC, while mine accommodates some of the messiness = of reality. >>=20 >> --Richard >>=20 > For the record I agree with Paul, any thing not signed or does not = verify =3D=3D=3D> hard Failure. >=20 > Olafur >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From marka@isc.org Tue Jan 17 17:34:53 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89EE01F0C58 for ; Tue, 17 Jan 2012 17:34:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0GkslYQNq70 for ; Tue, 17 Jan 2012 17:34:53 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id ED7E71F0C57 for ; Tue, 17 Jan 2012 17:34:52 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 3603DC94C6; Wed, 18 Jan 2012 01:34:39 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:7034:c5d9:cda5:d5c0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id D1B2E216C6A; Wed, 18 Jan 2012 01:34:38 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id ACD811B8A3FE; Wed, 18 Jan 2012 12:34:33 +1100 (EST) To: "Richard L. Barnes" From: Mark Andrews References: <201201170300.q0H3093u013188@fs4113.wdf.sap.corp> <20120117045837.A2ED21B7BE0D@drugs.dv.isc.org> <92196005-D2C6-4821-9F86-2B86ECED2C92@nic.cz> <05FD9960-E050-4420-ACC4-2CFC8D1867EF@bbn.com> In-reply-to: Your message of "Tue, 17 Jan 2012 14:52:34 CDT." <05FD9960-E050-4420-ACC4-2CFC8D1867EF@bbn.com> Date: Wed, 18 Jan 2012 12:34:33 +1100 Message-Id: <20120118013433.ACD811B8A3FE@drugs.dv.isc.org> Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 01:34:53 -0000 In message <05FD9960-E050-4420-ACC4-2CFC8D1867EF@bbn.com>, "Richard L. Barnes" writes: > > I still think that Paul's original text: > > > > is fine as is and Richard's text is overly too complicated. > > > > It starts to look like we are solving problems outside the scope of the > working group. We are making association between certificate and domain > name. > > This is right... > > > And the application _already_ know what (server) certificate it wants > too look up. > > ... but the "(server)" here is wrong. > > All that I'm objecting to is the conflation of names with servers. The > application knows what *name* it wants to authenticate, so let it use > that name, regardless of whether it represents the server directly or not. > > Insisting that the *server* name be used leads either to (1) spoofing > vulnerabilities, or (2) a universal requirement for DNSSEC. (1) is bad > for security; (2) is bad for deployment. > > --Richard Firstly, using a server does NOT require *universal* DNSSEC. It just requires that the zones involved be signed which they will be 99.999% of the time if you are using DANE. In most cases all the records involved will be in the same zone. e.g. example.com MX 0 mail.example.com mail.example.com A 1.2.3.4 mail.example.com AAAA 2001::1.2.3.4 _25._tcp.mail.example.com TLSA ... Or in the outsourced case 2 zones if DANE is being used example.com MX 0 mx.provider.net mx.provider.net A 1.2.3.4 mx.provider.net AAAA 2001::1.2.3.4 _25._tcp.mx.provider.net TLSA ... and if you are not using DANE, provider.net does not need to be signed. The presented CERT just has to be for mx.provider.net using a well known CA. Secondly, not everything is immediate client / server like HTTPS. Email for one isn't. It is store and forward. One needs to pick the correct name for the type of service. For HTTPS it is the name the user entered. For email it is the server name in the MX record (as published or synthesized). Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From mrex@sap.com Tue Jan 17 18:24:53 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E52385E8004 for ; Tue, 17 Jan 2012 18:24:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.07 X-Spam-Level: X-Spam-Status: No, score=-10.07 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8, WEIRD_PORT=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MIq6zU6NsIuV for ; Tue, 17 Jan 2012 18:24:53 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id E90BB5E8001 for ; Tue, 17 Jan 2012 18:24:52 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q0I2Oi5N016423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 18 Jan 2012 03:24:44 +0100 (MET) From: Martin Rex Message-Id: <201201180224.q0I2Oh4v001949@fs4113.wdf.sap.corp> To: marka@isc.org (Mark Andrews) Date: Wed, 18 Jan 2012 03:24:43 +0100 (MET) In-Reply-To: <20120118013433.ACD811B8A3FE@drugs.dv.isc.org> from "Mark Andrews" at Jan 18, 12 12:34:33 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: paul.hoffman@vpnc.org, dane@ietf.org Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 02:24:54 -0000 Mark Andrews wrote: > > One needs to pick the correct name for the type of service. For > HTTPS it is the name the user entered. For email it is the server > name in the MX record (as published or synthesized). We should agree to disagree and discontinue the discussion of whether or not mta-mta SMTP-AUTH server endpoint identification is broken. Ondrej indicated that this is outside of the charter of this WG and the discussion is running in circles. > > Richard L. Barnes wrote: > > > > All that I'm objecting to is the conflation of names with servers. The > > application knows what *name* it wants to authenticate, so let it use > > that name, regardless of whether it represents the server directly or not. > > > > Insisting that the *server* name be used leads either to (1) spoofing > > vulnerabilities, or (2) a universal requirement for DNSSEC. (1) is bad > > for security; (2) is bad for deployment. > > Firstly, using a server does NOT require *universal* DNSSEC. It > just requires that the zones involved be signed which they will be > 99.999% of the time if you are using DANE. Your proposed scheme certainly would. Keep in mind that a client with DANE will (attempt to) to use 100% of the time and the DNS zone where it will succeed are at 0% today and may be at ~5% in 5 years from now (long tail). > > In most cases all the records involved will be in the same zone. > > e.g. > example.com MX 0 mail.example.com > mail.example.com A 1.2.3.4 > mail.example.com AAAA 2001::1.2.3.4 > _25._tcp.mail.example.com TLSA ... I'm not aware that @gmail.com users have serious connectivity problems, which means that todays SMTP relays have to deal with weird setup like these, effectively they have to ignore the name in the certificate entirely. The check that you assert/suggest does NOT work today. ;; QUESTION SECTION: ;gmail.com. IN MX ;; ANSWER SECTION: gmail.com. 3600 IN MX 5 gmail-smtp-in.l.google.com. gmail.com. 3600 IN MX 10 alt1.gmail-smtp-in.l.google.com. gmail.com. 3600 IN MX 20 alt2.gmail-smtp-in.l.google.com. gmail.com. 3600 IN MX 30 alt3.gmail-smtp-in.l.google.com. gmail.com. 3600 IN MX 40 alt4.gmail-smtp-in.l.google.com. openssl s_client -no_ssl2 -starttls smtp -connect gmail-smtp-in.l.google.com:25 will obtain a Server certificate (under a well-know root) issued to the server "mx.google.com". That name in the server neither matches the EMails target domain (@gmail.com), nor does it match the server hostname that the MX record points to (gmail-smtp-in.l.google.com). There are 100 Million DNS domains, Even if only 1% of those are used for EMail, you can not seriously expect every sysadmin on this world to manually cope with every exception there is. For the installed base, matching of names from certificates in mta-mta SMTP-AUTH delivery will reliably cause interop problems, that is a sad fact of life. -Martin From cloos@jhcloos.com Tue Jan 17 19:12:10 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2837621F850F for ; Tue, 17 Jan 2012 19:12:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[AWL=0.504, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3fDvqYcEpFz for ; Tue, 17 Jan 2012 19:12:07 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by ietfa.amsl.com (Postfix) with ESMTP id 454FA21F84A2 for ; Tue, 17 Jan 2012 19:12:07 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 92EA8400A4; Wed, 18 Jan 2012 03:11:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1326856325; bh=LkWhcLfnlS8MDZ0ADhHC22xYJlR8RFMx34weZyn9TOo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=cz4Aj6U4uVsLzoWz08HPzlzlxbiMnCKnhN7fiK0TDE8kNbR0s0KKuSIT3Ewr9M20q kFtmMYt7lB3gmwivTVRpROKTaD4ytOrQTfeQVCiDeTInOt3Nixej79lwWHn281Q99D SQJ9ypolABkAl1NBgWl6HSZaxLeYjbKua2JaAxHs= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 7CAB736004C; Wed, 18 Jan 2012 02:58:40 +0000 (UTC) From: James Cloos To: Mark Andrews In-Reply-To: <20120118013433.ACD811B8A3FE@drugs.dv.isc.org> (Mark Andrews's message of "Wed, 18 Jan 2012 12:34:33 +1100") References: <201201170300.q0H3093u013188@fs4113.wdf.sap.corp> <20120117045837.A2ED21B7BE0D@drugs.dv.isc.org> <92196005-D2C6-4821-9F86-2B86ECED2C92@nic.cz> <05FD9960-E050-4420-ACC4-2CFC8D1867EF@bbn.com> <20120118013433.ACD811B8A3FE@drugs.dv.isc.org> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.92 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2012 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Tue, 17 Jan 2012 21:58:40 -0500 Message-ID: Lines: 23 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:120118:marka@isc.org::ML9E5TVcLwcniBi6:000xegT2 X-Hashcash: 1:30:120118:rbarnes@bbn.com::sjNhs/B9j//fJBsD:09cVDH X-Hashcash: 1:30:120118:paul.hoffman@vpnc.org::dle1GKyx8xXHEC/X:0000000000000000000000000000000000000000gbKj X-Hashcash: 1:30:120118:dane@ietf.org::mZvirgFfxrPgj3/X:000eBNhp Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 03:12:10 -0000 >>>>> "MA" == Mark Andrews writes: MA> Or in the outsourced case 2 zones if DANE is being used Note that it isn't only outsourced cases. Corps often have multiple unrelated domain registrations covering, eg, the corporate name, DBAs, trademarks and even promotions. Not to mention additional registrations used for attempts at efficiency. They may very well want email or voip to any or all of those to reach a central (set of) server(s), and so the MXs and NAPTRs/SRVs may all point to a single target zone. Individuals may also have multiples, especially com/net/org sets, etc. Richard's last proposal seems OK. We should just specify the port/ transport lookup and allow the application protocols to determine whether a given cert CN or alternatename should be accepted or refused. Of course, one hopes that once dnssec and tlsa get more widely adopted that agile, short-term certs will become more common. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From cloos@jhcloos.com Tue Jan 17 19:12:41 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D865021F8512 for ; Tue, 17 Jan 2012 19:12:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[AWL=0.454, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUdWUYcLJyYz for ; Tue, 17 Jan 2012 19:12:41 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by ietfa.amsl.com (Postfix) with ESMTP id E15DA21F84A2 for ; Tue, 17 Jan 2012 19:12:39 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 5C825400A4; Wed, 18 Jan 2012 03:12:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1326856359; bh=fhs/uBv779wP0gXkPQhoc/ZATGi2sqnpPNxmh+7xMws=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=Rb2OYf+jO7l8EFqPWLMcy5BmfW7ryYxCpzSFN0/ZE0ph4iv5iZhYLLhMItIsrlEOT hIf4Fv7C21OYp2aDZg+tA6Sf6Y+zERQeWm2I3iUzNEIjNPlfQUK+alkwrFX19lnjO+ Wvayk4LA0G/OTesxDxT5Tt78UPGsfBAU+65+ZB50= Received: by carbon.jhcloos.org (Postfix, from userid 500) id EA1A736004C; Wed, 18 Jan 2012 02:59:37 +0000 (UTC) From: James Cloos To: "Richard L. Barnes" In-Reply-To: <6AFCA86D-81BB-488C-90C8-0CFE736BE664@bbn.com> (Richard L. Barnes's message of "Tue, 17 Jan 2012 20:11:48 -0500") References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> <7A4B9C55-52C3-4A93-9DA7-62F98CF2A6A5@bbn.com> <03EDD353-7C2F-4E2E-911A-117673C94FAF@vpnc.org> <689C663D-4898-4C2D-858C-BE01CA38B666@vpnc.org> <4F0DA32D.7070206@ogud.com> <3868F318-8669-4B97-AFFE-46E0029A4903@insensate.co.uk> <63313B7F-BEA9-46C9-9E86-4E2597988F04@vpnc.org> <9C838E12-4909-47B1-B5DE-A5D4EF394C9A@bbn.com> <4F15DDF3.90307@ogud.com> <6AFCA86D-81BB-488C-90C8-0CFE736BE664@bbn.com> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.92 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2012 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Tue, 17 Jan 2012 21:59:37 -0500 Message-ID: Lines: 22 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:120118:rbarnes@bbn.com::LhCO6FtJM0rwNRv+:0A4zG+ X-Hashcash: 1:30:120118:ogud@ogud.com::ofQxXQQpDTEv9dLV:000I3jaT X-Hashcash: 1:30:120118:dane@ietf.org::a5J9NarKJc8FqVOv:000DfsoG Cc: dane@ietf.org Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 03:12:42 -0000 >>>>> "RLB" == Richard L Barnes writes: RLB> I agree that the proposed text I kept editing got weirder and RLB> weirder. Let me try to propose something again, starting from RLB> Paul's text: RLB> " RLB> The TLSA record is used to make a certificate association between RLB> for a triple of domain name, transport protocol, and port number RLB> where a TLS based service may exist. The triple used for TLSA RLB> lookup may be different than what the application started with, if RLB> the application protocol uses DNSSEC-protected SRV or MX records to RLB> find a server. Similarly, the certificate association returned in RLB> TLSA may have a domain name that is different than the domain name RLB> used in the TLSA query, depending on the application protocol's RLB> rules for TLS server identification. RLB> " That wording looks reasonable. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From marka@isc.org Tue Jan 17 19:48:59 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31CCA21F84D4 for ; Tue, 17 Jan 2012 19:48:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, WEIRD_PORT=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZIWICYysqZAt for ; Tue, 17 Jan 2012 19:48:58 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 769F721F84D3 for ; Tue, 17 Jan 2012 19:48:58 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 01E7EC94DB; Wed, 18 Jan 2012 03:48:48 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:7034:c5d9:cda5:d5c0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 576BB216C6A; Wed, 18 Jan 2012 03:48:48 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 6E8C81B8B782; Wed, 18 Jan 2012 14:48:44 +1100 (EST) To: mrex@sap.com From: Mark Andrews References: <201201180224.q0I2Oh4v001949@fs4113.wdf.sap.corp> In-reply-to: Your message of "Wed, 18 Jan 2012 03:24:43 BST." <201201180224.q0I2Oh4v001949@fs4113.wdf.sap.corp> Date: Wed, 18 Jan 2012 14:48:44 +1100 Message-Id: <20120118034844.6E8C81B8B782@drugs.dv.isc.org> Cc: paul.hoffman@vpnc.org, dane@ietf.org Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 03:48:59 -0000 In message <201201180224.q0I2Oh4v001949@fs4113.wdf.sap.corp>, Martin Rex writes: > Mark Andrews wrote: > > > > One needs to pick the correct name for the type of service. For > > HTTPS it is the name the user entered. For email it is the server > > name in the MX record (as published or synthesized). > > We should agree to disagree and discontinue the discussion of > whether or not mta-mta SMTP-AUTH server endpoint identification > is broken. > > Ondrej indicated that this is outside of the charter of this WG > and the discussion is running in circles. > > > Richard L. Barnes wrote: > > > > > > All that I'm objecting to is the conflation of names with servers. The > > > application knows what *name* it wants to authenticate, so let it use > > > that name, regardless of whether it represents the server directly or not. > > > > > > Insisting that the *server* name be used leads either to (1) spoofing > > > vulnerabilities, or (2) a universal requirement for DNSSEC. (1) is bad > > > for security; (2) is bad for deployment. > > > > Firstly, using a server does NOT require *universal* DNSSEC. It > > just requires that the zones involved be signed which they will be > > 99.999% of the time if you are using DANE. > > Your proposed scheme certainly would. > > Keep in mind that a client with DANE will (attempt to) to use 100% of > the time and the DNS zone where it will succeed are at 0% today > and may be at ~5% in 5 years from now (long tail). > > > In most cases all the records involved will be in the same zone. > > > > e.g. > > example.com MX 0 mail.example.com > > mail.example.com A 1.2.3.4 > > mail.example.com AAAA 2001::1.2.3.4 > > _25._tcp.mail.example.com TLSA ... > > I'm not aware that @gmail.com users have serious connectivity problems, > which means that todays SMTP relays have to deal with weird setup like > these, effectively they have to ignore the name in the certificate > entirely. The check that you assert/suggest does NOT work today. > > ;; QUESTION SECTION: > ;gmail.com. IN MX > > ;; ANSWER SECTION: > gmail.com. 3600 IN MX 5 gmail-smtp-in.l.google.com. > gmail.com. 3600 IN MX 10 alt1.gmail-smtp-in.l.google.com. > gmail.com. 3600 IN MX 20 alt2.gmail-smtp-in.l.google.com. > gmail.com. 3600 IN MX 30 alt3.gmail-smtp-in.l.google.com. > gmail.com. 3600 IN MX 40 alt4.gmail-smtp-in.l.google.com. > > openssl s_client -no_ssl2 -starttls smtp -connect gmail-smtp-in.l.google.com:2 > 5 > > will obtain a Server certificate (under a well-know root) issued > to the server "mx.google.com". That name in the server neither matches > the EMails target domain (@gmail.com), nor does it match the server > hostname that the MX record points to (gmail-smtp-in.l.google.com). > > There are 100 Million DNS domains, Even if only 1% of those are used > for EMail, you can not seriously expect every sysadmin on this world > to manually cope with every exception there is. For the installed > base, matching of names from certificates in mta-mta SMTP-AUTH > delivery will reliably cause interop problems, that is a sad fact of life. No. I expect Google to correct their MX records/CERT so they are *consistent*. This isn't rocket science. It's only sloppy administation that has cause this *misconfiguration* to exist. mx.google.com is a meaningless cert, supplying it is pointless. All it would take is for Google, Microsoft and Yahoo to turn on STARTTSL and verify the returned cert for the rest of the world to fix their misconfiguration. It's like IPv6, it requires a number of the large providers to turn it on at the same time. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From stpeter@stpeter.im Tue Jan 17 19:53:47 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE0DA11E8080 for ; Tue, 17 Jan 2012 19:53:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.839 X-Spam-Level: X-Spam-Status: No, score=-102.839 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgV3poAI--Fm for ; Tue, 17 Jan 2012 19:53:47 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1680711E8076 for ; Tue, 17 Jan 2012 19:53:47 -0800 (PST) Received: from squire.local (unknown [216.17.140.116]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A05DA40058; Tue, 17 Jan 2012 20:55:14 -0700 (MST) Message-ID: <4F164068.40506@stpeter.im> Date: Tue, 17 Jan 2012 20:45:44 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Richard L. Barnes" References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> <7A4B9C55-52C3-4A93-9DA7-62F98CF2A6A5@bbn.com> <03EDD353-7C2F-4E2E-911A-117673C94FAF@vpnc.org> <689C663D-4898-4C2D-858C-BE01CA38B666@vpnc.org> <4F0DA32D.7070206@ogud.com> <3868F318-8669-4B97-AFFE-46E0029A4903@insensate.co.uk> <63313B7F-BEA9-46C9-9E86-4E2597988F04@vpnc.org> <9C838E12-4909-47B1-B5DE-A5D4EF394C9A@bbn.com> <4F15DDF3.90307@ogud.com> <6AFCA86D-81BB-488C-90C8-0CFE736BE664@bbn.com> In-Reply-To: <6AFCA86D-81BB-488C-90C8-0CFE736BE664@bbn.com> X-Enigmail-Version: 1.3.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: dane@ietf.org Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 03:53:47 -0000 On 1/17/12 6:11 PM, Richard L. Barnes wrote: > The problem with that position is that it makes rules out use cases > that can be done securely without universal DNSSEC. As Lawrence, > Martin, and Matt have all pointed out, this includes things like SIP > and XMPP. And it rules them out for no technical reason. > > I agree that the proposed text I kept editing got weirder and > weirder. Let me try to propose something again, starting from Paul's > text: " The TLSA record is used to make a certificate association > between for a triple of domain name, transport protocol, and port > number where a TLS based service may exist. The triple used for TLSA > lookup may be different than what the application started with, if > the application protocol uses DNSSEC-protected SRV or MX records to > find a server. Similarly, the certificate association returned in > TLSA may have a domain name that is different than the domain name > used in the TLSA query, depending on the application protocol's rules > for TLS server identification. " > > IMO, this is underspecified, since there's no actual concrete > guidance for what applications should do. But the group seems > intolerant of further specificity, so I'll leave it at that for now. > (Editorially, the above should go in Section 3.) Richard, I assume that a spec could provide that further specificity for a particular application protocol. I think it makes sense to say that here, even if we don't provide guidance regarding the nature of that further specificity. Peter -- Peter Saint-Andre https://stpeter.im/ From marka@isc.org Tue Jan 17 21:09:54 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E145A21F856C for ; Tue, 17 Jan 2012 21:09:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJtgkSWP9vQR for ; Tue, 17 Jan 2012 21:09:53 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 423BC21F8569 for ; Tue, 17 Jan 2012 21:09:53 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 6C6785F999D; Wed, 18 Jan 2012 05:09:25 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:7034:c5d9:cda5:d5c0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 89661216C6B; Wed, 18 Jan 2012 05:09:22 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id CAB9D1B8BE96; Wed, 18 Jan 2012 16:09:20 +1100 (EST) To: James Cloos From: Mark Andrews References: <201201170300.q0H3093u013188@fs4113.wdf.sap.corp> <20120117045837.A2ED21B7BE0D@drugs.dv.isc.org> <92196005-D2C6-4821-9F86-2B86ECED2C92@nic.cz> <05FD9960-E050-4420-ACC4-2CFC8D1867EF@bbn.com> <20120118013433.ACD811B8A3FE@drugs.dv.isc.org> In-reply-to: Your message of "Tue, 17 Jan 2012 21:58:40 CDT." Date: Wed, 18 Jan 2012 16:09:20 +1100 Message-Id: <20120118050920.CAB9D1B8BE96@drugs.dv.isc.org> Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 05:09:54 -0000 In message , James Cloos writes: > >>>>> "MA" == Mark Andrews writes: > > MA> Or in the outsourced case 2 zones if DANE is being used > > Note that it isn't only outsourced cases. Corps often have multiple > unrelated domain registrations covering, eg, the corporate name, DBAs, > trademarks and even promotions. Not to mention additional registrations > used for attempts at efficiency. They may very well want email or voip > to any or all of those to reach a central (set of) server(s), and so the > MXs and NAPTRs/SRVs may all point to a single target zone. Which works fine. You just put the host name matching the cert on the RHS of the MX record and let the nameserver constuct the LHS. @ SOA ... @ NS ... @ MX 0 . @ A 1.2.3.4. @ AAAA 2001::1 www CNAME @ Now since this is DANE and you want all those https connections to be secure for www.*, tell me how you turn on DANE for www.* without signing all the zones that contain the address records for www.*? > Individuals may also have multiples, especially com/net/org sets, etc. > > Richard's last proposal seems OK. We should just specify the port/ > transport lookup and allow the application protocols to determine > whether a given cert CN or alternatename should be accepted or refused. > > Of course, one hopes that once dnssec and tlsa get more widely adopted > that agile, short-term certs will become more common. > > -JimC > -- > James Cloos OpenPGP: 1024D/ED7DAEA6 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From ondrej.sury@nic.cz Wed Jan 18 02:59:56 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D887521F87DF for ; Wed, 18 Jan 2012 02:59:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-rShytuOvSI for ; Wed, 18 Jan 2012 02:59:56 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 017BC21F87BD for ; Wed, 18 Jan 2012 02:59:55 -0800 (PST) Received: from [IPv6:2001:1488:ac14:1400:2456:d98:714d:1a3e] (unknown [IPv6:2001:1488:ac14:1400:2456:d98:714d:1a3e]) by mail.nic.cz (Postfix) with ESMTPSA id E8CF42A2F04; Wed, 18 Jan 2012 11:59:54 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1326884394; bh=azFQjjqi7EbKw7L5jYqNUb09aJ9JQ3LnkyCc7Mt33T4=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=AItgcioig5eqWpQ3zSWZQn9L4VQxNmnZNhVPby2jZSAACExA1fUHmIubaYeCpEsAK jwiNEpThenz127RMFSMuqWjzpM1GxnkUfzGV60CcQld8yq5ppP1pYAcoxK6gDoXsbB u7S6K9fap1wdv8VQ6QzNT70kIB1l8ph+lZjlc/Is= Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <6AFCA86D-81BB-488C-90C8-0CFE736BE664@bbn.com> Date: Wed, 18 Jan 2012 11:59:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> <7A4B9C55-52C3-4A93-9DA7-62F98CF2A6A5@bbn.com> <03EDD353-7C2F-4E2E-911A-117673C94FAF@vpnc.org> <689C663D-4898-4C2D-858C-BE01CA38B666@vpnc.org> <4F0DA32D.7070206@ogud.com> <3868F318-8669-4B97-AFFE-46E0029A4903@insensate.co.uk> <63313B7F-BEA9-46C9-9E86-4E2597988F04@vpnc.org> <9C838E12-4909-47B1-B5DE-A5D4EF394C9A@bbn.com> <4F15DDF3.90307@ogud.com> <6AFCA86D-81BB-488C-90C8-0CFE736BE664@bbn.com> To: Richard L. Barnes X-Mailer: Apple Mail (2.1251.1) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: IETF DANE WG list Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 10:59:57 -0000 This discussion reminds me of old joke: Have you heard about the new Cray? It's so fast, it requires TWO halt = instructions to stop it! On 18. 1. 2012, at 2:11, Richard L. Barnes wrote: > The problem with that position is that it makes rules out use cases = that can be done securely without universal DNSSEC. As Lawrence, = Martin, and Matt have all pointed out, this includes things like SIP and = XMPP. And it rules them out for no technical reason. >=20 > I agree that the proposed text I kept editing got weirder and weirder. = Let me try to propose something again, starting from Paul's text: > " > The TLSA record is used to make a certificate association between for = a triple of domain name, transport protocol, and port number where a TLS = based service may exist. The triple used for TLSA lookup may be = different than what the application started with, if the application = protocol uses DNSSEC-protected SRV or MX records to find a server. = Similarly, the certificate association returned in TLSA may have a = domain name that is different than the domain name used in the TLSA = query, depending on the application protocol's rules for TLS server = identification. > " As I understand the wdiff (apart from editorial fixes and minor nits) = you only have added {+DNSSEC-protected+} in front of SRV or MX records. Just to clarify - as I understand the new wording: The triple may be different, if DNSSEC was used. Does that also imply - = If DNSSEC was not used than you have to use the old triple? And may the = application use the "old triple" instead of "new triple" even if DNSSEC = was used? I am very uncomfortable with this, since it creates ambiguity for the = implementations. We should not build our protocol on top of the status = of current DNSSEC deployment. I think we already ruled that out when we = said: "DNSSEC required" in Issue #36. Let's not have this discussion = again, please. > IMO, this is underspecified, since there's no actual concrete guidance = for what applications should do. > But the group seems intolerant of further specificity, so I'll leave = it at that for now. (Editorially, the above should go in Section 3.) My view is that there are already algorithms how to find a name the = application will look for in the certificate. And we should stick to = just referring to that algorithm (since it may change in the future, = etc.). Or put I should put it in another way - there's no difference between = existing TLS/PKI and DANE when doing SRV and MX records. If you got = spoofed when doing additional lookups you will connect to different = server. That's why I really think it is out of the scope of this WG. = We should work on finishing DANE and not on fixing other protocols = (which may be bad) on the way (unless we absolutely have to). Since this discussion again started to go in circles, I will send = another email when I will ask just for +1/-1. O. -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From pieter.lexis@os3.nl Thu Jan 19 06:04:58 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1660421F8606 for ; Thu, 19 Jan 2012 06:04:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AiQLMPf7viUs for ; Thu, 19 Jan 2012 06:04:57 -0800 (PST) Received: from mail.serv.os3.nl (mail.serv.os3.nl [IPv6:2001:610:158:960::25]) by ietfa.amsl.com (Postfix) with ESMTP id 5531F21F85CC for ; Thu, 19 Jan 2012 06:04:56 -0800 (PST) Received: from smtp.os3.nl (smtp.os3.nl [IPv6:2001:610:158:960::119]) by mail.serv.os3.nl (Postfix) with ESMTP id 95DE817AA15 for ; Thu, 19 Jan 2012 15:04:55 +0100 (CET) Received: from [IPv6:2001:610:158:1020:cc8c:b99e:a4e5:509d] (unknown [IPv6:2001:610:158:1020:cc8c:b99e:a4e5:509d]) by smtp.os3.nl (Postfix) with ESMTPSA id 4483117AA0B for ; Thu, 19 Jan 2012 15:04:55 +0100 (CET) Message-ID: <4F182306.8000004@os3.nl> Date: Thu, 19 Jan 2012 15:04:54 +0100 From: Pieter Lexis User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111109 Thunderbird/3.1.16 MIME-Version: 1.0 To: dane@ietf.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dane] Questions about the current draft (14) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 14:04:58 -0000 Hi, I'm doing a small(4 week) academic research project for my Msc education Systems and Network Engineering at the University of Amsterdam[0]. I want to implement a TLSA record creator and a TLSA validator. The creator is 'done' and generates records naively (i.e. does not check the CN when Usage 1 is specified etc.) This validator will: 1. Look up the TLSA record 2. Verify the fields have the correct values 3. Download the certificate(chain) from the host and validate it I have a few question about the specification, as some things are unclear to me. I have no extensive knowledge on PKIX/X.509, so these could stem from ignorance. The questions deal with the creation of the resource records. About the Usage field. When the spec talks about '.. chain through to a CA certificate ..' (usage 0) Does this mean that the CA certificate has 'X509v3 Basic Constraints - CA' and 'X509v3 Key Usage: Key Cert Sign' set to true, whereas Usage 2 means that at least 'X509v3 Key Usage: Key Cert Sign' is true? Next Question: The hex'd (hash of the) certificate in that last field, is this the DER representation? Now for the validation: My first question is about the phrase 'Pass PKIX validation'. Does this mean 'The certificate (or SubjectPublicKeyInfo) must in a valid format' (e.g. DER encoded X.509 Certificate) or does it mean 'The certificate chain must be traversed successfully' or something else. Thanks in advance and best regards, Pieter Lexis 0 - https://www.os3.nl/2011-2012/info/start From paul.hoffman@vpnc.org Thu Jan 19 08:35:04 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A75B21F8575 for ; Thu, 19 Jan 2012 08:35:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WHjRoHQzG6Xe for ; Thu, 19 Jan 2012 08:35:03 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id B8A7421F8554 for ; Thu, 19 Jan 2012 08:35:03 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q0JGZ2q1088392 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 19 Jan 2012 09:35:03 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4F182306.8000004@os3.nl> Date: Thu, 19 Jan 2012 08:35:04 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F182306.8000004@os3.nl> To: Pieter Lexis X-Mailer: Apple Mail (2.1251.1) Cc: dane@ietf.org Subject: Re: [dane] Questions about the current draft (14) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 16:35:04 -0000 On Jan 19, 2012, at 6:04 AM, Pieter Lexis wrote: > About the Usage field. When the spec talks about '.. chain through to = a > CA certificate ..' (usage 0) Does this mean that the CA certificate = has > 'X509v3 Basic Constraints - CA' and 'X509v3 Key Usage: Key Cert Sign' > set to true, whereas Usage 2 means that at least 'X509v3 Key Usage: = Key > Cert Sign' is true? There is disagreement on the latter assertion. Self-signed, non-CA PKIX = certificates were not envisioned in the original X.509 spec, and = different people have different opinions about what they mean and so on. = The debate has happened on this list and on the PKIX WG list as well. > Next Question: The hex'd (hash of the) certificate in that last field, > is this the DER representation? The DER representation. In 2.1.4 (the description of the field), it = says: The field contains the bytes to be matched or the hash of the bytes to be matched. In 2.2 (the presentation format), it says: o The certificate for association field MUST be represented as a string of hexadecimal characters. Whitespace is allowed within the string of hexadecimal characters. Do not mistake the presentation format for the bits on the wire. > Now for the validation: > My first question is about the phrase 'Pass PKIX validation'. Does = this > mean 'The certificate (or SubjectPublicKeyInfo) must in a valid = format' > (e.g. DER encoded X.509 Certificate) or does it mean 'The certificate > chain must be traversed successfully' or something else. The chain must be traversed successfully. --Paul Hoffman From paul.hoffman@vpnc.org Thu Jan 19 08:59:36 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A183E21F8675 for ; Thu, 19 Jan 2012 08:59:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27tKeNWLeXUq for ; Thu, 19 Jan 2012 08:59:36 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD3321F8644 for ; Thu, 19 Jan 2012 08:59:36 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q0JGxZ01089358 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 19 Jan 2012 09:59:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Thu, 19 Jan 2012 08:59:37 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <31591FE4-E267-4BBC-9B5A-95B802378FAF@vpnc.org> References: <4F182306.8000004@os3.nl> To: Pieter Lexis X-Mailer: Apple Mail (2.1251.1) Cc: IETF DANE WG list Subject: Re: [dane] Questions about the current draft (14) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 16:59:36 -0000 Martin Rex pointed out that I was maybe sloppy in my answer to one of = the questions. On Jan 19, 2012, at 8:35 AM, Paul Hoffman wrote: > On Jan 19, 2012, at 6:04 AM, Pieter Lexis wrote: >> Next Question: The hex'd (hash of the) certificate in that last = field, >> is this the DER representation? >=20 > The DER representation. In 2.1.4 (the description of the field), it = says: > The field contains the bytes > to be matched or the hash of the bytes to be matched. > In 2.2 (the presentation format), it says: > o The certificate for association field MUST be represented as a > string of hexadecimal characters. Whitespace is allowed within > the string of hexadecimal characters. > Do not mistake the presentation format for the bits on the wire. If it is a full certificate or a SubjectPublicKeyInfo, both are in DER. = A hash does not have a DER representation: it is just the raw bytes of = the output of the hash function. --Paul Hoffman From pieter.lexis@os3.nl Thu Jan 19 10:08:47 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7D2E21F86C8 for ; Thu, 19 Jan 2012 10:08:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xP-yrPmuqAvu for ; Thu, 19 Jan 2012 10:08:47 -0800 (PST) Received: from mail.serv.os3.nl (mail.serv.os3.nl [IPv6:2001:610:158:960::25]) by ietfa.amsl.com (Postfix) with ESMTP id 1729221F8693 for ; Thu, 19 Jan 2012 10:08:47 -0800 (PST) Received: from smtp.os3.nl (smtp.os3.nl [IPv6:2001:610:158:960::119]) by mail.serv.os3.nl (Postfix) with ESMTP id 6428217AA15; Thu, 19 Jan 2012 19:08:46 +0100 (CET) Received: from [IPv6:2001:610:158:1020:cc8c:b99e:a4e5:509d] (unknown [IPv6:2001:610:158:1020:cc8c:b99e:a4e5:509d]) by smtp.os3.nl (Postfix) with ESMTPSA id 159E717AA0B; Thu, 19 Jan 2012 19:08:46 +0100 (CET) Message-ID: <4F185C2D.2050802@os3.nl> Date: Thu, 19 Jan 2012 19:08:45 +0100 From: Pieter Lexis User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111109 Thunderbird/3.1.16 MIME-Version: 1.0 To: Paul Hoffman References: <4F182306.8000004@os3.nl> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dane@ietf.org Subject: Re: [dane] Questions about the current draft (14) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 18:08:47 -0000 On 01/19/2012 05:35 PM, Paul Hoffman wrote: > There is disagreement on the latter assertion. Self-signed, non-CA > PKIX certificates were not envisioned in the original X.509 spec, and > different people have different opinions about what they mean and so > on. The debate has happened on this list and on the PKIX WG list as > well. So basically usage 0 and 2 are the same when verifying? Both must have the CA constraints set? I want to know to do the verification correctly. > Do not mistake the presentation format for the bits on the wire. I won't, thanks. It just was unclear to me how the certificate was encoded before hashing or converting to hex :-). > The chain must be traversed successfully. So if this means that chain must be traversed successfully, why is it also a requirement for usage 1? As traversing would be a waste of time if the certificate-to-be-matched matches with the TLSA record? See my comment in the draft pseudo-code below: // pass PKIX validation and match EE cert from TLSA if (R.certUsage == 1) { for each PKIX validation chain H { if (C passes PKIX validation in H) { /* Why traverse the chain if the if the only thing that matters is the offered cert itself? */ if (Match(matchingType, Select(selectorType, C), R)) { Finish(2) } } } } -- Pieter Lexis From paul.hoffman@vpnc.org Thu Jan 19 10:19:19 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF01F21F8693 for ; Thu, 19 Jan 2012 10:19:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Un-kD9AgWf5k for ; Thu, 19 Jan 2012 10:19:19 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA2A21F8688 for ; Thu, 19 Jan 2012 10:19:19 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q0JIJIOr093206 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 19 Jan 2012 11:19:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Paul Hoffman In-Reply-To: <4F185C2D.2050802@os3.nl> Date: Thu, 19 Jan 2012 10:19:19 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <9982E232-2EC5-44F2-9874-A916924E8E1D@vpnc.org> References: <4F182306.8000004@os3.nl> <4F185C2D.2050802@os3.nl> To: Pieter Lexis X-Mailer: Apple Mail (2.1251.1) Cc: dane@ietf.org Subject: Re: [dane] Questions about the current draft (14) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 18:19:20 -0000 On Jan 19, 2012, at 10:08 AM, Pieter Lexis wrote: > On 01/19/2012 05:35 PM, Paul Hoffman wrote: >> There is disagreement on the latter assertion. Self-signed, non-CA=20 >> PKIX certificates were not envisioned in the original X.509 spec, and >> different people have different opinions about what they mean and so >> on. The debate has happened on this list and on the PKIX WG list as >> well. >=20 > So basically usage 0 and 2 are the same when verifying? Type 0 is explicitly for CA certs; type 2 can be for certs that are not = CAs but are used as trust anchors. > Both must have > the CA constraints set? Nothing that I said above indicates that, I believe. > I want to know to do the verification correctly. Can you point to text in the current draft that indicates that a = certificate usage of type 2 must have the CA bit set? It would be useful = to us to make this clearer. >> Do not mistake the presentation format for the bits on the wire. >=20 > I won't, thanks. It just was unclear to me how the certificate was > encoded before hashing or converting to hex :-). >=20 >> The chain must be traversed successfully. >=20 > So if this means that chain must be traversed successfully, why is it > also a requirement for usage 1? Usage 1 lets you specify an end-entity certificate that is not used as a = trust anchor and thus must chain to an existing trust anchor; usage 2 = lets you specify an end-entity certificate that is used as a trust = anchor. --Paul Hoffman From paul.hoffman@vpnc.org Thu Jan 19 19:40:28 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAAE221F8609 for ; Thu, 19 Jan 2012 19:40:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BqP3o9uPCQOK for ; Thu, 19 Jan 2012 19:40:28 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7965821F8604 for ; Thu, 19 Jan 2012 19:40:23 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q0K3eK95010785 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 19 Jan 2012 20:40:21 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Paul Hoffman In-Reply-To: Date: Thu, 19 Jan 2012 19:40:21 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> <7A4B9C55-52C3-4A93-9DA7-62F98CF2A6A5@bbn.com> <03EDD353-7C2F-4E2E-911A-117673C94FAF@vpnc.org> <689C663D-4898-4C2D-858C-BE01CA38B666@vpnc.org> <4F0DA32D.7070206@ogud.com> <3868F318-8669-4B97-AFFE-46E0029A4903@insensate.co.uk> <63313B7F-BEA9-46C9-9E86-4E2597988F04@vpnc.org> <9C838E12-4909-47B1-B5DE-A5D4EF394C9A@bbn.com> <4F15DDF3.90307@ogud.com> <6AFCA86D-81BB-488C-90C8-0CFE736BE664@bbn.com> To: IETF DANE WG list X-Mailer: Apple Mail (2.1251.1) Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 03:40:28 -0000 While looking over the discussion, I tried to winnow out the parts that = were not about Issue #28, and the parts that were no in the purview of = this WG. After doing that and taking a deep breath, I think we (maybe) = end up with the following. Add to the end of Section 1.1: The TLSA record is used to make an association between a certificate and = a (domain name, transport protocol, port number) triple where a TLS = based service is assumed to exist. The triple is used to perform the = lookup described in Section 3. Most application protocols only use one = domain name in their connection procedures. However, some application = protocols such as XMPP [RFC6120] begin with one domain name and end up = with a potentially-different domain name; in such cases, the application = always uses the name with which it started for the TLSA lookup. That is: - Application protocols that do not begin with one domain name and end = up with a potentially-different one are not an issue because they only = have one name to deal with - There are no security issues with using the first name for the other = protocols like XMPP because of the DNSSEC requirements for the TLSA = record regardless of the DNSSEC requirements for any other part of those = protocols. - The side-trip we took on CNAME/DNAME is not related to looking up TLSA = records on the starting name. Folks in the WG probably still disagree about what applications should = do with the domain names in the certificates, but that's a discussion = for RFC 6125 and is not addressed by TLSA at all. Does this help? --Paul Hoffman From marka@isc.org Thu Jan 19 20:15:30 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 914B821F859E for ; Thu, 19 Jan 2012 20:15:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_00=-2.599, MANGLED_DOMAIN=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7pefwBUays2F for ; Thu, 19 Jan 2012 20:15:30 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 0146621F859B for ; Thu, 19 Jan 2012 20:15:30 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id E3734C941E; Fri, 20 Jan 2012 04:15:17 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:902a:92d4:e011:46b7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 87509216C6A; Fri, 20 Jan 2012 04:15:17 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 392FE1BB2900; Fri, 20 Jan 2012 15:15:14 +1100 (EST) To: Paul Hoffman From: Mark Andrews References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> <7A4B9C55-52C3-4A93-9DA7-62F98CF2A6A5@bbn.com> <03EDD353-7C2F-4E2E-911A-117673C94FAF@vpnc.org> <689C663D-4898-4C2D-858C-BE01CA38B666@vpnc.org> <4F0DA32D.7070206@ogud.com> <3868F318-8669-4B97-AFFE-46E0029A4903@insensate.co.uk> <63313B7F-BEA9-46C9-9E86-4E2597988F04@vpnc.org> <9C838E12-4909-47B1-B5DE-A5D4EF394C9A@bbn.com> <4F15DDF3.90307@ogud.com> <6AFCA86D-81BB-488C-90C8-0CFE736BE664@bbn.com> In-reply-to: Your message of "Thu, 19 Jan 2012 19:40:21 -0800." Date: Fri, 20 Jan 2012 15:15:14 +1100 Message-Id: <20120120041514.392FE1BB2900@drugs.dv.isc.org> Cc: IETF DANE WG list Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 04:15:30 -0000 In message , Paul Hoffman writes : > While looking over the discussion, I tried to winnow out the parts that were > not about Issue #28, and the parts that were no in the purview of this WG. Af > ter doing that and taking a deep breath, I think we (maybe) end up with the f > ollowing. > > Add to the end of Section 1.1: > > The TLSA record is used to make an association between a certificate and a (d > omain name, transport protocol, port number) triple where a TLS based service > is assumed to exist. The triple is used to perform the lookup described in S > ection 3. Most application protocols only use one domain name in their connec > tion procedures. However, some application protocols such as XMPP [RFC6120] b > egin with one domain name and end up with a potentially-different domain name > ; in such cases, the application always uses the name with which it started f > or the TLSA lookup. > > That is: > - Application protocols that do not begin with one domain name and end up wit > h a potentially-different one are not an issue because they only have one nam > e to deal with > - There are no security issues with using the first name for the other protoc > ols like XMPP because of the DNSSEC requirements for the TLSA record regardle > ss of the DNSSEC requirements for any other part of those protocols. > - The side-trip we took on CNAME/DNAME is not related to looking up TLSA reco > rds on the starting name. > > Folks in the WG probably still disagree about what applications should do wit > h the domain names in the certificates, but that's a discussion for RFC 6125 > and is not addressed by TLSA at all. > > Does this help? No. It is up to the protocol using SRV, or other record types, to define which domain name is fed into the the TSLA lookup. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From paul.hoffman@vpnc.org Fri Jan 20 06:55:19 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D649621F8577 for ; Fri, 20 Jan 2012 06:55:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FtV4Tl8sK5qY for ; Fri, 20 Jan 2012 06:55:19 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 49D0D21F8571 for ; Fri, 20 Jan 2012 06:55:19 -0800 (PST) Received: from [10.20.30.109] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q0KEtElO032029 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 20 Jan 2012 07:55:15 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Paul Hoffman In-Reply-To: <20120120041514.392FE1BB2900@drugs.dv.isc.org> Date: Fri, 20 Jan 2012 06:55:17 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> <7A4B9C55-52C3-4A93-9DA7-62F98CF2A6A5@bbn.com> <03EDD353-7C2F-4E2E-911A-117673C94FAF@vpnc.org> <689C663D-4898-4C2D-858C-BE01CA38B666@vpnc.org> <4F0DA32D.7070206@ogud.com> <3868F318-8669-4B97-AFFE-46E0029A4903@insensate.co.uk> <63313B7F-BEA9-46C9-9E86-4E2597988F04@vpnc.org> <9C838E12-4909-47B1-B5DE-A5D4EF394C9A@bbn.com> <4F15DDF3.90307@ogud.com> <6AFCA86D-81BB-488C-90C8-0CFE736BE664@bbn.com> <20120120041514.392FE1BB2900@drugs.dv.isc.org> To: IETF DANE WG list X-Mailer: Apple Mail (2.1251.1) Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 14:55:19 -0000 On Jan 19, 2012, at 8:15 PM, Mark Andrews wrote: > No. It is up to the protocol using SRV, or other record types, to > define which domain name is fed into the the TSLA lookup. Please say more. For example, if TLSA was released today, why would = HTTPS need to be changed to say "use the one name that you are using"? --Paul Hoffman From mrex@sap.com Fri Jan 20 08:30:30 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4D4921F85F7 for ; Fri, 20 Jan 2012 08:30:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.086 X-Spam-Level: X-Spam-Status: No, score=-10.086 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-fcn3SfUKbW for ; Fri, 20 Jan 2012 08:30:30 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 215D021F8592 for ; Fri, 20 Jan 2012 08:30:23 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q0KGULfA011572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 20 Jan 2012 17:30:21 +0100 (MET) From: Martin Rex Message-Id: <201201201630.q0KGUKrq000872@fs4113.wdf.sap.corp> To: marka@isc.org (Mark Andrews) Date: Fri, 20 Jan 2012 17:30:20 +0100 (MET) In-Reply-To: <20120120041514.392FE1BB2900@drugs.dv.isc.org> from "Mark Andrews" at Jan 20, 12 03:15:14 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: paul.hoffman@vpnc.org, dane@ietf.org Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 16:30:30 -0000 Mark Andrews wrote: > > It is up to the protocol using SRV, or other record types, to > define which domain name is fed into the the TSLA lookup. I actually can agree with that statement. How to come up with a trustworthy domain name that is fed into the TLSA lookup (as specified by DANE) is up to the application protocol. Similarly, how to secure any transformations on an original domain name from a trustworthy source into something that is finally used for the DANE TLSA lookup is up to the application protocol and outside of the scope of DANE protocol. Anyhow, I would appreciate at least a guidance in DANE protocol how applications could avoid/obviate any complex protocol extensions before being able to use DANE (or PKIX) securely, i.e. by doing what HTTPS or XMPP do (not performing any translations on the domain name that is used for the DANE TLSA lookup. > > Now since this is DANE and you want all those https connections to > be secure for www.*, tell me how you turn on DANE for www.* without > signing all the zones that contain the address records for www.*? You're misunderstanding DANE. The address records for https:// connections do *not* need to be signed. PKIX-based server endpoint identification never had such a prerequisite, and neither will DANE. DANE can be use as complementary to PKIX or as an alternative/substitute, and DANE itself only needs DNSSEC validation of the TLSA lookup in order to be secure. -Martin From warren@kumari.net Fri Jan 20 11:36:58 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA0C21F8533 for ; Fri, 20 Jan 2012 11:36:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.533 X-Spam-Level: X-Spam-Status: No, score=-106.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-hqOAbcLKbZ for ; Fri, 20 Jan 2012 11:36:50 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id ED21521F84D6 for ; Fri, 20 Jan 2012 11:36:49 -0800 (PST) Received: from dhcp-172-19-119-228.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id E83E91B413C9; Fri, 20 Jan 2012 14:36:48 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: Date: Fri, 20 Jan 2012 14:36:47 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <82A7544B-92C4-4186-9D2E-CC36309FD6BD@kumari.net> References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> <7A4B9C55-52C3-4A93-9DA7-62F98CF2A6A5@bbn.com> <03EDD353-7C2F-4E2E-911A-117673C94FAF@vpnc.org> <689C663D-4898-4C2D-858C-BE01CA38B666@vpnc.org> <4F0DA32D.7070206@ogud.com> <3868F318-8669-4B97-AFFE-46E0029A4903@insensate.co.uk> <63313B7F-BEA9-46C9-9E86-4E2597988F04@vpnc.org> <9C838E12-4909-47B1-B5DE-A5D4EF394C9A@bbn.com> <4F15DDF3.90307@ogud.com> <6AFCA86D-81BB-488C-90C8-0CFE736BE664@bbn.com> To: Paul Hoffman X-Mailer: Apple Mail (2.1084) Cc: IETF DANE WG list Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 19:36:58 -0000 On Jan 19, 2012, at 10:40 PM, Paul Hoffman wrote: > While looking over the discussion, I tried to winnow out the parts = that were not about Issue #28, and the parts that were no in the purview = of this WG. After doing that and taking a deep breath, I think we = (maybe) end up with the following. >=20 > Add to the end of Section 1.1: >=20 > The TLSA record is used to make an association between a certificate = and a (domain name, transport protocol, port number) triple where a TLS = based service is assumed to exist. The triple is used to perform the = lookup described in Section 3. Most application protocols only use one = domain name in their connection procedures. However, some application = protocols such as XMPP [RFC6120] begin with one domain name and end up = with a potentially-different domain name; in such cases, the application = always uses the name with which it started for the TLSA lookup. How would folk feel about adding something along the lines of: "It is understood that this may not work for all current protocols. = These protocols are encouraged to specify alternate lookup procedures or = not deploy DANE". If each protocol has to define it's own lookup procedure in order to use = DANE we are basically dead in the water. We also are not in a position (nor should we be!) where *we* can specify = this for each protocol, so we could: A: Go with the proposed text and solve this for most cases. B: Simply say that this only works for "protocols only use one domain = name in their connection procedures" and then go down the "Is protocol X = (e.g SMTP) a 'one domain name" protocol?" rathole. C: Go with the proposed text and then, for a few choice protocols = specify alternate procedure (and maybe a registry to track this). My preference would be for A. B and C seems like they will end up being really messy (and painful) and = would necessitate us understanding (and specifying things!) for other = WG's protocols (at which point our friendly ADs will come knocking...) In an ideal world we would wave a magic wand and every protocol designer = would give us a thumbs up on the proposed lookup mechanism or a clear, = concise alternate, but we don't live in an ideal world (but hopefully we = can try make it just a little bit more ideal :-P) W >=20 > That is: > - Application protocols that do not begin with one domain name and end = up with a potentially-different one are not an issue because they only = have one name to deal with > - There are no security issues with using the first name for the other = protocols like XMPP because of the DNSSEC requirements for the TLSA = record regardless of the DNSSEC requirements for any other part of those = protocols. > - The side-trip we took on CNAME/DNAME is not related to looking up = TLSA records on the starting name. >=20 > Folks in the WG probably still disagree about what applications should = do with the domain names in the certificates, but that's a discussion = for RFC 6125 and is not addressed by TLSA at all. >=20 > Does this help? >=20 > --Paul Hoffman >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 From rbarnes@bbn.com Fri Jan 20 12:08:58 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED8021F86DD for ; Fri, 20 Jan 2012 12:08:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.549 X-Spam-Level: X-Spam-Status: No, score=-105.549 tagged_above=-999 required=5 tests=[AWL=1.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3o8BOUuJzLTz for ; Fri, 20 Jan 2012 12:08:57 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 77F8421F86DA for ; Fri, 20 Jan 2012 12:08:57 -0800 (PST) Received: from ros-dhcp192-1-51-95.bbn.com ([192.1.51.95]:59237) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RoKla-000Hk0-Hk; Fri, 20 Jan 2012 15:08:54 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <9982E232-2EC5-44F2-9874-A916924E8E1D@vpnc.org> Date: Fri, 20 Jan 2012 15:08:53 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <96EF9042-5679-444A-9700-B295D67C7298@bbn.com> References: <4F182306.8000004@os3.nl> <4F185C2D.2050802@os3.nl> <9982E232-2EC5-44F2-9874-A916924E8E1D@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1084) Cc: dane@ietf.org Subject: Re: [dane] Questions about the current draft (14) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 20:08:58 -0000 >>> There is disagreement on the latter assertion. Self-signed, non-CA=20= >>> PKIX certificates were not envisioned in the original X.509 spec, = and >>> different people have different opinions about what they mean and so >>> on. The debate has happened on this list and on the PKIX WG list as >>> well. >>=20 >> So basically usage 0 and 2 are the same when verifying? >=20 > Type 0 is explicitly for CA certs; type 2 can be for certs that are = not CAs but are used as trust anchors. Type 0 also requires PKIX validation, in *addition* to matching the TLSA = record. And just to clarify, type 2 can contain either a CA cert or an EE cert. >> Both must have >> the CA constraints set? >=20 > Nothing that I said above indicates that, I believe. In order for a type 0 assertion to pass PKIX validation, all = intermediate certificates in a chain MUST have the CA bit set (by = definition). " (k) If certificate i is a version 3 certificate, verify that the basicConstraints extension is present and that cA is set to TRUE. (If certificate i is a version 1 or version 2 certificate, then the application MUST either verify that certificate i is a CA certificate through out-of-band means or reject the certificate. Conforming implementations may choose to reject all version 1 and version 2 intermediate certificates.) " --Richard From rbarnes@bbn.com Fri Jan 20 13:03:21 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 207D421F8507 for ; Fri, 20 Jan 2012 13:03:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.699 X-Spam-Level: X-Spam-Status: No, score=-105.699 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AjIVtIaWJ69w for ; Fri, 20 Jan 2012 13:03:20 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 7C14C21F84FC for ; Fri, 20 Jan 2012 13:03:20 -0800 (PST) Received: from ros-dhcp192-1-51-95.bbn.com ([192.1.51.95]:59332) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RoLcF-000II0-HS; Fri, 20 Jan 2012 16:03:19 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Fri, 20 Jan 2012 16:03:18 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> <7A4B9C55-52C3-4A93-9DA7-62F98CF2A6A5@bbn.com> <03EDD353-7C2F-4E2E-911A-117673C94FAF@vpnc.org> <689C663D-4898-4C2D-858C-BE01CA38B666@vpnc.org> <4F0DA32D.7070206@ogud.com> <3868F318-8669-4B97-AFFE-46E0029A4903@insensate.co.uk> <63313B7F-BEA9-46C9-9E86-4E2597988F04@vpnc.org> <9C838E12-4909-47B1-B5DE-A5D4EF394C9A@bbn.com> <4F15DDF3.90307@ogud.com> <6AFCA86D-81BB-488C-90C8-0CFE736BE664@bbn.com> To: Paul Hoffman X-Mailer: Apple Mail (2.1084) Cc: IETF DANE WG list Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 21:03:21 -0000 Thanks for taking a deep breath and making another try at this. (In = particular, I apologize for the CNAME detour, which I think was my = fault.) I think we're getting closer. With regard to your text: > The TLSA record is used to make an association between a certificate = and a (domain name, transport protocol, port number) triple where a TLS = based service is assumed to exist. The triple is used to perform the = lookup described in Section 3. Most application protocols only use one = domain name in their connection procedures. However, some application = protocols such as XMPP [RFC6120] begin with one domain name and end up = with a potentially-different domain name; in such cases, the application = always uses the name with which it started for the TLSA lookup. My only major complaint with this text is that it unnecessarily forbids = the use of DNSSEC-protected redirection records to redirect DANE. For = example, the following would be supported by the above text: _xmpp-server._tcp.a.com SRV jabber.b.com 522 [no DNSSEC] a.com TLSA ..... [with DNSSEC] But the following case would be forbidden by the above text: _xmpp-server._tcp.a.com SRV jabber.b.com 5222 [with DNSSEC] jabber.b.com TLSA ..... [with DNSSEC] ISTM that it would be good to have our text allow both of these cases. = They offer equivalent security properties, and different costs/benefits = with regard to deployment. For example, the second scenario above is = what you would want to do if you wanted to outsource, say, XMPP services = without having to update your DNS whenever your outsourcing provider = changes certificates. Which sort of brings us back to a point I made way back in the thread = (and which Mark just revived): Apps know what names they're going after, = so we should let them decide where to look for TLSA. In the single-name = case, it's obvious; in redirection cases, it will depend on where = there's DNSSEC. Plus, we obviously can't handle every protocol in this = document; it will be helpful in many cases to have clarifying documents. = The trouble is how to say all this concisely :) Suggested text, trying to maintain the simplicity of the original = proposal (but probably failing): " The TLSA record is used to make an association between a certificate and = a (domain name, transport protocol, port number) triple where a TLS = based service is assumed to exist. The triple is used to perform the = lookup described in Section 3. Many application protocols, such as HTTPS = [RFC2818], only use one domain name in their connection procedures. = These applications simply use that domain to find TLSA records. =20 Other application protocols such as SMTP [RFC3207], XMPP [RFC6120], and = SIP [RFC3261] may begin with one domain name and end up with a different = domain name. In such cases, it is always safe for the application to = use the name with which it started for the TLSA lookup. If service = delegation records (e.g., MX, SRV) are protected with DNSSEC, then = applications may choose to use the "target" names of these records to = locate TLSA records. This document does not define a specific procedure by which applications = to choose a domain name to use to find TLSA records. For protocols = where there is ambiguity, especially around redirection, there may be a = need for further application-specific standards. " Couple of editorial things: 1. This should be in Section 3 (as I've said before!) 2. Examples would be helpful, e.g., for HTTPS, SMTP, and XMPP/SIP 3. The phrase "is assumed to exist" makes me squirm. Who assumes? Why = are they assuming, instead of acting on real data? In fact, the TLSA = publisher is the owner of the TLS service, so they should know for real. = s/is assumed to exists/exists/= From paul.hoffman@vpnc.org Fri Jan 20 13:20:40 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7EC721F859E for ; Fri, 20 Jan 2012 13:20:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkoKFKNYALag for ; Fri, 20 Jan 2012 13:20:40 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id CF9FE21F8587 for ; Fri, 20 Jan 2012 13:20:39 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q0KLKbJd045313 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 20 Jan 2012 14:20:38 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Paul Hoffman In-Reply-To: Date: Fri, 20 Jan 2012 13:20:37 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <11720A93-A129-4847-832C-6E51B32C8B1A@vpnc.org> References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> <7A4B9C55-52C3-4A93-9DA7-62F98CF2A6A5@bbn.com> <03EDD353-7C2F-4E2E-911A-117673C94FAF@vpnc.org> <689C663D-4898-4C2D-858C-BE01CA38B666@vpnc.org> <4F0DA32D.7070206@ogud.com> <3868F318-8669-4B97-AFFE-46E0029A4903@insensate.co.uk> <63313B7F-BEA9-46C9-9E86-4E2597988F04@vpnc.org> <9C838E12-4909-47B1-B5DE-A5D4EF394C9A@bbn.com> <4F15DDF3.90307@ogud.com> <6AFCA86D-81BB-488C-90C8-0CFE736BE664@bbn.com> To: IETF DANE WG list X-Mailer: Apple Mail (2.1251.1) Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 21:20:40 -0000 On Jan 20, 2012, at 1:03 PM, Richard L. Barnes wrote: > Thanks for taking a deep breath and making another try at this. (In = particular, I apologize for the CNAME detour, which I think was my = fault.) I think we're getting closer. With regard to your text: >=20 >> The TLSA record is used to make an association between a certificate = and a (domain name, transport protocol, port number) triple where a TLS = based service is assumed to exist. The triple is used to perform the = lookup described in Section 3. Most application protocols only use one = domain name in their connection procedures. However, some application = protocols such as XMPP [RFC6120] begin with one domain name and end up = with a potentially-different domain name; in such cases, the application = always uses the name with which it started for the TLSA lookup. >=20 > My only major complaint with this text is that it unnecessarily = forbids the use of DNSSEC-protected redirection records to redirect = DANE. For example, the following would be supported by the above text: > _xmpp-server._tcp.a.com SRV jabber.b.com 522 [no DNSSEC] > a.com TLSA ..... [with DNSSEC] > But the following case would be forbidden by the above text: > _xmpp-server._tcp.a.com SRV jabber.b.com 5222 [with DNSSEC] > jabber.b.com TLSA ..... [with DNSSEC] >=20 > ISTM that it would be good to have our text allow both of these cases. = =20 Yes, if possible. > They offer equivalent security properties, and different = costs/benefits with regard to deployment. For example, the second = scenario above is what you would want to do if you wanted to outsource, = say, XMPP services without having to update your DNS whenever your = outsourcing provider changes certificates. >=20 > Which sort of brings us back to a point I made way back in the thread = (and which Mark just revived): Apps know what names they're going after, = so we should let them decide where to look for TLSA. In the single-name = case, it's obvious; in redirection cases, it will depend on where = there's DNSSEC. Plus, we obviously can't handle every protocol in this = document; it will be helpful in many cases to have clarifying documents. = The trouble is how to say all this concisely :) >=20 > Suggested text, trying to maintain the simplicity of the original = proposal (but probably failing): > " > The TLSA record is used to make an association between a certificate = and a (domain name, transport protocol, port number) triple where a TLS = based service is assumed to exist. The triple is used to perform the = lookup described in Section 3. Many application protocols, such as HTTPS = [RFC2818], only use one domain name in their connection procedures. = These applications simply use that domain to find TLSA records. =20 >=20 > Other application protocols such as SMTP [RFC3207], XMPP [RFC6120], = and SIP [RFC3261] may begin with one domain name and end up with a = different domain name. In such cases, it is always safe for the = application to use the name with which it started for the TLSA lookup. = If service delegation records (e.g., MX, SRV) are protected with DNSSEC, = then applications may choose to use the "target" names of these records = to locate TLSA records. >=20 > This document does not define a specific procedure by which = applications to choose a domain name to use to find TLSA records. For = protocols where there is ambiguity, especially around redirection, there = may be a need for further application-specific standards. > " It would be better to have our text have consistent and interoperable = implementations. It would also be good for out text not to make = assertions about protocols such as RFC 3207 that we know are ambiguous. What we really want is "look for the TLSA record down the redirection = chain and grab the first one you see". That makes it easy for protocols = where there is no redelegation chain, and also allows for the case you = propose, as long as the redelegation chain is secure. So, much simpler = than your proposal: The TLSA record is used to make an association between a certificate and = a (domain name, transport protocol, port number) triple where a TLS = based service is assumed to exist. The triple is used to perform the = lookup described in Section 3. Most application protocols only use one = domain name in their connection procedures. However, some application = protocols such as XMPP [RFC6120] begin with one domain name and end up = with a potentially-different domain name through a chain of lookups; in = such cases, the application uses the first name in the chain that has a = TLSA record, as long as that is either the first name or a name reached = through DNSSEC-protected redirection records. --Paul Hoffman From rbarnes@bbn.com Fri Jan 20 13:36:10 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 496FB21F8653 for ; Fri, 20 Jan 2012 13:36:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.812 X-Spam-Level: X-Spam-Status: No, score=-105.812 tagged_above=-999 required=5 tests=[AWL=0.787, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TkyOIgODaMpk for ; Fri, 20 Jan 2012 13:36:09 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id B961821F8650 for ; Fri, 20 Jan 2012 13:36:09 -0800 (PST) Received: from ros-dhcp192-1-51-95.bbn.com ([192.1.51.95]:59396) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RoM7z-000NKR-Rz; Fri, 20 Jan 2012 16:36:08 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <11720A93-A129-4847-832C-6E51B32C8B1A@vpnc.org> Date: Fri, 20 Jan 2012 16:36:06 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> <7A4B9C55-52C3-4A93-9DA7-62F98CF2A6A5@bbn.com> <03EDD353-7C2F-4E2E-911A-117673C94FAF@vpnc.org> <689C663D-4898-4C2D-858C-BE01CA38B666@vpnc.org> <4F0DA32D.7070206@ogud.com> <3868F318-8669-4B97-AFFE-46E0029A4903@insensate.co.uk> <63313B7F-BEA9-46C9-9E86-4E2597988F04@vpnc.org> <9C838E12-4909-47B1-B5DE-A5D4EF394C9A@bbn.com> <4F15DDF3.90307@ogud.com> <6AFCA86D-81BB-488C-90C8-0CFE736BE664@bbn.com> <11720A93-A129-4847-832C-6E51B32C8B1A@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1084) Cc: IETF DANE WG list Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 21:36:10 -0000 >> " >> The TLSA record is used to make an association between a certificate = and a (domain name, transport protocol, port number) triple where a TLS = based service is assumed to exist. The triple is used to perform the = lookup described in Section 3. Many application protocols, such as HTTPS = [RFC2818], only use one domain name in their connection procedures. = These applications simply use that domain to find TLSA records. =20 >>=20 >> Other application protocols such as SMTP [RFC3207], XMPP [RFC6120], = and SIP [RFC3261] may begin with one domain name and end up with a = different domain name. In such cases, it is always safe for the = application to use the name with which it started for the TLSA lookup. = If service delegation records (e.g., MX, SRV) are protected with DNSSEC, = then applications may choose to use the "target" names of these records = to locate TLSA records. >>=20 >> This document does not define a specific procedure by which = applications to choose a domain name to use to find TLSA records. For = protocols where there is ambiguity, especially around redirection, there = may be a need for further application-specific standards. >> " >=20 > It would be better to have our text have consistent and interoperable = implementations. =20 The "interoperability" we need is of the following form: For each = protocol where DANE is used for authentication, there needs to be an = unambiguous procedure a client to select a set of TLSA records to use. The question for this group is whether we need to define in this = document a uniform procedure followed by every protocol. That is what = your text is attempting to do. IMO: Defining a uniform procedure for all protocols is not viable, due = to the diversity of use cases. In order for DANE to be deployable, we = should specify guidelines to minimize ambiguity, especially for obvious = cases like HTTPS. But we should not attempt to resolve ambiguity that = is created by application protocols' service discovery mechanisms. = Instead, we should define which options are safe (namely, DNSSEC-based = indirection steps) ask the application communities to choose. This is = what my text is attempting to do. --Richard =20 From mamille2@cisco.com Fri Jan 20 13:40:21 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C173321F8658 for ; Fri, 20 Jan 2012 13:40:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ed4oQPdNBJoW for ; Fri, 20 Jan 2012 13:40:20 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 895D421F8653 for ; Fri, 20 Jan 2012 13:40:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=8369; q=dns/txt; s=iport; t=1327095620; x=1328305220; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=RgSwbvRo4ic9EQLhf4xAEiPtFD+DKBPzMeiknDCs5W8=; b=HJObf9pOAiSqntUJR5HIPDmsGAwEeCgLBY1kk8l/7raS7NiVylGdKHZl 2pAbLXXk+EsFMycJYLKVewXzD/9HOD8TCGSoh4CtP8q256cEKQARry6cv 3p0IMUal6r3IcwkKetTrvqELs4cDapHJ2KvbHYPZDyJc4ph7wHAg0BY6V M=; X-Files: smime.p7s : 2214 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAIveGU+rRDoG/2dsb2JhbABDrgqBBYFyAQEBAwEBAQEPAVsLBQsLRgIlMAYTIodaCJobAZ40i0NjBIg8hXqGY5Jr X-IronPort-AV: E=Sophos;i="4.71,545,1320624000"; d="p7s'?scan'208";a="26437563" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 20 Jan 2012 21:40:20 +0000 Received: from dhcp-64-101-72-238.cisco.com (dhcp-64-101-72-238.cisco.com [64.101.72.238]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q0KLeJvL004582; Fri, 20 Jan 2012 21:40:20 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-2-896103885; protocol="application/pkcs7-signature"; micalg=sha1 From: Matt Miller In-Reply-To: Date: Fri, 20 Jan 2012 14:40:54 -0700 Message-Id: References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> <7A4B9C55-52C3-4A93-9DA7-62F98CF2A6A5@bbn.com> <03EDD353-7C2F-4E2E-911A-117673C94FAF@vpnc.org> <689C663D-4898-4C2D-858C-BE01CA38B666@vpnc.org> <4F0DA32D.7070206@ogud.com> <3868F318-8669-4B97-AFFE-46E0029A4903@insensate.co.uk> <63313B7F-BEA9-46C9-9E86-4E2597988F04@vpnc.org> <9C838E12-4909-47B1-B5DE-A5D4EF394C9A@bbn.com> <4F15DDF3.90307@ogud.com> <6AFCA86D-81BB-488C-90C8-0CFE736BE664@bbn.com> To: "Richard L. Barnes" X-Mailer: Apple Mail (2.1084) Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 21:40:21 -0000 --Apple-Mail-2-896103885 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii (I'm ignoring the non-DNSSEC cases...) I've been pondering how I would want to implement this, and I think my = current preference is something like: _xmpp-server._tcp.a.com SRV jabber.b.com 5222 [DNSSEC] =3D=3D> a) _xmpp-server._tcp.a.com TLSA .... [DNSSEC], fallback to b) a.com TLSA .... [DNSSEC], fallback to c) _xmpp-server._tcp.jabber.b.com TLSA .... [DNSSEC], fallback to d) jabber.b.com TLSA .... , fallback to e) existing behaviors To be honest, I'm not sure I'd want to do b) or c) right now (but I'm = not sure I DON'T want to, either). But what I think it really means is, maybe this should be left = completely up to the individual protocols (or maybe even applications) = to determine, and DANE should declare this problem out of scope. - m&m Matt Miller - Collaboration Software Group - Cisco Systems, Inc. On Jan 20, 2012, at 14:03, Richard L. Barnes wrote: > Thanks for taking a deep breath and making another try at this. (In = particular, I apologize for the CNAME detour, which I think was my = fault.) I think we're getting closer. With regard to your text: >=20 >> The TLSA record is used to make an association between a certificate = and a (domain name, transport protocol, port number) triple where a TLS = based service is assumed to exist. The triple is used to perform the = lookup described in Section 3. Most application protocols only use one = domain name in their connection procedures. However, some application = protocols such as XMPP [RFC6120] begin with one domain name and end up = with a potentially-different domain name; in such cases, the application = always uses the name with which it started for the TLSA lookup. >=20 > My only major complaint with this text is that it unnecessarily = forbids the use of DNSSEC-protected redirection records to redirect = DANE. For example, the following would be supported by the above text: > _xmpp-server._tcp.a.com SRV jabber.b.com 522 [no DNSSEC] > a.com TLSA ..... [with DNSSEC] > But the following case would be forbidden by the above text: > _xmpp-server._tcp.a.com SRV jabber.b.com 5222 [with DNSSEC] > jabber.b.com TLSA ..... [with DNSSEC] >=20 > ISTM that it would be good to have our text allow both of these cases. = They offer equivalent security properties, and different costs/benefits = with regard to deployment. For example, the second scenario above is = what you would want to do if you wanted to outsource, say, XMPP services = without having to update your DNS whenever your outsourcing provider = changes certificates. >=20 > Which sort of brings us back to a point I made way back in the thread = (and which Mark just revived): Apps know what names they're going after, = so we should let them decide where to look for TLSA. In the single-name = case, it's obvious; in redirection cases, it will depend on where = there's DNSSEC. Plus, we obviously can't handle every protocol in this = document; it will be helpful in many cases to have clarifying documents. = The trouble is how to say all this concisely :) >=20 > Suggested text, trying to maintain the simplicity of the original = proposal (but probably failing): > " > The TLSA record is used to make an association between a certificate = and a (domain name, transport protocol, port number) triple where a TLS = based service is assumed to exist. The triple is used to perform the = lookup described in Section 3. Many application protocols, such as HTTPS = [RFC2818], only use one domain name in their connection procedures. = These applications simply use that domain to find TLSA records. =20 >=20 > Other application protocols such as SMTP [RFC3207], XMPP [RFC6120], = and SIP [RFC3261] may begin with one domain name and end up with a = different domain name. In such cases, it is always safe for the = application to use the name with which it started for the TLSA lookup. = If service delegation records (e.g., MX, SRV) are protected with DNSSEC, = then applications may choose to use the "target" names of these records = to locate TLSA records. >=20 > This document does not define a specific procedure by which = applications to choose a domain name to use to find TLSA records. For = protocols where there is ambiguity, especially around redirection, there = may be a need for further application-specific standards. > " >=20 > Couple of editorial things: > 1. This should be in Section 3 (as I've said before!) > 2. Examples would be helpful, e.g., for HTTPS, SMTP, and XMPP/SIP > 3. The phrase "is assumed to exist" makes me squirm. Who assumes? = Why are they assuming, instead of acting on real data? In fact, the = TLSA publisher is the owner of the TLS service, so they should know for = real. s/is assumed to exists/exists/ > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane --Apple-Mail-2-896103885 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNTCCBTEw ggMZoAMCAQICAwmYMjANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEyMTQxNzQ3MTlaFw0x MjEyMTMxNzQ3MTlaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjgf4wgfswDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMB0GA1UdEQQWMBSBEm1hbWlsbGUyQGNpc2NvLmNvbTAN BgkqhkiG9w0BAQUFAAOCAgEAoa/WVlTWG/rbVIFlG1tCdJrbVvIWNfUNSgojunKsoaVGCoIh7T1+ SgWe8sV+r7s5bVlq66iGxTm/qoKMHM9i4aNGlwWDkXqLHoCKbY4qKPGKnn7PaoA6DWQ5u7ZKBkn9 N2fY8iLxiAy/hLnjtRLlbSr2yBX0DbO1K0ORLDwfO2MUf1j2Cou+qVvEmyEe7cUq37iOOsNbtghT xjn+RE7WJiHcR9deAkfI1xXi7UZcFME+k6nhdnX/qWFFLox0fJJCzX1H8DTzRIjA+ciNLWSG+TRx s7fAn+YZisJdkGxMcWlHZxSu+ybPjc9T7zCyf4+yFHigdOMNxiQ2k/E9WTJ84xIis2TG3E9Nba9B PMb6cgjiqGxiFpKKHj9/5A3wDIHZ8dof+M7YFGnHzwF9i72ZEoaO3hMEhAg9LhqGtQtEZohbTZL2 FOeT+8VjUHSOKhEYurQjWrHDj+ZyDjzhOE/KMwqSWokZhoy0s+VQ05BrVlbXd5DJaB/Hem0MdDUc /6IjqtI6f8O/HLQFAVUQgtW50bfCjDOAB/SaEKzygblcAHxSKDbduRQaRst6cIHEy4eQxvxrHIhg b2KWZ00jS+7NUnAMOyzIJTcZfV5mkCb8UjMHq9NSChwpBFuDzpXxjU20xJGDvbVWNDwfbITCczph p4uuhLITzvhHKaUNwxoqx0oxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYD VQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRo b3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCZgyMAkGBSsOAwIaBQCg ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDEyMDIxNDA1 NVowIwYJKoZIhvcNAQkEMRYEFND5M9dLuExUfTIDAsZm+TMr/OMmMIGRBgkrBgEEAYI3EAQxgYMw gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0 QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq hkiG9w0BAQEFAASCAQAMeuAgys3Z3HGgipaDxaPqiRH3gM3eT09qx1855kr2uk1FjBEKZ3XZyxtE Qq1ITCs0tO+opdOVDkU74z4KO1EnXDXtkG9ABlc5pGOTPR1WxZkFEcLdAxHZzgc+sxQ4rrzTh9cO aXbYRWCRCQb6NnOq4O0fumTDjFG0103D8IAkSW1bn31iMJAMV5xNzZ1Admq1lr44rxJtEiF6wZ/a NB+2VwRJEhEesQ7wr+r1XoB+QC5Uc1HUmcdhybQ8AC1WNtpiCiCpkHEkaOp4FSGefcvm3eFKqxUf H77Pmcy57TncM4UM+ZjT/KLGY0lhlnOel1maIqxMLp9bX2U1hgUfNI5UAAAAAAAA --Apple-Mail-2-896103885-- From paul.hoffman@vpnc.org Fri Jan 20 14:37:06 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E70321F8653 for ; Fri, 20 Jan 2012 14:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W+hefFkjhdjU for ; Fri, 20 Jan 2012 14:37:05 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 62DEA21F8650 for ; Fri, 20 Jan 2012 14:37:05 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q0KMb0el047162 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 20 Jan 2012 15:37:01 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Fri, 20 Jan 2012 14:37:00 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8B45AB89-FA6D-40B9-A72E-4F7EC355A5DC@vpnc.org> References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> <7A4B9C55-52C3-4A93-9DA7-62F98CF2A6A5@bbn.com> <03EDD353-7C2F-4E2E-911A-117673C94FAF@vpnc.org> <689C663D-4898-4C2D-858C-BE01CA38B666@vpnc.org> <4F0DA32D.7070206@ogud.com> <3868F318-8669-4B97-AFFE-46E0029A4903@insensate.co.uk> <63313B7F-BEA9-46C9-9E86-4E2597988F04@vpnc.org> <9C838E12-4909-47B1-B5DE-A5D4EF394C9A@bbn.com> <4F15DDF3.90307@ogud.com> <6AFCA86D-81BB-488C-90C8-0CFE736BE664@bbn.com> <11720A93-A129-4847-832C-6E51B32C8B1A@vpnc.org> To: "Richard L. Barnes" X-Mailer: Apple Mail (2.1251.1) Cc: IETF DANE WG list Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 22:37:06 -0000 On Jan 20, 2012, at 1:36 PM, Richard L. Barnes wrote: > The "interoperability" we need is of the following form: For each = protocol where DANE is used for authentication, there needs to be an = unambiguous procedure a client to select a set of TLSA records to use. Fully agree. > The question for this group is whether we need to define in this = document a uniform procedure followed by every protocol. That is what = your text is attempting to do. Yes. Otherwise, we will get into the same situation that RFC 6125 had, = where two seemingly-similar protocols have very different processing = procedures. That might be OK for some people, but maddening for others. > IMO: Defining a uniform procedure for all protocols is not viable, due = to the diversity of use cases. In order for DANE to be deployable, we = should specify guidelines to minimize ambiguity, especially for obvious = cases like HTTPS. But we should not attempt to resolve ambiguity that = is created by application protocols' service discovery mechanisms. = Instead, we should define which options are safe (namely, DNSSEC-based = indirection steps) ask the application communities to choose. =20 I'm OK with that, if the WG understands that a few years from now, = people will bitch at us for not having done it right the first time. I = agree that specifying for the obvious cases like HTTPS might be = sufficient, even if it is not completely satisfying. > This is what my text is attempting to do. It misses by overstating, I believe. But I hear that mine overstates as = well. --Paul Hoffman From i.grok@comcast.net Sat Jan 21 12:51:32 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BFA821F84E1 for ; Sat, 21 Jan 2012 12:51:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.919 X-Spam-Level: X-Spam-Status: No, score=-101.919 tagged_above=-999 required=5 tests=[AWL=0.679, BAYES_00=-2.599, USER_IN_WHITELIST=-100, WEIRD_PORT=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22ghy6xu5N+9 for ; Sat, 21 Jan 2012 12:51:31 -0800 (PST) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by ietfa.amsl.com (Postfix) with ESMTP id E57ED21F84E2 for ; Sat, 21 Jan 2012 12:51:30 -0800 (PST) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta05.emeryville.ca.mail.comcast.net with comcast id QKlx1i0091Y3wxoA5LrWs0; Sat, 21 Jan 2012 20:51:30 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta15.emeryville.ca.mail.comcast.net with comcast id QLrV1i00A00PQ6U8bLrWV5; Sat, 21 Jan 2012 20:51:30 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.3) with ESMTP id q0LKpRX4023953 for ; Sat, 21 Jan 2012 15:51:27 -0500 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id q0LKpRvW023952 for dane@ietf.org; Sat, 21 Jan 2012 15:51:27 -0500 Date: Sat, 21 Jan 2012 15:51:27 -0500 From: Scott Schmit To: dane@ietf.org Message-ID: <20120121205127.GA23813@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <3868F318-8669-4B97-AFFE-46E0029A4903@insensate.co.uk> <63313B7F-BEA9-46C9-9E86-4E2597988F04@vpnc.org> <9C838E12-4909-47B1-B5DE-A5D4EF394C9A@bbn.com> <4F15DDF3.90307@ogud.com> <6AFCA86D-81BB-488C-90C8-0CFE736BE664@bbn.com> <11720A93-A129-4847-832C-6E51B32C8B1A@vpnc.org> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="MGYHOYXEY6WxJCY8" Content-Disposition: inline In-Reply-To: <11720A93-A129-4847-832C-6E51B32C8B1A@vpnc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2012 20:51:32 -0000 --MGYHOYXEY6WxJCY8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 20, 2012 at 01:20:37PM -0800, Paul Hoffman wrote: > It would be better to have our text have consistent and interoperable > implementations. It would also be good for out text not to make > assertions about protocols such as RFC 3207 that we know are > ambiguous. >=20 > What we really want is "look for the TLSA record down the redirection > chain and grab the first one you see". That makes it easy for > protocols where there is no redelegation chain, and also allows for > the case you propose, as long as the redelegation chain is secure. So, > much simpler than your proposal: >=20 > The TLSA record is used to make an association between a certificate > and a (domain name, transport protocol, port number) triple where a > TLS based service is assumed to exist. The triple is used to perform > the lookup described in Section 3. Most application protocols only use > one domain name in their connection procedures. However, some > application protocols such as XMPP [RFC6120] begin with one domain > name and end up with a potentially-different domain name through a > chain of lookups; in such cases, the application uses the first name > in the chain that has a TLSA record, as long as that is either the > first name or a name reached through DNSSEC-protected redirection > records. I think this is the most secure way to specify this without making each application protocol specify how it is to be done. I'll point out, however, that the text could be read as applying to CNAMEs, which this WG previously stated should not get this kind of treatment, I think primarily because DNS resolution libraries don't give that kind of visibility to facilitate the lookup. Also, a downside of the approach is the latencies involved in determining that there is no TLSA record at all--every step of the chain must be checked. We could specify the most-common case and let the applications decide the rest, but that feels like punting to me and will ultimately make DANE harder to deploy due to the inconsistent decisions made by various applications. If we pick the hostname, we end up requiring DNSSEC to be secure at every step in the chain to remain secure. This may make DANE undeployable in the near term for some sites. In the long term, however, this is hopefully not a huge problem. It seems like generating appropriate certificates for the hosts could be challenging in some cases (if a.com & b.com delegate to c.com, how does c.com get a certificate saying it's good for both?), but this isn't new and has been resolved somehow. This gets simpler if SPKI matching is used. If we pick the starting domain name, you don't need universal DNSSEC, but updates to the TLSA records will always require coordination between the hosts and the domain. That said, it's not terribly different from the coordination required to set up the SRV records, but the TLSA records will change more often (due to key rolling). This will be better in the near term, but the operational complexity will never go away. Another downside of this would be the confusion caused by this scenario: _tlsservice._tcp.example.com. SRV 0 0 1234 foo.example.com. _tlsservice._tcp.example.com. SRV 0 0 5678 bar.example2.net. _tlsservice2._tcp.example.com. SRV 0 0 5678 foo.example.com. The above implies that the proper TLSA records would be: _1234._tcp.example.com TLSA [stuff for foo.example.com:1234/tlsservice] _5678._tcp.example.com TLSA [stuff for bar.example2.net:5678/tlsservice] _5678._tcp.example.com TLSA [stuff for foo.example.com:5678/tlsservice2] The more I think about it, the more I like keeping the record with the hostname, with "first record in the chain" as a second choice. --=20 Scott Schmit --MGYHOYXEY6WxJCY8 Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQJgYJKoZIhvcNAQcCoIIQFzCCEBMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DVcwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBxswggYDoAMCAQICAwK+HTANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTExMDcxNzA1 MDQwNFoXDTEyMDcxNzExNDI1OVowYjEgMB4GA1UEDRMXNDY1MjU2LTBnRmI2Sk5ZWW44QnFW bUwxGzAZBgNVBAMMEmkuZ3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9r QGNvbWNhc3QubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2AjLOMsBGaqN hv2FcRbfom/QCeKMXu5tUd1JY5oIDZe5y29stnd+se/zUlEkiVeMam4Jgo1c8yGNnwLVYc5/ 9xVi7Qg1Is5b9AB6aJWElJDw/jIdihymNZ2kwkSLT0wl/lzd0mXlwFJPRgQiRkmE6V0ZmjsQ jaVtllVleGBbMvmWPm92e+4Bju9P81kKz7Xr02ijETmaPdVsl+jmOaKPS8Y+2Lat2xus4Ked oJ/7aIWIpz1gRSKjAHSZ1Wmwi2TYUjYhZryChu9e1RWtqk1CycNoeusJ8xdEVN3WSnJ299w/ 3ltK/x/9rpj2j9ShQZVB4NnX6cjQs7pz1lVxvIkjcQIDAQABo4IDrTCCA6kwCQYDVR0TBAIw ADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBQ29j2I0O8sRYi0So9NwwmT1caakDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhR gjAdBgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwggIhBgNVHSAEggIYMIICFDCCAhAG CysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJt ZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUF BwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJp bGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFu ZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0 cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQAZ5U0nL/2PQwsVfHgN7MVPbZEGzDzuj4Oy pTgz4XQFwPcCuy6U9sp1Dwmo3DyKX5nKN4xA7pslN+2Pl/kElGamX7zMCAH0xED0RTOLyk+v nDML4s+OUtWaYVnq1bZEp0F8Luq3zIslAYSebleyiz8M0EypZczsL5rOk86R2F9EYw1CBuFJ 5a4x0CmNu5o30fGNDFt+iXRlbJPp/KY25iUgVnBzJ4COT5kQjxn5lgr4t1I+BDCL5HQQ3h/8 2CzwrWVRBNb9Vqh9LL1ZtzYRt8JezoB6HkVvcKVNGlCZ+/MnvfMzPLwfbTDZC8o4d+4RH6aE LeGF2XmAOaenc/YRqm9oMYIClzCCApMCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQIDAr4dMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTIwMTIxMjA1MTI3WjAjBgkqhkiG9w0BCQQxFgQUUvxNPQ63 +NXvTMnzikIQngRfrZAweQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEA1NCeT+fW PgYTVidW1BBk4Bw92lyUKF5N2bXKAvBKq4mWJepMSqy28gv2oIdhT/53XmrFhXx3njaDgFSE 4grCbZ1OB+Wm7O47t072ogm81oVzYLHUCSsVz6DBncNHqD9atNSW8pYhjmlALTGevLfcT+M/ xJntua72oqjHCl16WmdbdowkCdhspujihh8hr/YbbsAXBexQ1Cy7ExTsctIgsDLsjVh+QCuj 7oP6d8o65xjeRzppWLxcXYZpZcwpDuWsggI521FNxyIEjcq96iBrqhubXHDPlplOr3oHJGGM SWXy6HLy6o6stMDjK8sPaOXnZsHQV6waLqeHnx3M1M7ROw== --MGYHOYXEY6WxJCY8-- From i.grok@comcast.net Sat Jan 21 13:38:56 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACE8321F84A6 for ; Sat, 21 Jan 2012 13:38:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.055 X-Spam-Level: X-Spam-Status: No, score=-102.055 tagged_above=-999 required=5 tests=[AWL=0.544, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jf6cem6JJWAz for ; Sat, 21 Jan 2012 13:38:56 -0800 (PST) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by ietfa.amsl.com (Postfix) with ESMTP id 25A0021F84DA for ; Sat, 21 Jan 2012 13:38:56 -0800 (PST) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta01.emeryville.ca.mail.comcast.net with comcast id QMas1i0051u4NiLA1Mew6W; Sat, 21 Jan 2012 21:38:56 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta21.emeryville.ca.mail.comcast.net with comcast id QMeu1i00g00PQ6U8hMevyA; Sat, 21 Jan 2012 21:38:55 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.3) with ESMTP id q0LLcsNQ024056 for ; Sat, 21 Jan 2012 16:38:54 -0500 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id q0LLcrTT024055 for dane@ietf.org; Sat, 21 Jan 2012 16:38:53 -0500 Date: Sat, 21 Jan 2012 16:38:53 -0500 From: Scott Schmit To: dane@ietf.org Message-ID: <20120121213853.GA15677@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <20120104081557.23741.87139.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="HlL+5n6rz5pIUxbD" Content-Disposition: inline In-Reply-To: <20120104081557.23741.87139.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] I-D Action: draft-ietf-dane-protocol-14.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2012 21:38:56 -0000 --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 04, 2012 at 12:15:57AM -0800, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. This draft is a work item of the DNS-based Authentication of Named E= ntities Working Group of the IETF. >=20 > Title : Using Secure DNS to Associate Certificates with Domain= Names For TLS > Author(s) : Paul Hoffman > Jakob Schlyter > Filename : draft-ietf-dane-protocol-14.txt > Pages : 24 > Date : 2012-01-04 >=20 > TLS and DTLS use PKIX certificates for authenticating the server. > Users want their applications to verify that the certificate provided > by the TLS server is in fact associated with the domain name they > expect. TLSA provides bindings of keys to domains that are asserted > not by external entities, but by the entities that operate the DNS. > This document describes how to use secure DNS to associate the TLS > server's certificate with the intended domain name. Proposed text for A.4 Handling Certificate Rollover: Certificate rollover is handled in much the same was as for rolling DNSSEC zone signing keys using the pre-publish key rollover method [RFC4641]. Suppose example.com has a single TLSA record for a TLS service on tcp port 990: _990._tcp.example.com IN TLSA 1 1 1 1CFC98A706BCF3683015... To start the rollover process, obtain or generate the new certificate or SubjectPublicKeyInfo to be used after the rollover and generate the new TLSA record. Add that record alongside the old one: _990._tcp.example.com IN TLSA 1 1 1 1CFC98A706BCF3683015... _990._tcp.example.com IN TLSA 1 1 1 62D5414CD1CC657E3D30... After the new records have propagated to the authoritative nameservers and the TTL of the old record has expired, switch to the new certificate on the TLS server. Once this has occurred, the old TLSA record can be removed: _990._tcp.example.com IN TLSA 1 1 1 62D5414CD1CC657E3D30... This completes the certificate rollover. [[ Is it typical practice for a CA to revoke the old certificate at renewal, or is there a grace period? If there is no grace period, then the operator is going to need to either match the CA certificate instead of the EE cert (or switch to it in the interim, provided they can find out what it is in advance) or do SPKI matching (again, possibly temporarily). ]] --=20 Scott Schmit --HlL+5n6rz5pIUxbD Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQJgYJKoZIhvcNAQcCoIIQFzCCEBMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DVcwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBxswggYDoAMCAQICAwK+HTANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTExMDcxNzA1 MDQwNFoXDTEyMDcxNzExNDI1OVowYjEgMB4GA1UEDRMXNDY1MjU2LTBnRmI2Sk5ZWW44QnFW bUwxGzAZBgNVBAMMEmkuZ3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9r QGNvbWNhc3QubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2AjLOMsBGaqN hv2FcRbfom/QCeKMXu5tUd1JY5oIDZe5y29stnd+se/zUlEkiVeMam4Jgo1c8yGNnwLVYc5/ 9xVi7Qg1Is5b9AB6aJWElJDw/jIdihymNZ2kwkSLT0wl/lzd0mXlwFJPRgQiRkmE6V0ZmjsQ jaVtllVleGBbMvmWPm92e+4Bju9P81kKz7Xr02ijETmaPdVsl+jmOaKPS8Y+2Lat2xus4Ked oJ/7aIWIpz1gRSKjAHSZ1Wmwi2TYUjYhZryChu9e1RWtqk1CycNoeusJ8xdEVN3WSnJ299w/ 3ltK/x/9rpj2j9ShQZVB4NnX6cjQs7pz1lVxvIkjcQIDAQABo4IDrTCCA6kwCQYDVR0TBAIw ADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBQ29j2I0O8sRYi0So9NwwmT1caakDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhR gjAdBgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwggIhBgNVHSAEggIYMIICFDCCAhAG CysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJt ZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUF BwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJp bGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFu ZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0 cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQAZ5U0nL/2PQwsVfHgN7MVPbZEGzDzuj4Oy pTgz4XQFwPcCuy6U9sp1Dwmo3DyKX5nKN4xA7pslN+2Pl/kElGamX7zMCAH0xED0RTOLyk+v nDML4s+OUtWaYVnq1bZEp0F8Luq3zIslAYSebleyiz8M0EypZczsL5rOk86R2F9EYw1CBuFJ 5a4x0CmNu5o30fGNDFt+iXRlbJPp/KY25iUgVnBzJ4COT5kQjxn5lgr4t1I+BDCL5HQQ3h/8 2CzwrWVRBNb9Vqh9LL1ZtzYRt8JezoB6HkVvcKVNGlCZ+/MnvfMzPLwfbTDZC8o4d+4RH6aE LeGF2XmAOaenc/YRqm9oMYIClzCCApMCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQIDAr4dMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTIwMTIxMjEzODUzWjAjBgkqhkiG9w0BCQQxFgQUtjikI05C tQ7B6ilVNdaZE0EbamoweQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAV2QxGXRK xI+mVJFxQxUJKx9es+lidulSStSpXsBPewrQqMPofn74QITgxyv8BSDuZn425pGROy2laddj 6R2tO45nIJYqYe5XN2XP8WMGwo2Guj0C58+x2PvYuJQcabiQhmIgc6lqtJ4ZDBu+TEXFw7Qy kLHI9Hz8l775p4ALIhfRucMJurAOhC5b76p5pAXqcHpnzVH8DUl5WjWRwdhLybmZ0V02/unO XEnud7lkUaEz66RDV8qabOzxBdvaSL8JV505Q8sqv+d5Z+LjPsOswYcKIABAitmoj7G5wwkI kdjFK1xx36T1bcD20qD5vrFBD7njNIU4by7Q7oV4aeqJfA== --HlL+5n6rz5pIUxbD-- From paul.hoffman@vpnc.org Sat Jan 21 14:01:05 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C414F21F84F6 for ; Sat, 21 Jan 2012 14:01:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RllKFeZSEFCE for ; Sat, 21 Jan 2012 14:01:05 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9BC21F84EA for ; Sat, 21 Jan 2012 14:01:05 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q0LM108B083700 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 21 Jan 2012 15:01:00 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20120121213853.GA15677@odin.ulthar.us> Date: Sat, 21 Jan 2012 14:00:59 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <0F600399-23E0-4ECD-BDE8-3B1E1E9254DD@vpnc.org> References: <20120104081557.23741.87139.idtracker@ietfa.amsl.com> <20120121213853.GA15677@odin.ulthar.us> To: Scott Schmit X-Mailer: Apple Mail (2.1251.1) Cc: dane@ietf.org Subject: Re: [dane] Proposed text for A.4 Handling Certificate Rollover X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2012 22:01:05 -0000 On Jan 21, 2012, at 1:38 PM, Scott Schmit wrote: > Proposed text for A.4 Handling Certificate Rollover: >=20 > Certificate rollover is handled in much the same was as for rolling > DNSSEC zone signing keys using the pre-publish key rollover method > [RFC4641]. Suppose example.com has a single TLSA record for a TLS > service on tcp port 990: >=20 > _990._tcp.example.com IN TLSA 1 1 1 1CFC98A706BCF3683015... >=20 > To start the rollover process, obtain or generate the new certificate = or > SubjectPublicKeyInfo to be used after the rollover and generate the = new > TLSA record. Add that record alongside the old one: >=20 > _990._tcp.example.com IN TLSA 1 1 1 1CFC98A706BCF3683015... > _990._tcp.example.com IN TLSA 1 1 1 62D5414CD1CC657E3D30... >=20 > After the new records have propagated to the authoritative nameservers > and the TTL of the old record has expired, switch to the new > certificate on the TLS server. Once this has occurred, the old TLSA > record can be removed: >=20 > _990._tcp.example.com IN TLSA 1 1 1 62D5414CD1CC657E3D30... >=20 > This completes the certificate rollover. Thank you! We still have some other sections to fill in; volunteers who want to = follow in Scott's footsteps for "Provisioning with NS Records" and = "Securing the Last Hop" are welcome to contact Jakob and I. > [[ Is it typical practice for a CA to revoke the old certificate at > renewal, or is there a grace period? If there is no grace period, then > the operator is going to need to either match the CA certificate = instead > of the EE cert (or switch to it in the interim, provided they can find > out what it is in advance) or do SPKI matching (again, possibly > temporarily). ]] There are many "typical" practices, but "no grace period" is uncommon = (but not unheard of). --Paul Hoffman From i.grok@comcast.net Sat Jan 21 14:55:06 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86A2721F84A5 for ; Sat, 21 Jan 2012 14:55:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.146 X-Spam-Level: X-Spam-Status: No, score=-102.146 tagged_above=-999 required=5 tests=[AWL=0.453, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pgx-+owiyunu for ; Sat, 21 Jan 2012 14:55:05 -0800 (PST) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id 392E221F8494 for ; Sat, 21 Jan 2012 14:55:05 -0800 (PST) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta09.westchester.pa.mail.comcast.net with comcast id QNXR1i0021wpRvQ59Nv5zY; Sat, 21 Jan 2012 22:55:05 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta18.westchester.pa.mail.comcast.net with comcast id QNv51i00K00PQ6U3eNv5Kj; Sat, 21 Jan 2012 22:55:05 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.3) with ESMTP id q0LMt33s024290 for ; Sat, 21 Jan 2012 17:55:03 -0500 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id q0LMt3W2024289 for dane@ietf.org; Sat, 21 Jan 2012 17:55:03 -0500 Date: Sat, 21 Jan 2012 17:55:03 -0500 From: Scott Schmit To: dane@ietf.org Message-ID: <20120121225503.GA24203@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <20120117193930.GA29471@vacation.karoshi.com.> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="uAKRQypu60I7Lcqm" Content-Disposition: inline In-Reply-To: <20120117193930.GA29471@vacation.karoshi.com.> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] existence proof X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2012 22:55:06 -0000 --uAKRQypu60I7Lcqm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 17, 2012 at 07:39:30PM +0000, bmanning@vacation.karoshi.com wro= te: > are there any zones with DANE (or proto-DANE) RRs in them that are visibl= e? $ dig +short TYPE65468 _443._tcp.ulthar.us \# 35 01010162D5414CD1CC657E3D30EA5E6D0136E92306E725413C616A51 CAB4B852C70A= 1C $ dig +short TYPE65468 _443._tcp.www.ulthar.us \# 35 01010162D5414CD1CC657E3D30EA5E6D0136E92306E725413C616A51 CAB4B852C70A= 1C That should be consistent with the current DANE draft. There's also Matt McCutchen's site (mattmccutchen.net), which uses an older draft (-06). I don't know of any others. --=20 Scott Schmit --uAKRQypu60I7Lcqm Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQJgYJKoZIhvcNAQcCoIIQFzCCEBMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DVcwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBxswggYDoAMCAQICAwK+HTANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTExMDcxNzA1 MDQwNFoXDTEyMDcxNzExNDI1OVowYjEgMB4GA1UEDRMXNDY1MjU2LTBnRmI2Sk5ZWW44QnFW bUwxGzAZBgNVBAMMEmkuZ3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9r QGNvbWNhc3QubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2AjLOMsBGaqN hv2FcRbfom/QCeKMXu5tUd1JY5oIDZe5y29stnd+se/zUlEkiVeMam4Jgo1c8yGNnwLVYc5/ 9xVi7Qg1Is5b9AB6aJWElJDw/jIdihymNZ2kwkSLT0wl/lzd0mXlwFJPRgQiRkmE6V0ZmjsQ jaVtllVleGBbMvmWPm92e+4Bju9P81kKz7Xr02ijETmaPdVsl+jmOaKPS8Y+2Lat2xus4Ked oJ/7aIWIpz1gRSKjAHSZ1Wmwi2TYUjYhZryChu9e1RWtqk1CycNoeusJ8xdEVN3WSnJ299w/ 3ltK/x/9rpj2j9ShQZVB4NnX6cjQs7pz1lVxvIkjcQIDAQABo4IDrTCCA6kwCQYDVR0TBAIw ADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBQ29j2I0O8sRYi0So9NwwmT1caakDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhR gjAdBgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwggIhBgNVHSAEggIYMIICFDCCAhAG CysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJt ZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUF BwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJp bGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFu ZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0 cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQAZ5U0nL/2PQwsVfHgN7MVPbZEGzDzuj4Oy pTgz4XQFwPcCuy6U9sp1Dwmo3DyKX5nKN4xA7pslN+2Pl/kElGamX7zMCAH0xED0RTOLyk+v nDML4s+OUtWaYVnq1bZEp0F8Luq3zIslAYSebleyiz8M0EypZczsL5rOk86R2F9EYw1CBuFJ 5a4x0CmNu5o30fGNDFt+iXRlbJPp/KY25iUgVnBzJ4COT5kQjxn5lgr4t1I+BDCL5HQQ3h/8 2CzwrWVRBNb9Vqh9LL1ZtzYRt8JezoB6HkVvcKVNGlCZ+/MnvfMzPLwfbTDZC8o4d+4RH6aE LeGF2XmAOaenc/YRqm9oMYIClzCCApMCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQIDAr4dMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTIwMTIxMjI1NTAzWjAjBgkqhkiG9w0BCQQxFgQU4E1WqoD+ KwVMz7TTnqYpIGOjOo4weQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAYCNEc+mj cftmnIubb6EYAczraiicSiPE+h+RPYraLdtpgjTyHbJ1eXUMGlvkIBQY6IpuqoIj4gp5yXyI 8NtNZ26SHs1o7RaS+eqLi5cgLiuYZg2VDsV+ZfsDXASX57ruKRtHBDajPIjb1WaPnQML5pvl 0cxmmIbvtm4C4uyVkxm0GHjSHXObi878dzD5q3ZP/Lee0IPLkCSZsY67jgL81VLJlqYaQcpp 8ORUa4FYFZgP/pCWd82O/zhCyF1NgLm84zy2RfQqDyWn824XQQRl8uFoejHKYXDGYLdEYisU B4mmo9hIhF6apzJxktQKGdv56DdsfCerXhPdqj165CGy7Q== --uAKRQypu60I7Lcqm-- From marka@isc.org Sat Jan 21 15:46:27 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 866CD21F84B2 for ; Sat, 21 Jan 2012 15:46:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, WEIRD_PORT=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UpPH-tOj3CYn for ; Sat, 21 Jan 2012 15:46:25 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 29A3521F848B for ; Sat, 21 Jan 2012 15:46:25 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 8B28FC9427 for ; Sat, 21 Jan 2012 23:46:10 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6933:c90f:651:97d7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 0A6BE216C6D for ; Sat, 21 Jan 2012 23:46:10 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 2A9071BC0CE4 for ; Sun, 22 Jan 2012 10:46:07 +1100 (EST) To: dane@ietf.org From: Mark Andrews References: <3868F318-8669-4B97-AFFE-46E0029A4903@insensate.co.uk> <63313B7F-BEA9-46C9-9E86-4E2597988F04@vpnc.org> <9C838E12-4909-47B1-B5DE-A5D4EF394C9A@bbn.com> <4F15DDF3.90307@ogud.com> <6AFCA86D-81BB-488C-90C8-0CFE736BE664@bbn.com> <11720A93-A129-4847-832C-6E51B32C8B1A@vpnc.org> <20120121205127.GA23813@odin.ulthar.us> Mail-Followup-To: dane@ietf.org In-reply-to: Your message of "Sat, 21 Jan 2012 15:51:27 CDT." <20120121205127.GA23813@odin.ulthar.us> Date: Sun, 22 Jan 2012 10:46:07 +1100 Message-Id: <20120121234607.2A9071BC0CE4@drugs.dv.isc.org> Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2012 23:46:27 -0000 In message <20120121205127.GA23813@odin.ulthar.us>, Scott Schmit writes: > On Fri, Jan 20, 2012 at 01:20:37PM -0800, Paul Hoffman wrote: > > It would be better to have our text have consistent and interoperable > > implementations. It would also be good for out text not to make > > assertions about protocols such as RFC 3207 that we know are > > ambiguous. > >=20 > > What we really want is "look for the TLSA record down the redirection > > chain and grab the first one you see". That makes it easy for > > protocols where there is no redelegation chain, and also allows for > > the case you propose, as long as the redelegation chain is secure. So, > > much simpler than your proposal: > >=20 > > The TLSA record is used to make an association between a certificate > > and a (domain name, transport protocol, port number) triple where a > > TLS based service is assumed to exist. The triple is used to perform > > the lookup described in Section 3. Most application protocols only use > > one domain name in their connection procedures. However, some > > application protocols such as XMPP [RFC6120] begin with one domain > > name and end up with a potentially-different domain name through a > > chain of lookups; in such cases, the application uses the first name > > in the chain that has a TLSA record, as long as that is either the > > first name or a name reached through DNSSEC-protected redirection > > records. > > I think this is the most secure way to specify this without making each > application protocol specify how it is to be done. One size does not fit. You are wasting the working groups time trying to make one size fit all. > I'll point out, however, that the text could be read as applying to > CNAMEs, which this WG previously stated should not get this kind of > treatment, It really depend on the protocol and its rules with respect to CNAMES. For HTTPS, CNAME is used like a SRV or MX record. This really is *wrong* from a DNS perspective. This "decision" is still causing operational problems today as it does not work for name at the apex of a zone. > I think primarily because DNS resolution libraries don't give > that kind of visibility to facilitate the lookup. Actually most libraries *do* return the canonical name. It the applications that choose to ignore that the canonical name differs. > Also, a downside of the approach is the latencies involved in > determining that there is no TLSA record at all--every step of the chain > must be checked. > > We could specify the most-common case and let the applications decide > the rest, but that feels like punting to me and will ultimately make > DANE harder to deploy due to the inconsistent decisions made by various > applications. DANE is no harder to deploy regardless of which name the application chooses to use. Getting a secure application may be harder, but deploying DANE isn't. Also it is *not* the DANE wg job to fix these applications. > If we pick the hostname, We do *not* get to make this choice. This choice is out of scope for DANE. DANE's job is to say how to get to the TLSA record *once* the application has the name, port and transport. It is *not* DANEs job to describe how the application goes from its inputs to that name. > we end up requiring DNSSEC to be secure at > every step in the chain to remain secure. This may make DANE > undeployable in the near term for some sites. In the long term, however, > this is hopefully not a huge problem. It seems like generating > appropriate certificates for the hosts could be challenging in some > cases (if a.com & b.com delegate to c.com, how does c.com get a > certificate saying it's good for both?), but this isn't new and has been > resolved somehow. This gets simpler if SPKI matching is used. > > If we pick the starting domain name, you don't need universal DNSSEC, > but updates to the TLSA records will always require coordination between > the hosts and the domain. That said, it's not terribly different from > the coordination required to set up the SRV records, but the TLSA > records will change more often (due to key rolling). This will be better > in the near term, but the operational complexity will never go away. > > Another downside of this would be the confusion caused by this scenario: > > _tlsservice._tcp.example.com. SRV 0 0 1234 foo.example.com. > _tlsservice._tcp.example.com. SRV 0 0 5678 bar.example2.net. > _tlsservice2._tcp.example.com. SRV 0 0 5678 foo.example.com. > > The above implies that the proper TLSA records would be: > > _1234._tcp.example.com TLSA [stuff for foo.example.com:1234/tlsservice] > _5678._tcp.example.com TLSA [stuff for bar.example2.net:5678/tlsservice] > _5678._tcp.example.com TLSA [stuff for foo.example.com:5678/tlsservice2] > > The more I think about it, the more I like keeping the record with the > hostname, with "first record in the chain" as a second choice. > > --=20 > Scott Schmit -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From i.grok@comcast.net Sat Jan 21 17:20:42 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B598F21F84A5 for ; Sat, 21 Jan 2012 17:20:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.611 X-Spam-Level: X-Spam-Status: No, score=-101.611 tagged_above=-999 required=5 tests=[AWL=-0.211, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6Y7-8XL4BPf for ; Sat, 21 Jan 2012 17:20:42 -0800 (PST) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [76.96.27.228]) by ietfa.amsl.com (Postfix) with ESMTP id 57F2E21F8494 for ; Sat, 21 Jan 2012 17:20:38 -0800 (PST) Received: from omta22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by qmta15.emeryville.ca.mail.comcast.net with comcast id QR0t1i0011vN32cAFRLeTr; Sun, 22 Jan 2012 01:20:38 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta22.emeryville.ca.mail.comcast.net with comcast id QRLc1i00W00PQ6U8iRLdg4; Sun, 22 Jan 2012 01:20:38 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.3) with ESMTP id q0M1KZAS024753 for ; Sat, 21 Jan 2012 20:20:35 -0500 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id q0M1KZ7u024752 for dane@ietf.org; Sat, 21 Jan 2012 20:20:35 -0500 Date: Sat, 21 Jan 2012 20:20:34 -0500 From: Scott Schmit To: dane@ietf.org Message-ID: <20120122012034.GA24296@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <59E1FDB4-B832-415A-BEE3-8E85CC55E337@vpnc.org> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="UlVJffcvxoiEqYs2" Content-Disposition: inline In-Reply-To: <59E1FDB4-B832-415A-BEE3-8E85CC55E337@vpnc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Pseudocode review X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2012 01:20:42 -0000 --UlVJffcvxoiEqYs2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 04, 2012 at 06:46:25AM -0800, Paul Hoffman wrote: > Greetings again. As Jakob indicated, we would *really* like to have a > careful review of the pseudocode now instead of waiting for WG Last > Call. TLSA has rules spread in many part of the body text, and the > pseudocode is supposed to pull every rule into one place, correctly. > Many developers like pseudocode, and will tend to focus on this > non-normative appendix rather than the body text. Ilari already found > one small error (thanks!), and we would like developer-like folks on > the list to poke harder at the section so that we are somewhat > confident that everyone understands what the protocol is doing. It looks correct, but some thoughts on how it could be better: I hate magic numbers. Since you're comfortable using enumerations elsewhere in the pseudocode, I'd recommend replacing 0/1/2 as arguments for Finish with ABORT_TLS/NO_TLSA/ACCEPT (or similar). Ideally, the usage/select/match numbers would be assigned to enumerations as well, but they're defined in the spec, so they aren't as big a deal. It's alluded to in Section 4.4, but it would probably be good to add "in conflict with local policy" and/or "with insufficient security per local policy" to the list of reasons that a record might be unusable. This helps resolve issue #35. In various places, you use R.foo to represent fields in the TLSA record, but then use R when you should use R.cert (partly fixable by having the helper functions use X.cert or Y.cert, but also shows up in the trust anchor handling section). It's obvious what you mean, but programming trains us to be literal. Grammar/spelling: final comment should read "if here, then none of the TLSA records were sufficient for TLS" Nits you can ignore if you want given your disclaimer on the pseudocode: It feels weird to me to do all the work to validate the EE cert against the chain before even checking if one of the certs in it match the one specified by the TLSA record. That said, it is pseudocode; deployed code will almost certainly look very different anyway. This pseudocode implies that the TLSA checker will/should search possible PKIX chains more thoroughly than the client normally would to try to find a match. This is a little out of step with the warnings in A.1.1. (And the main text is silent on the question.) Your Select & Match functions can return undef, but you don't handle them. Of course, your filtering should have removed the records that would cause the functions to return undef before these functions get them, but it would probably be better to mark those lines as unreachable (with this pseudocode). That makes it clear that receiving those values is a coding error. Hope this helps, --=20 Scott Schmit --UlVJffcvxoiEqYs2 Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQJgYJKoZIhvcNAQcCoIIQFzCCEBMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DVcwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBxswggYDoAMCAQICAwK+HTANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTExMDcxNzA1 MDQwNFoXDTEyMDcxNzExNDI1OVowYjEgMB4GA1UEDRMXNDY1MjU2LTBnRmI2Sk5ZWW44QnFW bUwxGzAZBgNVBAMMEmkuZ3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9r QGNvbWNhc3QubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2AjLOMsBGaqN hv2FcRbfom/QCeKMXu5tUd1JY5oIDZe5y29stnd+se/zUlEkiVeMam4Jgo1c8yGNnwLVYc5/ 9xVi7Qg1Is5b9AB6aJWElJDw/jIdihymNZ2kwkSLT0wl/lzd0mXlwFJPRgQiRkmE6V0ZmjsQ jaVtllVleGBbMvmWPm92e+4Bju9P81kKz7Xr02ijETmaPdVsl+jmOaKPS8Y+2Lat2xus4Ked oJ/7aIWIpz1gRSKjAHSZ1Wmwi2TYUjYhZryChu9e1RWtqk1CycNoeusJ8xdEVN3WSnJ299w/ 3ltK/x/9rpj2j9ShQZVB4NnX6cjQs7pz1lVxvIkjcQIDAQABo4IDrTCCA6kwCQYDVR0TBAIw ADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBQ29j2I0O8sRYi0So9NwwmT1caakDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhR gjAdBgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwggIhBgNVHSAEggIYMIICFDCCAhAG CysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJt ZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUF BwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJp bGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFu ZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0 cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQAZ5U0nL/2PQwsVfHgN7MVPbZEGzDzuj4Oy pTgz4XQFwPcCuy6U9sp1Dwmo3DyKX5nKN4xA7pslN+2Pl/kElGamX7zMCAH0xED0RTOLyk+v nDML4s+OUtWaYVnq1bZEp0F8Luq3zIslAYSebleyiz8M0EypZczsL5rOk86R2F9EYw1CBuFJ 5a4x0CmNu5o30fGNDFt+iXRlbJPp/KY25iUgVnBzJ4COT5kQjxn5lgr4t1I+BDCL5HQQ3h/8 2CzwrWVRBNb9Vqh9LL1ZtzYRt8JezoB6HkVvcKVNGlCZ+/MnvfMzPLwfbTDZC8o4d+4RH6aE LeGF2XmAOaenc/YRqm9oMYIClzCCApMCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQIDAr4dMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTIwMTIyMDEyMDM0WjAjBgkqhkiG9w0BCQQxFgQUGPIchHK7 C7ugVfaP7GW9W4xj48oweQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAbhRmRAbp xCMzq4C9va8XzhWGB4YjNujBRwadR6QGiHuxAg4Bgrqxl6kcgSwhc48gQjvyld5W5g+k4Dtc JYDFDyjkFx6JWqj/fQMNOJiwHgyAElx1ZV5BwC07MfKuCQC3wFbMNVcoexnVlg2KtKdWwUHZ oRDnY2zQ88U1kqFjgFdMxGgnAeGW8LVl9Z4cIEiVkTUT7jG2ydAKAzrykZQA11VlzDR1ldBq OR0MH//kWOBGHoYgCq0Mj4z17byt/H2iu971f/xGlXaiKuHf7In5MEzVK5VtyooiNCuClEN7 j5WHDw5UFdvEPWrgmIpMllOe42FwOkyjqxyS4beUtSLSYw== --UlVJffcvxoiEqYs2-- From tom@ritter.vg Sat Jan 21 20:31:47 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19CC621F841A for ; Sat, 21 Jan 2012 20:31:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.912 X-Spam-Level: X-Spam-Status: No, score=-2.912 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRJsdV6iP6Pi for ; Sat, 21 Jan 2012 20:31:46 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8FD21F849A for ; Sat, 21 Jan 2012 20:31:38 -0800 (PST) Received: by werp11 with SMTP id p11so1670727wer.31 for ; Sat, 21 Jan 2012 20:31:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :x-gm-message-state:content-type; bh=6S/z6SJDGX68fUBu0wrm2FuaNwsp4iVxQlT2Oo2ZHRs=; b=mHFMPNuHtidM2REah0cZnguI7vkWUmATRSTkOHAkTs9Q7az5RavS3milEXUTTNHIlH VsS2pv7Fy2jhybXBK6TqsfvjZ3coVaSDs0h+AjtZLsugd/DO9bkhfkgmi4c7nuPBEqld hjUma8hERqish4fRg5fY6K8NOsnp3LZ0PrGCU= Received: by 10.216.133.142 with SMTP id q14mr1418885wei.57.1327206697319; Sat, 21 Jan 2012 20:31:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.63.145 with HTTP; Sat, 21 Jan 2012 20:31:16 -0800 (PST) In-Reply-To: <20120121225503.GA24203@odin.ulthar.us> References: <20120117193930.GA29471@vacation.karoshi.com.> <20120121225503.GA24203@odin.ulthar.us> From: Tom Ritter Date: Sat, 21 Jan 2012 23:31:16 -0500 Message-ID: To: dane@ietf.org X-Gm-Message-State: ALoCoQlzGM+R03CPT8fxSEPJTfhwB7/J2wfdL9WQIZIaWZFQGyoctpaPPFuCjR8KUT951DWSKEXu Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [dane] existence proof X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2012 04:31:47 -0000 On 21 January 2012 17:55, Scott Schmit wrote: > I don't know of any others. Mike Cardwell has his set up also, along with SSH, PGP, and DKIM: https://grepular.com/Understanding_DNSSEC $ dig +short TYPE65468 _443._tcp.grepular.com \# 35 010101FDA20E60D267270D6E009C196B323C33D3EB7BFC8AF0E8FE4C F7BF563CB5A55D -tom From hannes.tschofenig@gmx.net Sun Jan 22 06:55:24 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C89CE21F84C8 for ; Sun, 22 Jan 2012 06:55:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxH621d5eEYm for ; Sun, 22 Jan 2012 06:55:24 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id E389221F84B4 for ; Sun, 22 Jan 2012 06:55:23 -0800 (PST) Received: (qmail invoked by alias); 22 Jan 2012 14:55:21 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.106]) [88.115.216.191] by mail.gmx.net (mp027) with SMTP; 22 Jan 2012 15:55:21 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19T8m8ZzIFTArDJh5WrtH0VP90citHkRiOrllpLFa usWHhkgP97rzC6 From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 22 Jan 2012 16:55:21 +0200 Message-Id: To: dane@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [dane] Question regarding draft-ietf-dane-protocol-14 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2012 14:55:24 -0000 Hi all,=20 I have a question regarding the support of raw public keys with DANE.=20 =46rom browsing through draft-ietf-dane-protocol-14 I understand that = you make use of the subjectPublicKeyInfo structure defined in RFC 5280.=20= My question: Do you dump the subjectPublicKeyInfo directly into a RR or = do you put an entire PKIX certificate in a RR but only the = subjectPublicKeyInfo field is "read" (and the rest is ignored)? Ciao Hannes From i.grok@comcast.net Sun Jan 22 08:24:34 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B08E921F84A0 for ; Sun, 22 Jan 2012 08:24:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.184 X-Spam-Level: X-Spam-Status: No, score=-102.184 tagged_above=-999 required=5 tests=[AWL=0.415, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9yUvnAxaI7n for ; Sun, 22 Jan 2012 08:24:34 -0800 (PST) Received: from qmta14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [76.96.27.212]) by ietfa.amsl.com (Postfix) with ESMTP id 49EAB21F8494 for ; Sun, 22 Jan 2012 08:24:34 -0800 (PST) Received: from omta01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by qmta14.emeryville.ca.mail.comcast.net with comcast id QgNW1i0030EPchoAEgQaUp; Sun, 22 Jan 2012 16:24:34 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta01.emeryville.ca.mail.comcast.net with comcast id QgQY1i00D00PQ6U8MgQZ8V; Sun, 22 Jan 2012 16:24:33 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.3) with ESMTP id q0MGOVDD006521 for ; Sun, 22 Jan 2012 11:24:31 -0500 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id q0MGOVSq006520 for dane@ietf.org; Sun, 22 Jan 2012 11:24:31 -0500 Date: Sun, 22 Jan 2012 11:24:31 -0500 From: Scott Schmit To: dane@ietf.org Message-ID: <20120122162431.GA14597@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="6TrnltStXW4iwmi0" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Question regarding draft-ietf-dane-protocol-14 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2012 16:24:34 -0000 --6TrnltStXW4iwmi0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 22, 2012 at 04:55:21PM +0200, Hannes Tschofenig wrote: > I have a question regarding the support of raw public keys with DANE.=20 >=20 > From browsing through draft-ietf-dane-protocol-14 I understand that > you make use of the subjectPublicKeyInfo structure defined in RFC > 5280.=20 >=20 > My question: Do you dump the subjectPublicKeyInfo directly into a RR > or do you put an entire PKIX certificate in a RR but only the > subjectPublicKeyInfo field is "read" (and the rest is ignored)? I think we intended the former, and the pseudocode agrees with me--it selects the SPKI from the cert and then does a match against the certificate data (whether full or hash) in the record. That said, the wording in 2.1.2 is ambiguous. Perhaps replacing: # A one-octet value, called "selector", specifying what will be # matched. with # A one-octet value, called "selector", specifying what the association # data will be matched against from the TLS certificate presented by # the server. would make this clearer? That said, calling the "Certficate for Association" field a certificate probably causes more of the confusion. Calling it "association data" or "matching data" would be better. Sometimes it's a certificate, sometimes it's a hash of a certificate, sometimes it's a SPKI, and sometimes it's a hash of an SPKI. --=20 Scott Schmit --6TrnltStXW4iwmi0 Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQJgYJKoZIhvcNAQcCoIIQFzCCEBMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DVcwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBxswggYDoAMCAQICAwK+HTANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTExMDcxNzA1 MDQwNFoXDTEyMDcxNzExNDI1OVowYjEgMB4GA1UEDRMXNDY1MjU2LTBnRmI2Sk5ZWW44QnFW bUwxGzAZBgNVBAMMEmkuZ3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9r QGNvbWNhc3QubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2AjLOMsBGaqN hv2FcRbfom/QCeKMXu5tUd1JY5oIDZe5y29stnd+se/zUlEkiVeMam4Jgo1c8yGNnwLVYc5/ 9xVi7Qg1Is5b9AB6aJWElJDw/jIdihymNZ2kwkSLT0wl/lzd0mXlwFJPRgQiRkmE6V0ZmjsQ jaVtllVleGBbMvmWPm92e+4Bju9P81kKz7Xr02ijETmaPdVsl+jmOaKPS8Y+2Lat2xus4Ked oJ/7aIWIpz1gRSKjAHSZ1Wmwi2TYUjYhZryChu9e1RWtqk1CycNoeusJ8xdEVN3WSnJ299w/ 3ltK/x/9rpj2j9ShQZVB4NnX6cjQs7pz1lVxvIkjcQIDAQABo4IDrTCCA6kwCQYDVR0TBAIw ADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBQ29j2I0O8sRYi0So9NwwmT1caakDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhR gjAdBgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwggIhBgNVHSAEggIYMIICFDCCAhAG CysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJt ZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUF BwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJp bGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFu ZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0 cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQAZ5U0nL/2PQwsVfHgN7MVPbZEGzDzuj4Oy pTgz4XQFwPcCuy6U9sp1Dwmo3DyKX5nKN4xA7pslN+2Pl/kElGamX7zMCAH0xED0RTOLyk+v nDML4s+OUtWaYVnq1bZEp0F8Luq3zIslAYSebleyiz8M0EypZczsL5rOk86R2F9EYw1CBuFJ 5a4x0CmNu5o30fGNDFt+iXRlbJPp/KY25iUgVnBzJ4COT5kQjxn5lgr4t1I+BDCL5HQQ3h/8 2CzwrWVRBNb9Vqh9LL1ZtzYRt8JezoB6HkVvcKVNGlCZ+/MnvfMzPLwfbTDZC8o4d+4RH6aE LeGF2XmAOaenc/YRqm9oMYIClzCCApMCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQIDAr4dMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTIwMTIyMTYyNDMxWjAjBgkqhkiG9w0BCQQxFgQUojiTobhO VplTAQkWMqmBHj2h7ZMweQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAPew8XZWs WzOH/n1O3f874BJMPz29tvYdK/6+sub14di1GMZMD/S7VfO3qSF2iBorPU4udpChcfq+JoGO 4uITi5ddxklfL/uc2L3TvA7z85gme0wYJi+C7NkFYDK7+wCzf7PJpBxoli0Bb7p7xHZJRcyJ 7mvvsizV0YKmf3syr4DGNif2my06HVTr4VJvoHpe4nUbzg7Mryq6cZb6hEQgDZ1T/qXAc6Wz lv4iCtqiE2ConMPXGhzeNNyr/ZCYGS6Sf7MjJVPmu0c7Qd8rIk2/hay/+DDbj+1obq1fu1tf WThWue2pJvBzwsrYMKWIZtrD5xbtP3xYffzm8LAvMiTXbQ== --6TrnltStXW4iwmi0-- From paul.hoffman@vpnc.org Sun Jan 22 09:17:04 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09BD821F843A for ; Sun, 22 Jan 2012 09:17:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hP0LlvQkNtB4 for ; Sun, 22 Jan 2012 09:17:03 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE9521F8438 for ; Sun, 22 Jan 2012 09:17:03 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q0MHGvW7008518 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 22 Jan 2012 10:16:57 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20120122162431.GA14597@odin.ulthar.us> Date: Sun, 22 Jan 2012 09:16:56 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3E901143-0E83-4D14-A9F4-4382B32C3647@vpnc.org> References: <20120122162431.GA14597@odin.ulthar.us> To: Scott Schmit X-Mailer: Apple Mail (2.1251.1) Cc: dane@ietf.org Subject: Re: [dane] Question regarding draft-ietf-dane-protocol-14 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2012 17:17:04 -0000 On Jan 22, 2012, at 8:24 AM, Scott Schmit wrote: > That said, the wording in 2.1.2 is ambiguous. Perhaps replacing: >=20 > # A one-octet value, called "selector", specifying what will be > # matched. >=20 > with >=20 > # A one-octet value, called "selector", specifying what the = association > # data will be matched against from the TLS certificate presented by > # the server. >=20 > would make this clearer? Yes. Will be in -15. > That said, calling the "Certficate for Association" field a = certificate > probably causes more of the confusion. Calling it "association data" > or "matching data" would be better. Sometimes it's a certificate, > sometimes it's a hash of a certificate, sometimes it's a SPKI, and > sometimes it's a hash of an SPKI. I'm hesitant to make that change now, but it is something worth = discussing in WGLC. --Paul Hoffman From paul.hoffman@vpnc.org Sun Jan 22 09:35:45 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1037421F8537 for ; Sun, 22 Jan 2012 09:35:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.951 X-Spam-Level: X-Spam-Status: No, score=-101.951 tagged_above=-999 required=5 tests=[AWL=-0.552, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0kUfS8698P5 for ; Sun, 22 Jan 2012 09:35:44 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 72C1C21F8533 for ; Sun, 22 Jan 2012 09:35:44 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q0MHZgZ6008971 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 22 Jan 2012 10:35:43 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20120122012034.GA24296@odin.ulthar.us> Date: Sun, 22 Jan 2012 09:35:42 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <59E1FDB4-B832-415A-BEE3-8E85CC55E337@vpnc.org> <20120122012034.GA24296@odin.ulthar.us> To: Scott Schmit X-Mailer: Apple Mail (2.1251.1) Cc: dane@ietf.org Subject: Re: [dane] Pseudocode review X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2012 17:35:45 -0000 On Jan 21, 2012, at 5:20 PM, Scott Schmit wrote: > It looks correct, but some thoughts on how it could be better: >=20 > I hate magic numbers. Since you're comfortable using enumerations > elsewhere in the pseudocode, I'd recommend replacing 0/1/2 as = arguments > for Finish with ABORT_TLS/NO_TLSA/ACCEPT (or similar). Good call. Done. > Ideally, the > usage/select/match numbers would be assigned to enumerations as well, > but they're defined in the spec, so they aren't as big a deal. It would be better to keep them aligned with the spec instead of adding = a level of indirection with some equivalences. > It's alluded to in Section 4.4, but it would probably be good to add = "in > conflict with local policy" and/or "with insufficient security per = local > policy" to the list of reasons that a record might be unusable. This > helps resolve issue #35. Yes. > In various places, you use R.foo to represent fields in the TLSA = record, > but then use R when you should use R.cert (partly fixable by having = the > helper functions use X.cert or Y.cert, but also shows up in the trust > anchor handling section). It's obvious what you mean, but programming > trains us to be literal. Already noted before, already fixed. > Grammar/spelling: final comment should read "if here, then none of the > TLSA records were sufficient for TLS" Sure. > Nits you can ignore if you want given your disclaimer on the = pseudocode: >=20 > It feels weird to me to do all the work to validate the EE cert = against > the chain before even checking if one of the certs in it match the one > specified by the TLSA record. That said, it is pseudocode; deployed > code will almost certainly look very different anyway. Correct. I *think* the pseudocode matches the wording in the document = for linguistic order, even if it is not optimized for speed. If others = really want this change, we can make it. > This pseudocode implies that the TLSA checker will/should search > possible PKIX chains more thoroughly than the client normally would to > try to find a match. This is a little out of step with the warnings in > A.1.1. (And the main text is silent on the question.) I'm not sure what you mean here; please say more. > Your Select & Match functions can return undef, but you don't handle > them. Of course, your filtering should have removed the records that > would cause the functions to return undef before these functions get > them, but it would probably be better to mark those lines as = unreachable > (with this pseudocode). That makes it clear that receiving those = values > is a coding error. Checking for coding errors is not the correct way to do this. I have = replaced "return undef" with "// unreachable", just like we have for the = Finish function. > Hope this helps, Definitely, but I still want to know more about the one noted above. --Paul Hoffman From i.grok@comcast.net Sun Jan 22 10:33:30 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E84C21F854B for ; Sun, 22 Jan 2012 10:33:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.23 X-Spam-Level: X-Spam-Status: No, score=-102.23 tagged_above=-999 required=5 tests=[AWL=0.369, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSJhLAxVJNHZ for ; Sun, 22 Jan 2012 10:33:29 -0800 (PST) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by ietfa.amsl.com (Postfix) with ESMTP id 93F3221F8548 for ; Sun, 22 Jan 2012 10:33:29 -0800 (PST) Received: from omta09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by qmta03.emeryville.ca.mail.comcast.net with comcast id QiTv1i0080S2fkCA3iZV46; Sun, 22 Jan 2012 18:33:29 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta09.emeryville.ca.mail.comcast.net with comcast id QiZU1i00500PQ6U8ViZUxq; Sun, 22 Jan 2012 18:33:29 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.3) with ESMTP id q0MIXQE2006842 for ; Sun, 22 Jan 2012 13:33:26 -0500 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id q0MIXPEq006841 for dane@ietf.org; Sun, 22 Jan 2012 13:33:25 -0500 Date: Sun, 22 Jan 2012 13:33:25 -0500 From: Scott Schmit To: dane@ietf.org Message-ID: <20120122183325.GA6635@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <59E1FDB4-B832-415A-BEE3-8E85CC55E337@vpnc.org> <20120122012034.GA24296@odin.ulthar.us> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="ReaqsoxgOBHFXBhH" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Pseudocode review X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2012 18:33:30 -0000 --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 22, 2012 at 09:35:42AM -0800, Paul Hoffman wrote: > On Jan 21, 2012, at 5:20 PM, Scott Schmit wrote: > > This pseudocode implies that the TLSA checker will/should search > > possible PKIX chains more thoroughly than the client normally would to > > try to find a match. This is a little out of step with the warnings in > > A.1.1. (And the main text is silent on the question.) >=20 > I'm not sure what you mean here; please say more. Sure. In the pseudocode: // A TLS client might have multiple trust anchors that it might use // when validating the TLS server's end entity certificate. Also, // there can be multiple PKIX validation chains for the // certificates given by the server in TLS. Thus, there are // possibly many chains that might need to be tested during // PKIX validation. Normally, if there are multiple possible chains between the certificate and a trust anchor, the client will stop after finding the first chain that validates successfully. Here, it checks every possibility until it either finds a TLSA match or finds none at all. In A.1.1, the text implies that the client will stop after finding the first chain that works, so the operator should chose their anchor with care, because the association could fail for some clients or under some conditions (e.g., the client has or hasn't visited a site with an alternate certificate recently). --=20 Scott Schmit --ReaqsoxgOBHFXBhH Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQJgYJKoZIhvcNAQcCoIIQFzCCEBMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DVcwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBxswggYDoAMCAQICAwK+HTANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTExMDcxNzA1 MDQwNFoXDTEyMDcxNzExNDI1OVowYjEgMB4GA1UEDRMXNDY1MjU2LTBnRmI2Sk5ZWW44QnFW bUwxGzAZBgNVBAMMEmkuZ3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9r QGNvbWNhc3QubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2AjLOMsBGaqN hv2FcRbfom/QCeKMXu5tUd1JY5oIDZe5y29stnd+se/zUlEkiVeMam4Jgo1c8yGNnwLVYc5/ 9xVi7Qg1Is5b9AB6aJWElJDw/jIdihymNZ2kwkSLT0wl/lzd0mXlwFJPRgQiRkmE6V0ZmjsQ jaVtllVleGBbMvmWPm92e+4Bju9P81kKz7Xr02ijETmaPdVsl+jmOaKPS8Y+2Lat2xus4Ked oJ/7aIWIpz1gRSKjAHSZ1Wmwi2TYUjYhZryChu9e1RWtqk1CycNoeusJ8xdEVN3WSnJ299w/ 3ltK/x/9rpj2j9ShQZVB4NnX6cjQs7pz1lVxvIkjcQIDAQABo4IDrTCCA6kwCQYDVR0TBAIw ADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBQ29j2I0O8sRYi0So9NwwmT1caakDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhR gjAdBgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwggIhBgNVHSAEggIYMIICFDCCAhAG CysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJt ZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUF BwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJp bGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFu ZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0 cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQAZ5U0nL/2PQwsVfHgN7MVPbZEGzDzuj4Oy pTgz4XQFwPcCuy6U9sp1Dwmo3DyKX5nKN4xA7pslN+2Pl/kElGamX7zMCAH0xED0RTOLyk+v nDML4s+OUtWaYVnq1bZEp0F8Luq3zIslAYSebleyiz8M0EypZczsL5rOk86R2F9EYw1CBuFJ 5a4x0CmNu5o30fGNDFt+iXRlbJPp/KY25iUgVnBzJ4COT5kQjxn5lgr4t1I+BDCL5HQQ3h/8 2CzwrWVRBNb9Vqh9LL1ZtzYRt8JezoB6HkVvcKVNGlCZ+/MnvfMzPLwfbTDZC8o4d+4RH6aE LeGF2XmAOaenc/YRqm9oMYIClzCCApMCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQIDAr4dMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTIwMTIyMTgzMzI1WjAjBgkqhkiG9w0BCQQxFgQU55SBx4+I ToLVo+EQKFJ6AN6d4fMweQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAii5qP4qE SwBbuIBMeG79FzkRnrPZKsly5FtHX2Ippt4x603XiP0y5RAyxF2YYCy+eVdSzFIDEhdZKVpo 10Sq5QQbZ5Ht6czG+T2jV4LkNgXpwAELPn5sLHdHoQ4O+KrHvPH909yOE0F/8rnP2cxPwDB5 ar3VJUwRN5e3FgwrTCLt+dzefOwfvRwiL8j99qadcXjzctZYeAyDxDqDgTwNASWurEZv/lh1 x4aSRA3B2S/gQXWOqeGf9t7AGTFkA7uqH3l6vgw93HcYcUH/I8/YEb66XNTgPZDzwwlkEDPH TWD1vnjBxcOy9JVgAGWsg1A9tf6DqDYatZr+0Tv7osXHzQ== --ReaqsoxgOBHFXBhH-- From hannes.tschofenig@gmx.net Sun Jan 22 10:36:32 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C40AF21F854B for ; Sun, 22 Jan 2012 10:36:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYXbtQA30Ojq for ; Sun, 22 Jan 2012 10:36:32 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 493D821F8548 for ; Sun, 22 Jan 2012 10:36:31 -0800 (PST) Received: (qmail invoked by alias); 22 Jan 2012 18:36:29 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.112]) [88.115.216.191] by mail.gmx.net (mp006) with SMTP; 22 Jan 2012 19:36:29 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18Lm/02sNYLd0X6SQyoLUxNuYcRysnz0nOuzdt4Xe Vt2IV/1i2G/Mdm Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <20120122162431.GA14597@odin.ulthar.us> Date: Sun, 22 Jan 2012 20:36:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1794A357-2969-4762-85F6-FFF27561F0B2@gmx.net> References: <20120122162431.GA14597@odin.ulthar.us> To: Scott Schmit X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: dane@ietf.org Subject: Re: [dane] Question regarding draft-ietf-dane-protocol-14 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2012 18:36:32 -0000 Hi Scott,=20 thanks for the quick response.=20 Good to hear that you use the subjectPublicKeyInfo block (without the = rest of the elements in the Certificate structure).=20 A follow-up question: Is there code available to create DER encoded = subjectPublicKeyInfo blocks and to decode them? Ciao Hannes PS: Regarding readability I have to say that=20 a) I didn't follow the work closely, =20 b) I am only interested in the raw public key based variant, and=20 c) the document mostly talks about putting certificates into the DNS.=20 For this reason it is a bit confusing.=20 On Jan 22, 2012, at 6:24 PM, Scott Schmit wrote: > On Sun, Jan 22, 2012 at 04:55:21PM +0200, Hannes Tschofenig wrote: >> I have a question regarding the support of raw public keys with DANE.=20= >>=20 >> =46rom browsing through draft-ietf-dane-protocol-14 I understand that >> you make use of the subjectPublicKeyInfo structure defined in RFC >> 5280.=20 >>=20 >> My question: Do you dump the subjectPublicKeyInfo directly into a RR >> or do you put an entire PKIX certificate in a RR but only the >> subjectPublicKeyInfo field is "read" (and the rest is ignored)? >=20 > I think we intended the former, and the pseudocode agrees with me--it > selects the SPKI from the cert and then does a match against the > certificate data (whether full or hash) in the record. >=20 > That said, the wording in 2.1.2 is ambiguous. Perhaps replacing: >=20 > # A one-octet value, called "selector", specifying what will be > # matched. >=20 > with >=20 > # A one-octet value, called "selector", specifying what the = association > # data will be matched against from the TLS certificate presented by > # the server. >=20 > would make this clearer? >=20 > That said, calling the "Certficate for Association" field a = certificate > probably causes more of the confusion. Calling it "association data" > or "matching data" would be better. Sometimes it's a certificate, > sometimes it's a hash of a certificate, sometimes it's a SPKI, and > sometimes it's a hash of an SPKI. >=20 > --=20 > Scott Schmit > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From i.grok@comcast.net Sun Jan 22 10:37:21 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB9D621F853F for ; Sun, 22 Jan 2012 10:37:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.267 X-Spam-Level: X-Spam-Status: No, score=-102.267 tagged_above=-999 required=5 tests=[AWL=0.332, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zUjIGf4ukPdq for ; Sun, 22 Jan 2012 10:37:21 -0800 (PST) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by ietfa.amsl.com (Postfix) with ESMTP id 3050C21F8548 for ; Sun, 22 Jan 2012 10:37:21 -0800 (PST) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by QMTA11.westchester.pa.mail.comcast.net with comcast id QemP1i0041uE5Es5BidMmX; Sun, 22 Jan 2012 18:37:21 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta16.westchester.pa.mail.comcast.net with comcast id QidM1i00h00PQ6U3cidM48; Sun, 22 Jan 2012 18:37:21 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.3) with ESMTP id q0MIbKAm006862 for ; Sun, 22 Jan 2012 13:37:20 -0500 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id q0MIbJ1F006861 for dane@ietf.org; Sun, 22 Jan 2012 13:37:19 -0500 Date: Sun, 22 Jan 2012 13:37:19 -0500 From: Scott Schmit To: dane@ietf.org Message-ID: <20120122183719.GB14597@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <59E1FDB4-B832-415A-BEE3-8E85CC55E337@vpnc.org> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="wzJLGUyc3ArbnUjN" Content-Disposition: inline In-Reply-To: <59E1FDB4-B832-415A-BEE3-8E85CC55E337@vpnc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Pseudocode review X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2012 18:37:22 -0000 --wzJLGUyc3ArbnUjN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 04, 2012 at 06:46:25AM -0800, Paul Hoffman wrote: > Greetings again. As Jakob indicated, we would *really* like to have a > careful review of the pseudocode now instead of waiting for WG Last > Call. TLSA has rules spread in many part of the body text, and the > pseudocode is supposed to pull every rule into one place, correctly. > Many developers like pseudocode, and will tend to focus on this > non-normative appendix rather than the body text. Ilari already found > one small error (thanks!), and we would like developer-like folks on > the list to poke harder at the section so that we are somewhat > confident that everyone understands what the protocol is doing. Sorry I missed this the first time, but I notice that with certificate usage type 2, the pseudocode doesn't pay attention to the selector type or match type fields. At the same time, there's no enforcement of the implicit rule that the selector type will be 0 and the match type 0. Also, nothing in the text says anything approaching "if the usage is 2, the selector type and match type MUST be 0". I don't think such a rule is necessary, provided the trust anchor used is a commonly-known one. For private trust anchors, they'll need to use matching type 0 and selector type 0 if the connection is going to succeed. Selector type 1 implies that the client has a full certificate to extract the SPKI from, which in this case, it wouldn't. Perhaps that should be in the text somewhere. --=20 Scott Schmit --wzJLGUyc3ArbnUjN Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQJgYJKoZIhvcNAQcCoIIQFzCCEBMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DVcwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBxswggYDoAMCAQICAwK+HTANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTExMDcxNzA1 MDQwNFoXDTEyMDcxNzExNDI1OVowYjEgMB4GA1UEDRMXNDY1MjU2LTBnRmI2Sk5ZWW44QnFW bUwxGzAZBgNVBAMMEmkuZ3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9r QGNvbWNhc3QubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2AjLOMsBGaqN hv2FcRbfom/QCeKMXu5tUd1JY5oIDZe5y29stnd+se/zUlEkiVeMam4Jgo1c8yGNnwLVYc5/ 9xVi7Qg1Is5b9AB6aJWElJDw/jIdihymNZ2kwkSLT0wl/lzd0mXlwFJPRgQiRkmE6V0ZmjsQ jaVtllVleGBbMvmWPm92e+4Bju9P81kKz7Xr02ijETmaPdVsl+jmOaKPS8Y+2Lat2xus4Ked oJ/7aIWIpz1gRSKjAHSZ1Wmwi2TYUjYhZryChu9e1RWtqk1CycNoeusJ8xdEVN3WSnJ299w/ 3ltK/x/9rpj2j9ShQZVB4NnX6cjQs7pz1lVxvIkjcQIDAQABo4IDrTCCA6kwCQYDVR0TBAIw ADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBQ29j2I0O8sRYi0So9NwwmT1caakDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhR gjAdBgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwggIhBgNVHSAEggIYMIICFDCCAhAG CysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJt ZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUF BwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJp bGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFu ZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0 cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQAZ5U0nL/2PQwsVfHgN7MVPbZEGzDzuj4Oy pTgz4XQFwPcCuy6U9sp1Dwmo3DyKX5nKN4xA7pslN+2Pl/kElGamX7zMCAH0xED0RTOLyk+v nDML4s+OUtWaYVnq1bZEp0F8Luq3zIslAYSebleyiz8M0EypZczsL5rOk86R2F9EYw1CBuFJ 5a4x0CmNu5o30fGNDFt+iXRlbJPp/KY25iUgVnBzJ4COT5kQjxn5lgr4t1I+BDCL5HQQ3h/8 2CzwrWVRBNb9Vqh9LL1ZtzYRt8JezoB6HkVvcKVNGlCZ+/MnvfMzPLwfbTDZC8o4d+4RH6aE LeGF2XmAOaenc/YRqm9oMYIClzCCApMCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQIDAr4dMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTIwMTIyMTgzNzE5WjAjBgkqhkiG9w0BCQQxFgQU1kjB0ikq pCY8eu8qL8Id6R9aq/MweQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAItZowYPT XUPQYdeokMIsppT/p4FuDUbHYclXzw3ZU/VFnLjmhn2ixUOgmiyhNHwEFBiJT5sv8Ejapo2T Rrx1KgAj6zGi/EfaMu89exARXH7AgVQ2Yor19frP5HMCZlmVgszALZIdJlPLHYH7SoLKWnLT RAQ5o4MpeHJ4T6RFQvNMPsreXv5SErKvBAQMmXmG1fRGUBlzl8kig1YJ3v7ODmYqF1y0MbJj KIgjjOMg9OJCWW5Mt8hubozSXRaepOLcZWSRVXzgkczcfMD/BDew1Eyfw7uXFILnJ8u7C/7G nV0NMstAMY3NS1a7qCuX9Mvj1NhC9XU4tVFcOH8P2xNzPA== --wzJLGUyc3ArbnUjN-- From Pieter.Lexis@os3.nl Sun Jan 22 10:45:55 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29C5A21F855A for ; Sun, 22 Jan 2012 10:45:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYpFZfDYG7hJ for ; Sun, 22 Jan 2012 10:45:54 -0800 (PST) Received: from mail.serv.os3.nl (mail.serv.os3.nl [IPv6:2001:610:158:960::25]) by ietfa.amsl.com (Postfix) with ESMTP id 7E93321F852F for ; Sun, 22 Jan 2012 10:45:54 -0800 (PST) Received: from webmail.os3.nl (mail.serv.os3.nl [IPv6:2001:610:158:960::25]) by mail.serv.os3.nl (Postfix) with ESMTP id 4291217AA01; Sun, 22 Jan 2012 19:45:53 +0100 (CET) Received: from 83.160.107.2 (SquirrelMail authenticated user plexis) by webmail.os3.nl with HTTP; Sun, 22 Jan 2012 19:45:53 +0100 (CET) Message-ID: <41545.83.160.107.2.1327257953.squirrel@webmail.os3.nl> In-Reply-To: <1794A357-2969-4762-85F6-FFF27561F0B2@gmx.net> References: <20120122162431.GA14597@odin.ulthar.us> <1794A357-2969-4762-85F6-FFF27561F0B2@gmx.net> Date: Sun, 22 Jan 2012 19:45:53 +0100 (CET) From: Pieter.Lexis@os3.nl To: "Hannes Tschofenig" User-Agent: SquirrelMail/1.4.13 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: dane@ietf.org Subject: Re: [dane] Question regarding draft-ietf-dane-protocol-14 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2012 18:45:55 -0000 Hi Hannes, > A follow-up question: Is there code available to create DER encoded > subjectPublicKeyInfo blocks and to decode them? I use python for doing this: Decoding can be done using the M2Crypto[0] library in python (a OpenSSL wrapper): from M2Crypto import X509 cert = X509.load_cert('/path/to/cert') print cert.get_pubkey().as_der() print cert.get_pubkey().as_text() For encoding, the M2Crypto.RSA module can be used afaik. -- Pieter Lexis 0 - http://www.heikkitoivonen.net/m2crypto/api/ From cloos@jhcloos.com Sun Jan 22 11:53:03 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF41521F8554 for ; Sun, 22 Jan 2012 11:53:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.188 X-Spam-Level: X-Spam-Status: No, score=-2.188 tagged_above=-999 required=5 tests=[AWL=0.412, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7lMlygNd-5qz for ; Sun, 22 Jan 2012 11:53:02 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by ietfa.amsl.com (Postfix) with ESMTP id 9086C21F854B for ; Sun, 22 Jan 2012 11:53:02 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 86E1F400FB; Sun, 22 Jan 2012 19:52:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1327261980; bh=NQxJR3cRXgQrKs2tQ9VdYFgjpgDJc593w0jiGaEIuQo=; h=From:To:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=EAst5H8gFIbri8syGf3wjoNYze+3b8bHq+GnhPr48GrU+u1qSP3qrDsha5lQDq/pD JQvinOm8uI0rZLT56y1QUWwYRxqNBPge8CqMUR5WAvIa6f4pixhT6r5fQ4IIEhhV0f ln1K/WgmGOAkImI+Rv8tF9XMvqRu+S5gLgsJCicA= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 92D6736004D; Sun, 22 Jan 2012 19:51:02 +0000 (UTC) From: James Cloos To: dane@ietf.org In-Reply-To: <20120122183719.GB14597@odin.ulthar.us> (Scott Schmit's message of "Sun, 22 Jan 2012 13:37:19 -0500") References: <59E1FDB4-B832-415A-BEE3-8E85CC55E337@vpnc.org> <20120122183719.GB14597@odin.ulthar.us> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.92 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2012 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Sun, 22 Jan 2012 14:51:02 -0500 Message-ID: Lines: 17 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:120122:dane@ietf.org::W8fC8QEgBprZR2Zv:000OdjcQ Subject: Re: [dane] Pseudocode review X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2012 19:53:03 -0000 >>>>> "SS" == Scott Schmit writes: SS> At the same time, there's no enforcement of the implicit rule that SS> the selector type will be 0 and the match type 0. Also, nothing in SS> the text says anything approaching "if the usage is 2, the selector SS> type and match type MUST be 0". What implicit rule? Why shouldn't 2 0 1 or 2 0 2 be OK? Or 2 1 1 or 2 1 2 for that matter? The tls server will send a cert chain, so matching a digest, spki or digest of an spki should be cryptographically secure. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From i.grok@comcast.net Sun Jan 22 12:45:11 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B457321F852F for ; Sun, 22 Jan 2012 12:45:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.297 X-Spam-Level: X-Spam-Status: No, score=-102.297 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQsZF1GpJ8UF for ; Sun, 22 Jan 2012 12:45:10 -0800 (PST) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by ietfa.amsl.com (Postfix) with ESMTP id 96D7221F84F1 for ; Sun, 22 Jan 2012 12:45:07 -0800 (PST) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta01.westchester.pa.mail.comcast.net with comcast id Qit61i0051uE5Es51kl8ba; Sun, 22 Jan 2012 20:45:08 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta16.westchester.pa.mail.comcast.net with comcast id Qkl71i00B00PQ6U3ckl798; Sun, 22 Jan 2012 20:45:07 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.3) with ESMTP id q0MKj5VJ007451 for ; Sun, 22 Jan 2012 15:45:05 -0500 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id q0MKj5BP007450 for dane@ietf.org; Sun, 22 Jan 2012 15:45:05 -0500 Date: Sun, 22 Jan 2012 15:45:05 -0500 From: Scott Schmit To: dane@ietf.org Message-ID: <20120122204505.GC14597@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <59E1FDB4-B832-415A-BEE3-8E85CC55E337@vpnc.org> <20120122183719.GB14597@odin.ulthar.us> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="Izn7cH1Com+I3R9J" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Pseudocode review X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2012 20:45:11 -0000 --Izn7cH1Com+I3R9J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 22, 2012 at 02:51:02PM -0500, James Cloos wrote: > >>>>> "SS" =3D=3D Scott Schmit writes: > SS> At the same time, there's no enforcement of the implicit rule that > SS> the selector type will be 0 and the match type 0. Also, nothing in > SS> the text says anything approaching "if the usage is 2, the selector > SS> type and match type MUST be 0". >=20 > What implicit rule? What I meant by implicit rule is that the pseudocode assumes that if the usage is 2, selector and match are 0, otherwise the pseudocode won't work. At the same time, it doesn't filter out 2 x y records where x !=3D 0 and y !=3D 0. > Why shouldn't 2 0 1 or 2 0 2 be OK? Or 2 1 1 or 2 1 2 for that matter? Sorry, I misremembered the rule concerning inclusion of the TA in the certificate chain sent by the server. Rereading the TLS RFC, I see that the server isn't required to send the TA's certificate, but it isn't prohibited from doing so either. I had assumed that the TA is always excluded. What I wrote is still true if the server chooses not to send it. As I explained in the following paragraph that you didn't quote, non-zero selector and match types will work fine as long as the client already knows the trust anchor. If the trust anchor is being introduced by the TLSA record, it's legal but won't work if trust anchors aren't included in the cert chain sent by the server. Apologies for the confusion. --=20 Scott Schmit --Izn7cH1Com+I3R9J Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQJgYJKoZIhvcNAQcCoIIQFzCCEBMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DVcwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBxswggYDoAMCAQICAwK+HTANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTExMDcxNzA1 MDQwNFoXDTEyMDcxNzExNDI1OVowYjEgMB4GA1UEDRMXNDY1MjU2LTBnRmI2Sk5ZWW44QnFW bUwxGzAZBgNVBAMMEmkuZ3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9r QGNvbWNhc3QubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2AjLOMsBGaqN hv2FcRbfom/QCeKMXu5tUd1JY5oIDZe5y29stnd+se/zUlEkiVeMam4Jgo1c8yGNnwLVYc5/ 9xVi7Qg1Is5b9AB6aJWElJDw/jIdihymNZ2kwkSLT0wl/lzd0mXlwFJPRgQiRkmE6V0ZmjsQ jaVtllVleGBbMvmWPm92e+4Bju9P81kKz7Xr02ijETmaPdVsl+jmOaKPS8Y+2Lat2xus4Ked oJ/7aIWIpz1gRSKjAHSZ1Wmwi2TYUjYhZryChu9e1RWtqk1CycNoeusJ8xdEVN3WSnJ299w/ 3ltK/x/9rpj2j9ShQZVB4NnX6cjQs7pz1lVxvIkjcQIDAQABo4IDrTCCA6kwCQYDVR0TBAIw ADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBQ29j2I0O8sRYi0So9NwwmT1caakDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhR gjAdBgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwggIhBgNVHSAEggIYMIICFDCCAhAG CysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJt ZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUF BwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJp bGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFu ZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0 cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQAZ5U0nL/2PQwsVfHgN7MVPbZEGzDzuj4Oy pTgz4XQFwPcCuy6U9sp1Dwmo3DyKX5nKN4xA7pslN+2Pl/kElGamX7zMCAH0xED0RTOLyk+v nDML4s+OUtWaYVnq1bZEp0F8Luq3zIslAYSebleyiz8M0EypZczsL5rOk86R2F9EYw1CBuFJ 5a4x0CmNu5o30fGNDFt+iXRlbJPp/KY25iUgVnBzJ4COT5kQjxn5lgr4t1I+BDCL5HQQ3h/8 2CzwrWVRBNb9Vqh9LL1ZtzYRt8JezoB6HkVvcKVNGlCZ+/MnvfMzPLwfbTDZC8o4d+4RH6aE LeGF2XmAOaenc/YRqm9oMYIClzCCApMCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQIDAr4dMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTIwMTIyMjA0NTA1WjAjBgkqhkiG9w0BCQQxFgQUQqGB01/2 w3ghTGuv+N726WlMwEwweQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAVoKGWm/Q EbPnACe/Rp7WmBgDtCNwzEJyGWxup4PTVZCqT8xZBvdbpvxguWEGeRIahUuDBCO7mxCGn/XT mvvtlZPQUnPELc3XzQaNLfi5zSXGdLgzCcA/0Tx66YCjs8bvCFxxzDZjxYgYHkL/C24UyjM4 J+GsOwiB+aLzFE5mJDXW34TBMm+9Jk5WSUrKGwCLX9+MA6POvDgUJNYlEwDmrqeXxIhx+V9x a7gJ/VGf5Ckxt3JOAyLlBH2l4ET0lKR6NCeUlfd1l99aKgyy7xcCYAAJmZXnTbuEUAIjtQYp c7owT6mr8SMF/ORmb5QItJUmd4fCfXVXK7ETrkr2LIc5aQ== --Izn7cH1Com+I3R9J-- From cloos@jhcloos.com Sun Jan 22 14:18:55 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C009C21F856C for ; Sun, 22 Jan 2012 14:18:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, J_CHICKENPOX_19=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id et9C3RoBkSiW for ; Sun, 22 Jan 2012 14:18:54 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by ietfa.amsl.com (Postfix) with ESMTP id 8E63A21F8562 for ; Sun, 22 Jan 2012 14:18:54 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 834C6400FB; Sun, 22 Jan 2012 22:18:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1327270733; bh=U98Vflywp+u7EQ74YQs5GscgCHESXojGon4DfMt90tw=; h=From:To:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=mIAANYAs8z1zZqsw+UsSVMDJuxg41VVYISc3gppo0oghOhgCqDOcQjQLY3MQWaeTJ +tnlr6uPBLKoUYO8o5YEkWHEbyW+dLgmdHikaCayJg6CrvYLu/9kPu2wfVzg6uXugn lfKrG1BkWEOVYpwgObkA9GYw6wko0tI3zfQLoEGk= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 8DF6B36004C; Sun, 22 Jan 2012 22:18:04 +0000 (UTC) From: James Cloos To: dane@ietf.org In-Reply-To: <20120122204505.GC14597@odin.ulthar.us> (Scott Schmit's message of "Sun, 22 Jan 2012 15:45:05 -0500") References: <59E1FDB4-B832-415A-BEE3-8E85CC55E337@vpnc.org> <20120122183719.GB14597@odin.ulthar.us> <20120122204505.GC14597@odin.ulthar.us> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.92 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2012 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Sun, 22 Jan 2012 17:18:04 -0500 Message-ID: Lines: 28 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:120122:dane@ietf.org::nJi/cv1JewlHQ8P8:0005NM+O Subject: Re: [dane] Pseudocode review X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2012 22:18:55 -0000 >>>>> "SS" == Scott Schmit writes: SS> What I meant by implicit rule is that the pseudocode assumes that if SS> the usage is 2, selector and match are 0, otherwise the pseudocode won't SS> work. At the same time, it doesn't filter out 2 x y records where x != 0 SS> and y != 0. OK. I thought you meant an implicit rule in the text, not in the pseudocode. Clearly my eyes must have glazed a bit when I first reviewed the peudocode; I think the R.certUsage == 2 case should have a (Match(matchingType, Select(selectorType, C), R) clause, too, like usage 1 does. SS> Rereading the TLS RFC, I see that the server isn't required to send SS> the TA's certificate, but it isn't prohibited from doing so SS> either. I had assumed that the TA is always excluded. What I wrote SS> is still true if the server chooses not to send it. My impression was that usage 2 was added primarily for the case where the chains have depth == 1. SS> Apologies for the confusion. Likewise! -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From matt@mattmccutchen.net Sun Jan 22 17:31:28 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78CFE21F8540 for ; Sun, 22 Jan 2012 17:31:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBdsLJklFF1q for ; Sun, 22 Jan 2012 17:31:27 -0800 (PST) Received: from homiemail-a6.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id C484921F84EC for ; Sun, 22 Jan 2012 17:31:27 -0800 (PST) Received: from homiemail-a6.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTP id 306CB598070 for ; Sun, 22 Jan 2012 17:31:27 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=message-id :subject:from:to:date:in-reply-to:references:content-type :content-transfer-encoding:mime-version; q=dns; s= mattmccutchen.net; b=geaGwyHXYaFHkH68mU6lXK5njXpO2WHqVNRn66OReLN CvDXM8aY/w6lAozx8CPpCOQLylQWaaLogl62EF82hfvYM8DFWw22GLP2259tY4tM 6BJfrymRKfSxfnBoAbN/upz1EovKewlvyAQ2VkFJZxcfhCHEoVG8jI2KjZ11A6fc = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= message-id:subject:from:to:date:in-reply-to:references :content-type:content-transfer-encoding:mime-version; s= mattmccutchen.net; bh=i88uelUUxKLjg9NIEJwPqGx9LjA=; b=APZqVXCJ/M jhQnPi+aQPsL4CFiIna96oXpP4NCIK21R4Z3jFmYzCuMkPB86VVOO0wX+KyAkL8y zd/UcovHKx/9O2NHb9u0Ybh+6Ku5VMVZ7qlyYM2EJoqcYMKQMO0dcBo1lHplPY9A irnqBTSJTuZzX12H9IHM2nQ5hXS0rVLxA= Received: from [IPv6:::1] (c-98-248-34-40.hsd1.ca.comcast.net [98.248.34.40]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTPSA id 1687F598069 for ; Sun, 22 Jan 2012 17:31:27 -0800 (PST) Message-ID: <1327282284.3558.10.camel@localhost> From: Matt McCutchen To: IETF DANE WG list Date: Sun, 22 Jan 2012 17:31:24 -0800 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Subject: Re: [dane] Opening Issue #37. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 01:31:28 -0000 On Sun, 2012-01-08 at 13:49 -0500, Warren Kumari wrote: > As threatened, I am opening DANE Issue #37 (We specifically waited till after the vacation to open it so that folk were around). > I would like us to discuss this issue (and try avoid going down any > rabbit holes (like rat holes, but more surreal)) and come to consensus > by Jan 23rd (around 2 weeks). Is it really possible that no one has commented on this, or am I somehow not seeing the messages? To reiterate what I said in the previous round of discussion: - When making a positive assertion (as I will be), the ability to specify the exact server certificate and not call PKIX validation at all would give me greater peace of mind. Make of that what you will. - As I observed at https://www.ietf.org/mail-archive/web/dane/current/msg03583.html, it is inconsistent that for restrictive assertions, we have separate usages for CA certificate (0) and server certificate (1), while for positive +restrictive assertions, we have a single usage for a CA certificate or a server certificate (2). If one would argue that we don't need a separate usage for a positive+restrictive assertion of a server certificate, the exact same argument would suggest that the current usages 0 and 1 should be combined. - If we do proceed with a single usage for positive+restrictive assertions with the understanding that the server certificate can serve as a trust anchor for itself, we need to make sure that implementations that do not take the same viewpoint internally (NSS) handle this case as we intend. -- Regards, Matt From paul.hoffman@vpnc.org Sun Jan 22 18:05:46 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4922921F84CE for ; Sun, 22 Jan 2012 18:05:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHO2qMhC8UFJ for ; Sun, 22 Jan 2012 18:05:45 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id ACE8321F84C3 for ; Sun, 22 Jan 2012 18:05:45 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q0N25g7Y098617 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 22 Jan 2012 19:05:43 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <1327282284.3558.10.camel@localhost> Date: Sun, 22 Jan 2012 18:05:42 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <1327282284.3558.10.camel@localhost> To: Matt McCutchen X-Mailer: Apple Mail (2.1251.1) Cc: IETF DANE WG list Subject: Re: [dane] Opening Issue #37. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 02:05:46 -0000 On Jan 22, 2012, at 5:31 PM, Matt McCutchen wrote: > Is it really possible that no one has commented on this, or am I somehow > not seeing the messages? The former. Maybe you are the only one who cares about it. --Paul Hoffman From i.grok@comcast.net Sun Jan 22 19:31:27 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93DAA21F85F2 for ; Sun, 22 Jan 2012 19:31:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.322 X-Spam-Level: X-Spam-Status: No, score=-102.322 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aksaIKfErMG8 for ; Sun, 22 Jan 2012 19:31:27 -0800 (PST) Received: from qmta08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7F221F85F1 for ; Sun, 22 Jan 2012 19:31:27 -0800 (PST) Received: from omta16.emeryville.ca.mail.comcast.net ([76.96.30.72]) by qmta08.emeryville.ca.mail.comcast.net with comcast id QrF91i0011ZMdJ4A8rXSvC; Mon, 23 Jan 2012 03:31:26 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta16.emeryville.ca.mail.comcast.net with comcast id QrXR1i00f00PQ6U8crXSSn; Mon, 23 Jan 2012 03:31:26 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.3) with ESMTP id q0N3VO54008178 for ; Sun, 22 Jan 2012 22:31:24 -0500 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id q0N3VOtJ008177 for dane@ietf.org; Sun, 22 Jan 2012 22:31:24 -0500 Date: Sun, 22 Jan 2012 22:31:24 -0500 From: Scott Schmit To: dane@ietf.org Message-ID: <20120123033124.GD14597@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <1327282284.3558.10.camel@localhost> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="HWvPVVuAAfuRc6SZ" Content-Disposition: inline In-Reply-To: <1327282284.3558.10.camel@localhost> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Opening Issue #37. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 03:31:27 -0000 --HWvPVVuAAfuRc6SZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 22, 2012 at 05:31:24PM -0800, Matt McCutchen wrote: > - When making a positive assertion (as I will be), the ability to > specify the exact server certificate and not call PKIX validation at all > would give me greater peace of mind. Make of that what you will. Then, IMHO what you *really* want is the bare key support from draft-ietf-tls-oob-pubkey (and the DANE draft that will surely follow its publication as RFC). > - As I observed at > https://www.ietf.org/mail-archive/web/dane/current/msg03583.html, it is > inconsistent that for restrictive assertions, we have separate usages > for CA certificate (0) and server certificate (1), while for positive > +restrictive assertions, we have a single usage for a CA certificate or > a server certificate (2). If one would argue that we don't need a > separate usage for a positive+restrictive assertion of a server > certificate, the exact same argument would suggest that the current > usages 0 and 1 should be combined. Is there really a problem? The draft states: # 2 -- The target certificate MUST pass PKIX validation, with any # certificate matching the TLSA record considered to be a trust # anchor for this validation But the trust anchor isn't required to be passed in the Server Certificate message, and clients routinely ignore whether TAs are marked as CA certificates or not (nor are they required to check). So you can put a self-signed EE cert in your TLS server configuration and the same certificate in your TLSA record (2 0 0). The TLS client will look up the TLSA record, mark the certificate as a trust anchor for this connection, get the one-certificate certificate chain, see a self-issued EE cert issued by an omitted TA certificate (the one in the TLSA record), and accept the certificate. And the RFCs would defend that behavior, as far as I understand it. Or am I missing something? --=20 Scott Schmit --HWvPVVuAAfuRc6SZ Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQJgYJKoZIhvcNAQcCoIIQFzCCEBMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DVcwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBxswggYDoAMCAQICAwK+HTANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTExMDcxNzA1 MDQwNFoXDTEyMDcxNzExNDI1OVowYjEgMB4GA1UEDRMXNDY1MjU2LTBnRmI2Sk5ZWW44QnFW bUwxGzAZBgNVBAMMEmkuZ3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9r QGNvbWNhc3QubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2AjLOMsBGaqN hv2FcRbfom/QCeKMXu5tUd1JY5oIDZe5y29stnd+se/zUlEkiVeMam4Jgo1c8yGNnwLVYc5/ 9xVi7Qg1Is5b9AB6aJWElJDw/jIdihymNZ2kwkSLT0wl/lzd0mXlwFJPRgQiRkmE6V0ZmjsQ jaVtllVleGBbMvmWPm92e+4Bju9P81kKz7Xr02ijETmaPdVsl+jmOaKPS8Y+2Lat2xus4Ked oJ/7aIWIpz1gRSKjAHSZ1Wmwi2TYUjYhZryChu9e1RWtqk1CycNoeusJ8xdEVN3WSnJ299w/ 3ltK/x/9rpj2j9ShQZVB4NnX6cjQs7pz1lVxvIkjcQIDAQABo4IDrTCCA6kwCQYDVR0TBAIw ADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBQ29j2I0O8sRYi0So9NwwmT1caakDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhR gjAdBgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwggIhBgNVHSAEggIYMIICFDCCAhAG CysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJt ZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUF BwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJp bGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFu ZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0 cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQAZ5U0nL/2PQwsVfHgN7MVPbZEGzDzuj4Oy pTgz4XQFwPcCuy6U9sp1Dwmo3DyKX5nKN4xA7pslN+2Pl/kElGamX7zMCAH0xED0RTOLyk+v nDML4s+OUtWaYVnq1bZEp0F8Luq3zIslAYSebleyiz8M0EypZczsL5rOk86R2F9EYw1CBuFJ 5a4x0CmNu5o30fGNDFt+iXRlbJPp/KY25iUgVnBzJ4COT5kQjxn5lgr4t1I+BDCL5HQQ3h/8 2CzwrWVRBNb9Vqh9LL1ZtzYRt8JezoB6HkVvcKVNGlCZ+/MnvfMzPLwfbTDZC8o4d+4RH6aE LeGF2XmAOaenc/YRqm9oMYIClzCCApMCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQIDAr4dMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTIwMTIzMDMzMTI0WjAjBgkqhkiG9w0BCQQxFgQUiHwPO4Iv i22aTV/2Cfx7AQde9DoweQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEANACrrCjp Hu3O0Qvi9OPVfFzdwjXB1drpIW2EDucSQm4F6SG+CDdMYMCNtaRFAI3SL6nthkxSwnJiIabq s/vlNHngLAkkRWeHKyPKAvlcetswquiEQdc96jagGIZQZoglYlPuE93tKBOx/8QjKNnnX1cQ oddQSgk+2q5fJfsVZWhQG+sbv3yE2mDl3qMqpoShiirCwag/lTFW7etxgfFQOJbNNCbrJzlW tYFDnDH78lCJ9mN2Hr0hwwrQ1Ez6r4rfeO0rUDguOLy0JRHPE+pUxr65hwXQUjnCMryFrrOZ FQvMsf/5SbA+ydLlJsUczwltYcRdd5dmGg0EBBpBbHdsQA== --HWvPVVuAAfuRc6SZ-- From hannes.tschofenig@gmx.net Sun Jan 22 23:06:38 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29FFB21F85A7 for ; Sun, 22 Jan 2012 23:06:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NV4A34Kk5-wK for ; Sun, 22 Jan 2012 23:06:37 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 12F5021F859E for ; Sun, 22 Jan 2012 23:06:36 -0800 (PST) Received: (qmail invoked by alias); 23 Jan 2012 07:06:35 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.106]) [88.115.216.191] by mail.gmx.net (mp061) with SMTP; 23 Jan 2012 08:06:35 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX185MOcJVms50GoSkJkvK/3DElLT5rLC4hw9g0+kYy hWIv33O1zAswGs Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig X-Priority: 3 (Normal) In-Reply-To: <41545.83.160.107.2.1327257953.squirrel@webmail.os3.nl> Date: Mon, 23 Jan 2012 09:06:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120122162431.GA14597@odin.ulthar.us> <1794A357-2969-4762-85F6-FFF27561F0B2@gmx.net> <41545.83.160.107.2.1327257953.squirrel@webmail.os3.nl> To: Pieter.Lexis@os3.nl X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: dane@ietf.org Subject: Re: [dane] Question regarding draft-ietf-dane-protocol-14 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 07:06:38 -0000 Hi Pieter,=20 Thanks for your quick response. I should have better explained my = question.=20 For certificate handling there are many tools available (many of them = come with the ssl/tls stack but some are also shipped separately, such = as the Windows makecert). Some of them come with a fairly nice user = interface as well.=20 Since you guys are not only using certs but fragments of them (as it is = the case with the subjectPublicKeyInfo) I was wondering whether someone = has worked on these tools already to allow convenient creating, and = verification of subjectPublicKeyInfo structures so that they then be = dumped into the RR. For deploying smaller systems, and for testing this = would be quite useful.=20 Ciao Hannes PS: In your code below you seem to be using a certificate as a starting = point.Those who want to use raw public keys probably wouldn't create = certificates. =20 On Jan 22, 2012, at 8:45 PM, Pieter.Lexis@os3.nl wrote: > Hi Hannes, >=20 >> A follow-up question: Is there code available to create DER encoded >> subjectPublicKeyInfo blocks and to decode them? >=20 > I use python for doing this: >=20 > Decoding can be done using the M2Crypto[0] library in python (a = OpenSSL > wrapper): >=20 > from M2Crypto import X509 > cert =3D X509.load_cert('/path/to/cert') > print cert.get_pubkey().as_der() > print cert.get_pubkey().as_text() >=20 > For encoding, the M2Crypto.RSA module can be used afaik. >=20 > -- Pieter Lexis >=20 > 0 - http://www.heikkitoivonen.net/m2crypto/api/ >=20 From matt@mattmccutchen.net Mon Jan 23 00:38:29 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2BAA21F85BB for ; Mon, 23 Jan 2012 00:38:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QYqAgf7EpJaL for ; Mon, 23 Jan 2012 00:38:29 -0800 (PST) Received: from homiemail-a38.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA6B21F85B9 for ; Mon, 23 Jan 2012 00:38:28 -0800 (PST) Received: from homiemail-a38.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a38.g.dreamhost.com (Postfix) with ESMTP id 4624810AFB2; Mon, 23 Jan 2012 00:38:28 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=message-id :subject:from:to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:mime-version; q=dns; s= mattmccutchen.net; b=PIAQgkTaOMnk9Tyf894HtvFosUZzFt7rB1O4ntRPiaU uklMC8TxpjkXRW/KkGsQJlL9u3wqPaUc1anrRbwF5tCsyf+PL7RP10ur0xvOGVbJ lEnO65+0/84XfUKisV/uV7gia+R1sRQDdq0yrsCMchjOO87+rto1wMLedydFJtoU = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= message-id:subject:from:to:cc:date:in-reply-to:references :content-type:content-transfer-encoding:mime-version; s= mattmccutchen.net; bh=oA9huvw2uRsJyBI/r/a5ISaLV7A=; b=nZw57B1OAo YF7GLFOsYF+l0ebGPmM5QQ1qD+LzeLJUJoAZiHkxH1CHqSelByfLBk2JmaoPpQis FRYoA55E8Is7YbQIsQWb3znYXsSmgZPnWXvFHlbbb7jcIA/RGXWxmbyeB2KXYkz5 ELOkRiOTeSXc8lHSZ8WDrgDW5Mbr6cxvs= Received: from [IPv6:::1] (c-98-248-34-40.hsd1.ca.comcast.net [98.248.34.40]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a38.g.dreamhost.com (Postfix) with ESMTPSA id 08EC110AFB1; Mon, 23 Jan 2012 00:38:27 -0800 (PST) Message-ID: <1327307907.3558.25.camel@localhost> From: Matt McCutchen To: Scott Schmit Date: Mon, 23 Jan 2012 00:38:27 -0800 In-Reply-To: <20120123033124.GD14597@odin.ulthar.us> References: <1327282284.3558.10.camel@localhost> <20120123033124.GD14597@odin.ulthar.us> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Cc: dane@ietf.org Subject: Re: [dane] Opening Issue #37. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 08:38:30 -0000 On Sun, 2012-01-22 at 22:31 -0500, Scott Schmit wrote: > On Sun, Jan 22, 2012 at 05:31:24PM -0800, Matt McCutchen wrote: > > - When making a positive assertion (as I will be), the ability to > > specify the exact server certificate and not call PKIX validation at all > > would give me greater peace of mind. Make of that what you will. > > Then, IMHO what you *really* want is the bare key support from > draft-ietf-tls-oob-pubkey (and the DANE draft that will surely follow > its publication as RFC). Actually, not. My desire at this point is to have DANE clients use a certificate acceptance test that does not involve PKIX validation. I am not adverse to the public key being wrapped in an X.509 certificate. > > - As I observed at > > https://www.ietf.org/mail-archive/web/dane/current/msg03583.html, it is > > inconsistent that for restrictive assertions, we have separate usages > > for CA certificate (0) and server certificate (1), while for positive > > +restrictive assertions, we have a single usage for a CA certificate or > > a server certificate (2). If one would argue that we don't need a > > separate usage for a positive+restrictive assertion of a server > > certificate, the exact same argument would suggest that the current > > usages 0 and 1 should be combined. > > Is there really a problem? > > The draft states: > # 2 -- The target certificate MUST pass PKIX validation, with any > # certificate matching the TLSA record considered to be a trust > # anchor for this validation > > But the trust anchor isn't required to be passed in the Server > Certificate message, and clients routinely ignore whether TAs are marked > as CA certificates or not (nor are they required to check). > > So you can put a self-signed EE cert in your TLS server configuration > and the same certificate in your TLSA record (2 0 0). The TLS > client will look up the TLSA record, mark the certificate as a trust > anchor for this connection, get the one-certificate certificate chain, > see a self-issued EE cert issued by an omitted TA certificate (the one > in the TLSA record), and accept the certificate. And the RFCs would > defend that behavior, as far as I understand it. This may or may not work in implementations. But that wasn't the point I was making. If a separate usage for a positive and restrictive assertion of a server certificate is unjustified complexity, then so too is the distinction between usages 0 and 1. We could have simply: 0 -- The target certificate MUST pass PKIX validation using the client's usual trust anchor set, and also MUST pass PKIX validation with any certificate matching the TLSA record (and only such a certificate) considered to be a trust anchor for this validation. 2 -- The target certificate MUST pass PKIX validation, with any certificate matching the TLSA record (and only such a certificate) considered to be a trust anchor for this validation. Nothing, except the document already being written, justifies the current state of affairs with usages 0 and 1 separate but usage 2 serving a dual purpose. -- Matt From pieter.lexis@os3.nl Mon Jan 23 01:42:15 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4204721F8504 for ; Mon, 23 Jan 2012 01:42:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.275 X-Spam-Level: X-Spam-Status: No, score=-2.275 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FvDN99JxL4QR for ; Mon, 23 Jan 2012 01:42:14 -0800 (PST) Received: from mail.serv.os3.nl (mail.serv.os3.nl [IPv6:2001:610:158:960::25]) by ietfa.amsl.com (Postfix) with ESMTP id AB5D321F84FF for ; Mon, 23 Jan 2012 01:42:14 -0800 (PST) Received: from smtp.os3.nl (smtp.os3.nl [IPv6:2001:610:158:960::119]) by mail.serv.os3.nl (Postfix) with ESMTP id 4B82717AA0A; Mon, 23 Jan 2012 10:42:12 +0100 (CET) Received: from [IPv6:2001:610:158:1020:d0a7:f589:5f26:f21e] (unknown [IPv6:2001:610:158:1020:d0a7:f589:5f26:f21e]) by smtp.os3.nl (Postfix) with ESMTPSA id 0D2A017AA01; Mon, 23 Jan 2012 10:42:12 +0100 (CET) Message-ID: <4F1D2B73.8040207@os3.nl> Date: Mon, 23 Jan 2012 10:42:11 +0100 From: Pieter Lexis User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111109 Thunderbird/3.1.16 MIME-Version: 1.0 To: Hannes Tschofenig References: <20120122162431.GA14597@odin.ulthar.us> <1794A357-2969-4762-85F6-FFF27561F0B2@gmx.net> <41545.83.160.107.2.1327257953.squirrel@webmail.os3.nl> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dane@ietf.org Subject: Re: [dane] Question regarding draft-ietf-dane-protocol-14 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 09:42:15 -0000 Hi Hannes, On 01/23/2012 08:06 AM, Hannes Tschofenig wrote: > Since you guys are not only using certs but fragments of them (as it > is the case with the subjectPublicKeyInfo) I was wondering whether > someone has worked on these tools already to allow convenient > creating, and verification of subjectPublicKeyInfo structures so that > they then be dumped into the RR. For deploying smaller systems, and > for testing this would be quite useful. As a matter-of-fact I have. I'm currently busy implementing a TLSA creator/verifier in python (hence the python code) that takes a certificate (either from an on-disk certificate or a certificate retrieved in the TLS session) and dumps the SubjectPublicKeyInfo or full cert in (hashed) DER format into the RR. I'm planning on releasing the tool somewhere this week, after I've verified all permutations of fields produce the right results. Cheers, Pieter Lexis From rbarnes@bbn.com Mon Jan 23 06:44:29 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93F5A21F8726 for ; Mon, 23 Jan 2012 06:44:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.899 X-Spam-Level: X-Spam-Status: No, score=-105.899 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yscgXqczNpeM for ; Mon, 23 Jan 2012 06:44:29 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2230821F8723 for ; Mon, 23 Jan 2012 06:44:29 -0800 (PST) Received: from ros-dhcp192-1-51-95.bbn.com ([192.1.51.95]:54229) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RpL8F-000MqU-BX; Mon, 23 Jan 2012 09:44:27 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <1327307907.3558.25.camel@localhost> Date: Mon, 23 Jan 2012 09:44:26 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <9FAA7940-7753-414E-B201-A0A8232D21EB@bbn.com> References: <1327282284.3558.10.camel@localhost> <20120123033124.GD14597@odin.ulthar.us> <1327307907.3558.25.camel@localhost> To: Matt McCutchen X-Mailer: Apple Mail (2.1084) Cc: dane@ietf.org Subject: Re: [dane] Opening Issue #37. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 14:44:29 -0000 > Nothing, except the document already being written, justifies the > current state of affairs with usages 0 and 1 separate but usage 2 > serving a dual purpose. Well, there is a use cases document that achieved consensus in this = working group: The certificate usage types map exactly to the three major use cases in = the document. --Richard= From paul.hoffman@vpnc.org Mon Jan 23 08:17:52 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9821621F84C3 for ; Mon, 23 Jan 2012 08:17:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBzS7BtuMtpd for ; Mon, 23 Jan 2012 08:17:52 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1B81D21F84A5 for ; Mon, 23 Jan 2012 08:17:52 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q0NGHlvk063180 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 Jan 2012 09:17:47 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman X-Priority: 3 (Normal) In-Reply-To: Date: Mon, 23 Jan 2012 08:17:46 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <12A49427-75C8-4394-AD8D-EF1DDAF67ACB@vpnc.org> References: <20120122162431.GA14597@odin.ulthar.us> <1794A357-2969-4762-85F6-FFF27561F0B2@gmx.net> <41545.83.160.107.2.1327257953.squirrel@webmail.os3.nl> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1251.1) Cc: IETF DANE WG list Subject: Re: [dane] Question regarding draft-ietf-dane-protocol-14 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 16:17:52 -0000 On Jan 22, 2012, at 11:06 PM, Hannes Tschofenig wrote: > PS: In your code below you seem to be using a certificate as a = starting point.Those who want to use raw public keys probably wouldn't = create certificates. The WG is currently only focused on certificates and the keys from = certificates because those are the only things that can be used in = standards-compliant TLS. As others have noted, if the TLS WG adopts a = standards-track method for using raw public keys, it is likely that DANE = would be updated to use them. Until then, however, the WG has = (repeatedly) decided that because our work does not change TLS, raw = public keys that would be used in TLS are out of scope. --Paul Hoffman From simon@arlott.org Sun Jan 22 08:18:13 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A05021F8508 for ; Sun, 22 Jan 2012 08:18:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vN5G9I3Uo6lU for ; Sun, 22 Jan 2012 08:18:12 -0800 (PST) Received: from proxima.lp0.eu (proxima.lp0.eu [IPv6:2001:8b0:ffea:0:205:b4ff:fe12:530]) by ietfa.amsl.com (Postfix) with ESMTP id 469A921F84FF for ; Sun, 22 Jan 2012 08:18:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=arlott.org; s=exim; h=Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=DvF3QIbNDwomcaN5kh1yrIFeg8CORDPTBteSX+pirpw=; b=Kk1yDto4CiZIZHqp6PUSx4ag8g+yb+V/2uqzBZUs+vkJbsFtYmIFD73QLAbU1KCQKILxDlxX1fywbwCAfykPnS2ruAB29gQPlxo7UZcMardPbY2u8i5Xj6TYiTXi61KB; Received: from redrum.lp0.eu ([2001:8b0:ffea:0:2e0:81ff:fe4d:2bec]:54146 ident=simon) by proxima.lp0.eu ([2001:8b0:ffea:0:205:b4ff:fe12:530]:465) with esmtpsav (TLSv1:CAMELLIA256-SHA:256/CN=Simon Arlott) id 1Rp07M-0007l3-Ey for dane@ietf.org; Sun, 22 Jan 2012 16:18:09 +0000 Message-ID: <4F1C36C0.9060207@simon.arlott.org.uk> Date: Sun, 22 Jan 2012 16:18:08 +0000 From: Simon Arlott User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110823 Thunderbird/5.0 MIME-Version: 1.0 To: dane@ietf.org References: <20120117193930.GA29471@vacation.karoshi.com.> <20120121225503.GA24203@odin.ulthar.us> In-Reply-To: <20120121225503.GA24203@odin.ulthar.us> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090507080906030404030701" X-Mailman-Approved-At: Mon, 23 Jan 2012 08:38:06 -0800 Subject: Re: [dane] existence proof X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2012 16:44:23 -0000 This is a cryptographically signed message in MIME format. --------------ms090507080906030404030701 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 21/01/12 22:55, Scott Schmit wrote: > On Tue, Jan 17, 2012 at 07:39:30PM +0000, bmanning@vacation.karoshi.com= wrote: >> are there any zones with DANE (or proto-DANE) RRs in them that are vis= ible? >=20 > $ dig +short TYPE65468 _443._tcp.ulthar.us > \# 35 01010162D5414CD1CC657E3D30EA5E6D0136E92306E725413C616A51 CAB4B852= C70A1C > $ dig +short TYPE65468 _443._tcp.www.ulthar.us > \# 35 01010162D5414CD1CC657E3D30EA5E6D0136E92306E725413C616A51 CAB4B852= C70A1C >=20 > That should be consistent with the current DANE draft. >=20 > There's also Matt McCutchen's site (mattmccutchen.net), which uses an > older draft (-06). >=20 > I don't know of any others. I've added these based on draft 14: HTTPS $ dig _443._tcp.lp0.eu type65468 +short _tlsa.proxima.lp0.eu. \# 67 010102490D884C778E9031D8F1BDFB4B6E7673418BAD66CB8115E36C ED911EA612= B688AE7CC1909BF23391574E41865E41A51E03ECBC18FA 6125A5A14C7D2BA5E0CFF3 SMTP (TLS) $ dig arlott.org mx +short 0 proxima.lp0.eu. 5 blackhole.arlott.org.uk. $ dig _smtp._tcp.arlott.org srv +short 0 10 25 blackhole.arlott.org.uk. 0 90 25 proxima.lp0.eu. $ dig _25._tcp.proxima.lp0.eu type65468 +short _tlsa.proxima.lp0.eu. \# 67 010102490D884C778E9031D8F1BDFB4B6E7673418BAD66CB8115E36C ED911EA612= B688AE7CC1909BF23391574E41865E41A51E03ECBC18FA 6125A5A14C7D2BA5E0CFF3 $ dig _25._tcp.blackhole.arlott.org.uk type65468 +short _tlsa.blackhole.arlott.org.uk. \# 67 0101025654772D26434FB13DCEAF9F26C5C51A886471DC90A6965194 F4018E80F8= 965232FAEDDB22A4039A0EBE017DD4E48055DF12659451 52D6C489CEC2EA8D2A5A7D XMPP (TLS) $ dig _xmpp-server._tcp.arlott.org.uk srv +short 0 0 5269 proxima.lp0.eu. $ dig _5269._tcp.proxima.lp0.eu type65468 +short _tlsa.proxima.lp0.eu. \# 67 010102490D884C778E9031D8F1BDFB4B6E7673418BAD66CB8115E36C ED911EA612= B688AE7CC1909BF23391574E41865E41A51E03ECBC18FA 6125A5A14C7D2BA5E0CFF3 I'm assuming the following command is correct to calculate a hash of SubjectPublicKeyInfo: $ openssl x509 -pubkey -in ... | openssl rsa -pubin | \ head -n -1 | tail -n +2 | base64 -d | sha512sum - writing RSA key 490d884c778e9031d8f1bdfb4b6e7673418bad66cb8115e36ced911ea612b688ae7cc1909= bf23391574e41865e41a51e03ecbc18fa6125a5a14c7d2ba5e0cff3 - It matches the record for ulthar.us: $ dig _443._tcp.ulthar.us type65468 +short \# 35 01010162D5414CD1CC657E3D30EA5E6D0136E92306E725413C616A51 CAB4B852C7= 0A1C $ openssl s_client -showcerts -connect ulthar.us:443 /dev/nu= ll | \ openssl x509 -pubkey | openssl rsa -pubin | \ head -n -1 | tail -n +2 | base64 -d | sha256sum - writing RSA key 62d5414cd1cc657e3d30ea5e6d0136e92306e725413c616a51cab4b852c70a1c - --=20 Simon Arlott --------------ms090507080906030404030701 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFLzCC BSswggMToAMCAQICAwonrjANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMTA0 MjkxOTM0MzBaFw0xMzA0MjgxOTM0MzBaMDgxFTATBgNVBAMTDFNpbW9uIEFybG90dDEfMB0G CSqGSIb3DQEJARYQc2ltb25AYXJsb3R0Lm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALIIK63ZkK5EhTZGUa5tevs/o/KTweoehTe9btmhWX7X4xce1TG6f14ofHL9VHR2 ID1qmau8phtyiu+B2XtFf5Ac8PdKPlsWT9qfkF9IC98rdY9b6v/uqyMRU4ADnFS8NmRI4QlZ JfFVynjpIJ4GOQxmbo5WHpDmfhxY5uDZPPbLaDniFQIh2Fc0vt7lqXAXuXKsB08uEzaidrEp 2qimmzY5QMc51ZEHtIyIujEDWYnldwNX/9rKzLoyQikR6707y5nI0fTkIfLbuQsjS1D8NKSU RZEhO6DszajpKy4CpePnADo5xiEroNLhbEtWfIX2A0EBtxQD252+Pa7U3XMCvGECAwEAAaOB /DCB+TAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2Vy dGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzBA BgNVHSUEOTA3BggrBgEFBQcDBAYIKwYBBQUHAwIGCisGAQQBgjcKAwQGCisGAQQBgjcKAwMG CWCGSAGG+EIEATAyBggrBgEFBQcBAQQmMCQwIgYIKwYBBQUHMAGGFmh0dHA6Ly9vY3NwLmNh Y2VydC5vcmcwGwYDVR0RBBQwEoEQc2ltb25AYXJsb3R0Lm9yZzANBgkqhkiG9w0BAQUFAAOC AgEAG2JdvUFhtFS9RHT96gGjDIqcL2ftYZEbkt1e16xw5RBbzi0QIzaITptxPQMufsvdgQnm nZrPXDW9MdFvxpsVJlkB4aOK9mhfTkQ+67H+8lM5GQzR6SZjepc9H+rlgr+b0hRkqtQTDJOq ebUzAWEacphSr0Ywa+/8jQExX7qQxudYlOA01raQUABsa/CqJG4ZfOnA/OkBWcB+i4wSetjW WAqM1eclAFvfpJqfMwbQ5K8Jpeq0vj+7HvpH0NfK5BqP/bhBP83Lxa7+Vd+AqtvXoPa7SGZL 8O0zcCUCra8PUYZSv8W8hRcSwFJdNXCQVmkpapgi2+3u0dxLNpsbK3czEEReDpVX36DZoLCD 2Ta1QawKKRPLK2lWsKipa3rrC1F3P+16a5NJQcOLV7T8/TIP7JYdH4OkLvj3JIz1z72yQEVD wAaEKMoAstA6m18DpH3IlBU7cFDcqiMEHRtLqLreGPsGFHTahnJqPddnSazUFMfkw/FLnFrE 3EMijz6eiVHu5DO9z/9osc0d8Qxsh9Wml7jMC2+kTr2zZKk+YNnTkWRiqaR7aHGFlDw1SoaJ +RDY8LCeeVh/XfA+hNC4/+gmYYkxKK91Kwwgbd1UZciabJrzR/fo7PS45ie0zrSFZNQCQ0q5 j1dc+mDlVJUPq8/AIkNZbxK8sJ/1ltjGm7PxeSkxggOUMIIDkAIBATCBgDB5MRAwDgYDVQQK EwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNB IENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0 Lm9yZwIDCieuMAkGBSsOAwIaBQCgggHoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTEyMDEyMjE2MTgwOFowIwYJKoZIhvcNAQkEMRYEFGUsOJv3juHnTn3N Gf45oUWyuuwTMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB kQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMKJ64wgZMGCyqGSIb3DQEJEAIL MYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0 Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJ ARYSc3VwcG9ydEBjYWNlcnQub3JnAgMKJ64wDQYJKoZIhvcNAQEBBQAEggEAhwC+BWFgVMMs k0hTQFIxadK+BRtTb8czyXKVgARgaqwfKePmpBYc0UCRLMnFz61zqYjRK9qEeI7/9f/iH1lx ciUuTpxNluB1ShFrUJrfInyfZX/vbQjm9jhUYUDHwPvHy6m5ZX6OJhm838xcvQMZQK/DaR61 m18/YPy2G9B3awmr1CCHnaw8/1rFUJtoJloK1Gkfbp9eYq0RmeQ4lRWtm8UPZK+Xr0pqtfi3 uiVL6VjK6cJGj31Co4YAcH1/n02qJm/3aev7TcdXurK8K2tK0C7F3z4aJ3hCOXFxnJE3Tn15 ZI2qyYO4ijlJHfvHi2PCJtLR4rfMBTEtpBYVudQNhgAAAAAAAA== --------------ms090507080906030404030701-- From paul@nohats.ca Mon Jan 23 09:48:07 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5A4F21F8540 for ; Mon, 23 Jan 2012 09:48:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.842 X-Spam-Level: X-Spam-Status: No, score=0.842 tagged_above=-999 required=5 tests=[AWL=-1.710, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, J_CHICKENPOX_36=0.6, J_CHICKENPOX_38=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_46=0.6, J_CHICKENPOX_65=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2lCaIephhao for ; Mon, 23 Jan 2012 09:48:06 -0800 (PST) Received: from letoams.cypherpunks.ca (unknown [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 8642A21F8531 for ; Mon, 23 Jan 2012 09:48:05 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id 56F8781943; Mon, 23 Jan 2012 12:47:25 -0500 (EST) Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.5/8.14.5/Submit) with ESMTP id q0NHlNY2028359; Mon, 23 Jan 2012 12:47:24 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 23 Jan 2012 12:47:23 -0500 (EST) From: Paul Wouters To: Pieter Lexis In-Reply-To: <4F1D2B73.8040207@os3.nl> Message-ID: References: <20120122162431.GA14597@odin.ulthar.us> <1794A357-2969-4762-85F6-FFF27561F0B2@gmx.net> <41545.83.160.107.2.1327257953.squirrel@webmail.os3.nl> <4F1D2B73.8040207@os3.nl> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-1054247823-1327340845=:28037" X-Mailman-Approved-At: Mon, 23 Jan 2012 09:48:44 -0800 Cc: dane@ietf.org Subject: Re: [dane] Question regarding draft-ietf-dane-protocol-14 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 17:48:07 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323328-1054247823-1327340845=:28037 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Mon, 23 Jan 2012, Pieter Lexis wrote: > As a matter-of-fact I have. I'm currently busy implementing a TLSA > creator/verifier in python (hence the python code) that takes a > certificate (either from an on-disk certificate or a certificate > retrieved in the TLS session) and dumps the SubjectPublicKeyInfo or full > cert in (hashed) DER format into the RR. > > I'm planning on releasing the tool somewhere this week, after I've > verified all permutations of fields produce the right results. I created one a while ago, and it should get published better. It is want powers/powered http://dane.xelerance.com/ It uses ldnsx, a python module added to recent ldns versions. Since it is small and I currently do not have a good publication url, I attached it. Note it uses some non-obvious socket calls due to some unavailable modes for ipv6 in some of the other python networking modules. Paul ps. someone also gave me some patches that i havent had time to look at yet to support more then type 1 certifiactes. --8323328-1054247823-1327340845=:28037 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=dane.py Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=dane.py IyEvdXNyL2Jpbi9weXRob24NCg0KIyBkYW5lIGlzIGEgdG9vbCB0byBnZW5l cmF0ZSBhbmQgdmVyaWZ5IEhBU1RMUyBhbmQgVExTQSByZWNvcmRzDQojIEJ5 IFBhdWwgV291dGVycyA8cGF1bEB4ZWxlcmFuY2UuY29tPiBhbmQgQ2hyaXN0 b3BoZXIgT2xhaCA8Y2hyaXNAeGVsZXJhbmNlLmNvbT4NCiMgQ29weXJpZ2h0 IDIwMTEgYnkgWGVsZXJhbmNlIGh0dHA6Ly93d3cueGVsZXJhbmNlLmNvbS8N CiMgTGljZW5zZTogR05VIEdFTkVSQUwgUFVCTElDIExJQ0VOU0UgVmVyc2lv biAyIG9yIGxhdGVyDQojDQojIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvd2cvZGFuZS9jaGFydGVyLw0KIyBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1pZXRmLWRhbmUtcHJvdG9jb2wvIA0KDQppbXBv cnQgc3lzDQppbXBvcnQgYmluYXNjaWkNCmltcG9ydCBzc2wsIHNvY2tldA0K aW1wb3J0IGhhc2hsaWINCmltcG9ydCB3YXJuaW5ncw0KDQp0cnk6DQoJaW1w b3J0IGxkbnN4DQpleGNlcHQ6DQoJaW1wb3J0IGRhbmVsZG5zeCBhcyBsZG5z eA0KDQp0cnk6DQoJaW1wb3J0IHN5cw0KCWltcG9ydCBhcmdwYXJzZQ0KZXhj ZXB0IEltcG9ydEVycm9yICwgZToNCgltb2R1bGUgPSBzdHIoZSlbMTY6XQ0K CXByaW50ID4+IHN5cy5zdGRlcnIsICJkYW5lIHJlcXVpcmVzIHRoZSBweXRo b24gbW9kdWxlICIgKyBtb2R1bGUNCglpZiBtb2R1bGUgaW4gWyJhcmdwYXJz ZSIsICJpcGNhbGMiLCAibGRucyJdOg0KCQlwcmludCA+PiBzeXMuc3RkZXJy LCAiRmVkb3JhL0NlbnRPUzogeXVtIGluc3RhbGwgIiBcDQogICAgICAgICAg ICAgICAgICAgKyB7ImFyZ3BhcnNlIjoicHl0aG9uLWFyZ3BhcnNlIiwgImlw Y2FsYyI6ICJweXRob24taXBjYWxjIiwgImxkbnMiOiAibGRucy1weXRob24i fQ0KCQlwcmludCA+PiBzeXMuc3RkZXJyLCAiRGViaWFuL1VidW50dTogYXB0 LWdldCBpbnN0YWxsICIgXA0KICAgICAgICAgICAgICAgICAgICsgeyJhcmdw YXJzZSI6InB5dGhvbi1hcmdwYXJzZSIsICJpcGNhbGMiOiAicHl0aG9uLWlw Y2FsYyIsICJsZG5zIjogInB5dGhvbi1sZG5zIn0NCgkJcHJpbnQgPj4gc3lz LnN0ZGVyciwgIm9wZW5TVVNFOiB6eXBwZXIgaW4gIiBcDQogICAgICAgICAg ICAgICAgICAgKyB7ImFyZ3BhcnNlIjoicHl0aG9uLWFyZ3BhcnNlIiwgImlw Y2FsYyI6ICJweXRob24taXBjYWxjIiwgImxkbnMiOiAicHl0aG9uLWxkbnMi fQ0KCXN5cy5leGl0KDEpDQoNCmRlZiBjcmVhdGVfdHh0KGhvc3RuYW1lLCBw dWJrZXkpOg0KCSIiIiBLYW1pbnNreSAvIEdpbG1vcmUgdHlwZSBUTFMgcHVi a2V5IGluIFRYVCBSUnR5cGUgLS0gdGVzdGluZyB2ZXJzaW9uIiIiDQoJd2Fy bmluZ3Mud2FybigiY3JlYXRlX3R4dCBpcyB1bnRlc3RlZC4uLiIpDQoJaGFz aG9iaiA9IGhhc2hsaWIuc2hhMSgpICNBcmUgdGhlcmUgb3RoZXIgdmFsaWQg aGFzaGVzPw0KCWhhc2hvYmoudXBkYXRlKHB1YmtleSkgI1Nob3VsZCB3ZSB0 cnkgYW5kIGdldCB0aGUgcHVia2V5IG91cnNlbHZlcywgbGlrZSBpbiBjcmVh dGVfVExTQT8NCglyZXN1bHQgPSBoYXNob2JqLmhleGRpZ2VzdCgpLnVwcGVy KCkNCglyZXR1cm4gIiVzIElOIFRYVCBcInY9a2V5MSBoYT1zaGExIGg9JXNc IiIgJSAoaG9zdG5hbWUsIHJlc3VsdCkNCg0KZGVmIGNyZWF0ZV9oYXN0bHMo aG9zdG5hbWUsIGZhbGxiYWNrX2RlZmF1bHQsIHNlcnZpY2VzKToNCgkiIiIg Q3JlYXRlcyBhIEhBU1RMUyBSUnR5cGUgIiIiDQoNCmRlZiBjaGVja0V4aXN0 aW5nVExTQShob3N0bmFtZSwgY2VydHR5cGUsIHJlZnR5cGUpOg0KCSIiIiBj aGVjayBpZiBhIFRMU0EgcmVjb3JkIGFscmVhZHkgZXhpc3RzLCB0byBjb21w YXJlIGFuZCBub3RpZnkgaWYgdXBkYXRlIGlzIG5lZWRlZCANCgkgICAgVU5U RVNURUQhISEhICIiIg0KCQ0KCXdhcm5pbmdzLndhcm4oImNoZWNrRXhpc3Rp bmdUTFNBIGlzIHVudGVzdGVkLi4uIikNCglyZXMgPSBsZG5zeC5yZXNvbHZl cigpICNHZXQgdGhlIGFwcHJvcHJpYXRlIHJlc291cmNlIHJlY29yZHMuLi4N Cglwa3QgPSByZXMucXVlcnkoaG9zdG5hbWUsICJUWVBFNjU0NjgiLCB0cmll cyA9IDMpDQoJcHJlc19UTFNBcz1zZXQocGt0LmFuc3dlcihycl90eXBlPSJU WVBFNjU0NjgiKSkNCglwcmVzX1RMU0FzID0gbWFwKGxhbWJkYSBycjogc3Ry KHJyKS5zdHJpcCgpLCBwcmVzX1RMU0FzKQ0KCQ0KCVRMU0FzID0gc2V0KGNy ZWF0ZV9UTFNBcyhob3N0bmFtZSwgY2VydHR5cGUscmVmdHlwZSkuc3BsaXQo J1xuJykpDQoJDQoJcmV0dXJuIFRMU0FzID09IHByZXNfVExTQXMgIyBhcmUg dGhpbmdzIHRoZSBzYW1lIGFzIGJlZm9yZT8NCgkNCg0KZGVmIGNoZWNrRXhp c3RpbmdIQVNUTFMoYWRkcmVzcyk6DQoJIiIiIGNoZWNrIGlmIGEgSEFTVExT IHJlY29yZCBhbHJlYWR5IGV4aXN0cywgdG8gY29tcGFyZSBhbmQgbm90aWZ5 IGlmIHVwZGF0ZSBpcyBuZWVkZWQgIiIiDQoNCg0KZGVmIGNyZWF0ZV90bHNh KGhvc3RuYW1lLCBjZXJ0dHlwZSwgcmVmdHlwZSk6DQoJIiIiQ3JlYXRlcyBh IFRMU0EgUlJ0eXBlIiIiDQoJIiIiIGdldCBhbGwgQS9BQUFBIHJlY29yZHMg Zm9yIGhvc3RuYW1lICIiIg0KCWlmIHNlY3VyZToNCgkJcGt0ID0gbGRuc3gu c2VjdXJlX3F1ZXJ5KGhvc3RuYW1lLCAiQU5ZIiwgZmxleD1UcnVlKQ0KCWVs c2U6DQoJCXBrdCA9IGxkbnN4LnF1ZXJ5KGhvc3RuYW1lLCAiQU5ZIikNCgly ZWNvcmRzID0gcGt0LmFuc3dlciggcnJfdHlwZSA9IHsgImlwdjQiOiJBIiwg ICJpcHY2IjoiQUFBQSIsICAiYm90aCI6IkF8QUFBQSIgfVt0cmFuc3BvcnRd ICkNCg0KCWRyYWZ0cywgcmZjcyA9IFtdLCBbXQ0KDQoJZm9yIHJyIGluIHJl Y29yZHM6DQoJCWRyYWZ0ID0gZ2VuVExTQShob3N0bmFtZSwgcnIuaXAoKSwg Y2VydHR5cGUsIHJlZnR5cGUsIGRyYWZ0PVRydWUpDQoJCXJmYyA9IGdlblRM U0EoaG9zdG5hbWUsIHJyLmlwKCksIGNlcnR0eXBlLCByZWZ0eXBlLCBkcmFm dD1GYWxzZSkNCgkJaWYgZHJhZnQgYW5kIG5vdCAoZHJhZnQgaW4gZHJhZnRz KToNCgkJCWRyYWZ0cy5hcHBlbmQoZHJhZnQuc3RyaXAoKSkNCgkJaWYgcmZj IGFuZCBub3QgKHJmYyBpbiByZmNzKToNCgkJCXJmY3MuYXBwZW5kKHJmYy5z dHJpcCgpKQ0KCXJldCA9ICIiDQoJaWYgbm90IGZtdCA9PSAicmZjIjoNCgkJ cmV0ICs9ICJcbiIuam9pbihkcmFmdHMpDQoJaWYgbm90IGZtdCA9PSAiZHJh ZnQiOg0KCQlyZXQgKz0gIlxuIi5qb2luKHJmY3MpDQoJcmV0dXJuIHJldA0K DQpkZWYgZ2VuVExTQShob3N0bmFtZSwgYWRkcmVzcywgY2VydHR5cGUsIHJl ZnR5cGUsIGRyYWZ0PVRydWUpOg0KCXRyeToNCgkJIyBlcnJvcnMgd2lsbCBi ZSB0aHJvd24gYWxyZWFkeSBiZWZvcmUgd2UgZ2V0IGhlcmUNCgkJZGVyY2Vy dCA9IGdldF9jZXJ0KGhvc3RuYW1lLCBhZGRyZXNzKQ0KCWV4Y2VwdDoNCgkJ cmV0dXJuDQoJaWYgbm90IGRlcmNlcnQ6DQoJCXJldHVybg0KDQoJaWYgY2Vy dHR5cGUgIT0gMToNCgkJcmFpc2UgRXhjZXB0aW9uKCJPbmx5IEVFLWNlcnQg c3VwcG9ydGVkIHJpZ2h0IG5vdyIpDQoJY2VydGhleCA9IGhhc2hDZXJ0KHJl ZnR5cGUsIGRlcmNlcnQpDQoJaWYgZHJhZnQ6DQoJCSMgb2N0ZXQgbGVuZ3Ro IGlzIGhhbGYgb2YgdGhlIHN0cmluZyBsZW5ndGg7IHJlbWVtYmVyIGNlcnR0 eXBlIGFuZCByZWZ0eXBlIGFyZSBwYXJ0IG9mIHRoZSBsZW5ndGggc28gKzIN CgkJcmV0dXJuICJfNDQzLl90Y3AuJXMgSU4gVFlQRTY1NDY4IFwjICVzIDAl czAlcyVzIiUoaG9zdG5hbWUsIGxlbihjZXJ0aGV4KS8yKzIsIGNlcnR0eXBl LCByZWZ0eXBlLCBjZXJ0aGV4ICkNCgllbHNlOg0KCQlyZXR1cm4gIl80NDMu X3RjcC4lcyBJTiBUTFNBICVzICVzICVzIiUoaG9zdG5hbWUsIGNlcnR0eXBl LCByZWZ0eXBlLCBjZXJ0aGV4KQ0KDQpkZWYgZ2V0X2NlcnQoaG9zdG5hbWUs IGFkZHJlc3MpOg0KCSMgV2UgZG9uJ3QgdXNlIHNzbC5nZXRfc2VydmVyX2Nl cnRpZmljYXRlIGJlY2F1c2UgaXQgZG9lcyBub3Qgc3VwcG9ydCBJUHY2LCBh bmQgaXQgY29udmVydHMgREVSIHRvIFBFTSwgd2hpY2gNCgkjIHdlIHdvdWxk IGp1c3QgaGF2ZSB0byBjb252ZXJ0IGJhY2sgdG8gREVSIHVzaW5nIHNzbC5Q RU1fY2VydF90b19ERVJfY2VydCgpDQoJdHJ5Og0KCQkjIGtpbmRhIHVnbHkg a2x1ZGdlDQoJCWlmICI6IiBpbiBhZGRyZXNzOg0KCQkJY29ubiA9IHNvY2tl dC5zb2NrZXQoc29ja2V0LkFGX0lORVQ2KQ0KCQllbHNlOg0KCQkJY29ubiA9 IHNvY2tldC5zb2NrZXQoc29ja2V0LkFGX0lORVQpDQoJCWNvbm4uY29ubmVj dCgoYWRkcmVzcywgNDQzKSkNCglleGNlcHQgc29ja2V0LmVycm9yICwgZToN CgkJI3JhaXNlIEV4Y2VwdGlvbigiJXMgKCVzKTogJXMiJShob3N0bmFtZSwg YWRkcmVzcywgc3RyKGUpKSkNCgkJcHJpbnQgPj4gc3lzLnN0ZGVyciwgIiVz ICglcyk6ICVzIiUoaG9zdG5hbWUsIGFkZHJlc3MsIHN0cihlKSkNCgkJcmV0 dXJuDQoJdHJ5Og0KCQlzb2NrID0gc3NsLndyYXBfc29ja2V0KGNvbm4pDQoJ ZXhjZXB0IHNzbC5TU0xFcnJvciAsIGU6DQoJCSNyYWlzZSBFeGNlcHRpb24o IiVzICglcyk6ICVzIiUoaG9zdG5hbWUsIGFkZHJlc3MsIHN0cihlKSkpDQoJ CXByaW50ID4+IHN5cy5zdGRlcnIsICIlcyAoJXMpOiAlcyIlKGhvc3RuYW1l LCBhZGRyZXNzLCBzdHIoZSkpDQoJCXJldHVybg0KCXRyeToNCgkJZGVyY2Vy dCA9IHNvY2suZ2V0cGVlcmNlcnQoVHJ1ZSkNCglleGNlcHQgQXR0cmlidXRl RXJyb3IgLCBlOg0KCQkjcHJpbnQgPj4gc3lzLnN0ZGVyciwgIiVzICglcyk6 ICVzIiUoaG9zdG5hbWUsIGFkZHJlc3MsIHN0cihlKSkNCgkJcmV0dXJuDQoJ c29jay5jbG9zZSgpDQoJY29ubi5jbG9zZSgpDQoJcmV0dXJuIGRlcmNlcnQN Cg0KIyB0YWtlIFBFTSBlbmNvZGVkIEVFLWNlcnQgYW5kIERFUiBlbmNvZGUg aXQsIHRoZW4gc2hhMjU2IGl0DQpkZWYgaGFzaENlcnQocmVmdHlwZSxjZXJ0 YmxvYik6DQoJaWYgcmVmdHlwZSA9PSAwOg0KCQlyZXR1cm4gYmluYXNjaWku YjJhX2hleChjZXJ0YmxvYikudXBwZXIoKQ0KCWVsaWYgcmVmdHlwZSA9PSAx Og0KCQloYXNob2JqID0gaGFzaGxpYi5zaGEyNTYoKQ0KCQloYXNob2JqLnVw ZGF0ZShjZXJ0YmxvYikNCgllbGlmIHJlZnR5cGUgPT0gMjoNCgkJaGFzaG9i aiA9IGhhc2hsaWIuc2hhNTEyKCkNCgkJaGFzaG9iai51cGRhdGUoY2VydGJs b2IpDQoJZWxzZToNCgkJcmV0dXJuIDANCglyZXR1cm4gaGFzaG9iai5oZXhk aWdlc3QoKS51cHBlcigpDQoNCnNlY3VyZSwgdHJhbnNwb3J0LCBxdWlldCwg Zm10ID0gVHJ1ZSwgImJvdGgiLCBGYWxzZSwgImRyYWZ0Ig0KDQojIGNyZWF0 ZSB0aGUgcGFyc2VyDQpwYXJzZXIgPSBhcmdwYXJzZS5Bcmd1bWVudFBhcnNl cihkZXNjcmlwdGlvbj0nQ3JlYXRlIFRMUyByZWxhdGVkIEROUyByZWNvcmRz IGZvciBob3N0cyBvciBhbiBlbnRpcmUgem9uZS4gdmVyc2lvbiAxLjIuMScp DQoNCiMgQVhGUg0KcGFyc2VyLmFkZF9hcmd1bWVudCgnLW4nLCAnLS1uYW1l c2VydmVyJywgbWV0YXZhcj0ibmFtZXNlcnZlciIsIGFjdGlvbj0nYXBwZW5k JywgaGVscD0nbmFtZXNlcnZlciB0byBxdWVyeScpDQpwYXJzZXIuYWRkX2Fy Z3VtZW50KCctLWF4ZnInLCBhY3Rpb249J3N0b3JlX3RydWUnLCBoZWxwPSd1 c2UgQVhGUiAoYWxsIEEvQUFBQSByZWNvcmRzIHdpbGwgYmUgc2Nhbm5lZCkn KQ0KDQojIElFVEYgc3RhdHVzIHJlbGF0ZWQsIGN1cnJlbnRseSAtLWRyYWZ0 IGlzIHRoZSBkZWZhdWx0DQpwYXJzZXIuYWRkX2FyZ3VtZW50KCctLWRyYWZ0 JywgYWN0aW9uPSdzdG9yZV90cnVlJyxoZWxwPSdvdXRwdXQgaW4gZHJhZnQg cHJpdmF0ZSBycnR5cGUgKDY1NDY4LzY1NDY5KSBmb3JtYXQgKGRlZmF1bHQp JykNCnBhcnNlci5hZGRfYXJndW1lbnQoJy0tcmZjJywgYWN0aW9uPSdzdG9y ZV90cnVlJyxoZWxwPSdvdXRwdXQgaW4gcmZjIChUTFNBL0hBU1RMUykgcnJ0 eXBlIGZvcm1hdCcpDQoNCiMgVExTQSByZWxhdGVkCQ0KcGFyc2VyLmFkZF9h cmd1bWVudCgnLS10bHNhJywgYWN0aW9uPSdzdG9yZV90cnVlJyxoZWxwPSdn ZW5lcmF0ZSBUTFNBIHJlY29yZCAoZGVmYXVsdDp5ZXMpJykNCnBhcnNlci5h ZGRfYXJndW1lbnQoJy0tZWVjZXJ0JywgYWN0aW9uPSdzdG9yZV90cnVlJyxo ZWxwPSd1c2UgRUVjZXJ0IGZvciBUTFNBIHJlY29yZCAoZGVmYXVsdCknKQ0K cGFyc2VyLmFkZF9hcmd1bWVudCgnLS1jYWNlcnQnLCBhY3Rpb249J3N0b3Jl X3RydWUnLGhlbHA9J3VzZSBDQWNlcnQgZm9yIFRMU0EgcmVjb3JkIChub3Qg c3VwcG9ydGVkIHlldCknKQ0KcGFyc2VyLmFkZF9hcmd1bWVudCgnLS1wdWJr ZXknLCBhY3Rpb249J3N0b3JlX3RydWUnLGhlbHA9J3VzZSBwdWJrZXkgZm9y IFRMU0EgcmVjb3JkIChub3Qgc3VwcG9ydGVkIHlldCknKQ0KcGFyc2VyLmFk ZF9hcmd1bWVudCgnLS10eHQnLCBhY3Rpb249J3N0b3JlX3RydWUnLGhlbHA9 J2dlbmVyYXRlIEthbWluc2t5IHN0eWxlIFRYVCByZWNvcmQgKG5vdCBzdXBw b3J0ZWQgeWV0KScpDQoNCnBhcnNlci5hZGRfYXJndW1lbnQoJy0tc2hhMjU2 JywgYWN0aW9uPSdzdG9yZV90cnVlJyxoZWxwPSd1c2UgU0hBMjU2IGZvciB0 aGUgVExTQSBjZXJ0IHR5cGUnKQ0KcGFyc2VyLmFkZF9hcmd1bWVudCgnLS1z aGE1MTInLCBhY3Rpb249J3N0b3JlX3RydWUnLGhlbHA9J3VzZSBTSEE1MTIg Zm9yIHRoZSBUTFNBIGNlcnQgdHlwZScpDQpwYXJzZXIuYWRkX2FyZ3VtZW50 KCctLWZ1bGwnLCBhY3Rpb249J3N0b3JlX3RydWUnLGhlbHA9J3VzZSBmdWxs IGNlcnRpZmljYXRlIGZvciB0aGUgVExTQSBjZXJ0IHR5cGUnKQ0KDQojIGFs bG93IG5vbi1kbnNzZWMgYW5zd2Vycw0KcGFyc2VyLmFkZF9hcmd1bWVudCgn LS1pbnNlY3VyZScsIGFjdGlvbj0nc3RvcmVfdHJ1ZScsaGVscD0nYWxsb3cg dXNlIG9mIG5vbi1kbnNzZWMgYW5zd2VycyB0byBmaW5kIFNTTCBob3N0cycp DQoNCiMgbGltaXQgbmV0d29ya2luZyB0byBpcHY0IG9yIGlwdjYgb25seQ0K cGFyc2VyLmFkZF9hcmd1bWVudCgnLTQnLCBkZXN0PSdpcHY0JywgYWN0aW9u PSdzdG9yZV90cnVlJyxoZWxwPSd1c2UgaXB2NCBuZXR3b3JraW5nIG9ubHkn KQ0KcGFyc2VyLmFkZF9hcmd1bWVudCgnLTYnLCBkZXN0PSdpcHY2JywgYWN0 aW9uPSdzdG9yZV90cnVlJyxoZWxwPSd1c2UgaXB2NiBuZXR3b3JraW5nIG9u bHknKQ0KcGFyc2VyLmFkZF9hcmd1bWVudCgnLXEnLCAnLS1xdWlldCcsIGFj dGlvbj0nc3RvcmVfdHJ1ZScsaGVscD0nc3VwcHJlc3Mgd2FybmluZ3MgYW5k IGVycm9ycycpDQpwYXJzZXIuYWRkX2FyZ3VtZW50KCctdicsICctLXZlcnNp b24nLCBhY3Rpb249J3N0b3JlX3RydWUnLGhlbHA9J3Nob3cgdmVyc2lvbiBh bmQgZXhpdCcpDQoNCiMgZmluYWxseSwgdGhlIGhvc3QgbGlzdA0KcGFyc2Vy LmFkZF9hcmd1bWVudCgnaG9zdHMnLCBtZXRhdmFyPSJob3N0bmFtZSIsIG5h cmdzPScrJykNCg0KYXJncyA9IHBhcnNlci5wYXJzZV9hcmdzKHN5cy5hcmd2 WzE6XSkNCg0KaWYgYXJncy52ZXJzaW9uOg0KCXN5cy5leGl0KCJkYW5lOiB2 ZXJzaW9uIDEuMi4yIikNCmlmIG5vdCBhcmdzLnJmYzoNCglhcmdzLmRyYWZ0 ID0gVHJ1ZQ0KDQppZiBhcmdzLmNhY2VydDoNCglzeXMuZXhpdCgiVExTQSBD QWNlcnQgdHlwZSByZWNvcmQgbm90IHlldCBzdXBwb3J0ZWQiKQ0KaWYgYXJn cy5wdWJrZXk6DQoJc3lzLmV4aXQoIlRMU0EgUHVia2V5IHR5cGUgcmVjb3Jk IG5vdCB5ZXQgc3VwcG9ydGVkIikNCg0KaWYgYXJncy5zaGE1MTI6DQoJcmVm dHlwZT0yDQplbGlmIGFyZ3MuZnVsbDoNCglyZWZ0eXBlPTANCmVsc2U6DQoJ cmVmdHlwZT0xDQoNCmlmIGFyZ3MucXVpZXQ6DQoJcXVpZXQgPSBUcnVlDQoN CmlmIGFyZ3MudGxzYToNCglhcmdzLmVlY2VydCA9IFRydWUNCg0KaWYgYXJn cy5pbnNlY3VyZToNCglzZWN1cmUgPSBGYWxzZQ0KDQppZiBhcmdzLmlwdjQg YW5kIG5vdCBhcmdzLmlwdjY6DQoJdHJhbnNwb3J0ID0gImlwdjQiDQppZiBh cmdzLmlwdjYgYW5kIG5vdCBhcmdzLmlwdjQ6DQoJdHJhbnNwb3J0ID0gImlw djYiDQoNCiMgZmlsdGVyIHRoZSBub24tb3B0aW9ucyBhcmd1bWVudHMgZm9y IGFuICJAYXJndW1lbnQiIGFuZCBjb252ZXJ0IGl0IGZvciB0aGUgYXhmciBv cHRpb24uDQpmaWx0ZXJIb3N0PSBbXQ0KaWYgbm90IGFyZ3MubmFtZXNlcnZl cjoNCglhcmdzLm5hbWVzZXJ2ZXIgPSBbXQ0KZm9yIGhvc3QgaW4gYXJncy5o b3N0czoNCglpZiBob3N0WzBdID09ICJAIjoNCgkJYXJncy5uYW1lc2VydmVy LmFwcGVuZChob3N0WzE6XSkNCgkJYXJncy5ob3N0cy5yZW1vdmUoaG9zdCkN CgkJYXJncy5heGZyPVRydWUNCgkNCmlmIGFyZ3MucmZjIGFuZCBhcmdzLmRy YWZ0Og0KCWZtdCA9ICJib3RoIg0KZWxpZiBhcmdzLnJmYzoNCglmbXQgPSAi cmZjIg0KZWxzZToNCglmbXQgPSAiZHJhZnQiDQoNCmlmIG5vdCBhcmdzLmhv c3RzOg0KCXN5cy5leGl0KCJIb3N0IGFyZSBuZWVkZWQuIikNCiMJbWFpbigi LS1oZWxwIikNCg0KZm9yIGhvc3QgaW4gYXJncy5ob3N0czoNCglpZiBob3N0 Wy0xXSAhPSAiLiI6DQoJCWhvc3QgKz0gIi4iDQppZiBub3QgYXJncy5heGZy Og0KCWZvciBob3N0IGluIGFyZ3MuaG9zdHM6DQoJCXByaW50IGNyZWF0ZV90 bHNhKGhvc3QsMSxyZWZ0eXBlKQ0KaWYgYXJncy5heGZyOg0KCSMgVHJ5IGFu ZCBBWEZSIGl0DQoJaWYgbGVuKGFyZ3MubmFtZXNlcnZlcikgPT0gMDoNCgkJ c3lzLmV4aXQoIm5hbWVzZXJ2ZXIgbmVlZGVkLiBzeW50YXg6IC1uIG5hbWVz ZXJ2ZXIiKQ0KCXJlc29sdmVyID0gbGRuc3gucmVzb2x2ZXIoYXJncy5uYW1l c2VydmVyWzBdLCBkbnNzZWM9VHJ1ZSkNCglmb3IgaG9zdCBpbiBhcmdzLmhv c3RzOg0KCQlpcHY0ID0gW10NCgkJaXB2NiA9IFtdDQoJCWZvciByciBpbiBy ZXNvbHZlci5BWEZSKGhvc3QpOg0KCQkJaWYgcnIucnJfdHlwZSgpID09ICJB IiAgICBhbmQgcnIub3duZXIoKSBub3QgaW4gaXB2NDoNCgkJCQlpcHY0LmFw cGVuZChyci5vd25lcigpKQ0KCQkJaWYgcnIucnJfdHlwZSgpID09ICJBQUFB IiBhbmQgcnIub3duZXIoKSBub3QgaW4gaXB2NjoNCgkJCQlpcHY2LmFwcGVu ZChyci5vd25lcigpKQ0KCQlpZiB0cmFuc3BvcnQgIT0gImlwdjYiOg0KCQkJ Zm9yIGhvc3QgaW4gaXB2NDoNCgkJCQlwcmludCBjcmVhdGVfdGxzYShob3N0 LDEscmVmdHlwZSkNCgkJaWYgdHJhbnNwb3J0ICE9ICJpcHY0IjoNCgkJCWZv ciBob3N0IGluIGlwdjY6DQoJCQkJcHJpbnQgY3JlYXRlX3Rsc2EoaG9zdCwx LHJlZnR5cGUpDQoNCg0K --8323328-1054247823-1327340845=:28037-- From paul.hoffman@vpnc.org Mon Jan 23 09:54:46 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6133021F8679 for ; Mon, 23 Jan 2012 09:54:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQt3OZ14i8eg for ; Mon, 23 Jan 2012 09:54:46 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id D292321F8467 for ; Mon, 23 Jan 2012 09:54:45 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q0NHshdj067080 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 Jan 2012 10:54:43 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20120122183325.GA6635@odin.ulthar.us> Date: Mon, 23 Jan 2012 09:54:43 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8BD41639-E2A2-4348-9796-B2BFF193B088@vpnc.org> References: <59E1FDB4-B832-415A-BEE3-8E85CC55E337@vpnc.org> <20120122012034.GA24296@odin.ulthar.us> <20120122183325.GA6635@odin.ulthar.us> To: Scott Schmit X-Mailer: Apple Mail (2.1251.1) Cc: dane@ietf.org Subject: Re: [dane] Pseudocode review X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 17:54:46 -0000 Sorry, I'm still missing it, and I think that the problem is on my end. On Jan 22, 2012, at 10:33 AM, Scott Schmit wrote: > On Sun, Jan 22, 2012 at 09:35:42AM -0800, Paul Hoffman wrote: >> On Jan 21, 2012, at 5:20 PM, Scott Schmit wrote: >>> This pseudocode implies that the TLSA checker will/should search >>> possible PKIX chains more thoroughly than the client normally would = to >>> try to find a match. This is a little out of step with the warnings = in >>> A.1.1. (And the main text is silent on the question.) >>=20 >> I'm not sure what you mean here; please say more. >=20 > Sure. In the pseudocode: > // A TLS client might have multiple trust anchors that it might use > // when validating the TLS server's end entity certificate. Also, > // there can be multiple PKIX validation chains for the > // certificates given by the server in TLS. Thus, there are > // possibly many chains that might need to be tested during > // PKIX validation. >=20 > Normally, if there are multiple possible chains between the = certificate > and a trust anchor, the client will stop after finding the first chain > that validates successfully. Here, it checks every possibility until = it > either finds a TLSA match or finds none at all. I don't see how the wording above indicates that all chains must be = tested. It says "might need to be tested". > In A.1.1, the text implies that the client will stop after finding the > first chain that works, so the operator should chose their anchor with > care, because the association could fail for some clients or under = some > conditions (e.g., the client has or hasn't visited a site with an > alternate certificate recently). Yes, that is correct. If you propose alternate wording for the pseudocode comment above, I = suspect I'll say "that's what we meant" and use it directly. --Paul Hoffman From paul.hoffman@vpnc.org Mon Jan 23 10:02:44 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE52321F86AA for ; Mon, 23 Jan 2012 10:02:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afnW6Hv36E+G for ; Mon, 23 Jan 2012 10:02:44 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8B221F86A9 for ; Mon, 23 Jan 2012 10:02:44 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q0NI2g5E067391 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 Jan 2012 11:02:43 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20120122183719.GB14597@odin.ulthar.us> Date: Mon, 23 Jan 2012 10:02:42 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <59E1FDB4-B832-415A-BEE3-8E85CC55E337@vpnc.org> <20120122183719.GB14597@odin.ulthar.us> To: Scott Schmit X-Mailer: Apple Mail (2.1251.1) Cc: dane@ietf.org Subject: Re: [dane] Pseudocode review X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 18:02:45 -0000 On Jan 22, 2012, at 10:37 AM, Scott Schmit wrote: > On Wed, Jan 04, 2012 at 06:46:25AM -0800, Paul Hoffman wrote: >> Greetings again. As Jakob indicated, we would *really* like to have a >> careful review of the pseudocode now instead of waiting for WG Last >> Call. TLSA has rules spread in many part of the body text, and the >> pseudocode is supposed to pull every rule into one place, correctly. >> Many developers like pseudocode, and will tend to focus on this >> non-normative appendix rather than the body text. Ilari already found >> one small error (thanks!), and we would like developer-like folks on >> the list to poke harder at the section so that we are somewhat >> confident that everyone understands what the protocol is doing. >=20 > Sorry I missed this the first time, but I notice that with certificate > usage type 2, the pseudocode doesn't pay attention to the selector = type > or match type fields. I had a very good reason for not adding that when Jakob and I were first = working on the pseudocode, and for the life of me I can't remember it. = I'll add it in the -15. > At the same time, there's no enforcement of the > implicit rule that the selector type will be 0 and the match type 0. > Also, nothing in the text says anything approaching "if the usage is = 2, > the selector type and match type MUST be 0". >=20 > I don't think such a rule is necessary, provided the trust anchor used > is a commonly-known one. For private trust anchors, they'll need to = use > matching type 0 and selector type 0 if the connection is going to > succeed. Selector type 1 implies that the client has a full = certificate > to extract the SPKI from, which in this case, it wouldn't. Perhaps = that > should be in the text somewhere. I fully disagree with that last paragraph. Usage type 2 is useful for = the case of "I generated this cert myself and I'm going to use it in the = TLS handshake so that the chain to the (new TLSA) root is length 0". --Paul Hoffman From ondrej.mikle@nic.cz Mon Jan 23 10:07:49 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5117C21F86C4 for ; Mon, 23 Jan 2012 10:07:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r98nap3zHGTk for ; Mon, 23 Jan 2012 10:07:45 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 0306C21F8693 for ; Mon, 23 Jan 2012 10:07:45 -0800 (PST) Received: from [IPv6:2001:1488:ac14:1400:222:64ff:fe2f:75c2] (unknown [IPv6:2001:1488:ac14:1400:222:64ff:fe2f:75c2]) by mail.nic.cz (Postfix) with ESMTPSA id BA6AF2A2B1F; Mon, 23 Jan 2012 19:07:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1327342063; bh=Y9g2zMS4W68M2ANQqc0eRUYVDN6mF9PxJeWSxWcU6mM=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Qwxl+B3kyUr655kKCmnrzvdVwDMemaBvLpK3dVhYfKYbZfu+CKNIEtwwv75FS6Xcy qrfd2pORIvevqTxBeW6nwFDA20fbRdpkS31Ep11+MZTa14OUdbHyJ0s3r0ittb5ZzK ysAFEnYhvUZHn5pk6jI+S89ebLypbCUAvOECCC58= Message-ID: <4F1DA1B1.6030404@nic.cz> Date: Mon, 23 Jan 2012 19:06:41 +0100 From: Ondrej Mikle User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Jim Schaad References: <4EEE63EB.9020800@nic.cz> <00ca01ccc5b6$57d79e10$0786da30$@augustcellars.com> In-Reply-To: <00ca01ccc5b6$57d79e10$0786da30$@augustcellars.com> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane@ietf.org Subject: Re: [dane] New "operational considerations" text (was: Addition to "Security considerations") X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 18:07:49 -0000 On 12/29/2011 12:13 AM, Jim Schaad wrote: > From my point of view this text is far improved. > > Of course I still have some suggestions Updated version of current A.1 section is below (it's shortened output from xml2rfc, I'll post link to git source tomorrow). Typos and errors mentioned in other threads should be fixed as well. I mostly adopted Jim's suggestion/replacement texts without changes. What caused probably most confusion in the text is the difference in RFCs and actual PKIX implementations: AFAIK the only implementation that can return all chains is MS CryptoAPI, others don't implement it - NSS definitely doesn't and I didn't find it in Java libs (security API and bouncycastle) or OS X's Security.framework. I removed references to "first match only" behavior from the text, but we need to keep in mind that in the "transitional period" such behavior is likely to cause some issues (and given that many implementations are not even close to RFC 3280/5280 compliant, it will take some time). --- begin text --- A.1. Creating TLSA Records When creating TLSA record with certificate usage type 0 (CA Certificate) or type 2 (Trust Anchor), the implications need to be understood taken when choosing between selector type 0 (full certificate) and 1 (SubjectPublicKeyInfo). Careful choice is required due to the different methods various TLS clients employed to build trust-chains. We first outline cases to be aware of and then discuss implications on choice of selector type. Certificate usage 2 is not affected by the issue of chain building when the end entity certificate and the trust anchor certificate are the same. A.1.1. Ambiguities and corner cases of trust-chain building by TLS clients TLS clients may implement their own chain building code rather than rely on the chain presented by the server. This means that, except for the end-entity certificate, any certificate presented in the suggested chain may or may not be present in the final chain built by the client. Certificates the client can use to replace certificates from original chain include: 1. client's trust anchors 2. certificates cached locally 3. certificates retrieved via URI listed in Authority Information Access X.509v3 extension. CAs frequently issue/reissue certificates with different validity period, signature algorithm (updated hash), CA key pair (cross- certificate) or extensions (public key, subject remain intact). Those are the certificates TLS client can use in place of an original certificate. Cases when clients are known to exchange or remove certificates that could cause TLSA association by full certificate to fail are listed below: 1. The client considers the signature algorithm of a certificate to no longer be sufficiently secure. This may be because of the hash algorithm or the signature key size. 2. The client may not have associated root certificate in trust store and uses a cross-certificate with identical subject and public key instead. A.1.2. Discussion on choice of selector type Definition: "false-negative failure" means that client will not accept the TLSA association for certificate designated by DNS administrator. A.1.2.1. Choosing selector type 0 (full certificate) "Full certificate" selector provides most precise specification of TLS certificate association, capturing all fields of X.509 certificate. For DNS administrator, best course to avoid false- negative failures at client's side when using this selector are: 1. don't associate to CA certificates having signature algorithm with hash that is considered weak if CA issued a replacement certificate - hash algorithms considered weak at moment of writing: MD2 (RFC 6149), MD5 (RFC 6331) 2. check how common client programs process the TLSA association on fresh client installations - local certificate cache needs to be empty A.1.2.2. Choosing selector type 1 (SubjectPublicKeyInfo) SubjectPublicKeyInfo selector gives greater flexibility in avoiding share of false-negative failures caused by trust-chain-building algorithms used in clients. One specific use-case should be noted: creating TLSA association to certificate I1 that directly signed end entity certificate S1 of server. Since the key used to sign S1 is fixed, association to I1 must succeed - if client swaps I1 for other certificate I2, its SPKI must match SPKI of I1. Such association would not suffer from false- negative failure on client's side should the client use a reissued CA certificate I2 in place of I1. The attack surface is a bit broader compared to "full certificate" selector: 1. administrator must know or trust the CA not to engage in bad practices (not sharing key of I1 for unrelated CA certificates leading to trust-chain redirect) 2. administrator should understand whether some X.509v3 extension may adversely affect security of the association. If possible, administrator should overview CA certificates sharing the SPKI. Using SPKI selector for association with a certificate in chain above I1 is to be decided on by-case basis. There are too many possibilities depending on issuing CA. Unless full implications of such association are understood by administrator, using selector type 0 might be better option security-wise. --- end-text --- Ondrej Mikle From ondrej.mikle@nic.cz Mon Jan 23 10:36:41 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F06921F8588 for ; Mon, 23 Jan 2012 10:36:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyfIacH4Pqaz for ; Mon, 23 Jan 2012 10:36:41 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id BA11F21F8582 for ; Mon, 23 Jan 2012 10:36:40 -0800 (PST) Received: from [IPv6:2001:1488:ac14:1400:222:64ff:fe2f:75c2] (unknown [IPv6:2001:1488:ac14:1400:222:64ff:fe2f:75c2]) by mail.nic.cz (Postfix) with ESMTPSA id F228B2A0BD3 for ; Mon, 23 Jan 2012 19:36:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1327343800; bh=l6TMFZ0WJAqhMAe58XQa2rF4fOZIHYTienOA6ecCbGM=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=w++IzRyDaRJZi8kNY0aVFGlf2RPPGTTA2o/zGETR0pf/fclriRkdpafLxpXKdeaMS vWpeo75ERhGop7QZTtnGqkyz9OqZL+VBu6laYpvImwrA0p7Uz5062fUi1An7nXV4x1 XjuqkybMF98Pgh9hFN5jrStfAGMWiCZ3Aqi4aFqQ= Message-ID: <4F1DA879.3010504@nic.cz> Date: Mon, 23 Jan 2012 19:35:37 +0100 From: Ondrej Mikle User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: dane@ietf.org References: <59E1FDB4-B832-415A-BEE3-8E85CC55E337@vpnc.org> <20120122012034.GA24296@odin.ulthar.us> <20120122183325.GA6635@odin.ulthar.us> <8BD41639-E2A2-4348-9796-B2BFF193B088@vpnc.org> In-Reply-To: <8BD41639-E2A2-4348-9796-B2BFF193B088@vpnc.org> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: Re: [dane] Pseudocode review X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 18:36:41 -0000 On 01/23/2012 06:54 PM, Paul Hoffman wrote: > Sorry, I'm still missing it, and I think that the problem is on my end. > > On Jan 22, 2012, at 10:33 AM, Scott Schmit wrote: > >> In A.1.1, the text implies that the client will stop after finding the >> first chain that works, so the operator should chose their anchor with >> care, because the association could fail for some clients or under some >> conditions (e.g., the client has or hasn't visited a site with an >> alternate certificate recently). > > > Yes, that is correct. > > If you propose alternate wording for the pseudocode comment above, I suspect I'll say "that's what we meant" and use it directly. I removed the "first match" behavior from the update to A.1 I posted a while ago. Though in real deployment it will take time until implementations support building and checking all paths (e.g. RFC 4158). What about adding the following sentence at the end of the "// A TLS client might have multiple trust anchors that it might..." pseudocode commend: "Note that there will be transitional period where clients may not check all chains and instead pick one arbitrary chain." Ondrej Mikle From mrex@sap.com Mon Jan 23 11:21:32 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2653B21F86F0 for ; Mon, 23 Jan 2012 11:21:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.083 X-Spam-Level: X-Spam-Status: No, score=-10.083 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMDWdPXIEQIM for ; Mon, 23 Jan 2012 11:21:31 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5713F21F86EF for ; Mon, 23 Jan 2012 11:21:31 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q0NJLT8w009923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 Jan 2012 20:21:29 +0100 (MET) From: Martin Rex Message-Id: <201201231921.q0NJLS1i021543@fs4113.wdf.sap.corp> To: i.grok@comcast.net (Scott Schmit) Date: Mon, 23 Jan 2012 20:21:28 +0100 (MET) In-Reply-To: <20120123033124.GD14597@odin.ulthar.us> from "Scott Schmit" at Jan 22, 12 10:31:24 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] Opening Issue #37. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 19:21:32 -0000 Scott Schmit wrote: > > The draft states: > # 2 -- The target certificate MUST pass PKIX validation, with any > # certificate matching the TLSA record considered to be a trust > # anchor for this validation That statement in the draft seems to be somewhat incorrect and misleading. If the TLSA usage type 2 refers to a NON-self-signed End-Entity cert (or its hash or its SPKI), then it will be technically impossible to perform PKIX path validation. So the PKIX path validation for usage type 2 needs to be conditionalized to those situations where there exists a PKIX path. -Martin From zack.weinberg@gmail.com Mon Jan 23 12:39:37 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7406D21F86B8 for ; Mon, 23 Jan 2012 12:39:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ASAKVv+ejfU for ; Mon, 23 Jan 2012 12:39:37 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D897021F8670 for ; Mon, 23 Jan 2012 12:39:36 -0800 (PST) Received: by obbwc12 with SMTP id wc12so4189872obb.31 for ; Mon, 23 Jan 2012 12:39:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=9QmdCCCS56yrtEGSK7MDCKMxrZife++qDqN5tkCH9e0=; b=AXrFW5DdRqyMZuD7aaIfTSpoXiOQq+4PdMG+8ZECcb3cOS0ZO9sXaO7k5BlWqqCHkQ Cw4Jlo1BA3CgRg0BqV5Eh55v8J4KaG98uh77V7Li4ixixvapF25X9yDWFVNkZSZWq37a YHtH48uMCxomJ24mF6r9wlieGd6hfe9ioHDyg= MIME-Version: 1.0 Received: by 10.182.222.102 with SMTP id ql6mr9268091obc.2.1327351176508; Mon, 23 Jan 2012 12:39:36 -0800 (PST) Sender: zack.weinberg@gmail.com Received: by 10.182.227.69 with HTTP; Mon, 23 Jan 2012 12:39:36 -0800 (PST) In-Reply-To: <201201231921.q0NJLS1i021543@fs4113.wdf.sap.corp> References: <20120123033124.GD14597@odin.ulthar.us> <201201231921.q0NJLS1i021543@fs4113.wdf.sap.corp> Date: Mon, 23 Jan 2012 12:39:36 -0800 X-Google-Sender-Auth: kc8YxEYi5J7psr0tT3ROFFNqH-0 Message-ID: From: Zack Weinberg To: dane@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: Re: [dane] Opening Issue #37. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 20:39:37 -0000 This seems like a decent point to bring up (again) the fact that as far as I am aware, "libpkix" is the only open-source *library* out there that claims to implement RFC 4158 and 5280 in detail, and no *client* I know of uses it unconditionally. In particular, for HTTPS, while both Firefox and Chrome have stated *plans* to switch to libpkix, these plans have no dates attached to them, and the other widely used browsers have expressed no interest at all in public. The "legacy" certificate validation algorithms that all browsers use at the moment are *not* conformant to either RFC and there are advocates for keeping it that way (largely on efficiency and "nobody needs all of that damn complexity anyway" grounds). Outside HTTPS, I am not familiar with the state of play, but I would expect it to be similar. Furthermore, as Peter Gutmann has pointed out repeatedly on this list, "PKIX validation" is *not* a well-defined term even within the RFCs - the language is sloppy enough that implementations can and do disagree on what the correct behavior is. I think it is not DANE's job to fix this mess, and we should drop the phrase "PKIX validation" entirely from the spec, replacing it with something like # DANE clients SHOULD perform the same validation steps on the # certificate chain that they would have in the absence of TLSA # records, except that they MUST defer deciding whether the chain # terminates in an acceptable root until TLSA information has been # taken into account. thus allowing DANE-compliant clients to continue with their present state of (non)conformance to PKIX. zw From pieter.lexis@os3.nl Mon Jan 23 13:06:35 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA8EE21F86DC for ; Mon, 23 Jan 2012 13:06:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.34 X-Spam-Level: X-Spam-Status: No, score=-2.34 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eoInatOb4RI8 for ; Mon, 23 Jan 2012 13:06:35 -0800 (PST) Received: from mail.serv.os3.nl (mail.serv.os3.nl [IPv6:2001:610:158:960::25]) by ietfa.amsl.com (Postfix) with ESMTP id 57F8521F86DA for ; Mon, 23 Jan 2012 13:06:35 -0800 (PST) Received: from smtp.os3.nl (smtp.os3.nl [IPv6:2001:610:158:960::119]) by mail.serv.os3.nl (Postfix) with ESMTP id 2149017AA0A for ; Mon, 23 Jan 2012 22:06:34 +0100 (CET) Received: from [IPv6:2001:980:5dd1:1:e991:65d4:ca5c:96f5] (unknown [IPv6:2001:980:5dd1:1:e991:65d4:ca5c:96f5]) by smtp.os3.nl (Postfix) with ESMTPSA id C83A817AA01 for ; Mon, 23 Jan 2012 22:06:33 +0100 (CET) Message-ID: <4F1DCBD8.9020903@os3.nl> Date: Mon, 23 Jan 2012 22:06:32 +0100 From: Pieter Lexis User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111109 Thunderbird/3.1.16 MIME-Version: 1.0 To: dane@ietf.org References: <20120104081557.23741.87139.idtracker@ietfa.amsl.com> <4F0C3895.4030200@os3.nl> In-Reply-To: <4F0C3895.4030200@os3.nl> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dane] I-D Action: draft-ietf-dane-protocol-14.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 21:06:36 -0000 Hi, Another typo: On page 8, in the RR examples: The last 2 example miss the opening bracket before the certificate for association. _443._tcp.www.example.com. IN TLSA 1 1 2 92003ba34942dc74152e2f2c408d29ec a5a520e7f2e06bb944f4dca346baf63c 1b177615d466f6c4b71c216a50292bd5 8c9ebdd2f74e38fe51ffd48c43326cbc ) Must be: _443._tcp.www.example.com. IN TLSA ( 1 1 2 92003ba34942dc74152e2f2c408d29ec a5a520e7f2e06bb944f4dca346baf63c 1b177615d466f6c4b71c216a50292bd5 8c9ebdd2f74e38fe51ffd48c43326cbc ) And _443._tcp.www.example.com. IN TLSA 2 0 0 30820307308201efa003020102020... ) must be _443._tcp.www.example.com. IN TLSA ( 2 0 0 30820307308201efa003020102020... ) Regards, Pieter Lexis From warren@kumari.net Mon Jan 23 14:15:00 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A84FC21F8499 for ; Mon, 23 Jan 2012 14:15:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.211 X-Spam-Level: X-Spam-Status: No, score=-106.211 tagged_above=-999 required=5 tests=[AWL=-0.212, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id spuM3eH04ygN for ; Mon, 23 Jan 2012 14:14:59 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id CCCA821F871C for ; Mon, 23 Jan 2012 14:14:59 -0800 (PST) Received: from dhcp-172-19-119-228.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id F3F081B40680; Mon, 23 Jan 2012 17:14:58 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Warren Kumari In-Reply-To: Date: Mon, 23 Jan 2012 17:14:57 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <94CE2361-B25E-41AF-9B1F-AFEF67472E1D@kumari.net> References: <8A3B478E-6D5F-4DF7-80FC-895B5C47675B@kumari.net> <026B2D43-F056-44B5-BCEA-825CC57B0BD7@vpnc.org> <4F0B1162.1080304@ogud.com> <3C2FA271-6A49-4A7B-A871-AE19FF3318DC@nic.cz> To: Warren Kumari X-Mailer: Apple Mail (2.1084) Cc: dane@ietf.org Subject: Re: [dane] Opening Issue #35 - Behavior for a supported algorithm that is not considered "strong" by the client. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 22:15:00 -0000 Hi all, I am calling consensus on this item. The authors are requested to add text similar to what was proposed = below, but to please try and word the conditions as a list (as suggested = by Olafur) to aid readability. Thank you all for making this consensus call easy :-P W On Jan 10, 2012, at 12:03 PM, Warren Kumari wrote: > [ No hats ]=20 > On Jan 10, 2012, at 9:59 AM, Ond=C5=99ej Sur=C3=BD wrote: >=20 >>=20 >> On 9. 1. 2012, at 17:10, Olafur Gudmundsson wrote: >>=20 >>> On 08/01/2012 21:00, Paul Hoffman wrote: >>>> At the end of section 4.4, we currently say: >>>> If a certificate association contains a certificate usage, = selector, >>>> or matching type that is not understood by the TLS client, that >>>> certificate association MUST be marked as unusable. If the >>>> comparison data for a certificate is malformed, the certificate >>>> association MUST be marked as unusable. >>>>=20 >>>> I propose that we add: >>>> If a certificate association contains a matching type or = certificate >>>> for association that uses a cryptographic algorithm that is >>>> considered too weak for the TLS client's policy, the certificate >>>> association MUST be marked as unusable. >>=20 >> +1 here >=20 > +1. >=20 >>=20 >>>> --Paul Hoffman >>>>=20 >>> +1 In general to the text, but can we convert this to a list for = readability? >>>=20 >>> Something like: (rough draft) >>> If a certificate association contains one or more of the following = conditions: >>> - certification usage, select or machining type that is not = understood >>> - uses a cryptographic algorithm considered too weak by policy >>> - comparison data for the certificate is malformed >>> the client MUST mark that certificate association as unusable. >>=20 >>=20 >> Also +1 here >=20 > +0 (I don't care either way -- I slightly prefer the text as provided, = but not enough to count.) >=20 > W >=20 >>=20 >> O. >> -- >> Ond=C5=99ej Sur=C3=BD >> vedouc=C3=AD v=C3=BDzkumu/Head of R&D department >> ------------------------------------------- >> CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC >> Americka 23, 120 00 Praha 2, Czech Republic >> mailto:ondrej.sury@nic.cz http://nic.cz/ >> tel:+420.222745110 fax:+420.222745112 >> ------------------------------------------- >>=20 >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >=20 From trac+dane@trac.tools.ietf.org Mon Jan 23 14:26:24 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C9F621F8796 for ; Mon, 23 Jan 2012 14:26:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJcsbTqdSBYF for ; Mon, 23 Jan 2012 14:26:24 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id E9AD521F8795 for ; Mon, 23 Jan 2012 14:26:23 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RpSL5-0007RW-Cy; Mon, 23 Jan 2012 17:26:11 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-dane-protocol@tools.ietf.org, warren@kumari.net X-Trac-Project: dane Date: Mon, 23 Jan 2012 22:26:11 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/35#comment:1 Message-ID: <071.a12dc5b0695a3f15d01a8498ac232fce@trac.tools.ietf.org> References: <056.1a974588106d5c2e6a6fd25a8a0d7236@trac.tools.ietf.org> X-Trac-Ticket-ID: 35 In-Reply-To: <056.1a974588106d5c2e6a6fd25a8a0d7236@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dane-protocol@tools.ietf.org, warren@kumari.net, dane@ietf.org X-SA-Exim-Mail-From: trac+dane@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120123222623.E9AD521F8795@ietfa.amsl.com> Resent-Date: Mon, 23 Jan 2012 14:26:23 -0800 (PST) Resent-From: trac+dane@trac.tools.ietf.org Cc: dane@ietf.org Subject: Re: [dane] #35: Behavior for a supported algorithm that is not considered "strong" by the client. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 22:26:24 -0000 #35: Behavior for a supported algorithm that is not considered "strong" by the client. Changes (by warren@…): * status: new => closed * resolution: => fixed Comment: "The authors are requested to add text similar to what was proposed below, but to please try and word the conditions as a list (as suggested by Olafur) to aid readability. Thank you all for making this consensus call easy :-P" http://www.ietf.org/mail-archive/web/dane/current/msg04146.html ------ The proposed text was (to save folk having to click on the link or read the archives :-)): If a certificate association contains a matching type or certificate for association that uses a cryptographic algorithm that is considered too weak for the TLS client's policy, the certificate association MUST be marked as unusable. Olafur's suggestion: +1 In general to the text, but can we convert this to a list for readability? Something like: (rough draft) If a certificate association contains one or more of the following conditions: - certification usage, select or machining type that is not understood - uses a cryptographic algorithm considered too weak by policy - comparison data for the certificate is malformed the client MUST mark that certificate association as unusable. -- -------------------------+----------------------------------------- Reporter: warren@… | Owner: draft-ietf-dane-protocol@… Type: enhancement | Status: closed Priority: minor | Milestone: Component: protocol | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+----------------------------------------- Ticket URL: dane From paul.hoffman@vpnc.org Mon Jan 23 14:50:30 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F286C21F8661 for ; Mon, 23 Jan 2012 14:50:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PILlYZK7Styu for ; Mon, 23 Jan 2012 14:50:30 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 77D0921F865C for ; Mon, 23 Jan 2012 14:50:30 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q0NMoSLH078134 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 23 Jan 2012 15:50:29 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Paul Hoffman In-Reply-To: <201201231921.q0NJLS1i021543@fs4113.wdf.sap.corp> Date: Mon, 23 Jan 2012 14:50:27 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <734367B8-48F9-4D8F-A106-DC744754FB84@vpnc.org> References: <201201231921.q0NJLS1i021543@fs4113.wdf.sap.corp> To: IETF DANE WG list X-Mailer: Apple Mail (2.1251.1) Subject: Re: [dane] Opening Issue #37. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 22:50:31 -0000 On Jan 23, 2012, at 11:21 AM, Martin Rex wrote: > Scott Schmit wrote: >>=20 >> The draft states: >> # 2 -- The target certificate MUST pass PKIX validation, with any >> # certificate matching the TLSA record considered to be a trust >> # anchor for this validation >=20 > That statement in the draft seems to be somewhat incorrect and = misleading. >=20 > If the TLSA usage type 2 refers to a NON-self-signed End-Entity cert > (or its hash or its SPKI), then it will be technically impossible to > perform PKIX path validation. I fully disagree with this statement. Trust anchors in PKIX (RFC 5280) = are keys, not certificates. If you believe otherwise, please quote from = RFC 5280. > So the PKIX path validation for usage type 2 needs to be = conditionalized > to those situations where there exists a PKIX path. A path between a certificate and itself is still a path. --Paul Hoffman From paul.hoffman@vpnc.org Mon Jan 23 14:54:37 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD1B21F8555 for ; Mon, 23 Jan 2012 14:54:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K9cAsT8w22ZP for ; Mon, 23 Jan 2012 14:54:36 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7B84B21F853A for ; Mon, 23 Jan 2012 14:54:36 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q0NMsZol078302 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 23 Jan 2012 15:54:36 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Paul Hoffman In-Reply-To: Date: Mon, 23 Jan 2012 14:54:34 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7769AE22-B0EF-48F2-86E8-AD6977F83124@vpnc.org> References: <20120123033124.GD14597@odin.ulthar.us> <201201231921.q0NJLS1i021543@fs4113.wdf.sap.corp> To: IETF DANE WG list X-Mailer: Apple Mail (2.1251.1) Subject: Re: [dane] Opening Issue #37. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 22:54:37 -0000 On Jan 23, 2012, at 12:39 PM, Zack Weinberg wrote: > This seems like a decent point to bring up (again) the fact that as > far as I am aware, "libpkix" is the only open-source *library* out > there that claims to implement RFC 4158 and 5280 in detail, and no > *client* I know of uses it unconditionally. In particular, for HTTPS, > while both Firefox and Chrome have stated *plans* to switch to > libpkix, these plans have no dates attached to them, and the other > widely used browsers have expressed no interest at all in public. The > "legacy" certificate validation algorithms that all browsers use at > the moment are *not* conformant to either RFC and there are advocates > for keeping it that way (largely on efficiency and "nobody needs all > of that damn complexity anyway" grounds). Outside HTTPS, I am not > familiar with the state of play, but I would expect it to be similar. >=20 > Furthermore, as Peter Gutmann has pointed out repeatedly on this list, > "PKIX validation" is *not* a well-defined term even within the RFCs - > the language is sloppy enough that implementations can and do disagree > on what the correct behavior is. >=20 > I think it is not DANE's job to fix this mess, and we should drop the > phrase "PKIX validation" entirely from the spec, replacing it with > something like >=20 > # DANE clients SHOULD perform the same validation steps on the > # certificate chain that they would have in the absence of TLSA > # records, except that they MUST defer deciding whether the chain > # terminates in an acceptable root until TLSA information has been > # taken into account. >=20 > thus allowing DANE-compliant clients to continue with their present > state of (non)conformance to PKIX. -1. This proposed wording is just as silly as people saying that PKIX = validation is well-defined and well-understood. Saying "we don't know = what conformant means" is a terrible way to write a standard. --Paul Hoffman From paul.hoffman@vpnc.org Mon Jan 23 14:56:29 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BEE421F8667 for ; Mon, 23 Jan 2012 14:56:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MIuEQ5yl+FST for ; Mon, 23 Jan 2012 14:56:28 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id AEBC021F8555 for ; Mon, 23 Jan 2012 14:56:28 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q0NMuRj9078394 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 Jan 2012 15:56:28 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4F1DCBD8.9020903@os3.nl> Date: Mon, 23 Jan 2012 14:56:26 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <1347F834-BA42-4407-86B4-2B16754FBD1F@vpnc.org> References: <20120104081557.23741.87139.idtracker@ietfa.amsl.com> <4F0C3895.4030200@os3.nl> <4F1DCBD8.9020903@os3.nl> To: Pieter Lexis X-Mailer: Apple Mail (2.1251.1) Cc: dane@ietf.org Subject: Re: [dane] I-D Action: draft-ietf-dane-protocol-14.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 22:56:29 -0000 On Jan 23, 2012, at 1:06 PM, Pieter Lexis wrote: > Another typo: >=20 > On page 8, in the RR examples: > The last 2 example miss the opening bracket before the certificate for > association. Interestingly, the AppsArea reviewer's message from yesterday pointed = this out. You have just negated my message to him that no one had = noticed the error until now. :-) Fixed in -15. --Paul Hoffman From paul.hoffman@vpnc.org Mon Jan 23 15:04:22 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4241C21F855D for ; Mon, 23 Jan 2012 15:04:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YdkQ-sDOpUbw for ; Mon, 23 Jan 2012 15:04:21 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id B3B6021F855B for ; Mon, 23 Jan 2012 15:04:21 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q0NN4KDa078694 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 Jan 2012 16:04:21 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4F1DA879.3010504@nic.cz> Date: Mon, 23 Jan 2012 15:04:19 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <077BF214-D6FA-4079-A0E2-CFD3D39A80BD@vpnc.org> References: <59E1FDB4-B832-415A-BEE3-8E85CC55E337@vpnc.org> <20120122012034.GA24296@odin.ulthar.us> <20120122183325.GA6635@odin.ulthar.us> <8BD41639-E2A2-4348-9796-B2BFF193B088@vpnc.org> <4F1DA879.3010504@nic.cz> To: Ondrej Mikle X-Mailer: Apple Mail (2.1251.1) Cc: dane@ietf.org Subject: Re: [dane] Pseudocode review X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 23:04:22 -0000 On Jan 23, 2012, at 10:35 AM, Ondrej Mikle wrote: > On 01/23/2012 06:54 PM, Paul Hoffman wrote: >> Sorry, I'm still missing it, and I think that the problem is on my = end. >>=20 >> On Jan 22, 2012, at 10:33 AM, Scott Schmit wrote: >>=20 >>> In A.1.1, the text implies that the client will stop after finding = the >>> first chain that works, so the operator should chose their anchor = with >>> care, because the association could fail for some clients or under = some >>> conditions (e.g., the client has or hasn't visited a site with an >>> alternate certificate recently). >>=20 >>=20 >> Yes, that is correct. >>=20 >> If you propose alternate wording for the pseudocode comment above, I = suspect I'll say "that's what we meant" and use it directly. >=20 >=20 > I removed the "first match" behavior from the update to A.1 I posted a > while ago. Though in real deployment it will take time until > implementations support building and checking all paths (e.g. RFC = 4158). >=20 > What about adding the following sentence at the end of the "// A TLS > client might have multiple trust anchors that it might..." pseudocode > commend: >=20 > "Note that there will be transitional period where clients may not = check > all chains and instead pick one arbitrary chain." I'm still confused. Why should an implementation check all chains? The = first good chain is good enough, yes? --Paul Hoffman From ondrej.mikle@nic.cz Mon Jan 23 15:09:59 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE48D21F855D for ; Mon, 23 Jan 2012 15:09:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKFpZ+N4P9I8 for ; Mon, 23 Jan 2012 15:09:59 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 0871E21F8557 for ; Mon, 23 Jan 2012 15:09:59 -0800 (PST) Received: from localhost.localdomain (ip-84-42-137-177.net.upcbroadband.cz [84.42.137.177]) by mail.nic.cz (Postfix) with ESMTPSA id 2773A2A2EFE for ; Tue, 24 Jan 2012 00:09:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1327360198; bh=3DUNa+AqAueYw+yZWb9wqY0J7NdhpjIWR+Ibp/7kGjw=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=KlYyUCU2ooaqFo7mwOZNbW+caQofP/LyWxZuf9YC/ZmZTMzk0HH1Pvv/P2aYOXkZy k9e/WIS+MaCv5im3OgRfOLHveZ9ydzoNDfVHXN5ZUM4HbOWluwbdbyBpUK1IpFXfF2 yv2UF/BZcde5cFv7M3+NT/4AaPiHPB0siTs4yZSo= Message-ID: <4F1DE8C5.5090700@nic.cz> Date: Tue, 24 Jan 2012 00:09:57 +0100 From: Ondrej Mikle User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: dane@ietf.org References: <20120123033124.GD14597@odin.ulthar.us> <201201231921.q0NJLS1i021543@fs4113.wdf.sap.corp> In-Reply-To: X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: Re: [dane] Opening Issue #37. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 23:10:00 -0000 On 01/23/2012 09:39 PM, Zack Weinberg wrote: > This seems like a decent point to bring up (again) the fact that as > far as I am aware, "libpkix" is the only open-source *library* out > there that claims to implement RFC 4158 and 5280 in detail, and no > *client* I know of uses it unconditionally. [snip] > I think it is not DANE's job to fix this mess, and we should drop the > phrase "PKIX validation" entirely from the spec, replacing it with > something like > > # DANE clients SHOULD perform the same validation steps on the > # certificate chain that they would have in the absence of TLSA > # records, except that they MUST defer deciding whether the chain > # terminates in an acceptable root until TLSA information has been > # taken into account. > > thus allowing DANE-compliant clients to continue with their present > state of (non)conformance to PKIX. I agree with your description of the issue, but I don't think the proposed replacement of "PKIX validation" will solve it. The real issue is in "non-deterministic" way how clients build trust paths presently (and with caching of intermediate certs, it's non-trivial to reproduce). While before DANE a client built some chain that validated, with TLSA constraints it won't be enough. RFC 4158 section 6 just adds more non-determinism, especially AIA retrieval. I'm a bit afraid that the discover-all-chains-when-checking-TLSA algorithm, while being correct, raises the bar too high (implementation-wise and performance-wise; following thread has quite concise summary on real-world implementation: http://comments.gmane.org/gmane.comp.mozilla.crypto/16445) Ondrej Mikle From zack.weinberg@gmail.com Mon Jan 23 15:35:45 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32A0C21F8681 for ; Mon, 23 Jan 2012 15:35:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8B3NXgiFeWS for ; Mon, 23 Jan 2012 15:35:44 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id AA29C21F867B for ; Mon, 23 Jan 2012 15:35:44 -0800 (PST) Received: by obbwc12 with SMTP id wc12so4404439obb.31 for ; Mon, 23 Jan 2012 15:35:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=el5aNlHPYlE8bsoD463/7BD2eLW3tbSPkizTn1o61wQ=; b=aQU/nsfHgC2GpIpwQzN7dI9jjWEjvnAhoWXr1NxyoFfVqQMA7ppSxPEPT9G8XK8jKU TkKTqaQJSrTUOXKWRz75+Fzeth1Q0qJ9s2vMEXUMkOaTnnnw/TKPMOIA96xC38MLfOLI ggcCburZsocvQR2GQ5QCWgVdF6Qum8D5Pds+c= MIME-Version: 1.0 Received: by 10.182.75.65 with SMTP id a1mr9657308obw.32.1327361744207; Mon, 23 Jan 2012 15:35:44 -0800 (PST) Sender: zack.weinberg@gmail.com Received: by 10.182.227.69 with HTTP; Mon, 23 Jan 2012 15:35:44 -0800 (PST) In-Reply-To: <7769AE22-B0EF-48F2-86E8-AD6977F83124@vpnc.org> References: <20120123033124.GD14597@odin.ulthar.us> <201201231921.q0NJLS1i021543@fs4113.wdf.sap.corp> <7769AE22-B0EF-48F2-86E8-AD6977F83124@vpnc.org> Date: Mon, 23 Jan 2012 15:35:44 -0800 X-Google-Sender-Auth: jU2PxucV-l5owqOmhVMxHJL6U08 Message-ID: From: Zack Weinberg To: IETF DANE WG list Content-Type: text/plain; charset=UTF-8 Subject: Re: [dane] Opening Issue #37. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 23:35:45 -0000 On Mon, Jan 23, 2012 at 2:54 PM, Paul Hoffman wrote: > >> thus allowing DANE-compliant clients to continue with their present >> state of (non)conformance to PKIX. > > -1. This proposed wording is just as silly as people saying that PKIX > validation is well-defined and well-understood. Saying "we don't know > what conformant means" is a terrible way to write a standard. Well, I don't much care exactly how it's worded, but I think it is *critical* that we manage to "allow DANE-compliant clients to continue with their present state of (non)conformance to PKIX". It seems to me that the easiest way to do that is to define DANE clients' behavior in the presence of TLSA records as adjustments to their behavior in the absence of TLSA records, taking no position on what the "behavior in the absence of TLSA records" should be. Hence the suggested wording. Do you have a better idea? zw From paul.hoffman@vpnc.org Mon Jan 23 15:41:32 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8604721F86BA for ; Mon, 23 Jan 2012 15:41:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppNZ3a+VoCDZ for ; Mon, 23 Jan 2012 15:41:32 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1754621F86B6 for ; Mon, 23 Jan 2012 15:41:32 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q0NNfUTD079786 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 Jan 2012 16:41:31 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4F1DA1B1.6030404@nic.cz> Date: Mon, 23 Jan 2012 15:41:30 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <4EEE63EB.9020800@nic.cz> <00ca01ccc5b6$57d79e10$0786da30$@augustcellars.com> <4F1DA1B1.6030404@nic.cz> To: Ondrej Mikle X-Mailer: Apple Mail (2.1251.1) Cc: IETF DANE WG list Subject: Re: [dane] New "operational considerations" text (was: Addition to "Security considerations") X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 23:41:32 -0000 I have edited the earlier text to use this new batch. It will appear in -15. --Paul Hoffman From paul.hoffman@vpnc.org Mon Jan 23 15:42:43 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D631921F8681 for ; Mon, 23 Jan 2012 15:42:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFVNI-J3jThy for ; Mon, 23 Jan 2012 15:42:43 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3359A21F85A4 for ; Mon, 23 Jan 2012 15:42:43 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q0NNgfKF079809 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 Jan 2012 16:42:42 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Mon, 23 Jan 2012 15:42:41 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3F134138-06A0-400A-9CA6-5FF55B331D04@vpnc.org> References: <20120123033124.GD14597@odin.ulthar.us> <201201231921.q0NJLS1i021543@fs4113.wdf.sap.corp> <7769AE22-B0EF-48F2-86E8-AD6977F83124@vpnc.org> To: Zack Weinberg X-Mailer: Apple Mail (2.1251.1) Cc: IETF DANE WG list Subject: Re: [dane] Opening Issue #37. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 23:42:44 -0000 On Jan 23, 2012, at 3:35 PM, Zack Weinberg wrote: > On Mon, Jan 23, 2012 at 2:54 PM, Paul Hoffman = wrote: >>=20 >>> thus allowing DANE-compliant clients to continue with their present >>> state of (non)conformance to PKIX. >>=20 >> -1. This proposed wording is just as silly as people saying that PKIX >> validation is well-defined and well-understood. Saying "we don't know >> what conformant means" is a terrible way to write a standard. >=20 > Well, I don't much care exactly how it's worded, but I think it is > *critical* that we manage to "allow DANE-compliant clients to continue > with their present state of (non)conformance to PKIX". It seems to me > that the easiest way to do that is to define DANE clients' behavior in > the presence of TLSA records as adjustments to their behavior in the > absence of TLSA records, taking no position on what the "behavior in > the absence of TLSA records" should be. Hence the suggested wording. > Do you have a better idea? Yes: leave the current text as-is. If someone is not going to conform to = PKIX today, we are not telling them to do it any differently with DANE. --Paul Hoffman From ondrej.mikle@nic.cz Mon Jan 23 16:53:07 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 651DA21F8525 for ; Mon, 23 Jan 2012 16:53:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTu3dAmg53Km for ; Mon, 23 Jan 2012 16:53:06 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 5CDF921F8522 for ; Mon, 23 Jan 2012 16:53:06 -0800 (PST) Received: from localhost.localdomain (ip-84-42-137-177.net.upcbroadband.cz [84.42.137.177]) by mail.nic.cz (Postfix) with ESMTPSA id 976AD2A2D55; Tue, 24 Jan 2012 01:53:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1327366385; bh=9A6xEIo91SUmG4qVqPjgTH47kaUzNpHetLn/yShiFtM=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=T17z/x78GyPYMxfPKcw5I4YzZv+MvZhJFQ++uiZ0m/cyZYxH/iwviw+qKzl91eljH 8gkBKMop17o6K1zB3iA0D5iYSVxnERZ+0OSrkPR95PB7Q9nNsFMm/lOjfOha/NZqgI lqSpsa1mb72H4mmQzJzigjdr5giOmO6hA2XANnuE= Message-ID: <4F1E00F1.9030008@nic.cz> Date: Tue, 24 Jan 2012 01:53:05 +0100 From: Ondrej Mikle User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Paul Hoffman References: <59E1FDB4-B832-415A-BEE3-8E85CC55E337@vpnc.org> <20120122012034.GA24296@odin.ulthar.us> <20120122183325.GA6635@odin.ulthar.us> <8BD41639-E2A2-4348-9796-B2BFF193B088@vpnc.org> <4F1DA879.3010504@nic.cz> <077BF214-D6FA-4079-A0E2-CFD3D39A80BD@vpnc.org> In-Reply-To: <077BF214-D6FA-4079-A0E2-CFD3D39A80BD@vpnc.org> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane@ietf.org Subject: Re: [dane] Pseudocode review X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 00:53:07 -0000 On 01/24/2012 12:04 AM, Paul Hoffman wrote: > On Jan 23, 2012, at 10:35 AM, Ondrej Mikle wrote: > >> On 01/23/2012 06:54 PM, Paul Hoffman wrote: >>> Sorry, I'm still missing it, and I think that the problem is on my end. >>> >>> On Jan 22, 2012, at 10:33 AM, Scott Schmit wrote: >>> >>>> In A.1.1, the text implies that the client will stop after finding the >>>> first chain that works, so the operator should chose their anchor with >>>> care, because the association could fail for some clients or under some >>>> conditions (e.g., the client has or hasn't visited a site with an >>>> alternate certificate recently). >>> >>> >>> Yes, that is correct. >>> >>> If you propose alternate wording for the pseudocode comment above, I suspect I'll say "that's what we meant" and use it directly. >> >> >> I removed the "first match" behavior from the update to A.1 I posted a >> while ago. Though in real deployment it will take time until >> implementations support building and checking all paths (e.g. RFC 4158). >> >> What about adding the following sentence at the end of the "// A TLS >> client might have multiple trust anchors that it might..." pseudocode >> commend: >> >> "Note that there will be transitional period where clients may not check >> all chains and instead pick one arbitrary chain." > > > I'm still confused. Why should an implementation check all chains? The first good chain is good enough, yes? I'm not sure where the confusion happens, so I'll write it out explicitly in a "python-ic" pseudocode. Wanted: first chain where the expression "TLSA association succeeds && PKIX validation succeeds" evaluates to true (according to DANE rules). Current implementations of PKIX validation (except CryptoAPI) have only a method like: findFirstValidChain(chainFromHandshake, trustAnchors, cachedCerts) returning CertChain In a naive implementation, a developer might be tempted to do: tlsaRecord = fetchTlsa(fqdn, port, protocol) certChain = findFirstValidChain(chainFromHandshake, trustAnchors, cachedCerts) valid = checkTlsa(certChain, tlsaRecord) Such "first match" implementation will ocassionally fail as false-negative. The "checkTlsa" method does first TLSA check, then PKIX validation on a chain (including CLR/OCSP) according to DANE rules. An implementation that should be correct according to DANE rules might look like (taking into account blocking operations like OCSP/CRL/AIA fetching): tlsaRecord = fetchTlsa(fqdn, port, protocol) # build initial certchains queue to check from "offline" data queue = [chainFromHandshake] + buildValidChains(chainFromHandshake, trustAnchors, cachedCerts) while (not queue.empty): chain = queue.popFront() if checkTlsa(chain, tlsaRecord): return True #add chains we didn't see before via RFC 4158 methods like AIA fetch queue += buildRfc4158Chains(chain, trustAnchors, cachedCerts) return False #no certchain matched Methods "buildValidChains" and "findFirstValidChain" differ only in the fact that the first one returns all chains, not just the first one (cycle detection is skipped for clarity). Ondrej Mikle From zack.weinberg@gmail.com Mon Jan 23 17:24:03 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC1921F8618 for ; Mon, 23 Jan 2012 17:24:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZR5+rirvt4er for ; Mon, 23 Jan 2012 17:24:03 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2027321F8615 for ; Mon, 23 Jan 2012 17:24:03 -0800 (PST) Received: by obbwc12 with SMTP id wc12so4507196obb.31 for ; Mon, 23 Jan 2012 17:24:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=JRMWB2owAjIM1R+tnblYaLlvP4jWYi7WNgQyrb4YlQc=; b=NSaZ60vyx85GuOFFMctIe/lZFIvSO+zYjcpOs0fD0aysJQ5FUZEzZsRFFW0GWRzgoK ww2quoULgK69MgeXnq2n8qnymCuV7IEpvJbFzgxlgJwtuqYog4DsxUpB8ZJ/b3z4G99V NmQ3WZBUeM24JmZ8k3pEIOMpXiGiTbcVtthhg= MIME-Version: 1.0 Received: by 10.182.76.135 with SMTP id k7mr9858227obw.62.1327368242749; Mon, 23 Jan 2012 17:24:02 -0800 (PST) Sender: zack.weinberg@gmail.com Received: by 10.182.227.69 with HTTP; Mon, 23 Jan 2012 17:24:02 -0800 (PST) In-Reply-To: References: <20120123033124.GD14597@odin.ulthar.us> <201201231921.q0NJLS1i021543@fs4113.wdf.sap.corp> <7769AE22-B0EF-48F2-86E8-AD6977F83124@vpnc.org> <3F134138-06A0-400A-9CA6-5FF55B331D04@vpnc.org> Date: Mon, 23 Jan 2012 17:24:02 -0800 X-Google-Sender-Auth: e4_aQw3acZyn_d-3YMY0eJo2i5A Message-ID: From: Zack Weinberg To: IETF DANE WG list Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [dane] Opening Issue #37. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 01:24:03 -0000 (accidentally hit reply-to-sender rather than reply-to-list, sorry about th= at) On Mon, Jan 23, 2012 at 3:42 PM, Paul Hoffman wrote= : > On Jan 23, 2012, at 3:35 PM, Zack Weinberg wrote: >> >> Well, I don't much care exactly how it's worded, but I think it is >> *critical* that we manage to "allow DANE-compliant clients to continue >> with their present state of (non)conformance to PKIX". > > Yes: leave the current text as-is. If someone is not going to conform > to PKIX today, we are not telling them to do it any differently with DANE= . I disagree. =C2=A0The current text is saying you have to conform to RFC 5280 if you want to implement DANE. =C2=A0That will be taken as an argument against implementing DANE by people who think RFC 5280 validation is too expensive and/or complicated. zw From paul.hoffman@vpnc.org Mon Jan 23 17:25:45 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1AE21F8618 for ; Mon, 23 Jan 2012 17:25:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8pdNdIhxyMlU for ; Mon, 23 Jan 2012 17:25:44 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id AB17821F8615 for ; Mon, 23 Jan 2012 17:25:44 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q0O1Phta081999 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 Jan 2012 18:25:44 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Mon, 23 Jan 2012 17:25:43 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <38753795-7C00-4DD5-99A0-3CF4ED2B407B@vpnc.org> References: <20120123033124.GD14597@odin.ulthar.us> <201201231921.q0NJLS1i021543@fs4113.wdf.sap.corp> <7769AE22-B0EF-48F2-86E8-AD6977F83124@vpnc.org> <3F134138-06A0-400A-9CA6-5FF55B331D04@vpnc.org> To: Zack Weinberg X-Mailer: Apple Mail (2.1251.1) Cc: IETF DANE WG list Subject: Re: [dane] Opening Issue #37. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 01:25:45 -0000 On Jan 23, 2012, at 5:24 PM, Zack Weinberg wrote: > (accidentally hit reply-to-sender rather than reply-to-list, sorry = about that) >=20 > On Mon, Jan 23, 2012 at 3:42 PM, Paul Hoffman = wrote: >> On Jan 23, 2012, at 3:35 PM, Zack Weinberg wrote: >>>=20 >>> Well, I don't much care exactly how it's worded, but I think it is >>> *critical* that we manage to "allow DANE-compliant clients to = continue >>> with their present state of (non)conformance to PKIX". >>=20 >> Yes: leave the current text as-is. If someone is not going to conform >> to PKIX today, we are not telling them to do it any differently with = DANE. >=20 > I disagree. The current text is saying you have to conform to RFC > 5280 if you want to implement DANE. =20 Yep, just like RFC 2818 says you have to implement PKIX if you want to = implement TLS. > That will be taken as an argument > against implementing DANE by people who think RFC 5280 validation is > too expensive and/or complicated. Errr, how are they doing TLS now without PKIX validation? --Paul Hoffman From mrex@sap.com Mon Jan 23 17:49:55 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 038CB21F853A for ; Mon, 23 Jan 2012 17:49:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.108 X-Spam-Level: X-Spam-Status: No, score=-10.108 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTx1Qg4sCoNk for ; Mon, 23 Jan 2012 17:49:54 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 3B19C21F8531 for ; Mon, 23 Jan 2012 17:49:52 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q0O1npIU022300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 Jan 2012 02:49:51 +0100 (MET) From: Martin Rex Message-Id: <201201240149.q0O1non1013583@fs4113.wdf.sap.corp> To: ondrej.mikle@nic.cz (Ondrej Mikle) Date: Tue, 24 Jan 2012 02:49:50 +0100 (MET) In-Reply-To: <4F1DE8C5.5090700@nic.cz> from "Ondrej Mikle" at Jan 24, 12 00:09:57 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] Opening Issue #37. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 01:49:55 -0000 Ondrej Mikle wrote: > > On 01/23/2012 09:39 PM, Zack Weinberg wrote: > > This seems like a decent point to bring up (again) the fact that as > > far as I am aware, "libpkix" is the only open-source *library* out > > there that claims to implement RFC 4158 and 5280 in detail, and no > > *client* I know of uses it unconditionally. > > [snip] > > > I think it is not DANE's job to fix this mess, and we should drop the > > phrase "PKIX validation" entirely from the spec, replacing it with > > something like > > > > # DANE clients SHOULD perform the same validation steps on the > > # certificate chain that they would have in the absence of TLSA > > # records, except that they MUST defer deciding whether the chain > > # terminates in an acceptable root until TLSA information has been > > # taken into account. > > > > thus allowing DANE-compliant clients to continue with their present > > state of (non)conformance to PKIX. > > I agree with your description of the issue, but I don't think the proposed > replacement of "PKIX validation" will solve it. The real issue is in > "non-deterministic" way how clients build trust paths presently (and with > caching of intermediate certs, it's non-trivial to reproduce). > While before DANE a client built some chain that validated, with TLSA > constraints it won't be enough. > > RFC 4158 section 6 just adds more non-determinism, especially AIA retrieval. rfc4158 is informative, and I am not aware of any reference from PKIX (rfc5280) to rfc4158. Btw. it would be folly to perform AIA retrievel (aka forward chaining) during certificate path validation, because it would mean to perform downloads from arbitrary untrusted URLs supplied by an attacker. I'm aware that Web Browsers do lots of folly things all the time, but a PKIX implementation should not try to reproduce each and every security vulnerability of a browser that displays a plain-http resource. -Martin From mrex@sap.com Mon Jan 23 17:59:27 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59D5921F85E7 for ; Mon, 23 Jan 2012 17:59:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.112 X-Spam-Level: X-Spam-Status: No, score=-10.112 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzkpZ4VVRkHg for ; Mon, 23 Jan 2012 17:59:27 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id A392021F85E6 for ; Mon, 23 Jan 2012 17:59:26 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q0O1xKcf018784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 Jan 2012 02:59:25 +0100 (MET) From: Martin Rex Message-Id: <201201240159.q0O1xJL8014216@fs4113.wdf.sap.corp> To: paul.hoffman@vpnc.org (Paul Hoffman) Date: Tue, 24 Jan 2012 02:59:19 +0100 (MET) In-Reply-To: <734367B8-48F9-4D8F-A106-DC744754FB84@vpnc.org> from "Paul Hoffman" at Jan 23, 12 02:50:27 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] Opening Issue #37. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 01:59:27 -0000 Paul Hoffman wrote: > > On Jan 23, 2012, at 11:21 AM, Martin Rex wrote: > > > Scott Schmit wrote: > >> > >> The draft states: > >> # 2 -- The target certificate MUST pass PKIX validation, with any > >> # certificate matching the TLSA record considered to be a trust > >> # anchor for this validation > > > > That statement in the draft seems to be somewhat incorrect and misleading. > > > > If the TLSA usage type 2 refers to a NON-self-signed End-Entity cert > > (or its hash or its SPKI), then it will be technically impossible to > > perform PKIX path validation. > > I fully disagree with this statement. Trust anchors in PKIX (RFC 5280) are keys, not certificates. If you believe otherwise, please quote from RFC 5280. > > > So the PKIX path validation for usage type 2 needs to be conditionalized > > to those situations where there exists a PKIX path. > > > A path between a certificate and itself is still a path. Nope, that applies only to *self-signed* certs. Allowing TLSA usage type 2 EE-cert matches to *self-signed* EE-certs (that are not even covered by existing ITU-T X.509 and PKIX specs), but disallowing well-defined non-self-signed EE-certs to be matched by TLSA usage type 2 records seems strange to me. -Martin From warren@kumari.net Mon Jan 23 18:16:15 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CCDC21F861F for ; Mon, 23 Jan 2012 18:16:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.505 X-Spam-Level: X-Spam-Status: No, score=-106.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m+sqC7hbNj4G for ; Mon, 23 Jan 2012 18:16:15 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 0B7F421F8616 for ; Mon, 23 Jan 2012 18:16:14 -0800 (PST) Received: from [192.168.0.12] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id D5B3A1B402A0; Mon, 23 Jan 2012 21:16:13 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: <201201240159.q0O1xJL8014216@fs4113.wdf.sap.corp> Date: Mon, 23 Jan 2012 21:16:09 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <993CD7E3-670B-448F-AA2D-377DBBEA56D6@kumari.net> References: <201201240159.q0O1xJL8014216@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1084) Cc: Paul Hoffman , dane@ietf.org Subject: Re: [dane] Opening Issue #37. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 02:16:15 -0000 [ Administrative note, not aimed at anyone... ]=20 We are going to delay calling consensus on this for a few more days as = we have some (potentially) interesting / productive discussions. Please let's all try keep this civil though - we are so close to = finishing, and it would be nice to end on a positive note=85 W On Jan 23, 2012, at 8:59 PM, Martin Rex wrote: > Paul Hoffman wrote: >>=20 >> On Jan 23, 2012, at 11:21 AM, Martin Rex wrote: >>=20 >>> Scott Schmit wrote: >>>>=20 >>>> The draft states: >>>> # 2 -- The target certificate MUST pass PKIX validation, with = any >>>> # certificate matching the TLSA record considered to be a trust >>>> # anchor for this validation >>>=20 >>> That statement in the draft seems to be somewhat incorrect and = misleading. >>>=20 >>> If the TLSA usage type 2 refers to a NON-self-signed End-Entity cert >>> (or its hash or its SPKI), then it will be technically impossible to >>> perform PKIX path validation. >>=20 >> I fully disagree with this statement. Trust anchors in PKIX (RFC = 5280) are keys, not certificates. If you believe otherwise, please quote = from RFC 5280. >>=20 >>> So the PKIX path validation for usage type 2 needs to be = conditionalized >>> to those situations where there exists a PKIX path. >>=20 >>=20 >> A path between a certificate and itself is still a path. >=20 > Nope, that applies only to *self-signed* certs. >=20 > Allowing TLSA usage type 2 EE-cert matches to *self-signed* EE-certs > (that are not even covered by existing ITU-T X.509 and PKIX specs), > but disallowing well-defined non-self-signed EE-certs to be matched > by TLSA usage type 2 records seems strange to me. >=20 > -Martin > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 -- Don't be impressed with unintelligible stuff said condescendingly. -- Radia Perlman. From paul.hoffman@vpnc.org Mon Jan 23 18:36:46 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EABD21F85E5 for ; Mon, 23 Jan 2012 18:36:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGT1dWfFsoUZ for ; Mon, 23 Jan 2012 18:36:45 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id BA11121F85E1 for ; Mon, 23 Jan 2012 18:36:45 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q0O2aipm083382 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 Jan 2012 19:36:44 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Paul Hoffman In-Reply-To: <201201240159.q0O1xJL8014216@fs4113.wdf.sap.corp> Date: Mon, 23 Jan 2012 18:36:44 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <378456A1-5D12-4F64-809F-D3AE4EDBA36B@vpnc.org> References: <201201240159.q0O1xJL8014216@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1251.1) Cc: dane@ietf.org Subject: Re: [dane] Opening Issue #37. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 02:36:46 -0000 On Jan 23, 2012, at 5:59 PM, Martin Rex wrote: > Paul Hoffman wrote: >>=20 >> On Jan 23, 2012, at 11:21 AM, Martin Rex wrote: >>=20 >>> Scott Schmit wrote: >>>>=20 >>>> The draft states: >>>> # 2 -- The target certificate MUST pass PKIX validation, with = any >>>> # certificate matching the TLSA record considered to be a trust >>>> # anchor for this validation >>>=20 >>> That statement in the draft seems to be somewhat incorrect and = misleading. >>>=20 >>> If the TLSA usage type 2 refers to a NON-self-signed End-Entity cert >>> (or its hash or its SPKI), then it will be technically impossible to >>> perform PKIX path validation. >>=20 >> I fully disagree with this statement. Trust anchors in PKIX (RFC = 5280) are keys, not certificates. If you believe otherwise, please quote = from RFC 5280. >>=20 >>> So the PKIX path validation for usage type 2 needs to be = conditionalized >>> to those situations where there exists a PKIX path. >>=20 >>=20 >> A path between a certificate and itself is still a path. >=20 > Nope, that applies only to *self-signed* certs. Really? Where in the PKIX spec does it say that? You can repeat your assertion as often as you like; it's still wrong = unless you support it with facts. > Allowing TLSA usage type 2 EE-cert matches to *self-signed* EE-certs > (that are not even covered by existing ITU-T X.509 and PKIX specs), Really? Where in the PKIX spec does it say that? > but disallowing well-defined non-self-signed EE-certs to be matched > by TLSA usage type 2 records seems strange to me. When did anyone say that some types of EE certs are disallowed by type = 2?!?! --Paul Hoffman From mrex@sap.com Mon Jan 23 19:39:30 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB6321F85C9 for ; Mon, 23 Jan 2012 19:39:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.115 X-Spam-Level: X-Spam-Status: No, score=-10.115 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lUTGhO0gHsak for ; Mon, 23 Jan 2012 19:39:30 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 9637821F85AA for ; Mon, 23 Jan 2012 19:39:29 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q0O3dRQR005168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 Jan 2012 04:39:27 +0100 (MET) From: Martin Rex Message-Id: <201201240339.q0O3dQ69019834@fs4113.wdf.sap.corp> To: paul.hoffman@vpnc.org (Paul Hoffman) Date: Tue, 24 Jan 2012 04:39:26 +0100 (MET) In-Reply-To: <378456A1-5D12-4F64-809F-D3AE4EDBA36B@vpnc.org> from "Paul Hoffman" at Jan 23, 12 06:36:44 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] Opening Issue #37. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 03:39:30 -0000 Paul Hoffman wrote: > > When did anyone say that some types of EE certs are disallowed by type 2?!?! the statement # 2 -- The target certificate MUST pass PKIX validation clearly implies this. When talking about PKIX validation, that is a reference to performing certification path validation (and optionally revocation checking) along the lines of rfc5280 section 6.1 and ITU-T X.509 08/2005 Section 10. If you believe that I have missed a part of rfc5280 or ITU-T X.509 08/2005 where it describes how to perform certificate path validation with the same non-self-signed certificate being both path certificate and trust anchor, I'll be glad about a reference to this description. > Martin Rex wrote: > > > > Paul Hoffman wrote: > >> > >> A path between a certificate and itself is still a path. > > > > Nope, that applies only to *self-signed* certs. > > Really? Where in the PKIX spec does it say that? That is a common implementated behaviour that rfc5280 for the certificate path validation. rfc5280 section 6.1 contains this description: rfc5280, section 6.1: When the trust anchor is provided in the form of a self-signed certificate, this self-signed certificate is not included as part of the prospective certification path. that is often implemented as "this self-signed certificate is typically not included as part of the prospective certification path, unless it is also used as the TLS server certificate." -- which is perfectly OK with rfc5280, as it does not use use imperatives (SHOULD NOT /MUST NOT). > > You can repeat your assertion as often as you like; > it's still wrong unless you support it with facts. > > > Allowing TLSA usage type 2 EE-cert matches to *self-signed* EE-certs > > (that are not even covered by existing ITU-T X.509 and PKIX specs), > > Really? Where in the PKIX spec does it say that? And ITU-T X.509 08/2005 says this: 3.3.56 self-signed certificate: [...] NOTE Use of self-issued certificates and self-signed certificates issued by other than CAs are outside the scope of this Recommendation | International Standard. rfc5280 declares itself a profile of ITU-T X.509 08/2005 Abstract This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this and does not currently cover self-signed non-CA either, that have been exempted by ITU-T X.509. So with respect to non-CA self-signed certs being used with TLS in the installed base, there exists only implementation-defined behaviour. -Martin From paul.hoffman@vpnc.org Mon Jan 23 20:00:22 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 382A121F8604 for ; Mon, 23 Jan 2012 20:00:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8IMll+SWyWK8 for ; Mon, 23 Jan 2012 20:00:21 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8BCAE21F85FD for ; Mon, 23 Jan 2012 20:00:21 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q0O40JgI085000 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 Jan 2012 21:00:20 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Paul Hoffman In-Reply-To: <201201240339.q0O3dQ69019834@fs4113.wdf.sap.corp> Date: Mon, 23 Jan 2012 20:00:19 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2B03A335-83DE-425A-9A2E-1BE849FEFBCB@vpnc.org> References: <201201240339.q0O3dQ69019834@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1251.1) Cc: dane@ietf.org Subject: Re: [dane] Opening Issue #37. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 04:00:22 -0000 On Jan 23, 2012, at 7:39 PM, Martin Rex wrote: > Paul Hoffman wrote: >>=20 >> When did anyone say that some types of EE certs are disallowed by = type 2?!?! >=20 > the statement >=20 > # 2 -- The target certificate MUST pass PKIX validation >=20 > clearly implies this. =20 Sorry, but I don't see any such implication, certainly not clearly. > When talking about PKIX validation, that is a reference to performing > certification path validation (and optionally revocation checking) > along the lines of rfc5280 section 6.1 and ITU-T X.509 08/2005 Section = 10. No, just to Section 6.1 of RFC 5280. As you have been told (repeatedly) = on the PKIX WG mailing list, X.509 is not PKIX. If you insist that it = is, you are in a different reality than the one shared in the IETF, so = discussion is fruitless. > If you believe that I have missed a part of rfc5280 or ITU-T X.509 = 08/2005 > where it describes how to perform certificate path validation with > the same non-self-signed certificate being both path certificate and = trust > anchor, I'll be glad about a reference to this description. See below. >> Martin Rex wrote: >>>=20 >>> Paul Hoffman wrote: >>>>=20 >>>> A path between a certificate and itself is still a path. >>>=20 >>> Nope, that applies only to *self-signed* certs. >>=20 >> Really? Where in the PKIX spec does it say that? >=20 > That is a common implementated behaviour that rfc5280 for the = certificate > path validation. =20 As we are well aware of here, "common" does not mean "correct". > rfc5280 section 6.1 contains this description: >=20 > rfc5280, section 6.1: >=20 > When the trust anchor is provided in the form of a self-signed > certificate, this self-signed certificate is not included as part of > the prospective certification path. >=20 > that is often implemented as "this self-signed certificate is = typically > not included as part of the prospective certification path, unless it = is > also used as the TLS server certificate." -- which is perfectly OK > with rfc5280, as it does not use use imperatives (SHOULD NOT /MUST = NOT). Read that quoted text again: the self-signed cert is not included *as = part of the prospective certification path*. It is the terminus. The = fact that it is "often implemented" wrong does not mean that your = repeated assertions are right, just that you are asserting what bad = implementations do. >> You can repeat your assertion as often as you like; >> it's still wrong unless you support it with facts. >>=20 >>> Allowing TLSA usage type 2 EE-cert matches to *self-signed* EE-certs >>> (that are not even covered by existing ITU-T X.509 and PKIX specs), >>=20 >> Really? Where in the PKIX spec does it say that? >=20 >=20 > And ITU-T X.509 08/2005 says this: >=20 > 3.3.56 self-signed certificate: [...] >=20 > NOTE Use of self-issued certificates and self-signed = certificates > issued by other than CAs are outside the scope of this > Recommendation | International Standard. Again: that's not PKIX. > rfc5280 declares itself a profile of ITU-T X.509 08/2005 >=20 > Abstract >=20 > This memo profiles the X.509 v3 certificate and X.509 v2 certificate > revocation list (CRL) for use in the Internet. An overview of this >=20 > and does not currently cover self-signed non-CA either, that have > been exempted by ITU-T X.509. They are not "exempted", they are outside the scope. Note the huge = difference there. PKIX *profiles* X.509 by changing it, yes? > So with respect to non-CA self-signed certs being used with TLS in > the installed base, there exists only implementation-defined = behaviour. There are plenty of implementations that get this right, and plenty that = get it wrong. You are choosing the latter to support your assertions. --Paul Hoffman From mrex@sap.com Mon Jan 23 21:15:18 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACE9921F8557 for ; Mon, 23 Jan 2012 21:15:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.119 X-Spam-Level: X-Spam-Status: No, score=-10.119 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fzDPLq6Uq+f1 for ; Mon, 23 Jan 2012 21:15:17 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 62EFB21F8552 for ; Mon, 23 Jan 2012 21:15:17 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q0O5FFcP004743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 Jan 2012 06:15:15 +0100 (MET) From: Martin Rex Message-Id: <201201240515.q0O5FEM5025321@fs4113.wdf.sap.corp> To: paul.hoffman@vpnc.org (Paul Hoffman) Date: Tue, 24 Jan 2012 06:15:14 +0100 (MET) In-Reply-To: <2B03A335-83DE-425A-9A2E-1BE849FEFBCB@vpnc.org> from "Paul Hoffman" at Jan 23, 12 08:00:19 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] Opening Issue #37. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 05:15:18 -0000 Paul Hoffman wrote: > > Martin Rex wrote: > > > > Really? Where in the PKIX spec does it say that? > > > > That is a common implementated behaviour that rfc5280 for the certificate > > path validation. > > > > rfc5280, section 6.1: > > > > When the trust anchor is provided in the form of a self-signed > > certificate, this self-signed certificate is not included as part of > > the prospective certification path. > > As we are well aware of here, "common" does not mean "correct". OK, let's say I use rfc5280, section 6.1 and supply as self-signed cert as prospective certification path and supply as trust anchor only the tbsCertificate of the self-signed cert so that sentence no longer applies. > > Read that quoted text again: the self-signed cert is not included > *as part of the prospective certification path*. It is the terminus. > The fact that it is "often implemented" wrong does not mean that your > repeated assertions are right, just that you are asserting what bad > implementations do. Now I am throughly confused about what you would like implementations of dane-protocol to do exactly where it currently says that for TLSA usage type 2 "MUST pass PKIX validation", in case that the TLSA usage type 2 record identifies the server's certificate. * which algorithm you are refering to by this term "pass PKIX validation" if it is _not_ rfc5280 section 6.1 plus optionally section 6.3 * in case the algorithm should be rfc5280 section 6.1, please specify the contents of the two required input parameters to that algorithm: (1) prospective certification path (2) trust anchor > > When talking about PKIX validation, that is a reference to performing > > certification path validation (and optionally revocation checking) > > along the lines of rfc5280 section 6.1 and ITU-T X.509 08/2005 Section 10. > > No, just to Section 6.1 of RFC 5280. As you have been told (repeatedly) > on the PKIX WG mailing list, X.509 is not PKIX. If you insist that it is, > you are in a different reality than the one shared in the IETF, > so discussion is fruitless. I would strongly recommend that you look at PKIX/rfc5280 section 6.1 and how it describes it's own relation to X.509: https://tools.ietf.org/html/rfc5280#section-6.1 6.1. Basic Path Validation This text describes an algorithm for X.509 path processing. A conforming implementation MUST include an X.509 path processing procedure that is functionally equivalent to the external behavior of this algorithm. [...] While the certificate and CRL profiles specified in Sections 4 and 5 of this document specify values for certificate and CRL fields and extensions that are considered to be appropriate for the Internet PKI, the algorithm presented in this section is not limited to accepting certificates and CRLs that conform to these profiles. !! Therefore, the algorithm only includes checks to verify that the !! certification path is valid according to X.509 and does not include !! checks to verify that the certificates and CRLs conform to this !! profile. While the algorithm could be extended to include checks for !! conformance to the profiles in Sections 4 and 5, this profile !! RECOMMENDS against including such checks. My copy of PKIX/rfc5280 recommends X.509 certificate path validation over checks suggested in sections 4 and 5. -Martin From matt@mattmccutchen.net Mon Jan 23 22:35:35 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CCB821F8575 for ; Mon, 23 Jan 2012 22:35:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5cTBxSMwvfm for ; Mon, 23 Jan 2012 22:35:34 -0800 (PST) Received: from homiemail-a6.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id C9E2921F8572 for ; Mon, 23 Jan 2012 22:35:34 -0800 (PST) Received: from homiemail-a6.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTP id 49FAF59807A; Mon, 23 Jan 2012 22:35:34 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=message-id :subject:from:to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:mime-version; q=dns; s= mattmccutchen.net; b=HIQ5Hu8HLz08DPosX+qRMIh6DTCABm2utz68L9EGhmC 9WcJXJnlHSqWivx5FLz8MZWElmA3VaYg3bbB4sg+R/7xw4uiCcakpKWtUI91bsHR 8GZ98i9EIjzCPi8zD8ifZL9+7LD4dn731ltuWOCJ4IE2KRnwKe615Yqz1zme6Iy8 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= message-id:subject:from:to:cc:date:in-reply-to:references :content-type:content-transfer-encoding:mime-version; s= mattmccutchen.net; bh=DeCdrRuM8+NKGiNFimOR8n0WZg8=; b=sRyF3h+QMb H1mGzpYifdyk+AaTLr1gOD149wWly1sKfybySpHdjcWYmGlzmjYqY7D/mC716/mS uF0wCT0g/Hbfo94rbvFliUTn0YHN3+xwKlHdmUsI7HwXnAsVfmOqghHkItteza6n 3+NVQirJwEGWRLMmuVsYtH4Af4FZVAIYQ= Received: from [IPv6:::1] (c-98-248-34-40.hsd1.ca.comcast.net [98.248.34.40]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTPSA id 10F12598070; Mon, 23 Jan 2012 22:35:34 -0800 (PST) Message-ID: <1327386932.3558.49.camel@localhost> From: Matt McCutchen To: "Richard L. Barnes" Date: Mon, 23 Jan 2012 22:35:32 -0800 In-Reply-To: <9FAA7940-7753-414E-B201-A0A8232D21EB@bbn.com> References: <1327282284.3558.10.camel@localhost> <20120123033124.GD14597@odin.ulthar.us> <1327307907.3558.25.camel@localhost> <9FAA7940-7753-414E-B201-A0A8232D21EB@bbn.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Cc: Paul Wouters , dane@ietf.org Subject: Re: [dane] Opening Issue #37. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 06:35:35 -0000 On Mon, 2012-01-23 at 09:44 -0500, Richard L. Barnes wrote: > > Nothing, except the document already being written, justifies the > > current state of affairs with usages 0 and 1 separate but usage 2 > > serving a dual purpose. > > Well, there is a use cases document that achieved consensus in this working group: > > The certificate usage types map exactly to the three major use cases in the document. So what? Why is it desirable that different "use cases" be supported via different certificate usage values? The argument that a single usage can support both Sections 3.1 and 3.2 of RFC 6394 is exactly the same one you are making that usage 2 supports positive-and-restrictive assertions of both CA certificates and server certificates. On the other side, Paul Wouters claimed (https://www.ietf.org/mail-archive/web/dane/current/msg03520.html) that the use cases document declined to address positive-and-restrictive assertion of a server certificate with the understanding that that level of detail would be considered in the protocol document. If that is true, it rather belies your point. (Paul, if you could provide the actual reference, I would be very grateful.) -- Matt From ietf@augustcellars.com Mon Jan 23 22:35:44 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7E6321F8600 for ; Mon, 23 Jan 2012 22:35:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.37 X-Spam-Level: X-Spam-Status: No, score=-3.37 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PSoTd5zGV8VC for ; Mon, 23 Jan 2012 22:35:43 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id B345321F85F8 for ; Mon, 23 Jan 2012 22:35:43 -0800 (PST) Received: from Tobias (exodus.augustcellars.com [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 7109338F2B; Mon, 23 Jan 2012 22:35:42 -0800 (PST) From: "Jim Schaad" To: "'Ondrej Mikle'" References: <4EEE63EB.9020800@nic.cz> <00ca01ccc5b6$57d79e10$0786da30$@augustcellars.com> <4F1DA1B1.6030404@nic.cz> In-Reply-To: <4F1DA1B1.6030404@nic.cz> Date: Mon, 23 Jan 2012 22:35:01 -0800 Message-ID: <030801ccda62$4ebde620$ec39b260$@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: AQEN/+1oJB+kzN84Sepf7JgEBX1cmwIa1F2FAmQJ8R+XdHYoAA== Content-Language: en-us Cc: dane@ietf.org Subject: Re: [dane] New "operational considerations" text (was: Addition to "Security considerations") X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 06:35:44 -0000 > -----Original Message----- > From: Ondrej Mikle [mailto:ondrej.mikle@nic.cz] > Sent: Monday, January 23, 2012 10:07 AM > To: Jim Schaad > Cc: dane@ietf.org > Subject: Re: [dane] New "operational considerations" text (was: Addition to > "Security considerations") > > On 12/29/2011 12:13 AM, Jim Schaad wrote: > > From my point of view this text is far improved. > > > > Of course I still have some suggestions > > Updated version of current A.1 section is below (it's shortened output from > xml2rfc, I'll post link to git source tomorrow). Typos and errors mentioned in > other threads should be fixed as well. > > I mostly adopted Jim's suggestion/replacement texts without changes. > > What caused probably most confusion in the text is the difference in RFCs > and actual PKIX implementations: > AFAIK the only implementation that can return all chains is MS CryptoAPI, > others don't implement it - NSS definitely doesn't and I didn't find it in Java > libs (security API and bouncycastle) or OS X's Security.framework. > > I removed references to "first match only" behavior from the text, but we > need to keep in mind that in the "transitional period" such behavior is likely > to cause some issues (and given that many implementations are not even > close to RFC 3280/5280 compliant, it will take some time). > > --- begin text --- > > A.1. Creating TLSA Records > > When creating TLSA record with certificate usage type 0 (CA > Certificate) or type 2 (Trust Anchor), the implications need to be > understood taken when choosing between selector type 0 (full > certificate) and 1 (SubjectPublicKeyInfo). Careful choice is > required due to the different methods various TLS clients employed to > build trust-chains. We first outline cases to be aware of and then > discuss implications on choice of selector type. > > Certificate usage 2 is not affected by the issue of chain building > when the end entity certificate and the trust anchor certificate are > the same. > > A.1.1. Ambiguities and corner cases of trust-chain building by TLS > clients > > TLS clients may implement their own chain building code rather than > rely on the chain presented by the server. This means that, except > for the end-entity certificate, any certificate presented in the > suggested chain may or may not be present in the final chain built by > the client. > > Certificates the client can use to replace certificates from original > chain include: > > 1. client's trust anchors > > 2. certificates cached locally > > 3. certificates retrieved via URI listed in Authority Information > Access X.509v3 extension. > > CAs frequently issue/reissue certificates with different validity > period, signature algorithm (updated hash), CA key pair (cross- > certificate) or extensions (public key, subject remain intact). We need to set off the last parenthesis expression since they are not extensions. Suggest ... or extensions where the public key and subject remain the same. > Those are the certificates TLS client can use in place of an original > certificate. > > Cases when clients are known to exchange or remove certificates that > could cause TLSA association by full certificate to fail are listed > below: > > 1. The client considers the signature algorithm of a certificate to > no longer be sufficiently secure. This may be because of the > hash algorithm or the signature key size. > > 2. The client may not have associated root certificate in trust > store and uses a cross-certificate with identical subject and > public key instead. > > A.1.2. Discussion on choice of selector type > > Definition: "false-negative failure" means that client will not > accept the TLSA association for certificate designated by DNS > administrator. I don't care for this definition of false-negative failure. It implies that if the association was actually incorrect then it would still be a false negative failure. I would also want to look at the other side of this. Definition: "false-positive acceptance" means that the client accepts a TLSA association for a certificate not designated by the DNS administrator. Is that really what you want to say? Jim > > A.1.2.1. Choosing selector type 0 (full certificate) > > "Full certificate" selector provides most precise specification of > TLS certificate association, capturing all fields of X.509 > certificate. For DNS administrator, best course to avoid false- > negative failures at client's side when using this selector are: > > 1. don't associate to CA certificates having signature algorithm > with hash that is considered weak if CA issued a replacement > certificate > > - hash algorithms considered weak at moment of writing: MD2 > (RFC 6149), MD5 (RFC 6331) > > 2. check how common client programs process the TLSA association on > fresh client installations - local certificate cache needs to be > empty > > A.1.2.2. Choosing selector type 1 (SubjectPublicKeyInfo) > > SubjectPublicKeyInfo selector gives greater flexibility in avoiding > share of false-negative failures caused by trust-chain-building > algorithms used in clients. > > One specific use-case should be noted: creating TLSA association to > certificate I1 that directly signed end entity certificate S1 of > server. Since the key used to sign S1 is fixed, association to I1 > must succeed - if client swaps I1 for other certificate I2, its SPKI > must match SPKI of I1. Such association would not suffer from false- > negative failure on client's side should the client use a reissued CA > certificate I2 in place of I1. > > The attack surface is a bit broader compared to "full certificate" > selector: > > 1. administrator must know or trust the CA not to engage in bad > practices (not sharing key of I1 for unrelated CA certificates > leading to trust-chain redirect) > > 2. administrator should understand whether some X.509v3 extension > may adversely affect security of the association. If possible, > administrator should overview CA certificates sharing the SPKI. > > Using SPKI selector for association with a certificate in chain above > I1 is to be decided on by-case basis. There are too many > possibilities depending on issuing CA. Unless full implications of > such association are understood by administrator, using selector type > 0 might be better option security-wise. > > --- end-text --- > > Ondrej Mikle From ietf@augustcellars.com Mon Jan 23 22:37:31 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50B5321F8591 for ; Mon, 23 Jan 2012 22:37:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALnVFJL5-fXh for ; Mon, 23 Jan 2012 22:37:29 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id D7E6021F8592 for ; Mon, 23 Jan 2012 22:37:29 -0800 (PST) Received: from Tobias (exodus.augustcellars.com [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 6D50938F1B; Mon, 23 Jan 2012 22:37:28 -0800 (PST) From: "Jim Schaad" To: "'Ondrej Mikle'" References: <59E1FDB4-B832-415A-BEE3-8E85CC55E337@vpnc.org> <20120122012034.GA24296@odin.ulthar.us> <20120122183325.GA6635@odin.ulthar.us> <8BD41639-E2A2-4348-9796-B2BFF193B088@vpnc.org> <4F1DA879.3010504@nic.cz> <077BF214-D6FA-4079-A0E2-CFD3D39A80BD@vpnc.org> <4F1E00F1.9030008@nic.cz> In-Reply-To: <4F1E00F1.9030008@nic.cz> Date: Mon, 23 Jan 2012 22:36:46 -0800 Message-ID: <030901ccda62$8e2ce9a0$aa86bce0$@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: AQH6KdQmJ/2fWJHFbSu0mVf6VQmpagHD+7shARI10dABUMNtAAGWLqC7AtRvn5ABoEg1AQJrOrA+lVuIiQA= Content-Language: en-us Cc: dane@ietf.org Subject: Re: [dane] Pseudocode review X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 06:37:31 -0000 I would hope that the code in these libraries would start accepting the DANE information as a chain building parameter and thus the first valid chain changes based on the DANE records. Jim > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of > Ondrej Mikle > Sent: Monday, January 23, 2012 4:53 PM > To: Paul Hoffman > Cc: dane@ietf.org > Subject: Re: [dane] Pseudocode review > > On 01/24/2012 12:04 AM, Paul Hoffman wrote: > > On Jan 23, 2012, at 10:35 AM, Ondrej Mikle wrote: > > > >> On 01/23/2012 06:54 PM, Paul Hoffman wrote: > >>> Sorry, I'm still missing it, and I think that the problem is on my end. > >>> > >>> On Jan 22, 2012, at 10:33 AM, Scott Schmit wrote: > >>> > >>>> In A.1.1, the text implies that the client will stop after finding > >>>> the first chain that works, so the operator should chose their > >>>> anchor with care, because the association could fail for some > >>>> clients or under some conditions (e.g., the client has or hasn't > >>>> visited a site with an alternate certificate recently). > >>> > >>> > >>> Yes, that is correct. > >>> > >>> If you propose alternate wording for the pseudocode comment above, I > suspect I'll say "that's what we meant" and use it directly. > >> > >> > >> I removed the "first match" behavior from the update to A.1 I posted > >> a while ago. Though in real deployment it will take time until > >> implementations support building and checking all paths (e.g. RFC 4158). > >> > >> What about adding the following sentence at the end of the "// A TLS > >> client might have multiple trust anchors that it might..." pseudocode > >> commend: > >> > >> "Note that there will be transitional period where clients may not > >> check all chains and instead pick one arbitrary chain." > > > > > > I'm still confused. Why should an implementation check all chains? The first > good chain is good enough, yes? > > I'm not sure where the confusion happens, so I'll write it out explicitly in a > "python-ic" pseudocode. > > Wanted: first chain where the expression "TLSA association succeeds && > PKIX validation succeeds" evaluates to true (according to DANE rules). > > Current implementations of PKIX validation (except CryptoAPI) have only a > method > like: > > findFirstValidChain(chainFromHandshake, trustAnchors, cachedCerts) > returning CertChain > > In a naive implementation, a developer might be tempted to do: > > > tlsaRecord = fetchTlsa(fqdn, port, protocol) certChain = > findFirstValidChain(chainFromHandshake, trustAnchors, cachedCerts) valid = > checkTlsa(certChain, tlsaRecord) > > > Such "first match" implementation will ocassionally fail as false-negative. The > "checkTlsa" method does first TLSA check, then PKIX validation on a chain > (including CLR/OCSP) according to DANE rules. > > An implementation that should be correct according to DANE rules might look > like (taking into account blocking operations like OCSP/CRL/AIA fetching): > > > tlsaRecord = fetchTlsa(fqdn, port, protocol) # build initial certchains queue to > check from "offline" data queue = [chainFromHandshake] + > buildValidChains(chainFromHandshake, > trustAnchors, cachedCerts) > > while (not queue.empty): > chain = queue.popFront() > if checkTlsa(chain, tlsaRecord): return True > > #add chains we didn't see before via RFC 4158 methods like AIA fetch > queue += buildRfc4158Chains(chain, trustAnchors, cachedCerts) > > return False #no certchain matched > > > Methods "buildValidChains" and "findFirstValidChain" differ only in the fact > that the first one returns all chains, not just the first one (cycle detection is > skipped for clarity). > > Ondrej Mikle > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From ietf@augustcellars.com Mon Jan 23 22:41:42 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC1D21F8600 for ; Mon, 23 Jan 2012 22:41:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.421 X-Spam-Level: X-Spam-Status: No, score=-3.421 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Is12vP2zHxA for ; Mon, 23 Jan 2012 22:41:42 -0800 (PST) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id ECF5421F85FD for ; Mon, 23 Jan 2012 22:41:41 -0800 (PST) Received: from Tobias (exodus.augustcellars.com [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 4FE642C9F4; Mon, 23 Jan 2012 22:41:40 -0800 (PST) From: "Jim Schaad" To: , "'Ondrej Mikle'" References: <4F1DE8C5.5090700@nic.cz> from "Ondrej Mikle" at Jan 24, 12 00:09:57 am <201201240149.q0O1non1013583@fs4113.wdf.sap.corp> In-Reply-To: <201201240149.q0O1non1013583@fs4113.wdf.sap.corp> Date: Mon, 23 Jan 2012 22:40:59 -0800 Message-ID: <030a01ccda63$246862a0$6d3927e0$@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: AQHYQLJVTy10FrnuhcDSB5yrf3y2V5YERGnQ Content-Language: en-us Cc: dane@ietf.org Subject: Re: [dane] Opening Issue #37. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 06:41:42 -0000 > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of > Martin Rex > Sent: Monday, January 23, 2012 5:50 PM > To: Ondrej Mikle > Cc: dane@ietf.org > Subject: Re: [dane] Opening Issue #37. > > Ondrej Mikle wrote: > > > > On 01/23/2012 09:39 PM, Zack Weinberg wrote: > > > This seems like a decent point to bring up (again) the fact that as > > > far as I am aware, "libpkix" is the only open-source *library* out > > > there that claims to implement RFC 4158 and 5280 in detail, and no > > > *client* I know of uses it unconditionally. > > > > [snip] > > > > > I think it is not DANE's job to fix this mess, and we should drop > > > the phrase "PKIX validation" entirely from the spec, replacing it > > > with something like > > > > > > # DANE clients SHOULD perform the same validation steps on the # > > > certificate chain that they would have in the absence of TLSA # > > > records, except that they MUST defer deciding whether the chain # > > > terminates in an acceptable root until TLSA information has been # > > > taken into account. > > > > > > thus allowing DANE-compliant clients to continue with their present > > > state of (non)conformance to PKIX. > > > > I agree with your description of the issue, but I don't think the > > proposed replacement of "PKIX validation" will solve it. The real > > issue is in "non-deterministic" way how clients build trust paths > > presently (and with caching of intermediate certs, it's non-trivial to > reproduce). > > While before DANE a client built some chain that validated, with TLSA > > constraints it won't be enough. > > > > RFC 4158 section 6 just adds more non-determinism, especially AIA > retrieval. > > rfc4158 is informative, and I am not aware of any reference from PKIX > (rfc5280) to rfc4158. It appears to reference RFC 3280 in the introduction, I have not looked father > > Btw. it would be folly to perform AIA retrievel (aka forward chaining) during > certificate path validation, because it would mean to perform downloads > from arbitrary untrusted URLs supplied by an attacker. I'm aware that Web > Browsers do lots of folly things all the time, but a PKIX implementation > should not try to reproduce each and every security vulnerability of a > browser that displays a plain-http resource. There is a possible attack in terms of tracking what the client is doing, but since the data download will be validated the issue is privacy not security. Jim > > > -Martin > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From matt@mattmccutchen.net Mon Jan 23 23:05:26 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12BC221F85EE for ; Mon, 23 Jan 2012 23:05:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPmGsFoNw+R4 for ; Mon, 23 Jan 2012 23:05:25 -0800 (PST) Received: from homiemail-a38.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 7B2BA21F85C0 for ; Mon, 23 Jan 2012 23:05:25 -0800 (PST) Received: from homiemail-a38.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a38.g.dreamhost.com (Postfix) with ESMTP id 4099110AFB0; Mon, 23 Jan 2012 23:05:25 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=message-id :subject:from:to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:mime-version; q=dns; s= mattmccutchen.net; b=IF3e7DvZ1Kpu4xGOcdTQenWD5osiZON/O8/jKJ8B2GY mJIFI92EK8XUk5WveNXDTMUeiSqFlsKeR1OV9uuMNV8CBYjikqLNiQI3MzZJA2DZ +BzqY34r6ozom+dSp3Bxai7pWW40Yz3EHekr8ULZtPbn8NSc+nALQGp+ufjweVH4 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= message-id:subject:from:to:cc:date:in-reply-to:references :content-type:content-transfer-encoding:mime-version; s= mattmccutchen.net; bh=ACd9tRjOG4KTRRx/6+U6k615+m8=; b=brc6n+6vW+ dg9wE7niz0TL381VEni+JKWS1ewahWlLwa8LZ4DUEUs4a+xrqhbzWHAJxaNpUtfO IlpoS2aMaXA2WJz4Z+NChpkXtfiQsOIyhBAow+Eo0h1vowFqtYzPyvyClBDpahj8 hLUlKFYgzyBv7tFqRBgL7K2+xS5ZVmg/U= Received: from [IPv6:::1] (c-98-248-34-40.hsd1.ca.comcast.net [98.248.34.40]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a38.g.dreamhost.com (Postfix) with ESMTPSA id 0D66D10AFAB; Mon, 23 Jan 2012 23:05:25 -0800 (PST) Message-ID: <1327388723.3558.73.camel@localhost> From: Matt McCutchen To: Paul Hoffman , Martin Rex Date: Mon, 23 Jan 2012 23:05:23 -0800 In-Reply-To: <734367B8-48F9-4D8F-A106-DC744754FB84@vpnc.org> References: <201201231921.q0NJLS1i021543@fs4113.wdf.sap.corp> <734367B8-48F9-4D8F-A106-DC744754FB84@vpnc.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Cc: IETF DANE WG list Subject: Re: [dane] Opening Issue #37. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 07:05:26 -0000 On Mon, 2012-01-23 at 14:50 -0800, Paul Hoffman wrote: > On Jan 23, 2012, at 11:21 AM, Martin Rex wrote: > > > Scott Schmit wrote: > >> > >> The draft states: > >> # 2 -- The target certificate MUST pass PKIX validation, with any > >> # certificate matching the TLSA record considered to be a trust > >> # anchor for this validation > > > > That statement in the draft seems to be somewhat incorrect and misleading. > > > > If the TLSA usage type 2 refers to a NON-self-signed End-Entity cert > > (or its hash or its SPKI), then it will be technically impossible to > > perform PKIX path validation. > Trust anchors in PKIX (RFC 5280) are keys, not certificates. The spec is easily fixed: 2 -- The target certificate MUST pass PKIX validation, with any SPKI of a certificate matching the TLSA record considered to be a trust anchor for this validation I still suspect Martin is right. Let me try to spell out the scenario. Suppose that for my TLS service, I wish to use a certificate C signed by a traditional public CA (for the benefit of legacy clients), but I want DANE clients to accept the certificate irrespective of whether they choose to include the CA in their traditional trust anchor list. To reduce my exposure to malfeasance by the CA, I want to make a restrictive assertion of the certificate C, not the CA certificate. Under these circumstances, I would use an association of usage 2 containing C. Let K be the SPKI of C. The DANE client would attempt to PKIX-validate C, with K considered to be a trust anchor for this validation. If the validation were to succeed, it could only be by virtue of the fact that C itself contains the trust anchor K (because the signature on C is by another, unrelated key). The path for C would contain zero(!) certificates followed by the trust anchor K; in particular, it would not contain the certificate C being validated. I find this hard to believe, but I will let those more familiar with the arcana of PKIX resolve the question. -- Matt From ietf@augustcellars.com Tue Jan 24 01:12:20 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70CA121F84AF for ; Tue, 24 Jan 2012 01:12:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.439 X-Spam-Level: X-Spam-Status: No, score=-3.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ccA5QdZdWkCh for ; Tue, 24 Jan 2012 01:12:18 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 5738721F8499 for ; Tue, 24 Jan 2012 01:12:18 -0800 (PST) Received: from Tobias (exodus.augustcellars.com [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id C120A38F2B; Tue, 24 Jan 2012 01:12:17 -0800 (PST) From: "Jim Schaad" To: "'Matt McCutchen'" , "'Paul Hoffman'" , "'Martin Rex'" References: <201201231921.q0NJLS1i021543@fs4113.wdf.sap.corp> <734367B8-48F9-4D8F-A106-DC744754FB84@vpnc.org> <1327388723.3558.73.camel@localhost> In-Reply-To: <1327388723.3558.73.camel@localhost> Date: Tue, 24 Jan 2012 01:11:38 -0800 Message-ID: <031201ccda78$2e732310$8b596930$@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: AQEfvNxEKi5iRks9LTk6gbWUh62fMwG9SsNcAIRu0cGXY2gzUA== Content-Language: en-us Cc: 'IETF DANE WG list' Subject: Re: [dane] Opening Issue #37. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 09:12:20 -0000 > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of > Matt McCutchen > Sent: Monday, January 23, 2012 11:05 PM > To: Paul Hoffman; Martin Rex > Cc: IETF DANE WG list > Subject: Re: [dane] Opening Issue #37. > > On Mon, 2012-01-23 at 14:50 -0800, Paul Hoffman wrote: > > On Jan 23, 2012, at 11:21 AM, Martin Rex wrote: > > > > > Scott Schmit wrote: > > >> > > >> The draft states: > > >> # 2 -- The target certificate MUST pass PKIX validation, with any > > >> # certificate matching the TLSA record considered to be a trust > > >> # anchor for this validation > > > > > > That statement in the draft seems to be somewhat incorrect and > misleading. > > > > > > If the TLSA usage type 2 refers to a NON-self-signed End-Entity cert > > > (or its hash or its SPKI), then it will be technically impossible to > > > perform PKIX path validation. > > > Trust anchors in PKIX (RFC 5280) are keys, not certificates. > > The spec is easily fixed: > > 2 -- The target certificate MUST pass PKIX validation, with any SPKI of a > certificate matching the TLSA record considered to be a trust anchor for this > validation > > I still suspect Martin is right. Let me try to spell out the scenario. > > Suppose that for my TLS service, I wish to use a certificate C signed by a > traditional public CA (for the benefit of legacy clients), but I want DANE > clients to accept the certificate irrespective of whether they choose to > include the CA in their traditional trust anchor list. To reduce my exposure to > malfeasance by the CA, I want to make a restrictive assertion of the > certificate C, not the CA certificate. > Under these circumstances, I would use an association of usage 2 containing > C. > > Let K be the SPKI of C. The DANE client would attempt to PKIX-validate C, > with K considered to be a trust anchor for this validation. If the validation > were to succeed, it could only be by virtue of the fact that C itself contains > the trust anchor K (because the signature on C is by another, unrelated key). > The path for C would contain zero(!) certificates followed by the trust anchor > K; in particular, it would not contain the certificate C being validated. I find > this hard to believe, but I will let those more familiar with the arcana of PKIX > resolve the question. That is exactly what I would expect to happen. The PKIX code is undefined for a chain length of zero, so your implementation of the code may vary. Some implementations (I think the msft one) would require that the actual certificate C be in the trusted store rather than any arbitrary certificate B which happened to have the same public key K. I would imagine that other implementations may or may not deal with this case correctly. Jim > > -- > Matt > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From pieter.lexis@os3.nl Tue Jan 24 04:30:36 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BCE721F8542 for ; Tue, 24 Jan 2012 04:30:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.383 X-Spam-Level: X-Spam-Status: No, score=-2.383 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7MB0FAV1l5f for ; Tue, 24 Jan 2012 04:30:35 -0800 (PST) Received: from mail.serv.os3.nl (mail.serv.os3.nl [IPv6:2001:610:158:960::25]) by ietfa.amsl.com (Postfix) with ESMTP id ECFA621F856C for ; Tue, 24 Jan 2012 04:30:34 -0800 (PST) Received: from smtp.os3.nl (smtp.os3.nl [IPv6:2001:610:158:960::119]) by mail.serv.os3.nl (Postfix) with ESMTP id 72DC917AA16 for ; Tue, 24 Jan 2012 13:30:33 +0100 (CET) Received: from [IPv6:2001:610:158:1020:88a8:cf1a:8da1:9845] (unknown [IPv6:2001:610:158:1020:88a8:cf1a:8da1:9845]) by smtp.os3.nl (Postfix) with ESMTPSA id 23C1B17A9C9 for ; Tue, 24 Jan 2012 13:30:33 +0100 (CET) Message-ID: <4F1EA468.4030201@os3.nl> Date: Tue, 24 Jan 2012 13:30:32 +0100 From: Pieter Lexis User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111109 Thunderbird/3.1.16 MIME-Version: 1.0 To: dane@ietf.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dane] Announcing the alpha release of swede - A tool to create and verify TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 12:30:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi All, I am doing a small academic project on the DANE specification to see it is implementable in its current form (apart from issue 37 and 28 currently being discussed, yes). For this I created a tool that can create all 18 permutations of TLSA records and can verify TLSA records from DNS with the certificate(-chain) received from the SSL-service. I have all permutations running on dane.kiev.studlab.os3.nl on ports 1500 through 1517 (tcp), using https. I've also used the tool to successfully[0] verify records mentioned in [1]. It has limitations, which are mentioned in the README file. The code is available on github[2] and as a tarball[3]. Please test it, review the code and comment on it and send me patches or pull-requests if you fix a bug. I hope this tool will be helpful for the WG. In addition, I wonder if it is a good idea to generate 18 test vectors for inclusion in the RFC?. 'swede' might be helpful in this respect Regards, Pieter Lexis 0 - http://pastie.org/3243017 1 - http://www.ietf.org/mail-archive/web/dane/current/msg04080.html 2 - https://github.com/pieterlexis/swede 3 - https://github.com/pieterlexis/swede/tarball/master -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPHqRlAAoJELPqGO5ebd4jsTIP+wZYurzeJoOFPhoMu/a/q1PR QNA09YYsCkuAc0cWloT+iZPppHrK0r/FlXbto2Dc4GSQwEv7INcEKv5ltLjqWJjl D7gLv+caIDw7M2cysPG3HIMaz+hRXHaerEtg+owoWleihE2lehgcTHPVPAXS78Sc iGg+9d775s4ISDFgSD8I9EJorj0gDCrvYAmQsi7ukl0GbM/ISJGMASVm1rE6WJ6A nvQeTqjAvvIba2Jse7ybH8xFjYkb8Ujk27RJP67ZlpTx4Bx8GdSXFDPCBHvBrlBW 8HqqCO8F4WWDpjxpcTv89c1CvmTyzE0ryfjh3OMbQj70FXE2ficVGbV46IvVTP5R CcfIpezr4u2PUkdbYFjlknjBA5rpV8CqXWDoTc8Eczn43VvOp2cF4ZlquPjQvQmZ gqu0FgXsN2ljHvGbxroXG/h7E9Uoe31+2Oyg/oY41h5c4JQlKDC6SaDzjHhOmFmT XHbKP+DuFoEV5Kpf9ZIeEwVTI++XKFHDU5iRDWbMv2WjA29p6oh5INZ5FP2lNx+e EshjxZVCeQuowHUXsCmS1mPsOEoPWZyV61ryUwQoLVHnozJfOy4AxbeWabtyPGud C06hSqZRpjVSKGIElimhG+ToVzPhJFwQuItn3+efruahe8NEhsbut45xk5Yi4EE0 TX6onFLovK6N79BpSvdi =okS7 -----END PGP SIGNATURE----- From i.grok@comcast.net Tue Jan 24 05:22:49 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D49D521F853B for ; Tue, 24 Jan 2012 05:22:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.344 X-Spam-Level: X-Spam-Status: No, score=-102.344 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNBDJQQjKvGV for ; Tue, 24 Jan 2012 05:22:49 -0800 (PST) Received: from qmta14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [76.96.27.212]) by ietfa.amsl.com (Postfix) with ESMTP id ED5D221F84F3 for ; Tue, 24 Jan 2012 05:22:42 -0800 (PST) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta14.emeryville.ca.mail.comcast.net with comcast id RRMW1i0051Y3wxoAERNiH6; Tue, 24 Jan 2012 13:22:42 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta15.emeryville.ca.mail.comcast.net with comcast id RRNh1i00h00PQ6U8bRNiH3; Tue, 24 Jan 2012 13:22:42 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.3) with ESMTP id q0ODMeSM029032 for ; Tue, 24 Jan 2012 08:22:40 -0500 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id q0ODMeME029031 for dane@ietf.org; Tue, 24 Jan 2012 08:22:40 -0500 Date: Tue, 24 Jan 2012 08:22:40 -0500 From: Scott Schmit To: dane@ietf.org Message-ID: <20120124132240.GE14597@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <4F1EA468.4030201@os3.nl> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="WBsA/oQW3eTA3LlM" Content-Disposition: inline In-Reply-To: <4F1EA468.4030201@os3.nl> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Announcing the alpha release of swede - A tool to create and verify TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 13:22:49 -0000 --WBsA/oQW3eTA3LlM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 24, 2012 at 01:30:32PM +0100, Pieter Lexis wrote: > I hope this tool will be helpful for the WG. In addition, I wonder if it > is a good idea to generate 18 test vectors for inclusion in the RFC?. > 'swede' might be helpful in this respect Equally important are test vectors demonstrating validation failure and going through multiple records on a given host (some of which pass and some of which fail). Nevertheless, good stuff! I've been meaning to do the same, but haven't gotten around to it myself (other than to generate records). --=20 Scott Schmit --WBsA/oQW3eTA3LlM Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQJgYJKoZIhvcNAQcCoIIQFzCCEBMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DVcwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBxswggYDoAMCAQICAwK+HTANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTExMDcxNzA1 MDQwNFoXDTEyMDcxNzExNDI1OVowYjEgMB4GA1UEDRMXNDY1MjU2LTBnRmI2Sk5ZWW44QnFW bUwxGzAZBgNVBAMMEmkuZ3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9r QGNvbWNhc3QubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2AjLOMsBGaqN hv2FcRbfom/QCeKMXu5tUd1JY5oIDZe5y29stnd+se/zUlEkiVeMam4Jgo1c8yGNnwLVYc5/ 9xVi7Qg1Is5b9AB6aJWElJDw/jIdihymNZ2kwkSLT0wl/lzd0mXlwFJPRgQiRkmE6V0ZmjsQ jaVtllVleGBbMvmWPm92e+4Bju9P81kKz7Xr02ijETmaPdVsl+jmOaKPS8Y+2Lat2xus4Ked oJ/7aIWIpz1gRSKjAHSZ1Wmwi2TYUjYhZryChu9e1RWtqk1CycNoeusJ8xdEVN3WSnJ299w/ 3ltK/x/9rpj2j9ShQZVB4NnX6cjQs7pz1lVxvIkjcQIDAQABo4IDrTCCA6kwCQYDVR0TBAIw ADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBQ29j2I0O8sRYi0So9NwwmT1caakDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhR gjAdBgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwggIhBgNVHSAEggIYMIICFDCCAhAG CysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJt ZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUF BwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJp bGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFu ZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0 cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQAZ5U0nL/2PQwsVfHgN7MVPbZEGzDzuj4Oy pTgz4XQFwPcCuy6U9sp1Dwmo3DyKX5nKN4xA7pslN+2Pl/kElGamX7zMCAH0xED0RTOLyk+v nDML4s+OUtWaYVnq1bZEp0F8Luq3zIslAYSebleyiz8M0EypZczsL5rOk86R2F9EYw1CBuFJ 5a4x0CmNu5o30fGNDFt+iXRlbJPp/KY25iUgVnBzJ4COT5kQjxn5lgr4t1I+BDCL5HQQ3h/8 2CzwrWVRBNb9Vqh9LL1ZtzYRt8JezoB6HkVvcKVNGlCZ+/MnvfMzPLwfbTDZC8o4d+4RH6aE LeGF2XmAOaenc/YRqm9oMYIClzCCApMCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQIDAr4dMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTIwMTI0MTMyMjQwWjAjBgkqhkiG9w0BCQQxFgQUZ0sLXmbq wQpnFLK2fwYnNK1+mMMweQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEArrZymAak ggZNA5CB3ZoRuBc1TZE+W7+0MSMvFazrXWqmrYZAWX/K83RO/QRsCSwWrFj1F2we4ZezxQNT EEqx4qtHQ4o85s6P/R99x+6jB+8eEAUp+LpqXTaIfi3ONXU4WaJxmljXVshkadxQWqkJHPX7 /OviEhbnYrpYt7n/YxZ4J6jH+phDXDL/dCEw9tGW1DUkxHkEnk28WhRgzyDufuYjlHRK6S7s aZ11igcunp7j3Ns/jcFWUrXkyw9fIf0ic96LPWOhtkA+NJtNqUyjgZtBW3FblQtl2BprfFM1 iY4873XH9F+NO6OhKSwdKCAr9J+Dw6OjYe9Nah0gJ6BJuA== --WBsA/oQW3eTA3LlM-- From paul@nohats.ca Tue Jan 24 05:38:21 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE38921F84DE for ; Tue, 24 Jan 2012 05:38:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.673 X-Spam-Level: X-Spam-Status: No, score=-0.673 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPe7BwyT4itT for ; Tue, 24 Jan 2012 05:38:21 -0800 (PST) Received: from letoams.cypherpunks.ca (unknown [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 30D6C21F84DD for ; Tue, 24 Jan 2012 05:38:20 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id 8C28381943; Tue, 24 Jan 2012 08:37:38 -0500 (EST) Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.5/8.14.5/Submit) with ESMTP id q0ODbaYx011191; Tue, 24 Jan 2012 08:37:38 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 24 Jan 2012 08:37:36 -0500 (EST) From: Paul Wouters To: Pieter Lexis In-Reply-To: <4F1EA468.4030201@os3.nl> Message-ID: References: <4F1EA468.4030201@os3.nl> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dane@ietf.org Subject: Re: [dane] Announcing the alpha release of swede - A tool to create and verify TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 13:38:21 -0000 On Tue, 24 Jan 2012, Pieter Lexis wrote: > I am doing a small academic project on the DANE specification to see it > is implementable in its current form (apart from issue 37 and 28 > currently being discussed, yes). For this I created a tool that can > create all 18 permutations of TLSA records and can verify TLSA records > from DNS with the certificate(-chain) received from the SSL-service. > > I have all permutations running on dane.kiev.studlab.os3.nl on ports > 1500 through 1517 (tcp), using https. How do i specify type usage? The usage did not tell me. It seems to generate the same RRdata otherwise (though we could have it both wrong :) Paul From pieter.lexis@os3.nl Tue Jan 24 05:53:17 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2407F21F84E2 for ; Tue, 24 Jan 2012 05:53:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.414 X-Spam-Level: X-Spam-Status: No, score=-2.414 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l45DjND7hNtH for ; Tue, 24 Jan 2012 05:53:16 -0800 (PST) Received: from mail.serv.os3.nl (mail.serv.os3.nl [IPv6:2001:610:158:960::25]) by ietfa.amsl.com (Postfix) with ESMTP id 6284A21F84A5 for ; Tue, 24 Jan 2012 05:53:16 -0800 (PST) Received: from smtp.os3.nl (smtp.os3.nl [IPv6:2001:610:158:960::119]) by mail.serv.os3.nl (Postfix) with ESMTP id 8A9B617AA16 for ; Tue, 24 Jan 2012 14:53:15 +0100 (CET) Received: from [IPv6:2001:610:158:1020:88a8:cf1a:8da1:9845] (unknown [IPv6:2001:610:158:1020:88a8:cf1a:8da1:9845]) by smtp.os3.nl (Postfix) with ESMTPSA id 4F2F617A9C9 for ; Tue, 24 Jan 2012 14:53:15 +0100 (CET) Message-ID: <4F1EB7CA.2030905@os3.nl> Date: Tue, 24 Jan 2012 14:53:14 +0100 From: Pieter Lexis User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111109 Thunderbird/3.1.16 MIME-Version: 1.0 To: dane@ietf.org References: <4F1EA468.4030201@os3.nl> <20120124132240.GE14597@odin.ulthar.us> In-Reply-To: <20120124132240.GE14597@odin.ulthar.us> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dane] Announcing the alpha release of swede - A tool to create and verify TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 13:53:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/24/2012 02:22 PM, Scott Schmit wrote: > Equally important are test vectors demonstrating validation failure and > going through multiple records on a given host (some of which pass and > some of which fail). swede iterates over the TLSA records recieved and checks each of them. Try swede verify -p 1518 dane.kiev.practicum.os3.nl It returns a usage 0 and usage 1 RR. I also have created TXT records with some info in them. Cheers, Pieter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPHrfKAAoJELPqGO5ebd4jgC4P/RGRXZzX1MaaFKiIVipiz4Ep jp06Gs6VZTpo9rKhpXRv0W7fMNNDP0Hqv4NBwDxM84Q0B2loL3a88cY7W3yAPtgu 12Anlpet1X6O3LpiLtbRTMmO9rVYCZassQaFfIY4vVe6c1ay5yO5/qR7W0nRmmQy iassUJsbGatr7TylcMkLGVfI5IOT8GMeVg874IQAOqVYaXkrPdBzZCBaxWW6bDjb O/4mCJA2ocoXSpuH2YsrUbXIyZWmzUNp4F/9KEY0AQKvQ5JKXVd0jwq5YIcli6Rj TwHT0b1W9vbq+djrkBjQkz65cn1ByAJRNpeK2dDmB1unxG06UE3S7FFD3VenqP/w mUL3sSthofPDKLXfkLVDD00FdsujUb1fICluLFaSJ6kswjHKtaMnIxvTwijLZnnW 0JGEEtyt0wOe/8P+QEGsUu7dKYk54rvvd0eghdeSVZXVurx+p5GGHaHld3yIpgXe GERnkfGWueB6k1f3mzCf7fmrU/QCMibX1HixaBC+B6CQnSkN1Y1yJcEKrKnA4o7L lK2U7vuH58nCSon51GY5s5su9vt5yCLs+AWNXXUB5Qe46OUi/XunjN2oELjmzgQB RHAm1BFd7RAcFLTfSYsTSeZJDiPa0DfUwDr7+UNk315QBl4ISyfG8nXkAZUSPFSk LUt3VG8ieOuHkyduU3Pr =Vr2M -----END PGP SIGNATURE----- From pieter.lexis@os3.nl Tue Jan 24 05:54:28 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68AEC21F8516 for ; Tue, 24 Jan 2012 05:54:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ducz6J8hpMwo for ; Tue, 24 Jan 2012 05:54:28 -0800 (PST) Received: from mail.serv.os3.nl (mail.serv.os3.nl [IPv6:2001:610:158:960::25]) by ietfa.amsl.com (Postfix) with ESMTP id CC3A921F854D for ; Tue, 24 Jan 2012 05:54:27 -0800 (PST) Received: from smtp.os3.nl (smtp.os3.nl [IPv6:2001:610:158:960::119]) by mail.serv.os3.nl (Postfix) with ESMTP id 1FEFD17AA16 for ; Tue, 24 Jan 2012 14:54:27 +0100 (CET) Received: from [IPv6:2001:610:158:1020:88a8:cf1a:8da1:9845] (unknown [IPv6:2001:610:158:1020:88a8:cf1a:8da1:9845]) by smtp.os3.nl (Postfix) with ESMTPSA id 0B54917A9C9 for ; Tue, 24 Jan 2012 14:54:27 +0100 (CET) Message-ID: <4F1EB812.3080800@os3.nl> Date: Tue, 24 Jan 2012 14:54:26 +0100 From: Pieter Lexis User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111109 Thunderbird/3.1.16 MIME-Version: 1.0 To: dane@ietf.org References: <4F1EA468.4030201@os3.nl> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dane] Announcing the alpha release of swede - A tool to create and verify TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 13:54:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, (now for the on-list reply) On 01/24/2012 02:37 PM, Paul Wouters wrote: > How do i specify type usage? The usage did not tell me. It seems to > generate the same RRdata otherwise (though we could have it both wrong swede create -h should show the options. - --- swede create -u {0,1,2} - --- Cheers, Pieter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPHrgSAAoJELPqGO5ebd4j5nIQAI2VERFh9kSCAYH9JX7LCybD u2RzDVQ4r5rf7z3OQuhGWNjBBaGxD4pzJnXJG6xuwklAGuDkPQW+ThN6XxVIdzfY w7VtS19pJcDcj5rM3OAg96hStDKz7OSRiI/EJpmRklF0bDKtmt2VAyJX28j3Puxg Klth+8lBsE+ik3tbHieGgu76oY//H3kJJL9fXpAhO46GnKumiGhfqYzpgxiLQi6L f4vySxDO3s5cr1yaCgvoDjgs1t2eM4GfjT8PHj+DEmoTVA4n7cZ/xhcctF3SNzdD jtD9yKvwypdcAZ5a64VfMxYmHqcOgNYGy+g4LuDeHyCApetYuRXQuInSbv9OSlhy 6caxj8ZK7guCaAYrqbrqVjUgwx+AETRDUdVzQDM4RvI2J0VFieDNfFq8iKcjJFKx UHVgsJXH+04gJT83xBZy/Qp+Op3C9UBIHU46vGnSAHLJoWVbSxTlEK04CAYT4mVD F7DHk05LfASXvegLtbrheGvo6e4qIgLPujo1aVVsHQamvCF5dwjLi0HPxJiMx202 QdS8o6dQcCSjBPF4O1gpqlSkC83QhrB92ZQpr8lhSiuaczZGLeKDFie3JfFKgGdH gl8metm7NJdHwZ1CZKR/6XCcBObH2Nl28IW4LvD+xnqndD4MCYEbzFEPAC8OgjYR xlDltS99xAw/iNLEXcGU =IBHo -----END PGP SIGNATURE----- From jerry.lundstrom@iis.se Tue Jan 24 06:44:28 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50D3721F8577 for ; Tue, 24 Jan 2012 06:44:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6uAfFgmb0tIt for ; Tue, 24 Jan 2012 06:44:27 -0800 (PST) Received: from relay2.iis.se (relay2.iis.se [IPv6:2a00:801:f0:211::147]) by ietfa.amsl.com (Postfix) with ESMTP id BABB221F859F for ; Tue, 24 Jan 2012 06:44:23 -0800 (PST) Received: from EXCH2K7HUB-RV.office.nic.se (exch2k7hub-rv.office.nic.se [212.247.204.21]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay2.iis.se (Postfix) with ESMTPS id BC5844014FE; Tue, 24 Jan 2012 14:44:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=iis.se; s=r2iis; t=1327416262; bh=u+PNncknNCRGVhBa529wtXTB4fEl2l0FOjGbN8Y2EFU=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=li3bkBjJBZxz9uvkkclx5HyhwvZ9WH0dtMgXPF1AYlh+WBPtSCLyBZqCZmcllGbdX MpGhiioOZMu660FEU+2kK5u1IfRMF9QzMTGxeFkRauza1yT6Msu59lFDIspDNR4P7u rS88iGoJv5AMFJAzvgGEEin4Ep0Zt/0ph2KF9AmQ= Received: from Exchange2k7.office.nic.se ([169.254.1.47]) by EXCH2K7HUB-RV.office.nic.se ([212.247.204.21]) with mapi; Tue, 24 Jan 2012 15:44:21 +0100 From: =?iso-8859-1?Q?Jerry_Lundstr=F6m?= To: Pieter Lexis Date: Tue, 24 Jan 2012 15:44:20 +0100 Thread-Topic: [dane] Announcing the alpha release of swede - A tool to create and verify TLSA records Thread-Index: Aczapqgq5IJQrC+zQIOxsZ0HzlRk9A== Message-ID: References: <4F1EA468.4030201@os3.nl> In-Reply-To: <4F1EA468.4030201@os3.nl> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US, sv-SE Content-Type: multipart/signed; boundary="Apple-Mail=_4E98E901-3259-4EA2-B71A-899DB68F32FB"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "dane@ietf.org" Subject: Re: [dane] Announcing the alpha release of swede - A tool to create and verify TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 14:44:28 -0000 --Apple-Mail=_4E98E901-3259-4EA2-B71A-899DB68F32FB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, On Jan 24, 2012, at 13:30 , Pieter Lexis wrote: > 'swede' I must ask, why the name? :) -- Jerry Lundstr=F6m - Software Engineer .SE - The Internet Infrastructure Foundation http://www.iis.se/ --Apple-Mail=_4E98E901-3259-4EA2-B71A-899DB68F32FB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQEcBAEBAgAGBQJPHsPEAAoJEDEA5dU7hbym9VsH/3wEL9I69qsFyIhGRVEkhIXO IREvJ1wTvVmjpy5cLTu6lkZUY0Yncac5SY7VvNBzXMMFM/XqUTBbFn17wzLhNryx 72PZIzz280DRE0FK2MF8a1rqlryz5vO6lpkp7Ao6QTrp56MuPKA15Du9tx6Osxt9 LktHy5+iD6hqLuOiGspHySsiB5FinixOpOGEI48Tvv0eOvNoui1TzQHiZd6jDd4N rFsTOGkvACk4gf0ml3wfiXGi0Gkg2/t+uC8Anp0G00UySOXbgUTZipAHEI0cGfXm L+XjltLvLZxkDM3hfHT7jkvAeNyyGmEsNQfu39HV74eb8ZUO7FvmDVZ5fssGBVY= =tAzq -----END PGP SIGNATURE----- --Apple-Mail=_4E98E901-3259-4EA2-B71A-899DB68F32FB-- From dane@lists.grepular.com Tue Jan 24 06:47:07 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 695D221F8467 for ; Tue, 24 Jan 2012 06:47:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_21=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7fmbx4ouzKP for ; Tue, 24 Jan 2012 06:47:06 -0800 (PST) Received: from alfa.cardwellit.com (alfa.cardwellit.com [IPv6:2a01:7e00::f03c:91ff:fe93:2a19]) by ietfa.amsl.com (Postfix) with ESMTP id AD2DB21F845C for ; Tue, 24 Jan 2012 06:47:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.grepular.com; s=dkim1; h=Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=I9nVtADqYzigyH0wyszRpmcRO06Ns6VgmU+VA7RnOos=; b=Ock4OQMkmrZfVEVSUWN5/IVvOrAHWwTPe9QebZplNJwUE38jgobQ5jRyYhMZ5cQ43d2NWM/nQSMC/Rt14J749vIlQyDWIWnSqI3vzN/BBiLEkCDiTBzE/bQWFoQslG+LiQFekGjhSl0N999cEBgisdKcYrbR3yTc1GiFl5/rwcw=; Message-ID: <4F1EC466.1030706@lists.grepular.com> Date: Tue, 24 Jan 2012 14:47:02 +0000 From: dane@lists.grepular.com User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: dane@ietf.org References: <4F1EA468.4030201@os3.nl> In-Reply-To: X-Enigmail-Version: 1.3.4 OpenPGP: url=https://grepular.com/0018461F.pub.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig81183152F70699CAD32F4F3C" Subject: Re: [dane] Announcing the alpha release of swede - A tool to create and verify TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 14:47:07 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig81183152F70699CAD32F4F3C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 24/01/12 14:44, Jerry Lundstr=F6m wrote: >> 'swede' >=20 > I must ask, why the name? :) At a guess: Dane - Danish Swede - Swedish --=20 Mike Cardwell https://grepular.com/ http://cardwellit.com/ OpenPGP Key 35BC AF1D 3AA2 1F84 3DC3 B0CF 70A5 F512 0018 461F XMPP OTR Key 8924 B06A 7917 AAF3 DBB1 BF1B 295C 3C78 3EF1 46B4 --------------enig81183152F70699CAD32F4F3C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQGGBAEBAgBwBQJPHsRoMBSAAAAAACAAB3ByZWZlcnJlZC1lbWFpbC1lbmNvZGlu Z0BwZ3AuY29tcGdwbWltZTgUgAAAAAAVABpwa2EtYWRkcmVzc0BnbnVwZy5vcmdt aWtlLmNhcmR3ZWxsQGdyZXB1bGFyLmNvbQAKCRCdJiMBwdHnBBx+CAC+kmBXRRKJ AcMZbBZVVoqXXv2Ui/0ylENaBaYwt11CrCLw4JWi9fE1ytAsdHFMv2ZtS8FUlw5P CreqayECCkwiuXE6jbgzEcUEaWQnIKZzsjaFfEUOabyoJSuWfc2xWW2e9vTgbvsY fAbe93FNGTFWefUKkW7o2FHG4oPyTNbF9mXnOIvUfutJw9KJim+bZK1/y6Q3ZJ1X SalX7hTDeLOLyZqgRAtGBVt/PU3hVTZDJhbBPj5OnqtdAhPRy0K4bn7QeZXmKBMA TPYFlJqzmlKRbY4zhm4f0sz4GBbzp2tmX0Mx8T1u++X1Is8h4cs+8G7EPX3NaZea bbBenCx1c3cQ =/ebK -----END PGP SIGNATURE----- --------------enig81183152F70699CAD32F4F3C-- From pieter.lexis@os3.nl Tue Jan 24 07:08:19 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA3321F8663 for ; Tue, 24 Jan 2012 07:08:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_RMML_Stock1=0.21] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NmRYZ+B36DdI for ; Tue, 24 Jan 2012 07:08:18 -0800 (PST) Received: from mail.serv.os3.nl (mail.serv.os3.nl [IPv6:2001:610:158:960::25]) by ietfa.amsl.com (Postfix) with ESMTP id 462F821F8661 for ; Tue, 24 Jan 2012 07:08:18 -0800 (PST) Received: from smtp.os3.nl (smtp.os3.nl [IPv6:2001:610:158:960::119]) by mail.serv.os3.nl (Postfix) with ESMTP id 8FC0317AA16 for ; Tue, 24 Jan 2012 16:08:17 +0100 (CET) Received: from [IPv6:2001:610:158:1020:88a8:cf1a:8da1:9845] (unknown [IPv6:2001:610:158:1020:88a8:cf1a:8da1:9845]) by smtp.os3.nl (Postfix) with ESMTPSA id 4038617A9C9 for ; Tue, 24 Jan 2012 16:08:17 +0100 (CET) Message-ID: <4F1EC960.1020401@os3.nl> Date: Tue, 24 Jan 2012 16:08:16 +0100 From: Pieter Lexis User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111109 Thunderbird/3.1.16 MIME-Version: 1.0 To: dane@ietf.org References: <4F1EA468.4030201@os3.nl> <4F1EC466.1030706@lists.grepular.com> In-Reply-To: <4F1EC466.1030706@lists.grepular.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [dane] Announcing the alpha release of swede - A tool to create and verify TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 15:08:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/24/2012 03:47 PM, dane@lists.grepular.com wrote: > On 24/01/12 14:44, Jerry Lundström wrote: > >>> 'swede' >> >> I must ask, why the name? :) > > At a guess: > > Dane - Danish > Swede - Swedish And 'dane' already was a tool in the SSHFP package. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPHslcAAoJELPqGO5ebd4juPgP/RzQUPiJOZN/6wFcjwYjtj20 dp4ICDrGOKlNyA6Nig737SFqCjhclu2CAyNL2kYrEIyXl0LH8vkQ1xzQHXaPgeDn SOpRRZYhRXYiVaO4WE+t58RTfs+OzEMmUUXvg4+lgyB0G+GDZ8vYCHBGGMatGyF2 /Aeyd6jcJtkoENNBx2zXYVSi5ucraR3oI1hBTJ0iiWh+FHuGMWqpLCenylfBVF2m jS7GLq3RYntKmQBEr7Sq6jXXyOLHwQwRdYoZBVpE7hFY/QHnAChW1gxJ8g9NL+c6 lYkRVaakBxoedchjLm3LMW+vm/UHDYlm9BGa5y2RNORCQZQPzvpWGUTMa4/k/cXx AfF6EbD+T96H73vYmwUoPZmbOaYlaBj223R6wbgplnVZ4dmA9Tf8bEUXtFyIQRrn irUGHEr9JwrsqSCK9SPqmkd6j3qQ1qtzLKGRJEz3lCA/LzggRnSKqFwUwM9ORm94 7ap9iXcZbJ+KdFPRTlEYNcR3vH10QPnZaV8QowHqTDKs2Faw8BFRs5wNTehRegdy Elw3lW2UN9ZlK0RpzYLNADcFCkVt82mmD1GvbkadDacgOEktZj5cw+uH8hZyx7xg GVq2rkWTtHby0TCO3HWW6SM1VGWlT1c3qBgZ109gfyYmH6BCjblSnBXVtP2EJX6H DSKhKxed/zmWlEfs58fx =0JG+ -----END PGP SIGNATURE----- From cloos@jhcloos.com Tue Jan 24 07:12:32 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 674DB21F85C0 for ; Tue, 24 Jan 2012 07:12:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.228 X-Spam-Level: X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NIlzvAofXlA for ; Tue, 24 Jan 2012 07:12:31 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by ietfa.amsl.com (Postfix) with ESMTP id A2EB121F8574 for ; Tue, 24 Jan 2012 07:12:31 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 3245D400EC; Tue, 24 Jan 2012 15:12:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1327417950; bh=arKXYGUMS/MKegJZsA+37G8oyXBsNZ2Yf7X36G1buuA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=yAtPJOrOTqg0B99swW7Uz/beUUYdKtzPk9diHMO63n0NTI4ZPSzAs0ZMGHSGnTJaN 2X4TdW+/eM8CWKKNDkJXy6N6cax0pNzIfEUUZItAPvjkYyWLXiOK7+7/Gm0qa2Y3Ab K8Ue1PZBufOMe4IcO/lmg4h/8PfowEgOL9AOX2Yk= Received: by carbon.jhcloos.org (Postfix, from userid 500) id F033A36004C; Tue, 24 Jan 2012 15:01:48 +0000 (UTC) From: James Cloos To: Pieter Lexis In-Reply-To: <4F1EA468.4030201@os3.nl> (Pieter Lexis's message of "Tue, 24 Jan 2012 13:30:32 +0100") References: <4F1EA468.4030201@os3.nl> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.92 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2012 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Tue, 24 Jan 2012 10:01:48 -0500 Message-ID: Lines: 25 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Hashcash: 1:30:120124:pieter.lexis@os3.nl::GNfA2rw/kmdAZ+7i:00000000000000000000000000000000000000000UrBwd X-Hashcash: 1:30:120124:dane@ietf.org::a5csAqMTHhFi/Ex4:000bXJFE Cc: dane@ietf.org Subject: Re: [dane] Announcing the alpha release of swede - A tool to create and verify TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 15:12:32 -0000 --=-=-= Content-Type: text/plain I was unable to use swede on my workstation because it started every lookup at . and must have timed out before drilling down to the TLSA and A/AAAA RRs. I added this to take advantage of the local (unbound) cache: --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=0001-Use-the-local-dns-cache.patch >From a7e5728b624ab414d003cef169c1c107239733f2 Mon Sep 17 00:00:00 2001 From: James Cloos Date: Tue, 24 Jan 2012 09:40:25 -0500 Subject: [PATCH] Use the local dns cache Without this, swede is unable to drill down from the . IN NS lookup to the final TLSA and A/AAAA lookup(s) before libunbound times out. Signed-off-by: James Cloos --- swede | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/swede b/swede index 643c079..5390427 100755 --- a/swede +++ b/swede @@ -111,6 +111,7 @@ def getRecords(hostname, rrtype='A', secure=True): """Do a lookup of a name and a rrtype, returns a list of binary coded strings. Only queries for rr_class IN.""" ctx = unbound.ub_ctx() ctx.add_ta_file('root.key') + ctx.resolvconf("/etc/resolv.conf") if type(rrtype) == str: if 'RR_TYPE_' + rrtype in dir(unbound): -- 1.7.8.3 --=-=-= Content-Type: text/plain and it started working. I haven't tested this with non-unbound resolvers in the resolv.conf, but unbound itself works when using non-verifying foward-hosts so it ought to be OK. Also, this: :; for p in $(seq 00 17);do dig @localhost +tcp +short +dnssec _15${p}._tcp.dane.kiev.studlab.os3.nl TYPE65468; done generates NXDOMAIN for all of those ports. Are those meant for create instead of verify?) -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 --=-=-=-- From ondrej.mikle@nic.cz Tue Jan 24 07:13:48 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3FCF21F8675 for ; Tue, 24 Jan 2012 07:13:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_47=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DcVrgqQVoGKd for ; Tue, 24 Jan 2012 07:13:48 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 121EC21F85E6 for ; Tue, 24 Jan 2012 07:13:48 -0800 (PST) Received: from [IPv6:2001:1488:ac14:1400:222:64ff:fe2f:75c2] (unknown [IPv6:2001:1488:ac14:1400:222:64ff:fe2f:75c2]) by mail.nic.cz (Postfix) with ESMTPSA id E43E72A2BEB; Tue, 24 Jan 2012 16:13:46 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1327418026; bh=EX4Fy1RMcqAgZBmWR3Mdjuyb8kc1okU1JMjf8Vrmt1I=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=QDVbErjWnCx12zV3RCc4R/obRoxoBK+V0xsbd0wv/l8qTUItEGUwBQqtYhMWJbjxW OQNoEQ/FVj/D/9S88hdr64a377vMquVEZkFWtd3ydskTg4struLp+jDUca2r9VDQgm /DsJoeOakDojywrYxtF3Xb/kuUjkLkXzYLA9YI58= Message-ID: <4F1ECA6B.6010609@nic.cz> Date: Tue, 24 Jan 2012 16:12:43 +0100 From: Ondrej Mikle User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Jim Schaad References: <4EEE63EB.9020800@nic.cz> <00ca01ccc5b6$57d79e10$0786da30$@augustcellars.com> <4F1DA1B1.6030404@nic.cz> <030801ccda62$4ebde620$ec39b260$@augustcellars.com> In-Reply-To: <030801ccda62$4ebde620$ec39b260$@augustcellars.com> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane@ietf.org Subject: Re: [dane] New "operational considerations" text (was: Addition to "Security considerations") X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 15:13:48 -0000 On 01/24/2012 07:35 AM, Jim Schaad wrote: >> -----Original Message----- >> From: Ondrej Mikle [mailto:ondrej.mikle@nic.cz] >> Sent: Monday, January 23, 2012 10:07 AM >> To: Jim Schaad >> Cc: dane@ietf.org >> Subject: Re: [dane] New "operational considerations" text (was: Addition > to >> "Security considerations") >> >> CAs frequently issue/reissue certificates with different validity >> period, signature algorithm (updated hash), CA key pair (cross- >> certificate) or extensions (public key, subject remain intact). > > We need to set off the last parenthesis expression since they are not > extensions. Suggest > > ... or extensions where the public key and subject remain the same. Fixed, new wording: CAs frequently issue/reissue certificates with different validity period, signature algorithm (updated hash), CA key pair (cross- certificate) or extensions where the public key and subject remain the same. Those are the certificates TLS client can use in place of an original certificate. >> A.1.2. Discussion on choice of selector type >> >> Definition: "false-negative failure" means that client will not >> accept the TLSA association for certificate designated by DNS >> administrator. > > I don't care for this definition of false-negative failure. It implies that > if the association was actually incorrect then it would still be a false > negative failure. > > I would also want to look at the other side of this. > > Definition: "false-positive acceptance" means that the client accepts a TLSA > association for a certificate not designated by the DNS administrator. > > Is that really what you want to say? Mostly yes. I added "a correct TLSA association" to the false-negative case and added the false-positive definition: Definition: "false-negative failure" means that the client will not accept a correct TLSA association for certificate designated by DNS administrator. Definition: "false-positive acceptance" means that the client accepts a TLSA association for a certificate not designated by the DNS administrator. Full text of section is here (for easier copy&pasting later): https://git.nic.cz/redmine/projects/ietf/repository/revisions/master/entry/draft-ietf-dane-protocol_creating_tlsa_section.txt https://git.nic.cz/redmine/projects/ietf/repository/revisions/master/entry/draft-ietf-dane-protocol_creating_tlsa_section.xml git://git.nic.cz/ietf (whole repository git access) Ondrej Mikle From pieter.lexis@os3.nl Tue Jan 24 07:37:09 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1A3E21F845D for ; Tue, 24 Jan 2012 07:37:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9cR74LFHqwx for ; Tue, 24 Jan 2012 07:37:09 -0800 (PST) Received: from mail.serv.os3.nl (mail.serv.os3.nl [IPv6:2001:610:158:960::25]) by ietfa.amsl.com (Postfix) with ESMTP id D55BD21F845C for ; Tue, 24 Jan 2012 07:37:08 -0800 (PST) Received: from smtp.os3.nl (smtp.os3.nl [IPv6:2001:610:158:960::119]) by mail.serv.os3.nl (Postfix) with ESMTP id 2E14C17AA16; Tue, 24 Jan 2012 16:37:07 +0100 (CET) Received: from [IPv6:2001:610:158:1020:88a8:cf1a:8da1:9845] (unknown [IPv6:2001:610:158:1020:88a8:cf1a:8da1:9845]) by smtp.os3.nl (Postfix) with ESMTPSA id E60F617A9C9; Tue, 24 Jan 2012 16:37:06 +0100 (CET) Message-ID: <4F1ED022.5060704@os3.nl> Date: Tue, 24 Jan 2012 16:37:06 +0100 From: Pieter Lexis User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111109 Thunderbird/3.1.16 MIME-Version: 1.0 To: James Cloos References: <4F1EA468.4030201@os3.nl> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dane@ietf.org Subject: Re: [dane] Announcing the alpha release of swede - A tool to create and verify TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 15:37:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/24/2012 04:01 PM, James Cloos wrote: > I was unable to use swede on my workstation because it started every > lookup at . and must have timed out before drilling down to the TLSA > and A/AAAA RRs. > > I added this to take advantage of the local (unbound) cache: I > haven't tested this with non-unbound resolvers in the resolv.conf, > but unbound itself works when using non-verifying foward-hosts so it Thanks! I'll put it in, the reason I didn't was that (as far as I could see) relied on the AD bit being set in the response. As the resolving also worked when I turned off the local resolver didn't load a resolv.conf. > ought to be OK. :; for p in $(seq 00 17);do dig @localhost +tcp > +short +dnssec _15${p}._tcp.dane.kiev.studlab.os3.nl TYPE65468; done I made a dump typo I make all the time, it's dane.kiev.practicum.os3.nl using that hostname you can verify (studlab is a subdomain for the machines, not to test stuff): dig +tcp +short +dnssec _1516._tcp.dane.kiev.practicum.os3.nl TYPE65468 \# 35 000101DF2D479AC580EEAAACF26940DB1F5D85BD979868F3C89653AC 460C9061551CCE If any one can tell me conclusively about the unbound thing, I'll amend the code, for now I'll make it optional. - -- Pieter Lexis -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPHtAeAAoJELPqGO5ebd4jzYEP/Rh1FxDejItbrYrZXUOlo/lz 11uDq0dC3QXUfXR2He/Bn3fRyJivKIc0ECHwyWvtPJPa6YgstCuuVWWB9NbKEsTU iCfPeTsYOzwDRqrEYk34LuLkzu8oMV0np9B5a9WwqKGabGOIoPHIKkLf8E+RWl4m 0SDrQMWt5LZcg0C2IoCTEeTMHRfKFfpG3ubUU20URlIA8jX91ky7qx/fC5OB2plY wrrsC1cfSl8/YgDII3BWZq3wSrlFYp8baCHNPPO8G0LukfYJJdoF1rXSxW5VxM2t OmBTohgdLt6VEf9sGfjACJVoVZZRkm/XS8AVwT9mub0F8Q93JmP0mOoqwGdc3Nva bWexpSvt0aUkugioGJDa4lMUql3EeQiguNd2bRQys8+u96Ksv7ek2KR33xY7Gjp7 3OoEiAzPEQhUiwDXH0H1VkOMF0bcMat//cpneGDkAXpkukMND9wOi//pbLhXk3nC Q9evP1Z7Q07LLcLXPMeoheMRzMJTYcnGzWrcRnE7ymLpprrZZ06vQrcKvD54fPBv V9dFMAG7r1yJ0HFp56FHfcgPycDrDjy3Q8cEZRwsIbOHizj7OyNiSov4+bV6iqc/ QB5dyVQ4ib513biIG9/13qyG2HoWvl3aOjBxM1pBtOmstqRKgBqGPQS6gwpPaDfq 3P2Wq0JjhxPsVeCn0E97 =G5VT -----END PGP SIGNATURE----- From pieter.lexis@os3.nl Tue Jan 24 08:06:36 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6355321F8639 for ; Tue, 24 Jan 2012 08:06:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3p5EaZc-28z for ; Tue, 24 Jan 2012 08:06:35 -0800 (PST) Received: from mail.serv.os3.nl (mail.serv.os3.nl [IPv6:2001:610:158:960::25]) by ietfa.amsl.com (Postfix) with ESMTP id A60DC21F862F for ; Tue, 24 Jan 2012 08:06:35 -0800 (PST) Received: from smtp.os3.nl (smtp.os3.nl [IPv6:2001:610:158:960::119]) by mail.serv.os3.nl (Postfix) with ESMTP id 10E1217AA2A; Tue, 24 Jan 2012 17:06:35 +0100 (CET) Received: from [IPv6:2001:610:158:1020:88a8:cf1a:8da1:9845] (unknown [IPv6:2001:610:158:1020:88a8:cf1a:8da1:9845]) by smtp.os3.nl (Postfix) with ESMTPSA id 083DA17AA24; Tue, 24 Jan 2012 17:06:35 +0100 (CET) Message-ID: <4F1ED70A.9060901@os3.nl> Date: Tue, 24 Jan 2012 17:06:34 +0100 From: Pieter Lexis User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111109 Thunderbird/3.1.16 MIME-Version: 1.0 To: James Cloos References: <4F1EA468.4030201@os3.nl> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dane@ietf.org Subject: Re: [dane] Announcing the alpha release of swede - A tool to create and verify TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 16:06:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/24/2012 04:01 PM, James Cloos wrote: > I added this to take advantage of the local (unbound) cache: Added it as an option[0], thanks! 0 - https://github.com/pieterlexis/swede/commit/09009d50eff972daf8b995f5d21d8a65a71880d9 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPHtcHAAoJELPqGO5ebd4jwIsP/jT7LItaF83oPDArSdp/GCMr ri1W9S9GE0I/3Phhgy4nK0w1dBbAhjw1Era1fa/TRe6k8Yock3qp9CKLXmKOyQEc lK1HOuRhDIDwrfXijtSu5K/z/4U4Tau6TEbwbx8GEWJABb8O6Uzqx5ZvlcB7r/eA tfHM+7d31N8JmGnu3rCwnNfIE2JUWHgmNrIQIYrpe/5ZX2ij7StUQbymjUwmcuqN /Rw3/ZQSxzpVCLNF4i7MO0I9ojQ4e04BbQqNT9LUYsSLtn4GynXyuo0LmdV6X3hP sgBw//bjtg0EatASceh1BhLpHaSdDzShrXd7JfU/F81ZGthPw1MbMvKpTCkkD0zY fy0mC6OCWQgAONRm8EcTzF8wA1vTM4OkFN/N5E563Bekafwp3boyyKvBdsjVKzfA gh6qwrF99cO80vSmxnGrsxrP/di+eKiMsowG2iyt6i+ML572a+2eIX2haxDdYiAR xn+3OZWko1TpABh0UHYNFQXLhPLTZGWlTeYWrNc5KPy63ouOr2xpg/ub8IOKhHHo pc26w136cko7ZKqWpc8NNkZJ9oBYeKg30zu05vDDXP6lMSH6PPt+6buaj3av6YaS vvGFyt7EW0WtCJP6qr8EvDvEM340Q2qvws+uM+nKGvYz3gFe8GX0AMl72cZIu94w HGXuwbNIephZeYSEnTXv =ntGj -----END PGP SIGNATURE----- From paul.hoffman@vpnc.org Tue Jan 24 09:10:09 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D6C811E8079 for ; Tue, 24 Jan 2012 09:10:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.251 X-Spam-Level: X-Spam-Status: No, score=-102.251 tagged_above=-999 required=5 tests=[AWL=-0.252, BAYES_00=-2.599, J_CHICKENPOX_47=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WpxWDN5u81fa for ; Tue, 24 Jan 2012 09:10:09 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 01BBB11E8076 for ; Tue, 24 Jan 2012 09:09:55 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q0OH9VMX005094 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 24 Jan 2012 10:09:32 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4F1ECA6B.6010609@nic.cz> Date: Tue, 24 Jan 2012 09:09:31 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EEE63EB.9020800@nic.cz> <00ca01ccc5b6$57d79e10$0786da30$@augustcellars.com> <4F1DA1B1.6030404@nic.cz> <030801ccda62$4ebde620$ec39b260$@augustcellars.com> <4F1ECA6B.6010609@nic.cz> To: Ondrej Mikle X-Mailer: Apple Mail (2.1251.1) Cc: dane@ietf.org Subject: Re: [dane] New "operational considerations" text (was: Addition to "Security considerations") X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 17:10:09 -0000 On Jan 24, 2012, at 7:12 AM, Ondrej Mikle wrote: > Fixed, new wording: Note that Jakob and I are not using your wording as-is, but are also = honing the English some as we include it in the document. I have made = the change that Jim proposed in the next draft. >>> A.1.2. Discussion on choice of selector type >>>=20 >>> Definition: "false-negative failure" means that client will not >>> accept the TLSA association for certificate designated by DNS >>> administrator. >>=20 >> I don't care for this definition of false-negative failure. It = implies that >> if the association was actually incorrect then it would still be a = false >> negative failure.=20 >>=20 >> I would also want to look at the other side of this. =20 >>=20 >> Definition: "false-positive acceptance" means that the client accepts = a TLSA >> association for a certificate not designated by the DNS = administrator. >>=20 >> Is that really what you want to say? >=20 > Mostly yes. I added "a correct TLSA association" to the false-negative > case and added the false-positive definition: >=20 > Definition: "false-negative failure" means that the client will not > accept a correct TLSA association for certificate designated by DNS > administrator. >=20 > Definition: "false-positive acceptance" means that the client = accepts > a TLSA association for a certificate not designated by the DNS > administrator. >=20 >=20 > Full text of section is here (for easier copy&pasting later): >=20 > = https://git.nic.cz/redmine/projects/ietf/repository/revisions/master/entry= /draft-ietf-dane-protocol_creating_tlsa_section.txt > = https://git.nic.cz/redmine/projects/ietf/repository/revisions/master/entry= /draft-ietf-dane-protocol_creating_tlsa_section.xml > git://git.nic.cz/ietf (whole repository git access) I'll grab this text and try to work it in. We'll clearly need to spend = more time editing this section after the next draft is out. --Paul Hoffman From paul.hoffman@vpnc.org Tue Jan 24 09:19:32 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F03C211E8088 for ; Tue, 24 Jan 2012 09:19:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8sWQ4QcKltB for ; Tue, 24 Jan 2012 09:19:32 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 768E811E8085 for ; Tue, 24 Jan 2012 09:19:32 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q0OHJUAj005444 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 24 Jan 2012 10:19:31 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <1327388723.3558.73.camel@localhost> Date: Tue, 24 Jan 2012 09:19:30 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201201231921.q0NJLS1i021543@fs4113.wdf.sap.corp> <734367B8-48F9-4D8F-A106-DC744754FB84@vpnc.org> <1327388723.3558.73.camel@localhost> To: Matt McCutchen X-Mailer: Apple Mail (2.1251.1) Cc: IETF DANE WG list Subject: Re: [dane] Opening Issue #37. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 17:19:33 -0000 On Jan 23, 2012, at 11:05 PM, Matt McCutchen wrote: >>>> The draft states: >>>> # 2 -- The target certificate MUST pass PKIX validation, with = any >>>> # certificate matching the TLSA record considered to be a trust >>>> # anchor for this validation >>>=20 > The spec is easily fixed: >=20 > 2 -- The target certificate MUST pass PKIX validation, with any SPKI = of > a certificate matching the TLSA record considered to be a trust anchor > for this validation I think I see where you are going, but I think you might have gotten the = text wrong. Is the following what you meant? 2 -- The target certificate MUST pass PKIX validation, with the SPKI of the TLSA record considered to be a trust anchor for this validation If so, it might satisfy Martin's concern as well. --Paul Hoffman From zack.weinberg@gmail.com Tue Jan 24 09:38:04 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42D9021F84E2 for ; Tue, 24 Jan 2012 09:38:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sGyQvNW1WCY6 for ; Tue, 24 Jan 2012 09:38:03 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0EFE521F84F4 for ; Tue, 24 Jan 2012 09:38:03 -0800 (PST) Received: by obbwc12 with SMTP id wc12so5544481obb.31 for ; Tue, 24 Jan 2012 09:38:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=oAHep1Ahsd7p8Loa7N3UxHuA/bEwRjIK/2GBmAHW0yA=; b=jDzlaBGRH2mp1qfM66ssH44gjUndbyFbvy4vgKuqj+wKZf/YlRabOt6ki8ebHa5RR1 Cw2BJ62GqLmC/lUZMwAvjZIFEtG+PIoXMQcSLu4zh94i1UK8ixx2yrxJ0TgTY7IXlznf PS1OhgiDOzQo0VAXqlGnA9WDx6ECOSB1/Bdys= MIME-Version: 1.0 Received: by 10.182.147.106 with SMTP id tj10mr12694890obb.12.1327426682627; Tue, 24 Jan 2012 09:38:02 -0800 (PST) Sender: zack.weinberg@gmail.com Received: by 10.182.227.69 with HTTP; Tue, 24 Jan 2012 09:38:02 -0800 (PST) In-Reply-To: <38753795-7C00-4DD5-99A0-3CF4ED2B407B@vpnc.org> References: <20120123033124.GD14597@odin.ulthar.us> <201201231921.q0NJLS1i021543@fs4113.wdf.sap.corp> <7769AE22-B0EF-48F2-86E8-AD6977F83124@vpnc.org> <3F134138-06A0-400A-9CA6-5FF55B331D04@vpnc.org> <38753795-7C00-4DD5-99A0-3CF4ED2B407B@vpnc.org> Date: Tue, 24 Jan 2012 09:38:02 -0800 X-Google-Sender-Auth: K4bpWXtBWbFvuqao2CQb1Rwdxdg Message-ID: From: Zack Weinberg To: IETF DANE WG list Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [dane] Opening Issue #37. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 17:38:04 -0000 On Mon, Jan 23, 2012 at 5:25 PM, Paul Hoffman wrote= : > On Jan 23, 2012, at 5:24 PM, Zack Weinberg wrote: >>> Yes: leave the current text as-is. If someone is not going to conform >>> to PKIX today, we are not telling them to do it any differently with DA= NE. >> >> I disagree. =C2=A0The current text is saying you have to conform to RFC >> 5280 if you want to implement DANE. > > Yep, just like RFC 2818 says you have to implement PKIX if you want to im= plement TLS. RFC 2818 [HTTP over TLS] says you have to check the hostname in the URL against the hostname in the end-entity certificate, but says nothing about validation to be performed on the certificate chain itself. Were you possibly thinking of RFC 2246 [TLS 1.0]? This is what that says: # D.3. Certificates and authentication # # Implementations are responsible for verifying the integrity of # certificates and should generally support certificate revocation # messages. Certificates should always be verified to ensure proper # signing by a trusted Certificate Authority (CA). The selection and # addition of trusted CAs should be done very carefully. Users should # be able to view information about the certificate and root CA. I read this as "you are required to validate certificates, but *how* you validate certificates is unspecified." >> That will be taken as an argument >> against implementing DANE by people who think RFC 5280 validation is >> too expensive and/or complicated. > > Errr, how are they doing TLS now without PKIX validation? They use ad-hoc validation algorithms which generally include some subset of the checks defined in RFC 5280 plus possibly other stuff. They claim conformance with TLS 1.0. zw From zack.weinberg@gmail.com Tue Jan 24 09:46:51 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5326921F84CE for ; Tue, 24 Jan 2012 09:46:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ia7PHmBh7R-G for ; Tue, 24 Jan 2012 09:46:50 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id CEF3121F8573 for ; Tue, 24 Jan 2012 09:46:50 -0800 (PST) Received: by obbwc12 with SMTP id wc12so5555580obb.31 for ; Tue, 24 Jan 2012 09:46:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=KVVWjgkJjccCzrJG1jY7LocrFl9OWyUr2CO3NegPi0Y=; b=ROxEfEgWjjsKW0TCGy72vJBwlnnub1Q3X9hler3ID71HvXTQHe4V4kerRf3DoO3hnV 7lPdjMOlOlII6GUKWQF/RabCqxDtLnaXZzJoSvY5wD20clWcWKOC6WOQUnmNlRgfclyi c8OYeCBkhFjlJtMYS7qST09VbaX9lVUgGsiCU= MIME-Version: 1.0 Received: by 10.182.0.106 with SMTP id 10mr12535191obd.72.1327427210502; Tue, 24 Jan 2012 09:46:50 -0800 (PST) Sender: zack.weinberg@gmail.com Received: by 10.182.227.69 with HTTP; Tue, 24 Jan 2012 09:46:50 -0800 (PST) In-Reply-To: <201201240515.q0O5FEM5025321@fs4113.wdf.sap.corp> References: <2B03A335-83DE-425A-9A2E-1BE849FEFBCB@vpnc.org> <201201240515.q0O5FEM5025321@fs4113.wdf.sap.corp> Date: Tue, 24 Jan 2012 09:46:50 -0800 X-Google-Sender-Auth: JmzeyN9gDLHOHYmUtHu6W78UYcM Message-ID: From: Zack Weinberg To: IETF DANE WG list Content-Type: text/plain; charset=UTF-8 Subject: Re: [dane] Opening Issue #37. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 17:46:51 -0000 This argument underlines my contention that DANE should _not_ attempt to define how clients construct or validate the certificate chain. It should be enough to say that the client does _whatever it does now_, and then (for types 0 and 1) applies an additional constraint that a matching certificate must appear at a certain position in the chain, or (for type 2) temporarily considers a matching certificate to be an additional trust anchor. ANY attempt to specify client validation in more detail than "whatever the client would have done in the absence of TLSA information" will require some clients to change how they do path construction or validation when TLSA records are present, and implementors will prefer to ignore DANE if it requires that change. Yes, path construction is nondeterministic and not consistent across clients. DANE should not attempt to fix that en passant; it will only make deployment harder. From mrex@sap.com Tue Jan 24 10:59:59 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB9611F0C3E for ; Tue, 24 Jan 2012 10:59:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.129 X-Spam-Level: X-Spam-Status: No, score=-10.129 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYMDvqXUj1dF for ; Tue, 24 Jan 2012 10:59:59 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id E5B041F0C38 for ; Tue, 24 Jan 2012 10:59:58 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q0OIxvGN028717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 Jan 2012 19:59:57 +0100 (MET) From: Martin Rex Message-Id: <201201241859.q0OIxuGI011754@fs4113.wdf.sap.corp> To: paul.hoffman@vpnc.org (Paul Hoffman) Date: Tue, 24 Jan 2012 19:59:56 +0100 (MET) In-Reply-To: from "Paul Hoffman" at Jan 24, 12 09:19:30 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] Opening Issue #37. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 19:00:00 -0000 Paul Hoffman wrote: > > 2 -- The target certificate MUST pass PKIX validation, with the SPKI of > the TLSA record considered to be a trust anchor > for this validation > > If so, it might satisfy Martin's concern as well. That is only a partial solution. Usage case 2 covers three different variants: (1) Server uses self-signed cert, TLSA identifies self-signed cert (2) Server uses CA-issued cert from private CA, TLSA identifies a CA-certificate from the Server's certifcation path (3) Server uses CA-issued cert from private CA, TLSA identifies the server's CA-issued cert directly Only for (1) and (2) a PKIX (certificate path) validation could be specified, it is *IMPOSSIBLE* to perform a PKIX validation for (3). I would also appreciate if PKIX validation and rfc-2818 server endpoint identification would not be conflated by dane-protocol. rfc-2818 server endpoint identification makes sense for traditional PKIX-based server identification, because this is how the CA asserts for which DNS domain name the server certificate was issued. For DANE, the existence of the TLSA record already provides the binding to the DNS domain name. So this WG is in principle free to specify whether or not the DANE-part of the validation looks at name attributes of the server certificate. But for usage types 0 and 1 a PKIX-based endpoint identification should be performed for consistency with the existing endpoint identification, which narrows this down to usage type 2. doing name matching makes DANE-only scenarios (usage type 2) more difficult to configure (usability), and may require additional TLS features to be available and employed for multihoming and virtual hosting. If name-matching is required for the DANE part as well, then it would later be easier to switch a productive setup from usage type 2 to usage type 0 or 1. An additional check in the DANE-part adds complexity (more code, more cpu cycles) and requires some amount of synchronization between potentially independent software modules (the part that performs server endpoint identification in the PKIX world and the part that performs server endpoint identification in the DANE part). -Martin From paul.hoffman@vpnc.org Tue Jan 24 11:37:43 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BBF521F852B for ; Tue, 24 Jan 2012 11:37:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G43T9gw2aW+F for ; Tue, 24 Jan 2012 11:37:42 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5D45A21F8532 for ; Tue, 24 Jan 2012 11:37:42 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q0OJbeMC010327 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 24 Jan 2012 12:37:40 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <201201241859.q0OIxuGI011754@fs4113.wdf.sap.corp> Date: Tue, 24 Jan 2012 11:37:40 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8D3FC301-99F1-46C8-8275-2C44328CE463@vpnc.org> References: <201201241859.q0OIxuGI011754@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1251.1) Cc: dane@ietf.org Subject: [dane] DANE ad RFC 2818 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 19:37:43 -0000 On Jan 24, 2012, at 10:59 AM, Martin Rex wrote: > I would also appreciate if PKIX validation and rfc-2818 server = endpoint > identification would not be conflated by dane-protocol. >=20 Fully agree. I apologize for doing that the other day. The current spec = only mentions 2818 in passing, not tied to the DANE processing protocol. --Paul Hoffman From paul.hoffman@vpnc.org Tue Jan 24 11:43:33 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEEE821F854E for ; Tue, 24 Jan 2012 11:43:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6TAAuAtbypJ for ; Tue, 24 Jan 2012 11:43:33 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 71F1C21F854C for ; Tue, 24 Jan 2012 11:43:33 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q0OJhW9O010674 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 24 Jan 2012 12:43:32 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <201201241859.q0OIxuGI011754@fs4113.wdf.sap.corp> Date: Tue, 24 Jan 2012 11:43:32 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <0271CAAA-E58C-41EF-9E07-EA7256375B10@vpnc.org> References: <201201241859.q0OIxuGI011754@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1251.1) Cc: dane@ietf.org Subject: [dane] Specifying a new trust anchor X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 19:43:34 -0000 On Jan 24, 2012, at 10:59 AM, Martin Rex wrote: > Paul Hoffman wrote: >>=20 >> 2 -- The target certificate MUST pass PKIX validation, with the SPKI = of >> the TLSA record considered to be a trust anchor >> for this validation >>=20 >> If so, it might satisfy Martin's concern as well. >=20 > That is only a partial solution. >=20 > Usage case 2 covers three different variants: >=20 > (1) Server uses self-signed cert, TLSA identifies self-signed cert >=20 > (2) Server uses CA-issued cert from private CA, TLSA identifies > a CA-certificate from the Server's certifcation path >=20 > (3) Server uses CA-issued cert from private CA, TLSA identifies > the server's CA-issued cert directly >=20 > Only for (1) and (2) a PKIX (certificate path) validation could be > specified, it is *IMPOSSIBLE* to perform a PKIX validation for (3). With the proposed wording above, I agree that #3 would not work. In such = a case, the server would publish a type 0 cert instead. With the current wording in the draft, #3 would work fine if you believe = (as many of us do) that a chain of zero length is fine. Others believe = that a chain of zero length would not be correct PKIX validation, so #1 = would not work, but #2 and #3 would. So, using my propose wording above, you (Martin) still get what you want = as long as the server doesn't do #3 as usage type 2, but instead does it = as usage type 0, yes? --Paul Hoffman From mrex@sap.com Tue Jan 24 13:03:32 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF7C21F852B for ; Tue, 24 Jan 2012 13:03:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.137 X-Spam-Level: X-Spam-Status: No, score=-10.137 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4i6av+vLJVUm for ; Tue, 24 Jan 2012 13:03:29 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id BE37C11E8085 for ; Tue, 24 Jan 2012 13:03:27 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q0OL3PQB006710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 Jan 2012 22:03:25 +0100 (MET) From: Martin Rex Message-Id: <201201242103.q0OL3Ptw018538@fs4113.wdf.sap.corp> To: paul.hoffman@vpnc.org (Paul Hoffman) Date: Tue, 24 Jan 2012 22:03:25 +0100 (MET) In-Reply-To: <0271CAAA-E58C-41EF-9E07-EA7256375B10@vpnc.org> from "Paul Hoffman" at Jan 24, 12 11:43:32 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] Specifying a new trust anchor X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 21:03:32 -0000 Paul Hoffman wrote: > > Martin Rex wrote: > > > Paul Hoffman wrote: > >> > >> 2 -- The target certificate MUST pass PKIX validation, with the SPKI of > >> the TLSA record considered to be a trust anchor > >> for this validation > >> > >> If so, it might satisfy Martin's concern as well. > > > > That is only a partial solution. > > > > Usage case 2 covers three different variants: > > > > (1) Server uses self-signed cert, TLSA identifies self-signed cert > > > > (2) Server uses CA-issued cert from private CA, TLSA identifies > > a CA-certificate from the Server's certifcation path > > > > (3) Server uses CA-issued cert from private CA, TLSA identifies > > the server's CA-issued cert directly > > > > Only for (1) and (2) a PKIX (certificate path) validation could be > > specified, it is *IMPOSSIBLE* to perform a PKIX validation for (3). > > With the proposed wording above, I agree that #3 would not work. > In such a case, the server would publish a type 0 cert instead. > > With the current wording in the draft, #3 would work fine if you believe > (as many of us do) that a chain of zero length is fine. Others believe > that a chain of zero length would not be correct PKIX validation, > so #1 would not work, but #2 and #3 would. > > So, using my propose wording above, you (Martin) still get what you want > as long as the server doesn't do #3 as usage type 2, but instead does > it as usage type 0, yes? I still disagree. I believe we've been around here before ;-) http://www.ietf.org/mail-archive/web/dane/current/msg04160.html Making case #1 work with rfc5280 section 6.1 is easy -- passing the cert in as both, chain and trust anchor (and for the latter only the tbsCertificate part if you want to be anal about that one sentence). But I don't see how you could specify (3) to provide the necessary arguments to the average certificate path validation function and come out with the result "passed PKIX validation". -Martin From mrex@sap.com Tue Jan 24 15:56:21 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED69421F8559 for ; Tue, 24 Jan 2012 15:56:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.14 X-Spam-Level: X-Spam-Status: No, score=-10.14 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sydvP3GCnnlj for ; Tue, 24 Jan 2012 15:56:21 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA3B21F8537 for ; Tue, 24 Jan 2012 15:56:21 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q0ONuEjR020588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Jan 2012 00:56:19 +0100 (MET) From: Martin Rex Message-Id: <201201242356.q0ONuEuX028022@fs4113.wdf.sap.corp> To: ondrej.mikle@nic.cz (Ondrej Mikle) Date: Wed, 25 Jan 2012 00:56:14 +0100 (MET) In-Reply-To: <4F1E00F1.9030008@nic.cz> from "Ondrej Mikle" at Jan 24, 12 01:53:05 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: paul.hoffman@vpnc.org, dane@ietf.org Subject: Re: [dane] Pseudocode review X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 23:56:22 -0000 Ondrej Mikle wrote: > > Wanted: first chain where the expression "TLSA association succeeds && PKIX > validation succeeds" evaluates to true (according to DANE rules). > > Current implementations of PKIX validation (except CryptoAPI) > have only a method like: > > findFirstValidChain(chainFromHandshake, trustAnchors, cachedCerts) returning > CertChain > > In a naive implementation, a developer might be tempted to do: I'm actually heavily opposed to suggesting such convolutions in dane protocol. It perfectly sensible for a TLS client, and conforming to PKIX, to simply ASN.1 decode the well-formed certification path from the Server's certificate message, scan the list of preconfigured trust anchors whether it matches a cert from the server's cert path and then call a certificate path validation algorithm with the server-supplied cert path and the matching trust anchor. I know that there are some TLS clients (mostly browser) doing all kinds of fancy, weird and stupid things before validating the cert chain provided by the server, but that is wasting energy and causing TLS server configuration errors to result in inconsistent, sometimes seemingly non-deterministic failures regularly precluding timely recognition and fix of the server configuration error by the responsible admin. -Martin From i.grok@comcast.net Tue Jan 24 20:35:04 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8F3711E80AE for ; Tue, 24 Jan 2012 20:35:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.362 X-Spam-Level: X-Spam-Status: No, score=-102.362 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RsiM0637aZWo for ; Tue, 24 Jan 2012 20:35:04 -0800 (PST) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by ietfa.amsl.com (Postfix) with ESMTP id 281F111E80A5 for ; Tue, 24 Jan 2012 20:35:04 -0800 (PST) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta07.westchester.pa.mail.comcast.net with comcast id RgFx1i0031ei1Bg57gb44s; Wed, 25 Jan 2012 04:35:04 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta24.westchester.pa.mail.comcast.net with comcast id Rgb41i00W00PQ6U3kgb4vk; Wed, 25 Jan 2012 04:35:04 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.3) with ESMTP id q0P4Z02D031460 for ; Tue, 24 Jan 2012 23:35:00 -0500 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id q0P4YwaN031459 for dane@ietf.org; Tue, 24 Jan 2012 23:34:58 -0500 Date: Tue, 24 Jan 2012 23:34:58 -0500 From: Scott Schmit To: dane@ietf.org Message-ID: <20120125043458.GA20171@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <201201241859.q0OIxuGI011754@fs4113.wdf.sap.corp> <0271CAAA-E58C-41EF-9E07-EA7256375B10@vpnc.org> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="FCuugMFkClbJLl1L" Content-Disposition: inline In-Reply-To: <0271CAAA-E58C-41EF-9E07-EA7256375B10@vpnc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Specifying a new trust anchor X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 04:35:05 -0000 --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 24, 2012 at 11:43:32AM -0800, Paul Hoffman wrote: > On Jan 24, 2012, at 10:59 AM, Martin Rex wrote: > > (3) Server uses CA-issued cert from private CA, TLSA identifies > > the server's CA-issued cert directly > So, using my propose wording above, you (Martin) still get what you > want as long as the server doesn't do #3 as usage type 2, but instead > does it as usage type 0, yes? Actually, usage 0 can't work if the CA is a *private* CA (i.e., not signed by any of the client's TAs). --=20 Scott Schmit --FCuugMFkClbJLl1L Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQJgYJKoZIhvcNAQcCoIIQFzCCEBMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DVcwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBxswggYDoAMCAQICAwK+HTANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTExMDcxNzA1 MDQwNFoXDTEyMDcxNzExNDI1OVowYjEgMB4GA1UEDRMXNDY1MjU2LTBnRmI2Sk5ZWW44QnFW bUwxGzAZBgNVBAMMEmkuZ3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9r QGNvbWNhc3QubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2AjLOMsBGaqN hv2FcRbfom/QCeKMXu5tUd1JY5oIDZe5y29stnd+se/zUlEkiVeMam4Jgo1c8yGNnwLVYc5/ 9xVi7Qg1Is5b9AB6aJWElJDw/jIdihymNZ2kwkSLT0wl/lzd0mXlwFJPRgQiRkmE6V0ZmjsQ jaVtllVleGBbMvmWPm92e+4Bju9P81kKz7Xr02ijETmaPdVsl+jmOaKPS8Y+2Lat2xus4Ked oJ/7aIWIpz1gRSKjAHSZ1Wmwi2TYUjYhZryChu9e1RWtqk1CycNoeusJ8xdEVN3WSnJ299w/ 3ltK/x/9rpj2j9ShQZVB4NnX6cjQs7pz1lVxvIkjcQIDAQABo4IDrTCCA6kwCQYDVR0TBAIw ADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBQ29j2I0O8sRYi0So9NwwmT1caakDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhR gjAdBgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwggIhBgNVHSAEggIYMIICFDCCAhAG CysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJt ZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUF BwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJp bGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFu ZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0 cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQAZ5U0nL/2PQwsVfHgN7MVPbZEGzDzuj4Oy pTgz4XQFwPcCuy6U9sp1Dwmo3DyKX5nKN4xA7pslN+2Pl/kElGamX7zMCAH0xED0RTOLyk+v nDML4s+OUtWaYVnq1bZEp0F8Luq3zIslAYSebleyiz8M0EypZczsL5rOk86R2F9EYw1CBuFJ 5a4x0CmNu5o30fGNDFt+iXRlbJPp/KY25iUgVnBzJ4COT5kQjxn5lgr4t1I+BDCL5HQQ3h/8 2CzwrWVRBNb9Vqh9LL1ZtzYRt8JezoB6HkVvcKVNGlCZ+/MnvfMzPLwfbTDZC8o4d+4RH6aE LeGF2XmAOaenc/YRqm9oMYIClzCCApMCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQIDAr4dMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTIwMTI1MDQzNDU4WjAjBgkqhkiG9w0BCQQxFgQUGwvan54F R4G72qb8jzxlLC9Bb5oweQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAgt9aN4ng F7fPAvqNyOletqjYk9X//avLa4NeGcDBzZxVZn9z7KY9lXK6AAKj0pvJtZjhNIR1LOAjI+fP BQcSEI71QhmawQRzJrnw9tj95Gc6pAOO6Bh97Y25NdvzoHIZLEzZai+fCbjHXfGCZGX6ld6B Z6i9xYLWdPIoOeYfGI3KTTtTU/rA2V8Ax2GZvWaUf904Ana3AaAdxsoLshMezJLXdOD7bzk8 4I0kYatofqpU5hfACTgEX8SDwSKLpB+p4eJ0B2yTPS5GKM2YuuMbkUphZJlJVgSNAsnXlFNB 3diwYoXs1MlZTCZcrl2qb9kGoHn8jSaUmzUyVZZ6xUy+Eg== --FCuugMFkClbJLl1L-- From matt@mattmccutchen.net Tue Jan 24 21:40:09 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C07511E80BD for ; Tue, 24 Jan 2012 21:40:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LADxpW8Aw32u for ; Tue, 24 Jan 2012 21:40:07 -0800 (PST) Received: from homiemail-a3.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id DFFFB11E80BB for ; Tue, 24 Jan 2012 21:40:07 -0800 (PST) Received: from homiemail-a3.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a3.g.dreamhost.com (Postfix) with ESMTP id 0E09F28406E; Tue, 24 Jan 2012 21:40:06 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=message-id :subject:from:to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:mime-version; q=dns; s= mattmccutchen.net; b=E57XqPeKEIEz+MKUrO4+z5P9djMhnO5AnGAwImXUAK+ SVa2i0pPETJgL7DgTnO+yW3zg5L7/U64jrPVFFkNFtkMBczgT3PW6zCyOwrzEV7a CUX11X9xrzy/+DScfn4XL+AhfirgukUtaLVJ+Jf5+1ZrmgeAUH82LC3Tqd/GGvqc = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= message-id:subject:from:to:cc:date:in-reply-to:references :content-type:content-transfer-encoding:mime-version; s= mattmccutchen.net; bh=bPsgr8chpeXDOpSW2a0DAdIDemw=; b=TC+1fvFV7i T7Sn/7zyjtueaIzXSCGk2XstM7/mtTf3JaLZ6fQsD+yPyvTkCvieFZf9zv2aGtp+ mm+HqJm/5gLX08v57DEmBOEIFB7E8a2OmA96IvBelIBLzzkRys2k6NqBY3gtTtPx gWhWlLT7aZJhHecwxf8nxQR/gOqxWWjRk= Received: from [IPv6:::1] (c-98-248-34-40.hsd1.ca.comcast.net [98.248.34.40]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a3.g.dreamhost.com (Postfix) with ESMTPSA id BFD2F28406A; Tue, 24 Jan 2012 21:40:05 -0800 (PST) Message-ID: <1327470004.3558.76.camel@localhost> From: Matt McCutchen To: Paul Hoffman Date: Tue, 24 Jan 2012 21:40:04 -0800 In-Reply-To: References: <201201231921.q0NJLS1i021543@fs4113.wdf.sap.corp> <734367B8-48F9-4D8F-A106-DC744754FB84@vpnc.org> <1327388723.3558.73.camel@localhost> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Cc: IETF DANE WG list Subject: Re: [dane] Opening Issue #37. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 05:40:09 -0000 On Tue, 2012-01-24 at 09:19 -0800, Paul Hoffman wrote: > On Jan 23, 2012, at 11:05 PM, Matt McCutchen wrote: > > >>>> The draft states: > >>>> # 2 -- The target certificate MUST pass PKIX validation, with any > >>>> # certificate matching the TLSA record considered to be a trust > >>>> # anchor for this validation > >>> > > The spec is easily fixed: > > > > 2 -- The target certificate MUST pass PKIX validation, with any SPKI of > > a certificate matching the TLSA record considered to be a trust anchor > > for this validation > > I think I see where you are going, but I think you might have gotten the text wrong. Is the following what you meant? > > 2 -- The target certificate MUST pass PKIX validation, with the SPKI of > the TLSA record considered to be a trust anchor > for this validation No: if the TLSA record has matching type other than 0, "the SPKI of the TLSA record" doesn't mean much. > If so, it might satisfy Martin's concern as well. This difference does not affect Martin's concern, which is about whether PKIX validation succeeds after the intended key is set as a trust anchor. -- Matt From matt@mattmccutchen.net Tue Jan 24 21:56:44 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5118A21F8523 for ; Tue, 24 Jan 2012 21:56:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0zItTutEy2E for ; Tue, 24 Jan 2012 21:56:43 -0800 (PST) Received: from homiemail-a62.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 557C421F8501 for ; Tue, 24 Jan 2012 21:56:42 -0800 (PST) Received: from homiemail-a62.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTP id 332E0634073; Tue, 24 Jan 2012 21:56:42 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=message-id :subject:from:to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:mime-version; q=dns; s= mattmccutchen.net; b=SdALDeQEvLHhTgl6NPRNeq2bWoYC2+a3YVVHAfHUNdV APpfYHh1Y6diS3IIKABiSAh4hTnosBVQ0Of6flwBaXyvxcrB8Ik3e7cpL58PJyGV ZfwQh2NvbD7iEZMfona89WAe6ocGBi6GrwOftwvk2Lp4IgP9m6FlrIWwRTY8DKV8 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= message-id:subject:from:to:cc:date:in-reply-to:references :content-type:content-transfer-encoding:mime-version; s= mattmccutchen.net; bh=AI0O1uY6achSxxLkuSBfv/gijdw=; b=SHT5BxDuvA Uugqgra2WNcccWaHOMxhTgQFfABgEz7or89KZrnjLJAuGOat+1CBI83I9qaWMRan eT9VWwQ2Qj1eA+lkEBiwBtPGhRyvRyzb658KxW/ERmMZWlbhiowTTJZca9YBfquC i/NymSyCG1+TjE9vrqUdgbIx8NfS5cp94= Received: from [IPv6:::1] (c-98-248-34-40.hsd1.ca.comcast.net [98.248.34.40]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTPSA id 0730563406F; Tue, 24 Jan 2012 21:56:41 -0800 (PST) Message-ID: <1327471001.3558.87.camel@localhost> From: Matt McCutchen To: Paul Hoffman Date: Tue, 24 Jan 2012 21:56:41 -0800 In-Reply-To: <0271CAAA-E58C-41EF-9E07-EA7256375B10@vpnc.org> References: <201201241859.q0OIxuGI011754@fs4113.wdf.sap.corp> <0271CAAA-E58C-41EF-9E07-EA7256375B10@vpnc.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Cc: dane@ietf.org Subject: Re: [dane] Specifying a new trust anchor X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 05:56:44 -0000 On Tue, 2012-01-24 at 11:43 -0800, Paul Hoffman wrote: > On Jan 24, 2012, at 10:59 AM, Martin Rex wrote: > > > Paul Hoffman wrote: > >> > >> 2 -- The target certificate MUST pass PKIX validation, with the SPKI of > >> the TLSA record considered to be a trust anchor > >> for this validation > >> > >> If so, it might satisfy Martin's concern as well. > > > > That is only a partial solution. > > > > Usage case 2 covers three different variants: > > > > (1) Server uses self-signed cert, TLSA identifies self-signed cert > > > > (2) Server uses CA-issued cert from private CA, TLSA identifies > > a CA-certificate from the Server's certifcation path > > > > (3) Server uses CA-issued cert from private CA, TLSA identifies > > the server's CA-issued cert directly > > > > Only for (1) and (2) a PKIX (certificate path) validation could be > > specified, it is *IMPOSSIBLE* to perform a PKIX validation for (3). > > With the proposed wording above, I agree that #3 would not work. In such a case, the server would publish a type 0 cert instead. > > With the current wording in the draft, #3 would work fine if you > believe (as many of us do) that a chain of zero length is fine. What? You yourself pointed out (https://www.ietf.org/mail-archive/web/dane/current/msg04148.html) that trust anchors are keys, not certificates. Hence, the meaning of the current wording is not well defined, and your wording above (or mine; it doesn't matter in this context) is the nearest possible correction. So I don't see how you can derive a definite outcome for the current wording that differs from the outcome for your wording at the top. > Others believe that a chain of zero length would not be correct PKIX > validation, so #1 would not work, but #2 and #3 would. How did you come to this conclusion? Letting C be the server cert and K be its SPKI, in #1, there is (arguably) a valid chain of length 1 from C to K, while in #3, there is only the zero-length chain consisting of K. So if anything, #1 is in better shape than #3. -- Matt From matt@mattmccutchen.net Tue Jan 24 22:50:39 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFE621F865C for ; Tue, 24 Jan 2012 22:50:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bo6JXro87EMr for ; Tue, 24 Jan 2012 22:50:38 -0800 (PST) Received: from homiemail-a7.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 95C5C21F8659 for ; Tue, 24 Jan 2012 22:50:38 -0800 (PST) Received: from homiemail-a7.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a7.g.dreamhost.com (Postfix) with ESMTP id 400C025C06D; Tue, 24 Jan 2012 22:50:38 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=message-id :subject:from:to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:mime-version; q=dns; s= mattmccutchen.net; b=pYFksCq0YiqerACZedJVeho8YOwT/kjJ3DZEXytnL+f FhLJFlzYKPK6fS1Orv4byS/HTKLiU9yZKfbnXh1T9/rbxa+wxKCWkph9GNfFwExa aH3jskmqNnm0lkjlBCt2TZcNTLl5qb14DajqDNA/d0ev6RS8aHf4vcRVjDzkNcG0 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= message-id:subject:from:to:cc:date:in-reply-to:references :content-type:content-transfer-encoding:mime-version; s= mattmccutchen.net; bh=cQ8XbOVS7eeNR6jit59IJIqUAYM=; b=gINeBIGgh8 cpnwv/c1xofh3o9E/VLXsoo7KAl7HbrhHmsaQOqkLyRb28kmhvGCefYgPfUYd0HE i0h5dc6jhM8h2pAI5xNyUmiqLhxjCKHthrZgcfgLR/1mQd4G06Ba9OXFoxO2BsSN RBq+QQls/7g7QvBxTjtNvdYxF1sSaWnVY= Received: from [IPv6:::1] (c-98-248-34-40.hsd1.ca.comcast.net [98.248.34.40]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a7.g.dreamhost.com (Postfix) with ESMTPSA id 08D7425C06B; Tue, 24 Jan 2012 22:50:37 -0800 (PST) Message-ID: <1327474236.3558.109.camel@localhost> From: Matt McCutchen To: Paul Hoffman Date: Tue, 24 Jan 2012 22:50:36 -0800 In-Reply-To: <0271CAAA-E58C-41EF-9E07-EA7256375B10@vpnc.org> References: <201201241859.q0OIxuGI011754@fs4113.wdf.sap.corp> <0271CAAA-E58C-41EF-9E07-EA7256375B10@vpnc.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Cc: dane@ietf.org Subject: Re: [dane] Specifying a new trust anchor X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 06:50:39 -0000 On Tue, 2012-01-24 at 11:43 -0800, Paul Hoffman wrote: > On Jan 24, 2012, at 10:59 AM, Martin Rex wrote: > > Usage case 2 covers three different variants: > > > > (1) Server uses self-signed cert, TLSA identifies self-signed cert > > > > (2) Server uses CA-issued cert from private CA, TLSA identifies > > a CA-certificate from the Server's certifcation path > > > > (3) Server uses CA-issued cert from private CA, TLSA identifies > > the server's CA-issued cert directly > > > > Only for (1) and (2) a PKIX (certificate path) validation could be > > specified, it is *IMPOSSIBLE* to perform a PKIX validation for (3). > > With the proposed wording above, I agree that #3 would not work. In such a case, the server would publish a type 0 cert instead. > > With the current wording in the draft, #3 would work fine if you believe (as many of us do) that a chain of zero length is fine. So, I looked in RFC 5280, and a path of zero length is not valid. Section 6 states: "Valid paths begin with certificates issued by a trust anchor." A path that contains no certificates at all does not begin with a certificate issued by a trust anchor, hence it is not valid. I hope this settles the matter. -- Matt From pieter.lexis@os3.nl Wed Jan 25 02:49:25 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C98021F8679 for ; Wed, 25 Jan 2012 02:49:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f67Ma+Yrh3-H for ; Wed, 25 Jan 2012 02:49:23 -0800 (PST) Received: from mail.serv.os3.nl (mail.serv.os3.nl [IPv6:2001:610:158:960::25]) by ietfa.amsl.com (Postfix) with ESMTP id C828A21F8671 for ; Wed, 25 Jan 2012 02:49:22 -0800 (PST) Received: from smtp.os3.nl (smtp.os3.nl [IPv6:2001:610:158:960::119]) by mail.serv.os3.nl (Postfix) with ESMTP id E247E17AA23 for ; Wed, 25 Jan 2012 11:49:20 +0100 (CET) Received: from [IPv6:2001:610:158:1020:1497:4368:f36e:a581] (unknown [IPv6:2001:610:158:1020:1497:4368:f36e:a581]) by smtp.os3.nl (Postfix) with ESMTPSA id A824B17AA16 for ; Wed, 25 Jan 2012 11:49:20 +0100 (CET) Message-ID: <4F1FDE30.40902@os3.nl> Date: Wed, 25 Jan 2012 11:49:20 +0100 From: Pieter Lexis User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111109 Thunderbird/3.1.16 MIME-Version: 1.0 To: dane@ietf.org References: <2B03A335-83DE-425A-9A2E-1BE849FEFBCB@vpnc.org> <201201240515.q0O5FEM5025321@fs4113.wdf.sap.corp> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dane] Opening Issue #37. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 10:49:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Disclaimer: I'm no PKIX/X509 expert. On 01/24/2012 06:46 PM, Zack Weinberg wrote: > This argument underlines my contention that DANE should _not_ attempt > to define how clients construct or validate the certificate chain. I agree with Zack here, I believe this is out of scope for the DANE WG and attempting to specify this will hamper DANE deployment in the real world. > It should be enough to say that the client does _whatever it does > now_, and then (for types 0 and 1) applies an additional constraint > that a matching certificate must appear at a certain position in the > chain, or (for type 2) temporarily considers a matching certificate to > be an additional trust anchor. +1, this is the definition I used when creating 'swede' as it feels the most logical thing to do. Usage 0 and 1 'just' add a fairly easy additional constraint to the status quo (the CA or EE cert must match and chain to an accepted CA cert in the end-application certificate store). Whereas usage 2, in my opinion, can be described as (non-ietf text up ahead) 'If the EE cert matches the TLSA record or if it chains to a certificate that matches the TLSA record, accept it without consulting the local certificate store'. This assumes the certificates in the (eventual) certificate-chain are valid (except for them not being in the local certificate store). If these (perhaps over-simplified) definitions are used, in my opinion there is no big hurdle for TLS implementations to (correctly) implement DANE, which in turn will make server-operators more likely to start offering TLSA records for their services (because there is no chicken-and-egg problem). Just my 2 cents. - -- Pieter Lexis -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPH94sAAoJELPqGO5ebd4jXxQQAIooEvfqEtffp50HnnYEyE2T ZD9D6c2wrpHEoTKEhc2tXDXL+q8x/vh5n5YDai9S9rdlIG92S/a3WB3CggywmdYA EsrDgQ85+LMyy6WSQzxseAEyBJhSN47skdXWaJQqNSYaX/WKIS2Fg7UnpRSrw7Hs z5R9w695iN3EnY/GyAJLscE0bgkCHwzXqrvLQPKZZtTuO1wktf9tqrwSeOAVpJqw p1BtimBs0475T9aXG6FhOvoLn0psdHXM0v5TZ5BOnvx0elmy7piADK3E5GwKkz9j DtFSBGcX0dXZGeRMBgoXdAP24zJwEB/aXWjbSuYcWMP0yYIORcCN/VDjQcxET1tt zJb+bJgrydHMUN72mG5TPgngoTSn3d0EIUohTUHxBFKF1+CWcSwnnOaNy0dwlksj PTw4hD2L42pATqgjRyKYXtxOOH97Gj2kX6hDEYE/FWek+vITS+/TbtsPAI/Jw2sO 5XrCoMukTPbjVuecXxzILZNCM2mce7BpuxNGR8pILI4FNMeRocQeVSQb/Yrn0eVW k1DY0g4tAwKl42A8F6TBM1vpftAEjOOK7o8aaQXBsshrdsXm/XykjOSG5jlQITeJ fmvXJb184205LVUWCifEFGDp3GIgWv1AbiDMYtfzB7gT/ojlmHrnW6NAVrLJ43rb 5KjqDM8B3l9v5Fj0/yE1 =zCwR -----END PGP SIGNATURE----- From ondrej.mikle@nic.cz Wed Jan 25 05:21:13 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0539D21F86BA for ; Wed, 25 Jan 2012 05:21:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5NsEJl80OJp for ; Wed, 25 Jan 2012 05:21:12 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 23D0021F86B9 for ; Wed, 25 Jan 2012 05:21:11 -0800 (PST) Received: from [IPv6:2001:1488:ac14:1400:222:64ff:fe2f:75c2] (unknown [IPv6:2001:1488:ac14:1400:222:64ff:fe2f:75c2]) by mail.nic.cz (Postfix) with ESMTPSA id 4957A2A3005; Wed, 25 Jan 2012 14:21:01 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1327497661; bh=3j5ZOTE3fMuxa43AW6AMP1M2rSaueNqieLb6utPit5M=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=CvOpd5T/wQ/waIQQ9ES9PXfiBACNnvTG7GcXhlF7ITsBfog3U8OKjxmhQVG3gK6Kc owb/rz7FQYGhTCdUOEn507BZjlhsr/F2SN+pfcTiRDolGnI4XIXz8VsCcFFRrzIYHG jkQf7kNM0fdiYOWKUZaq4p3Ezi5lXY3xcZuXKnMA= Message-ID: <4F20017E.8050105@nic.cz> Date: Wed, 25 Jan 2012 14:19:58 +0100 From: Ondrej Mikle User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: mrex@sap.com References: <201201242356.q0ONuEuX028022@fs4113.wdf.sap.corp> In-Reply-To: <201201242356.q0ONuEuX028022@fs4113.wdf.sap.corp> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: paul.hoffman@vpnc.org, dane@ietf.org Subject: Re: [dane] Pseudocode review X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 13:21:13 -0000 On 01/25/2012 12:56 AM, Martin Rex wrote: > Ondrej Mikle wrote: >> >> Wanted: first chain where the expression "TLSA association succeeds && PKIX >> validation succeeds" evaluates to true (according to DANE rules). >> >> Current implementations of PKIX validation (except CryptoAPI) >> have only a method like: >> >> findFirstValidChain(chainFromHandshake, trustAnchors, cachedCerts) returning >> CertChain >> >> In a naive implementation, a developer might be tempted to do: > > I'm actually heavily opposed to suggesting such convolutions > in dane protocol. > > It perfectly sensible for a TLS client, and conforming to PKIX, > to simply ASN.1 decode the well-formed certification path from > the Server's certificate message, scan the list of preconfigured > trust anchors whether it matches a cert from the server's cert path > and then call a certificate path validation algorithm with the > server-supplied cert path and the matching trust anchor. > > I know that there are some TLS clients (mostly browser) doing > all kinds of fancy, weird and stupid things before validating > the cert chain provided by the server, but that is wasting energy > and causing TLS server configuration errors to result in > inconsistent, sometimes seemingly non-deterministic failures > regularly precluding timely recognition and fix of the server > configuration error by the responsible admin. +1. I don't favor the way browsers employ "all kinds of fancy, weird and stupid things before validating" either. Attempt to hide server errors was a stupid marketing push ("because browser XY doesn't show error and we don't want users to go away"). But reverting to previous behavior may be a hard task. Ondrej Mikle From i.grok@comcast.net Wed Jan 25 06:01:31 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A126321F86CB for ; Wed, 25 Jan 2012 06:01:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.378 X-Spam-Level: X-Spam-Status: No, score=-102.378 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2tyjXhVNRSn for ; Wed, 25 Jan 2012 06:01:31 -0800 (PST) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by ietfa.amsl.com (Postfix) with ESMTP id 21C1521F86C8 for ; Wed, 25 Jan 2012 06:01:31 -0800 (PST) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta02.emeryville.ca.mail.comcast.net with comcast id Rp6M1i0011Y3wxoA2q1W0b; Wed, 25 Jan 2012 14:01:30 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta15.emeryville.ca.mail.comcast.net with comcast id Rq1V1i00u00PQ6U8bq1WGH; Wed, 25 Jan 2012 14:01:30 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.3) with ESMTP id q0PE1Qol002446 for ; Wed, 25 Jan 2012 09:01:26 -0500 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id q0PE1QtS002445 for dane@ietf.org; Wed, 25 Jan 2012 09:01:26 -0500 Date: Wed, 25 Jan 2012 09:01:26 -0500 From: Scott Schmit To: dane@ietf.org Message-ID: <20120125140126.GB31796@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <201201242356.q0ONuEuX028022@fs4113.wdf.sap.corp> <4F20017E.8050105@nic.cz> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="H1spWtNR+x+ondvy" Content-Disposition: inline In-Reply-To: <4F20017E.8050105@nic.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Pseudocode review X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 14:01:31 -0000 --H1spWtNR+x+ondvy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 25, 2012 at 02:19:58PM +0100, Ondrej Mikle wrote: > On 01/25/2012 12:56 AM, Martin Rex wrote: > > I'm actually heavily opposed to suggesting such convolutions > > in dane protocol. > >=20 > > It perfectly sensible for a TLS client, and conforming to PKIX, > > to simply ASN.1 decode the well-formed certification path from > > the Server's certificate message, scan the list of preconfigured > > trust anchors whether it matches a cert from the server's cert path > > and then call a certificate path validation algorithm with the > > server-supplied cert path and the matching trust anchor. > >=20 > > I know that there are some TLS clients (mostly browser) doing > > all kinds of fancy, weird and stupid things before validating > > the cert chain provided by the server, but that is wasting energy > > and causing TLS server configuration errors to result in > > inconsistent, sometimes seemingly non-deterministic failures > > regularly precluding timely recognition and fix of the server > > configuration error by the responsible admin. >=20 > +1. I don't favor the way browsers employ "all kinds of fancy, weird and > stupid things before validating" either. Attempt to hide server errors > was a stupid marketing push ("because browser XY doesn't show error and > we don't want users to go away"). But reverting to previous behavior may > be a hard task. +1 I'd almost be in favor of tilting the spec in favor of "if you don't reconfigure your server to include just the certs you want checked, it's not allowed to work. It's not that hard to do it right, it won't break anything for non-DANE clients, so turn away from the dark side!" --=20 Scott Schmit --H1spWtNR+x+ondvy Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQJgYJKoZIhvcNAQcCoIIQFzCCEBMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DVcwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBxswggYDoAMCAQICAwK+HTANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTExMDcxNzA1 MDQwNFoXDTEyMDcxNzExNDI1OVowYjEgMB4GA1UEDRMXNDY1MjU2LTBnRmI2Sk5ZWW44QnFW bUwxGzAZBgNVBAMMEmkuZ3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9r QGNvbWNhc3QubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2AjLOMsBGaqN hv2FcRbfom/QCeKMXu5tUd1JY5oIDZe5y29stnd+se/zUlEkiVeMam4Jgo1c8yGNnwLVYc5/ 9xVi7Qg1Is5b9AB6aJWElJDw/jIdihymNZ2kwkSLT0wl/lzd0mXlwFJPRgQiRkmE6V0ZmjsQ jaVtllVleGBbMvmWPm92e+4Bju9P81kKz7Xr02ijETmaPdVsl+jmOaKPS8Y+2Lat2xus4Ked oJ/7aIWIpz1gRSKjAHSZ1Wmwi2TYUjYhZryChu9e1RWtqk1CycNoeusJ8xdEVN3WSnJ299w/ 3ltK/x/9rpj2j9ShQZVB4NnX6cjQs7pz1lVxvIkjcQIDAQABo4IDrTCCA6kwCQYDVR0TBAIw ADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBQ29j2I0O8sRYi0So9NwwmT1caakDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhR gjAdBgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwggIhBgNVHSAEggIYMIICFDCCAhAG CysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJt ZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUF BwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJp bGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFu ZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0 cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQAZ5U0nL/2PQwsVfHgN7MVPbZEGzDzuj4Oy pTgz4XQFwPcCuy6U9sp1Dwmo3DyKX5nKN4xA7pslN+2Pl/kElGamX7zMCAH0xED0RTOLyk+v nDML4s+OUtWaYVnq1bZEp0F8Luq3zIslAYSebleyiz8M0EypZczsL5rOk86R2F9EYw1CBuFJ 5a4x0CmNu5o30fGNDFt+iXRlbJPp/KY25iUgVnBzJ4COT5kQjxn5lgr4t1I+BDCL5HQQ3h/8 2CzwrWVRBNb9Vqh9LL1ZtzYRt8JezoB6HkVvcKVNGlCZ+/MnvfMzPLwfbTDZC8o4d+4RH6aE LeGF2XmAOaenc/YRqm9oMYIClzCCApMCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQIDAr4dMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTIwMTI1MTQwMTI2WjAjBgkqhkiG9w0BCQQxFgQUjOqWT6CN AU3Wt8PpTkY7Bc23viwweQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAE/DCMf+H MyBvOY6lJRhagRlCGE02z+/poB6YR2mRYbG4DDX7iezBHt3GzllHOCKAcGMOpB61so3amHWm DRf3pvIn4D0/r+0XSBWAc4ECb3qnH/vDfrgIn+wIxyVqUS6EBFE1yXlt+41bzaKF5l0Kyokk E9RA7euokq9pCiuVf3Vnq7hg1IAMleEJTJuHznPtKmxZGpaPtoZYdyG7vQRaQKBYd20w+g72 mbsXst0qm2j7hekRbY/DPQSieekhrdLKjHi19abA8a7VMjDV/TclbkkhndVFF5fUuHkLBE7m L0WOBIQX9Vlbw1wXbezeVsarO+29N5e0h51j84rKDliu7Q== --H1spWtNR+x+ondvy-- From pieter.lexis@os3.nl Wed Jan 25 12:56:45 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70BD011E80C4 for ; Wed, 25 Jan 2012 12:56:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWwytFZbv+eW for ; Wed, 25 Jan 2012 12:56:44 -0800 (PST) Received: from mail.serv.os3.nl (mail.serv.os3.nl [IPv6:2001:610:158:960::25]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB6211E80BE for ; Wed, 25 Jan 2012 12:56:39 -0800 (PST) Received: from smtp.os3.nl (smtp.os3.nl [IPv6:2001:610:158:960::119]) by mail.serv.os3.nl (Postfix) with ESMTP id 0045017AA23 for ; Wed, 25 Jan 2012 21:56:37 +0100 (CET) Received: from [IPv6:2001:980:5dd1:1:8505:7a19:cf1e:33a6] (unknown [IPv6:2001:980:5dd1:1:8505:7a19:cf1e:33a6]) by smtp.os3.nl (Postfix) with ESMTPSA id 9887917AA16 for ; Wed, 25 Jan 2012 21:56:37 +0100 (CET) Message-ID: <4F206C84.9040104@os3.nl> Date: Wed, 25 Jan 2012 21:56:36 +0100 From: Pieter Lexis User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111109 Thunderbird/3.1.16 MIME-Version: 1.0 To: dane@ietf.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dane] Impossible situation in the last example of section A.2.1.1. (draft 14) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 20:56:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I just noticed that the last example in section A.2.1.1. describes an impossible situation, I'll show the example and explain after that: sub5.example.com. IN CNAME sub6.example.com. _443._tcp.sub5.example.com. IN TLSA 1 1 1 308202c5308201ab... sub6.example.com. IN A 10.0.0.0 _443._tcp.sub6.example.com. IN TLSA 1 1 1 ac49d9ba4570ac49... Both TLSA record contain the SHA-256 hash of public key (Selector 1) of the end-entity certificate and they are different. This is impossible, as they describe the _exact_ same thing in the same way. If you connect to port 443 on both sub5 and sub6 you will get the same certificate from the webserver (because sub5 CNAME sub6) and therefore one of those connections will be terminated by the TLS stack because the TLSA doesn't match. A proper example could be: sub5.example.com. IN CNAME sub6.example.com. _443._tcp.sub5.example.com. IN TLSA 0 1 1 308202c5308201ab... sub6.example.com. IN A 10.0.0.0 _443._tcp.sub6.example.com. IN TLSA 1 1 1 ac49d9ba4570ac49... Changing the usage (or the selector, or the matching type) field will fix this fault. - -- Pieter Lexis -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPIGyAAAoJELPqGO5ebd4jW8QQAKTQ1ODiRM0mLlHXwwZDSkmN 9Doe8gaPLZOtoHevLirzdgBJBpkd/9fRSos6alRR4ag4ldCfUybD00K7olm/1mKX jNvb+7T2tXXEPfJGWDQvyNhQE/gJGRA5KE+ZGrSToaC8as6PK5tCQ/nYErSVeuy9 4CsX6bGogC8uq6w1mQ0dEzuz/t16NcC/5vRIImoie9tmVK4IWxwA8ennIYlqBC+m Is2Mya6KzYTujvOKFtuaWcpi7xI15G6sbAayD+tDbyzA5UKRtRmCvwe0MgHdeF4k UCPSTFl+cIr2zGVNoOCsg72M6bNN1pYt+3fPjKM15WvSv+TAXHjRRPqxNvOqSXgZ D05vzDYhXir4XzkyOHUmDLH+3f3hP1ycBjtVtm8YdNGLvnsHM3a9/7bkvXMnY4oD 2wk8eD2/Asu0AB/E4Cfwm1DGw28mgNZtlm7CAYFQtwlP2R+b8lqyDxQd753sF5G9 oKNuzOb1jjXhkm55wWPKpnvKtZR4SNpt2C7FfsL2tpZTB2D+hO1WG88B8Ns67Pf/ WYxaXNglnWeDcR1lHKql0JdagBWK5VyP+mNi1/YXMc1KXDIw53jaQCb+/atb8Ndg n5qbdedDimuFWgmWR/BgrjzBGUKar9G+Jfku2HGeHdv3cJm7rLJajC8KSBiaRSLG fB/9amh1+w/2IsTGgnIi =XVvc -----END PGP SIGNATURE----- From jakob@kirei.se Wed Jan 25 13:01:38 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15FC811E80D1 for ; Wed, 25 Jan 2012 13:01:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1esA-eCjjagJ for ; Wed, 25 Jan 2012 13:01:37 -0800 (PST) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id BEFD711E80B9 for ; Wed, 25 Jan 2012 13:01:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=iTTqjBHoo1X4if9up4OjW1WGf5kJQDAmdGqqFsHiT+c=; b=I/TZ5RRJGRoP/Y4q3v3zHBdNd9oVVs0uRfsXKXxCehKlktkheRZH04TrHrT9PYUqqEK1mzpFyVctA kXSbke+Ht26dNfjzwhkqSNl1YiyyZqQ2VPj2yox3+h4m/H5ZW8ckoEO7cicswgV4ULvU/wcfEzR+R1 BTLdDME96itc0fKM= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Wed, 25 Jan 2012 22:01:34 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: <4F206C84.9040104@os3.nl> Date: Wed, 25 Jan 2012 22:01:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <05552873-5AB8-428B-8809-75F156A7E5E5@kirei.se> References: <4F206C84.9040104@os3.nl> To: Pieter Lexis X-Mailer: Apple Mail (2.1251.1) Cc: dane@ietf.org Subject: Re: [dane] Impossible situation in the last example of section A.2.1.1. (draft 14) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 21:01:38 -0000 On 25 jan 2012, at 21:56, Pieter Lexis wrote: > If you connect to port 443 on both sub5 and sub6 you will get the same > certificate from the webserver (because sub5 CNAME sub6) and therefore > one of those connections will be terminated by the TLS stack because = the > TLSA doesn't match. SNI (Server Name Identification, RFC 4366) allows you to present = different certificates based on the virtual host. jakob From mrex@sap.com Wed Jan 25 13:06:15 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A125F21F85FB for ; Wed, 25 Jan 2012 13:06:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.149 X-Spam-Level: X-Spam-Status: No, score=-10.149 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8KGRkRYK33fF for ; Wed, 25 Jan 2012 13:06:15 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id E372421F85F0 for ; Wed, 25 Jan 2012 13:06:14 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q0PL6Db8012315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Jan 2012 22:06:13 +0100 (MET) From: Martin Rex Message-Id: <201201252106.q0PL6Ct0009745@fs4113.wdf.sap.corp> To: pieter.lexis@os3.nl (Pieter Lexis) Date: Wed, 25 Jan 2012 22:06:12 +0100 (MET) In-Reply-To: <4F206C84.9040104@os3.nl> from "Pieter Lexis" at Jan 25, 12 09:56:36 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] Impossible situation in the last example of section A.2.1.1. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 21:06:15 -0000 Pieter Lexis wrote: > > I just noticed that the last example in section A.2.1.1. describes an > impossible situation, I'll show the example and explain after that: > > sub5.example.com. IN CNAME sub6.example.com. > _443._tcp.sub5.example.com. IN TLSA 1 1 1 308202c5308201ab... > sub6.example.com. IN A 10.0.0.0 > _443._tcp.sub6.example.com. IN TLSA 1 1 1 ac49d9ba4570ac49... > > Both TLSA record contain the SHA-256 hash of public key (Selector 1) of > the end-entity certificate and they are different. This is impossible, > as they describe the _exact_ same thing in the same way. To me that example looks OK (but either needs TLS extension SNI or a TLS cert with two hostnames or a wildcard cert). A Web-Browser that gets the URL https://sub5.example.com will perform a server endpoint identification for "sub5.example.com", independent of whether sub5.example.com resolves into an A record directly, or resolves into an A record through CNAME indirection. Likewise a Web-Browser that gets the URL https://sub6.example.com will perform a server endpoint identification for "sub6.example.com" independent of whether sub6.example.com resolves into an A record directly, or resolves into an A record through CNAME indirection. -Martin From mrex@sap.com Wed Jan 25 13:09:29 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5D8B21F8617 for ; Wed, 25 Jan 2012 13:09:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.151 X-Spam-Level: X-Spam-Status: No, score=-10.151 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zyElR9Ehf9xa for ; Wed, 25 Jan 2012 13:09:29 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id EF37421F860B for ; Wed, 25 Jan 2012 13:09:28 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q0PL9MLd000166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Jan 2012 22:09:22 +0100 (MET) From: Martin Rex Message-Id: <201201252109.q0PL9MfK009863@fs4113.wdf.sap.corp> To: mrex@sap.com Date: Wed, 25 Jan 2012 22:09:21 +0100 (MET) In-Reply-To: <201201252106.q0PL6Ct0009745@fs4113.wdf.sap.corp> from "Martin Rex" at Jan 25, 12 10:06:12 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] Impossible situation in the last example of section X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 21:09:29 -0000 Martin Rex wrote: > > Pieter Lexis wrote: > > > > I just noticed that the last example in section A.2.1.1. describes an > > impossible situation, I'll show the example and explain after that: > > > > sub5.example.com. IN CNAME sub6.example.com. > > _443._tcp.sub5.example.com. IN TLSA 1 1 1 308202c5308201ab... > > sub6.example.com. IN A 10.0.0.0 > > _443._tcp.sub6.example.com. IN TLSA 1 1 1 ac49d9ba4570ac49... > > > > Both TLSA record contain the SHA-256 hash of public key (Selector 1) of > > the end-entity certificate and they are different. This is impossible, > > as they describe the _exact_ same thing in the same way. > > To me that example looks OK (but either needs TLS extension SNI > or a TLS cert with two hostnames or a wildcard cert). but based on the differing TLSA contents of that example, it appears that TLS extension SNI is assumed, not the multiple dNSName-SubjectAltNames and neither the Wildcard cert. > > A Web-Browser that gets the URL https://sub5.example.com > will perform a server endpoint identification for "sub5.example.com", > independent of whether sub5.example.com resolves into an A record directly, > or resolves into an A record through CNAME indirection. > > Likewise a Web-Browser that gets the URL https://sub6.example.com > will perform a server endpoint identification for "sub6.example.com" > independent of whether sub6.example.com resolves into an A record directly, > or resolves into an A record through CNAME indirection. -Martin From bert.hubert@netherlabs.nl Wed Jan 25 13:12:44 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE3E721F8623 for ; Wed, 25 Jan 2012 13:12:44 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 20 hex): X-Spam_report: ...that system for details.\n \n Content previ[...] X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LsWciwOtWT+S for ; Wed, 25 Jan 2012 13:12:44 -0800 (PST) Received: from xs.powerdns.com (xs.powerdns.com [IPv6:2001:888:2000:1d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1A91D21F8621 for ; Wed, 25 Jan 2012 13:12:44 -0800 (PST) Received: from [10.200.0.2] by xs.powerdns.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1RqA91-0002yN-Tq; Wed, 25 Jan 2012 22:12:41 +0100 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: bert hubert In-Reply-To: <201201252109.q0PL9MfK009863@fs4113.wdf.sap.corp> Date: Wed, 25 Jan 2012 22:12:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201201252109.q0PL9MfK009863@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1251.1) X-Spam_score: -2.9 X-Spam_score_int: -28 X-Spam_bar: -- X-Spam_report: Spam detection software, running on the system "xs.powerdns.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On Jan 25, 2012, at 10:09 PM, Martin Rex wrote: >>> Both TLSA record contain the SHA-256 hash of public key (Selector 1) of >>> the end-entity certificate and they are different. This is impossible, >>> as they describe the _exact_ same thing in the same way. >> >> To me that example looks OK (but either needs TLS extension SNI >> or a TLS cert with two hostnames or a wildcard cert). > > but based on the differing TLSA contents of that example, > it appears that TLS extension SNI is assumed, > not the multiple dNSName-SubjectAltNames and neither the Wildcard cert. > [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: dane@ietf.org Subject: Re: [dane] Impossible situation in the last example of section X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 21:12:44 -0000 On Jan 25, 2012, at 10:09 PM, Martin Rex wrote: >>> Both TLSA record contain the SHA-256 hash of public key (Selector 1) = of >>> the end-entity certificate and they are different. This is = impossible, >>> as they describe the _exact_ same thing in the same way. >>=20 >> To me that example looks OK (but either needs TLS extension SNI >> or a TLS cert with two hostnames or a wildcard cert). >=20 > but based on the differing TLSA contents of that example, > it appears that TLS extension SNI is assumed, > not the multiple dNSName-SubjectAltNames and neither the Wildcard = cert. >=20 It might be 'explainable' why this example could be legit, but it might = be better to follow Pieters suggestion and make it something that = doesn't need explaining. It is a minor tweak, shouldn't hurt, and would = make things internally more consistent. Bert From pieter.lexis@os3.nl Wed Jan 25 15:37:14 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD34521F8570 for ; Wed, 25 Jan 2012 15:37:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNcO6z+VBFUl for ; Wed, 25 Jan 2012 15:37:14 -0800 (PST) Received: from mail.serv.os3.nl (mail.serv.os3.nl [IPv6:2001:610:158:960::25]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA0421F8566 for ; Wed, 25 Jan 2012 15:37:14 -0800 (PST) Received: from smtp.os3.nl (smtp.os3.nl [IPv6:2001:610:158:960::119]) by mail.serv.os3.nl (Postfix) with ESMTP id 595F317A9FF for ; Thu, 26 Jan 2012 00:37:13 +0100 (CET) Received: from [IPv6:2001:980:5dd1:1:819a:423:b789:6d9c] (unknown [IPv6:2001:980:5dd1:1:819a:423:b789:6d9c]) by smtp.os3.nl (Postfix) with ESMTPSA id 0C3EE17A9FC for ; Thu, 26 Jan 2012 00:37:13 +0100 (CET) Message-ID: <4F209228.5060105@os3.nl> Date: Thu, 26 Jan 2012 00:37:12 +0100 From: Pieter Lexis User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111109 Thunderbird/3.1.16 MIME-Version: 1.0 To: dane@ietf.org References: <201201252109.q0PL9MfK009863@fs4113.wdf.sap.corp> In-Reply-To: <201201252109.q0PL9MfK009863@fs4113.wdf.sap.corp> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dane] Impossible situation in the last example of section X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 23:37:14 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/25/2012 10:09 PM, Martin Rex wrote: > but based on the differing TLSA contents of that example, > it appears that TLS extension SNI is assumed, > not the multiple dNSName-SubjectAltNames and neither the Wildcard cert. In my experience SNI is hardly deployed 'out there' (but I can't quickly find an article to prove or disprove it), hence I didn't thought about it. In order to avoid this confusion (I'd doubt I'm the only one) either a small remark (+ reference to RFC 4366?) should be added to this example that the use of SNI is assumed or the example should be changed by changing one of the first 3 fields in the Rdata. I'd prefer the second option. - -- Pieter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPIJIlAAoJELPqGO5ebd4jx60QALKPPelUAGr6evSTHcrqwRY7 ThLcg59onvQGb6bedJzpwGu0jiyFJODettQoHPZtJB2RAZEqr/X4aFutUE5eq0SD 4swHpqNOTz3p6XrJyvRfuCXjCoGUiyn7EHdOWbK98MrU85TpNPvbNfvSYt1gUBaq QsLd7vzvrxOC+FUP/Qo7GAVtldWpajfukaqdZghnWNBGkNCHSi/uOUklGWxGoK7W WmSuRjkjG5fknbud0JuT2Kb7HhC++qQuGnKMXYAsxKYax5cgdJyze+ekzqvD3M5j DvkITQr2cqH3q4mrQY1fv/CNw0Xgu49Fn+DvBBAQr7NqOgLZBaKuhEM4akqX3kBq tLDQ+js4FcfNTByh9jzO3OgSfP/LbDouUzkV8sgk08fr4XJ+0XK+HVV/D+dphs2I sRYFMx1bg8Y2HxRojeX1LKLA0M6x6BYF1gwubV4wgvMp86soWV1V/hXtsMC8WLjp k9skA5AJm3fgMc6dZl0yjvwtEVo4VijPzeUhW82gU7QDtmURlRYgahhsVN6FUGkA bktmKWQLkiKdk1jNg77iLpHItk8EgdVtNo7WLlEg5tYbY/8VXyI8vB5npPdErmqp qLK9oR1OQEcazIPqdduqyE89blumsv1hWAkRoU2LaLawmoOEojI45fWKZGVWKfXB uar4fAKelJUFyRaQjY9P =XZJt -----END PGP SIGNATURE----- From mrex@sap.com Wed Jan 25 15:55:52 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1BA11E8085 for ; Wed, 25 Jan 2012 15:55:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.155 X-Spam-Level: X-Spam-Status: No, score=-10.155 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dOjst6fqMyvy for ; Wed, 25 Jan 2012 15:55:51 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8CE11E8071 for ; Wed, 25 Jan 2012 15:55:51 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q0PNtntQ001843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 Jan 2012 00:55:49 +0100 (MET) From: Martin Rex Message-Id: <201201252355.q0PNtm99019188@fs4113.wdf.sap.corp> To: pieter.lexis@os3.nl (Pieter Lexis) Date: Thu, 26 Jan 2012 00:55:48 +0100 (MET) In-Reply-To: <4F209228.5060105@os3.nl> from "Pieter Lexis" at Jan 26, 12 00:37:12 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] Impossible situation in the last example of section X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 23:55:52 -0000 Pieter Lexis wrote: > > On 01/25/2012 10:09 PM, Martin Rex wrote: > > but based on the differing TLSA contents of that example, > > it appears that TLS extension SNI is assumed, > > not the multiple dNSName-SubjectAltNames and neither the Wildcard cert. > > In my experience SNI is hardly deployed 'out there' (but I can't quickly > find an article to prove or disprove it), hence I didn't thought about it. > > In order to avoid this confusion (I'd doubt I'm the only one) either a > small remark (+ reference to RFC 4366?) should be added to this example > that the use of SNI is assumed or the example should be changed by > changing one of the first 3 fields in the Rdata. I'd prefer the second > option. I agree, that examples should not rely on silent assumptions and let the reader wonder whether the example is incorrect. If an example relies on optional protocol features, such as a TLS extension SNI prerequisite for it to work, then this needs to be clearly spelled out in the description of the example. Newer Web Browsers (Firefox,Chrome,Opera) usually support TLS extension SNI and have it enabled. Where TLS is not part of the browser, but part of the OS, the version of the Browser might be irrelevant, such as on Microsoft Windows XP/2003, where SChannel does not support TLS extensions, so none of MSIE 6/7/8 has SNI on XP/2003. And neither does Apple Safari on Windows XP/2003. Many programmatic clients do not have TLS extension SNI enabled (or do not have it at all), because it will require explicit application-level reconnect fallback code to cope with extensions-intolerant servers. -Martin From mrex@sap.com Wed Jan 25 16:20:26 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21BAF11E80A0 for ; Wed, 25 Jan 2012 16:20:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.157 X-Spam-Level: X-Spam-Status: No, score=-10.157 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3h0r6kBQ1ug for ; Wed, 25 Jan 2012 16:20:25 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id D65DA11E8097 for ; Wed, 25 Jan 2012 16:20:17 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q0Q0KGx9017404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 Jan 2012 01:20:16 +0100 (MET) From: Martin Rex Message-Id: <201201260020.q0Q0KGJx020689@fs4113.wdf.sap.corp> To: pieter.lexis@os3.nl (Pieter Lexis) Date: Thu, 26 Jan 2012 01:20:16 +0100 (MET) In-Reply-To: <4F209228.5060105@os3.nl> from "Pieter Lexis" at Jan 26, 12 00:37:12 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] Impossible situation in the last example of section X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 00:20:26 -0000 Pieter Lexis wrote: > > In order to avoid this confusion (I'd doubt I'm the only one) either a > small remark (+ reference to RFC 4366?) should be added to this example > that the use of SNI is assumed or the example should be changed by > changing one of the first 3 fields in the Rdata. I'd prefer the second > option. I forgot YES, rfc4366 is the correct reference for TLS extension SNI. Although there is rfc6066 which is _updating_ rfc4366 (rather than obsoleting it, as the incorrect meta-data suggests). rfc6066 can not possibly obsolete rfc4366, because rfc6066 was stripped from the definitions of ExtendedClientHello and ExtendedServerHello PDUs and therefore it is impossible to use rfc2246 + rfc6066 (without rfc4366) to add support for TLS extension SNI to an existing implementation of TLSv1.0 (rfc2246). Same for rfc4346+rfc6066 (without rfc4366) for an existing implementation of TLSv1.1. -Martin From warren@kumari.net Wed Jan 25 19:06:00 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C96911E809A for ; Wed, 25 Jan 2012 19:06:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.897 X-Spam-Level: X-Spam-Status: No, score=-105.897 tagged_above=-999 required=5 tests=[AWL=-0.498, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O+r4kbvY-gFU for ; Wed, 25 Jan 2012 19:05:59 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id EDBFE11E8096 for ; Wed, 25 Jan 2012 19:05:58 -0800 (PST) Received: from [192.168.0.12] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 917A81B402A0; Wed, 25 Jan 2012 22:05:57 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: <4F1EA468.4030201@os3.nl> Date: Wed, 25 Jan 2012 22:05:56 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F1EA468.4030201@os3.nl> To: Pieter Lexis X-Mailer: Apple Mail (2.1084) Cc: IETF DANE WG list Subject: Re: [dane] Announcing the alpha release of swede - A tool to create and verify TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 03:06:00 -0000 This is wicked awesome, thank you very very much for doing this=85 When running 'verify' on a domain that didn't have a DANE record it = would die with an uncaught exception. This looked a little ugly, so here = is a tiny patch to throw an exception in getRecords() (in case you want = to handle it differently elsewhere) and then catch it in getTLSA(). Again, thank you! W -------- wkumari@scratch-monkey:~/tmp/pieterlexis-swede-09009d5$ diff -rua = swede.orig swede --- swede.orig 2012-01-26 02:36:46.108174855 +0000 +++ swede 2012-01-26 02:58:34.798175146 +0000 @@ -24,6 +24,11 @@ from hashlib import sha256, sha512 from ipaddr import IPv4Address, IPv6Address =20 + +class LookupError(Exception): + """DNS Lookup Error.""" + + def genTLSA(hostname, protocol, port, certificate, output=3D'draft', = usage=3D1, selector=3D0, mtype=3D1): """This function generates a TLSARecord object using the data = passed in the parameters, it then validates the record and returns the RR as a string. @@ -135,7 +140,7 @@ # If we are here the data was either secure or insecure = data is accepted return result.data.raw else: - raise Exception('Error: Unsuccesful lookup or no data = returned.') + raise LookupError('Unsuccesful lookup or no data = returned for rrtype %s.' % rrtype) =20 def getHash(certificate, mtype): """Hashes the certificate based on the mtype. @@ -170,6 +175,9 @@ except InsecureLookupException, e: print str(e) sys.exit(1) + except LookupError, e: + print 'Unable to resolve %s: %s' % (hostname, str(e)) + sys.exit(1) ret =3D [] for record in records: hexdata =3D b2a_hex(record) wkumari@scratch-monkey:~/tmp/pieterlexis-swede-09009d5$=20 ----------- On Jan 24, 2012, at 7:30 AM, Pieter Lexis wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Hi All, >=20 > I am doing a small academic project on the DANE specification to see = it > is implementable in its current form (apart from issue 37 and 28 > currently being discussed, yes). For this I created a tool that can > create all 18 permutations of TLSA records and can verify TLSA records > from DNS with the certificate(-chain) received from the SSL-service. >=20 > I have all permutations running on dane.kiev.studlab.os3.nl on ports > 1500 through 1517 (tcp), using https. >=20 > I've also used the tool to successfully[0] verify records mentioned in = [1]. >=20 > It has limitations, which are mentioned in the README file. >=20 > The code is available on github[2] and as a tarball[3]. Please test = it, > review the code and comment on it and send me patches or pull-requests > if you fix a bug. >=20 > I hope this tool will be helpful for the WG. In addition, I wonder if = it > is a good idea to generate 18 test vectors for inclusion in the RFC?. > 'swede' might be helpful in this respect >=20 > Regards, >=20 > Pieter Lexis >=20 > 0 - http://pastie.org/3243017 > 1 - http://www.ietf.org/mail-archive/web/dane/current/msg04080.html > 2 - https://github.com/pieterlexis/swede > 3 - https://github.com/pieterlexis/swede/tarball/master > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >=20 > iQIcBAEBAgAGBQJPHqRlAAoJELPqGO5ebd4jsTIP+wZYurzeJoOFPhoMu/a/q1PR > QNA09YYsCkuAc0cWloT+iZPppHrK0r/FlXbto2Dc4GSQwEv7INcEKv5ltLjqWJjl > D7gLv+caIDw7M2cysPG3HIMaz+hRXHaerEtg+owoWleihE2lehgcTHPVPAXS78Sc > iGg+9d775s4ISDFgSD8I9EJorj0gDCrvYAmQsi7ukl0GbM/ISJGMASVm1rE6WJ6A > nvQeTqjAvvIba2Jse7ybH8xFjYkb8Ujk27RJP67ZlpTx4Bx8GdSXFDPCBHvBrlBW > 8HqqCO8F4WWDpjxpcTv89c1CvmTyzE0ryfjh3OMbQj70FXE2ficVGbV46IvVTP5R > CcfIpezr4u2PUkdbYFjlknjBA5rpV8CqXWDoTc8Eczn43VvOp2cF4ZlquPjQvQmZ > gqu0FgXsN2ljHvGbxroXG/h7E9Uoe31+2Oyg/oY41h5c4JQlKDC6SaDzjHhOmFmT > XHbKP+DuFoEV5Kpf9ZIeEwVTI++XKFHDU5iRDWbMv2WjA29p6oh5INZ5FP2lNx+e > EshjxZVCeQuowHUXsCmS1mPsOEoPWZyV61ryUwQoLVHnozJfOy4AxbeWabtyPGud > C06hSqZRpjVSKGIElimhG+ToVzPhJFwQuItn3+efruahe8NEhsbut45xk5Yi4EE0 > TX6onFLovK6N79BpSvdi > =3DokS7 > -----END PGP SIGNATURE----- > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 -- Don't be impressed with unintelligible stuff said condescendingly. -- Radia Perlman. From warren@kumari.net Wed Jan 25 19:07:11 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 285A811E809D for ; Wed, 25 Jan 2012 19:07:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.884 X-Spam-Level: X-Spam-Status: No, score=-105.884 tagged_above=-999 required=5 tests=[AWL=-0.485, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WsPz4m9dniKH for ; Wed, 25 Jan 2012 19:07:10 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 4F43A11E809B for ; Wed, 25 Jan 2012 19:07:10 -0800 (PST) Received: from [192.168.0.12] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 8A3DA1B402A0; Wed, 25 Jan 2012 22:07:08 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: Date: Wed, 25 Jan 2012 22:07:07 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F1EA468.4030201@os3.nl> To: Warren Kumari X-Mailer: Apple Mail (2.1084) Cc: IETF DANE WG list Subject: Re: [dane] Announcing the alpha release of swede - A tool to create and verify TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 03:07:11 -0000 And I meant to send this offlist=85 Oh well=85 W On Jan 25, 2012, at 10:05 PM, Warren Kumari wrote: > This is wicked awesome, thank you very very much for doing this=85 >=20 > When running 'verify' on a domain that didn't have a DANE record it = would die with an uncaught exception. This looked a little ugly, so here = is a tiny patch to throw an exception in getRecords() (in case you want = to handle it differently elsewhere) and then catch it in getTLSA(). >=20 > Again, thank you! >=20 > W >=20 >=20 > -------- > wkumari@scratch-monkey:~/tmp/pieterlexis-swede-09009d5$ diff -rua = swede.orig swede > --- swede.orig 2012-01-26 02:36:46.108174855 +0000 > +++ swede 2012-01-26 02:58:34.798175146 +0000 > @@ -24,6 +24,11 @@ > from hashlib import sha256, sha512 > from ipaddr import IPv4Address, IPv6Address >=20 > + > +class LookupError(Exception): > + """DNS Lookup Error.""" > + > + > def genTLSA(hostname, protocol, port, certificate, output=3D'draft', = usage=3D1, selector=3D0, mtype=3D1): > """This function generates a TLSARecord object using the data = passed in the parameters, > it then validates the record and returns the RR as a string. > @@ -135,7 +140,7 @@ > # If we are here the data was either secure or insecure = data is accepted > return result.data.raw > else: > - raise Exception('Error: Unsuccesful lookup or no data = returned.') > + raise LookupError('Unsuccesful lookup or no data = returned for rrtype %s.' % rrtype) >=20 > def getHash(certificate, mtype): > """Hashes the certificate based on the mtype. > @@ -170,6 +175,9 @@ > except InsecureLookupException, e: > print str(e) > sys.exit(1) > + except LookupError, e: > + print 'Unable to resolve %s: %s' % (hostname, str(e)) > + sys.exit(1) > ret =3D [] > for record in records: > hexdata =3D b2a_hex(record) > wkumari@scratch-monkey:~/tmp/pieterlexis-swede-09009d5$=20 >=20 >=20 > ----------- >=20 >=20 > On Jan 24, 2012, at 7:30 AM, Pieter Lexis wrote: >=20 >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >>=20 >> Hi All, >>=20 >> I am doing a small academic project on the DANE specification to see = it >> is implementable in its current form (apart from issue 37 and 28 >> currently being discussed, yes). For this I created a tool that can >> create all 18 permutations of TLSA records and can verify TLSA = records >> from DNS with the certificate(-chain) received from the SSL-service. >>=20 >> I have all permutations running on dane.kiev.studlab.os3.nl on ports >> 1500 through 1517 (tcp), using https. >>=20 >> I've also used the tool to successfully[0] verify records mentioned = in [1]. >>=20 >> It has limitations, which are mentioned in the README file. >>=20 >> The code is available on github[2] and as a tarball[3]. Please test = it, >> review the code and comment on it and send me patches or = pull-requests >> if you fix a bug. >>=20 >> I hope this tool will be helpful for the WG. In addition, I wonder if = it >> is a good idea to generate 18 test vectors for inclusion in the RFC?. >> 'swede' might be helpful in this respect >>=20 >> Regards, >>=20 >> Pieter Lexis >>=20 >> 0 - http://pastie.org/3243017 >> 1 - http://www.ietf.org/mail-archive/web/dane/current/msg04080.html >> 2 - https://github.com/pieterlexis/swede >> 3 - https://github.com/pieterlexis/swede/tarball/master >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.11 (GNU/Linux) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >>=20 >> iQIcBAEBAgAGBQJPHqRlAAoJELPqGO5ebd4jsTIP+wZYurzeJoOFPhoMu/a/q1PR >> QNA09YYsCkuAc0cWloT+iZPppHrK0r/FlXbto2Dc4GSQwEv7INcEKv5ltLjqWJjl >> D7gLv+caIDw7M2cysPG3HIMaz+hRXHaerEtg+owoWleihE2lehgcTHPVPAXS78Sc >> iGg+9d775s4ISDFgSD8I9EJorj0gDCrvYAmQsi7ukl0GbM/ISJGMASVm1rE6WJ6A >> nvQeTqjAvvIba2Jse7ybH8xFjYkb8Ujk27RJP67ZlpTx4Bx8GdSXFDPCBHvBrlBW >> 8HqqCO8F4WWDpjxpcTv89c1CvmTyzE0ryfjh3OMbQj70FXE2ficVGbV46IvVTP5R >> CcfIpezr4u2PUkdbYFjlknjBA5rpV8CqXWDoTc8Eczn43VvOp2cF4ZlquPjQvQmZ >> gqu0FgXsN2ljHvGbxroXG/h7E9Uoe31+2Oyg/oY41h5c4JQlKDC6SaDzjHhOmFmT >> XHbKP+DuFoEV5Kpf9ZIeEwVTI++XKFHDU5iRDWbMv2WjA29p6oh5INZ5FP2lNx+e >> EshjxZVCeQuowHUXsCmS1mPsOEoPWZyV61ryUwQoLVHnozJfOy4AxbeWabtyPGud >> C06hSqZRpjVSKGIElimhG+ToVzPhJFwQuItn3+efruahe8NEhsbut45xk5Yi4EE0 >> TX6onFLovK6N79BpSvdi >> =3DokS7 >> -----END PGP SIGNATURE----- >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >>=20 >=20 > -- > Don't be impressed with unintelligible stuff said condescendingly. > -- Radia Perlman. >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 -- Don't be impressed with unintelligible stuff said condescendingly. -- Radia Perlman. From i.grok@comcast.net Wed Jan 25 20:34:16 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF9E11E80AF for ; Wed, 25 Jan 2012 20:34:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.392 X-Spam-Level: X-Spam-Status: No, score=-102.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aq2j4IzWGNYS for ; Wed, 25 Jan 2012 20:34:16 -0800 (PST) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by ietfa.amsl.com (Postfix) with ESMTP id B813C11E8083 for ; Wed, 25 Jan 2012 20:34:15 -0800 (PST) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta12.westchester.pa.mail.comcast.net with comcast id S4Ue1i0011swQuc5C4aGpG; Thu, 26 Jan 2012 04:34:16 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta15.westchester.pa.mail.comcast.net with comcast id S4aF1i00E00PQ6U3b4aG8K; Thu, 26 Jan 2012 04:34:16 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.3) with ESMTP id q0Q4YCCn004663 for ; Wed, 25 Jan 2012 23:34:12 -0500 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id q0Q4YCR0004662 for dane@ietf.org; Wed, 25 Jan 2012 23:34:12 -0500 Date: Wed, 25 Jan 2012 23:34:12 -0500 From: Scott Schmit To: dane@ietf.org Message-ID: <20120126043412.GA4307@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <4F206C84.9040104@os3.nl> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="IS0zKkzwUGydFO0o" Content-Disposition: inline In-Reply-To: <4F206C84.9040104@os3.nl> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Impossible situation in the last example of section A.2.1.1. (draft 14) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 04:34:16 -0000 --IS0zKkzwUGydFO0o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 25, 2012 at 09:56:36PM +0100, Pieter Lexis wrote: > sub5.example.com. IN CNAME sub6.example.com. > _443._tcp.sub5.example.com. IN TLSA 0 1 1 308202c5308201ab... > sub6.example.com. IN A 10.0.0.0 > _443._tcp.sub6.example.com. IN TLSA 1 1 1 ac49d9ba4570ac49... Good catch on the original not being terribly sensible without SNI, but I don't think sub5.example.com having a different type of TLSA record =66rom sub6.example.com really makes any more sense (you'd either be saying that the same cert should be checked 2 different ways for no obvious reason, or that they're different certs.) IMHO, the best resolution would be this: sub5.example.com. IN CNAME sub6.example.com. _443._tcp.sub5.example.com. IN TLSA 1 1 1 308202c5308201ab... sub6.example.com. IN A 10.0.0.0 _443._tcp.sub6.example.com. IN TLSA 1 1 1 308202c5308201ab... The selector type being 1 allows example.com to use matching SPKIs with potentially-different certificates if SNI is used, or a wildcard certificate, and both are consistent with the example and left to the imagination of the reader. While you're at it, the A record shouldn't be pointing at 10.0.0.0; that's not a valid IPv4 address (based on the RFC 1918 reservation). For that matter, we should be using an address from 192.0.2.0/24 and include a AAAA from 2001:db8::/32 to promote IPv6 adoption. :-) --=20 Scott Schmit --IS0zKkzwUGydFO0o Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQJgYJKoZIhvcNAQcCoIIQFzCCEBMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DVcwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBxswggYDoAMCAQICAwK+HTANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTExMDcxNzA1 MDQwNFoXDTEyMDcxNzExNDI1OVowYjEgMB4GA1UEDRMXNDY1MjU2LTBnRmI2Sk5ZWW44QnFW bUwxGzAZBgNVBAMMEmkuZ3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9r QGNvbWNhc3QubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2AjLOMsBGaqN hv2FcRbfom/QCeKMXu5tUd1JY5oIDZe5y29stnd+se/zUlEkiVeMam4Jgo1c8yGNnwLVYc5/ 9xVi7Qg1Is5b9AB6aJWElJDw/jIdihymNZ2kwkSLT0wl/lzd0mXlwFJPRgQiRkmE6V0ZmjsQ jaVtllVleGBbMvmWPm92e+4Bju9P81kKz7Xr02ijETmaPdVsl+jmOaKPS8Y+2Lat2xus4Ked oJ/7aIWIpz1gRSKjAHSZ1Wmwi2TYUjYhZryChu9e1RWtqk1CycNoeusJ8xdEVN3WSnJ299w/ 3ltK/x/9rpj2j9ShQZVB4NnX6cjQs7pz1lVxvIkjcQIDAQABo4IDrTCCA6kwCQYDVR0TBAIw ADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBQ29j2I0O8sRYi0So9NwwmT1caakDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhR gjAdBgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwggIhBgNVHSAEggIYMIICFDCCAhAG CysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJt ZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUF BwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJp bGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFu ZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0 cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQAZ5U0nL/2PQwsVfHgN7MVPbZEGzDzuj4Oy pTgz4XQFwPcCuy6U9sp1Dwmo3DyKX5nKN4xA7pslN+2Pl/kElGamX7zMCAH0xED0RTOLyk+v nDML4s+OUtWaYVnq1bZEp0F8Luq3zIslAYSebleyiz8M0EypZczsL5rOk86R2F9EYw1CBuFJ 5a4x0CmNu5o30fGNDFt+iXRlbJPp/KY25iUgVnBzJ4COT5kQjxn5lgr4t1I+BDCL5HQQ3h/8 2CzwrWVRBNb9Vqh9LL1ZtzYRt8JezoB6HkVvcKVNGlCZ+/MnvfMzPLwfbTDZC8o4d+4RH6aE LeGF2XmAOaenc/YRqm9oMYIClzCCApMCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQIDAr4dMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTIwMTI2MDQzNDEyWjAjBgkqhkiG9w0BCQQxFgQUq3RLmcXA 5+EmBv0thnsatD+F1aYweQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAVhivRkLE VkkpFZmxcvtq8ANaIkAotFrPD0g7i4LO4wvsLLq5Vip4Gw3npuLXSYW1Hti6k+8LJjq6BNmM PJFJ1rGPM0Pcm+GziGd5f4QgINmO2hyHE/CeEm1KkzHnShHggelNbVSIbvBC5431Wv5iXEbZ a0z0R5YoFHIi5iBGVQdCE4bFjieY5Mvz7Ko5q7IYeviPovseV7VqzJqwmAL1eIEy8UzQq+oF wwZljQddaEm5575DZjA4c68u+Hw5Q9GEPuuW8DIX0fdAHo1tAdkzXU8lcC/0UjaYbk2nSFCu GbXztVznjOKIzTsOBI7Nkz+X3clt/6Tc/sTqxiXS+xPvCA== --IS0zKkzwUGydFO0o-- From jakob@kirei.se Wed Jan 25 22:33:43 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99FD321F855F for ; Wed, 25 Jan 2012 22:33:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yR5EeFLBDuEj for ; Wed, 25 Jan 2012 22:33:42 -0800 (PST) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id 5472321F853C for ; Wed, 25 Jan 2012 22:33:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=lAWgsaV9RDV5wSzXa87q7Og2nJOX5XtrOVOARJx21JQ=; b=Nm53fOYBikzcLt33EvBppxmz3E7VKI2tIoKIWGKlx80M+JfsJQvAVcwUyx23eY4vihxvIyknccw1T h/M+GtBAWu10FeF5oVZ0enCE5emmRTjVbgj0m6ek7GoU7S0NRqKQldZU3KgSSb2Yl5RUKTFKvHXavn 9qAmX/z11Kf/FZbo= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Thu, 26 Jan 2012 07:33:39 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: <20120126043412.GA4307@odin.ulthar.us> Date: Thu, 26 Jan 2012 07:33:31 +0100 Content-Transfer-Encoding: 7bit Message-Id: <4736FFFB-18D6-4ACA-A28D-B3617970CC05@kirei.se> References: <4F206C84.9040104@os3.nl> <20120126043412.GA4307@odin.ulthar.us> To: Scott Schmit X-Mailer: Apple Mail (2.1251.1) Cc: dane@ietf.org Subject: Re: [dane] Impossible situation in the last example of section A.2.1.1. (draft 14) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 06:33:43 -0000 On 26 jan 2012, at 05:34, Scott Schmit wrote: > While you're at it, the A record shouldn't be pointing at 10.0.0.0; > that's not a valid IPv4 address (based on the RFC 1918 reservation). For > that matter, we should be using an address from 192.0.2.0/24 and include > a AAAA from 2001:db8::/32 to promote IPv6 adoption. :-) fixed in the next rev of the draft. jakob From jakob@kirei.se Wed Jan 25 22:41:14 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B24611E80CD for ; Wed, 25 Jan 2012 22:41:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cqTuZ3zKd+uP for ; Wed, 25 Jan 2012 22:41:11 -0800 (PST) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id D392D11E80BB for ; Wed, 25 Jan 2012 22:41:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=pPcGpcwY2MdKZo+vTYXOLkr8+vzjKyD5TVVfHR8Rt4g=; b=ZNocKAcYFH18/ZiH4UP+3nK8mtsd3DeQRTYdvhWTpKMp6tR81LeaNczuIzaPRlxpRoy5LInDqqCjE osOhyqGbP4H5/hdmrx9v4SxerzZAyZe/IsR9SIjr9KNOSV0mjPNktfe/DTekwQ67Ot4E9uJVfmaSz1 2Ztu7pZLf+xhKHwA= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Thu, 26 Jan 2012 07:41:06 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: <201201252355.q0PNtm99019188@fs4113.wdf.sap.corp> Date: Thu, 26 Jan 2012 07:41:05 +0100 Content-Transfer-Encoding: 7bit Message-Id: <08909758-031E-4563-A958-815608D1F056@kirei.se> References: <201201252355.q0PNtm99019188@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1251.1) Cc: dane@ietf.org Subject: Re: [dane] Impossible situation in the last example of section X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 06:41:14 -0000 On 26 jan 2012, at 00:55, Martin Rex wrote: > If an example relies on optional protocol features, such as > a TLS extension SNI prerequisite for it to work, then this > needs to be clearly spelled out in the description of the > example. I've added the follow text to the next rev of the draft: + One should note that deploying different certificates for multiple + services located at a shared TLS listener often requires the use of + TLS SNI (Server Name Indication) [RFC4366]. jakob From ondrej.sury@nic.cz Thu Jan 26 00:06:31 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E12111E8083 for ; Thu, 26 Jan 2012 00:06:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SxoKHcqS50Ry for ; Thu, 26 Jan 2012 00:06:31 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id B1D4511E8075 for ; Thu, 26 Jan 2012 00:06:30 -0800 (PST) Received: from kimac.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 656632A2F4F; Thu, 26 Jan 2012 09:06:28 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1327565188; bh=Ln7VmRMX2AfjLatzXEgHctsPKDSKs+2ngp4OinaM7gc=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=F2/yLAM+VhtwLvx2A11ORYzj2GdKwFr0VWlRNHiEdzqpF3YnVXDo8L68vCFcISaH6 tj9K0Bxns+6RZbIlAsT+qObQiHIwOEyEGW5isTlVtg/oV/VDZj5ivrLZWH4EWh+jY1 rix0lEdxrz+zowFgaPa1m0kSGgFAot1cT5XDgxmc= Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <4F209228.5060105@os3.nl> Date: Thu, 26 Jan 2012 09:06:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0EFDC293-7706-46A4-B56B-87A4A150460D@nic.cz> References: <201201252109.q0PL9MfK009863@fs4113.wdf.sap.corp> <4F209228.5060105@os3.nl> To: Pieter Lexis X-Mailer: Apple Mail (2.1251.1) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane@ietf.org Subject: Re: [dane] Impossible situation in the last example of section X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 08:06:31 -0000 On 26. 1. 2012, at 0:37, Pieter Lexis wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 01/25/2012 10:09 PM, Martin Rex wrote: >> but based on the differing TLSA contents of that example, >> it appears that TLS extension SNI is assumed, >> not the multiple dNSName-SubjectAltNames and neither the Wildcard = cert. >=20 > In my experience SNI is hardly deployed 'out there' (but I can't = quickly > find an article to prove or disprove it), hence I didn't thought about = it. It will get deployed more and more as: 1) Windows XP gets replaced 2) IPv4 addresses run out There's pretty good support for SNI in common webservers. The Windows = XP and admin inertia are the only two obstacles left. O. -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From ondrej.sury@nic.cz Thu Jan 26 00:08:49 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68C8411E80AD for ; Thu, 26 Jan 2012 00:08:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVM46mGEHaYC for ; Thu, 26 Jan 2012 00:08:49 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id BE1A411E80E1 for ; Thu, 26 Jan 2012 00:08:48 -0800 (PST) Received: from kimac.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 0A1DB2A3039; Thu, 26 Jan 2012 09:08:48 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1327565328; bh=VlozIFhFlglNCYDl9z8Vc4Z3FQ9AIdrUexOxSR65wGE=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=t/foKq9WneeMapw9ci4E9zl0tiN6yk2CgQI/qdTPjNbcqNeWyl4/kU9cHhCYbTWNc RWWuAHY2SujnpHEXLG36ZoEk8UfnuPgcbPfENHNMIWa9vPcad2gJ0uW6Js2aDC5Vmh Fj4FAir0stCuGkO0esKXyHzskHsT3YEsX+FHERoI= Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <239A4A6A-D5CF-4D22-88E5-E04D7B992067@kumari.net> Date: Thu, 26 Jan 2012 09:08:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <239A4A6A-D5CF-4D22-88E5-E04D7B992067@kumari.net> To: Warren Kumari X-Mailer: Apple Mail (2.1251.1) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: IETF DANE WG list Subject: Re: [dane] Does the WG want to meet in Paris? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 08:08:49 -0000 Hello all again, we didn't receive any opinions on this, so this is another round after which we close the "poll" and probably NOT MEET in Paris. O. On 8. 1. 2012, at 19:26, Warren Kumari wrote: > Hello all, >=20 > I think that we are *almost* done with the protocol document, and with = some effort will be done before Paris. Does the WG want to meet or = should we skip it this time? >=20 > I personally think we can skip this round (we will done / basically = done on the protocol doc and (IMO) are unlikely to have S/MIME / IPsec = docs ready for discussion) and meeting time is a valuable / scare = resource, but whatever the WG wants=E2=80=A6 >=20 > W >=20 > --- > Don't be impressed with unintelligible stuff said condescendingly . > -- Radia Perlman. >=20 > Warren Kumari > warren@kumari.net >=20 >=20 >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From ondrej.sury@nic.cz Thu Jan 26 00:21:21 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E426211E80AD for ; Thu, 26 Jan 2012 00:21:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTdvuT47DI7P for ; Thu, 26 Jan 2012 00:21:21 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id CF64911E8075 for ; Thu, 26 Jan 2012 00:21:20 -0800 (PST) Received: from kimac.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 1B8292A2F69; Thu, 26 Jan 2012 09:21:20 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1327566080; bh=U4KsTRVHWnCv1z7YugXMSpNvES4BG9cjMLVuUdkv15c=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=bKom2W97Ykza8vRd4xOFgMRIVAR2Wz3jK+WhYz4QiAGVYcozoJjpctDI9Ye0ILO0S kL1aCcQcLt6DYKuHNxWdPUYfCT1Qg9Dbrv6B6bYoJA9lF0lH1b34ykmgbKGGnmMVRa 4UPQHRGLNfw4+6nu+2o7bifoZAEJFdM8cB7+FtGU= Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <8B45AB89-FA6D-40B9-A72E-4F7EC355A5DC@vpnc.org> Date: Thu, 26 Jan 2012 09:21:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> <7A4B9C55-52C3-4A93-9DA7-62F98CF2A6A5@bbn.com> <03EDD353-7C2F-4E2E-911A-117673C94FAF@vpnc.org> <689C663D-4898-4C2D-858C-BE01CA38B666@vpnc.org> <4F0DA32D.7070206@ogud.com> <3868F318-8669-4B97-AFFE-46E0029A4903@insensate.co.uk> <63313B7F-BEA9-46C9-9E86-4E2597988F04@vpnc.org> <9C838E12-4909-47B1-B5DE-A5D4EF394C9A@bbn.com> <4F15DDF3.90307@ogud.com> <6AFCA86D-81BB-488C-90C8-0CFE736BE664@bbn.com> <11720A93-A129-4847-832C-6E51B32C8B1A@vpnc.org> <8B45AB89-FA6D-40B9-A72E-4F7EC355A5DC@vpnc.org> To: Paul Hoffman , dane-chairs@tools.ietf.org, Mark Andrews X-Mailer: Apple Mail (2.1251.1) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: IETF DANE WG list Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 08:21:22 -0000 I kind of agree with marka here: >> If we pick the hostname, >=20 > We do *not* get to make this choice. This choice is out of scope > for DANE. DANE's job is to say how to get to the TLSA record *once* > the application has the name, port and transport. It is *not* DANEs > job to describe how the application goes from its inputs to that > name. On 20. 1. 2012, at 23:37, Paul Hoffman wrote: >> IMO: Defining a uniform procedure for all protocols is not viable, = due to the diversity of use cases. In order for DANE to be deployable, = we should specify guidelines to minimize ambiguity, especially for = obvious cases like HTTPS. But we should not attempt to resolve = ambiguity that is created by application protocols' service discovery = mechanisms. Instead, we should define which options are safe (namely, = DNSSEC-based indirection steps) ask the application communities to = choose. =20 >=20 > I'm OK with that, if the WG understands that a few years from now, = people will bitch at us for not having done it right the first time. I = agree that specifying for the obvious cases like HTTPS might be = sufficient, even if it is not completely satisfying. I sense we are still going in the circles. Would it be acceptable for WG (and ADs) to say something like (in simple terms): "Use the first name unless the protocol specifies otherwise." And then create RFCs for different protocols as an inter-WG effort? Say one RFC for MX, one for XMPP, one for SIP and one to rule them all? I know that what I am suggestion is basically just postponing the argument, but I have a feeling if we continue this we may never agree and get DANE protocol out. O. P.S.: People will bitch at us anyway... -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From ondrej.sury@nic.cz Thu Jan 26 00:26:56 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4F9321F85BB for ; Thu, 26 Jan 2012 00:26:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ilg8cWkx3o6p for ; Thu, 26 Jan 2012 00:26:56 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 1DBE421F8568 for ; Thu, 26 Jan 2012 00:26:56 -0800 (PST) Received: from kimac.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 614BE2A303C; Thu, 26 Jan 2012 09:26:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1327566415; bh=ZZifEZMlD+tPTIEE3La2t6pkA6UZSErINluUXHhZnc8=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=bPM0AHxwxcxlmcxGRo4SRb64ZSanG+583JWcY7pDukdndiCTijjvplS+XtM1dTJ2i uiuqnOQ8eawnH+F4VNjQKi78HEsZZwR0QWKMOwvpZDsMPcKR8EB3xBv2iUY5ffHuGh ZyvlrcjbcAycUjnuH1KNYTVz2bXo3GLtO6E2pG/o= Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <3F134138-06A0-400A-9CA6-5FF55B331D04@vpnc.org> Date: Thu, 26 Jan 2012 09:26:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <20AB8A4F-FD52-4272-BDCD-7756920B6E2F@nic.cz> References: <20120123033124.GD14597@odin.ulthar.us> <201201231921.q0NJLS1i021543@fs4113.wdf.sap.corp> <7769AE22-B0EF-48F2-86E8-AD6977F83124@vpnc.org> <3F134138-06A0-400A-9CA6-5FF55B331D04@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1251.1) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: IETF DANE WG list Subject: Re: [dane] Opening Issue #37. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 08:26:56 -0000 On 24. 1. 2012, at 0:42, Paul Hoffman wrote: > On Jan 23, 2012, at 3:35 PM, Zack Weinberg wrote: >=20 >> On Mon, Jan 23, 2012 at 2:54 PM, Paul Hoffman = wrote: >>>=20 >>>> thus allowing DANE-compliant clients to continue with their present >>>> state of (non)conformance to PKIX. >>>=20 >>> -1. This proposed wording is just as silly as people saying that = PKIX >>> validation is well-defined and well-understood. Saying "we don't = know >>> what conformant means" is a terrible way to write a standard. >>=20 >> Well, I don't much care exactly how it's worded, but I think it is >> *critical* that we manage to "allow DANE-compliant clients to = continue >> with their present state of (non)conformance to PKIX". It seems to = me >> that the easiest way to do that is to define DANE clients' behavior = in >> the presence of TLSA records as adjustments to their behavior in the >> absence of TLSA records, taking no position on what the "behavior in >> the absence of TLSA records" should be. Hence the suggested wording. >> Do you have a better idea? >=20 >=20 > Yes: leave the current text as-is. If someone is not going to conform = to PKIX today, we are not telling them to do it any differently with = DANE. +1 Let's not standardize "status quo" here. O. -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From ondrej.sury@nic.cz Thu Jan 26 00:36:35 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C347121F8656 for ; Thu, 26 Jan 2012 00:36:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJVSrdT+bUzj for ; Thu, 26 Jan 2012 00:36:35 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 1825721F8655 for ; Thu, 26 Jan 2012 00:36:34 -0800 (PST) Received: from kimac.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 6A66C2A282B; Thu, 26 Jan 2012 09:36:33 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1327566993; bh=ZIBaqqDUaEBYlDk2TMz6CaINy8uX+0Ttfctwe39yxdQ=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=KxzkGRXzwETtb/fgrLDd+twBYMs+UhYfNa6Son76hL93SiyiHz4s4uZ/ucuBEeFFS 5SPaVUA4BZhPP44AqqnlfVgit+vKqiaGaK8ypu78I0HVI6HihQUu0kPxhbaIViApWO /DLINJ8iv487acty6y6rTg6qE/3CLCsICQvA7zFQ= Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: Date: Thu, 26 Jan 2012 09:36:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120123033124.GD14597@odin.ulthar.us> <201201231921.q0NJLS1i021543@fs4113.wdf.sap.corp> <7769AE22-B0EF-48F2-86E8-AD6977F83124@vpnc.org> <3F134138-06A0-400A-9CA6-5FF55B331D04@vpnc.org> To: Zack Weinberg X-Mailer: Apple Mail (2.1251.1) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: IETF DANE WG list Subject: Re: [dane] Opening Issue #37. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 08:36:35 -0000 On 24. 1. 2012, at 2:24, Zack Weinberg wrote: > (accidentally hit reply-to-sender rather than reply-to-list, sorry = about that) >=20 > On Mon, Jan 23, 2012 at 3:42 PM, Paul Hoffman = wrote: >> On Jan 23, 2012, at 3:35 PM, Zack Weinberg wrote: >>>=20 >>> Well, I don't much care exactly how it's worded, but I think it is >>> *critical* that we manage to "allow DANE-compliant clients to = continue >>> with their present state of (non)conformance to PKIX". >>=20 >> Yes: leave the current text as-is. If someone is not going to conform >> to PKIX today, we are not telling them to do it any differently with = DANE. >=20 > I disagree. The current text is saying you have to conform to RFC > 5280 if you want to implement DANE. That will be taken as an argument > against implementing DANE by people who think RFC 5280 validation is > too expensive and/or complicated. Zack are you saying we should consider various projects internal politics when constructing the protocol? I disagree with that. And I really believe that if something like that would stop the implementation it doesn't really matter if we put your proposed degree of freedom into the protocol or not. In another words - if the project/people doesn't care about conformance to PKIX, why it would suddenly start when implementing DANE? O. -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From cloos@jhcloos.com Thu Jan 26 05:10:10 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 969EB21F8665 for ; Thu, 26 Jan 2012 05:10:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.255 X-Spam-Level: X-Spam-Status: No, score=-2.255 tagged_above=-999 required=5 tests=[AWL=0.345, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J1PPg6RlIWq7 for ; Thu, 26 Jan 2012 05:10:09 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by ietfa.amsl.com (Postfix) with ESMTP id 6710821F8645 for ; Thu, 26 Jan 2012 05:10:07 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id EFB61400A4; Thu, 26 Jan 2012 13:09:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1327583405; bh=ybftHQFPZjbeCfA9Y82DHyfu5AK7EE3yb95XmpOH7dw=; h=From:To:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=smqSJdNaAOr4/ODdUgq2KWDNlhAqpRWOgYmoFtXAsDOf0oCQ0fF5zG6czwEQ52lTQ VflwjjjUBVw0YtFOAfgYqck+z4LOtzChmkBHvLdTNjEIq/bd81e6q9acx2Ci2w31Gn APDRXZn0BlmOdUykXlHNrdh0TZ8Osi2t6s3vjC6Q= Received: by carbon.jhcloos.org (Postfix, from userid 500) id A318C36004B; Thu, 26 Jan 2012 13:05:08 +0000 (UTC) From: James Cloos To: dane@ietf.org In-Reply-To: <20120126043412.GA4307@odin.ulthar.us> (Scott Schmit's message of "Wed, 25 Jan 2012 23:34:12 -0500") References: <4F206C84.9040104@os3.nl> <20120126043412.GA4307@odin.ulthar.us> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.92 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2012 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Thu, 26 Jan 2012 08:05:08 -0500 Message-ID: Lines: 18 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:120126:dane@ietf.org::fBTuvlkK87X6/8DS:000hDGL6 Subject: Re: [dane] Impossible situation in the last example of section A.2.1.1. (draft 14) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 13:10:10 -0000 >>>>> "SS" == Scott Schmit writes: SS> IMHO, the best resolution would be this: SS> sub5.example.com. IN CNAME sub6.example.com. SS> _443._tcp.sub5.example.com. IN TLSA 1 1 1 308202c5308201ab... SS> sub6.example.com. IN A 10.0.0.0 SS> _443._tcp.sub6.example.com. IN TLSA 1 1 1 308202c5308201ab... Is it OK for children of a CNAME RR to exist? Obviously NS and DS RRs cannot have the same name as a CNAME RR, preventing zone cuts. But can they exist w/in a single zone? I have a vague feeling that we might have dicussed this already, which is why I didn't ask yesterday. But just in case.... -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From i.grok@comcast.net Thu Jan 26 05:16:43 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E23F21F8702 for ; Thu, 26 Jan 2012 05:16:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.404 X-Spam-Level: X-Spam-Status: No, score=-102.404 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQYiN6XpKots for ; Thu, 26 Jan 2012 05:16:42 -0800 (PST) Received: from qmta10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by ietfa.amsl.com (Postfix) with ESMTP id 905EB21F86E1 for ; Thu, 26 Jan 2012 05:16:42 -0800 (PST) Received: from omta23.emeryville.ca.mail.comcast.net ([76.96.30.90]) by qmta10.emeryville.ca.mail.comcast.net with comcast id SDDp1i0031wfjNsAADGdtL; Thu, 26 Jan 2012 13:16:37 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta23.emeryville.ca.mail.comcast.net with comcast id SDGb1i01100PQ6U8jDGcib; Thu, 26 Jan 2012 13:16:37 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.3) with ESMTP id q0QDGYmb006177 for ; Thu, 26 Jan 2012 08:16:34 -0500 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id q0QDGYop006176 for dane@ietf.org; Thu, 26 Jan 2012 08:16:34 -0500 Date: Thu, 26 Jan 2012 08:16:34 -0500 From: Scott Schmit To: dane@ietf.org Message-ID: <20120126131634.GA4693@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <63313B7F-BEA9-46C9-9E86-4E2597988F04@vpnc.org> <9C838E12-4909-47B1-B5DE-A5D4EF394C9A@bbn.com> <4F15DDF3.90307@ogud.com> <6AFCA86D-81BB-488C-90C8-0CFE736BE664@bbn.com> <11720A93-A129-4847-832C-6E51B32C8B1A@vpnc.org> <8B45AB89-FA6D-40B9-A72E-4F7EC355A5DC@vpnc.org> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="yrj/dFKFPuw6o+aM" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 13:16:43 -0000 --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 26, 2012 at 09:21:19AM +0100, Ond=C5=99ej Sur=C3=BD wrote: > I sense we are still going in the circles. Would it be acceptable > for WG (and ADs) to say something like (in simple terms): >=20 > "Use the first name unless the protocol specifies otherwise." >=20 > And then create RFCs for different protocols as an inter-WG effort? > Say one RFC for MX, one for XMPP, one for SIP and one to rule them all? +1 I can live with that. I'm a little nervous that there may not be energy around creating these other documents, but I guess if there isn't then the first name must be acceptable to everyone (or DANE's not going to get deployed for them anyway). --=20 Scott Schmit --yrj/dFKFPuw6o+aM Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQJgYJKoZIhvcNAQcCoIIQFzCCEBMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DVcwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBxswggYDoAMCAQICAwK+HTANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTExMDcxNzA1 MDQwNFoXDTEyMDcxNzExNDI1OVowYjEgMB4GA1UEDRMXNDY1MjU2LTBnRmI2Sk5ZWW44QnFW bUwxGzAZBgNVBAMMEmkuZ3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9r QGNvbWNhc3QubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2AjLOMsBGaqN hv2FcRbfom/QCeKMXu5tUd1JY5oIDZe5y29stnd+se/zUlEkiVeMam4Jgo1c8yGNnwLVYc5/ 9xVi7Qg1Is5b9AB6aJWElJDw/jIdihymNZ2kwkSLT0wl/lzd0mXlwFJPRgQiRkmE6V0ZmjsQ jaVtllVleGBbMvmWPm92e+4Bju9P81kKz7Xr02ijETmaPdVsl+jmOaKPS8Y+2Lat2xus4Ked oJ/7aIWIpz1gRSKjAHSZ1Wmwi2TYUjYhZryChu9e1RWtqk1CycNoeusJ8xdEVN3WSnJ299w/ 3ltK/x/9rpj2j9ShQZVB4NnX6cjQs7pz1lVxvIkjcQIDAQABo4IDrTCCA6kwCQYDVR0TBAIw ADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBQ29j2I0O8sRYi0So9NwwmT1caakDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhR gjAdBgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwggIhBgNVHSAEggIYMIICFDCCAhAG CysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJt ZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUF BwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJp bGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFu ZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0 cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQAZ5U0nL/2PQwsVfHgN7MVPbZEGzDzuj4Oy pTgz4XQFwPcCuy6U9sp1Dwmo3DyKX5nKN4xA7pslN+2Pl/kElGamX7zMCAH0xED0RTOLyk+v nDML4s+OUtWaYVnq1bZEp0F8Luq3zIslAYSebleyiz8M0EypZczsL5rOk86R2F9EYw1CBuFJ 5a4x0CmNu5o30fGNDFt+iXRlbJPp/KY25iUgVnBzJ4COT5kQjxn5lgr4t1I+BDCL5HQQ3h/8 2CzwrWVRBNb9Vqh9LL1ZtzYRt8JezoB6HkVvcKVNGlCZ+/MnvfMzPLwfbTDZC8o4d+4RH6aE LeGF2XmAOaenc/YRqm9oMYIClzCCApMCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQIDAr4dMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTIwMTI2MTMxNjM0WjAjBgkqhkiG9w0BCQQxFgQUl07rgiJ+ 9Gktn8j6/sT6ZvICfHMweQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAjvtjNrmf cVvymagHAIKsb6xu4/TpIV/G5n7LLDQK5HrJ5SF6QdB5WwFfDkWDSfRUdSo0YxV5E0NhiR/J zAcR9RJ+RgegDPp9dc9IPDmX30htIx6H37AAmF2RQHF7Jc6teWRp47fEsp3xx9RFoSLHOeNJ XXpxhBaRub8x2ypiqlkJ8NQW/nUmRfASHKRqP+aj3HdxKA5ww95FFRtlNDGD1aHHAqeufKph YXubcscvfeEjsNAorb5wYxm81hMwOmfk0uf6swDxmJ8cfRxtlQA0vUaKGuQD7o2hQ149HoFJ pr8VyOYQ1ioh8zPHVM58hNQkv72lykL9Dx2zH37nH3uVzg== --yrj/dFKFPuw6o+aM-- From stpeter@stpeter.im Thu Jan 26 05:31:32 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 519A821F863F for ; Thu, 26 Jan 2012 05:31:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.705 X-Spam-Level: X-Spam-Status: No, score=-102.705 tagged_above=-999 required=5 tests=[AWL=-0.106, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i94t61nook-1 for ; Thu, 26 Jan 2012 05:31:31 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A4C7F21F85EF for ; Thu, 26 Jan 2012 05:31:31 -0800 (PST) Received: from squire.local (unknown [216.17.251.49]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0214540058 for ; Thu, 26 Jan 2012 06:41:18 -0700 (MST) Message-ID: <4F2155B1.8050908@stpeter.im> Date: Thu, 26 Jan 2012 06:31:29 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: dane@ietf.org References: <63313B7F-BEA9-46C9-9E86-4E2597988F04@vpnc.org> <9C838E12-4909-47B1-B5DE-A5D4EF394C9A@bbn.com> <4F15DDF3.90307@ogud.com> <6AFCA86D-81BB-488C-90C8-0CFE736BE664@bbn.com> <11720A93-A129-4847-832C-6E51B32C8B1A@vpnc.org> <8B45AB89-FA6D-40B9-A72E-4F7EC355A5DC@vpnc.org> <20120126131634.GA4693@odin.ulthar.us> In-Reply-To: <20120126131634.GA4693@odin.ulthar.us> X-Enigmail-Version: 1.3.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 13:31:32 -0000 On 1/26/12 6:16 AM, Scott Schmit wrote: > On Thu, Jan 26, 2012 at 09:21:19AM +0100, OndÅ™ej Surý wrote: >> I sense we are still going in the circles. Would it be acceptable >> for WG (and ADs) to say something like (in simple terms): >> >> "Use the first name unless the protocol specifies otherwise." >> >> And then create RFCs for different protocols as an inter-WG effort? >> Say one RFC for MX, one for XMPP, one for SIP and one to rule them all? > > +1 I can live with that. I'm a little nervous that there may not be energy > around creating these other documents, but I guess if there isn't then > the first name must be acceptable to everyone (or DANE's not going to > get deployed for them anyway). At least we'll find out who the customers are. ;-) I'd volunteer to work on the XMPP spec -- we definitely want to use the output of the DANE WG. Peter -- Peter Saint-Andre https://stpeter.im/ From stephen.farrell@cs.tcd.ie Thu Jan 26 05:35:09 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3611A21F8666 for ; Thu, 26 Jan 2012 05:35:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.616 X-Spam-Level: X-Spam-Status: No, score=-102.616 tagged_above=-999 required=5 tests=[AWL=-0.317, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2u-EkiybfD6z for ; Thu, 26 Jan 2012 05:35:08 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 83C7621F8653 for ; Thu, 26 Jan 2012 05:35:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 26974171C20; Thu, 26 Jan 2012 13:35:07 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1327584906; bh=P67hZh6ilq3DOL 5nVkdmzFTTqDkNYpDHHNbGcWOkwvU=; b=oEFplZsMo3PnOzMs7Bn5DxXUVuocqY XekrxigUYdsZmb0n3eiqZKZepYhWHz1cjeUo0RLcYWXsQEgb2e0irPfOZua4dPVI ytr0bZq1FaLqEG4Ev09P1lstqvkYAlBjpzA4Lqs6LtslTkLZw/iOIIw0vkAYbeOg I4d+O+68rjxnZKvdzJz3u8a0yie13rZA9qn0z+X2kVxyGT+ZMCIWUqsQ9bJFMzaD SVYuga9eHwJaU3Jp6iQDUUhENUyCGYpQ9uikSb8HjPDCXY/Es3O9waj56HMKby2z yn99db6PMzjttzrL/OUNS/qsC/rhXeMfwjXbugqShF9Ui3tThpW3itFQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id M+EVptC-KFh0; Thu, 26 Jan 2012 13:35:06 +0000 (GMT) Received: from [10.1.1.138] (wifi.ist.utl.pt [193.136.128.57]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 0657D171C99; Thu, 26 Jan 2012 13:35:03 +0000 (GMT) Message-ID: <4F215685.7040206@cs.tcd.ie> Date: Thu, 26 Jan 2012 13:35:01 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> <689C663D-4898-4C2D-858C-BE01CA38B666@vpnc.org> <4F0DA32D.7070206@ogud.com> <3868F318-8669-4B97-AFFE-46E0029A4903@insensate.co.uk> <63313B7F-BEA9-46C9-9E86-4E2597988F04@vpnc.org> <9C838E12-4909-47B1-B5DE-A5D4EF394C9A@bbn.com> <4F15DDF3.90307@ogud.com> <6AFCA86D-81BB-488C-90C8-0CFE736BE664@bbn.com> <11720A93-A129-4847-832C-6E51B32C8B1A@vpnc.org> <8B45AB89-FA6D-40B9-A72E-4F7EC355A5DC@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: dane-chairs@tools.ietf.org, Paul Hoffman , IETF DANE WG list Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 13:35:09 -0000 Hiya, On 01/26/2012 08:21 AM, OndÅ™ej Surý wrote: > And then create RFCs for different protocols as an inter-WG effort? > Say one RFC for MX, one for XMPP, one for SIP and one to rule them all? > > I know that what I am suggestion is basically just postponing > the argument, but I have a feeling if we continue this we may > never agree and get DANE protocol out. If following that plan you should probably also discuss whether to recharter the DANE WG to do that, or whether its better to handle those documents either in other WGs or as individual submissions. Any of those could work, depending on what the WG prefer. S. From i.grok@comcast.net Thu Jan 26 05:40:26 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA3721F85A7 for ; Thu, 26 Jan 2012 05:40:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.415 X-Spam-Level: X-Spam-Status: No, score=-102.415 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oBxfnHocSfKo for ; Thu, 26 Jan 2012 05:40:26 -0800 (PST) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by ietfa.amsl.com (Postfix) with ESMTP id 109DE21F8591 for ; Thu, 26 Jan 2012 05:40:26 -0800 (PST) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta05.emeryville.ca.mail.comcast.net with comcast id SDZg1i0021smiN4A5DgRWS; Thu, 26 Jan 2012 13:40:25 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta20.emeryville.ca.mail.comcast.net with comcast id SDgQ1i00Q00PQ6U8gDgRe3; Thu, 26 Jan 2012 13:40:25 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.3) with ESMTP id q0QDeMp2006351 for ; Thu, 26 Jan 2012 08:40:22 -0500 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id q0QDeMFu006350 for dane@ietf.org; Thu, 26 Jan 2012 08:40:22 -0500 Date: Thu, 26 Jan 2012 08:40:22 -0500 From: Scott Schmit To: dane@ietf.org Message-ID: <20120126134022.GB4693@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <4F206C84.9040104@os3.nl> <20120126043412.GA4307@odin.ulthar.us> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="oLBj+sq0vYjzfsbl" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Impossible situation in the last example of section A.2.1.1. (draft 14) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 13:40:26 -0000 --oLBj+sq0vYjzfsbl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 26, 2012 at 08:05:08AM -0500, James Cloos wrote: > >>>>> "SS" =3D=3D Scott Schmit writes: >=20 > SS> IMHO, the best resolution would be this: > SS> sub5.example.com. IN CNAME sub6.example.com. > SS> _443._tcp.sub5.example.com. IN TLSA 1 1 1 308202c5308201ab... > SS> sub6.example.com. IN A 10.0.0.0 > SS> _443._tcp.sub6.example.com. IN TLSA 1 1 1 308202c5308201ab... >=20 > Is it OK for children of a CNAME RR to exist? Obviously NS and DS RRs > cannot have the same name as a CNAME RR, preventing zone cuts. But can > they exist w/in a single zone? >=20 > I have a vague feeling that we might have dicussed this already, which > is why I didn't ask yesterday. But just in case.... This is legal. CNAMEs aren't allowed to coexist with any other record at the node in question (with the exception of RRSIGs), but they don't conflict with elements below them in the tree. That's what I remembered =66rom our previous discussions, and testing it out with some open & ISP resolvers, it appears to work just fine. --=20 Scott Schmit --oLBj+sq0vYjzfsbl Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQJgYJKoZIhvcNAQcCoIIQFzCCEBMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DVcwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBxswggYDoAMCAQICAwK+HTANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTExMDcxNzA1 MDQwNFoXDTEyMDcxNzExNDI1OVowYjEgMB4GA1UEDRMXNDY1MjU2LTBnRmI2Sk5ZWW44QnFW bUwxGzAZBgNVBAMMEmkuZ3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9r QGNvbWNhc3QubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2AjLOMsBGaqN hv2FcRbfom/QCeKMXu5tUd1JY5oIDZe5y29stnd+se/zUlEkiVeMam4Jgo1c8yGNnwLVYc5/ 9xVi7Qg1Is5b9AB6aJWElJDw/jIdihymNZ2kwkSLT0wl/lzd0mXlwFJPRgQiRkmE6V0ZmjsQ jaVtllVleGBbMvmWPm92e+4Bju9P81kKz7Xr02ijETmaPdVsl+jmOaKPS8Y+2Lat2xus4Ked oJ/7aIWIpz1gRSKjAHSZ1Wmwi2TYUjYhZryChu9e1RWtqk1CycNoeusJ8xdEVN3WSnJ299w/ 3ltK/x/9rpj2j9ShQZVB4NnX6cjQs7pz1lVxvIkjcQIDAQABo4IDrTCCA6kwCQYDVR0TBAIw ADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBQ29j2I0O8sRYi0So9NwwmT1caakDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhR gjAdBgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwggIhBgNVHSAEggIYMIICFDCCAhAG CysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJt ZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUF BwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJp bGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFu ZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0 cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQAZ5U0nL/2PQwsVfHgN7MVPbZEGzDzuj4Oy pTgz4XQFwPcCuy6U9sp1Dwmo3DyKX5nKN4xA7pslN+2Pl/kElGamX7zMCAH0xED0RTOLyk+v nDML4s+OUtWaYVnq1bZEp0F8Luq3zIslAYSebleyiz8M0EypZczsL5rOk86R2F9EYw1CBuFJ 5a4x0CmNu5o30fGNDFt+iXRlbJPp/KY25iUgVnBzJ4COT5kQjxn5lgr4t1I+BDCL5HQQ3h/8 2CzwrWVRBNb9Vqh9LL1ZtzYRt8JezoB6HkVvcKVNGlCZ+/MnvfMzPLwfbTDZC8o4d+4RH6aE LeGF2XmAOaenc/YRqm9oMYIClzCCApMCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQIDAr4dMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTIwMTI2MTM0MDIyWjAjBgkqhkiG9w0BCQQxFgQUV0OGMo6v JXWuVmJsPQjKzXSp0KIweQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEANnerTL4U u5FpRhUNiFd/6CztHY+nXEZeaxn+0c0rl/nk8gTRimiaFrTkdx79aAmQsxlpsWAmJR+u3mMt JGo4QfMsfibMRc3+TeXrsWFj+n4UYuPNFeGx/CMAxuZtwkX6sNHM3sh8EE3LxBmfBWQO0k6q qQHlaZ3LOaXW4r9vrMYujsbIJA0GQJUzizp/oxpRCaYYqh2tHC8fEyHgCwDqDTvFOnwobsX+ vGClDu4+SvNX6/2RS37XSSWXR1OC6/2Zwji9hP7eBImst/OcaPQm9o1Xqvmtn4OUeGm9RL3p l4fwQkSxXDPf/uqJxfC8zBQZofiIDsqRdBd6tp4SDXNelw== --oLBj+sq0vYjzfsbl-- From stpeter@stpeter.im Thu Jan 26 05:43:56 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C74621F85EA for ; Thu, 26 Jan 2012 05:43:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bADG+gDdWgAB for ; Thu, 26 Jan 2012 05:43:55 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 93B1C21F85AF for ; Thu, 26 Jan 2012 05:43:55 -0800 (PST) Received: from squire.local (unknown [216.17.251.49]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0D0C640058; Thu, 26 Jan 2012 06:53:42 -0700 (MST) Message-ID: <4F215899.8000901@stpeter.im> Date: Thu, 26 Jan 2012 06:43:53 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Stephen Farrell References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> <689C663D-4898-4C2D-858C-BE01CA38B666@vpnc.org> <4F0DA32D.7070206@ogud.com> <3868F318-8669-4B97-AFFE-46E0029A4903@insensate.co.uk> <63313B7F-BEA9-46C9-9E86-4E2597988F04@vpnc.org> <9C838E12-4909-47B1-B5DE-A5D4EF394C9A@bbn.com> <4F15DDF3.90307@ogud.com> <6AFCA86D-81BB-488C-90C8-0CFE736BE664@bbn.com> <11720A93-A129-4847-832C-6E51B32C8B1A@vpnc.org> <8B45AB89-FA6D-40B9-A72E-4F7EC355A5DC@vpnc.org> <4F215685.7040206@cs.tcd.ie> In-Reply-To: <4F215685.7040206@cs.tcd.ie> X-Enigmail-Version: 1.3.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: dane-chairs@tools.ietf.org, Paul Hoffman , IETF DANE WG list Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 13:43:56 -0000 On 1/26/12 6:35 AM, Stephen Farrell wrote: > > Hiya, > > On 01/26/2012 08:21 AM, OndÅ™ej Surý wrote: >> And then create RFCs for different protocols as an inter-WG effort? >> Say one RFC for MX, one for XMPP, one for SIP and one to rule them all? >> >> I know that what I am suggestion is basically just postponing >> the argument, but I have a feeling if we continue this we may >> never agree and get DANE protocol out. > > If following that plan you should probably also discuss whether > to recharter the DANE WG to do that, or whether its better to > handle those documents either in other WGs or as individual > submissions. Any of those could work, depending on what the > WG prefer. Given that there might not be active working groups for some of these documents (e.g., MX), I think it would be more productive to work on them all in DANE, coordinating with active WGs where appropriate. Peter -- Peter Saint-Andre https://stpeter.im/ From mamille2@cisco.com Thu Jan 26 07:01:49 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D08721F863E for ; Thu, 26 Jan 2012 07:01:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eEeOSMyVQ8cj for ; Thu, 26 Jan 2012 07:01:48 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id C064621F84B9 for ; Thu, 26 Jan 2012 07:01:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=3909; q=dns/txt; s=iport; t=1327590108; x=1328799708; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=1oFjhL3Fl6dbyUEKoyYTbkc+yEGvfeZCLELDufr2tMM=; b=CiZyqT5duGzIMct/Ogo5cMTrxec3plhspMP6yKF+qkY2aDGMZ9m03JhS Sfgdu8xgH8OY1B04f/+HiLoQnBFIljtRorhUw/vQ8Tt8IBk7B7zfNVOoS bcHTFGNWs00XsCfXYoRbLjaV99Qo4GtwlKYDju27rNhvZezn0CMDzUmy7 k=; X-Files: smime.p7s : 2214 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANdpIU+rRDoG/2dsb2JhbABChQmpQoEFgXIBAQEEEgEQVhALGCoCAgJVBhMioSsBjGOFaYt3iSIODhABCAEGBAMDBAcYAwECgnAaAg4CBnUHBgUBCwIBC4ItM2MEiD+FfYZjknE X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="p7s'?scan'208";a="27259611" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 26 Jan 2012 15:01:48 +0000 Received: from dhcp-64-101-72-224.cisco.com (dhcp-64-101-72-224.cisco.com [64.101.72.224]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q0QF1m1v022797; Thu, 26 Jan 2012 15:01:48 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-2--756879684; protocol="application/pkcs7-signature"; micalg=sha1 From: Matt Miller In-Reply-To: Date: Thu, 26 Jan 2012 08:02:34 -0700 Message-Id: <24C09300-DB5A-4FCC-A1FD-40EEFBEA6422@cisco.com> References: <11849EEF-83A6-4FC1-AF07-440782FAE509@kumari.net> <7A4B9C55-52C3-4A93-9DA7-62F98CF2A6A5@bbn.com> <03EDD353-7C2F-4E2E-911A-117673C94FAF@vpnc.org> <689C663D-4898-4C2D-858C-BE01CA38B666@vpnc.org> <4F0DA32D.7070206@ogud.com> <3868F318-8669-4B97-AFFE-46E0029A4903@insensate.co.uk> <63313B7F-BEA9-46C9-9E86-4E2597988F04@vpnc.org> <9C838E12-4909-47B1-B5DE-A5D4EF394C9A@bbn.com> <4F15DDF3.90307@ogud.com> <6AFCA86D-81BB-488C-90C8-0CFE736BE664@bbn.com> <11720A93-A129-4847-832C-6E51B32C8B1A@vpnc.org> <8B45AB89-FA6D-40B9-A72E-4F7EC355A5DC@vpnc.org> To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= X-Mailer: Apple Mail (2.1084) Cc: dane-chairs@tools.ietf.org, Paul Hoffman , IETF DANE WG list Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 15:01:49 -0000 --Apple-Mail-2--756879684 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 26, 2012, at 01:21, Ond=C5=99ej Sur=C3=BD wrote: >=20 >=20 > I sense we are still going in the circles. Would it be acceptable > for WG (and ADs) to say something like (in simple terms): >=20 > "Use the first name unless the protocol specifies otherwise." >=20 > And then create RFCs for different protocols as an inter-WG effort? > Say one RFC for MX, one for XMPP, one for SIP and one to rule them = all? >=20 +1 - m&m Matt Miller - Collaboration Software Group - Cisco Systems, Inc. --Apple-Mail-2--756879684 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNTCCBTEw ggMZoAMCAQICAwmYMjANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEyMTQxNzQ3MTlaFw0x MjEyMTMxNzQ3MTlaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjgf4wgfswDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMB0GA1UdEQQWMBSBEm1hbWlsbGUyQGNpc2NvLmNvbTAN BgkqhkiG9w0BAQUFAAOCAgEAoa/WVlTWG/rbVIFlG1tCdJrbVvIWNfUNSgojunKsoaVGCoIh7T1+ SgWe8sV+r7s5bVlq66iGxTm/qoKMHM9i4aNGlwWDkXqLHoCKbY4qKPGKnn7PaoA6DWQ5u7ZKBkn9 N2fY8iLxiAy/hLnjtRLlbSr2yBX0DbO1K0ORLDwfO2MUf1j2Cou+qVvEmyEe7cUq37iOOsNbtghT xjn+RE7WJiHcR9deAkfI1xXi7UZcFME+k6nhdnX/qWFFLox0fJJCzX1H8DTzRIjA+ciNLWSG+TRx s7fAn+YZisJdkGxMcWlHZxSu+ybPjc9T7zCyf4+yFHigdOMNxiQ2k/E9WTJ84xIis2TG3E9Nba9B PMb6cgjiqGxiFpKKHj9/5A3wDIHZ8dof+M7YFGnHzwF9i72ZEoaO3hMEhAg9LhqGtQtEZohbTZL2 FOeT+8VjUHSOKhEYurQjWrHDj+ZyDjzhOE/KMwqSWokZhoy0s+VQ05BrVlbXd5DJaB/Hem0MdDUc /6IjqtI6f8O/HLQFAVUQgtW50bfCjDOAB/SaEKzygblcAHxSKDbduRQaRst6cIHEy4eQxvxrHIhg b2KWZ00jS+7NUnAMOyzIJTcZfV5mkCb8UjMHq9NSChwpBFuDzpXxjU20xJGDvbVWNDwfbITCczph p4uuhLITzvhHKaUNwxoqx0oxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYD VQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRo b3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCZgyMAkGBSsOAwIaBQCg ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDEyNjE1MDIz NVowIwYJKoZIhvcNAQkEMRYEFE+eOb7AKJ1t57J5n4UOcp/PymmuMIGRBgkrBgEEAYI3EAQxgYMw gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0 QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq hkiG9w0BAQEFAASCAQBfdKrpzhLk2T4Yt07G3Pz+sEQsoYqY9PyvOYTkIBp1hrbZtrFJCgRwE1hO 1anTmxs1slBQbwvtNqGHsgD83h5OZSyvLzLiZ57RncOoxsY0HoOCX+/Fn/Sj2UqZZPPSFTBZvhRg i1UcPmCUz6v79kHh2vvRDX3YmMaUjBpRPa3A2asaUJp4Q6W39Pfwl5q4/lFFOtBSxb7R2PrYZQky qZnfprMz+2a0jyMa4MbX2a7YM5K9Kh9Fgbt3m0I9xdK3WJ34iYuRI8SCWPOaffKff2uxJiG+3SSC TEl0Xrr9X9gfnVlvO7jWIGXuUCibuFw3NkTdazyOW6+VN6GB1LDz1eu0AAAAAAAA --Apple-Mail-2--756879684-- From mamille2@cisco.com Thu Jan 26 07:02:38 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5321721F8562 for ; Thu, 26 Jan 2012 07:02:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.58 X-Spam-Level: X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9hDXabdilLUC for ; Thu, 26 Jan 2012 07:02:37 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id DB7C021F852E for ; Thu, 26 Jan 2012 07:02:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=4559; q=dns/txt; s=iport; t=1327590158; x=1328799758; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=mZ6T564s+MzJ+XEt4Nkdsk6ujlyoSw3kddEQ0RchuzU=; b=FXb8ADrUNSkRpFHB4q+wpQYKqpgXKOCisBEdUE4Uf6lr7EmdBXWth0M1 606YenrgRu6aJ+O8f9FWa4YMqS4rI7DQotJ4efuafE7Gc1/3ZGX3j3XHq 2TH2eI42ZMjpjid+NgEpqNJ6iRUUyKf0odYRQSa3ssMdmqLwbd75/gV22 k=; X-Files: smime.p7s : 2214 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANdpIU+rRDoG/2dsb2JhbABChQmpQoEFgXIBAQEDARIBEFYFCwsYKgICAlUGEyKHWplRAYxjhWmLd4kiDg4QAQgBBgQDAwQHGwOCcBoCDgIGdQcGBQELAgELgi0zYwSIP4V9hmOScQ X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="p7s'?scan'208";a="27259714" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 26 Jan 2012 15:02:37 +0000 Received: from dhcp-64-101-72-224.cisco.com (dhcp-64-101-72-224.cisco.com [64.101.72.224]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q0QF1m1w022797; Thu, 26 Jan 2012 15:02:37 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-3--756830149; protocol="application/pkcs7-signature"; micalg=sha1 From: Matt Miller In-Reply-To: <4F2155B1.8050908@stpeter.im> Date: Thu, 26 Jan 2012 08:03:24 -0700 Message-Id: <1D5610EF-1AB3-4CDE-A4E9-10D16C103E0E@cisco.com> References: <63313B7F-BEA9-46C9-9E86-4E2597988F04@vpnc.org> <9C838E12-4909-47B1-B5DE-A5D4EF394C9A@bbn.com> <4F15DDF3.90307@ogud.com> <6AFCA86D-81BB-488C-90C8-0CFE736BE664@bbn.com> <11720A93-A129-4847-832C-6E51B32C8B1A@vpnc.org> <8B45AB89-FA6D-40B9-A72E-4F7EC355A5DC@vpnc.org> <20120126131634.GA4693@odin.ulthar.us> <4F2155B1.8050908@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1084) Cc: dane@ietf.org Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 15:02:38 -0000 --Apple-Mail-3--756830149 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 26, 2012, at 06:31, Peter Saint-Andre wrote: > On 1/26/12 6:16 AM, Scott Schmit wrote: >> On Thu, Jan 26, 2012 at 09:21:19AM +0100, Ond=C5=99ej Sur=C3=BD = wrote: >>> I sense we are still going in the circles. Would it be acceptable >>> for WG (and ADs) to say something like (in simple terms): >>>=20 >>> "Use the first name unless the protocol specifies otherwise." >>>=20 >>> And then create RFCs for different protocols as an inter-WG effort? >>> Say one RFC for MX, one for XMPP, one for SIP and one to rule them = all? >>=20 >> +1 I can live with that. I'm a little nervous that there may not be = energy >> around creating these other documents, but I guess if there isn't = then >> the first name must be acceptable to everyone (or DANE's not going to >> get deployed for them anyway). >=20 > At least we'll find out who the customers are. ;-) >=20 > I'd volunteer to work on the XMPP spec -- we definitely want to use = the > output of the DANE WG. >=20 Since you've already volunteered to work on the XMPP spec, I volunteer = to help (-: - m&m Matt Miller - Collaboration Software Group - Cisco Systems, Inc. --Apple-Mail-3--756830149 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNTCCBTEw ggMZoAMCAQICAwmYMjANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEyMTQxNzQ3MTlaFw0x MjEyMTMxNzQ3MTlaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjgf4wgfswDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMB0GA1UdEQQWMBSBEm1hbWlsbGUyQGNpc2NvLmNvbTAN BgkqhkiG9w0BAQUFAAOCAgEAoa/WVlTWG/rbVIFlG1tCdJrbVvIWNfUNSgojunKsoaVGCoIh7T1+ SgWe8sV+r7s5bVlq66iGxTm/qoKMHM9i4aNGlwWDkXqLHoCKbY4qKPGKnn7PaoA6DWQ5u7ZKBkn9 N2fY8iLxiAy/hLnjtRLlbSr2yBX0DbO1K0ORLDwfO2MUf1j2Cou+qVvEmyEe7cUq37iOOsNbtghT xjn+RE7WJiHcR9deAkfI1xXi7UZcFME+k6nhdnX/qWFFLox0fJJCzX1H8DTzRIjA+ciNLWSG+TRx s7fAn+YZisJdkGxMcWlHZxSu+ybPjc9T7zCyf4+yFHigdOMNxiQ2k/E9WTJ84xIis2TG3E9Nba9B PMb6cgjiqGxiFpKKHj9/5A3wDIHZ8dof+M7YFGnHzwF9i72ZEoaO3hMEhAg9LhqGtQtEZohbTZL2 FOeT+8VjUHSOKhEYurQjWrHDj+ZyDjzhOE/KMwqSWokZhoy0s+VQ05BrVlbXd5DJaB/Hem0MdDUc /6IjqtI6f8O/HLQFAVUQgtW50bfCjDOAB/SaEKzygblcAHxSKDbduRQaRst6cIHEy4eQxvxrHIhg b2KWZ00jS+7NUnAMOyzIJTcZfV5mkCb8UjMHq9NSChwpBFuDzpXxjU20xJGDvbVWNDwfbITCczph p4uuhLITzvhHKaUNwxoqx0oxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYD VQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRo b3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCZgyMAkGBSsOAwIaBQCg ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDEyNjE1MDMy NFowIwYJKoZIhvcNAQkEMRYEFDi2jaxg4bfo4lOr/RmH/1oMYZIcMIGRBgkrBgEEAYI3EAQxgYMw gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0 QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq hkiG9w0BAQEFAASCAQAQsQBgVyfeCi+iBmETGC9HqyR4ZC2zmRKeuM4h66DVSmd546ga0wS9LEHY bPWhu6OljF+CfNt3d3aF4n4Pa38vw2axq9aaoLAlLfa16TSRTx8zzTRUsdTFcRvmONwnvnt6kpTS A1FC7J/smI3E5voEUNe1RK+dn7WE7zHhNQpYMuratMipQn8k0xgoImvLSOWoOCqOdC7OdD6XueHz aKcfXEfYXCS+ZAHIsaCgdSXJQncccWHeLKCX27NSYRdal+QCDm1xeg1/FhrenSdJsBdbMLGylGIw blk9v/unb0XV64dCVC2E+N4SGEzsQp6q6qVZ4EPUgFz/KEJ9EIshxdL9AAAAAAAA --Apple-Mail-3--756830149-- From ajs@anvilwalrusden.com Thu Jan 26 07:29:13 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE7121F85C5 for ; Thu, 26 Jan 2012 07:29:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.656 X-Spam-Level: X-Spam-Status: No, score=-2.656 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rf19f9xSwvJP for ; Thu, 26 Jan 2012 07:29:13 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id C5B6A21F85AC for ; Thu, 26 Jan 2012 07:29:05 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 02FAF1ECB41F for ; Thu, 26 Jan 2012 15:29:04 +0000 (UTC) Date: Thu, 26 Jan 2012 10:29:03 -0500 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20120126152902.GI16280@mail.yitter.info> References: <4F206C84.9040104@os3.nl> <20120126043412.GA4307@odin.ulthar.us> <20120126134022.GB4693@odin.ulthar.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120126134022.GB4693@odin.ulthar.us> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Impossible situation in the last example of section A.2.1.1. (draft 14) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 15:29:13 -0000 On Thu, Jan 26, 2012 at 08:40:22AM -0500, Scott Schmit wrote: > from our previous discussions, and testing it out with some open & ISP > resolvers, it appears to work just fine. As we have recently discovered from, e.g., the way case is handled in RRSIGs, testing with deployed software is not actually a reliable measure of what the RFCs say. But it's also true that there's nothing in any RFC which makes CNAME a terminal RRTYPE. Yes, it is permitted to have records beneath a CNAME. Interestingly, when this first came up, it was surprising how many people who knew the DNS well thought that CNAMEs _were_ a terminal type, so I expect this example will be an opportunity for some people to learn something. A -- Andrew Sullivan ajs@anvilwalrusden.com From mrex@sap.com Thu Jan 26 12:23:07 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6097A21F8666 for ; Thu, 26 Jan 2012 12:23:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.012 X-Spam-Level: X-Spam-Status: No, score=-10.012 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDdJ52qmCHfE for ; Thu, 26 Jan 2012 12:23:06 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 9C29321F8663 for ; Thu, 26 Jan 2012 12:23:06 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q0QKN4b4010329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 Jan 2012 21:23:04 +0100 (MET) From: Martin Rex Message-Id: <201201262023.q0QKN3lZ028508@fs4113.wdf.sap.corp> To: ondrej.sury@nic.cz (=?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?=) Date: Thu, 26 Jan 2012 21:23:03 +0100 (MET) In-Reply-To: <0EFDC293-7706-46A4-B56B-87A4A150460D@nic.cz> from "=?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?=" at Jan 26, 12 09:06:28 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] Impossible situation in the last example of section X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 20:23:07 -0000 =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= wrote: > > > > > In my experience SNI is hardly deployed 'out there' (but I can't quickly > > find an article to prove or disprove it), hence I didn't thought about it. > > It will get deployed more and more as: > > 1) Windows XP gets replaced > 2) IPv4 addresses run out > > There's pretty good support for SNI in common webservers. The Windows XP > and admin inertia are the only two obstacles left. SNI is usable for specific scenarios that are browser-only and have limited participants/users. SNI may become generally useful faster than IPv6, but not by a significant margin. We don't have support for SNI in the implementation I maintain, neither in the TLS client, nor in the TLS server. Support for SSLv3 with an initial SSL Version 2.0 CLIENT-HELLO appears much more important to our customers (in some parts of the world XP with MSIE 6 seems to be still common enough for businesses to care). -Martin From owens.bill@gmail.com Thu Jan 26 18:37:00 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC7BE21F8677 for ; Thu, 26 Jan 2012 18:37:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JNWu4ik9do+s for ; Thu, 26 Jan 2012 18:37:00 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id BFBAD21F8669 for ; Thu, 26 Jan 2012 18:36:59 -0800 (PST) Received: by werm10 with SMTP id m10so1061353wer.31 for ; Thu, 26 Jan 2012 18:36:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=AzDuvSND8dzfRByvNLVtSQurWjJZksbTn8LjtaTh+1U=; b=f5tfzDJvQ+cRGTMA7YA4Pi3ydcV+ZzVYRqhDQ6xEOVF0Bz2o9J3mm2HukOCOjaD77T bVTO2kH724ZlZkX7iLh9R5xcw1Coe8H4wy1scV6MouN20ymxrGZlDLuZYRf1lkK+w1n7 ydNwCEfKCqiE7RcFwjcxtr8+e9DAWZcRsl4eU= MIME-Version: 1.0 Received: by 10.216.134.196 with SMTP id s46mr1986942wei.44.1327631818902; Thu, 26 Jan 2012 18:36:58 -0800 (PST) Received: by 10.180.97.161 with HTTP; Thu, 26 Jan 2012 18:36:58 -0800 (PST) Date: Thu, 26 Jan 2012 21:36:58 -0500 Message-ID: From: Bill Owens To: dane@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [dane] Comments on draft-ietf-dane-protocol-14 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 02:37:00 -0000 I've been trying to give the current draft a thorough reading, and I confess to being confused in a few parts. I believe that my inexperience with TLS and PKIX is showing, but that the draft itself is making things worse ;) In particular, the use of the all-important word 'certificate' seems to me to be inconsistent. I think there is one use of the word, meaning the certificate presented by the TLS server during the opening of the TLS connection; that object is called by the following names: 'certificate' : 31 times 'server's certificate' : 4 times 'PKIX certificate' : 5 times 'end entity certificate' : 7 times 'certificate from TLS' : 1 time It seems as though 'end entity certificate' is the correct terminology from the PKIX standard but I'm not certain of that. Likewise, the data included in the TLSA record are called: 'certificate association' : 15 times 'certificate for association' : 4 times Occasionally it is referred to as simply a certificate, for example in the first paragraph of section 1.2. The document also talks about CA certificates and trust anchors, and I believe that usage is consistent. I can't say whether the language creates any ambiguity, since I don't know enough about the intricacies of PKIX; since anyone actually implementing this protocol would need to have such expertise, perhaps there's no issue. However, a set of definitions near the beginning of the document, and a more consistent use of the defined terms, would make things a lot easier to follow. There are a few other small changes that the authors might want to consider: - Section 1.2 says "This document does not specify how DNSSEC validation occurs...", but then goes on to make such a suggestion in Section 4.4, and leaves a placeholder for discussing last-hop issues in the Appendix. - Section 4.1 refers to "the public key of such a certificate, that the must be found in any of the PKIX validation chains" Should there be something between "the" and "must", or is "the" a typo? - Section 4.4 talks about "how to match the identify given in a PKIX certificate" - should that be "identity", or "identifier", or ? - Also in Section 4.4, the paragraph about clients is confusingly written. I think that it means to say something like this: Clients that validate the DNSSEC signatures themselves MUST use standard DNSSEC validation procedures. Clients that rely on another entity to perform the DNSSEC signature validation MUST use a secure transport (such as TSIG...) between themselves and the validator. Note that it is not sufficient to use secure transport to a DNS resolver that does not do DNSSEC signature validation. - The paragraph on SSL proxies in Section 8 ends with the statement "Thus, such proxies might choose to aggressively block TLSA requests and/or responses." I think that would be a downgrade attack, which is prevented by authenticated denial of existence. - Minor wording: Appendix A.1.1 is missing "the" in the last sentence ("client builds the trust chain") and A.1.2.1 likewise in the first sentence ("provides the most precise") Finally in the pseudocode, I believe that I can follow the processing except for the appearance of the PKIX validation chain H in in the usage=2 case. Wouldn't the chain consist only of R, which was provided by the TLSA record? If not, how does the client obtain the rest of the chain? On that point, is it meaningful to have usage=2 and selector=1, and if so, how does the client obtain the certificate referred to by the SubjectPublicKeyInfo in the TLSA record? And I apologize if a similar but shorter message shows up on the list at some point; I tried sending it twice from my usual email address (owens@nysernet.org) but it did not appear to go through. I've yet to hear back from the IETF mail support folks about what might be going on. Bill. From zack.weinberg@gmail.com Thu Jan 26 19:29:00 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CBDB11E8088 for ; Thu, 26 Jan 2012 19:29:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GEKfp5bA+VEc for ; Thu, 26 Jan 2012 19:28:59 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8094911E8074 for ; Thu, 26 Jan 2012 19:28:59 -0800 (PST) Received: by mail-tul01m020-f172.google.com with SMTP id wc12so1516791obb.31 for ; Thu, 26 Jan 2012 19:28:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=H4V+O9OyZngKuf1AuMgdy5SooS83vvHFe9x5F0nYlNw=; b=KyfyG4XyAJn+z2wfSbQhCdp9vEIpAQj8jvZKoYR8DwL0GDot8VsPM0/3btVeXpZkoc yGzSNJkHeFlRMQR4xYk7f6R70GmeHx9SUF24vPyM1GzhPfw1RH4kXisci9qzeUEg/ECV +GFuikVglbnoGKSlLJW/tugCFjet3mEa5VjbA= MIME-Version: 1.0 Received: by 10.182.111.10 with SMTP id ie10mr4656813obb.77.1327634939394; Thu, 26 Jan 2012 19:28:59 -0800 (PST) Sender: zack.weinberg@gmail.com Received: by 10.182.227.69 with HTTP; Thu, 26 Jan 2012 19:28:59 -0800 (PST) In-Reply-To: References: <20120123033124.GD14597@odin.ulthar.us> <201201231921.q0NJLS1i021543@fs4113.wdf.sap.corp> <7769AE22-B0EF-48F2-86E8-AD6977F83124@vpnc.org> <3F134138-06A0-400A-9CA6-5FF55B331D04@vpnc.org> Date: Thu, 26 Jan 2012 19:28:59 -0800 X-Google-Sender-Auth: GLeiUzBEuRrchvjGLbHdoubXRm4 Message-ID: From: Zack Weinberg To: IETF DANE WG list Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [dane] Opening Issue #37. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 03:29:00 -0000 On Thu, Jan 26, 2012 at 12:36 AM, Ond=C5=99ej Sur=C3=BD wrote: > On 24. 1. 2012, at 2:24, Zack Weinberg wrote: > >> I disagree. =C2=A0The current text is saying you have to conform to RFC >> 5280 if you want to implement DANE. =C2=A0That will be taken as an argum= ent >> against implementing DANE by people who think RFC 5280 validation is >> too expensive and/or complicated. > > Zack are you saying we should consider various projects internal > politics when constructing the protocol? =C2=A0I disagree with that. Maybe (do you *want* to write a spec that nobody will implement?) but that's not really the point so let's leave it aside. My position is that we should not require RFC 5280 (or any other standardized definition of "PKIX validation") as part of DANE. My justifications for that position are: 1. Real implementations of TLS don't do RFC 5280 today; they do various ad-hoc things instead. Turning on DANE for a domain should not change that, because that's a gigantic, surprising, and inappropriate-for-this-WG-to-require side effect. 2. It is unclear -- see the big long argument in this very thread -- whether the intended behavior of type 2 TLSA records is implementable on top of RFC 5280 validation; the easiest way out of the hole is to not specify validation. (The ad-hoc things that real implementations do will be able to handle type 2 records Just Fine.) zw From bortzmeyer@nic.fr Fri Jan 27 02:04:24 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96B0621F8562 for ; Fri, 27 Jan 2012 02:04:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.433 X-Spam-Level: X-Spam-Status: No, score=-102.433 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OR-bA5PZlmPU for ; Fri, 27 Jan 2012 02:04:24 -0800 (PST) Received: from mx2.nic.fr (mx2.nic.fr [IPv6:2001:660:3003:2::4:11]) by ietfa.amsl.com (Postfix) with ESMTP id CFE4421F84B8 for ; Fri, 27 Jan 2012 02:04:23 -0800 (PST) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id BE6641C0112; Fri, 27 Jan 2012 11:04:22 +0100 (CET) Received: by mx2.nic.fr (Postfix, from userid 500) id A7B1D1C011A; Fri, 27 Jan 2012 11:04:22 +0100 (CET) Received: from relay1.nic.fr (relay1.nic.fr [IPv6:2001:67c:2218:9::4:162]) by mx2.nic.fr (Postfix) with ESMTP id 99E551C0112; Fri, 27 Jan 2012 11:04:22 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [IPv6:2001:67c:2219:8::6:69]) by relay1.nic.fr (Postfix) with ESMTP id 97A404C007F; Fri, 27 Jan 2012 11:04:22 +0100 (CET) Date: Fri, 27 Jan 2012 11:04:22 +0100 From: Stephane Bortzmeyer To: Bill Owens Message-ID: <20120127100422.GA16397@nic.fr> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux wheezy/sid X-Kernel: Linux 3.1.0-1-686-pae i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.21 (2010-09-15) X-Bogosity: No, tests=bogofilter, spamicity=0.000002, version=1.1.5 X-PMX-Version: 5.4.6.353000, Antispam-Engine: 2.6.1.350677, Antispam-Data: 2012.1.27.95115 X-PerlMx-Spam: Gauge=IIIIIII, Probability=8%, Report='BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1100_1199 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CD 0, __CT 0, __CT_TEXT_PLAIN 0, __FRAUD_BODY_WEBMAIL 0, __FRAUD_WEBMAIL 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __TO_MALFORMED_2 0, __URI_NO_PATH 0, __URI_NO_WWW 0, __USER_AGENT 0' Cc: dane@ietf.org Subject: Re: [dane] Comments on draft-ietf-dane-protocol-14 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 10:04:24 -0000 On Thu, Jan 26, 2012 at 09:36:58PM -0500, Bill Owens wrote a message of 86 lines which said: > The document also talks about CA certificates and trust anchors, and > I believe that usage is consistent. They are different things. A CA certificate has the CA bit set. A trust anchor is a certificate which is used to start a validation chain. You may have a CA certificate which is not a trust anchor (because you don't trust that CA, for instance). > Finally in the pseudocode, I believe that I can follow the > processing except for the appearance of the PKIX validation chain H > in in the usage=2 case. Wouldn't the chain consist only of R, which > was provided by the TLSA record? If not, how does the client obtain > the rest of the chain? In the TLS negotation (several certificates can be sent by the server and it is its responsability to include a complete chain). > On that point, is it meaningful to have usage=2 and selector=1, > and if so, how does the client obtain the certificate referred to by > the SubjectPublicKeyInfo in the TLSA record? Same thing, I would say. RFC 5246, section 7.4.2 seems clear about it. From warren@kumari.net Fri Jan 27 15:36:24 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB7E21F861F for ; Fri, 27 Jan 2012 15:36:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.472 X-Spam-Level: X-Spam-Status: No, score=-106.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LciXQKAUZkrt for ; Fri, 27 Jan 2012 15:36:24 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id F0DC521F8618 for ; Fri, 27 Jan 2012 15:36:23 -0800 (PST) Received: from [192.168.0.12] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 0BC681B4116E for ; Fri, 27 Jan 2012 18:36:22 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1084) From: Warren Kumari In-Reply-To: <1D5610EF-1AB3-4CDE-A4E9-10D16C103E0E@cisco.com> Date: Fri, 27 Jan 2012 18:36:28 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5E65EFCF-2CD8-4129-B0A6-CA50EFFB2995@kumari.net> References: <63313B7F-BEA9-46C9-9E86-4E2597988F04@vpnc.org> <9C838E12-4909-47B1-B5DE-A5D4EF394C9A@bbn.com> <4F15DDF3.90307@ogud.com> <6AFCA86D-81BB-488C-90C8-0CFE736BE664@bbn.com> <11720A93-A129-4847-832C-6E51B32C8B1A@vpnc.org> <8B45AB89-FA6D-40B9-A72E-4F7EC355A5DC@vpnc.org> <20120126131634.GA4693@odin.ulthar.us> <4F2155B1.8050908@stpeter.im> <1D5610EF-1AB3-4CDE-A4E9-10D16C103E0E@cisco.com> To: IETF DANE WG list X-Mailer: Apple Mail (2.1084) Subject: Re: [dane] Opening issue #28 - Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 23:36:24 -0000 Hi all, Thank you all very much for all of your input and discussions on Issue = #28 (Interaction of SRV and TLSA records). While we would like to have settled on a one size fits all, it doesn't = seem like we are going to be able to get consensus on that, so: Unless we hear strong objections, we are going to go with the scheme = that had (rough) consensus: "use the first name that has a TLSA record, = unless there is a protocol specific exception" scheme. This solutions = solves the vast majority of cases, and still allows protocols that need = special handling the ability to define it. *After* we have launched the protocol doc, we will discuss: 1: Rechartering DANE to work on the "Using DANE to work with = Protocol_foo" documents (where foo is, for example, MX, SIP, XMPP / = whatever) 2: Handing off these documents to other working groups (assuming they = exist and are willing to work on this) 3: Individual submissions or some combination of the above. Our AD is supportive of this plan (the "After we have launched=85" bit), = but we will need to get the current work ( -protocol- ) completed before = starting on the new docs. We are also NOT opening up the "Which one (or = combination) of 1, 2, 3 are we going to do, and for what protocols" yet. = We have enough to do and opening yet another can-of-worms^W discussion = will just distract us further. Again, we thank you for all of the work and passion that has gone into = Issue #28 (and all the others), and for minimizing the drama. Ondrej and Warren. --=20 With Feudalism, it's your Count that votes. From paul.hoffman@vpnc.org Sat Jan 28 12:09:46 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6900121F85B4 for ; Sat, 28 Jan 2012 12:09:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJ0s9S0eXRgy for ; Sat, 28 Jan 2012 12:09:46 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id C515B21F85AF for ; Sat, 28 Jan 2012 12:09:42 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q0SK9f9w013469 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 28 Jan 2012 13:09:42 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1251.1) From: Paul Hoffman In-Reply-To: <5E65EFCF-2CD8-4129-B0A6-CA50EFFB2995@kumari.net> Date: Sat, 28 Jan 2012 12:09:41 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6B227F55-22E9-46F6-B2F7-38E813BC55EB@vpnc.org> References: <63313B7F-BEA9-46C9-9E86-4E2597988F04@vpnc.org> <9C838E12-4909-47B1-B5DE-A5D4EF394C9A@bbn.com> <4F15DDF3.90307@ogud.com> <6AFCA86D-81BB-488C-90C8-0CFE736BE664@bbn.com> <11720A93-A129-4847-832C-6E51B32C8B1A@vpnc.org> <8B45AB89-FA6D-40B9-A72E-4F7EC355A5DC@vpnc.org> <20120126131634.GA4693@odin.ulthar.us> <4F2155B1.8050908@stpeter.im> <1D5610EF-1AB3-4CDE-A4E9-10D16C103E0E@cisco.com> <5E65EFCF-2CD8-4129-B0A6-CA50EFFB2995@kumari.net> To: IETF DANE WG list X-Mailer: Apple Mail (2.1251.1) Subject: [dane] Closing issue #28 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2012 20:09:46 -0000 On Jan 27, 2012, at 3:36 PM, Warren Kumari wrote: > Thank you all very much for all of your input and discussions on Issue = #28 (Interaction of SRV and TLSA records). > While we would like to have settled on a one size fits all, it doesn't = seem like we are going to be able to get consensus on that, so: >=20 > Unless we hear strong objections, we are going to go with the scheme = that had (rough) consensus: "use the first name that has a TLSA record, = unless there is a protocol specific exception" scheme. This solutions = solves the vast majority of cases, and still allows protocols that need = special handling the ability to define it. Good stuff. Jakob and I have found an easy way to put this into the next = draft. --Paul Hoffman From jakob@kirei.se Sat Jan 28 12:39:59 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B422C21F8547 for ; Sat, 28 Jan 2012 12:39:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78JOiXfUtf1P for ; Sat, 28 Jan 2012 12:39:59 -0800 (PST) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id 3839B21F84EE for ; Sat, 28 Jan 2012 12:39:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=MRaPgBIzsrN53QbQOCYnZ/Lcl/hwJMo9n5R/EKgkpRo=; b=crhppvJEoQb+/Gkfkbhr562LRLCdnUKhVarY/5WPel8nHClP72T8U9wUbvFizXK8edLahgMK2R+sA FUko2rJj1HoVDosiF5/WGuT/WtkXYQJ3GMO1iR46AAn3GLKVI1iO3p0rAhMuSMWXhgf4yvR2E6XzDB oajEvdAYlxqhoGl0= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Sat, 28 Jan 2012 21:39:43 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: Date: Sat, 28 Jan 2012 21:39:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <49D697D1-761F-4DF2-B34F-E5BED8DF638A@kirei.se> References: To: Bill Owens X-Mailer: Apple Mail (2.1251.1) Cc: dane@ietf.org Subject: Re: [dane] Comments on draft-ietf-dane-protocol-14 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2012 20:39:59 -0000 On 27 jan 2012, at 03:36, Bill Owens wrote: > I think there is one use of the word, meaning the certificate > presented by the TLS server during the opening of the TLS connection; > that object is called by the following names: > 'certificate' : 31 times > 'server's certificate' : 4 times > 'PKIX certificate' : 5 times > 'end entity certificate' : 7 times > 'certificate from TLS' : 1 time The word 'certificate' is used in different contexts, sometimes a = certificate in general is described, sometimes the very cert from the = TLS server. I'll try to make another pass - perhaps it will be clearer. > Likewise, the data included in the TLSA record are called: > 'certificate association' : 15 times > 'certificate for association' : 4 times > Occasionally it is referred to as simply a certificate, for example in > the first paragraph of section 1.2. I've cleaned this up, the field is now called "certificate association = data" (as it can be either a cert or a hash-of-cert). > There are a few other small changes that the authors might want to = consider: >=20 > - Section 1.2 says "This document does not specify how DNSSEC > validation occurs...", but then goes on to make such a suggestion in > Section 4.4, and leaves a placeholder for discussing last-hop issues > in the Appendix. Yes, we need to revisit this sentence when write the appendix. > - Section 4.1 refers to "the public key of such a certificate, that > the must be found in any of the PKIX validation chains" Should there > be something between "the" and "must", or is "the" a typo? Fixed. > - Section 4.4 talks about "how to match the identify given in a PKIX > certificate" - should that be "identity", or "identifier", or ? Fixed. > - Also in Section 4.4, the paragraph about clients is confusingly > written. I think that it means to say something like this: >=20 > Clients that validate the DNSSEC signatures themselves MUST use > standard DNSSEC validation procedures. Clients that rely on another > entity to perform the DNSSEC signature validation MUST use a secure > transport (such as TSIG...) between themselves and the validator. Note > that it is not sufficient to use secure transport to a DNS resolver > that does not do DNSSEC signature validation. Thanks. > - The paragraph on SSL proxies in Section 8 ends with the statement > "Thus, such proxies might choose to aggressively block TLSA requests > and/or responses." I think that would be a downgrade attack, which is > prevented by authenticated denial of existence. We'll looking into this. > - Minor wording: Appendix A.1.1 is missing "the" in the last sentence > ("client builds the trust chain") and A.1.2.1 likewise in the first > sentence ("provides the most precise") Fixed. > Finally in the pseudocode, I believe that I can follow the processing > except for the appearance of the PKIX validation chain H in in the > usage=3D2 case. Wouldn't the chain consist only of R, which was = provided > by the TLSA record? If not, how does the client obtain the rest of the > chain? On that point, is it meaningful to have usage=3D2 and = selector=3D1, > and if so, how does the client obtain the certificate referred to by > the SubjectPublicKeyInfo in the TLSA record? We'll looking into this separately. Thanks you for all your comments, jakob From ondrej.sury@nic.cz Tue Jan 31 01:07:04 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAE3C21F8757 for ; Tue, 31 Jan 2012 01:07:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.956 X-Spam-Level: X-Spam-Status: No, score=-0.956 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4u+Op96z1Wxh for ; Tue, 31 Jan 2012 01:07:04 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id E1EE221F8750 for ; Tue, 31 Jan 2012 01:07:03 -0800 (PST) Received: from [IPv6:2001:1488:ac14:1400:f408:ddc0:8033:956c] (unknown [IPv6:2001:1488:ac14:1400:f408:ddc0:8033:956c]) by mail.nic.cz (Postfix) with ESMTPSA id A225A2A3054; Tue, 31 Jan 2012 10:07:01 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1328000821; bh=tGQl+f3drzytnoFwGFwNJugJ6UXEQDzYpn5ZfoDVWcw=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=O72u9f37HUA0J5zqFhB3Fwn+dAaq1hoY4gOm5obB/jFsYMQVtatK02M+d5cMqIJSt Kt+JNXWfly9ur2HxlZAAmLjQHORJCpBa5otXTrScCPQuuTf8e/UX+UkJQsBYnD+6N0 UW8WI3UTPR7xHwIa1Irak9nluJtPV+PeCLY0cPS0= Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: Date: Tue, 31 Jan 2012 10:07:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120123033124.GD14597@odin.ulthar.us> <201201231921.q0NJLS1i021543@fs4113.wdf.sap.corp> <7769AE22-B0EF-48F2-86E8-AD6977F83124@vpnc.org> <3F134138-06A0-400A-9CA6-5FF55B331D04@vpnc.org> To: Zack Weinberg X-Mailer: Apple Mail (2.1251.1) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: IETF DANE WG list Subject: Re: [dane] Opening Issue #37. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 09:07:05 -0000 IETF is a standardization organization and should work on top of existing standards. I fully understand your position, but we need to keep a level of consistency within IETF. If that will be used as an argument against implementing DANE, it will be sad, but I don't really think it will be the main showstopper. It's joint wish of chairs to not loosen the requirements for PKIX validation in the draft. If the rest of the WG care, you should speak now. Ondrej P.S.: It seems that we have a different directions in this thread and I'm going to handle them case by case. So expect more emails in a minute. This is only part where I handle Zack's request to drop PKIX validation. On 27. 1. 2012, at 4:28, Zack Weinberg wrote: > On Thu, Jan 26, 2012 at 12:36 AM, Ond=C5=99ej Sur=C3=BD = wrote: >> On 24. 1. 2012, at 2:24, Zack Weinberg wrote: >>=20 >>> I disagree. The current text is saying you have to conform to RFC >>> 5280 if you want to implement DANE. That will be taken as an = argument >>> against implementing DANE by people who think RFC 5280 validation is >>> too expensive and/or complicated. >>=20 >> Zack are you saying we should consider various projects internal >> politics when constructing the protocol? I disagree with that. >=20 > Maybe (do you *want* to write a spec that nobody will implement?) but > that's not really the point so let's leave it aside. >=20 > My position is that we should not require RFC 5280 (or any other > standardized definition of "PKIX validation") as part of DANE. >=20 > My justifications for that position are: >=20 > 1. Real implementations of TLS don't do RFC 5280 today; they do > various ad-hoc things instead. Turning on DANE for a domain should > not change that, because that's a gigantic, surprising, and > inappropriate-for-this-WG-to-require side effect. >=20 > 2. It is unclear -- see the big long argument in this very thread -- > whether the intended behavior of type 2 TLSA records is implementable > on top of RFC 5280 validation; the easiest way out of the hole is to > not specify validation. (The ad-hoc things that real implementations > do will be able to handle type 2 records Just Fine.) >=20 > zw > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From ondrej.sury@nic.cz Tue Jan 31 01:21:34 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B045F21F855E for ; Tue, 31 Jan 2012 01:21:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.594 X-Spam-Level: X-Spam-Status: No, score=-1.594 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amybGpAx8Jnc for ; Tue, 31 Jan 2012 01:21:34 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id A847121F8554 for ; Tue, 31 Jan 2012 01:21:33 -0800 (PST) Received: from [IPv6:2001:1488:ac14:1400:f408:ddc0:8033:956c] (unknown [IPv6:2001:1488:ac14:1400:f408:ddc0:8033:956c]) by mail.nic.cz (Postfix) with ESMTPSA id E65DB2A2F45; Tue, 31 Jan 2012 10:21:32 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1328001692; bh=fkQPhpthYPnt1X1udKsC1SsrWFXHgK9HpPUh8XuBtZs=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=r59HK2immw50Ij3mI3Q1dbe0AL6LPu+KKRZjjBd7qB+N+DVud3JMKPhJMwxgNNYGX Ai+N5/JtGv1+xN1/xJuNi5Fw0WCEO9cF4xe8rn5OWzW5MNpPEMGzgY736ACk2ml4s6 6vKqr972AIN9rQvIoVL8tjlFiZ5rWLPKHwZk+0rA= Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <201201241859.q0OIxuGI011754@fs4113.wdf.sap.corp> Date: Tue, 31 Jan 2012 10:21:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1D9EEB84-8B84-4187-BB1C-E07DB561F82C@nic.cz> References: <201201241859.q0OIxuGI011754@fs4113.wdf.sap.corp> To: mrex@sap.com, Matt McCutchen X-Mailer: Apple Mail (2.1251.1) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Paul Hoffman , dane@ietf.org Subject: [dane] Call for last comments on issue #37. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 09:21:34 -0000 Martin, Matt, it seems this thread is either unimportant or very hard to understand to the rest of the working group (and I must admit it's very hard for me to understand the underlying problem). Would you be willing to accept this partial solution, so we can move on with the draft? If not would you be willing to propose a specific text we can work on? It would also help for clarity of the issue to have a text which can be incorporated into the draft. =46rom the chair viewpoint I think it's more important to stick to = existing standards than to cover every possible use case. If there's one working way how to deploy EE-certificate without using existing CAs (trust = anchors) I am perfectly happy even if it's not the easiest way possible. Writing a good step-by-step HOWTO is a perfect way how to solve this. I think we have discussed this issue long enough and haven't gotten = anywhere, so I am inclined to close this issue and leave the draft as is. If = other WG members has some opinion please speak now, I'll leave some time to = Martin and Matt to propose a specific text and call for consensus in a few = days. Ideally I would like to see this issue closed at the end of this week. Ondrej On 24. 1. 2012, at 19:59, Martin Rex wrote: > Paul Hoffman wrote: >>=20 >> 2 -- The target certificate MUST pass PKIX validation, with the SPKI = of >> the TLSA record considered to be a trust anchor >> for this validation >>=20 >> If so, it might satisfy Martin's concern as well. >=20 > That is only a partial solution. >=20 > Usage case 2 covers three different variants: >=20 > (1) Server uses self-signed cert, TLSA identifies self-signed cert >=20 > (2) Server uses CA-issued cert from private CA, TLSA identifies > a CA-certificate from the Server's certifcation path >=20 > (3) Server uses CA-issued cert from private CA, TLSA identifies > the server's CA-issued cert directly >=20 > Only for (1) and (2) a PKIX (certificate path) validation could be > specified, it is *IMPOSSIBLE* to perform a PKIX validation for (3). >=20 > I would also appreciate if PKIX validation and rfc-2818 server = endpoint > identification would not be conflated by dane-protocol. >=20 >=20 > rfc-2818 server endpoint identification makes sense for traditional > PKIX-based server identification, because this is how the CA asserts > for which DNS domain name the server certificate was issued. >=20 > For DANE, the existence of the TLSA record already provides the = binding > to the DNS domain name. So this WG is in principle free to specify > whether or not the DANE-part of the validation looks at name = attributes > of the server certificate. >=20 > But for usage types 0 and 1 a PKIX-based endpoint identification = should > be performed for consistency with the existing endpoint = identification, > which narrows this down to usage type 2. >=20 > doing name matching makes DANE-only scenarios (usage type 2) > more difficult to configure (usability), and may require additional > TLS features to be available and employed for multihoming and virtual > hosting. If name-matching is required for the DANE part as well, > then it would later be easier to switch a productive setup from > usage type 2 to usage type 0 or 1. >=20 > An additional check in the DANE-part adds complexity (more code, > more cpu cycles) and requires some amount of synchronization between > potentially independent software modules (the part that performs > server endpoint identification in the PKIX world and the part > that performs server endpoint identification in the DANE part). >=20 >=20 > -Martin >=20 >=20 >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From tom@ritter.vg Tue Jan 31 07:24:32 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE11111E8081 for ; Tue, 31 Jan 2012 07:24:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.827 X-Spam-Level: X-Spam-Status: No, score=-2.827 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kDXfrAWIsX3 for ; Tue, 31 Jan 2012 07:24:31 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id AC2CF21F8513 for ; Tue, 31 Jan 2012 07:24:30 -0800 (PST) Received: by wibhm9 with SMTP id hm9so71129wib.31 for ; Tue, 31 Jan 2012 07:24:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=Ggy759q+qUeBwuY542Txh9Vnd+jTvE0yEmlQuObI9oI=; b=lyaIfe7zraQ6wMCJ1wZKz7JfEM6ieblHOCyhrhEsHSPGDw7Ke+O9q8vAqibzw0bV7R 8UQtOpgitR58I13AB8o5Aed6xRobOeVVa31VVg9kzXruqTzbZHiUBg1e5tEbbtIjaoov e+lbCGrtcxbMhR4c5IAMwXHXRbVPryhIXjHWA= Received: by 10.180.87.8 with SMTP id t8mr4480105wiz.15.1328023469769; Tue, 31 Jan 2012 07:24:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.1.137 with HTTP; Tue, 31 Jan 2012 07:24:09 -0800 (PST) In-Reply-To: <1D9EEB84-8B84-4187-BB1C-E07DB561F82C@nic.cz> References: <201201241859.q0OIxuGI011754@fs4113.wdf.sap.corp> <1D9EEB84-8B84-4187-BB1C-E07DB561F82C@nic.cz> From: Tom Ritter Date: Tue, 31 Jan 2012 10:24:09 -0500 Message-ID: To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: dane@ietf.org Subject: Re: [dane] Call for last comments on issue #37. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 15:24:32 -0000 On 31 January 2012 04:21, Ond=C5=99ej Sur=C3=BD wrote: > it seems this thread is either unimportant or very hard to understand > to the rest of the working group (and I must admit it's very hard for > me to understand the underlying problem). Put a mark in the 'very hard to understand, but important to' column for me= . > If there's one working > way how to deploy EE-certificate without using existing CAs (trust anchor= s) > I am perfectly happy even if it's not the easiest way possible. =C2=A0Wri= ting > a good step-by-step HOWTO is a perfect way how to solve this. I am most interested in deploying EE certificates without using existing CAs (trust anchors). I also am okay with a more-complicated but existing mechanism. And I would greatly appreciate a HOWTO. As I read section 4.3 of -14 - I was *not confused*, and thought I would just drop the self-signed cert or public key of the self-signed cert in the TLSA record, return only my self-signed cert (1 cert, no chain), and be good to go. This discussion implies to me that this is not the case, and therefore what I thought was not confusing, must be so confusing I don't even know enough to be confused. My confusion may center around passing "PKIX Validation" - I confess I'm not certain of what that all entails. -14 does not define it explicitly, and I'm not sure if its use is colloquial[1] or specific[2]. I'm sure the specific version states that it must chain to a trust anchor without specifying standards for trust anchors, in which case section 4.3 of -14 would work (because it would add the TLSA record as a trust anchor). Colloquially, I fear implementors would interpret "PKIX Validation" to also include chaining to one of the root certs in a machine/device/software repository, and Section 4.3 of -14 would not work. [1] Colloquial being the approximation that vendors have deployed, and what 'most people' would say off the top of their heads if you asked them: Must chain to a root cert in a repository, checking basicConstraints, etc [2] Specific being I'm-still-not-sure but maybe RFC 5280 Section 6? If everyone else is having the same problem I'm having, adding a HOWTO and defining 'PKIX validation' would help. -tom From cloos@jhcloos.com Tue Jan 31 09:49:56 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A74521F852B for ; Tue, 31 Jan 2012 09:49:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.136 X-Spam-Level: X-Spam-Status: No, score=-2.136 tagged_above=-999 required=5 tests=[AWL=0.464, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hXrY04T-c81M for ; Tue, 31 Jan 2012 09:49:55 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by ietfa.amsl.com (Postfix) with ESMTP id 848D021F8523 for ; Tue, 31 Jan 2012 09:49:55 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id ED8FF40141; Tue, 31 Jan 2012 17:49:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1328032194; bh=VNFOOIozPmNH5ICXNF1q4JhUvg02Q95oXrgYwoHESdo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=fJjeMbK9G63+5a9S7KENYZZ2OUaNXQeRlIxV/Tjs7yi4+pBwceuE7RhBMXESVooKo B01ePX3pyXgtXB7KmkFvZof+k++FGVJCQiK4/BAcK7DO7kumZUETTvTl4koeE+nWfs p7dPuIje/9VMMTfhSQfbo6p63WKoCWPFivaQtvHM= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 26CD536004C; Tue, 31 Jan 2012 17:45:53 +0000 (UTC) From: James Cloos To: dane@ietf.org In-Reply-To: (Tom Ritter's message of "Tue, 31 Jan 2012 10:24:09 -0500") References: <201201241859.q0OIxuGI011754@fs4113.wdf.sap.corp> <1D9EEB84-8B84-4187-BB1C-E07DB561F82C@nic.cz> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.92 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2012 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Tue, 31 Jan 2012 12:45:53 -0500 Message-ID: Lines: 40 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:120131:dane@ietf.org::DV1k0UEYge1pPpBO:000D+wls X-Hashcash: 1:30:120131:tom@ritter.vg::f5V+hl6k+rHruo9H:0003jrL+ Subject: Re: [dane] Call for last comments on issue #37. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 17:49:56 -0000 >>>>> "TR" == Tom Ritter writes: TR> thought I would just drop the self-signed cert or public key of the TR> self-signed cert in the TLSA record, return only my self-signed cert TR> (1 cert, no chain), and be good to go. This is exaclty the use case to which type 2 SHOULD cater. TR> My confusion may center around passing "PKIX Validation" - I confess TR> I'm not certain of what that all entails. And the best way for type 2 to cater to it would be to avoid demanding "PKIX Validation". It should be possible to configure a tls server to offer a chain of one or more certs, any one of which matches the dane type 2 certification, and expect dane-aware tls clients to accept that as a valid and secure association. One might want the tls server to send a chain of more than one cert to support non-dane tls clients (in which case the chain likely also would be signed by an otherwise-trusted root cert). Or one might want to use a dane type2 rr to trust one's own, private root cert. The latter case, of course, facilitates publishing the same TLSA RR on multiple paths, just like a tlsa type 1 does. So, what wording says that, "iff there are multiple tls certs in the chain from the cert which matches the tls server's private key through to the tls cert matching the TLSA type 2 RR, then that chain MUST, *internally*, be a valid chain as described in the tls standard(s)", without requiring that said chain be rooted anywhere? Or be constrained by anything other than TLSA? And without confusing anyone? [ Hoping that my above wording is clear :) ] -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From mrex@sap.com Tue Jan 31 15:08:07 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEC121F8585 for ; Tue, 31 Jan 2012 15:08:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.361 X-Spam-Level: X-Spam-Status: No, score=-9.361 tagged_above=-999 required=5 tests=[AWL=-0.657, BAYES_00=-2.599, HELO_EQ_DE=0.35, INVALID_DATE=1.245, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7DOs0QOcSNkM for ; Tue, 31 Jan 2012 15:08:06 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB1421F8584 for ; Tue, 31 Jan 2012 15:08:05 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q0VN837Y011035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 1 Feb 2012 00:08:03 +0100 (MET) From: Martin Rex Message-Id: <201201312308.q0VN82IP003373@fs4113.wdf.sap.corp> To: ondrej.sury@nic.cz (=?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?=) In-Reply-To: <1D9EEB84-8B84-4187-BB1C-E07DB561F82C@nic.cz> from "=?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?=" at Jan 31, 12 10:21:32 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: paul.hoffman@vpnc.org, dane@ietf.org Subject: Re: [dane] Call for last comments on issue #37. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Tue, 31 Jan 2012 23:08:07 -0000 X-Original-Date: Wed, 1 Feb 2012 00:08:02 -74300 (MET) X-List-Received-Date: Tue, 31 Jan 2012 23:08:07 -0000 Ondrej wrote: > > Would you be willing to accept this partial solution, so we can move > on with the draft? If not would you be willing to propose a specific > text we can work on? It would also help for clarity of the issue to > have a text which can be incorporated into the draft. Asking for proposed text is fair an reasonable. I'll try to come up with something. The issue with "PKIX validation" is that this is probably the most fuzzy thing that exists within the IETF. But rfc5280 itself RECOMMENDs to be laissez-faire about a number of things it specifies: Quoting from rfc5280, section 6.1 Basic Path validation (3rd paragraph): http://tools.ietf.org/html/rfc5280#section-6.1 While the certificate and CRL profiles specified in Sections 4 and 5 of this document specify values for certificate and CRL fields and extensions that are considered to be appropriate for the Internet PKI, the algorithm presented in this section is not limited to accepting certificates and CRLs that conform to these profiles. Therefore, the algorithm only includes checks to verify that the certification path is valid according to X.509 and does not include checks to verify that the certificates and CRLs conform to this profile. While the algorithm could be extended to include checks for conformance to the profiles in Sections 4 and 5, this profile RECOMMENDS against including such checks. > Martin Rex wrote: > > > > Usage case 2 covers three different variants: > > > > (1) Server uses self-signed cert, TLSA identifies self-signed cert > > > > (2) Server uses CA-issued cert from private CA, TLSA identifies > > a CA-certificate from the Server's certifcation path > > > > (3) Server uses CA-issued cert from private CA, TLSA identifies > > the server's CA-issued cert directly > > > > Only for (1) and (2) a PKIX (certificate path) validation could be > > specified, it is *IMPOSSIBLE* to perform a PKIX validation for (3). > > > > I would also appreciate if PKIX validation and rfc-2818 server endpoint > > identification would not be conflated by dane-protocol. > > From the chair viewpoint I think it's more important to stick to existing > standards than to cover every possible use case. If there's one working > way how to deploy EE-certificate without using existing CAs (trust anchors) > I am perfectly happy even if it's not the easiest way possible. Writing > a good step-by-step HOWTO is a perfect way how to solve this. Iff we want usage (2) in the protocol document (the situation where a server certificate is not signed under a trust anchor from TLS X.509 PKI), then we need to define it in a fashion that it can be indepedently implemented in an interoperable fashion. Iff we refer to PKIX (rfc5280) certificate path validation, then we MUST specify which parameters to supply as input to the algorithm described in rfc5280 section 6.1. Even if many implementations of PKIX actually use a different algorithm, like one where you pass a set of trust anchors and the algorithm will look for a match of the prospective path to any of the trust anchors by itself, or an algorithm which performs certificate revocation checking concurrently with basic path validation. -Martin