From jakob@kirei.se Thu Sep 1 00:42:13 2011 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 1E3E021F8AAC for ; Thu, 1 Sep 2011 00:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.634 X-Spam-Level: X-Spam-Status: No, score=-0.634 tagged_above=-999 required=5 tests=[AWL=0.064, 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 r5NYFBmTrwct for ; Thu, 1 Sep 2011 00:42:12 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id DDE0721F8AAA for ; Thu, 1 Sep 2011 00:42:11 -0700 (PDT) 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=LuYH8frU7i50w9Jec0Bf9+QTu5ABKnUlBU1ZryTiaEs=; b=YGOBQYNY/1CCMsRYs2MwKLErdcfI2+TuORlEVL7mM2F5lii3a+nFjJ238MTLv4GJca5aMphwtiGR2 Aszn7+apWpNUPVX9MhKRrB6szU6iHaNshdB5djr5N6DWM1htu+LR17iMFAbsoH/QFho6P9k6rPfkeT cEaPjp5/OmYNSSyE= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Thu, 1 Sep 2011 09:43:23 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: <201109011413253330934@163.com> Date: Thu, 1 Sep 2011 09:43:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4CBA8AED-F76D-46DF-A2A0-0B1608E3C8C2@kirei.se> References: <201108310848003094902@163.com> <201109011413253330934@163.com> To: yzw_iplab X-Mailer: Apple Mail (2.1244.3) Cc: trac+dane , "paul.hoffman" , dane Subject: Re: [dane] #31: Multiple TLSA records in a response 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, 01 Sep 2011 07:42:13 -0000 On 1 sep 2011, at 08:13, yzw_iplab wrote: > In both cases, the authentication failure period may last for = 1/2*RTT(DNS server-TLS server). This is not correct. In case of multiple certificate associations (TLSA = RRs), any of them is enough for a match and there will will be no = authentication failure period during a rollover (as long as multiple = TLSA RR are published). jakob From ondrej.sury@nic.cz Thu Sep 1 11:14:53 2011 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 115BE21F9842 for ; Thu, 1 Sep 2011 11:14:53 -0700 (PDT) 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 hD0ohYspbW6I for ; Thu, 1 Sep 2011 11:14:52 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 5BDC721F9840 for ; Thu, 1 Sep 2011 11:14:51 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:a1b8:8550:4f1b:aebd] (unknown [IPv6:2001:1488:ac14:1400:a1b8:8550:4f1b:aebd]) by mail.nic.cz (Postfix) with ESMTPSA id C21C12A034F; Thu, 1 Sep 2011 20:16:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1314900981; bh=OhbOzCDk6vERZ8oSqm6ObFbdHK5Ijh3XiEJgumuFLHw=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=hKnTA5lhk3Hx//O/jH6pknlcLYvHwachHpXeVbI8OuPRkP680mhzR+u7bm8LT7gXb VK3AH8WIELd2KleIPwsDIS3tjuYCfDl6l6kCDFT2JIuAE+XiZtGpsjQl8LT9nUX7ae D+h3qI0Ymw2FV9m5tB1erkC+AgY6i1dczlHmu/eQ= Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <201109011639444268036@163.com> Date: Thu, 1 Sep 2011 20:16:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201108310848003094902@163.com>, <201109011413253330934@163.com>, <4CBA8AED-F76D-46DF-A2A0-0B1608E3C8C2@kirei.se> <201109011639444268036@163.com> To: DANE WG X-Mailer: Apple Mail (2.1244.3) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: yzw_iplab , Paul Hoffman Subject: Re: [dane] #31: Multiple TLSA records in a response 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, 01 Sep 2011 18:14:53 -0000 Jakob, Paul, I have quickly re-read the dane-protocol-10 and the confusion might come from the fact that we don't explicitly state anywhere that you might have more TLSA records in the 4.4. On 1. 9. 2011, at 10:39, yzw_iplab wrote: > In order to fix it, the first case is the best choice. I don't believe there's anything to be fixed in the protocol. It's implicitly stated in this (and following paragraph): An application that requests TLS certificate associations using the method described in this document obtains zero or more usable certificate associations. If the application receives zero usable certificate associations, it processes TLS in the normal fashion. However I feel this might need little clarification in the DANE protocol document, explicitly stating that there could be one or more TLSA = records at the same owner. > I mean the protocol draft should manifest the update process I believe this should go to the operational document, not into the = protocol. > and it should explain that the client should use all the TLSA RRs got = from the DNS response for the authentication (e.g., when the client gets = old TLSA RR and new TLSA RR, it should use the two RRs to authenticate = the TLS server). When all the TLSA RRs are failed to authenticate the = server, the TLS authentication association is unusable. Any one of the = multiple TLSA RRs can successfully authenticate the server, the process = can be continued. This is stated in the DANE protocol draft (last paragraph of 4.4): If a match between one of the certificate association(s) and the server's end entity certificate in TLS is found, the TLS client continues the TLS handshake. If no match between the usable certificate association(s) and the server's end entity certificate in TLS is found, the TLS client MUST abort the handshake with an "access_denied" error. There's nothing as old and new from the client view (e.g. the client has = no knowledge about NEW and OLD). 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 warren@kumari.net Fri Sep 2 11:32:12 2011 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 4B8CF21F8C64 for ; Fri, 2 Sep 2011 11:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.47 X-Spam-Level: X-Spam-Status: No, score=-102.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 izFqPG3AHb9Z for ; Fri, 2 Sep 2011 11:32:11 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 8AAF321F8C5D for ; Fri, 2 Sep 2011 11:32:11 -0700 (PDT) Received: from dhcp-172-19-118-218.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 8979A1B416D9; Fri, 2 Sep 2011 14:33:45 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <5ED4A3CB-0064-4809-9799-0D5A52552C81@kumari.net> Date: Fri, 2 Sep 2011 14:33:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <056.21c83c2b666513905539b3ccb6df6a31@trac.tools.ietf.org> <84B49D08-BE8A-4E02-9EF1-24E993856FF5@vpnc.org> <54C1B56E-7673-4F32-8E7B-25959C121A03@bbn.com> <91A5DF74-6DCB-4530-96A4-46786AB62FCB@vpnc.org> <5F91C397-05BE-4A8A-A5DD-B02B0A832C21@kumari.net> <53597CBD-8E3F-4A66-98BE-720C609B2B0C@kirei.se> <71E8458F-CC74-4AFB-B3B7-520A711F56A4@vpnc.org> <833020D5-E3F1-4253-9876-B54748B92DDA@kirei.se> <5ED4A3CB-0064-4809-9799-0D5A52552C81@kumari.net> To: Warren Kumari X-Mailer: Apple Mail (2.1084) Cc: Paul Hoffman , DANE WG Subject: Re: [dane] #29: Request new Reference Type - Public Key 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, 02 Sep 2011 18:32:12 -0000 On Aug 30, 2011, at 10:43 AM, Warren Kumari wrote: >=20 > On Aug 25, 2011, at 1:57 PM, Jakob Schlyter wrote: >=20 >> On 25 aug 2011, at 17:56, Paul Hoffman wrote: >>=20 >>> The problem we are having in agreeing on terms is that we don't = agree to the use cases for a TLSA record that has a SPKI-not-in-a-cert = in it. The most vocal proponents of providing an SPKI-not-in-a-cert is = no PKIX validation, just exact matching with the end entity certificate = or SPKI-not-in-a-cert provided in TLS. Others want to maybe also be able = to use SPKI-not-in-a-cert for the kinds of matching that will also = involve PKIX validation. >>=20 >> Yes, I forgot about the difference between "require PKIX, match on = SPKI" and "ignore PKIX, match on SPKI" - thanks for pointing that out. >>=20 >>> My feeling is that the easiest way out of this is to let the = SPKI-not-in-a-cert folks have their own usage type that explicitly says = "SPKI-not-in-a-cert from the TLS Certificate message MUST match the TLSA = record". Using Jakob's three-part taxonomy, there would be a fourth = usage type, and any record with that usage type would have to use "SPKI" = and otherwise be ignored as bad; the matching type could be either full = or hashed. I don't think that adding a usage type that has to have a = specific selector type is that dangerous. >=20 >=20 > So, from the "Please indicate a preference" mail = (http://www.ietf.org/mail-archive/web/dane/current/msg03272.html) the = chairs see consensus for option #3 ('Richard's "very different" = proposal'). >=20 > This below suggestions is a small revision to that, and I wanted to = confirm with the WG that this 3 fields revision is acceptable (just the = 3 fields revision, not the "Ignore PKIX, match the TLSA record" bit). >=20 > This feels like a minor cleanup to us, no on has objected on list, and = so: > a: silence will be taken as consent > b: we will call this at 16:00GMT on September 2nd. Ok, and we are calling it. While not universal, the chairs see consensus for this proposal. We would like to thank the working group for staying focused... W >=20 > W >=20 >> Given Paul's feedback, my proposal would have three fields (in = addition to the association data itself): >>=20 >> usage: >> - 0. Certificate MUST pass PKIX validation and MUST chain through a = CA certificate matching the TLSA record >> - 1. Certificate MUST pass PKIX validation and MUST match the TLSA = record >> - 2. Certificate MUST pass PKIX validation, with any certificate = matching the TLSA record considered to be a trust anchor for this = validation >> - (future) 3. Ignore PKIX, match the TLSA record >>=20 >> selector: >> - 0. Certificate >> - 1. SubjectPublicKeyInfo >>=20 >> matching type: >> - 0. match on exact selected contents >> - 1. sha-256 hash of selected contents >> - 2. sha-512 hash of selected contents >>=20 >>=20 >> jakob >>=20 >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >>=20 >=20 From warren@kumari.net Fri Sep 2 11:36:18 2011 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 09FF621F8B53 for ; Fri, 2 Sep 2011 11:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.474 X-Spam-Level: X-Spam-Status: No, score=-102.474 tagged_above=-999 required=5 tests=[AWL=0.125, 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 Ihq1E-1GjthZ for ; Fri, 2 Sep 2011 11:36:17 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 59E8821F8B5E for ; Fri, 2 Sep 2011 11:36:17 -0700 (PDT) Received: from dhcp-172-19-118-218.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 3689C1B404D8; Fri, 2 Sep 2011 14:37:53 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Warren Kumari In-Reply-To: <8E693634-83A1-49D4-84E0-648A1A050B7B@kumari.net> Date: Fri, 2 Sep 2011 14:37:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <665CB382-0438-44DE-952C-309C1C4E2386@kumari.net> References: <74B71A15-E1E1-4057-9C6B-4721FCC270C2@nic.cz> <006301cc5bc7$860006f0$920014d0$@augustcellars.com> <006d01cc5d21$922d7ba0$b68872e0$@augustcellars.com> <8E693634-83A1-49D4-84E0-648A1A050B7B@kumari.net> To: Warren Kumari X-Mailer: Apple Mail (2.1084) Cc: 'Paul Hoffman' , 'DANE WG' Subject: Re: [dane] Opening issue #7: Error Handling : What to do when you receive an invalid record 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, 02 Sep 2011 18:36:18 -0000 On Aug 30, 2011, at 3:30 PM, Warren Kumari wrote: > Hi there all, >=20 > We would like to call this on Friday at 16:00UTC, but would delay like = some additional input. >=20 > Is the proposed text (below) acceptable to the WG? >=20 And we are calling this this... While we only got one explicit LGTM (Thanks Bill!) the text is the = result of discussions on the list, and so we are calling consensus on = the text from Paul, with Jim's modification. Thanks, W > W >=20 >=20 > On Aug 17, 2011, at 5:06 PM, Jim Schaad wrote: >=20 >>=20 >>=20 >>> -----Original Message----- >>> From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] >>> Sent: Wednesday, August 17, 2011 8:11 AM >>> To: Jim Schaad >>> Cc: DANE WG >>> Subject: Re: [dane] Opening issue #7: Error Handling : What to do = when you >>> receive an invalid record >>>=20 >>>=20 >>> On Aug 15, 2011, at 8:49 PM, Jim Schaad wrote: >>>=20 >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On = Behalf >>>>> Of Paul Hoffman >>>>> Sent: Monday, August 15, 2011 7:40 PM >>>>> To: Ondrej Sur=FD >>>>> Cc: dane@ietf.org >>>>> Subject: Re: [dane] Opening issue #7: Error Handling : What to do >>>>> when you receive an invalid record >>>>>=20 >>>>> Make it unusable. >>>>>=20 >>>>> Current: >>>>> If a certificate association contains a reference type that is not >>>>> understood by the TLS client, that certificate association MUST be >>>>> marked as unusable. >>>>> Proposed: >>>>> If a certificate association contains a reference type or >>>>> certificate >>>> type that >>>>> is not >>>>> understood by the TLS client, that certificate association MUST be >>>>> marked as unusable. If an error occurs when comparing using >>>>> reference types that are not exact matches (such as hashes), the >>>>> certificate association MUST be marked as unusable. >>>>=20 >>>> If an error occurs when comparing using reference types, the >>>> certificate association MUST be marked as unusable. >>>>=20 >>>> -- I don't understand why there is a reason for the 'not exact >>>> matches', it should not matter as long as the comparison is done in >>>> the correct manner if you are comparing either the direct bytes or = via a >>> function such as a hash. >>>=20 >>> Good point. >>>>=20 >>>> -- Note that the statement that it be marked as unusable does not >>>> match the pseudo code in appendix B unless there is a check = someplace >>>> in the code that I missed for things which are marked unusable as >>>> oppose to a usable but failed check. >>>=20 >>> The pseudocode in Appendix B is incomplete. We will add the = following (or >>> something like it) near the beginning: >>>=20 >>> // unusable records include unknown certType, unknown certAssoc >>> // and erroneous RDATA >>> strip unusable records >>> if (no good TLSA record(s) received) { >>> fall back to "normal" cert validation >>> } >>>=20 >>> Proposed: >>> If a certificate association contains a reference type or = certificate >> type that is >>> not >>> understood by the TLS client, that certificate association MUST be >>> marked as unusable. If an error occurs when comparing, the >>> certificate association MUST be marked as unusable. >>>=20 >>> Does that resolve your concern? >>=20 >> It all looks good except for the last line in the proposed text. An >> comparison failure could be thought of as an error and in that case = you do >> not want to be marked as unusable. I think what you meant was: >>=20 >> If the comparison data for a certificate is malformed, the = certificate >> association MUST be marked as unusable. >>=20 >> Jim >>=20 >>>=20 >>> --Paul Hoffman >>=20 >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >>=20 >=20 From trac+dane@trac.tools.ietf.org Fri Sep 2 12:01:57 2011 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 8672721F8D13 for ; Fri, 2 Sep 2011 12:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 5Tjzel2wZ6pZ for ; Fri, 2 Sep 2011 12:01:57 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:123a::1:2a]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8CF21F8D11 for ; Fri, 2 Sep 2011 12:01:57 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QzZ1Z-0004RB-GP; Fri, 02 Sep 2011 12:03:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: warren@kumari.net X-Trac-Project: dane Date: Fri, 02 Sep 2011 19:03:33 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/7#comment:2 Message-ID: <064.f749a8aee8b0bbc219a81fa6a1b62536@trac.tools.ietf.org> References: <055.82d7847280663475cac02867fc62eca5@trac.tools.ietf.org> X-Trac-Ticket-ID: 7 In-Reply-To: <055.82d7847280663475cac02867fc62eca5@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 zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: dane@ietf.org Subject: Re: [dane] #7: Error Handling : What to do when you receive an invalid record 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: Fri, 02 Sep 2011 19:01:57 -0000 #7: Error Handling : What to do when you receive an invalid record Changes (by warren@…): * status: new => closed * resolution: => fixed Comment: And we are calling this this... While we only got one explicit LGTM (Thanks Bill!) the text is the result of discussions on the list, and so we are calling consensus on the text from Paul, with Jim's modification. Thanks, W ---------------------- http://www.ietf.org/mail-archive/web/dane/current/msg03327.html -- -----------------------------------+---------------------------------------- Reporter: mlepinsk@… | Owner: Type: defect | Status: closed Priority: major | Milestone: Component: protocol | Version: Severity: Candidate WG Document | Resolution: fixed Keywords: | -----------------------------------+---------------------------------------- Ticket URL: dane From bmanning@karoshi.com Fri Sep 2 15:50:38 2011 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 56CF521F8E33 for ; Fri, 2 Sep 2011 15:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.092 X-Spam-Level: X-Spam-Status: No, score=-6.092 tagged_above=-999 required=5 tests=[AWL=0.207, 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 x4ZzwMnCaFLK for ; Fri, 2 Sep 2011 15:50:37 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id A68EC21F8E32 for ; Fri, 2 Sep 2011 15:50:37 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id p82Mq5P8006570; Fri, 2 Sep 2011 22:52:05 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id p82Mq1C5006569; Fri, 2 Sep 2011 22:52:01 GMT Date: Fri, 2 Sep 2011 22:52:00 +0000 From: bmanning@vacation.karoshi.com To: =?utf-8?B?T25kxZllaiBTdXLDvQ==?= Message-ID: <20110902225200.GA6521@vacation.karoshi.com.> References: <4CBA8AED-F76D-46DF-A2A0-0B1608E3C8C2@kirei.se> <201109011639444268036@163.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.1i Cc: yzw_iplab , Paul Hoffman , DANE WG Subject: Re: [dane] #31: Multiple TLSA records in a response 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, 02 Sep 2011 22:50:38 -0000 On Thu, Sep 01, 2011 at 08:16:21PM +0200, OndEej SurC= wrote: > Jakob, Paul, > I have quickly re-read the dane-protocol-10 and the confusion might comefrom the fact that we don't explicitly state anywhere that you mighthave more TLSA records in the 4.4. > However I feel this might need little clarification in the DANE protocoldocument, explicitly stating that there could be one or more TLSA recordsat the same owner. > > I mean the protocol draft should manifest the update process > I believe this should go to the operational document, not into the protocol. > > and it should explain that the client should use all the TLSA RRs got from the DNS response for the authentication (e.g., when the client gets old TLSA RR and new TLSA RR, it should use the two RRs to authenticate the TLS server). When all the TLSA RRs are failed to authenticate the server, the TLS authentication association is unusable. Any one of the multiple TLSA RRs can successfully authenticate the server, the process can be continued. > There's nothing as old and new from the client view (e.g. the client has no knowledge about NEW and OLD). this sounds problematic to me. "... should use ALL the TLSA RRs..." - so If I pub 254 TLSA RRs, the client has to use ALL of them? Sounds like a DDoS on the wire to me. "OLD and NEW" - sounds like a use case is being codified in the protocol. the presumptive here seesm to be that presented TLSA RRs will only differ in the timestamps. i.e. they will be exact matches in all other respects. Usually, when presented with a choice of multiple answers, it is prudent to lay out the tie breaker rules. The stated rule "any one of the multiple TLSA RRs can suthenticate (...) can continue" sounds suspect to me. First In? Closest Match? How is the evaluation to be done? /bill From bmanning@karoshi.com Fri Sep 2 16:04:04 2011 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 3966E21F8B7F for ; Fri, 2 Sep 2011 16:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.985 X-Spam-Level: X-Spam-Status: No, score=-3.985 tagged_above=-999 required=5 tests=[AWL=-1.911, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, MIME_ASCII0=1.5, NULL_IN_BODY=2.425, 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 x9awKwbOXP1W for ; Fri, 2 Sep 2011 16:04:03 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id B42DB21F8B4E for ; Fri, 2 Sep 2011 16:04:03 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id p82N5eP8006603; Fri, 2 Sep 2011 23:05:40 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id p82N5aMT006602; Fri, 2 Sep 2011 23:05:36 GMT Date: Fri, 2 Sep 2011 23:05:36 +0000 From: bmanning@vacation.karoshi.com To: dane issue tracker Message-ID: <20110902230536.GB6521@vacation.karoshi.com.> References: <060.d55c279a583dd38213fda7e1f7c9e46d@trac.tools.ietf.org> <069.63b756414a8d964317fe74f502fd4d93@trac.tools.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <069.63b756414a8d964317fe74f502fd4d93@trac.tools.ietf.org> User-Agent: Mutt/1.4.1i Cc: draft-ietf-dane-protocol@tools.ietf.org, paul.hoffman@vpnc.org, dane@ietf.org Subject: Re: [dane] #31: Multiple TLSA records in a response 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, 02 Sep 2011 23:04:04 -0000 On Wed, Aug 17, 2011 at 03:43:29PM -0000, dane issue tracker wrote: > #31: Multiple TLSA records in a response > > Comment(by paul.hoffman@b&): > Proposal: in section 4.4, add a short paragraph that says "A domain name can have more than one TLSA record. A typical use for multiple TLSA records would be when the site is changing from one certificate to another. If a DNS response contains multiple TLSA records, any record from the set returned can be used to make certificate associations." > -- -----------------------------------+---------------------------------------- Reporter: paul.hoffman@b& | Owner: draft-ietf-dane-protocol@b& Type: defect | Status: new Priority: major | Milestone: Component: protocol | Version: Severity: - | Keywords: -----------------------------------+---------------------------------------- > Ticket URL: dane > _______________________________________________dane mailing listdane@ietf.orghttps://www.ietf.org/mailman/listinfo/dane any is too ambigious. what are the tie breaker rules? /bill From jakob@kirei.se Sat Sep 3 04:11:50 2011 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 9B70421F87C9 for ; Sat, 3 Sep 2011 04:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.636 X-Spam-Level: X-Spam-Status: No, score=-0.636 tagged_above=-999 required=5 tests=[AWL=0.062, 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 2V949i0iAHoq for ; Sat, 3 Sep 2011 04:11:50 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id 6371621F858D for ; Sat, 3 Sep 2011 04:11:49 -0700 (PDT) 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=xxSx4UVcfStU9z3xuW+cJWyD1NRKrOmKVKvV2QM/dtw=; b=CT2ZERhGckRa34VrFtq+nrOa0P2d4G4SNpADAvwdb5QatIDDZVEQcfOynYkhMD9glN6PCGCssMCHT 7nMYKgSki6SICgI2CFunSGF0HCfHtioP6AE8vx+EMC4h6RtwmyWVO8si5bw6391QVssbI+NaVs91Wt E6O9b7bc6v6QsuSg= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Sat, 3 Sep 2011 13:13:22 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: <20110902225200.GA6521@vacation.karoshi.com.> Date: Sat, 3 Sep 2011 13:13:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4CBA8AED-F76D-46DF-A2A0-0B1608E3C8C2@kirei.se> <201109011639444268036@163.com> <20110902225200.GA6521@vacation.karoshi.com.> To: bmanning@vacation.karoshi.com X-Mailer: Apple Mail (2.1244.3) Cc: yzw_iplab , Paul Hoffman , DANE WG Subject: Re: [dane] #31: Multiple TLSA records in a response 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, 03 Sep 2011 11:11:50 -0000 On 3 sep 2011, at 00:52, bmanning@vacation.karoshi.com wrote: > this sounds problematic to me. =20 >=20 > "... should use ALL the TLSA RRs..." - so If I pub 254 TLSA = RRs, the client has to use > ALL of them? Sounds like a DDoS on the wire to me. The simple rule is that one matching TLSA (that the client can use) is = enough . Once the client finds a match, it MAY ignore the rest of the = TLSA records. jakob From bmanning@karoshi.com Sat Sep 3 04:26:06 2011 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 0711721F8B4E for ; Sat, 3 Sep 2011 04:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.197 X-Spam-Level: X-Spam-Status: No, score=-6.197 tagged_above=-999 required=5 tests=[AWL=0.402, 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 TV872Vk4N7KE for ; Sat, 3 Sep 2011 04:26:05 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id 59F9E21F8ACA for ; Sat, 3 Sep 2011 04:26:04 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id p83BRZP8014719; Sat, 3 Sep 2011 11:27:36 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id p83BRWoY014718; Sat, 3 Sep 2011 11:27:32 GMT Date: Sat, 3 Sep 2011 11:27:32 +0000 From: bmanning@vacation.karoshi.com To: Jakob Schlyter Message-ID: <20110903112732.GA14712@vacation.karoshi.com.> References: <4CBA8AED-F76D-46DF-A2A0-0B1608E3C8C2@kirei.se> <201109011639444268036@163.com> <20110902225200.GA6521@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: yzw_iplab , bmanning@vacation.karoshi.com, Paul Hoffman , DANE WG Subject: Re: [dane] #31: Multiple TLSA records in a response 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, 03 Sep 2011 11:26:06 -0000 On Sat, Sep 03, 2011 at 01:13:10PM +0200, Jakob Schlyter wrote: > On 3 sep 2011, at 00:52, bmanning@vacation.karoshi.com wrote: > > > this sounds problematic to me. > > > > "... should use ALL the TLSA RRs..." - so If I pub 254 TLSA RRs, the client has to use > > ALL of them? Sounds like a DDoS on the wire to me. > > The simple rule is that one matching TLSA (that the client can use) is enough . Once the client finds a match, it MAY ignore the rest of the TLSA records. ok,,, first match. is that in the spec? /bill > > jakob > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From jakob@kirei.se Sat Sep 3 04:46:31 2011 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 9319D21F8515 for ; Sat, 3 Sep 2011 04:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.637 X-Spam-Level: X-Spam-Status: No, score=-0.637 tagged_above=-999 required=5 tests=[AWL=0.061, 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 J2Ptyzg7PVWC for ; Sat, 3 Sep 2011 04:46:31 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id 664F221F854D for ; Sat, 3 Sep 2011 04:46:30 -0700 (PDT) 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=RlvfHjeKE2dbn4ARl3LmFr362SNkezlzYqt+zAdPqlg=; b=m0/+JDPFUf0FgsCiIrK6ZhVaa7cddoQjrifJHOBvYdIvnELbciKAlDC5Y+4A5nD3QvJhtOnIzk4DP Ucg9cs9OHUf3QTHyen20D6RsQZHICdZtaTjcQ8KV84TR9GT9xwvWv9x54ic2EL9YPG0pR1q3R5YYCX 8zg7b+wf8Q6gEoNs= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Sat, 3 Sep 2011 13:48:06 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: <20110903112732.GA14712@vacation.karoshi.com.> Date: Sat, 3 Sep 2011 13:48:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <812921FE-6CA6-4B80-A7C0-E3410428BED6@kirei.se> References: <4CBA8AED-F76D-46DF-A2A0-0B1608E3C8C2@kirei.se> <201109011639444268036@163.com> <20110902225200.GA6521@vacation.karoshi.com.> <20110903112732.GA14712@vacation.karoshi.com.> To: bmanning@vacation.karoshi.com X-Mailer: Apple Mail (2.1244.3) Cc: yzw_iplab , Paul Hoffman , DANE WG Subject: Re: [dane] #31: Multiple TLSA records in a response 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, 03 Sep 2011 11:46:31 -0000 On 3 sep 2011, at 13:27, bmanning@vacation.karoshi.com wrote: > ok,,, first match. is that in the spec? Yes. "If a match between one of the certificate association(s) and the server's end entity certificate in TLS is found, the TLS client continues the TLS handshake. If no match between the usable certificate association(s) and the server's end entity certificate in TLS is found, the TLS client MUST abort the handshake with an "access_denied" error." (the definition of "usable", what TLSA records to ignore etc. is defined = as well, and is even more clarified in the next version) jakob From jakob@kirei.se Wed Sep 7 01:18:32 2011 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 C559121F8B48 for ; Wed, 7 Sep 2011 01:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.639 X-Spam-Level: X-Spam-Status: No, score=-0.639 tagged_above=-999 required=5 tests=[AWL=0.059, 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 Pob+x4CJjU7U for ; Wed, 7 Sep 2011 01:18:32 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id A52D421F8B46 for ; Wed, 7 Sep 2011 01:18:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:from:content-type:content-transfer-encoding:subject:date:message-id: to:mime-version:x-mailer; bh=NNxwiGbKLQKEJPadsa7QHOEQ3qk3kyk8CLOpMoQyHQA=; b=1izzKogzjljTaFB96RNU+IhE4o0PWMlO5BIcGWMDHAp1Mmb8NozWXo72DMgkp++q6JUaljQzNogn3 WncJMNGC265drCpZlgsGB9n+03ap6Qss4u+yhsfE9WOM0y+DgkePShFF25CERBGdVM4ku9agZWpei+ jBUsz71Yq8v4QoG8= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS for ; Wed, 7 Sep 2011 10:20:11 +0200 (CEST) From: Jakob Schlyter Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Sep 2011 10:20:09 +0200 Message-Id: To: dane WG Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) Subject: [dane] FYI: Updated protocol draft pending 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, 07 Sep 2011 08:18:32 -0000 Hi, I know all of you are anxiously waiting for the next revision of the = protocol draft, and we'll post an update as soon as we have made all the = changes resulting from the new usage/selector/match split. We really = hope to have something pushed out later this week! jakob & paul From warren@kumari.net Wed Sep 7 15:49:39 2011 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 39D5721F8D30 for ; Wed, 7 Sep 2011 15:49:39 -0700 (PDT) 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 eZ3eyAtxg8cJ for ; Wed, 7 Sep 2011 15:49:38 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id B28EA21F8D08 for ; Wed, 7 Sep 2011 15:49:38 -0700 (PDT) Received: from [10.0.1.4] (unknown [38.104.58.218]) by vimes.kumari.net (Postfix) with ESMTPSA id A45601B40340; Wed, 7 Sep 2011 18:51:28 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: <812921FE-6CA6-4B80-A7C0-E3410428BED6@kirei.se> Date: Wed, 7 Sep 2011 18:51:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <557EBC88-0EB5-49EA-8ED1-A93EF0E5BEF5@kumari.net> References: <4CBA8AED-F76D-46DF-A2A0-0B1608E3C8C2@kirei.se> <201109011639444268036@163.com> <20110902225200.GA6521@vacation.karoshi.com.> <20110903112732.GA14712@vacation.karoshi.com.> <812921FE-6CA6-4B80-A7C0-E3410428BED6@kirei.se> To: Jakob Schlyter X-Mailer: Apple Mail (2.1084) Cc: yzw_iplab , bmanning@vacation.karoshi.com, Paul Hoffman , DANE WG Subject: Re: [dane] #31: Multiple TLSA records in a response 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, 07 Sep 2011 22:49:39 -0000 Alrighty=85 As part of the new, faster, leaner, meaner approach to working issues = I'd like to call consensus on this on Friday 16:00UTC. Is the (current) below text acceptable (especially after "usable" is = clarified in the next version) to the WG? W On Sep 3, 2011, at 7:48 AM, Jakob Schlyter wrote: > On 3 sep 2011, at 13:27, bmanning@vacation.karoshi.com wrote: >=20 >> ok,,, first match. is that in the spec? >=20 > Yes. >=20 > "If a match between one of the certificate association(s) and the > server's end entity certificate in TLS is found, the TLS client > continues the TLS handshake. If no match between the usable > certificate association(s) and the server's end entity certificate = in > TLS is found, the TLS client MUST abort the handshake with an > "access_denied" error." >=20 > (the definition of "usable", what TLSA records to ignore etc. is = defined as well, and is even more clarified in the next version) >=20 > jakob >=20 >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 From yzw_iplab@163.com Wed Sep 7 17:50:17 2011 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 B453B21F8C87 for ; Wed, 7 Sep 2011 17:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.675 X-Spam-Level: **** X-Spam-Status: No, score=4.675 tagged_above=-999 required=5 tests=[AWL=0.656, BAYES_40=-0.185, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] 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 m8J7Ns2cQ3Aw for ; Wed, 7 Sep 2011 17:50:17 -0700 (PDT) Received: from m50-134.163.com (m50-134.163.com [123.125.50.134]) by ietfa.amsl.com (Postfix) with ESMTP id 526D021F8C82 for ; Wed, 7 Sep 2011 17:50:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=Received:Date:From:To:Cc:References:Subject: Message-ID:Mime-Version:Content-Type; bh=xGqo481OpaGJsfYISB0ZRx3 BXa9EQN/OFyhFbVJJb+I=; b=dmed1LJV3I5wF8YTP8ar+7i2Qj/mefgKPE8TZWz mQAp88TePbz+FaI+4szXBR5VFI6pKhKsosQDorbtuoCD4oxYl0Y+6diWeyiwAw0e MdVOdafut9JNI7DxgmfNVHKGQUPJmSOMgOB6Bb7aQMOdow/w1Mq6wD1ygsBJnWco tYQg= Received: from lenovo-THINK (unknown [218.241.111.47]) by smtp4 (Coremail) with SMTP id DtGowECZZE6zEWhOFw1bAQ--.7386S2; Thu, 08 Sep 2011 08:52:03 +0800 (CST) Date: Thu, 8 Sep 2011 08:51:40 +0800 From: "yzw_iplab" To: "Warren Kumari" , "Jakob Schlyter" References: <4CBA8AED-F76D-46DF-A2A0-0B1608E3C8C2@kirei.se>, <201109011639444268036@163.com>, , <20110902225200.GA6521@vacation.karoshi.com.>, , <20110903112732.GA14712@vacation.karoshi.com.>, <812921FE-6CA6-4B80-A7C0-E3410428BED6@kirei.se> Message-ID: <201109080851404237814@163.com> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon030865816017_=====" X-CM-TRANSID: DtGowECZZE6zEWhOFw1bAQ--.7386S2 X-Coremail-Antispam: 1Uf129KBjvJXoW7KF45uF1xWFWkKry8uFW3ZFb_yoW8Wr17pr WftrsIkFs0gw43C3s7Ga4Fq34UArWxJw4UJw1Yyr1DCa98Aw4Fqr4xt3Z8ZFy7Gr1rGr4Y 93yjgr4Yq34rZ3DanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07jBD7sUUUUU= X-CM-SenderInfo: 512zsxhsoduqqrwthudrp/1tbipQ+0zki7Z02CPwAAs0 Cc: "paul.hoffman" , bmanning , dane Subject: Re: [dane] #31: Multiple TLSA records in a response 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, 08 Sep 2011 00:50:17 -0000 This is a multi-part message in MIME format. --=====003_Dragon030865816017_===== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SWYgdGhlcmUgYXJlIG11bHRpcGxlIFRMU0EgUlJzIChlLmcsIKGwSWYgSSBwdWIgMjU0IFRMU0Eg UlJzobEtLXF1b3RlZCBmcm9tIGJtYW5uaW5noa9zIG1haWwpIGZvciBhIG5hbWUuIFRoZSBvbmUt Ynktb25lIGNvbXBhcmlzb24gYXBwcm9hY2ggaXMgbm90IGVmZmljaWVudCBlbm91Z2guIE1heWJl IHRoZSBsaWZldGltZSBvciBwcmlvcml0eSBvZiBUTFNBIFJSIHNob3VsZCBiZSBjb25zaWRlcmVk IGZvciB0aGUgdmFsaWRhdGlvbi4NCklmIGl0IGlzIG5vdCBjb25zaWRlcmVkIGluIHRoaXMgZG9j dW1lbnQsIEkgdGhpbmsgaXQgaXMgY2xlYXIgbm93Lg0KDQoyMDExLTA5LTA4IA0KDQoNCg0KeXp3 X2lwbGFiIA0KDQoNCg0Kt6K8/sjLo7ogV2FycmVuIEt1bWFyaSANCreiy83Ksbzko7ogMjAxMS0w OS0wOCAgMDY6NTE6MzQgDQrK1bz+yMujuiBKYWtvYiBTY2hseXRlciANCrOty82juiBibWFubmlu ZzsgeXp3X2lwbGFiOyBQYXVsIEhvZmZtYW47IERBTkUgV0cgDQrW98zio7ogUmU6IFtkYW5lXSAj MzE6IE11bHRpcGxlIFRMU0EgcmVjb3JkcyBpbiBhIHJlc3BvbnNlIA0KIA0KQWxyaWdodHmhrQ0K QXMgcGFydCBvZiB0aGUgbmV3LCBmYXN0ZXIsIGxlYW5lciwgbWVhbmVyIGFwcHJvYWNoIHRvIHdv cmtpbmcgaXNzdWVzIEknZCBsaWtlIHRvIGNhbGwgY29uc2Vuc3VzIG9uIHRoaXMgb24gRnJpZGF5 IDE2OjAwVVRDLg0KSXMgdGhlIChjdXJyZW50KSBiZWxvdyB0ZXh0IGFjY2VwdGFibGUgKGVzcGVj aWFsbHkgYWZ0ZXIgInVzYWJsZSIgaXMgY2xhcmlmaWVkIGluIHRoZSBuZXh0IHZlcnNpb24pIHRv IHRoZSBXRz8NClcNCk9uIFNlcCAzLCAyMDExLCBhdCA3OjQ4IEFNLCBKYWtvYiBTY2hseXRlciB3 cm90ZToNCj4gT24gMyBzZXAgMjAxMSwgYXQgMTM6MjcsIGJtYW5uaW5nQHZhY2F0aW9uLmthcm9z aGkuY29tIHdyb3RlOg0KPiANCj4+ICBvaywsLCBmaXJzdCBtYXRjaC4gIGlzIHRoYXQgaW4gdGhl IHNwZWM/DQo+IA0KPiBZZXMuDQo+IA0KPiAgIklmIGEgbWF0Y2ggYmV0d2VlbiBvbmUgb2YgdGhl IGNlcnRpZmljYXRlIGFzc29jaWF0aW9uKHMpIGFuZCB0aGUNCj4gICBzZXJ2ZXIncyBlbmQgZW50 aXR5IGNlcnRpZmljYXRlIGluIFRMUyBpcyBmb3VuZCwgdGhlIFRMUyBjbGllbnQNCj4gICBjb250 aW51ZXMgdGhlIFRMUyBoYW5kc2hha2UuICBJZiBubyBtYXRjaCBiZXR3ZWVuIHRoZSB1c2FibGUN Cj4gICBjZXJ0aWZpY2F0ZSBhc3NvY2lhdGlvbihzKSBhbmQgdGhlIHNlcnZlcidzIGVuZCBlbnRp dHkgY2VydGlmaWNhdGUgaW4NCj4gICBUTFMgaXMgZm91bmQsIHRoZSBUTFMgY2xpZW50IE1VU1Qg YWJvcnQgdGhlIGhhbmRzaGFrZSB3aXRoIGFuDQo+ICAgImFjY2Vzc19kZW5pZWQiIGVycm9yLiIN Cj4gDQo+ICh0aGUgZGVmaW5pdGlvbiBvZiAidXNhYmxlIiwgd2hhdCBUTFNBIHJlY29yZHMgdG8g aWdub3JlIGV0Yy4gaXMgZGVmaW5lZCBhcyB3ZWxsLCBhbmQgaXMgZXZlbiBtb3JlIGNsYXJpZmll ZCBpbiB0aGUgbmV4dCB2ZXJzaW9uKQ0KPiANCj4gIGpha29iDQo+IA0KPiANCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gZGFuZSBtYWlsaW5nIGxp c3QNCj4gZGFuZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2RhbmUNCj4gDQo= --=====003_Dragon030865816017_===== Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBuYW1lPUdFTkVSQVRPUiBjb250 ZW50PSJNU0hUTUwgOS4wMC44MTEyLjE2NDM0Ij4NCjxTVFlMRT5AZm9udC1mYWNlIHsNCglmb250 LWZhbWlseTogy87M5TsNCn0NCkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBWZXJkYW5hOw0K fQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IEDLzszlOw0KfQ0KQHBhZ2UgU2VjdGlvbjEg e3NpemU6IDU5NS4zcHQgODQxLjlwdDsgbWFyZ2luOiA3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4w cHQ7IGxheW91dC1ncmlkOiAxNS42cHQ7IH0NClAuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJRlk6 IGludGVyLWlkZW9ncmFwaDsgVEVYVC1BTElHTjoganVzdGlmeTsgTUFSR0lOOiAwY20gMGNtIDBw dDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iOyBGT05ULVNJWkU6IDEwLjVwdA0KfQ0K TEkuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJRlk6IGludGVyLWlkZW9ncmFwaDsgVEVYVC1BTElH TjoganVzdGlmeTsgTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcg Um9tYW4iOyBGT05ULVNJWkU6IDEwLjVwdA0KfQ0KRElWLk1zb05vcm1hbCB7DQoJVEVYVC1KVVNU SUZZOiBpbnRlci1pZGVvZ3JhcGg7IFRFWFQtQUxJR046IGp1c3RpZnk7IE1BUkdJTjogMGNtIDBj bSAwcHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgRk9OVC1TSVpFOiAxMC41cHQN Cn0NCkE6bGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lDQp9 DQpTUEFOLk1zb0h5cGVybGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5k ZXJsaW5lDQp9DQpBOnZpc2l0ZWQgew0KCUNPTE9SOiBwdXJwbGU7IFRFWFQtREVDT1JBVElPTjog dW5kZXJsaW5lDQp9DQpTUEFOLk1zb0h5cGVybGlua0ZvbGxvd2VkIHsNCglDT0xPUjogcHVycGxl OyBURVhULURFQ09SQVRJT046IHVuZGVybGluZQ0KfQ0KU1BBTi5FbWFpbFN0eWxlMTcgew0KCUZP TlQtU1RZTEU6IG5vcm1hbDsgRk9OVC1GQU1JTFk6IFZlcmRhbmE7IENPTE9SOiB3aW5kb3d0ZXh0 OyBGT05ULVdFSUdIVDogbm9ybWFsOyBURVhULURFQ09SQVRJT046IG5vbmU7IG1zby1zdHlsZS10 eXBlOiBwZXJzb25hbC1jb21wb3NlDQp9DQpESVYuU2VjdGlvbjEgew0KCXBhZ2U6IFNlY3Rpb24x DQp9DQpVTktOT1dOIHsNCglGT05ULVNJWkU6IDEwcHQNCn0NCkJMT0NLUVVPVEUgew0KCU1BUkdJ Ti1UT1A6IDBweDsgTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tTEVGVDogMmVtDQp9DQpPTCB7 DQoJTUFSR0lOLVRPUDogMHB4OyBNQVJHSU4tQk9UVE9NOiAwcHgNCn0NClVMIHsNCglNQVJHSU4t VE9QOiAwcHg7IE1BUkdJTi1CT1RUT006IDBweA0KfQ0KPC9TVFlMRT4NCjwvSEVBRD4NCjxCT0RZ IHN0eWxlPSJNQVJHSU46IDEwcHg7IEZPTlQtRkFNSUxZOiB2ZXJkYW5hOyBGT05ULVNJWkU6IDEw cHQiPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwIGZhY2U9VmVyZGFuYT4NCjxQIHN0eWxlPSJN QVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQpzdHlsZT0iRk9OVC1G QU1JTFk6ICdWZXJkYW5hJywnc2Fucy1zZXJpZic7IENPTE9SOiBuYXZ5OyBtc28tYmlkaS1mb250 LWZhbWlseTogy87M5TsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IFpILUNOIiANCmxhbmc9RU4tVVM+ PEZPTlQgc2l6ZT0yPklmIHRoZXJlIGFyZSBtdWx0aXBsZSBUTFNBIFJScyAoZS5nLCChsElmIEkg cHViIDI1NCBUTFNBIA0KUlJzobEtLXF1b3RlZCBmcm9tIGJtYW5uaW5noa9zIG1haWwpIGZvciBh IG5hbWUuIFRoZSBvbmUtYnktb25lIGNvbXBhcmlzb24gDQphcHByb2FjaCBpcyBub3QgZWZmaWNp ZW50IGVub3VnaC4gTWF5YmUgdGhlIGxpZmV0aW1lIG9yIHByaW9yaXR5IG9mIFRMU0EgUlIgDQpz aG91bGQgYmUgY29uc2lkZXJlZCBmb3IgdGhlIHZhbGlkYXRpb24uPD94bWw6bmFtZXNwYWNlIHBy ZWZpeCA9IG8gbnMgPSANCiJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2Ui IC8+PG86cD48L286cD48L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIHN0eWxlPSJNQVJHSU46IDBjbSAw Y20gMHB0IiBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgc2l6ZT0yPjxTUEFOIA0Kc3R5bGU9IkZPTlQt RkFNSUxZOiAnVmVyZGFuYScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogbmF2eTsgbXNvLWJpZGktZm9u dC1mYW1pbHk6IMvOzOU7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBaSC1DTiIgDQpsYW5nPUVOLVVT PklmIGl0IGlzIG5vdCBjb25zaWRlcmVkIGluIHRoaXMgZG9jdW1lbnQsIEkgdGhpbmsgaXQgaXMg Y2xlYXIgDQpub3cuPC9TUEFOPjxTUEFOIA0Kc3R5bGU9IkZPTlQtRkFNSUxZOiAnVmVyZGFuYScs J3NhbnMtc2VyaWYnOyBtc28tYmlkaS1mb250LWZhbWlseTogy87M5TsgbXNvLWZhcmVhc3QtbGFu Z3VhZ2U6IFpILUNOIiANCmxhbmc9RU4tVVM+PG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD48 L0ZPTlQ+PEZPTlQgY29sb3I9IzAwMDA4MCANCmZhY2U9VmVyZGFuYT48L0ZPTlQ+PC9ESVY+DQo8 RElWPjxGT05UIGNvbG9yPSMwMDAwODAgZmFjZT1WZXJkYW5hPjwvRk9OVD4mbmJzcDs8L0RJVj4N CjxESVY+PEZPTlQgY29sb3I9I2MwYzBjMCBmYWNlPVZlcmRhbmE+MjAxMS0wOS0wOCA8L0ZPTlQ+ PC9ESVY+PEZPTlQgDQpjb2xvcj0jMDAwMDgwIGZhY2U9VmVyZGFuYT4NCjxIUiBzdHlsZT0iV0lE VEg6IDEwMHB4IiBhbGlnbj1sZWZ0IGNvbG9yPSNiNWM0ZGYgU0laRT0xPg0KPC9GT05UPg0KPERJ Vj48Rk9OVCBjb2xvcj0jYzBjMGMwIGZhY2U9VmVyZGFuYT48U1BBTj55endfaXBsYWI8L1NQQU4+ IDwvRk9OVD48L0RJVj4NCjxIUiBjb2xvcj0jYjVjNGRmIFNJWkU9MT4NCg0KPERJVj48Rk9OVCBm YWNlPVZlcmRhbmE+PFNUUk9ORz63orz+yMujujwvU1RST05HPiBXYXJyZW4gS3VtYXJpIDwvRk9O VD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hPjxTVFJPTkc+t6LLzcqxvOSjujwvU1RS T05HPiAyMDExLTA5LTA4Jm5ic3A7IDA2OjUxOjM0IA0KPC9GT05UPjwvRElWPg0KPERJVj48Rk9O VCBmYWNlPVZlcmRhbmE+PFNUUk9ORz7K1bz+yMujujwvU1RST05HPiBKYWtvYiBTY2hseXRlciA8 L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYT48U1RST05HPrOty82jujwvU1RS T05HPiBibWFubmluZzsgeXp3X2lwbGFiOyBQYXVsIEhvZmZtYW47IA0KREFORSBXRyA8L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYT48U1RST05HPtb3zOKjujwvU1RST05HPiBS ZTogW2RhbmVdICMzMTogTXVsdGlwbGUgVExTQSANCnJlY29yZHMgaW4gYSByZXNwb25zZSA8L0ZP TlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYT48L0ZPTlQ+IDwvRElWPg0KPERJVj48 Rk9OVCBmYWNlPVZlcmRhbmE+DQo8RElWPkFscmlnaHR5oa08L0RJVj4NCjxESVY+PC9ESVY+DQo8 RElWPkFzJm5ic3A7cGFydCZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bmV3LCZuYnNwO2Zhc3Rlciwm bmJzcDtsZWFuZXIsJm5ic3A7bWVhbmVyJm5ic3A7YXBwcm9hY2gmbmJzcDt0byZuYnNwO3dvcmtp bmcmbmJzcDtpc3N1ZXMmbmJzcDtJJ2QmbmJzcDtsaWtlJm5ic3A7dG8mbmJzcDtjYWxsJm5ic3A7 Y29uc2Vuc3VzJm5ic3A7b24mbmJzcDt0aGlzJm5ic3A7b24mbmJzcDtGcmlkYXkmbmJzcDsxNjow MFVUQy48L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPklzJm5ic3A7dGhlJm5ic3A7KGN1cnJlbnQp Jm5ic3A7YmVsb3cmbmJzcDt0ZXh0Jm5ic3A7YWNjZXB0YWJsZSZuYnNwOyhlc3BlY2lhbGx5Jm5i c3A7YWZ0ZXImbmJzcDsidXNhYmxlIiZuYnNwO2lzJm5ic3A7Y2xhcmlmaWVkJm5ic3A7aW4mbmJz cDt0aGUmbmJzcDtuZXh0Jm5ic3A7dmVyc2lvbikmbmJzcDt0byZuYnNwO3RoZSZuYnNwO1dHPzwv RElWPg0KPERJVj48L0RJVj4NCjxESVY+VzwvRElWPg0KPERJVj5PbiZuYnNwO1NlcCZuYnNwOzMs Jm5ic3A7MjAxMSwmbmJzcDthdCZuYnNwOzc6NDgmbmJzcDtBTSwmbmJzcDtKYWtvYiZuYnNwO1Nj aGx5dGVyJm5ic3A7d3JvdGU6PC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7T24m bmJzcDszJm5ic3A7c2VwJm5ic3A7MjAxMSwmbmJzcDthdCZuYnNwOzEzOjI3LCZuYnNwO2JtYW5u aW5nQHZhY2F0aW9uLmthcm9zaGkuY29tJm5ic3A7d3JvdGU6PC9ESVY+DQo8RElWPiZndDsmbmJz cDs8L0RJVj4NCjxESVY+Jmd0OyZndDsmbmJzcDsgDQpvaywsLCZuYnNwO2ZpcnN0Jm5ic3A7bWF0 Y2guJm5ic3A7Jm5ic3A7aXMmbmJzcDt0aGF0Jm5ic3A7aW4mbmJzcDt0aGUmbmJzcDtzcGVjPzwv RElWPg0KPERJVj4mZ3Q7Jm5ic3A7PC9ESVY+DQo8RElWPiZndDsmbmJzcDtZZXMuPC9ESVY+DQo8 RElWPiZndDsmbmJzcDs8L0RJVj4NCjxESVY+Jmd0OyZuYnNwOyZuYnNwOyJJZiZuYnNwO2EmbmJz cDttYXRjaCZuYnNwO2JldHdlZW4mbmJzcDtvbmUmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2NlcnRp ZmljYXRlJm5ic3A7YXNzb2NpYXRpb24ocykmbmJzcDthbmQmbmJzcDt0aGU8L0RJVj4NCjxESVY+ Jmd0OyZuYnNwOyZuYnNwOyZuYnNwO3NlcnZlcidzJm5ic3A7ZW5kJm5ic3A7ZW50aXR5Jm5ic3A7 Y2VydGlmaWNhdGUmbmJzcDtpbiZuYnNwO1RMUyZuYnNwO2lzJm5ic3A7Zm91bmQsJm5ic3A7dGhl Jm5ic3A7VExTJm5ic3A7Y2xpZW50PC9ESVY+DQo8RElWPiZndDsmbmJzcDsmbmJzcDsmbmJzcDtj b250aW51ZXMmbmJzcDt0aGUmbmJzcDtUTFMmbmJzcDtoYW5kc2hha2UuJm5ic3A7Jm5ic3A7SWYm bmJzcDtubyZuYnNwO21hdGNoJm5ic3A7YmV0d2VlbiZuYnNwO3RoZSZuYnNwO3VzYWJsZTwvRElW Pg0KPERJVj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Y2VydGlmaWNhdGUmbmJzcDthc3NvY2lhdGlv bihzKSZuYnNwO2FuZCZuYnNwO3RoZSZuYnNwO3NlcnZlcidzJm5ic3A7ZW5kJm5ic3A7ZW50aXR5 Jm5ic3A7Y2VydGlmaWNhdGUmbmJzcDtpbjwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7VExTJm5ic3A7aXMmbmJzcDtmb3VuZCwmbmJzcDt0aGUmbmJzcDtUTFMmbmJzcDtjbGllbnQm bmJzcDtNVVNUJm5ic3A7YWJvcnQmbmJzcDt0aGUmbmJzcDtoYW5kc2hha2UmbmJzcDt3aXRoJm5i c3A7YW48L0RJVj4NCjxESVY+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyJhY2Nlc3NfZGVuaWVkIiZu YnNwO2Vycm9yLiI8L0RJVj4NCjxESVY+Jmd0OyZuYnNwOzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7 KHRoZSZuYnNwO2RlZmluaXRpb24mbmJzcDtvZiZuYnNwOyJ1c2FibGUiLCZuYnNwO3doYXQmbmJz cDtUTFNBJm5ic3A7cmVjb3JkcyZuYnNwO3RvJm5ic3A7aWdub3JlJm5ic3A7ZXRjLiZuYnNwO2lz Jm5ic3A7ZGVmaW5lZCZuYnNwO2FzJm5ic3A7d2VsbCwmbmJzcDthbmQmbmJzcDtpcyZuYnNwO2V2 ZW4mbmJzcDttb3JlJm5ic3A7Y2xhcmlmaWVkJm5ic3A7aW4mbmJzcDt0aGUmbmJzcDtuZXh0Jm5i c3A7dmVyc2lvbik8L0RJVj4NCjxESVY+Jmd0OyZuYnNwOzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7 IGpha29iPC9ESVY+DQo8RElWPiZndDsmbmJzcDs8L0RJVj4NCjxESVY+Jmd0OyZuYnNwOzwvRElW Pg0KPERJVj4mZ3Q7Jm5ic3A7X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188L0RJVj4NCjxESVY+Jmd0OyZuYnNwO2RhbmUmbmJzcDttYWlsaW5nJm5ic3A7bGlz dDwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7ZGFuZUBpZXRmLm9yZzwvRElWPg0KPERJVj4mZ3Q7Jm5i c3A7aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kYW5lPC9ESVY+DQo8RElW PiZndDsmbmJzcDs8L0RJVj4NCjxESVY+PC9ESVY+PC9GT05UPjwvRElWPjwvQk9EWT48L0hUTUw+ DQo= --=====003_Dragon030865816017_=====-- From paul.hoffman@vpnc.org Wed Sep 7 18:00:01 2011 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 3F57C21F8CE0 for ; Wed, 7 Sep 2011 18:00:01 -0700 (PDT) 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 TWVjoMWzHeUz for ; Wed, 7 Sep 2011 18:00:00 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id BFF6C21F8CA0 for ; Wed, 7 Sep 2011 18:00:00 -0700 (PDT) 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 p8811kth059435 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 7 Sep 2011 18:01:46 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=windows-1252 From: Paul Hoffman In-Reply-To: <201109080851404237814@163.com> Date: Wed, 7 Sep 2011 18:01:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4106A73D-5D89-4A72-93A6-1C376B2061A0@vpnc.org> References: <4CBA8AED-F76D-46DF-A2A0-0B1608E3C8C2@kirei.se>, <201109011639444268036@163.com>, , <20110902225200.GA6521@vacation.karoshi.com.>, , <20110903112732.GA14712@vacation.karoshi.com.>, <812921FE-6CA6-4B80-A7C0-E3410428BED6@kirei.se> <201109080851404237814@163.com> To: "yzw_iplab" X-Mailer: Apple Mail (2.1244.3) Cc: DANE WG Subject: Re: [dane] #31: Multiple TLSA records in a response 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, 08 Sep 2011 01:00:01 -0000 On Sep 7, 2011, at 5:51 PM, yzw_iplab wrote: > If there are multiple TLSA RRs (e.g, =93If I pub 254 TLSA RRs=94--quoted= from bmanning=92s mail) for a name. The one-by-one comparison approach = is not efficient enough. Maybe the lifetime or priority of TLSA RR = should be considered for the validation. > If it is not considered in this document, I think it is clear now. An implementation can optimize however it wants; the spec should not = specify how. --Paul Hoffman From jakob@kirei.se Wed Sep 7 20:08:20 2011 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 E8DA621F8B63 for ; Wed, 7 Sep 2011 20:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.64 X-Spam-Level: X-Spam-Status: No, score=-0.64 tagged_above=-999 required=5 tests=[AWL=0.058, 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 gxnl1or2gaXE for ; Wed, 7 Sep 2011 20:08:20 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id BB14921F8B6B for ; Wed, 7 Sep 2011 20:08:19 -0700 (PDT) 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=hGQlNsknAdjbPR3/BOhBvgjRFPQxENQg2ZftqYGCuJE=; b=hH7Z26hGV2TQrDZeF5+E/ST7Az+F6m5zhvamdSxf1rCV3URbRr+VfERw72QqV/HWBJ44QAP1dWqQQ CWqKSEnjPyM3UCu37pX/wbk3ZeeSUrbw60Bop0my+I+ItAPXbdB7DuxsJGGX/O+KtWFbfAbeOu2QRN tBDDR8EKStHRsv9A= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Thu, 8 Sep 2011 05:10:07 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=GB2312 From: Jakob Schlyter In-Reply-To: <201109080851404237814@163.com> Date: Thu, 8 Sep 2011 05:09:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <47F9495F-D7A0-4899-BF60-CEF9F8E894C0@kirei.se> References: <4CBA8AED-F76D-46DF-A2A0-0B1608E3C8C2@kirei.se>, <201109011639444268036@163.com>, , <20110902225200.GA6521@vacation.karoshi.com.>, , <20110903112732.GA14712@vacation.karoshi.com.>, <812921FE-6CA6-4B80-A7C0-E3410428BED6@kirei.se> <201109080851404237814@163.com> To: "yzw_iplab" X-Mailer: Apple Mail (2.1244.3) Cc: "paul.hoffman" , bmanning , dane Subject: Re: [dane] #31: Multiple TLSA records in a response 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, 08 Sep 2011 03:08:21 -0000 On 8 sep 2011, at 02:51, yzw_iplab wrote: > If there are multiple TLSA RRs (e.g, =A1=B0If I pub 254 TLSA = RRs=A1=B1--quoted from bmanning=A1=AFs mail) for a name. The one-by-one = comparison approach is not efficient enough. Maybe the lifetime or = priority of TLSA RR should be considered for the validation. > If it is not considered in this document, I think it is clear now. The suggested text (with a small change from Bill) is: On the first match between one of the certificate association(s) and the server's end entity certificate in TLS is found, the TLS client = continues the TLS handshake, ignoring remaining certificate associations. If no match between the usable certificate association(s) and the server's end = entity certificate in TLS is found, the TLS client MUST abort the handshake = with an "access_denied" error. jakob From bmanning@karoshi.com Wed Sep 7 22:06:20 2011 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 B8E5C21F87C9 for ; Wed, 7 Sep 2011 22:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.255 X-Spam-Level: X-Spam-Status: No, score=-4.255 tagged_above=-999 required=5 tests=[AWL=-1.581, BAYES_00=-2.599, MIME_ASCII0=1.5, NULL_IN_BODY=2.425, 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 5EB8j1ziM+0m for ; Wed, 7 Sep 2011 22:06:20 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id EE0FB21F8785 for ; Wed, 7 Sep 2011 22:06:18 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id p884AmEL003652; Thu, 8 Sep 2011 04:10:59 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id p884AbQn003651; Thu, 8 Sep 2011 04:10:37 GMT Date: Thu, 8 Sep 2011 04:10:37 +0000 From: bmanning@vacation.karoshi.com To: Jakob Schlyter Message-ID: <20110908041037.GB3220@vacation.karoshi.com.> References: <812921FE-6CA6-4B80-A7C0-E3410428BED6@kirei.se> <201109080851404237814@163.com> <47F9495F-D7A0-4899-BF60-CEF9F8E894C0@kirei.se> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <47F9495F-D7A0-4899-BF60-CEF9F8E894C0@kirei.se> User-Agent: Mutt/1.4.1i Cc: yzw_iplab , bmanning , "paul.hoffman" , dane Subject: Re: [dane] #31: Multiple TLSA records in a response 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, 08 Sep 2011 05:06:20 -0000 On Thu, Sep 08, 2011 at 05:09:59AM +0200, Jakob Schlyter wrote: > On 8 sep 2011, at 02:51, yzw_iplab wrote: > > If there are multiple TLSA RRs (e.g, bIf I pub 254 TLSA RRsb--quoted from bmanningbs mail) for a name. The one-by-one comparison approach is not efficient enough. Maybe the lifetime or priority of TLSA RR should be considered for the validation.> If it is not considered in this document, I think it is clear now. > The suggested text (with a small change from Bill) is: > On the first match between one of the certificate association(s) and theserver's end entity certificate in TLS is found, the TLS client continues theTLS handshake, ignoring remaining certificate associations. If no matchbetween the usable certificate association(s) and the server's end entitycertificate in TLS is found, the TLS client MUST abort the handshake with an"access_denied" error. > > jakob > _______________________________________________dane mailing listdane@ietf.orghttps://www.ietf.org/mailman/listinfo/dane i'm ok w/ last calling this text. /bill From hallam@gmail.com Thu Sep 8 05:15:19 2011 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 67A7421F8B7D for ; Thu, 8 Sep 2011 05:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.401 X-Spam-Level: X-Spam-Status: No, score=-3.401 tagged_above=-999 required=5 tests=[AWL=0.197, 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 8YpsZZIunz7q for ; Thu, 8 Sep 2011 05:15:15 -0700 (PDT) Received: from mail-gw0-f42.google.com (mail-gw0-f42.google.com [74.125.83.42]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE7821F8B3E for ; Thu, 8 Sep 2011 05:15:15 -0700 (PDT) Received: by gwb17 with SMTP id 17so1085134gwb.15 for ; Thu, 08 Sep 2011 05:17:07 -0700 (PDT) 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=ch0cFUj8F8/rxFgA2ycpRTsyrrgUNhwwDAlJiqqgotw=; b=MfOnoodGkiwZAisaZJJIECS5kt/0oMbGzC+PxmSm8RFIGMPGjKF6bIAW3JD9RhBeMO Wf927Hfc+ryd/g+hlF8Lb9csrcFwJoK9OQ4tp5fnLS+LLUddBJ7ivdgSrzF6KL4NTL6W CXFKb7RkvHV9XwfDSXN+rRSgp5RvMAWpRFEDU= MIME-Version: 1.0 Received: by 10.101.131.4 with SMTP id i4mr550569ann.61.1315484227056; Thu, 08 Sep 2011 05:17:07 -0700 (PDT) Received: by 10.101.114.9 with HTTP; Thu, 8 Sep 2011 05:17:07 -0700 (PDT) In-Reply-To: <47F9495F-D7A0-4899-BF60-CEF9F8E894C0@kirei.se> References: <4CBA8AED-F76D-46DF-A2A0-0B1608E3C8C2@kirei.se> <201109011639444268036@163.com> <20110902225200.GA6521@vacation.karoshi.com.> <20110903112732.GA14712@vacation.karoshi.com.> <812921FE-6CA6-4B80-A7C0-E3410428BED6@kirei.se> <201109080851404237814@163.com> <47F9495F-D7A0-4899-BF60-CEF9F8E894C0@kirei.se> Date: Thu, 8 Sep 2011 08:17:07 -0400 Message-ID: From: Phillip Hallam-Baker To: Jakob Schlyter Content-Type: multipart/alternative; boundary=001636c92a3f0fb4fb04ac6d0ac2 Cc: yzw_iplab , bmanning , "paul.hoffman" , dane Subject: Re: [dane] #31: Multiple TLSA records in a response 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, 08 Sep 2011 12:15:19 -0000 --001636c92a3f0fb4fb04ac6d0ac2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable As Steve Kent pointed out earlier, this group has no business with a MUST there. If you want to change PKIX processing you have to get consensus in the PKIX group. 2011/9/7 Jakob Schlyter > On 8 sep 2011, at 02:51, yzw_iplab wrote: > > > If there are multiple TLSA RRs (e.g, =93If I pub 254 TLSA RRs=94--quote= d from > bmanning=92s mail) for a name. The one-by-one comparison approach is not > efficient enough. Maybe the lifetime or priority of TLSA RR should be > considered for the validation. > > If it is not considered in this document, I think it is clear now. > > The suggested text (with a small change from Bill) is: > > On the first match between one of the certificate association(s) and the > server's end entity certificate in TLS is found, the TLS client continues > the > TLS handshake, ignoring remaining certificate associations. If no match > between the usable certificate association(s) and the server's end entity > certificate in TLS is found, the TLS client MUST abort the handshake with > an > "access_denied" error. > > > jakob > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > --=20 Website: http://hallambaker.com/ --001636c92a3f0fb4fb04ac6d0ac2 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable As Steve Kent pointed out earlier, this group has no business with a MUST t= here.

If you want to change PKIX processing you have to = get consensus in the PKIX group.



2011/9/7 Jakob Schlyter <jakob@kirei.se>
On 8 sep 2011, at 02:51, yzw_iplab wrote:

> If there are multiple TLSA RRs (e.g, =93If I pub 254 TLSA RRs=94--quot= ed from bmanning=92s mail) for a name. The one-by-one comparison approach i= s not efficient enough. Maybe the lifetime or priority of TLSA RR should be= considered for the validation.
> If it is not considered in this document, I think it is clear now.

The suggested text (with a small change from Bill) is:

On the first match between one of the certificate association(s) and the
server's end entity certificate in TLS is found, the = TLS client continues the
TLS handshake, ignoring remaining certificate associations. If no mat= ch
between the usable certificate association(s) and the ser= ver's end entity
certificate in TLS is found, the TLS client MUST abort the handshake with a= n
"access_denied" error.


=A0 =A0 =A0 =A0jakob

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



--
= Website: http://hallambaker.com/
--001636c92a3f0fb4fb04ac6d0ac2-- From mrex@sap.com Thu Sep 8 06:40:34 2011 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 8CBF021F8B6D for ; Thu, 8 Sep 2011 06:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.02 X-Spam-Level: X-Spam-Status: No, score=-10.02 tagged_above=-999 required=5 tests=[AWL=0.229, 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 QK8L5sIzd45F for ; Thu, 8 Sep 2011 06:40:34 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id D414821F8B36 for ; Thu, 8 Sep 2011 06:40:33 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p88DgFAC026060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Sep 2011 15:42:16 +0200 (MEST) From: Martin Rex Message-Id: <201109081342.p88DgFYZ013076@fs4113.wdf.sap.corp> To: hallam@gmail.com (Phillip Hallam-Baker) Date: Thu, 8 Sep 2011 15:42:15 +0200 (MEST) In-Reply-To: from "Phillip Hallam-Baker" at Sep 8, 11 08:17:07 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: yzw_iplab@163.com, bmanning@vacation.karoshi.com, paul.hoffman@vpnc.org, dane@ietf.org Subject: Re: [dane] #31: Multiple TLSA records in a response 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, 08 Sep 2011 13:40:34 -0000 Phillip Hallam-Baker wrote: > > As Steve Kent pointed out earlier, this group has no business with a MUST > there. > > If you want to change PKIX processing you have to get consensus in the PKIX > group. Steve's message was slightly unclear. PKIX is only "authoritative" for PKIX certificate path validation, (section 6.x of rfc5280) and the result from that check is a binary answer: (0) certificate path validation failed (1) certificate _not_ known to be invalid or (0) negative confirmation (1) absensence of negative confirmation But whether an "application caller" performs other or addtional checks or comparisons on any certificate from the certification path or any attributes thereof, before it considers a TLS server certificate acceptable, is purely at the discretion of that application caller and PKIX has no say in that. The matching performed on name-related attributes by rfc6125 (and rfc2818 before that) are outside of the scope of PKIX, similar to several checks that DANE defines. -Martin From rbarnes@bbn.com Thu Sep 8 07:28:23 2011 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 462B321F8BBB for ; Thu, 8 Sep 2011 07:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.553 X-Spam-Level: X-Spam-Status: No, score=-106.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 kW9UsM7FvfOB for ; Thu, 8 Sep 2011 07:28:22 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 9EBC221F8B0B for ; Thu, 8 Sep 2011 07:28:22 -0700 (PDT) Received: from [192.1.255.224] (port=54008 helo=col-dhcp-192-1-255-224.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1R1fcF-0005nR-S0; Thu, 08 Sep 2011 10:30:08 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: "Richard L. Barnes" In-Reply-To: <557EBC88-0EB5-49EA-8ED1-A93EF0E5BEF5@kumari.net> Date: Thu, 8 Sep 2011 10:29:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0FBA90D5-79E6-4826-9B41-2F04E01F83B0@bbn.com> References: <4CBA8AED-F76D-46DF-A2A0-0B1608E3C8C2@kirei.se> <201109011639444268036@163.com> <20110902225200.GA6521@vacation.karoshi.com.> <20110903112732.GA14712@vacation.karoshi.com.> <812921FE-6CA6-4B80-A7C0-E3410428BED6@kirei.se> <557EBC88-0EB5-49EA-8ED1-A93EF0E5BEF5@kumari.net> To: Warren Kumari X-Mailer: Apple Mail (2.1084) Cc: yzw_iplab , bmanning@vacation.karoshi.com, Paul Hoffman , DANE WG Subject: Re: [dane] #31: Multiple TLSA records in a response 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, 08 Sep 2011 14:28:23 -0000 I would actually like to propose a slightly different approach here. If you look at the use cases document, there are at least two different = uses for multiple TLSA records. The "Roll-Over" paragraph discusses = having two certificates active at once, and the "Combination" paragraph = discusses having multiple constraints on a certificate, e.g., to allow a = domain-operated CA and no other. The "Combination" case cannot be met = with the text under discussion, since only one association is ever = considered. As an alternative, I would propose that we create a simple way to = combine TLSA associations in a kind of disjunctive normal form. = Currently, TLSA records are combined with an "or" operation -- the whole = matches iff any one matches: RR1 || RR2 || RR3 || RR4 It would be nice to be able to say "AND these records together", so that = you could have something like the following: RR1 || (RR2 && RR3) || RR4 That way you could still do "first match", but that match might be = across a couple of records. Proposal: Add a "group id" (gid) field to the TLSA record format. This = field doesn't need to be long, one octet would suffice, and change the = matching logic to the following: " When there more than one TLSA record for a target domain, a certificate = matches if it matches all of the records within any record group. = Record groups are identified by the GID field; a group is comprised of = all records with the same GID value. To determine whether a certificate = is a TLSA match for a domain, it SHOULD execute the following steps: 1. Gather TLSA records into groups by GID 2. For each group - Determine whether the certificate matches all records in the group - If the certificate matches, then return true - If the certificate does not match, then process the next group 3. If no group matches, then return false " The current situation can be replicated by assigning each record a = distinct GID. This algorithm does require the client to process all TLSA records, but = only to the extent of parsing them and pulling the GIDs. That's a much = cheaper operation than actually doing the matches. --Richard On Sep 7, 2011, at 6:51 PM, Warren Kumari wrote: > Alrighty=85 >=20 > As part of the new, faster, leaner, meaner approach to working issues = I'd like to call consensus on this on Friday 16:00UTC. >=20 > Is the (current) below text acceptable (especially after "usable" is = clarified in the next version) to the WG? >=20 > W > On Sep 3, 2011, at 7:48 AM, Jakob Schlyter wrote: >=20 >> On 3 sep 2011, at 13:27, bmanning@vacation.karoshi.com wrote: >>=20 >>> ok,,, first match. is that in the spec? >>=20 >> Yes. >>=20 >> "If a match between one of the certificate association(s) and the >> server's end entity certificate in TLS is found, the TLS client >> continues the TLS handshake. If no match between the usable >> certificate association(s) and the server's end entity certificate = in >> TLS is found, the TLS client MUST abort the handshake with an >> "access_denied" error." >>=20 >> (the definition of "usable", what TLSA records to ignore etc. is = defined as well, and is even more clarified in the next version) >>=20 >> jakob >>=20 >>=20 >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >>=20 >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From internet-drafts@ietf.org Thu Sep 8 08:32:49 2011 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 80B3E21F8A6F; Thu, 8 Sep 2011 08:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.008, 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 ZBYGqWlSXG1X; Thu, 8 Sep 2011 08:32:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB08821F87F0; Thu, 8 Sep 2011 08:32:48 -0700 (PDT) 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.60 Message-ID: <20110908153248.32355.69147.idtracker@ietfa.amsl.com> Date: Thu, 08 Sep 2011 08:32:48 -0700 Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-protocol-11.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: Thu, 08 Sep 2011 15:32:49 -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-11.txt Pages : 20 Date : 2011-09-08 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-11.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-11.txt From paul.hoffman@vpnc.org Thu Sep 8 08:52:54 2011 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 0751521F84F8 for ; Thu, 8 Sep 2011 08:52:54 -0700 (PDT) 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 Fx-hnHWX7nnp for ; Thu, 8 Sep 2011 08:52:53 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6A44821F84DA for ; Thu, 8 Sep 2011 08:52:53 -0700 (PDT) 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 p88FsjkA067901 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 8 Sep 2011 08:54:45 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1244.3) From: Paul Hoffman In-Reply-To: <0FBA90D5-79E6-4826-9B41-2F04E01F83B0@bbn.com> Date: Thu, 8 Sep 2011 08:54:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4CBA8AED-F76D-46DF-A2A0-0B1608E3C8C2@kirei.se> <201109011639444268036@163.com> <20110902225200.GA6521@vacation.karoshi.com.> <20110903112732.GA14712@vacation.karoshi.com.> <812921FE-6CA6-4B80-A7C0-E3410428BED6@kirei.se> <557EBC88-0EB5-49EA-8ED1-A93EF0E5BEF5@kumari.net> <0FBA90D5-79E6-4826-9B41-2F04E01F83B0@bbn.com> To: DANE WG X-Mailer: Apple Mail (2.1244.3) Subject: Re: [dane] #31: Multiple TLSA records in a response 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, 08 Sep 2011 15:52:54 -0000 On Sep 8, 2011, at 7:29 AM, Richard L. Barnes wrote: > I would actually like to propose a slightly different approach here. >=20 > If you look at the use cases document, there are at least two = different uses for multiple TLSA records. The "Roll-Over" paragraph = discusses having two certificates active at once, and the "Combination" = paragraph discusses having multiple constraints on a certificate, e.g., = to allow a domain-operated CA and no other. The "Combination" case = cannot be met with the text under discussion, since only one association = is ever considered. >=20 > As an alternative, I would propose that we create a simple way to = combine TLSA associations in a kind of disjunctive normal form. = Currently, TLSA records are combined with an "or" operation -- the whole = matches iff any one matches: > RR1 || RR2 || RR3 || RR4 > It would be nice to be able to say "AND these records together", so = that you could have something like the following: > RR1 || (RR2 && RR3) || RR4 > That way you could still do "first match", but that match might be = across a couple of records. >=20 > Proposal: Add a "group id" (gid) field to the TLSA record format. = This field doesn't need to be long, one octet would suffice, and change = the matching logic to the following: > " > When there more than one TLSA record for a target domain, a = certificate matches if it matches all of the records within any record = group. Record groups are identified by the GID field; a group is = comprised of all records with the same GID value. To determine whether = a certificate is a TLSA match for a domain, it SHOULD execute the = following steps: > 1. Gather TLSA records into groups by GID > 2. For each group > - Determine whether the certificate matches all records in the group > - If the certificate matches, then return true > - If the certificate does not match, then process the next group > 3. If no group matches, then return false > " >=20 > The current situation can be replicated by assigning each record a = distinct GID. >=20 > This algorithm does require the client to process all TLSA records, = but only to the extent of parsing them and pulling the GIDs. That's a = much cheaper operation than actually doing the matches. While this change does meet the "combination" use case, it also makes = the protocol more complex. It requires that domain administrators who = don't care about combination still pick a group ID (even if it is 0). Is = the use case actually worth the additional complexity? If so, I think = that Richard's proposal is probably the least complex way to implement = it. --Paul Hoffman From rbarnes@bbn.com Thu Sep 8 09:04:14 2011 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 08C6B21F889A for ; Thu, 8 Sep 2011 09:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.557 X-Spam-Level: X-Spam-Status: No, score=-106.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 aP3GQUnWXd-Q for ; Thu, 8 Sep 2011 09:04:13 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB8D21F87FA for ; Thu, 8 Sep 2011 09:04:13 -0700 (PDT) Received: from [192.1.255.224] (port=54707 helo=col-dhcp-192-1-255-224.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1R1h77-0007uX-IH; Thu, 08 Sep 2011 12:06:05 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Thu, 8 Sep 2011 12:06:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <04313062-8BD4-4314-8996-72B93C73B791@bbn.com> References: <4CBA8AED-F76D-46DF-A2A0-0B1608E3C8C2@kirei.se> <201109011639444268036@163.com> <20110902225200.GA6521@vacation.karoshi.com.> <20110903112732.GA14712@vacation.karoshi.com.> <812921FE-6CA6-4B80-A7C0-E3410428BED6@kirei.se> <557EBC88-0EB5-49EA-8ED1-A93EF0E5BEF5@kumari.net> <0FBA90D5-79E6-4826-9B41-2F04E01F83B0@bbn.com> To: Paul Hoffman X-Mailer: Apple Mail (2.1084) Cc: DANE WG Subject: Re: [dane] #31: Multiple TLSA records in a response 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, 08 Sep 2011 16:04:14 -0000 n Sep 8, 2011, at 11:54 AM, Paul Hoffman wrote: > On Sep 8, 2011, at 7:29 AM, Richard L. Barnes wrote: >=20 >> I would actually like to propose a slightly different approach here. >>=20 >> If you look at the use cases document, there are at least two = different uses for multiple TLSA records. The "Roll-Over" paragraph = discusses having two certificates active at once, and the "Combination" = paragraph discusses having multiple constraints on a certificate, e.g., = to allow a domain-operated CA and no other. The "Combination" case = cannot be met with the text under discussion, since only one association = is ever considered. >>=20 >> As an alternative, I would propose that we create a simple way to = combine TLSA associations in a kind of disjunctive normal form. = Currently, TLSA records are combined with an "or" operation -- the whole = matches iff any one matches: >> RR1 || RR2 || RR3 || RR4 >> It would be nice to be able to say "AND these records together", so = that you could have something like the following: >> RR1 || (RR2 && RR3) || RR4 >> That way you could still do "first match", but that match might be = across a couple of records. >>=20 >> Proposal: Add a "group id" (gid) field to the TLSA record format. = This field doesn't need to be long, one octet would suffice, and change = the matching logic to the following: >> " >> When there more than one TLSA record for a target domain, a = certificate matches if it matches all of the records within any record = group. Record groups are identified by the GID field; a group is = comprised of all records with the same GID value. To determine whether = a certificate is a TLSA match for a domain, it SHOULD execute the = following steps: >> 1. Gather TLSA records into groups by GID >> 2. For each group >> - Determine whether the certificate matches all records in the group >> - If the certificate matches, then return true >> - If the certificate does not match, then process the next group >> 3. If no group matches, then return false >> " >>=20 >> The current situation can be replicated by assigning each record a = distinct GID. >>=20 >> This algorithm does require the client to process all TLSA records, = but only to the extent of parsing them and pulling the GIDs. That's a = much cheaper operation than actually doing the matches. >=20 >=20 > While this change does meet the "combination" use case, it also makes = the protocol more complex. It requires that domain administrators who = don't care about combination still pick a group ID (even if it is 0). Is = the use case actually worth the additional complexity? If so, I think = that Richard's proposal is probably the least complex way to implement = it. If there's worry about defaults, you could certainly create a "no group" = special case (e.g., GID=3D=3D0), and update the processing so that "no = group" things are handled on an "individual first match" basis (i.e., = the current rules) (i.e., each record as its own group). --Richard From yzw_iplab@163.com Thu Sep 8 17:40:31 2011 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 6C5EA21F8BF0 for ; Thu, 8 Sep 2011 17:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.695 X-Spam-Level: **** X-Spam-Status: No, score=4.695 tagged_above=-999 required=5 tests=[AWL=0.490, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] 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 CnoTLZUoJHg3 for ; Thu, 8 Sep 2011 17:40:30 -0700 (PDT) Received: from m50-133.163.com (m50-133.163.com [123.125.50.133]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8BC21F8BE5 for ; Thu, 8 Sep 2011 17:40:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=Received:Date:From:To:Cc:References:Subject: Message-ID:Mime-Version:Content-Type; bh=2j3+NxLlBb6YJCZCa+eN/Cr QGOpkzmyPD/uuRjnKff0=; b=mBSuWsrVFNIfgCJu5NYq0/u6jlcgKIKN7p+BAlg jwOSG+5QHslBFJ0oHORWh/x6ucvwJifKRIrsoaU7BfTlAJPELSa8xyNLUMG0uLuo 8mQmxjbhixozV7fook0tFnYM9W2AZnjCjDJsGbvxRH/2RgkcrbkYZ11cpNAZAWfK tBNo= Received: from lenovo-THINK (unknown [218.241.111.47]) by smtp3 (Coremail) with SMTP id DdGowED50FTjYGlOpo2WAQ--.56S2; Fri, 09 Sep 2011 08:42:12 +0800 (CST) Date: Fri, 9 Sep 2011 08:41:49 +0800 From: "yzw_iplab" To: "Richard L. Barnes" References: <4CBA8AED-F76D-46DF-A2A0-0B1608E3C8C2@kirei.se>, <201109011639444268036@163.com>, , <20110902225200.GA6521@vacation.karoshi.com.>, , <20110903112732.GA14712@vacation.karoshi.com.>, <812921FE-6CA6-4B80-A7C0-E3410428BED6@kirei.se>, <557EBC88-0EB5-49EA-8ED1-A93EF0E5BEF5@kumari.net> Message-ID: <201109090841489973304@163.com> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon754056751867_=====" X-CM-TRANSID: DdGowED50FTjYGlOpo2WAQ--.56S2 X-Coremail-Antispam: 1Uf129KBjvJXoWxAw4rur1UGr48KFW8XF1DZFb_yoWrXF18pr Z5GFsrKa1DK3WUA3s7Ka40q34rAr97t3yUXr1Ygr18uas8Xw18trWxK3WYva47Grn5GF1F qrWqkry5Jw1UAaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07jd0eQUUUUU= X-CM-SenderInfo: 512zsxhsoduqqrwthudrp/1tbiHgC1zj-6ZEXEcwAAs2 Cc: bmanning , "paul.hoffman" , dane Subject: Re: [dane] #31: Multiple TLSA records in a response 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, 09 Sep 2011 00:40:31 -0000 This is a multi-part message in MIME format. --=====003_Dragon754056751867_===== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MSlJdCBpcyB1bmNsZWFyIHdoYXQgdGhlIGRlZmluaXRpb24gb2YgR3JvdXAgaXMuDQoyKUZvciB0 aGUgVExTIHNlcnZlciwgaXQgb25seSBtYWludGFpbnMgb25lIGNlcnRpZmljYXRlIGF0IGEgdGlt ZS4gQWx0aG91Z2ggdGhlIGNlcnRpZmljYXRlIGFzc29jaWF0aW9ucyBhcmUgZ3JvdXBlZCwgdGhl eSBzdGlsbCBzaG91bGQgYmUgY2hlY2tlZCBvbmUgYnkgb25lLg0KMymhsUEgY2VydGlmaWNhdGUg bWF0Y2hlcyBpZiBpdCBtYXRjaGVzIGFsbCBvZiB0aGUgcmVjb3JkcyB3aXRoaW4gYW55IHJlY29y ZCBncm91cKGxLCB3aGF0oa9zIHRoZSBtZWFuaW5nIGFuZCBwdXJwb3NlIG9mIHRoaXM/DQoyMDEx LTA5LTA5IA0KDQoNCg0KeXp3X2lwbGFiIA0KDQoNCg0Kt6K8/sjLo7ogUmljaGFyZCBMLiBCYXJu ZXMgDQq3osvNyrG85KO6IDIwMTEtMDktMDggIDIyOjMwOjEwIA0KytW8/sjLo7ogV2FycmVuIEt1 bWFyaSANCrOty82juiBKYWtvYiBTY2hseXRlcjsgeXp3X2lwbGFiOyBibWFubmluZzsgUGF1bCBI b2ZmbWFuOyBEQU5FIFdHIA0K1vfM4qO6IFJlOiBbZGFuZV0gIzMxOiBNdWx0aXBsZSBUTFNBIHJl Y29yZHMgaW4gYSByZXNwb25zZSANCiANCkkgd291bGQgYWN0dWFsbHkgbGlrZSB0byBwcm9wb3Nl IGEgc2xpZ2h0bHkgZGlmZmVyZW50IGFwcHJvYWNoIGhlcmUuDQpJZiB5b3UgbG9vayBhdCB0aGUg dXNlIGNhc2VzIGRvY3VtZW50LCB0aGVyZSBhcmUgYXQgbGVhc3QgdHdvIGRpZmZlcmVudCB1c2Vz IGZvciBtdWx0aXBsZSBUTFNBIHJlY29yZHMuICBUaGUgIlJvbGwtT3ZlciIgcGFyYWdyYXBoIGRp c2N1c3NlcyBoYXZpbmcgdHdvIGNlcnRpZmljYXRlcyBhY3RpdmUgYXQgb25jZSwgYW5kIHRoZSAi Q29tYmluYXRpb24iIHBhcmFncmFwaCBkaXNjdXNzZXMgaGF2aW5nIG11bHRpcGxlIGNvbnN0cmFp bnRzIG9uIGEgY2VydGlmaWNhdGUsIGUuZy4sIHRvIGFsbG93IGEgZG9tYWluLW9wZXJhdGVkIENB IGFuZCBubyBvdGhlci4gIFRoZSAiQ29tYmluYXRpb24iIGNhc2UgY2Fubm90IGJlIG1ldCB3aXRo IHRoZSB0ZXh0IHVuZGVyIGRpc2N1c3Npb24sIHNpbmNlIG9ubHkgb25lIGFzc29jaWF0aW9uIGlz IGV2ZXIgY29uc2lkZXJlZC4NCkFzIGFuIGFsdGVybmF0aXZlLCBJIHdvdWxkIHByb3Bvc2UgdGhh dCB3ZSBjcmVhdGUgYSBzaW1wbGUgd2F5IHRvIGNvbWJpbmUgVExTQSBhc3NvY2lhdGlvbnMgaW4g YSBraW5kIG9mIGRpc2p1bmN0aXZlIG5vcm1hbCBmb3JtLiAgQ3VycmVudGx5LCBUTFNBIHJlY29y ZHMgYXJlIGNvbWJpbmVkIHdpdGggYW4gIm9yIiBvcGVyYXRpb24gLS0gdGhlIHdob2xlIG1hdGNo ZXMgaWZmIGFueSBvbmUgbWF0Y2hlczoNCiAgUlIxIHx8IFJSMiB8fCBSUjMgfHwgUlI0DQpJdCB3 b3VsZCBiZSBuaWNlIHRvIGJlIGFibGUgdG8gc2F5ICJBTkQgdGhlc2UgcmVjb3JkcyB0b2dldGhl ciIsIHNvIHRoYXQgeW91IGNvdWxkIGhhdmUgc29tZXRoaW5nIGxpa2UgdGhlIGZvbGxvd2luZzoN CiAgUlIxIHx8IChSUjIgJiYgUlIzKSB8fCBSUjQNClRoYXQgd2F5IHlvdSBjb3VsZCBzdGlsbCBk byAiZmlyc3QgbWF0Y2giLCBidXQgdGhhdCBtYXRjaCBtaWdodCBiZSBhY3Jvc3MgYSBjb3VwbGUg b2YgcmVjb3Jkcy4NClByb3Bvc2FsOiBBZGQgYSAiZ3JvdXAgaWQiIChnaWQpIGZpZWxkIHRvIHRo ZSBUTFNBIHJlY29yZCBmb3JtYXQuICBUaGlzIGZpZWxkIGRvZXNuJ3QgbmVlZCB0byBiZSBsb25n LCBvbmUgb2N0ZXQgd291bGQgc3VmZmljZSwgYW5kIGNoYW5nZSB0aGUgbWF0Y2hpbmcgbG9naWMg dG8gdGhlIGZvbGxvd2luZzoNCiINCldoZW4gdGhlcmUgbW9yZSB0aGFuIG9uZSBUTFNBIHJlY29y ZCBmb3IgYSB0YXJnZXQgZG9tYWluLCBhIGNlcnRpZmljYXRlIG1hdGNoZXMgaWYgaXQgbWF0Y2hl cyBhbGwgb2YgdGhlIHJlY29yZHMgd2l0aGluIGFueSByZWNvcmQgZ3JvdXAuICBSZWNvcmQgZ3Jv dXBzIGFyZSBpZGVudGlmaWVkIGJ5IHRoZSBHSUQgZmllbGQ7IGEgZ3JvdXAgaXMgY29tcHJpc2Vk IG9mIGFsbCByZWNvcmRzIHdpdGggdGhlIHNhbWUgR0lEIHZhbHVlLiAgVG8gZGV0ZXJtaW5lIHdo ZXRoZXIgYSBjZXJ0aWZpY2F0ZSBpcyBhIFRMU0EgbWF0Y2ggZm9yIGEgZG9tYWluLCBpdCBTSE9V TEQgZXhlY3V0ZSB0aGUgZm9sbG93aW5nIHN0ZXBzOg0KMS4gR2F0aGVyIFRMU0EgcmVjb3JkcyBp bnRvIGdyb3VwcyBieSBHSUQNCjIuIEZvciBlYWNoIGdyb3VwDQogICAtIERldGVybWluZSB3aGV0 aGVyIHRoZSBjZXJ0aWZpY2F0ZSBtYXRjaGVzIGFsbCByZWNvcmRzIGluIHRoZSBncm91cA0KICAg LSBJZiB0aGUgY2VydGlmaWNhdGUgbWF0Y2hlcywgdGhlbiByZXR1cm4gdHJ1ZQ0KICAgLSBJZiB0 aGUgY2VydGlmaWNhdGUgZG9lcyBub3QgbWF0Y2gsIHRoZW4gcHJvY2VzcyB0aGUgbmV4dCBncm91 cA0KMy4gSWYgbm8gZ3JvdXAgbWF0Y2hlcywgdGhlbiByZXR1cm4gZmFsc2UNCiINClRoZSBjdXJy ZW50IHNpdHVhdGlvbiBjYW4gYmUgcmVwbGljYXRlZCBieSBhc3NpZ25pbmcgZWFjaCByZWNvcmQg YSBkaXN0aW5jdCBHSUQuDQpUaGlzIGFsZ29yaXRobSBkb2VzIHJlcXVpcmUgdGhlIGNsaWVudCB0 byBwcm9jZXNzIGFsbCBUTFNBIHJlY29yZHMsIGJ1dCBvbmx5IHRvIHRoZSBleHRlbnQgb2YgcGFy c2luZyB0aGVtIGFuZCBwdWxsaW5nIHRoZSBHSURzLiAgVGhhdCdzIGEgbXVjaCBjaGVhcGVyIG9w ZXJhdGlvbiB0aGFuIGFjdHVhbGx5IGRvaW5nIHRoZSBtYXRjaGVzLg0KLS1SaWNoYXJkDQpPbiBT ZXAgNywgMjAxMSwgYXQgNjo1MSBQTSwgV2FycmVuIEt1bWFyaSB3cm90ZToNCj4gQWxyaWdodHmh rQ0KPiANCj4gQXMgcGFydCBvZiB0aGUgbmV3LCBmYXN0ZXIsIGxlYW5lciwgbWVhbmVyIGFwcHJv YWNoIHRvIHdvcmtpbmcgaXNzdWVzIEknZCBsaWtlIHRvIGNhbGwgY29uc2Vuc3VzIG9uIHRoaXMg b24gRnJpZGF5IDE2OjAwVVRDLg0KPiANCj4gSXMgdGhlIChjdXJyZW50KSBiZWxvdyB0ZXh0IGFj Y2VwdGFibGUgKGVzcGVjaWFsbHkgYWZ0ZXIgInVzYWJsZSIgaXMgY2xhcmlmaWVkIGluIHRoZSBu ZXh0IHZlcnNpb24pIHRvIHRoZSBXRz8NCj4gDQo+IFcNCj4gT24gU2VwIDMsIDIwMTEsIGF0IDc6 NDggQU0sIEpha29iIFNjaGx5dGVyIHdyb3RlOg0KPiANCj4+IE9uIDMgc2VwIDIwMTEsIGF0IDEz OjI3LCBibWFubmluZ0B2YWNhdGlvbi5rYXJvc2hpLmNvbSB3cm90ZToNCj4+IA0KPj4+ICBvayws LCBmaXJzdCBtYXRjaC4gIGlzIHRoYXQgaW4gdGhlIHNwZWM/DQo+PiANCj4+IFllcy4NCj4+IA0K Pj4gIklmIGEgbWF0Y2ggYmV0d2VlbiBvbmUgb2YgdGhlIGNlcnRpZmljYXRlIGFzc29jaWF0aW9u KHMpIGFuZCB0aGUNCj4+ICBzZXJ2ZXIncyBlbmQgZW50aXR5IGNlcnRpZmljYXRlIGluIFRMUyBp cyBmb3VuZCwgdGhlIFRMUyBjbGllbnQNCj4+ICBjb250aW51ZXMgdGhlIFRMUyBoYW5kc2hha2Uu ICBJZiBubyBtYXRjaCBiZXR3ZWVuIHRoZSB1c2FibGUNCj4+ICBjZXJ0aWZpY2F0ZSBhc3NvY2lh dGlvbihzKSBhbmQgdGhlIHNlcnZlcidzIGVuZCBlbnRpdHkgY2VydGlmaWNhdGUgaW4NCj4+ICBU TFMgaXMgZm91bmQsIHRoZSBUTFMgY2xpZW50IE1VU1QgYWJvcnQgdGhlIGhhbmRzaGFrZSB3aXRo IGFuDQo+PiAgImFjY2Vzc19kZW5pZWQiIGVycm9yLiINCj4+IA0KPj4gKHRoZSBkZWZpbml0aW9u IG9mICJ1c2FibGUiLCB3aGF0IFRMU0EgcmVjb3JkcyB0byBpZ25vcmUgZXRjLiBpcyBkZWZpbmVk IGFzIHdlbGwsIGFuZCBpcyBldmVuIG1vcmUgY2xhcmlmaWVkIGluIHRoZSBuZXh0IHZlcnNpb24p DQo+PiANCj4+ICBqYWtvYg0KPj4gDQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+PiBkYW5lIG1haWxpbmcgbGlzdA0KPj4gZGFuZUBpZXRm Lm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kYW5lDQo+PiAN Cj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IGRhbmUgbWFpbGluZyBsaXN0DQo+IGRhbmVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9kYW5lDQo= --=====003_Dragon754056751867_===== Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBuYW1lPUdFTkVSQVRPUiBjb250 ZW50PSJNU0hUTUwgOS4wMC44MTEyLjE2NDM0Ij4NCjxTVFlMRT5AZm9udC1mYWNlIHsNCglmb250 LWZhbWlseTogy87M5TsNCn0NCkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBWZXJkYW5hOw0K fQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IEDLzszlOw0KfQ0KQHBhZ2UgU2VjdGlvbjEg e3NpemU6IDU5NS4zcHQgODQxLjlwdDsgbWFyZ2luOiA3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4w cHQ7IGxheW91dC1ncmlkOiAxNS42cHQ7IH0NClAuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJRlk6 IGludGVyLWlkZW9ncmFwaDsgVEVYVC1BTElHTjoganVzdGlmeTsgTUFSR0lOOiAwY20gMGNtIDBw dDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iOyBGT05ULVNJWkU6IDEwLjVwdA0KfQ0K TEkuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJRlk6IGludGVyLWlkZW9ncmFwaDsgVEVYVC1BTElH TjoganVzdGlmeTsgTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcg Um9tYW4iOyBGT05ULVNJWkU6IDEwLjVwdA0KfQ0KRElWLk1zb05vcm1hbCB7DQoJVEVYVC1KVVNU SUZZOiBpbnRlci1pZGVvZ3JhcGg7IFRFWFQtQUxJR046IGp1c3RpZnk7IE1BUkdJTjogMGNtIDBj bSAwcHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgRk9OVC1TSVpFOiAxMC41cHQN Cn0NCkE6bGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lDQp9 DQpTUEFOLk1zb0h5cGVybGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5k ZXJsaW5lDQp9DQpBOnZpc2l0ZWQgew0KCUNPTE9SOiBwdXJwbGU7IFRFWFQtREVDT1JBVElPTjog dW5kZXJsaW5lDQp9DQpTUEFOLk1zb0h5cGVybGlua0ZvbGxvd2VkIHsNCglDT0xPUjogcHVycGxl OyBURVhULURFQ09SQVRJT046IHVuZGVybGluZQ0KfQ0KU1BBTi5FbWFpbFN0eWxlMTcgew0KCUZP TlQtU1RZTEU6IG5vcm1hbDsgRk9OVC1GQU1JTFk6IFZlcmRhbmE7IENPTE9SOiB3aW5kb3d0ZXh0 OyBGT05ULVdFSUdIVDogbm9ybWFsOyBURVhULURFQ09SQVRJT046IG5vbmU7IG1zby1zdHlsZS10 eXBlOiBwZXJzb25hbC1jb21wb3NlDQp9DQpESVYuU2VjdGlvbjEgew0KCXBhZ2U6IFNlY3Rpb24x DQp9DQpVTktOT1dOIHsNCglGT05ULVNJWkU6IDEwcHQNCn0NCkJMT0NLUVVPVEUgew0KCU1BUkdJ Ti1UT1A6IDBweDsgTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tTEVGVDogMmVtDQp9DQpPTCB7 DQoJTUFSR0lOLVRPUDogMHB4OyBNQVJHSU4tQk9UVE9NOiAwcHgNCn0NClVMIHsNCglNQVJHSU4t VE9QOiAwcHg7IE1BUkdJTi1CT1RUT006IDBweA0KfQ0KPC9TVFlMRT4NCjwvSEVBRD4NCjxCT0RZ IHN0eWxlPSJNQVJHSU46IDEwcHg7IEZPTlQtRkFNSUxZOiB2ZXJkYW5hOyBGT05ULVNJWkU6IDEw cHQiPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwPjxTUEFOIA0Kc3R5bGU9IkZPTlQtRkFNSUxZ OiAnVmVyZGFuYScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogbmF2eTsgbXNvLWJpZGktZm9udC1mYW1p bHk6IMvOzOU7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBaSC1DTiIgDQpsYW5nPUVOLVVTPg0KPFAg c3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBzaXplPTI+ PFNQQU4gDQpzdHlsZT0iRk9OVC1GQU1JTFk6ICdWZXJkYW5hJywnc2Fucy1zZXJpZic7IENPTE9S OiBuYXZ5OyBtc28tYmlkaS1mb250LWZhbWlseTogy87M5TsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 IFpILUNOIiANCmxhbmc9RU4tVVM+MSlJdCBpcyB1bmNsZWFyIHdoYXQgdGhlIGRlZmluaXRpb24g b2YgR3JvdXAgaXMuPC9TUEFOPjxCIA0Kc3R5bGU9Im1zby1iaWRpLWZvbnQtd2VpZ2h0OiBub3Jt YWwiPjxTUEFOIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTogWkgtQ04iIA0KbGFuZz1FTi1V Uz48P3htbDpuYW1lc3BhY2UgcHJlZml4ID0gbyBucyA9IA0KInVybjpzY2hlbWFzLW1pY3Jvc29m dC1jb206b2ZmaWNlOm9mZmljZSIgLz48bzpwPjwvbzpwPjwvU1BBTj48L0I+PC9GT05UPjwvUD4N CjxQIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQpz dHlsZT0iRk9OVC1GQU1JTFk6ICdWZXJkYW5hJywnc2Fucy1zZXJpZic7IENPTE9SOiBuYXZ5OyBt c28tYmlkaS1mb250LWZhbWlseTogy87M5TsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IFpILUNOIiAN Cmxhbmc9RU4tVVM+PEZPTlQgc2l6ZT0yPjIpRm9yIHRoZSBUTFMgc2VydmVyLCBpdCBvbmx5IG1h aW50YWlucyBvbmUgY2VydGlmaWNhdGUgDQphdCBhIHRpbWUuIEFsdGhvdWdoIHRoZSBjZXJ0aWZp Y2F0ZSBhc3NvY2lhdGlvbnMgYXJlIGdyb3VwZWQsIHRoZXkgc3RpbGwgc2hvdWxkIA0KYmUgY2hl Y2tlZCBvbmUgYnkgb25lLjxvOnA+PC9vOnA+PC9GT05UPjwvU1BBTj48L1A+DQo8UCBzdHlsZT0i TUFSR0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0Kc3R5bGU9IkZPTlQt RkFNSUxZOiAnVmVyZGFuYScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogbmF2eTsgbXNvLWJpZGktZm9u dC1mYW1pbHk6IMvOzOU7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBaSC1DTiIgDQpsYW5nPUVOLVVT PjxGT05UIHNpemU9Mj4zKaGxQSBjZXJ0aWZpY2F0ZSBtYXRjaGVzIGlmIGl0IG1hdGNoZXMgYWxs IG9mIHRoZSANCnJlY29yZHMgd2l0aGluIGFueSByZWNvcmQgZ3JvdXChsSwgd2hhdKGvcyB0aGUg bWVhbmluZyBhbmQgcHVycG9zZSBvZiANCnRoaXM/PG86cD48L286cD48L0ZPTlQ+PC9TUEFOPjwv UD4NCjxQIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz1Nc29Ob3JtYWw+PC9TUEFO PjwvRk9OVD48Rk9OVCANCmNvbG9yPSMwMDAwODA+PC9GT05UPjwvUD48L0RJVj4NCjxESVY+PEZP TlQgY29sb3I9I2MwYzBjMD4yMDExLTA5LTA5IDwvRk9OVD48L0RJVj48Rk9OVCBjb2xvcj0jMDAw MDgwPg0KPEhSIHN0eWxlPSJXSURUSDogMTAwcHgiIGFsaWduPWxlZnQgY29sb3I9I2I1YzRkZiBT SVpFPTE+DQo8L0ZPTlQ+DQo8RElWPjxGT05UIGNvbG9yPSNjMGMwYzA+PFNQQU4+eXp3X2lwbGFi PC9TUEFOPiA8L0ZPTlQ+PC9ESVY+DQo8SFIgY29sb3I9I2I1YzRkZiBTSVpFPTE+DQoNCjxESVY+ PFNUUk9ORz63orz+yMujujwvU1RST05HPiBSaWNoYXJkIEwuIEJhcm5lcyA8L0RJVj4NCjxESVY+ PFNUUk9ORz63osvNyrG85KO6PC9TVFJPTkc+IDIwMTEtMDktMDgmbmJzcDsgMjI6MzA6MTAgPC9E SVY+DQo8RElWPjxTVFJPTkc+ytW8/sjLo7o8L1NUUk9ORz4gV2FycmVuIEt1bWFyaSA8L0RJVj4N CjxESVY+PFNUUk9ORz6zrcvNo7o8L1NUUk9ORz4gSmFrb2IgU2NobHl0ZXI7IHl6d19pcGxhYjsg Ym1hbm5pbmc7IFBhdWwgSG9mZm1hbjsgDQpEQU5FIFdHIDwvRElWPg0KPERJVj48U1RST05HPtb3 zOKjujwvU1RST05HPiBSZTogW2RhbmVdICMzMTogTXVsdGlwbGUgVExTQSByZWNvcmRzIGluIGEg cmVzcG9uc2UgDQo8L0RJVj4NCjxESVY+IDwvRElWPg0KPERJVj4NCjxESVY+SSZuYnNwO3dvdWxk Jm5ic3A7YWN0dWFsbHkmbmJzcDtsaWtlJm5ic3A7dG8mbmJzcDtwcm9wb3NlJm5ic3A7YSZuYnNw O3NsaWdodGx5Jm5ic3A7ZGlmZmVyZW50Jm5ic3A7YXBwcm9hY2gmbmJzcDtoZXJlLjwvRElWPg0K PERJVj48L0RJVj4NCjxESVY+SWYmbmJzcDt5b3UmbmJzcDtsb29rJm5ic3A7YXQmbmJzcDt0aGUm bmJzcDt1c2UmbmJzcDtjYXNlcyZuYnNwO2RvY3VtZW50LCZuYnNwO3RoZXJlJm5ic3A7YXJlJm5i c3A7YXQmbmJzcDtsZWFzdCZuYnNwO3R3byZuYnNwO2RpZmZlcmVudCZuYnNwO3VzZXMmbmJzcDtm b3ImbmJzcDttdWx0aXBsZSZuYnNwO1RMU0EmbmJzcDtyZWNvcmRzLiZuYnNwOyZuYnNwO1RoZSZu YnNwOyJSb2xsLU92ZXIiJm5ic3A7cGFyYWdyYXBoJm5ic3A7ZGlzY3Vzc2VzJm5ic3A7aGF2aW5n Jm5ic3A7dHdvJm5ic3A7Y2VydGlmaWNhdGVzJm5ic3A7YWN0aXZlJm5ic3A7YXQmbmJzcDtvbmNl LCZuYnNwO2FuZCZuYnNwO3RoZSZuYnNwOyJDb21iaW5hdGlvbiImbmJzcDtwYXJhZ3JhcGgmbmJz cDtkaXNjdXNzZXMmbmJzcDtoYXZpbmcmbmJzcDttdWx0aXBsZSZuYnNwO2NvbnN0cmFpbnRzJm5i c3A7b24mbmJzcDthJm5ic3A7Y2VydGlmaWNhdGUsJm5ic3A7ZS5nLiwmbmJzcDt0byZuYnNwO2Fs bG93Jm5ic3A7YSZuYnNwO2RvbWFpbi1vcGVyYXRlZCZuYnNwO0NBJm5ic3A7YW5kJm5ic3A7bm8m bmJzcDtvdGhlci4mbmJzcDsmbmJzcDtUaGUmbmJzcDsiQ29tYmluYXRpb24iJm5ic3A7Y2FzZSZu YnNwO2Nhbm5vdCZuYnNwO2JlJm5ic3A7bWV0Jm5ic3A7d2l0aCZuYnNwO3RoZSZuYnNwO3RleHQm bmJzcDt1bmRlciZuYnNwO2Rpc2N1c3Npb24sJm5ic3A7c2luY2UmbmJzcDtvbmx5Jm5ic3A7b25l Jm5ic3A7YXNzb2NpYXRpb24mbmJzcDtpcyZuYnNwO2V2ZXImbmJzcDtjb25zaWRlcmVkLjwvRElW Pg0KPERJVj48L0RJVj4NCjxESVY+QXMmbmJzcDthbiZuYnNwO2FsdGVybmF0aXZlLCZuYnNwO0km bmJzcDt3b3VsZCZuYnNwO3Byb3Bvc2UmbmJzcDt0aGF0Jm5ic3A7d2UmbmJzcDtjcmVhdGUmbmJz cDthJm5ic3A7c2ltcGxlJm5ic3A7d2F5Jm5ic3A7dG8mbmJzcDtjb21iaW5lJm5ic3A7VExTQSZu YnNwO2Fzc29jaWF0aW9ucyZuYnNwO2luJm5ic3A7YSZuYnNwO2tpbmQmbmJzcDtvZiZuYnNwO2Rp c2p1bmN0aXZlJm5ic3A7bm9ybWFsJm5ic3A7Zm9ybS4mbmJzcDsmbmJzcDtDdXJyZW50bHksJm5i c3A7VExTQSZuYnNwO3JlY29yZHMmbmJzcDthcmUmbmJzcDtjb21iaW5lZCZuYnNwO3dpdGgmbmJz cDthbiZuYnNwOyJvciImbmJzcDtvcGVyYXRpb24mbmJzcDstLSZuYnNwO3RoZSZuYnNwO3dob2xl Jm5ic3A7bWF0Y2hlcyZuYnNwO2lmZiZuYnNwO2FueSZuYnNwO29uZSZuYnNwO21hdGNoZXM6PC9E SVY+DQo8RElWPiZuYnNwOyZuYnNwO1JSMSZuYnNwO3x8Jm5ic3A7UlIyJm5ic3A7fHwmbmJzcDtS UjMmbmJzcDt8fCZuYnNwO1JSNDwvRElWPg0KPERJVj5JdCZuYnNwO3dvdWxkJm5ic3A7YmUmbmJz cDtuaWNlJm5ic3A7dG8mbmJzcDtiZSZuYnNwO2FibGUmbmJzcDt0byZuYnNwO3NheSZuYnNwOyJB TkQmbmJzcDt0aGVzZSZuYnNwO3JlY29yZHMmbmJzcDt0b2dldGhlciIsJm5ic3A7c28mbmJzcDt0 aGF0Jm5ic3A7eW91Jm5ic3A7Y291bGQmbmJzcDtoYXZlJm5ic3A7c29tZXRoaW5nJm5ic3A7bGlr ZSZuYnNwO3RoZSZuYnNwO2ZvbGxvd2luZzo8L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7UlIxJm5i c3A7fHwmbmJzcDsoUlIyJm5ic3A7JmFtcDsmYW1wOyZuYnNwO1JSMykmbmJzcDt8fCZuYnNwO1JS NDwvRElWPg0KPERJVj5UaGF0Jm5ic3A7d2F5Jm5ic3A7eW91Jm5ic3A7Y291bGQmbmJzcDtzdGls bCZuYnNwO2RvJm5ic3A7ImZpcnN0Jm5ic3A7bWF0Y2giLCZuYnNwO2J1dCZuYnNwO3RoYXQmbmJz cDttYXRjaCZuYnNwO21pZ2h0Jm5ic3A7YmUmbmJzcDthY3Jvc3MmbmJzcDthJm5ic3A7Y291cGxl Jm5ic3A7b2YmbmJzcDtyZWNvcmRzLjwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+UHJvcG9zYWw6 Jm5ic3A7QWRkJm5ic3A7YSZuYnNwOyJncm91cCZuYnNwO2lkIiZuYnNwOyhnaWQpJm5ic3A7Zmll bGQmbmJzcDt0byZuYnNwO3RoZSZuYnNwO1RMU0EmbmJzcDtyZWNvcmQmbmJzcDtmb3JtYXQuJm5i c3A7Jm5ic3A7VGhpcyZuYnNwO2ZpZWxkJm5ic3A7ZG9lc24ndCZuYnNwO25lZWQmbmJzcDt0byZu YnNwO2JlJm5ic3A7bG9uZywmbmJzcDtvbmUmbmJzcDtvY3RldCZuYnNwO3dvdWxkJm5ic3A7c3Vm ZmljZSwmbmJzcDthbmQmbmJzcDtjaGFuZ2UmbmJzcDt0aGUmbmJzcDttYXRjaGluZyZuYnNwO2xv Z2ljJm5ic3A7dG8mbmJzcDt0aGUmbmJzcDtmb2xsb3dpbmc6PC9ESVY+DQo8RElWPiI8L0RJVj4N CjxESVY+V2hlbiZuYnNwO3RoZXJlJm5ic3A7bW9yZSZuYnNwO3RoYW4mbmJzcDtvbmUmbmJzcDtU TFNBJm5ic3A7cmVjb3JkJm5ic3A7Zm9yJm5ic3A7YSZuYnNwO3RhcmdldCZuYnNwO2RvbWFpbiwm bmJzcDthJm5ic3A7Y2VydGlmaWNhdGUmbmJzcDttYXRjaGVzJm5ic3A7aWYmbmJzcDtpdCZuYnNw O21hdGNoZXMmbmJzcDthbGwmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3JlY29yZHMmbmJzcDt3aXRo aW4mbmJzcDthbnkmbmJzcDtyZWNvcmQmbmJzcDtncm91cC4mbmJzcDsmbmJzcDtSZWNvcmQmbmJz cDtncm91cHMmbmJzcDthcmUmbmJzcDtpZGVudGlmaWVkJm5ic3A7YnkmbmJzcDt0aGUmbmJzcDtH SUQmbmJzcDtmaWVsZDsmbmJzcDthJm5ic3A7Z3JvdXAmbmJzcDtpcyZuYnNwO2NvbXByaXNlZCZu YnNwO29mJm5ic3A7YWxsJm5ic3A7cmVjb3JkcyZuYnNwO3dpdGgmbmJzcDt0aGUmbmJzcDtzYW1l Jm5ic3A7R0lEJm5ic3A7dmFsdWUuJm5ic3A7Jm5ic3A7VG8mbmJzcDtkZXRlcm1pbmUmbmJzcDt3 aGV0aGVyJm5ic3A7YSZuYnNwO2NlcnRpZmljYXRlJm5ic3A7aXMmbmJzcDthJm5ic3A7VExTQSZu YnNwO21hdGNoJm5ic3A7Zm9yJm5ic3A7YSZuYnNwO2RvbWFpbiwmbmJzcDtpdCZuYnNwO1NIT1VM RCZuYnNwO2V4ZWN1dGUmbmJzcDt0aGUmbmJzcDtmb2xsb3dpbmcmbmJzcDtzdGVwczo8L0RJVj4N CjxESVY+MS4mbmJzcDtHYXRoZXImbmJzcDtUTFNBJm5ic3A7cmVjb3JkcyZuYnNwO2ludG8mbmJz cDtncm91cHMmbmJzcDtieSZuYnNwO0dJRDwvRElWPg0KPERJVj4yLiZuYnNwO0ZvciZuYnNwO2Vh Y2gmbmJzcDtncm91cDwvRElWPg0KPERJVj4mbmJzcDsmbmJzcDsmbmJzcDstJm5ic3A7RGV0ZXJt aW5lJm5ic3A7d2hldGhlciZuYnNwO3RoZSZuYnNwO2NlcnRpZmljYXRlJm5ic3A7bWF0Y2hlcyZu YnNwO2FsbCZuYnNwO3JlY29yZHMmbmJzcDtpbiZuYnNwO3RoZSZuYnNwO2dyb3VwPC9ESVY+DQo8 RElWPiZuYnNwOyZuYnNwOyZuYnNwOy0mbmJzcDtJZiZuYnNwO3RoZSZuYnNwO2NlcnRpZmljYXRl Jm5ic3A7bWF0Y2hlcywmbmJzcDt0aGVuJm5ic3A7cmV0dXJuJm5ic3A7dHJ1ZTwvRElWPg0KPERJ Vj4mbmJzcDsmbmJzcDsmbmJzcDstJm5ic3A7SWYmbmJzcDt0aGUmbmJzcDtjZXJ0aWZpY2F0ZSZu YnNwO2RvZXMmbmJzcDtub3QmbmJzcDttYXRjaCwmbmJzcDt0aGVuJm5ic3A7cHJvY2VzcyZuYnNw O3RoZSZuYnNwO25leHQmbmJzcDtncm91cDwvRElWPg0KPERJVj4zLiZuYnNwO0lmJm5ic3A7bm8m bmJzcDtncm91cCZuYnNwO21hdGNoZXMsJm5ic3A7dGhlbiZuYnNwO3JldHVybiZuYnNwO2ZhbHNl PC9ESVY+DQo8RElWPiI8L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPlRoZSZuYnNwO2N1cnJlbnQm bmJzcDtzaXR1YXRpb24mbmJzcDtjYW4mbmJzcDtiZSZuYnNwO3JlcGxpY2F0ZWQmbmJzcDtieSZu YnNwO2Fzc2lnbmluZyZuYnNwO2VhY2gmbmJzcDtyZWNvcmQmbmJzcDthJm5ic3A7ZGlzdGluY3Qm bmJzcDtHSUQuPC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj5UaGlzJm5ic3A7YWxnb3JpdGhtJm5i c3A7ZG9lcyZuYnNwO3JlcXVpcmUmbmJzcDt0aGUmbmJzcDtjbGllbnQmbmJzcDt0byZuYnNwO3By b2Nlc3MmbmJzcDthbGwmbmJzcDtUTFNBJm5ic3A7cmVjb3JkcywmbmJzcDtidXQmbmJzcDtvbmx5 Jm5ic3A7dG8mbmJzcDt0aGUmbmJzcDtleHRlbnQmbmJzcDtvZiZuYnNwO3BhcnNpbmcmbmJzcDt0 aGVtJm5ic3A7YW5kJm5ic3A7cHVsbGluZyZuYnNwO3RoZSZuYnNwO0dJRHMuJm5ic3A7Jm5ic3A7 VGhhdCdzJm5ic3A7YSZuYnNwO211Y2gmbmJzcDtjaGVhcGVyJm5ic3A7b3BlcmF0aW9uJm5ic3A7 dGhhbiZuYnNwO2FjdHVhbGx5Jm5ic3A7ZG9pbmcmbmJzcDt0aGUmbmJzcDttYXRjaGVzLjwvRElW Pg0KPERJVj48L0RJVj4NCjxESVY+LS1SaWNoYXJkPC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj48 L0RJVj4NCjxESVY+T24mbmJzcDtTZXAmbmJzcDs3LCZuYnNwOzIwMTEsJm5ic3A7YXQmbmJzcDs2 OjUxJm5ic3A7UE0sJm5ic3A7V2FycmVuJm5ic3A7S3VtYXJpJm5ic3A7d3JvdGU6PC9ESVY+DQo8 RElWPjwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7QWxyaWdodHmhrTwvRElWPg0KPERJVj4mZ3Q7Jm5i c3A7PC9ESVY+DQo8RElWPiZndDsmbmJzcDtBcyZuYnNwO3BhcnQmbmJzcDtvZiZuYnNwO3RoZSZu YnNwO25ldywmbmJzcDtmYXN0ZXIsJm5ic3A7bGVhbmVyLCZuYnNwO21lYW5lciZuYnNwO2FwcHJv YWNoJm5ic3A7dG8mbmJzcDt3b3JraW5nJm5ic3A7aXNzdWVzJm5ic3A7SSdkJm5ic3A7bGlrZSZu YnNwO3RvJm5ic3A7Y2FsbCZuYnNwO2NvbnNlbnN1cyZuYnNwO29uJm5ic3A7dGhpcyZuYnNwO29u Jm5ic3A7RnJpZGF5Jm5ic3A7MTY6MDBVVEMuPC9ESVY+DQo8RElWPiZndDsmbmJzcDs8L0RJVj4N CjxESVY+Jmd0OyZuYnNwO0lzJm5ic3A7dGhlJm5ic3A7KGN1cnJlbnQpJm5ic3A7YmVsb3cmbmJz cDt0ZXh0Jm5ic3A7YWNjZXB0YWJsZSZuYnNwOyhlc3BlY2lhbGx5Jm5ic3A7YWZ0ZXImbmJzcDsi dXNhYmxlIiZuYnNwO2lzJm5ic3A7Y2xhcmlmaWVkJm5ic3A7aW4mbmJzcDt0aGUmbmJzcDtuZXh0 Jm5ic3A7dmVyc2lvbikmbmJzcDt0byZuYnNwO3RoZSZuYnNwO1dHPzwvRElWPg0KPERJVj4mZ3Q7 Jm5ic3A7PC9ESVY+DQo8RElWPiZndDsmbmJzcDtXPC9ESVY+DQo8RElWPiZndDsmbmJzcDtPbiZu YnNwO1NlcCZuYnNwOzMsJm5ic3A7MjAxMSwmbmJzcDthdCZuYnNwOzc6NDgmbmJzcDtBTSwmbmJz cDtKYWtvYiZuYnNwO1NjaGx5dGVyJm5ic3A7d3JvdGU6PC9ESVY+DQo8RElWPiZndDsmbmJzcDs8 L0RJVj4NCjxESVY+Jmd0OyZndDsmbmJzcDtPbiZuYnNwOzMmbmJzcDtzZXAmbmJzcDsyMDExLCZu YnNwO2F0Jm5ic3A7MTM6MjcsJm5ic3A7Ym1hbm5pbmdAdmFjYXRpb24ua2Fyb3NoaS5jb20mbmJz cDt3cm90ZTo8L0RJVj4NCjxESVY+Jmd0OyZndDsmbmJzcDs8L0RJVj4NCjxESVY+Jmd0OyZndDsm Z3Q7Jm5ic3A7IA0Kb2ssLCwmbmJzcDtmaXJzdCZuYnNwO21hdGNoLiZuYnNwOyZuYnNwO2lzJm5i c3A7dGhhdCZuYnNwO2luJm5ic3A7dGhlJm5ic3A7c3BlYz88L0RJVj4NCjxESVY+Jmd0OyZndDsm bmJzcDs8L0RJVj4NCjxESVY+Jmd0OyZndDsmbmJzcDtZZXMuPC9ESVY+DQo8RElWPiZndDsmZ3Q7 Jm5ic3A7PC9ESVY+DQo8RElWPiZndDsmZ3Q7Jm5ic3A7IklmJm5ic3A7YSZuYnNwO21hdGNoJm5i c3A7YmV0d2VlbiZuYnNwO29uZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7Y2VydGlmaWNhdGUmbmJz cDthc3NvY2lhdGlvbihzKSZuYnNwO2FuZCZuYnNwO3RoZTwvRElWPg0KPERJVj4mZ3Q7Jmd0OyZu YnNwOyZuYnNwO3NlcnZlcidzJm5ic3A7ZW5kJm5ic3A7ZW50aXR5Jm5ic3A7Y2VydGlmaWNhdGUm bmJzcDtpbiZuYnNwO1RMUyZuYnNwO2lzJm5ic3A7Zm91bmQsJm5ic3A7dGhlJm5ic3A7VExTJm5i c3A7Y2xpZW50PC9ESVY+DQo8RElWPiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Y29udGludWVzJm5ic3A7 dGhlJm5ic3A7VExTJm5ic3A7aGFuZHNoYWtlLiZuYnNwOyZuYnNwO0lmJm5ic3A7bm8mbmJzcDtt YXRjaCZuYnNwO2JldHdlZW4mbmJzcDt0aGUmbmJzcDt1c2FibGU8L0RJVj4NCjxESVY+Jmd0OyZn dDsmbmJzcDsmbmJzcDtjZXJ0aWZpY2F0ZSZuYnNwO2Fzc29jaWF0aW9uKHMpJm5ic3A7YW5kJm5i c3A7dGhlJm5ic3A7c2VydmVyJ3MmbmJzcDtlbmQmbmJzcDtlbnRpdHkmbmJzcDtjZXJ0aWZpY2F0 ZSZuYnNwO2luPC9ESVY+DQo8RElWPiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7VExTJm5ic3A7aXMmbmJz cDtmb3VuZCwmbmJzcDt0aGUmbmJzcDtUTFMmbmJzcDtjbGllbnQmbmJzcDtNVVNUJm5ic3A7YWJv cnQmbmJzcDt0aGUmbmJzcDtoYW5kc2hha2UmbmJzcDt3aXRoJm5ic3A7YW48L0RJVj4NCjxESVY+ Jmd0OyZndDsmbmJzcDsmbmJzcDsiYWNjZXNzX2RlbmllZCImbmJzcDtlcnJvci4iPC9ESVY+DQo8 RElWPiZndDsmZ3Q7Jm5ic3A7PC9ESVY+DQo8RElWPiZndDsmZ3Q7Jm5ic3A7KHRoZSZuYnNwO2Rl ZmluaXRpb24mbmJzcDtvZiZuYnNwOyJ1c2FibGUiLCZuYnNwO3doYXQmbmJzcDtUTFNBJm5ic3A7 cmVjb3JkcyZuYnNwO3RvJm5ic3A7aWdub3JlJm5ic3A7ZXRjLiZuYnNwO2lzJm5ic3A7ZGVmaW5l ZCZuYnNwO2FzJm5ic3A7d2VsbCwmbmJzcDthbmQmbmJzcDtpcyZuYnNwO2V2ZW4mbmJzcDttb3Jl Jm5ic3A7Y2xhcmlmaWVkJm5ic3A7aW4mbmJzcDt0aGUmbmJzcDtuZXh0Jm5ic3A7dmVyc2lvbik8 L0RJVj4NCjxESVY+Jmd0OyZndDsmbmJzcDs8L0RJVj4NCjxESVY+Jmd0OyZndDsmbmJzcDsgamFr b2I8L0RJVj4NCjxESVY+Jmd0OyZndDsmbmJzcDs8L0RJVj4NCjxESVY+Jmd0OyZndDsmbmJzcDs8 L0RJVj4NCjxESVY+Jmd0OyZndDsmbmJzcDtfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzwvRElWPg0KPERJVj4mZ3Q7Jmd0OyZuYnNwO2RhbmUmbmJzcDttYWls aW5nJm5ic3A7bGlzdDwvRElWPg0KPERJVj4mZ3Q7Jmd0OyZuYnNwO2RhbmVAaWV0Zi5vcmc8L0RJ Vj4NCjxESVY+Jmd0OyZndDsmbmJzcDtodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2RhbmU8L0RJVj4NCjxESVY+Jmd0OyZndDsmbmJzcDs8L0RJVj4NCjxESVY+Jmd0OyZuYnNw OzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188L0RJVj4NCjxESVY+Jmd0OyZuYnNwO2RhbmUmbmJzcDttYWlsaW5nJm5i c3A7bGlzdDwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7ZGFuZUBpZXRmLm9yZzwvRElWPg0KPERJVj4m Z3Q7Jm5ic3A7aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kYW5lPC9ESVY+ DQo8RElWPjwvRElWPjwvRElWPjwvQk9EWT48L0hUTUw+DQo= --=====003_Dragon754056751867_=====-- From jakob@kirei.se Fri Sep 9 00:05:25 2011 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 7591721F8B52 for ; Fri, 9 Sep 2011 00:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.642 X-Spam-Level: X-Spam-Status: No, score=-0.642 tagged_above=-999 required=5 tests=[AWL=0.056, 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 1ZMArbla6DGe for ; Fri, 9 Sep 2011 00:05:24 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id C716621F8B42 for ; Fri, 9 Sep 2011 00:05:20 -0700 (PDT) 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=K9M/aKEcgUAHAhQjC65+D9D00/kgiG8iKLSdInMc5pE=; b=dI+SjF01jPkuDcPzwsjE4MxhlgMremrOtc+UFMmQnVVQMqvBYvGA3837qcpnxMAO3qwD/Ycs9ey32 3P4O/08zW54p2gsswbS334flbywj6lINtDRgt99z5GI9HL+qOSIKbBHnlVGRZDm419Gmeh6W3+r1QP nCIqdQksejGwrmz8= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Fri, 9 Sep 2011 09:07:10 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: Date: Fri, 9 Sep 2011 09:07:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4CBA8AED-F76D-46DF-A2A0-0B1608E3C8C2@kirei.se> <201109011639444268036@163.com> <20110902225200.GA6521@vacation.karoshi.com.> <20110903112732.GA14712@vacation.karoshi.com.> <812921FE-6CA6-4B80-A7C0-E3410428BED6@kirei.se> <557EBC88-0EB5-49EA-8ED1-A93EF0E5BEF5@kumari.net> <0FBA90D5-79E6-4826-9B41-2F04E01F83B0@bbn.com> To: Paul Hoffman X-Mailer: Apple Mail (2.1244.3) Cc: DANE WG Subject: Re: [dane] #31: Multiple TLSA records in a response 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, 09 Sep 2011 07:05:25 -0000 On 8 sep 2011, at 17:54, Paul Hoffman wrote: > While this change does meet the "combination" use case, it also makes = the protocol more complex. It requires that domain administrators who = don't care about combination still pick a group ID (even if it is 0). Is = the use case actually worth the additional complexity? If so, I think = that Richard's proposal is probably the least complex way to implement = it. I do not believe that supporting "combination" is worth the additional = complexity and I urge the WG to keep DANE as simple as possible. jakob From ondrej.sury@nic.cz Fri Sep 9 00:27:22 2011 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 F1BE721F88B6 for ; Fri, 9 Sep 2011 00:27:21 -0700 (PDT) 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 iHTubJdHVdRx for ; Fri, 9 Sep 2011 00:27:21 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 3280E21F888A for ; Fri, 9 Sep 2011 00:27:21 -0700 (PDT) Received: from kimac.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id DBE2B2A010A; Fri, 9 Sep 2011 09:29:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1315553354; bh=KHMO3uwt8Ku2mGkGva2mnLhW0/7AVlfZr3jl0l2GXN8=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=URyd1CM+YDki9o2SsQ7K2ZiX8ubSO74lXxlU+hQjwHriAOIkfABf3HAC63y/3OGqk nm4T+Q5ewOsgH/IlpilIZCG0jIJuENURugexErJT9uHJNOKHPJBksJk5GNATQmD5JA 23a95MUfMSArF2lfMc136wZppSRC2a4TfHcnnx78= Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: Date: Fri, 9 Sep 2011 09:29:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4EFBB5F2-B01E-45D1-A727-5A459CE4E8B7@nic.cz> References: <4CBA8AED-F76D-46DF-A2A0-0B1608E3C8C2@kirei.se> <201109011639444268036@163.com> <20110902225200.GA6521@vacation.karoshi.com.> <20110903112732.GA14712@vacation.karoshi.com.> <812921FE-6CA6-4B80-A7C0-E3410428BED6@kirei.se> <557EBC88-0EB5-49EA-8ED1-A93EF0E5BEF5@kumari.net> <0FBA90D5-79E6-4826-9B41-2F04E01F83B0@bbn.com> To: Jakob Schlyter X-Mailer: Apple Mail (2.1244.3) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Paul Hoffman , DANE WG Subject: Re: [dane] #31: Multiple TLSA records in a response 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, 09 Sep 2011 07:27:22 -0000 On 9. 9. 2011, at 9:07, Jakob Schlyter wrote: > On 8 sep 2011, at 17:54, Paul Hoffman wrote: >=20 >> While this change does meet the "combination" use case, it also makes = the protocol more complex. It requires that domain administrators who = don't care about combination still pick a group ID (even if it is 0). Is = the use case actually worth the additional complexity? If so, I think = that Richard's proposal is probably the least complex way to implement = it. >=20 > I do not believe that supporting "combination" is worth the additional = complexity and I urge the WG to keep DANE as simple as possible. +1 -- 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 leifj@mnt.se Fri Sep 9 01:22:13 2011 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 CA83F21F8B26 for ; Fri, 9 Sep 2011 01:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=-0.400, 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 XyE7xlNjawJD for ; Fri, 9 Sep 2011 01:22:13 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id DE53121F8AD8 for ; Fri, 9 Sep 2011 01:22:12 -0700 (PDT) Received: from [192.36.125.212] (dhcp.pilsnet.sunet.se [192.36.125.212]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p898O0lf016124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 9 Sep 2011 10:24:04 +0200 (CEST) Message-ID: <4E69CD20.6030303@mnt.se> Date: Fri, 09 Sep 2011 10:24:00 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: dane@ietf.org References: <4CBA8AED-F76D-46DF-A2A0-0B1608E3C8C2@kirei.se> <201109011639444268036@163.com> <20110902225200.GA6521@vacation.karoshi.com.> <20110903112732.GA14712@vacation.karoshi.com.> <812921FE-6CA6-4B80-A7C0-E3410428BED6@kirei.se> <557EBC88-0EB5-49EA-8ED1-A93EF0E5BEF5@kumari.net> <0FBA90D5-79E6-4826-9B41-2F04E01F83B0@bbn.com> In-Reply-To: <0FBA90D5-79E6-4826-9B41-2F04E01F83B0@bbn.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [dane] #31: Multiple TLSA records in a response 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, 09 Sep 2011 08:22:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Proposal: Add a "group id" (gid) field to the TLSA record format. This field doesn't need to be long, one octet would suffice, and change the matching logic to the following: > " Woops - my featureitis detector just went off. Before you know it TLSA is the new NAPTR. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5pzSAACgkQ8Jx8FtbMZneJZgCeI5kCvnguBvB52EKevcp9cYI+ NfwAnjxlmOGMXK0X9dVqVS7BPIg70t+f =mv0E -----END PGP SIGNATURE----- From paul@xelerance.com Fri Sep 9 08:17:50 2011 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 1A63A21F86AA for ; Fri, 9 Sep 2011 08:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.489 X-Spam-Level: X-Spam-Status: No, score=-6.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 V7b5vIovrCLp for ; Fri, 9 Sep 2011 08:17:49 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id 8D6EF21F8680 for ; Fri, 9 Sep 2011 08:17:44 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 9A39E572E9; Fri, 9 Sep 2011 11:17:10 -0400 (EDT) Date: Fri, 9 Sep 2011 11:17:10 -0400 (EDT) From: Paul Wouters To: Jakob Schlyter In-Reply-To: Message-ID: References: <4CBA8AED-F76D-46DF-A2A0-0B1608E3C8C2@kirei.se> <201109011639444268036@163.com> <20110902225200.GA6521@vacation.karoshi.com.> <20110903112732.GA14712@vacation.karoshi.com.> <812921FE-6CA6-4B80-A7C0-E3410428BED6@kirei.se> <557EBC88-0EB5-49EA-8ED1-A93EF0E5BEF5@kumari.net> <0FBA90D5-79E6-4826-9B41-2F04E01F83B0@bbn.com> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: DANE WG Subject: Re: [dane] #31: Multiple TLSA records in a response 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, 09 Sep 2011 15:17:50 -0000 On Fri, 9 Sep 2011, Jakob Schlyter wrote: >> While this change does meet the "combination" use case, it also makes the protocol more complex. It requires that domain administrators who don't care about combination still pick a group ID (even if it is 0). Is the use case actually worth the additional complexity? If so, I think that Richard's proposal is probably the least complex way to implement it. > > I do not believe that supporting "combination" is worth the additional complexity and I urge the WG to keep DANE as simple as possible. +1 We don't want DANE to become PKIX. Paul From hallam@gmail.com Fri Sep 9 10:36:22 2011 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 DEF7821F848A for ; Fri, 9 Sep 2011 10:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.46 X-Spam-Level: X-Spam-Status: No, score=-3.46 tagged_above=-999 required=5 tests=[AWL=0.138, 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 cXGeaGZi-lIC for ; Fri, 9 Sep 2011 10:36:22 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2042821F8486 for ; Fri, 9 Sep 2011 10:36:22 -0700 (PDT) Received: by yxt33 with SMTP id 33so394820yxt.31 for ; Fri, 09 Sep 2011 10:38:17 -0700 (PDT) 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=yFsmkJAxtpbeUQe99X+7vXzJ/ucXSBK5/bEfJ+VpqOc=; b=TDqtMqRk4sg63EmShG3KrfFM81KPoKhsVwhT8CxIAuHil9TBjMnVsSbd+xwEXAnp2i VlcpFzl9nsezR98FX0TNLzK//Qf7IJ/t/6Gp9IP9QUuL8xE8Y2duJiuSlpl6hDnkf3I+ IQMV4v9nucWFnLMvNpMQGvjoDujQSlRwRnMK4= MIME-Version: 1.0 Received: by 10.101.86.1 with SMTP id o1mr435535anl.29.1315589897357; Fri, 09 Sep 2011 10:38:17 -0700 (PDT) Received: by 10.101.114.9 with HTTP; Fri, 9 Sep 2011 10:38:17 -0700 (PDT) In-Reply-To: References: <4CBA8AED-F76D-46DF-A2A0-0B1608E3C8C2@kirei.se> <201109011639444268036@163.com> <20110902225200.GA6521@vacation.karoshi.com.> <20110903112732.GA14712@vacation.karoshi.com.> <812921FE-6CA6-4B80-A7C0-E3410428BED6@kirei.se> <557EBC88-0EB5-49EA-8ED1-A93EF0E5BEF5@kumari.net> <0FBA90D5-79E6-4826-9B41-2F04E01F83B0@bbn.com> Date: Fri, 9 Sep 2011 13:38:17 -0400 Message-ID: From: Phillip Hallam-Baker To: Jakob Schlyter Content-Type: multipart/alternative; boundary=001636eedf6580890b04ac85a42e Cc: Paul Hoffman , DANE WG Subject: Re: [dane] #31: Multiple TLSA records in a response 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, 09 Sep 2011 17:36:23 -0000 --001636eedf6580890b04ac85a42e Content-Type: text/plain; charset=ISO-8859-1 +1 This stuff is way too complex to put into DNS. On Fri, Sep 9, 2011 at 3:07 AM, Jakob Schlyter wrote: > On 8 sep 2011, at 17:54, Paul Hoffman wrote: > > > While this change does meet the "combination" use case, it also makes the > protocol more complex. It requires that domain administrators who don't care > about combination still pick a group ID (even if it is 0). Is the use case > actually worth the additional complexity? If so, I think that Richard's > proposal is probably the least complex way to implement it. > > I do not believe that supporting "combination" is worth the additional > complexity and I urge the WG to keep DANE as simple as possible. > > jakob > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > -- Website: http://hallambaker.com/ --001636eedf6580890b04ac85a42e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1

This stuff is way too complex to put into DNS.
<= div>


On Fri, Se= p 9, 2011 at 3:07 AM, Jakob Schlyter <jakob@kirei.se> wrote:
On 8 sep 2011, at 17:54, = Paul Hoffman wrote:

> While this change does meet the "combination" use case, it a= lso makes the protocol more complex. It requires that domain administrators= who don't care about combination still pick a group ID (even if it is = 0). Is the use case actually worth the additional complexity? If so, I thin= k that Richard's proposal is probably the least complex way to implemen= t it.

I do not believe that supporting "combination" is worth the= additional complexity and I urge the WG to keep DANE as simple as possible= .

=A0 =A0 =A0 =A0jakob

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



--
= Website: http://hallambaker.com/
--001636eedf6580890b04ac85a42e-- From ietf@augustcellars.com Fri Sep 9 12:47:54 2011 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 E218421F88B7 for ; Fri, 9 Sep 2011 12:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.446 X-Spam-Level: X-Spam-Status: No, score=-3.446 tagged_above=-999 required=5 tests=[AWL=0.153, 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 e9J8e5SuGrJI for ; Fri, 9 Sep 2011 12:47:54 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 7631E21F88B6 for ; Fri, 9 Sep 2011 12:47:53 -0700 (PDT) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id D96D82CA53; Fri, 9 Sep 2011 12:49:48 -0700 (PDT) From: "Jim Schaad" To: "'Jakob Schlyter'" , "'Paul Hoffman'" References: <4CBA8AED-F76D-46DF-A2A0-0B1608E3C8C2@kirei.se> <201109011639444268036@163.com> <20110902225200.GA6521@vacation.karoshi.com.> <20110903112732.GA14712@vacation.karoshi.com.> <812921FE-6CA6-4B80-A7C0-E3410428BED6@kirei.se> <557EBC88-0EB5-49EA-8ED1-A93EF0E5BEF5@kumari.net> <0FBA90D5-79E6-4826-9B41-2F04E01F83B0@bbn.com> In-Reply-To: Date: Fri, 9 Sep 2011 13:26:47 -0700 Message-ID: <02bb01cc6f2e$cd0000d0$67000270$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQG2hYvWyV+pwncRjlgeKwo75T/DIwEtl3lmAdNKPIgCGgJHUAH1ahkZAlKPzlAB9LlCqQHZWnchAl2QVxAC6jP7eQHveyF8lM4Qq2A= Cc: 'DANE WG' Subject: Re: [dane] #31: Multiple TLSA records in a response 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, 09 Sep 2011 19:47:55 -0000 While I believe that this may end up being a feature that needs to be supported. I believe that it would be better to have a new cert type that said how to do combinations rather than having it baked in at a low level. Jim > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of > Jakob Schlyter > Sent: Friday, September 09, 2011 12:07 AM > To: Paul Hoffman > Cc: DANE WG > Subject: Re: [dane] #31: Multiple TLSA records in a response > > On 8 sep 2011, at 17:54, Paul Hoffman wrote: > > > While this change does meet the "combination" use case, it also makes the > protocol more complex. It requires that domain administrators who don't > care about combination still pick a group ID (even if it is 0). Is the use case > actually worth the additional complexity? If so, I think that Richard's proposal > is probably the least complex way to implement it. > > I do not believe that supporting "combination" is worth the additional > complexity and I urge the WG to keep DANE as simple as possible. > > jakob > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From iesg-secretary@ietf.org Mon Sep 12 10:58:05 2011 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 E32F521F8C61; Mon, 12 Sep 2011 10:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.257 X-Spam-Level: X-Spam-Status: No, score=-102.257 tagged_above=-999 required=5 tests=[AWL=-0.258, BAYES_00=-2.599, J_CHICKENPOX_32=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 7lYLjwer5wSe; Mon, 12 Sep 2011 10:58:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1248721F8C54; Mon, 12 Sep 2011 10:58:05 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110912175805.17439.42287.idtracker@ietfa.amsl.com> Date: Mon, 12 Sep 2011 10:58:05 -0700 Cc: dane mailing list , dane chair , RFC Editor Subject: [dane] Document Action: 'Use Cases and Requirements for DNS-based Authentication of Named Entities (DANE)' to Informational RFC (draft-ietf-dane-use-cases-05.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, 12 Sep 2011 17:58:06 -0000 The IESG has approved the following document: - 'Use Cases and Requirements for DNS-based Authentication of Named Entities (DANE)' (draft-ietf-dane-use-cases-05.txt) as an Informational RFC This document is the product of the DNS-based Authentication of Named Entities Working Group. The IESG contact persons are Stephen Farrell and Sean Turner. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dane-use-cases/ Technical Summary Many current applications use the certificate-based authentication features in TLS to allow clients to verify that a connected server properly represents a desired domain name. Traditionally, this authentication has been based on PKIX trust hierarchies, rooted in well-known CAs, but additional information can be provided via the DNS itself. This document describes a set of use cases in which the DNS and DNSSEC could be used to make assertions that support the TLS authentication process. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? The DANE WG has been asked at the IETF80 meeting in Prague to write the use cases document before it continue the work on the DANE protocol draft. The draft has been discussed in the DANE WG mailing list and has a strong consensus in the WG for publication as an informational RFC with notable exception of controversy about allowing to use DNS responses not validated by DNSSEC in one of the use cases. The rough consensus is that this is still a valid use case and the issue will be addressed and resolved in the DANE protocol draft. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? This document was reviewed by various people and has been through WGLC successfully. Personnel Ond?ej Surý (ondrej.sury@nic.cz) is the Document Shepherd. Stephen Farrell (stephen.farrell@cs.tcd.ie) is the responsible AD. RFC Editor Note 1. Section 1, last para on p3. s/holder/operator/ OLD: " With the advent of DNSSEC [RFC4033], it is now possible for DNS name resolution to provide its information securely, in the sense that clients can verify that DNS information was provided by the domain holder and not tampered with in transit. " NEW: " With the advent of DNSSEC [RFC4033], it is now possible for DNS name resolution to provide its information securely, in the sense that clients can verify that DNS information was provided by the domain operator and not tampered with in transit. " 2. Add this text at the end of Section 2 NEW: " This document refers several times to the notion of a "domain holder". This term is understood to mean the entity that is authorized to control the contents of a particular zone. For example, the registrants of 2nd- or 3rd-level domains are the holders of those domains. The holder of a particular domain is not necessarily the entity that operates the zone. It should be noted that the presence of a valid DNSSEC signature in a DNS reply does not necessarily imply that the records protected by that signature were authorized by the domain holder. The distinction between the holder of a domain and the operator of the corresponding zone has several security implications, which are discussed in the individual use cases below. " 3. Section 2, 2nd para - add the word "often" OLD: " Multiple servers of this type may be co-located on a single physical host, using different ports, and each of these can use different certificates. " NEW: " Multiple servers of this type may be co-located on a single physical host, often using different ports, and each of these can use different certificates. " Some typos: 4. Section 1, 4th para: OLD: " Today, an attacker can successfully authenticate as a given application service domain if he can obtain a "mis-issued" ciertificate from one of the widely-used CAs " NEW: " Today, an attacker can successfully authenticate as a given application service domain if he can obtain a "mis-issued" certificate from one of the widely-used CAs " 5. Section 3.1, 2nd last para, s/case/cause/ OLD: " In this case, DNSSEC is not helpful, since an attacker could still case a denial of service by blocking all DNS responses for the target domain. " NEW: " In this case, DNSSEC is not helpful, since an attacker could still cause a denial of service by blocking all DNS responses for the target domain. " 6. Section 3.3, 3rd para, repeated word OLD: "As in Section Section 3.1 above" NEW: "As in Section 3.1 above" From warren@kumari.net Wed Sep 14 10:43:32 2011 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 9A64C21F8ABB for ; Wed, 14 Sep 2011 10:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.478 X-Spam-Level: X-Spam-Status: No, score=-102.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 307rlDexPl8w for ; Wed, 14 Sep 2011 10:43:31 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id A9CA521F8A7D for ; Wed, 14 Sep 2011 10:43:31 -0700 (PDT) Received: from dhcp-172-19-119-117.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id AD6361B416FC; Wed, 14 Sep 2011 13:45:36 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: <557EBC88-0EB5-49EA-8ED1-A93EF0E5BEF5@kumari.net> Date: Wed, 14 Sep 2011 13:45:34 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <91769BA5-8BE5-4EBB-BFE3-A7E931344235@kumari.net> References: <4CBA8AED-F76D-46DF-A2A0-0B1608E3C8C2@kirei.se> <201109011639444268036@163.com> <20110902225200.GA6521@vacation.karoshi.com.> <20110903112732.GA14712@vacation.karoshi.com.> <812921FE-6CA6-4B80-A7C0-E3410428BED6@kirei.se> <557EBC88-0EB5-49EA-8ED1-A93EF0E5BEF5@kumari.net> To: Warren Kumari X-Mailer: Apple Mail (2.1084) Cc: DANE WG Subject: Re: [dane] #31: Multiple TLSA records in a response 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, 14 Sep 2011 17:43:32 -0000 Alright, we are calling this.... We delayed the calling for a few days (5ish) to confirm that Martin's = interpretation was reasonable[0] ( = http://www.ietf.org/mail-archive/web/dane/current/msg03341.html ) - = having heard nothing to the contrary we are assuming it is. The consented text was: On the first match between one of the certificate association(s) and the server's end entity certificate in TLS is found, the TLS client = continues the TLS handshake, ignoring remaining certificate associations. If no match between the usable certificate association(s) and the server's end = entity certificate in TLS is found, the TLS client MUST abort the handshake = with an "access_denied" error. We are also calling Richard's suggestion on adding a "group id" (gid) = field to the TLSA record format to allow for combinations ( = http://www.ietf.org/mail-archive/web/dane/current/msg03345.html ). While this does provide additional flexibility, the consensus is that it = adds too much additional complexity and so is not being included at the = moment[1]. I *may* open (and then close) an issue in the tracker to track this... W Footnotes with no hats: [0]: I think it is, but wanted to give folk (including Dr Kent) time to = respond. [1]: I think that this is an interesting idea, and if (heaven forbid) we = end up with a DANEbis or V2 we may want to consider it then -- or Jim's = suggestion ( = http://www.ietf.org/mail-archive/web/dane/current/msg03352.html ) or = something). On Sep 7, 2011, at 6:51 PM, Warren Kumari wrote: > Alrighty=85 >=20 > As part of the new, faster, leaner, meaner approach to working issues = I'd like to call consensus on this on Friday 16:00UTC. >=20 > Is the (current) below text acceptable (especially after "usable" is = clarified in the next version) to the WG? >=20 > W > On Sep 3, 2011, at 7:48 AM, Jakob Schlyter wrote: >=20 >> On 3 sep 2011, at 13:27, bmanning@vacation.karoshi.com wrote: >>=20 >>> ok,,, first match. is that in the spec? >>=20 >> Yes. >>=20 >> "If a match between one of the certificate association(s) and the >> server's end entity certificate in TLS is found, the TLS client >> continues the TLS handshake. If no match between the usable >> certificate association(s) and the server's end entity certificate = in >> TLS is found, the TLS client MUST abort the handshake with an >> "access_denied" error." >>=20 >> (the definition of "usable", what TLSA records to ignore etc. is = defined as well, and is even more clarified in the next version) >>=20 >> jakob >>=20 >>=20 >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >>=20 >=20 From trac+dane@trac.tools.ietf.org Wed Sep 14 13:59:11 2011 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 8E8A321F8C4D for ; Wed, 14 Sep 2011 13:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 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 q8bx1dpz7Fz9 for ; Wed, 14 Sep 2011 13:58:56 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 194D221F8C2B for ; Wed, 14 Sep 2011 13:58:55 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1R3wZi-0001lN-3V; Wed, 14 Sep 2011 17:00:54 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: draft-ietf-dane-protocol@tools.ietf.org, hallam@gmail.com, jakob@kirei.se, paul.hoffman@vpnc.org, warren@kumari.net, yzw_iplab@163.com X-Trac-Project: dane Date: Wed, 14 Sep 2011 21:00:54 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/31#comment:9 Message-ID: <069.2a08a5ab2e565decc7eee447651f46a5@trac.tools.ietf.org> References: <060.d55c279a583dd38213fda7e1f7c9e46d@trac.tools.ietf.org> X-Trac-Ticket-ID: 31 In-Reply-To: <060.d55c279a583dd38213fda7e1f7c9e46d@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dane-protocol@tools.ietf.org, hallam@gmail.com, jakob@kirei.se, paul.hoffman@vpnc.org, warren@kumari.net, yzw_iplab@163.com, 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: <20110914205856.194D221F8C2B@ietfa.amsl.com> Resent-Date: Wed, 14 Sep 2011 13:58:55 -0700 (PDT) Resent-From: trac+dane@trac.tools.ietf.org Cc: dane@ietf.org Subject: Re: [dane] #31: Multiple TLSA records in a response 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: Wed, 14 Sep 2011 20:59:11 -0000 #31: Multiple TLSA records in a response Changes (by warren@…): * status: new => closed * resolution: => fixed Comment: Summary: Consensus for this text (edits from Bill Manning): On the first match between one of the certificate association(s) and the server's end entity certificate in TLS is found, the TLS client continues the TLS handshake, ignoring remaining certificate associations. If no match between the usable certificate association(s) and the server's end entity certificate in TLS is found, the TLS client MUST abort the handshake with an "access_denied" error. There was discussion on the MUST, input from Martin Rex in http://www.ietf.org/mail-archive/web/dane/current/msg03341.html Longer text: http://www.ietf.org/mail-archive/web/dane/current/msg03354.html -- -----------------------------------+---------------------------------------- Reporter: paul.hoffman@… | Owner: draft-ietf-dane-protocol@… Type: defect | Status: closed Priority: major | Milestone: Component: protocol | Version: Severity: - | Resolution: fixed Keywords: | -----------------------------------+---------------------------------------- Ticket URL: dane From trac+dane@trac.tools.ietf.org Wed Sep 14 14:09:25 2011 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 44EF321F8D31 for ; Wed, 14 Sep 2011 14:09:25 -0700 (PDT) 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 G6w-c3N3kcyh for ; Wed, 14 Sep 2011 14:09:24 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id B954021F8D2E for ; Wed, 14 Sep 2011 14:09:20 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1R3wju-0002o7-2D; Wed, 14 Sep 2011 17:11:26 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: draft-ietf-dane-protocol@tools.ietf.org, warren@kumari.net X-Trac-Project: dane Date: Wed, 14 Sep 2011 21:11:26 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/dane/trac/ticket/32 Message-ID: <056.419ff55228378ebc0a4553cb4374780d@trac.tools.ietf.org> X-Trac-Ticket-ID: 32 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: <20110914210920.B954021F8D2E@ietfa.amsl.com> Resent-Date: Wed, 14 Sep 2011 14:09:20 -0700 (PDT) Resent-From: trac+dane@trac.tools.ietf.org Cc: dane@ietf.org Subject: [dane] #32: Grouping / combinations of certificates 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: Wed, 14 Sep 2011 21:09:26 -0000 #32: Grouping / combinations of certificates [ Tracking ticket ] It was proposed to add a "group id" (gid) field to the TLSA record format to "combine TLSA associations in a kind of disjunctive normal form" -- http://www.ietf.org/mail-archive/web/dane/current/msg03342.html It was deemed that this added too much additional complexity to the protocol to be considered at the moment. but I wanted to record this suggestion for future work. Also suggested was (Jim Schaad - http://www.ietf.org/mail- archive/web/dane/current/msg03352.html ): --- While I believe that this may end up being a feature that needs to be supported. I believe that it would be better to have a new cert type that said how to do combinations rather than having it baked in at a low level. --- -- -------------------------------+-------------------------------------------- Reporter: warren@… | Owner: draft-ietf-dane-protocol@… Type: enhancement | Status: new Priority: minor | Milestone: Component: protocol | Version: Severity: - | Keywords: -------------------------------+-------------------------------------------- Ticket URL: dane From trac+dane@trac.tools.ietf.org Wed Sep 14 14:09:42 2011 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 771EF21F8D3C for ; Wed, 14 Sep 2011 14:09:42 -0700 (PDT) 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 JYGViQadEGLy for ; Wed, 14 Sep 2011 14:09:41 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id C977221F8D2E for ; Wed, 14 Sep 2011 14:09:41 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1R3wkI-0002oO-RX; Wed, 14 Sep 2011 17:11:50 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: draft-ietf-dane-protocol@tools.ietf.org, warren@kumari.net X-Trac-Project: dane Date: Wed, 14 Sep 2011 21:11:50 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/dane/trac/ticket/32#comment:1 Message-ID: <065.38000d196f6de58315582ba474911ceb@trac.tools.ietf.org> References: <056.419ff55228378ebc0a4553cb4374780d@trac.tools.ietf.org> X-Trac-Ticket-ID: 32 In-Reply-To: <056.419ff55228378ebc0a4553cb4374780d@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: <20110914210941.C977221F8D2E@ietfa.amsl.com> Resent-Date: Wed, 14 Sep 2011 14:09:41 -0700 (PDT) Resent-From: trac+dane@trac.tools.ietf.org Cc: dane@ietf.org Subject: Re: [dane] #32: Grouping / combinations of certificates 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: Wed, 14 Sep 2011 21:09:43 -0000 #32: Grouping / combinations of certificates Changes (by warren@…): * status: new => closed * resolution: => fixed Comment: Tracking ticket, closing immediately! -- -------------------------------+-------------------------------------------- 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 trac+dane@trac.tools.ietf.org Wed Sep 14 14:29:46 2011 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 4C7F421F8D55 for ; Wed, 14 Sep 2011 14:29:46 -0700 (PDT) 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 WiIf7YC-r-1k for ; Wed, 14 Sep 2011 14:29:45 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id B4EF521F8D56 for ; Wed, 14 Sep 2011 14:29:45 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1R3x3g-0003fr-Ji; Wed, 14 Sep 2011 17:31:52 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: draft-ietf-dane-protocol@tools.ietf.org, paul.hoffman@vpnc.org, warren@kumari.net X-Trac-Project: dane Date: Wed, 14 Sep 2011 21:31:52 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/dane/trac/ticket/30#comment:2 Message-ID: <069.a93204a75b3d22ecd5e09096e708d42a@trac.tools.ietf.org> References: <060.d9d7d9eb5ef585fc2a7f1726d8ad15bf@trac.tools.ietf.org> X-Trac-Ticket-ID: 30 In-Reply-To: <060.d9d7d9eb5ef585fc2a7f1726d8ad15bf@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dane-protocol@tools.ietf.org, paul.hoffman@vpnc.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: <20110914212945.B4EF521F8D56@ietfa.amsl.com> Resent-Date: Wed, 14 Sep 2011 14:29:45 -0700 (PDT) Resent-From: trac+dane@trac.tools.ietf.org Cc: dane@ietf.org Subject: Re: [dane] #30: Better coverage for certificate association wording 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: Wed, 14 Sep 2011 21:29:46 -0000 #30: Better coverage for certificate association wording Changes (by warren@…): * status: new => closed * resolution: => fixed Comment: This was addressed in the Issue #31 ticket (http://trac.tools.ietf.org/wg/dane/trac/ticket/31) -- -----------------------------------+---------------------------------------- Reporter: paul.hoffman@… | Owner: draft-ietf-dane-protocol@… Type: defect | Status: closed Priority: major | Milestone: Component: protocol | Version: Severity: - | Resolution: fixed Keywords: | -----------------------------------+---------------------------------------- Ticket URL: dane From warren@kumari.net Wed Sep 14 14:36:35 2011 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 AA71521F8B2C for ; Wed, 14 Sep 2011 14:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.482 X-Spam-Level: X-Spam-Status: No, score=-102.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 bnivWtgAhSU6 for ; Wed, 14 Sep 2011 14:36:35 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 36CD021F8AFC for ; Wed, 14 Sep 2011 14:36:35 -0700 (PDT) Received: from dhcp-172-19-119-117.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id CEAE71B416FC; Wed, 14 Sep 2011 17:38:44 -0400 (EDT) From: Warren Kumari Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Sep 2011 17:38:42 -0400 Message-Id: <1E08D85E-3E17-4E30-BF21-6C37E8CE3052@kumari.net> To: DANE WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [dane] Opening issues #25, #26, #27 as a group. 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, 14 Sep 2011 21:36:35 -0000 Hi all. These are all related issues: #25: http://trac.tools.ietf.org/wg/dane/trac/ticket/25 - Independent = additive and restrictive assertions #26: http://trac.tools.ietf.org/wg/dane/trac/ticket/26 - Restrictive = assertions a conformance requirement, additive ones not? #27: http://trac.tools.ietf.org/wg/dane/trac/ticket/27 - Conjunction of = restrictions It would be great if we could discuss them as a group, and come to some = sort of consensus by next Friday (September 23rd). If commenting on a particular issue number, it would be awesome if you = could clearly state which :-P W= From zack.weinberg@gmail.com Wed Sep 14 14:43:47 2011 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 C11F721F8CC9 for ; Wed, 14 Sep 2011 14:43:47 -0700 (PDT) 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 mWfDQgqSdPgY for ; Wed, 14 Sep 2011 14:43:47 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC1221F8CC4 for ; Wed, 14 Sep 2011 14:43:47 -0700 (PDT) Received: by yxt33 with SMTP id 33so2017233yxt.31 for ; Wed, 14 Sep 2011 14:45:57 -0700 (PDT) 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:cc:content-type; bh=DyfDQtqaIrL3Yxr+bgWn5RcSFGSLNl8cBPZVLXa2qZc=; b=gnkwc2NRzz40Gdf9XPQnd2jmz8XOu1e0EW/1hob2xH91spK/pMDNRb+d+b6cpAqAbZ 0mlbKLGB8s82IdUS8JnThmh/b1sM30b43sjGshCdbYMZSf6RsRsclcGgVAz0R2qh6v34 k4wTgMso2CoxmZzfu+HdFpaLcUMfVMQc1x/n8= MIME-Version: 1.0 Received: by 10.68.16.231 with SMTP id j7mr567301pbd.472.1316036756560; Wed, 14 Sep 2011 14:45:56 -0700 (PDT) Sender: zack.weinberg@gmail.com Received: by 10.68.50.40 with HTTP; Wed, 14 Sep 2011 14:45:56 -0700 (PDT) In-Reply-To: <1E08D85E-3E17-4E30-BF21-6C37E8CE3052@kumari.net> References: <1E08D85E-3E17-4E30-BF21-6C37E8CE3052@kumari.net> Date: Wed, 14 Sep 2011 14:45:56 -0700 X-Google-Sender-Auth: TmxOthpk66oV39kB9emVOtvJSG4 Message-ID: From: Zack Weinberg To: Warren Kumari Content-Type: text/plain; charset=UTF-8 Cc: DANE WG Subject: Re: [dane] Opening issues #25, #26, #27 as a group. 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, 14 Sep 2011 21:43:47 -0000 On Wed, Sep 14, 2011 at 2:38 PM, Warren Kumari wrote: > These are all related issues: > #25: http://trac.tools.ietf.org/wg/dane/trac/ticket/25 - Independent additive and restrictive assertions > #26: http://trac.tools.ietf.org/wg/dane/trac/ticket/26 - Restrictive assertions a conformance requirement, additive ones not? > #27: http://trac.tools.ietf.org/wg/dane/trac/ticket/27 - Conjunction of restrictions As a general observation, I think leaving anything to "client policy" is a recipe for interoperability disaster. There should be no wiggle room for two different clients to behave differently in response to a given set of TLSA records plus TLS handshake. zw From hallam@gmail.com Wed Sep 14 14:49:51 2011 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 4106021F8D5C for ; Wed, 14 Sep 2011 14:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.435 X-Spam-Level: X-Spam-Status: No, score=-3.435 tagged_above=-999 required=5 tests=[AWL=0.163, 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 lTRKwpe1hemy for ; Wed, 14 Sep 2011 14:49:50 -0700 (PDT) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by ietfa.amsl.com (Postfix) with ESMTP id 488FA21F8D5B for ; Wed, 14 Sep 2011 14:49:50 -0700 (PDT) Received: by gwj18 with SMTP id 18so2691982gwj.27 for ; Wed, 14 Sep 2011 14:52:00 -0700 (PDT) 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=NOD23cMCNr3KblN9MWTySDSEfjkdUdmyEA1qLDG0oWI=; b=pBe/bnR1uKXKC0/gooM90RyBJD7NDJQo6AAprqFf2EQYhQmLUR3FBRdqg9642pnjzy mGMuEpGsiaXLA4YzQ9U+ibnQzSAd8IgusVttqEsRorHE71JxiAKq/0qwpKVc6VokeuMM oP1hcGeZFY+oXRHpC1EO8BkklqRQXGMqPE0Mo= MIME-Version: 1.0 Received: by 10.101.63.5 with SMTP id q5mr314370ank.140.1316037120010; Wed, 14 Sep 2011 14:52:00 -0700 (PDT) Received: by 10.100.120.20 with HTTP; Wed, 14 Sep 2011 14:51:59 -0700 (PDT) In-Reply-To: <1E08D85E-3E17-4E30-BF21-6C37E8CE3052@kumari.net> References: <1E08D85E-3E17-4E30-BF21-6C37E8CE3052@kumari.net> Date: Wed, 14 Sep 2011 17:51:59 -0400 Message-ID: From: Phillip Hallam-Baker To: Warren Kumari Content-Type: multipart/alternative; boundary=001636eee26d0cabd404acedc5a0 Cc: DANE WG Subject: Re: [dane] Opening issues #25, #26, #27 as a group. 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, 14 Sep 2011 21:49:51 -0000 --001636eee26d0cabd404acedc5a0 Content-Type: text/plain; charset=ISO-8859-1 I very strongly believe that the additive and restrictive aspects need to be separated. Separating the issues is necessary because the distribution concerns are not the same for additive and restrictive. DNSSEC access is not 100% and we can expect that it will be 0% in Internet connections sanctioned by the government of Iran. Thus a bypass mechanism is required and additive and restrictive trust require different approaches. If the record is only providing additive trust then it is only essential to get the record through to a client that is going to rely on the additive data. This can be achieved if necessary by stuffing the DNS data into Certs or OCSP tokens distributed by the cert subject (a la Langley/Kaminsky). If the record is providing restrictive trust the Cert or OCSP stuffing approach fails because it can be suppressed. Nor does DNSSEC provide any real leverage for an end client unless it has a means to bypass a MITM attack and gain a connection to DNSSEC ground truth. The approach here is likely to require some clients that use access to DNSSEC ground truth to alert response parties to the fact of an attack coupled with some out of band mechanism for pushing out policy in the case of an attack. These are two separate problems and should be addressed independently. On Wed, Sep 14, 2011 at 5:38 PM, Warren Kumari wrote: > Hi all. > > These are all related issues: > #25: http://trac.tools.ietf.org/wg/dane/trac/ticket/25 - Independent > additive and restrictive assertions > #26: http://trac.tools.ietf.org/wg/dane/trac/ticket/26 - Restrictive > assertions a conformance requirement, additive ones not? > #27: http://trac.tools.ietf.org/wg/dane/trac/ticket/27 - Conjunction of > restrictions > > > It would be great if we could discuss them as a group, and come to some > sort of consensus by next Friday (September 23rd). > If commenting on a particular issue number, it would be awesome if you > could clearly state which :-P > > W > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > -- Website: http://hallambaker.com/ --001636eee26d0cabd404acedc5a0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I very strongly believe that the additive and restrictive aspects need to b= e separated.

Separating the issues is necessary because = the distribution concerns are not the same for additive and restrictive. DN= SSEC access is not 100% and we can expect that it will be 0% in Internet co= nnections sanctioned by the government of Iran. Thus a bypass mechanism is = required and additive and restrictive trust require different approaches.


If the record is only providing additive= trust then it is only essential to get the record through to a client that= is going to rely on the additive data. This can be achieved if necessary b= y stuffing the DNS data into Certs or OCSP tokens distributed by the cert s= ubject (a la Langley/Kaminsky).

If the record is providing restrictive trust the Cert o= r OCSP stuffing approach fails because it can be suppressed. Nor does DNSSE= C provide any real leverage for an end client unless it has a means to bypa= ss a MITM attack and gain a connection to DNSSEC ground truth. The approach= here is likely to require some clients that use access to DNSSEC ground tr= uth to alert response parties to the fact of an attack coupled with some ou= t of band mechanism for pushing out policy in the case of an attack.


These are two separate problems and shou= ld be addressed independently.


On Wed, Sep 14, 2011 at 5:38 PM, Warren Kumari <warren@kumari.net>= wrote:
Hi all.

These are all related issues:
#25: http://trac.tools.ietf.org/wg/dane/trac/ticket/25 - Indepen= dent additive and restrictive assertions
#26: http://trac.tools.ietf.org/wg/dane/trac/ticket/26 - Restric= tive assertions a conformance requirement, additive ones not?
#27: http://trac.tools.ietf.org/wg/dane/trac/ticket/27 - Conjunc= tion of restrictions


It would be great if we could discuss them as a group, and come to some sor= t of consensus by next Friday (September 23rd).
If commenting on a particular issue number, it would be awesome if you coul= d clearly state which :-P

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



--
Website: http://hallambaker.com/

--001636eee26d0cabd404acedc5a0-- From warren@kumari.net Wed Sep 14 14:50:32 2011 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 ADB8021F8D53 for ; Wed, 14 Sep 2011 14:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=0.113, 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 wTVD2U6YR+vV for ; Wed, 14 Sep 2011 14:50:31 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id A9FB721F8D0A for ; Wed, 14 Sep 2011 14:50:28 -0700 (PDT) Received: from dhcp-172-19-119-117.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 4FC731B416FC; Wed, 14 Sep 2011 17:52:38 -0400 (EDT) From: Warren Kumari Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Sep 2011 17:52:36 -0400 Message-Id: <05701F4C-3419-40DF-A2E7-8BFF8A3434CA@kumari.net> To: DANE WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [dane] Reopening issue #22 for discussion.... 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, 14 Sep 2011 21:50:32 -0000 Hi all, A while back I (prematurely) closed issue #22 ( = http://trac.tools.ietf.org/wg/dane/trac/ticket/22 -- Provide the = security of the strongest digest supported by both sides ). I had thought that we had had discussions on-list to the effect of: While it may be fun, we cannot / should not specify what the strongest = digest is, and so we cannot really dictate how sides choose the = "strongest", and so client implementations will sort / choose the digest = that they believe is strongest. (I also thought I remembered discussions regarding if we needed to = specify that client implementations should do this, but it was decided = that that should just be an implementation detail). I have not been able to find these discussions, and so it may just just = been: A: in person discussions or (more worrying) B: a weird dream... Anyway, let's discuss this and get it closed... W= From bmanning@karoshi.com Thu Sep 15 06:17:28 2011 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 2201521F8558 for ; Thu, 15 Sep 2011 06:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.179 X-Spam-Level: X-Spam-Status: No, score=-6.179 tagged_above=-999 required=5 tests=[AWL=0.420, 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 AnemW46ky0e5 for ; Thu, 15 Sep 2011 06:17:27 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id 977C121F8548 for ; Thu, 15 Sep 2011 06:17:27 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id p8FDJcWj013595; Thu, 15 Sep 2011 13:19:38 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id p8FDJbom013594; Thu, 15 Sep 2011 13:19:37 GMT Date: Thu, 15 Sep 2011 13:19:37 +0000 From: bmanning@vacation.karoshi.com To: Warren Kumari Message-ID: <20110915131937.GC13546@vacation.karoshi.com.> References: <05701F4C-3419-40DF-A2E7-8BFF8A3434CA@kumari.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <05701F4C-3419-40DF-A2E7-8BFF8A3434CA@kumari.net> User-Agent: Mutt/1.4.1i Cc: DANE WG Subject: Re: [dane] Reopening issue #22 for discussion.... 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, 15 Sep 2011 13:17:28 -0000 On Wed, Sep 14, 2011 at 05:52:36PM -0400, Warren Kumari wrote: > Hi all, > > A while back I (prematurely) closed issue #22 ( http://trac.tools.ietf.org/wg/dane/trac/ticket/22 -- Provide the security of the strongest digest supported by both sides ). > > I had thought that we had had discussions on-list to the effect of: > While it may be fun, we cannot / should not specify what the strongest digest is, and so we cannot really dictate how sides choose the "strongest", and so client implementations will sort / choose the digest that they believe is strongest. > (I also thought I remembered discussions regarding if we needed to specify that client implementations should do this, but it was decided that that should just be an implementation detail). > > I have not been able to find these discussions, and so it may just just been: > A: in person discussions or (more worrying) > B: a weird dream... > > Anyway, let's discuss this and get it closed... > > W The only way to ensure client/server agreement is to only provide a single datum for consideration. When/If there is a choice, there is no perfect assurance that there will be agreement between server and client as to the respective merits of the data under consideration. Server may assert datum(A) is perfered/strongest/blond, while client polcy will dictate that ginger is to always be prefered to blonds, other attributes be hanged. The server can't strong arm clients. Period. (think deployed base and then making a change... going to upgrade everything in the field? Good Luck w/ that) /bill From paul.hoffman@vpnc.org Thu Sep 15 08:32:17 2011 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 40DDF21F88A0 for ; Thu, 15 Sep 2011 08:32:17 -0700 (PDT) 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 TgQJQHWXpwLk for ; Thu, 15 Sep 2011 08:32:16 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id C86DF21F857D for ; Thu, 15 Sep 2011 08:32:16 -0700 (PDT) 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 p8FFYQiH053684 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 15 Sep 2011 08:34:28 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1244.3) From: Paul Hoffman In-Reply-To: <20110915131937.GC13546@vacation.karoshi.com.> Date: Thu, 15 Sep 2011 08:34:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1FC517BE-41AD-449F-8864-3770A15D760E@vpnc.org> References: <05701F4C-3419-40DF-A2E7-8BFF8A3434CA@kumari.net> <20110915131937.GC13546@vacation.karoshi.com.> To: DANE WG X-Mailer: Apple Mail (2.1244.3) Subject: Re: [dane] Reopening issue #22 for discussion.... 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, 15 Sep 2011 15:32:17 -0000 I would prefer that we do not adopt the proposed design change. On Sep 15, 2011, at 6:19 AM, bmanning@vacation.karoshi.com wrote: > The server can't strong arm clients. Period. (think deployed = base and then making a > change... going to upgrade everything in the field? Good Luck = w/ that) +1. Further, I disagree with the part of the problem statement that says = "clients that support SHA-512 will still accept any certificate that = matches the SHA-256 digest". Clients that care about different strengths = can be configured not to do this. --Paul Hoffman From warren@kumari.net Thu Sep 15 08:34:32 2011 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 5ABC821F8B1E for ; Thu, 15 Sep 2011 08:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.493 X-Spam-Level: X-Spam-Status: No, score=-102.493 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 e32S6snhX7Es for ; Thu, 15 Sep 2011 08:34:31 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id D0D5C21F8B1B for ; Thu, 15 Sep 2011 08:34:31 -0700 (PDT) Received: from dhcp-172-19-119-117.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 382701B416DA; Thu, 15 Sep 2011 11:36:43 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <20110915131937.GC13546@vacation.karoshi.com.> Date: Thu, 15 Sep 2011 11:36:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1FD795CF-8698-4DD5-B4B7-29057A8A919F@kumari.net> References: <05701F4C-3419-40DF-A2E7-8BFF8A3434CA@kumari.net> <20110915131937.GC13546@vacation.karoshi.com.> To: bmanning@vacation.karoshi.com X-Mailer: Apple Mail (2.1084) Cc: DANE WG Subject: Re: [dane] Reopening issue #22 for discussion.... 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, 15 Sep 2011 15:34:32 -0000 On Sep 15, 2011, at 9:19 AM, bmanning@vacation.karoshi.com wrote: > On Wed, Sep 14, 2011 at 05:52:36PM -0400, Warren Kumari wrote: >> Hi all, >>=20 >> A while back I (prematurely) closed issue #22 ( = http://trac.tools.ietf.org/wg/dane/trac/ticket/22 -- Provide the = security of the strongest digest supported by both sides ). >>=20 >> I had thought that we had had discussions on-list to the effect of: >> While it may be fun, we cannot / should not specify what the = strongest digest is, and so we cannot really dictate how sides choose = the "strongest", and so client implementations will sort / choose the = digest that they believe is strongest. >> (I also thought I remembered discussions regarding if we needed to = specify that client implementations should do this, but it was decided = that that should just be an implementation detail). >>=20 >> I have not been able to find these discussions, and so it may just = just been: >> A: in person discussions or (more worrying) >> B: a weird dream... >>=20 >> Anyway, let's discuss this and get it closed... >>=20 >> W >=20 > The only way to ensure client/server agreement is to only = provide a single datum > for consideration. When/If there is a choice, there is no = perfect assurance that > there will be agreement between server and client as to the = respective merits of=20 > the data under consideration. Server may assert datum(A) is = perfered/strongest/blond, > while client polcy will dictate that ginger is to always be = prefered to blonds, other > attributes be hanged. >=20 > The server can't strong arm clients. Exactly -- the best the server can do is announce all of the TLSA = records (potentially with different algorithms) and the client can = select what it thinks is best.... I think we are in violent agreement, but canna tell! W > Period. (think deployed base and then making a > change... going to upgrade everything in the field? Good Luck = w/ that) > /bill >=20 From ietf@augustcellars.com Thu Sep 15 10:47:46 2011 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 A386E21F886D for ; Thu, 15 Sep 2011 10:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.389 X-Spam-Level: X-Spam-Status: No, score=-3.389 tagged_above=-999 required=5 tests=[AWL=0.210, 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 VQdP4e0XI+RN for ; Thu, 15 Sep 2011 10:47:44 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 4F7C021F86A4 for ; Thu, 15 Sep 2011 10:47:44 -0700 (PDT) Received: from TITUS (176.120.168.69.static.onlinenw.com [69.168.120.176]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 4C46C2CA43; Thu, 15 Sep 2011 10:49:56 -0700 (PDT) From: "Jim Schaad" To: "'Paul Hoffman'" , "'DANE WG'" References: <05701F4C-3419-40DF-A2E7-8BFF8A3434CA@kumari.net> <20110915131937.GC13546@vacation.karoshi.com.> <1FC517BE-41AD-449F-8864-3770A15D760E@vpnc.org> In-Reply-To: <1FC517BE-41AD-449F-8864-3770A15D760E@vpnc.org> Date: Thu, 15 Sep 2011 11:27:02 -0700 Message-ID: <005201cc73d5$10689760$3139c620$@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: AQGJSWP4Hv7RtevHQWG224TtxspjOwImHTlMArsLg92Vrg2qQA== Content-Language: en-us Subject: Re: [dane] Reopening issue #22 for discussion.... 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, 15 Sep 2011 17:47:46 -0000 We do however need to say what a client is to do in the event that a record exists, but the client does not believe that it is a sufficiently strong matching. I.e. if my client says that SHA-1 will not do for anything, what happens if only a SHA-1 record exists. Is this considered to be an unusable statement or a failed statement. Jim > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of > Paul Hoffman > Sent: Thursday, September 15, 2011 8:34 AM > To: DANE WG > Subject: Re: [dane] Reopening issue #22 for discussion.... > > I would prefer that we do not adopt the proposed design change. > > On Sep 15, 2011, at 6:19 AM, bmanning@vacation.karoshi.com wrote: > > > The server can't strong arm clients. Period. (think deployed base and > then making a > > change... going to upgrade everything in the field? Good Luck w/ > that) > > > +1. Further, I disagree with the part of the problem statement that says > "clients that support SHA-512 will still accept any certificate that matches the > SHA-256 digest". Clients that care about different strengths can be > configured not to do this. > > --Paul Hoffman > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From paul.hoffman@vpnc.org Thu Sep 15 11:00:34 2011 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 03E0C21F8BB7 for ; Thu, 15 Sep 2011 11:00:34 -0700 (PDT) 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 Q0o+QZcHdk9z for ; Thu, 15 Sep 2011 11:00:33 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 4D2C921F8BB8 for ; Thu, 15 Sep 2011 11:00:33 -0700 (PDT) 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 p8FI2glw023276 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 15 Sep 2011 11:02:43 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <005201cc73d5$10689760$3139c620$@augustcellars.com> Date: Thu, 15 Sep 2011 11:02:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <73971DE7-54A2-4C8B-8CBE-FD90596C819A@vpnc.org> References: <05701F4C-3419-40DF-A2E7-8BFF8A3434CA@kumari.net> <20110915131937.GC13546@vacation.karoshi.com.> <1FC517BE-41AD-449F-8864-3770A15D760E@vpnc.org> <005201cc73d5$10689760$3139c620$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1244.3) Cc: 'DANE WG' Subject: Re: [dane] Reopening issue #22 for discussion.... 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, 15 Sep 2011 18:00:34 -0000 On Sep 15, 2011, at 11:27 AM, Jim Schaad wrote: > We do however need to say what a client is to do in the event that a = record > exists, but the client does not believe that it is a sufficiently = strong > matching. I.e. if my client says that SHA-1 will not do for anything, = what > happens if only a SHA-1 record exists. Is this considered to be an = unusable > statement or a failed statement. What is a "failed statement"? We don't have that in the current = document. Saying "you MAY consider this certificate unusable" doesn't seem at all = useful to me, but if others want it, we can add it. --Paul Hoffman From mrex@sap.com Thu Sep 15 12:45:17 2011 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 D231D21F8BB8 for ; Thu, 15 Sep 2011 12:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.028 X-Spam-Level: X-Spam-Status: No, score=-10.028 tagged_above=-999 required=5 tests=[AWL=0.221, 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 sBK6lPROBSXj for ; Thu, 15 Sep 2011 12:45:17 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA9E21F8BB5 for ; Thu, 15 Sep 2011 12:45:16 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p8FJlRSb006215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Sep 2011 21:47:27 +0200 (MEST) From: Martin Rex Message-Id: <201109151947.p8FJlQCH008049@fs4113.wdf.sap.corp> To: warren@kumari.net (Warren Kumari) Date: Thu, 15 Sep 2011 21:47:26 +0200 (MEST) In-Reply-To: <91769BA5-8BE5-4EBB-BFE3-A7E931344235@kumari.net> from "Warren Kumari" at Sep 14, 11 01:45:34 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] #31: Multiple TLSA records in a response 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, 15 Sep 2011 19:45:17 -0000 Warren Kumari wrote: > > The consented text was: > > On the first match between one of the certificate association(s) and the > server's end entity certificate in TLS is found, the TLS client continues the > TLS handshake, ignoring remaining certificate associations. If no match > between the usable certificate association(s) and the server's end entity > certificate in TLS is found, the TLS client MUST abort the handshake with an > "access_denied" error. I'm slighlty confused by this specific error message text "access_denied". Traditionally, an "access_denied" error is not something that one inflicts on oneself, but used for situations with two distinct entities, where the other denies access, and the entity that receives that error has no means to ignore or override this. To me, the situation looks like a "server certificate DANE validation failed" error. And DANE-aware implementations MUST fail (by default) when encountering this error. Implementations MAY offer a means to continue in spite of this error, but if they do, they MUST ensure with reasonable confidence that the consumer of the technology is fully aware of the risks involved with continuing in spite of this error. btw. would it be OK to be more elaborate about DNS zones that use DNSSEC but do not contain any TLS records for a server host name. currently it reads: If the application receives zero usable certificate associations, it processes TLS in the normal fashion. How about something along these lines: If the application receives zero usable certificate associations (i.e. if zero TLSA records are returned for the server host name), then no additional checks based on this specification are performed on the server certificate (chain), and the normal TLS server certificate validation and server endpoint identification applies. I'm slightly confused by the term "application" in the above sentence, because it really refers to an implementation of this specification itself rather than some application calling this implementation. -Martin From paul.hoffman@vpnc.org Thu Sep 15 13:04:54 2011 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 3514C11E8087 for ; Thu, 15 Sep 2011 13:04:54 -0700 (PDT) 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 w0pPhtYlBqhh for ; Thu, 15 Sep 2011 13:04:53 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7E67411E807F for ; Thu, 15 Sep 2011 13:04:53 -0700 (PDT) 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 p8FK75KS081911 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 15 Sep 2011 13:07:05 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <201109151947.p8FJlQCH008049@fs4113.wdf.sap.corp> Date: Thu, 15 Sep 2011 13:07:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8B4D8904-2FC4-4808-A99E-FCCA07972F61@vpnc.org> References: <201109151947.p8FJlQCH008049@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1244.3) Cc: DANE WG Subject: Re: [dane] #31: Multiple TLSA records in a response 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, 15 Sep 2011 20:04:54 -0000 On Sep 15, 2011, at 12:47 PM, Martin Rex wrote: > Warren Kumari wrote: >>=20 >> The consented text was: >>=20 >> On the first match between one of the certificate association(s) and = the >> server's end entity certificate in TLS is found, the TLS client = continues the >> TLS handshake, ignoring remaining certificate associations. If no = match >> between the usable certificate association(s) and the server's end = entity >> certificate in TLS is found, the TLS client MUST abort the handshake = with an >> "access_denied" error. >=20 > I'm slighlty confused by this specific error message text = "access_denied". > Traditionally, an "access_denied" error is not something that one > inflicts on oneself, but used for situations with two distinct = entities, > where the other denies access, and the entity that receives that error > has no means to ignore or override this. To me, that is what is happening when the domain owner says "here is the = certifying information" and it is unusable. The definition in the TLS = spec for access_denied is: A valid certificate was received, but when access control was applied, the sender decided not to proceed with negotiation. This message is always fatal. If you have a different fatal TLS error that you think would be better, = that would be well worth discussing. In the end, however, the fact that = the TLS error is fatal is all that is relevant. > To me, the situation looks like a "server certificate DANE validation = failed" > error. And DANE-aware implementations MUST fail (by default) when > encountering this error. =20 You are proposing a new TLS fatal error condition. I think that = modifying the TLS protocol is outside the power of this WG. > Implementations MAY offer a means to continue > in spite of this error, but if they do, they MUST ensure with = reasonable > confidence that the consumer of the technology is fully aware of the = risks > involved with continuing in spite of this error. This was discussed earlier on the mailing list, I believe, and the = consensus was to make the failure fatal without allowing continuation. > btw. would it be OK to be more elaborate about DNS zones that > use DNSSEC but do not contain any TLS records for a server host name. > currently it reads: > If the application receives zero usable > certificate associations, it processes TLS in the normal fashion. >=20 > How about something along these lines: >=20 > If the application receives zero usable > certificate associations (i.e. if zero TLSA records are returned > for the server host name), then no additional checks based on this > specification are performed on the server certificate (chain), > and the normal TLS server certificate validation and server > endpoint identification applies. I don't see how that extra wording helps. "processes TLS in the normal = fashion" is shorter and clearer. > I'm slightly confused by the term "application" in the above sentence, > because it really refers to an implementation of this specification = itself > rather than some application calling this implementation. We fully disagree here. Applications do not "call this implementation": = they incorporate the additional rules as part of the implementation. --Paul Hoffman From mrex@sap.com Thu Sep 15 13:07:36 2011 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 E7D9921F8B81 for ; Thu, 15 Sep 2011 13:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.029 X-Spam-Level: X-Spam-Status: No, score=-10.029 tagged_above=-999 required=5 tests=[AWL=0.220, 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 0g9VAlolrFnn for ; Thu, 15 Sep 2011 13:07:36 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 31D0421F8B7B for ; Thu, 15 Sep 2011 13:07:36 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p8FK9haV008266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Sep 2011 22:09:48 +0200 (MEST) From: Martin Rex Message-Id: <201109152009.p8FK9gE3009126@fs4113.wdf.sap.corp> To: warren@kumari.net (Warren Kumari) Date: Thu, 15 Sep 2011 22:09:42 +0200 (MEST) In-Reply-To: <1FD795CF-8698-4DD5-B4B7-29057A8A919F@kumari.net> from "Warren Kumari" at Sep 15, 11 11:36:41 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: bmanning@vacation.karoshi.com, dane@ietf.org Subject: Re: [dane] Reopening issue #22 for discussion.... 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, 15 Sep 2011 20:07:37 -0000 Warren Kumari wrote: > > > > > The server can't strong arm clients. > > Exactly -- the best the server can do is announce all of the TLSA > records (potentially with different algorithms) and the client can > select what it thinks is best.... Since there is no negotiation involved when looking up TLSA records, we may be better off being clear about the algorithm. Do we want to require DNS admins to maintain SHA-512 (or any other hash other than SHA-256) hashes for _all_ permissible server certs for a given server host name whenever they add a certificate association for one certificate with SHA-512, so that a client can first scan the entire list of TLSA records for the algorithm it considers the strongest, and then have the client ignore _all_ other TLSA records when doing the matching? i.e. when a server should have three valid certs, and three TLSA records with SHA256 hashes of these certs respectively, plus only a single TLSA record with SHA512 for just one of those certs, then is this supposed to be a configuration error leading to interop problems for clients that prefer SHA-512 over SHA-256? Protocol-wise, requiring a full set of associations for each hash algorithm, that the domain admin wants to offer/configure, seems like the only approach that could provide better security during the migration period. But frankly, as long as the TLS of the current connection still involves SHA-256 (or even SHA-1) and as long as the chain of DNSSEC signatures protecting those TLSA records still use SHA-256 (or even SHA-1), the security benefit of a TLSA with SHA-512 over TLSA with SHA-256 looks quite insignificant to me. -Martin From paul.hoffman@vpnc.org Thu Sep 15 13:21:19 2011 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 EB7ED11E80A1 for ; Thu, 15 Sep 2011 13:21:18 -0700 (PDT) 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 rZHdGZDAIDM8 for ; Thu, 15 Sep 2011 13:21:18 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 84EDA21F8BBA for ; Thu, 15 Sep 2011 13:21:15 -0700 (PDT) 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 p8FKNQls086231 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 15 Sep 2011 13:23:27 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <201109152009.p8FK9gE3009126@fs4113.wdf.sap.corp> Date: Thu, 15 Sep 2011 13:23:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <37A67E8E-3121-431D-8546-338C5145A124@vpnc.org> References: <201109152009.p8FK9gE3009126@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1244.3) Cc: DANE WG Subject: Re: [dane] Reopening issue #22 for discussion.... 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, 15 Sep 2011 20:21:19 -0000 On Sep 15, 2011, at 1:09 PM, Martin Rex wrote: > Warren Kumari wrote: >>=20 >>>=20 >>> The server can't strong arm clients. >>=20 >> Exactly -- the best the server can do is announce all of the TLSA >> records (potentially with different algorithms) and the client can >> select what it thinks is best.... >=20 > Since there is no negotiation involved when looking up TLSA records, > we may be better off being clear about the algorithm. Current wording in the spec: DNS systems conforming to this specification MUST be able to create TLSA records using matching type 0 (no hash used) and matching type 1 (SHA-256), and SHOULD be able to create TLSA records using matching type 2 (SHA-512). > Do we want to require DNS admins to maintain SHA-512 (or any other > hash other than SHA-256) hashes for _all_ permissible server certs > for a given server host name whenever they add a certificate = association > for one certificate with SHA-512, so that a client can first scan > the entire list of TLSA records for the algorithm it considers the > strongest, and then have the client ignore _all_ other TLSA records > when doing the matching? Why require that at all? Why tell the DNS system what specific hash to = use? > i.e. when a server should have three valid certs, > and three TLSA records with SHA256 hashes of these certs respectively, > plus only a single TLSA record with SHA512 for just one of those = certs, > then is this supposed to be a configuration error leading to interop > problems for clients that prefer SHA-512 over SHA-256? No. > Protocol-wise, requiring a full set of associations for each hash > algorithm, that the domain admin wants to offer/configure, seems like > the only approach that could provide better security during the > migration period. I propose that we don't go the route of complicated algorithm transition = schemes. It has hurt DNSSEC badly already, with no clear benefit. > But frankly, as long as the TLS of the current connection still > involves SHA-256 (or even SHA-1) and as long as the chain of DNSSEC > signatures protecting those TLSA records still use SHA-256 > (or even SHA-1), the security benefit of a TLSA with SHA-512 over > TLSA with SHA-256 looks quite insignificant to me. +1 --Paul Hoffman From mrex@sap.com Thu Sep 15 13:43:36 2011 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 4613B11E80B2 for ; Thu, 15 Sep 2011 13:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.031 X-Spam-Level: X-Spam-Status: No, score=-10.031 tagged_above=-999 required=5 tests=[AWL=0.218, 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 6h2tmQnXlPQo for ; Thu, 15 Sep 2011 13:43:35 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 53C4811E807F for ; Thu, 15 Sep 2011 13:43:35 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p8FKjkBA011106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Sep 2011 22:45:46 +0200 (MEST) From: Martin Rex Message-Id: <201109152045.p8FKjjPC011328@fs4113.wdf.sap.corp> To: paul.hoffman@vpnc.org (Paul Hoffman) Date: Thu, 15 Sep 2011 22:45:45 +0200 (MEST) In-Reply-To: <8B4D8904-2FC4-4808-A99E-FCCA07972F61@vpnc.org> from "Paul Hoffman" at Sep 15, 11 01:07:05 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] #31: Multiple TLSA records in a response 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, 15 Sep 2011 20:43:36 -0000 Paul Hoffman wrote: > > Martin Rex wrote: > > > > I'm slighlty confused by this specific error message text "access_denied". > > Traditionally, an "access_denied" error is not something that one > > inflicts on oneself, but used for situations with two distinct entities, > > where the other denies access, and the entity that receives that error > > has no means to ignore or override this. > > To me, that is what is happening when the domain owner says > "here is the certifying information" and it is unusable. > The definition in the TLS spec for access_denied is: > A valid certificate was received, but when access control was > applied, the sender decided not to proceed with negotiation. This > message is always fatal. That seems to be confusing issues. The domain owner is some third party, it is neither the TLS client nor the TLS server, so no parts of the TLS spec really apply to the situation. The TLS spec defines the fatal alert (49) "access_denied" that a TLS peer can send prior to closing the connection -- but there is *NO* requirement in TLS that the connection must be aborted when some particular validation of the peer certificate fail or can not be performed. All of the TLS specs in existance are very clear on this aspect, see last sentence of Section 1 Introduction of all TLS specs: the decisions on [...] how to interpret the authentication certificates exchanged are left up to the judgment of the designers and implementors of protocols which run on top of TLS. > > If you have a different fatal TLS error that you think would be better, > that would be well worth discussing. In the end, however, the fact that > the TLS error is fatal is all that is relevant. Maybe it is just not sufficiently clear what is meant by this. This specification describes the behaviour of a "DANE client", that an application employs in helping to verify the server certificate (chain) of a TLS server -- exactly as the last sentence of section 1 Introduction of the TLS spec defines it. This DANE client sits alongside with an implementation of rfc6125 (or rfc2818) for traditional TLS (server) endpoing identification between application and TLS implementation. When the application client decides that it does not accept the server certificate, then the client's TLS implementation should close the connection with a fatal access_denied(46) alert, independent of why the client didn't accept the certificate, whether it was a pkix validation failure, whether it was an rfc6125/rfc2818 matching failure, whether it was a DANE matching failure, whether it's one of those rare applications clients that matches a policy OID or whether the client performed and failed some other fancy checks on the server certificate chain. That is nothing we should or have to specify in DANE. What DANE should specify is API level behaviour, but that is clearly distinct from what TLS does on the wire. Whether DANE is called directly by the TLS protocol stack or indirectly by the application, and whether the application offers the user options to override the DANE validation result before directing the TLS protocol stack to either abort or continue the handshake is at the discretion of the application caller. > > > How about something along these lines: > > > > If the application receives zero usable > > certificate associations (i.e. if zero TLSA records are returned > > for the server host name), then no additional checks based on this > > specification are performed on the server certificate (chain), > > and the normal TLS server certificate validation and server > > endpoint identification applies. > > I don't see how that extra wording helps. "processes TLS in the > normal fashion" is shorter and clearer. It may be shorter and clearer to you, but it is technically plain wrong. As I said, TLS is very explicit that making sense of the certificates of the communication peers is entirely at the discretion of the application caller. When using a TLS extension like rfc6091 then the handshake would be completely PKIX-free. What "normally" happens is a TLS server certificate validation and a server endpoint identification performed at the discretion of the application. While there may be TLS implementations where the TLS implementation can perform those checks on behalf of the application ("added value"), the protocol architecture is very clear that this is a function of the application and _NOT_ a function of the TLS implementation. > > > I'm slightly confused by the term "application" in the above sentence, > > because it really refers to an implementation of this specification itself > > rather than some application calling this implementation. > > We fully disagree here. Applications do not "call this implementation": > they incorporate the additional rules as part of the implementation. Yup, it seems like we disagree. I really expect seperate DANE client modules that may be distributed/part of the TLS software distribution that will perform the check on behalf of the application. I'm used to specification that refer to implementations of itself with terms like "compliant implementations", and use the term "application" to any code higher up in the software stack from their perspective. -Martin From mrex@sap.com Thu Sep 15 14:00:20 2011 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 5C33E11E80C1 for ; Thu, 15 Sep 2011 14:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.032 X-Spam-Level: X-Spam-Status: No, score=-10.032 tagged_above=-999 required=5 tests=[AWL=0.217, 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 6II5-tQt4jYN for ; Thu, 15 Sep 2011 14:00:19 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id AE15711E807F for ; Thu, 15 Sep 2011 14:00:18 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p8FL2Shh007297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Sep 2011 23:02:28 +0200 (MEST) From: Martin Rex Message-Id: <201109152102.p8FL2Rnn012213@fs4113.wdf.sap.corp> To: paul.hoffman@vpnc.org (Paul Hoffman) Date: Thu, 15 Sep 2011 23:02:27 +0200 (MEST) In-Reply-To: <37A67E8E-3121-431D-8546-338C5145A124@vpnc.org> from "Paul Hoffman" at Sep 15, 11 01:23:25 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] Reopening issue #22 for discussion.... 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, 15 Sep 2011 21:00:20 -0000 Paul Hoffman wrote: > > Martin Rex wrote: > > > > Do we want to require DNS admins to maintain SHA-512 (or any other > > hash other than SHA-256) hashes for _all_ permissible server certs > > for a given server host name whenever they add a certificate association > > for one certificate with SHA-512, so that a client can first scan > > the entire list of TLSA records for the algorithm it considers the > > strongest, and then have the client ignore _all_ other TLSA records > > when doing the matching? > > Why require that at all? Why tell the DNS system what specific hash to use? We don't tell the DNS system anything. (Don't we have to retrieve _all_ TLSA records in order to check the DNSSEC signature?) We tell the DANE client the algorithm for matching the TLSA records and the DNS admin how to correctly enter/configure the data. > > > i.e. when a server should have three valid certs, > > and three TLSA records with SHA256 hashes of these certs respectively, > > plus only a single TLSA record with SHA512 for just one of those certs, > > then is this supposed to be a configuration error leading to interop > > problems for clients that prefer SHA-512 over SHA-256? > > No. The problem I see with _not_ doing this is that we're actually cheating about hash agility -- because it will not work. When not doing this, different hashes may still be used to render the address bar in different shades of green depending on which hash was in the TLSA record that matched. But the hash algorithm agility and security of a protocol is not about the beautiful colors it can create when it works, but only about how it fails if it is attacked. If one worries about SHA-256 instead of SHA-512 hashes for the server certificate, then this is about possible hash collisions. And as long as there is a valid TLSA record with a SHA-256 hash value, the weakest link are collisions to that SHA-256 hash value. If there is no means to stop the client from matching TLSAs with SHA-256, then there is no security value in providing additional TLSAs with SHA-512. -Martin From zack.weinberg@gmail.com Thu Sep 15 14:23:18 2011 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 1BFAE11E8097 for ; Thu, 15 Sep 2011 14:23:18 -0700 (PDT) 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 9+O2fKCBjxAF for ; Thu, 15 Sep 2011 14:23:17 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7E57B11E807F for ; Thu, 15 Sep 2011 14:23:17 -0700 (PDT) Received: by pzk36 with SMTP id 36so253254pzk.10 for ; Thu, 15 Sep 2011 14:25:30 -0700 (PDT) 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:cc:content-type :content-transfer-encoding; bh=9EstDhceiUbHVHhzoX0sVPS8YZpVB6OHoj5Pab5QZjw=; b=qLDvxqaBdgAxk9MOlfgCzqGYy2LXygybBdFweslqQPttyajmgIvgRjaaFFo7UPWyWw 0+j2rud24lGduqVUYJk4Zg361PbiWm0aLBthm5sOR3RbrY4LKfI7xP7toJlczN3REZqY arGBY5DlBSsX9JHDpzQhmZKtmzYC48fF7J8h4= MIME-Version: 1.0 Received: by 10.68.12.8 with SMTP id u8mr2337765pbb.405.1316121929953; Thu, 15 Sep 2011 14:25:29 -0700 (PDT) Sender: zack.weinberg@gmail.com Received: by 10.68.50.40 with HTTP; Thu, 15 Sep 2011 14:25:29 -0700 (PDT) In-Reply-To: <201109152102.p8FL2Rnn012213@fs4113.wdf.sap.corp> References: <37A67E8E-3121-431D-8546-338C5145A124@vpnc.org> <201109152102.p8FL2Rnn012213@fs4113.wdf.sap.corp> Date: Thu, 15 Sep 2011 14:25:29 -0700 X-Google-Sender-Auth: tCCpyzEnp3sO904NIMn63psvIFY Message-ID: From: Zack Weinberg To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Paul Hoffman , dane@ietf.org Subject: Re: [dane] Reopening issue #22 for discussion.... 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, 15 Sep 2011 21:23:18 -0000 On Thu, Sep 15, 2011 at 2:02 PM, Martin Rex wrote: > If one worries about SHA-256 instead of SHA-512 hashes for the server > certificate, then this is about possible hash collisions. =C2=A0And as lo= ng > as there is a valid TLSA record with a SHA-256 hash value, the weakest > link are collisions to that SHA-256 hash value. =C2=A0If there is no mean= s > to stop the client from matching TLSAs with SHA-256, then there is > no security value in providing additional TLSAs with SHA-512. So I get the impression you want language along these lines: # If the RRset contains multiple TLSA records with the same # association type but different reference types, then after # discarding all records with unsupported reference types, the # client SHOULD rank the records by hash strength and discard all # but the strongest. For example, if the RRset contains two TLSA # records with the same association type, but one carries a SHA-1 # hash and one carries a SHA-256 hash, a client which supports # SHA-256 SHOULD ignore the record with the SHA-1 hash. (Please clarify if this is not what you want.) The problem I see with this is, there's no way to tell whether the two records are meant to be the SHA-1 and SHA-256 of the *same* certificate. If the two records are SHA-1(old-cert), SHA-256(new-cert) and the admin's going to remove the former after the change from old-cert to new-cert has a chance to settle, this would be the wrong behavior. The only way around this problem that I can think of at the moment is something like Matt's group-number proposal, only with different semantics: the group number would indicate which subsets of the RRset should be subject to ranking by hash strength. zw From hallam@gmail.com Thu Sep 15 14:34:35 2011 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 2B65911E80A6 for ; Thu, 15 Sep 2011 14:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.468 X-Spam-Level: X-Spam-Status: No, score=-3.468 tagged_above=-999 required=5 tests=[AWL=0.130, 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 GlZHrp68ZDq7 for ; Thu, 15 Sep 2011 14:34:34 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 255F911E80B1 for ; Thu, 15 Sep 2011 14:34:34 -0700 (PDT) Received: by gyd12 with SMTP id 12so2905432gyd.31 for ; Thu, 15 Sep 2011 14:36:46 -0700 (PDT) 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=2f4Ya6xwaMKJ03ipcHM7tUP7Ow17h5HJuGreaRJ7moc=; b=opuD17x0IadxJVk2MyIhoyWGN7/O8A7ZNTmHfc0ryFyJaVR02lvUhYuKhl9abDOy8h pCXRMxmid5DsAzoZv9JE4uhcjOFh+BXmzk+hDyeuQGIgKDGFF4jPXCkbSgQFl8gx4ZFq XgSjwK9OpfRuXmiRZfADjSfdYKQtlO5dncjXU= MIME-Version: 1.0 Received: by 10.100.55.34 with SMTP id d34mr1614337ana.30.1316122606823; Thu, 15 Sep 2011 14:36:46 -0700 (PDT) Received: by 10.100.120.20 with HTTP; Thu, 15 Sep 2011 14:36:46 -0700 (PDT) In-Reply-To: <8B4D8904-2FC4-4808-A99E-FCCA07972F61@vpnc.org> References: <201109151947.p8FJlQCH008049@fs4113.wdf.sap.corp> <8B4D8904-2FC4-4808-A99E-FCCA07972F61@vpnc.org> Date: Thu, 15 Sep 2011 16:36:46 -0500 Message-ID: From: Phillip Hallam-Baker To: Stephen Farrell , Sean Turner Content-Type: multipart/alternative; boundary=001485f6d9f475e81b04ad01aca0 Cc: DANE WG Subject: Re: [dane] #31: Multiple TLSA records in a response 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, 15 Sep 2011 21:34:35 -0000 --001485f6d9f475e81b04ad01aca0 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 15, 2011 at 3:07 PM, Paul Hoffman wrote: > > On Sep 15, 2011, at 12:47 PM, Martin Rex wrote: > andshake with an > > > To me, the situation looks like a "server certificate DANE validation > failed" > > error. And DANE-aware implementations MUST fail (by default) when > > encountering this error. > > You are proposing a new TLS fatal error condition. I think that modifying > the TLS protocol is outside the power of this WG. We are agreed on that, but what we are not agreed on is what constitutes modification of the TLS protocol. RFC 5246 has the word 'must' 168 times. I have just been through them all and cannot find any MUST that refers to rejecting a cert. The string OCSP does not occur, CRL occurs only once and that is in the PKIX reference. Martin uses the phrase 'DANE-aware implementations MUST'. That is a much weaker statement that the one you are proposing which requires ALL TLS clients to abort the handshake. > Warren Kumari wrote: >> >> The consented text was: >> >> On the first match between one of the certificate association(s) and the >> server's end entity certificate in TLS is found, the TLS client continues the >> TLS handshake, ignoring remaining certificate associations. If no match >> between the usable certificate association(s) and the server's end entity >> certificate in TLS is found, the TLS client MUST abort the handshake with an >> "access_denied" error. Were DANE to become an Internet Standard it would be an IETF criteria, not a DANE one. Thus the proposal as written is a modification of the TLS protocol and beyond the scope of this Working Group. The DANE WG can define what it is to be DANE aware, it MUST NOT be allowed to define what is acceptable behavior for a TLS client. The WG applied for a charter on the basis that it would produce a mechanism for publishing keys: "This working group will develop mechanisms for zone operators to present bindings between names within their control and public keys,..." Nowhere do I see a statement to the effect that the WG will impose requirements on client implementations, on the contrary: "The solutions specified by this working group rely upon the security of the DNS to provide source authentication for public keys. The decision whether the chain of trust provided by DNSSEC is sufficient to trust the key, or whether additional mechanisms are required to determine the acceptability of a key, is left to the entity that uses the key material." Given the approach that the WG has taken to this work I suggest that the ADs consider an applicability statement to clarify this situation. DANE was sold to the IETF on the basis that it would provide a means of using DNSSEC to publish keys. Instead it has developed a spec whose principle design objective has been to restrict use of keys issued under PKIX. -- Website: http://hallambaker.com/ --001485f6d9f475e81b04ad01aca0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Sep 15, 2011 at 3:07 PM, Paul Ho= ffman <paul.h= offman@vpnc.org> wrote:

On Sep 15, 2011, at 12:47 PM, Martin Rex wrote:
andshake with an

=
> To me, the situation looks like a "server certificate DANE valida= tion failed"
> error. =A0And DANE-aware implementations MUST fail (by default) when > encountering this error.

You are proposing a new TLS fatal error condition. I think that modif= ying the TLS protocol is outside the power of this WG.
We are agreed on that, but what we are not agreed on is what co= nstitutes modification of the TLS protocol.

RFC 5246 has the word 'must' 168 times. I have = just been through them all and cannot find any MUST that refers to rejectin= g a cert. The string OCSP does not occur, CRL occurs only once and that is = in the PKIX reference.




Martin use= s the phrase 'DANE-aware=A0implementations=A0MUST'. That is a much = weaker statement that the one you are proposing which requires ALL TLS clie= nts to abort the handshake.


> Warren Kumari wrote:
>&= gt;
>> The consented text was:
>>
>> On the first match= between one of the certificate association(s) and the
>> server&#= 39;s end entity certificate in TLS is found, the TLS client continues the >> TLS handshake, ignoring remaining certificate associations. If no = match
>> between the usable certificate association(s) and the ser= ver's end entity
>> certificate in TLS is found, the TLS clien= t MUST abort the handshake with an
>> "access_denied" error.

W= ere DANE to become an Internet Standard it would be an IETF criteria, not a= DANE one.=A0

Thus the proposal as written is a mo= dification of the TLS protocol and beyond the scope of this Working Group.= =A0


The DANE WG can define what it is to be = DANE aware, it MUST NOT be allowed to define what is acceptable behavior fo= r a TLS client.

The WG applied for a charter on th= e basis that it would produce a mechanism for publishing keys:

= "This working group will develop mechanisms for zone operators to
p= resent bindings between names within their control and public keys,..."= ;

Nowhere do I see a statement to the effect that the WG will i= mpose requirements on client implementations, on the contrary:

"The sol= utions specified by this working group rely upon the security of
the DNS to provide s= ource authentication for public keys. The decision=A0whether the chain of t= rust provided by DNSSEC is sufficient to trust the=A0key, or whether additi= onal mechanisms are required to determine the=A0acceptability of a key, is = left to the entity that uses the key=A0material."


Given the approach that the WG has taken to t= his work I suggest that the ADs consider an applicability statement to clar= ify this situation.

DANE was sold to the IETF on t= he basis that it would provide a means of using DNSSEC to publish keys. Ins= tead it has developed a spec whose principle design objective has been to r= estrict use of keys issued under PKIX.



--
Website: http://hallambaker.com/

--001485f6d9f475e81b04ad01aca0-- From bmanning@karoshi.com Thu Sep 15 14:44:08 2011 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 C084A11E80B8 for ; Thu, 15 Sep 2011 14:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.189 X-Spam-Level: X-Spam-Status: No, score=-6.189 tagged_above=-999 required=5 tests=[AWL=0.410, 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 vzXqgUSly7qa for ; Thu, 15 Sep 2011 14:44:08 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id 4E36311E8097 for ; Thu, 15 Sep 2011 14:44:07 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id p8FLkEWj014825; Thu, 15 Sep 2011 21:46:17 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id p8FLkEIa014824; Thu, 15 Sep 2011 21:46:14 GMT Date: Thu, 15 Sep 2011 21:46:14 +0000 From: bmanning@vacation.karoshi.com To: Martin Rex Message-ID: <20110915214614.GA14586@vacation.karoshi.com.> References: <37A67E8E-3121-431D-8546-338C5145A124@vpnc.org> <201109152102.p8FL2Rnn012213@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201109152102.p8FL2Rnn012213@fs4113.wdf.sap.corp> User-Agent: Mutt/1.4.1i Cc: Paul Hoffman , dane@ietf.org Subject: Re: [dane] Reopening issue #22 for discussion.... 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, 15 Sep 2011 21:44:08 -0000 On Thu, Sep 15, 2011 at 11:02:27PM +0200, Martin Rex wrote: > > If one worries about SHA-256 instead of SHA-512 hashes for the server > certificate, then this is about possible hash collisions. And as long > as there is a valid TLSA record with a SHA-256 hash value, the weakest > link are collisions to that SHA-256 hash value. If there is no means > to stop the client from matching TLSAs with SHA-256, then there is > no security value in providing additional TLSAs with SHA-512. > > -Martin the "one" you refer to above - is that the server or the client? As a server, publishing -256 and -512 hashes would imply, to me, that there exist clients for whom they -ONLY- support -256 or -512. the fallback for clients which support both is a crap shoot, whichever hash they get to first. /bill From mrex@sap.com Thu Sep 15 15:23:56 2011 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 AF25A11E8080 for ; Thu, 15 Sep 2011 15:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.035 X-Spam-Level: X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[AWL=0.214, 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 l--ZFXBaa8IR for ; Thu, 15 Sep 2011 15:23:56 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id DEA7E11E807F for ; Thu, 15 Sep 2011 15:23:55 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p8FMQ6ov015214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Sep 2011 00:26:07 +0200 (MEST) From: Martin Rex Message-Id: <201109152226.p8FMQ5kV016843@fs4113.wdf.sap.corp> To: bmanning@vacation.karoshi.com Date: Fri, 16 Sep 2011 00:26:05 +0200 (MEST) In-Reply-To: <20110915214614.GA14586@vacation.karoshi.com.> from "bmanning@vacation.karoshi.com" at Sep 15, 11 09:46: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] Reopening issue #22 for discussion.... 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, 15 Sep 2011 22:23:56 -0000 bmanning@vacation.karoshi.com wrote: > > On Thu, Sep 15, 2011 at 11:02:27PM +0200, Martin Rex wrote: > > > > If one worries about SHA-256 instead of SHA-512 hashes for the server > > certificate, then this is about possible hash collisions. And as long > > as there is a valid TLSA record with a SHA-256 hash value, the weakest > > link are collisions to that SHA-256 hash value. If there is no means > > to stop the client from matching TLSAs with SHA-256, then there is > > no security value in providing additional TLSAs with SHA-512. > > > > -Martin > > > the "one" you refer to above - is that the server or the client? In the current scope, the TLS client that implements DANE. > > As a server, publishing -256 and -512 hashes would imply, to me, > that there exist clients for whom they -ONLY- support -256 or -512. > the fallback for clients which support both is a crap shoot, whichever > hash they get to first. SHA-256 is mandatory to implement, SHA-512 is optional. The primary reason for hash agility is being able to switch to a different algorithm at some point in the future, when SHA-256 is no longer deemed adequate. The issues you're facing: - for interop with the installed base DANE clients you'll have to continue providing TLSA records with SHA-256 hashes for many years (10+) to come - for new DANE clients to obtain security benefit from TLSA records with a stronger hash, new DANE clients will have to ignore all records with a weaker hash as soon as they find a records with a stronger hash (that they implement) for a given server host name. - to provide smooth migration and interop for heterogeneous installed base of old and new DANE clients, the DNS admin must provide TLSA records with certificate hashes consistently for all desired hash algorithms for a given server host name. -Martin From warren@kumari.net Thu Sep 15 15:31:41 2011 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 E3B2021F8B19 for ; Thu, 15 Sep 2011 15:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.47 X-Spam-Level: X-Spam-Status: No, score=-102.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 NhawKynWJ99Z for ; Thu, 15 Sep 2011 15:31:41 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id E479A21F8B14 for ; Thu, 15 Sep 2011 15:31:40 -0700 (PDT) Received: from dhcp-172-19-119-117.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id A5AA11B416FC; Thu, 15 Sep 2011 18:33:52 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: Date: Thu, 15 Sep 2011 18:33:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2DF6952A-0A9D-4A4C-BF5B-EFD37134C006@kumari.net> References: <201109151947.p8FJlQCH008049@fs4113.wdf.sap.corp> <8B4D8904-2FC4-4808-A99E-FCCA07972F61@vpnc.org> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1084) Cc: DANE WG Subject: Re: [dane] #31: Multiple TLSA records in a response 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, 15 Sep 2011 22:31:42 -0000 On Sep 15, 2011, at 5:36 PM, Phillip Hallam-Baker wrote: >=20 >=20 > On Thu, Sep 15, 2011 at 3:07 PM, Paul Hoffman = wrote: >=20 > On Sep 15, 2011, at 12:47 PM, Martin Rex wrote: > andshake with an >=20 > > To me, the situation looks like a "server certificate DANE = validation failed" > > error. And DANE-aware implementations MUST fail (by default) when > > encountering this error. >=20 > You are proposing a new TLS fatal error condition. I think that = modifying the TLS protocol is outside the power of this WG. >=20 > We are agreed on that, but what we are not agreed on is what = constitutes modification of the TLS protocol. >=20 > RFC 5246 has the word 'must' 168 times. I have just been through them = all and cannot find any MUST that refers to rejecting a cert. The string = OCSP does not occur, CRL occurs only once and that is in the PKIX = reference. >=20 >=20 >=20 >=20 > Martin uses the phrase 'DANE-aware implementations MUST'. That is a = much weaker statement that the one you are proposing which requires ALL = TLS clients to abort the handshake. >=20 >=20 > > Warren Kumari wrote: > >> > >> The consented text was: > >> > >> On the first match between one of the certificate association(s) = and the > >> server's end entity certificate in TLS is found, the TLS client = continues the > >> TLS handshake, ignoring remaining certificate associations. If no = match > >> between the usable certificate association(s) and the server's end = entity > >> certificate in TLS is found, the TLS client MUST abort the = handshake with an > >> "access_denied" error. >=20 > Were DANE to become an Internet Standard it would be an IETF criteria, = not a DANE one.=20 >=20 > Thus the proposal as written is a modification of the TLS protocol and = beyond the scope of this Working Group.=20 >=20 I had interpreted that to mean for things doing DANE -- non-DANEy things = would not be looking for TLSAs, be performing most of this process, etc, = but I'd be interested to hear if my interpretation is not what was = intended. >=20 > The DANE WG can define what it is to be DANE aware, it MUST NOT be = allowed to define what is acceptable behavior for a TLS client. >=20 > The WG applied for a charter on the basis that it would produce a = mechanism for publishing keys: >=20 > "This working group will develop mechanisms for zone operators to > present bindings between names within their control and public = keys,..." >=20 > Nowhere do I see a statement to the effect that the WG will impose = requirements on client implementations, on the contrary: >=20 > "The solutions specified by this working group rely upon the security = of > the DNS to provide source authentication for public keys. The decision = whether the chain of trust provided by DNSSEC is sufficient to trust the = key, or whether additional mechanisms are required to determine the = acceptability of a key, is left to the entity that uses the key = material." >=20 This is somewhat ambiguous (and I'm low on coffee, so thinking is hard) = -- that says "is *sufficient* to trust the key" (emphasis added) which = sets the bar high, not that this cannot be used to explicitly NOT trust = the key. But, as I said, I'm low on coffee...=20 >=20 > Given the approach that the WG has taken to this work I suggest that = the ADs consider an applicability statement to clarify this situation. >=20 Seems more than fair -- Stephen / Sean, please let us know if we are = overstepping our charter.... > DANE was sold to the IETF on the basis that it would provide a means = of using DNSSEC to publish keys. Instead it has developed a spec whose = principle design objective has been to restrict use of keys issued under = PKIX. >=20 >=20 >=20 > --=20 > Website: http://hallambaker.com/ >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From mrex@sap.com Thu Sep 15 15:44:23 2011 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 06D9F11E809B for ; Thu, 15 Sep 2011 15:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.037 X-Spam-Level: X-Spam-Status: No, score=-10.037 tagged_above=-999 required=5 tests=[AWL=0.212, 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 q1ytC+wum5HP for ; Thu, 15 Sep 2011 15:44:22 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 46E3A11E809A for ; Thu, 15 Sep 2011 15:44:22 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p8FMkT9Q022843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Sep 2011 00:46:30 +0200 (MEST) From: Martin Rex Message-Id: <201109152246.p8FMkSFG018373@fs4113.wdf.sap.corp> To: ietf@augustcellars.com (Jim Schaad) Date: Fri, 16 Sep 2011 00:46:28 +0200 (MEST) In-Reply-To: <005201cc73d5$10689760$3139c620$@augustcellars.com> from "Jim Schaad" at Sep 15, 11 11:27:02 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] Reopening issue #22 for discussion.... 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, 15 Sep 2011 22:44:23 -0000 Jim Schaad wrote: > > We do however need to say what a client is to do in the event that a record > exists, but the client does not believe that it is a sufficiently strong > matching. I.e. if my client says that SHA-1 will not do for anything, what > happens if only a SHA-1 record exists. Is this considered to be an unusable > statement or a failed statement. Like the situation that the DNS admin has configured only TLSA records with SHA-512 hashes of certificates and a DANE client that does not support SHA-512 hashes connects to the server. Yes, the document should specify the desired client behaviour. Does the client "groom" the list of TLSA records first, removing all unsupported types (such as those with SHA-512). Ending up with an empty list of associations, should it continue with normal TLS server certificate validation and server endpoint identification, or should it abort because it could not perform a DANE validation due to the lack of TLA records with supported types? I see two possible behaviours: (1) continue normal TLS server certificate validation and server endpoint identification (as if there were no TLSA records) (2) fail the DANE server cert validation, which MUST (by default) abort the handshake/connection and I'm having difficulties deciding which I would prefer personally. I believe I'm leaning for (1), but wondering whether there should be a means in DANE for the domain admin to ask for (2). (No, I don't think that (2) should be unconditionally implied.) -Martin From paul@xelerance.com Thu Sep 15 16:10:31 2011 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 9F83A21F849D for ; Thu, 15 Sep 2011 16:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.491 X-Spam-Level: X-Spam-Status: No, score=-6.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 H5dLIxoTFLMG for ; Thu, 15 Sep 2011 16:10:31 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id 448A321F8492 for ; Thu, 15 Sep 2011 16:10:13 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id F0CE7572EC; Thu, 15 Sep 2011 19:10:15 -0400 (EDT) Date: Thu, 15 Sep 2011 19:10:15 -0400 (EDT) From: Paul Wouters To: Martin Rex In-Reply-To: <201109152246.p8FMkSFG018373@fs4113.wdf.sap.corp> Message-ID: References: <201109152246.p8FMkSFG018373@fs4113.wdf.sap.corp> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dane@ietf.org Subject: Re: [dane] Reopening issue #22 for discussion.... 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, 15 Sep 2011 23:10:31 -0000 On Fri, 16 Sep 2011, Martin Rex wrote: > I see two possible behaviours: > (1) continue normal TLS server certificate validation and server > endpoint identification (as if there were no TLSA records) > > (2) fail the DANE server cert validation, which MUST (by default) > abort the handshake/connection > > and I'm having difficulties deciding which I would prefer personally. > I believe I'm leaning for (1), but wondering whether there should be > a means in DANE for the domain admin to ask for (2). > (No, I don't think that (2) should be unconditionally implied.) Assuming that the TLSA RRset has been validated, and no specific Resource Records were removed, if the RRset contains no hashes the client understands, I think it should proceed as if the TLSA records are not present. However, that does seem to be a matter of local client policy. If a client knows there should be a usable TLSA record, and there is none, it might want to abort. I don't think the DNS admin should be allowed to make that call. Just like the server gives the TLS client a PKIX chain, and leaves it up to the client to decide to proceed or not. Paul From mrex@sap.com Thu Sep 15 16:18:48 2011 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 92BED21F8B35 for ; Thu, 15 Sep 2011 16:18:48 -0700 (PDT) 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 CYkjDFUTJ8Pp for ; Thu, 15 Sep 2011 16:18:48 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id BF28421F8B34 for ; Thu, 15 Sep 2011 16:18:47 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p8FNKoIO024197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Sep 2011 01:20:50 +0200 (MEST) From: Martin Rex Message-Id: <201109152320.p8FNKnSa020316@fs4113.wdf.sap.corp> To: hallam@gmail.com (Phillip Hallam-Baker) Date: Fri, 16 Sep 2011 01:20:49 +0200 (MEST) In-Reply-To: from "Phillip Hallam-Baker" at Sep 15, 11 04:36:46 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] #31: Multiple TLSA records in a response 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, 15 Sep 2011 23:18:48 -0000 Phillip Hallam-Baker wrote: > > We are agreed on that, but what we are not agreed on is what constitutes > modification of the TLS protocol. I see DANE as a useful addition for TLS clients, and I think it would be very good to include it as a utility function available to application callers along with TLS software distributions, but I do not consider it part of TLS itself (neither do I consider rfc6125/rfc2818 part of TLS). > > Thus the proposal as written is a modification of the TLS protocol and > beyond the scope of this Working Group. I would OK to discuss this is someone added an "Updates: 5246" or "Obsoletes: 5246" to the current document. Currently, it looks more like wordsmithing to me and premature to get upset about it. > > The DANE WG can define what it is to be DANE aware, it MUST NOT be allowed > to define what is acceptable behavior for a TLS client. I do not believe that an s/TLS client/DANE-aware TLS client/g is necessary on the document. A clarifying statement in the introduction might be sufficient. > > DANE was sold to the IETF on the basis that it would provide a means of > using DNSSEC to publish keys. Instead it has developed a spec whose > principle design objective has been to restrict use of keys issued under > PKIX. DANE is used to distribute DNSSEC-signed assertions the validity of public keys (including public keys embedded in X.509 certs) of TLS servers. I personally believe that DANE is still perfectly within its charter. Being able to distribute independent confirmations for TLS Server certificates issued under the traditional TLS X.509 PKI is a desperately needed functionality as has been painfully demonstrated several times resulting in some 200.000 virtual fatalities. While the TLS server certificate mis-issuance event at Commodo created a significant security threat, the most recent event at DigiNotar was *MUCH* worse. Sort-of an "extinction-level event" for the TLS X.509 PKI as we know it. Asked about why they had not revoked the fraudulent Google certificate, DigiNotar responded "we were not aware that this certificate had been issued". DANE could have easily stopped that Google cert problem dead in its tracks. PKIX has no current means to prevent it, even for clients that do OCSP plus hard fail (and both of these are serious problems, OCSP by RP for privacy, and OCSP hard fail for robustness and performance). -Martin From bmanning@karoshi.com Thu Sep 15 16:19:00 2011 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 AC1B61F0C3C for ; Thu, 15 Sep 2011 16:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.198 X-Spam-Level: X-Spam-Status: No, score=-6.198 tagged_above=-999 required=5 tests=[AWL=0.401, 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 Yj0Rx1s7Qz28 for ; Thu, 15 Sep 2011 16:19:00 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5001F0C3B for ; Thu, 15 Sep 2011 16:19:00 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id p8FNLCWj015004; Thu, 15 Sep 2011 23:21:12 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id p8FNLCui015003; Thu, 15 Sep 2011 23:21:12 GMT Date: Thu, 15 Sep 2011 23:21:12 +0000 From: bmanning@vacation.karoshi.com To: Martin Rex Message-ID: <20110915232112.GB14586@vacation.karoshi.com.> References: <20110915214614.GA14586@vacation.karoshi.com.> <201109152226.p8FMQ5kV016843@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201109152226.p8FMQ5kV016843@fs4113.wdf.sap.corp> User-Agent: Mutt/1.4.1i Cc: bmanning@vacation.karoshi.com, paul.hoffman@vpnc.org, dane@ietf.org Subject: Re: [dane] Reopening issue #22 for discussion.... 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, 15 Sep 2011 23:19:00 -0000 On Fri, Sep 16, 2011 at 12:26:05AM +0200, Martin Rex wrote: > bmanning@vacation.karoshi.com wrote: > > > SHA-256 is mandatory to implement, SHA-512 is optional. > > The primary reason for hash agility is being able to switch to a > different algorithm at some point in the future, when SHA-256 is no > longer deemed adequate. > > The issues you're facing: > - for interop with the installed base DANE clients you'll have to continue > providing TLSA records with SHA-256 hashes for many years (10+) to come -if- backward interoperablity is desired, yes (30+) years if BIND is any predictor. > - for new DANE clients to obtain security benefit from TLSA records with > a stronger hash, new DANE clients will have to ignore all records with > a weaker hash as soon as they find a records with a stronger hash (that > they implement) for a given server host name. thats not going to fly operationally. the server s going to have to cease publication of all weaker hashes - forcing clients to upgrade. thats the proven operational method. if the weaker hash exists it will get used. anything else is simply gyrations and conplex code paths in the client to try and figure out what the server was trying to say by speaking spanglish, finnish, and mayan... is there a credible reason to try and burden the client code with this goofy logic? seems like an ideal breeding ground for security exploits. > - to provide smooth migration and interop for heterogeneous installed > base of old and new DANE clients, the DNS admin must provide > TLSA records with certificate hashes consistently for all desired > hash algorithms for a given server host name. can I have some of what you are smoking? please? > > > -Martin From mrex@sap.com Thu Sep 15 16:26:46 2011 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 D510E21F84DB for ; Thu, 15 Sep 2011 16:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[AWL=0.210, 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 iUZ8wTpg6tnD for ; Thu, 15 Sep 2011 16:26:46 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 21BFF21F84B4 for ; Thu, 15 Sep 2011 16:26:45 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p8FNSv2b001034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Sep 2011 01:28:57 +0200 (MEST) From: Martin Rex Message-Id: <201109152328.p8FNSvqA020585@fs4113.wdf.sap.corp> To: paul@xelerance.com (Paul Wouters) Date: Fri, 16 Sep 2011 01:28:57 +0200 (MEST) In-Reply-To: from "Paul Wouters" at Sep 15, 11 07:10:15 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] Reopening issue #22 for discussion.... 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, 15 Sep 2011 23:26:46 -0000 Paul Wouters wrote: > > Martin Rex wrote: > > > > I see two possible behaviours: > > (1) continue normal TLS server certificate validation and server > > endpoint identification (as if there were no TLSA records) > > > > (2) fail the DANE server cert validation, which MUST (by default) > > abort the handshake/connection > > > > and I'm having difficulties deciding which I would prefer personally. > > I believe I'm leaning for (1), but wondering whether there should be > > a means in DANE for the domain admin to ask for (2). > > (No, I don't think that (2) should be unconditionally implied.) > > Assuming that the TLSA RRset has been validated, and no specific Resource > Records were removed, if the RRset contains no hashes the client understands, > I think it should proceed as if the TLSA records are not present. However, > that does seem to be a matter of local client policy. If a client knows there > should be a usable TLSA record, and there is none, it might want to abort. > > I don't think the DNS admin should be allowed to make that call. Just like > the server gives the TLS client a PKIX chain, and leaves it up to the client > to decide to proceed or not. I'm sorry for causing a misunderstanding. I was wondering whether the DNS admin should have a means to determine the result of the DANE validation (only) by a DANE client, in presence of TLSA records for a given server host name, but no TLSA records that this DANE client supports. I do not want to entitle DANE for an unconditional hard fail that the user could not override, similar to that I do not entitle PKIX to *require* OCSP plus hard fail for my TLS client. -Martin From hallam@gmail.com Thu Sep 15 17:22:14 2011 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 B3D1E11E8085 for ; Thu, 15 Sep 2011 17:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 gGNYv9Ep2Fr9 for ; Thu, 15 Sep 2011 17:22:14 -0700 (PDT) Received: from mail-vw0-f51.google.com (mail-vw0-f51.google.com [209.85.212.51]) by ietfa.amsl.com (Postfix) with ESMTP id B03C011E8081 for ; Thu, 15 Sep 2011 17:22:05 -0700 (PDT) Received: by vws20 with SMTP id 20so5073113vws.24 for ; Thu, 15 Sep 2011 17:24:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=YBcMPKpVbah4ICoW5ajG0CY9e0SnDz8CIHEITwhkEF0=; b=xS6MKHgEFFFAq4JEbwE80x6F6i8Zf7MAGKrN+TI5ZVq/+RQxruiGUxXj87L/zUL47r w5q481jmjjfkmGVi6PQBsQI/yuOAJ3zCmZwU2fuPnmkynGlW9Ov6JStpTMWutqCzjsMI 8LVEBUpErLH1ZiyGri74xePV+4yAFyae87jUY= Received: by 10.220.106.199 with SMTP id y7mr442254vco.220.1316132658522; Thu, 15 Sep 2011 17:24:18 -0700 (PDT) Received: from [10.68.132.166] (mobile-198-228-196-021.mycingular.net. [198.228.196.21]) by mx.google.com with ESMTPS id be17sm6089592vdc.15.2011.09.15.17.24.13 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Sep 2011 17:24:17 -0700 (PDT) References: <201109152320.p8FNKnSa020316@fs4113.wdf.sap.corp> In-Reply-To: <201109152320.p8FNKnSa020316@fs4113.wdf.sap.corp> Mime-Version: 1.0 (iPad Mail 8L1) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (8L1) From: Phillip Hallam-Baker Date: Thu, 15 Sep 2011 19:24:07 -0500 To: "mrex@sap.com" Cc: "dane@ietf.org" Subject: Re: [dane] #31: Multiple TLSA records in a response 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, 16 Sep 2011 00:22:14 -0000 The proposed language is unequivocal. Clients MUST abort the TLS handshake. Tha changes the TLS conformance as written. Your language, DANE aware is still ambiguous. The language would have to be '= DANE compliant' to make it clear that support for the DANE profile is an opt= ion and not an IETF mandate. Support for DANE at any level is going to be optional. So putting a MUST for= the most controversial part of the spec seems like a bad move for adoption i= n any case. =46rom a systems point of view, aborting the connection is at best going to p= rotect one user. Alerting some party to the possibility of a policy violatio= n is actually more important. Sent from my iPad On Sep 15, 2011, at 18:20, Martin Rex wrote: > Phillip Hallam-Baker wrote: >>=20 >> We are agreed on that, but what we are not agreed on is what constitutes >> modification of the TLS protocol. >=20 > I see DANE as a useful addition for TLS clients, and I think it would be > very good to include it as a utility function available to application > callers along with TLS software distributions, but I do not consider > it part of TLS itself (neither do I consider rfc6125/rfc2818 part of TLS).= >=20 >=20 >>=20 >> Thus the proposal as written is a modification of the TLS protocol and >> beyond the scope of this Working Group. >=20 > I would OK to discuss this is someone added an > "Updates: 5246" or "Obsoletes: 5246" to the current document. > Currently, it looks more like wordsmithing to me and premature > to get upset about it. >=20 >=20 >>=20 >> The DANE WG can define what it is to be DANE aware, it MUST NOT be allowe= d >> to define what is acceptable behavior for a TLS client. >=20 > I do not believe that an s/TLS client/DANE-aware TLS client/g > is necessary on the document. A clarifying statement in the > introduction might be sufficient. >=20 >=20 >>=20 >> DANE was sold to the IETF on the basis that it would provide a means of >> using DNSSEC to publish keys. Instead it has developed a spec whose >> principle design objective has been to restrict use of keys issued under >> PKIX. >=20 > DANE is used to distribute DNSSEC-signed assertions the validity > of public keys (including public keys embedded in X.509 certs) > of TLS servers. I personally believe that DANE is still perfectly > within its charter. >=20 >=20 > Being able to distribute independent confirmations for TLS Server > certificates issued under the traditional TLS X.509 PKI is a > desperately needed functionality as has been painfully demonstrated > several times resulting in some 200.000 virtual fatalities. >=20 > While the TLS server certificate mis-issuance event at Commodo created > a significant security threat, the most recent event at DigiNotar > was *MUCH* worse. Sort-of an "extinction-level event" for the > TLS X.509 PKI as we know it. Asked about why they had not revoked > the fraudulent Google certificate, DigiNotar responded "we were not aware > that this certificate had been issued". >=20 > DANE could have easily stopped that Google cert problem dead in its tracks= . >=20 > PKIX has no current means to prevent it, even for clients that > do OCSP plus hard fail (and both of these are serious problems, > OCSP by RP for privacy, and OCSP hard fail for robustness and performance)= . >=20 >=20 > -Martin From hallam@gmail.com Thu Sep 15 17:31:34 2011 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 7187521F8481 for ; Thu, 15 Sep 2011 17:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 loCZ1mqPqG5G for ; Thu, 15 Sep 2011 17:31:34 -0700 (PDT) Received: from mail-vw0-f51.google.com (mail-vw0-f51.google.com [209.85.212.51]) by ietfa.amsl.com (Postfix) with ESMTP id DD84521F847D for ; Thu, 15 Sep 2011 17:31:33 -0700 (PDT) Received: by vws20 with SMTP id 20so5082753vws.24 for ; Thu, 15 Sep 2011 17:33:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=3+hxVenShl+XFNNTLVt2Ube27Cjg2L3Yvqq61IFwWVE=; b=sH0fcpFXad3hMgw/iSnLUHw7Y5yQqqz0yWsOkbXPLGYrTzW8OIHX3D0v7y1eok8aNH DxoEtEbKroyPqH7JOaB/qtuw2e079/ruWm712tx3yr1CpT0GmGKby1N2IPRwkadS3vWG WgAjZFONG8Gpv8YCEga/qEPpC9skqhGDbTjrk= Received: by 10.52.100.101 with SMTP id ex5mr1266615vdb.254.1316133226580; Thu, 15 Sep 2011 17:33:46 -0700 (PDT) Received: from [10.68.132.166] (mobile-198-228-196-021.mycingular.net. [198.228.196.21]) by mx.google.com with ESMTPS id t13sm6107694vdj.17.2011.09.15.17.33.42 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Sep 2011 17:33:45 -0700 (PDT) References: <20110915214614.GA14586@vacation.karoshi.com.> <201109152226.p8FMQ5kV016843@fs4113.wdf.sap.corp> <4e72886d.c413440a.6897.ffffaf2eSMTPIN_ADDED@mx.google.com> In-Reply-To: <4e72886d.c413440a.6897.ffffaf2eSMTPIN_ADDED@mx.google.com> Mime-Version: 1.0 (iPad Mail 8L1) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <2BBD5ABC-EB88-4419-B4F3-27BA2EF093A4@gmail.com> X-Mailer: iPad Mail (8L1) From: Phillip Hallam-Baker Date: Thu, 15 Sep 2011 19:33:34 -0500 To: "bmanning@vacation.karoshi.com" Cc: "bmanning@vacation.karoshi.com" , "paul.hoffman@vpnc.org" , "dane@ietf.org" Subject: Re: [dane] Reopening issue #22 for discussion.... 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, 16 Sep 2011 00:31:34 -0000 I dont see it as an issue. Chrome and Firefox both autopatch. They are the only browsers by companies a= ttending DANE sessions. By the time anyone with a static browser deploys Sha3 will have been announc= ed. Legacy is a real hazzard in the browser world. But not for any mainstream br= owser deployed in the past four years. The IE4 or Bind thing does not apply.= I cant imagine any group that deployed DANE being asleep on sha3 deployment.= Sent from my iPad On Sep 15, 2011, at 18:21, bmanning@vacation.karoshi.com wrote: > On Fri, Sep 16, 2011 at 12:26:05AM +0200, Martin Rex wrote: >> bmanning@vacation.karoshi.com wrote: >>>=20 >> SHA-256 is mandatory to implement, SHA-512 is optional. >>=20 >> The primary reason for hash agility is being able to switch to a >> different algorithm at some point in the future, when SHA-256 is no >> longer deemed adequate. >>=20 >> The issues you're facing: >> - for interop with the installed base DANE clients you'll have to continu= e >> providing TLSA records with SHA-256 hashes for many years (10+) to come= >=20 > -if- backward interoperablity is desired, yes (30+) years if BIND is > any predictor. >=20 >> - for new DANE clients to obtain security benefit from TLSA records with >> a stronger hash, new DANE clients will have to ignore all records with >> a weaker hash as soon as they find a records with a stronger hash (that= >> they implement) for a given server host name. >=20 > thats not going to fly operationally. the server s going to have to > cease publication of all weaker hashes - forcing clients to upgrade. >=20 > thats the proven operational method. if the weaker hash exists it will= > get used. anything else is simply gyrations and conplex code paths in > the client to try and figure out what the server was trying to say by=20= > speaking spanglish, finnish, and mayan... is there a credible reason t= o > try and burden the client code with this goofy logic? seems like an id= eal > breeding ground for security exploits. =20 >=20 >> - to provide smooth migration and interop for heterogeneous installed >> base of old and new DANE clients, the DNS admin must provide >> TLSA records with certificate hashes consistently for all desired >> hash algorithms for a given server host name. >=20 > can I have some of what you are smoking? please? >=20 >>=20 >>=20 >> -Martin > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From paul.hoffman@vpnc.org Thu Sep 15 18:18:09 2011 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 4073D11E8086 for ; Thu, 15 Sep 2011 18:18:09 -0700 (PDT) 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 TEBspN8PveZ9 for ; Thu, 15 Sep 2011 18:18:08 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 910FB11E807F for ; Thu, 15 Sep 2011 18:18:08 -0700 (PDT) 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 p8G1Iufb024933 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 15 Sep 2011 18:18:57 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Paul Hoffman In-Reply-To: Date: Thu, 15 Sep 2011 18:18:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <01BDF4B9-9180-47BF-8BA6-0FCBA68488EF@vpnc.org> References: <201109151947.p8FJlQCH008049@fs4113.wdf.sap.corp> <8B4D8904-2FC4-4808-A99E-FCCA07972F61@vpnc.org> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1244.3) Cc: DANE WG Subject: Re: [dane] #31: Multiple TLSA records in a response 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, 16 Sep 2011 01:18:09 -0000 On Sep 15, 2011, at 2:36 PM, Phillip Hallam-Baker wrote: > Martin uses the phrase 'DANE-aware implementations MUST'. That is a = much weaker statement that the one you are proposing which requires ALL = TLS clients to abort the handshake. It is assumed in IETF protocols that only systems that implement the = protocol actually care about the protocol. Your interpretation that RFC = X might affect RFC Y without saying so is "interesting", and not = supported by anything published the IETF that I know of. Having said that, your proposed change (adding "DANE-aware" to the spec) = seems harmless. Unless we hear objections, we'll make that change in the = next draft. --Paul Hoffman From hallam@gmail.com Thu Sep 15 19:42:12 2011 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 BE47621F8663 for ; Thu, 15 Sep 2011 19:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.469 X-Spam-Level: X-Spam-Status: No, score=-3.469 tagged_above=-999 required=5 tests=[AWL=0.129, 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 iQQ3H8C9pMR5 for ; Thu, 15 Sep 2011 19:42:12 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id CB4F921F863E for ; Thu, 15 Sep 2011 19:42:11 -0700 (PDT) Received: by ywa6 with SMTP id 6so3065904ywa.31 for ; Thu, 15 Sep 2011 19:44:25 -0700 (PDT) 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=ZWz9nscYSrO5lhbla2UH6Tzw9Zq25EqT+hzaPLkPMGA=; b=A3A0uTr2V+lrMACDG0b1xU22sv0xexAcZpxt98TT57YkKKKc+z5DmEyLynMgWcNhFn zEalwdFvtxki+oM3BE+ogtSPQHtQvaTF8aW4GVUz1ykFf3OU2vKLMu2m49d7miqp8PEz JxxWiqJtq1lVKJHVWex3zs/Qq1MDbzD+Cz6xk= MIME-Version: 1.0 Received: by 10.100.215.16 with SMTP id n16mr1788168ang.8.1316141065097; Thu, 15 Sep 2011 19:44:25 -0700 (PDT) Received: by 10.100.120.20 with HTTP; Thu, 15 Sep 2011 19:44:25 -0700 (PDT) In-Reply-To: <01BDF4B9-9180-47BF-8BA6-0FCBA68488EF@vpnc.org> References: <201109151947.p8FJlQCH008049@fs4113.wdf.sap.corp> <8B4D8904-2FC4-4808-A99E-FCCA07972F61@vpnc.org> <01BDF4B9-9180-47BF-8BA6-0FCBA68488EF@vpnc.org> Date: Thu, 15 Sep 2011 21:44:25 -0500 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=0016368e2058a8d0d604ad05f834 Cc: DANE WG Subject: Re: [dane] #31: Multiple TLSA records in a response 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, 16 Sep 2011 02:42:12 -0000 --0016368e2058a8d0d604ad05f834 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 15, 2011 at 8:18 PM, Paul Hoffman wrote: > On Sep 15, 2011, at 2:36 PM, Phillip Hallam-Baker wrote: > > > Martin uses the phrase 'DANE-aware implementations MUST'. That is a much > weaker statement that the one you are proposing which requires ALL TLS > clients to abort the handshake. > > It is assumed in IETF protocols that only systems that implement the > protocol actually care about the protocol. Your interpretation that RFC X > might affect RFC Y without saying so is "interesting", and not supported by > anything published the IETF that I know of. > Given that you have on previous occasions led me to believe that you were prepared to accept a compromise which turned out not to be the case, I think it is in the interest of the group that there is total clarity on this point. Having said that, your proposed change (adding "DANE-aware" to the spec) > seems harmless. Unless we hear objections, we'll make that change in the > next draft. Actually that was Martin's formulation. I suggested DANE-compliant. DANE-aware might be taken to imply that if a client has the ability to check for DANE compliance then it is obliged to do so in every case. I still think that mandating aborting the connection is inappropriate. That is a trust decision for the client. In my (admittedly brief) reading on the TLS spec today we do not appear to mandate that a client abort a connection if a cert is invalid or revoked. It is appropriate for a protocol standard to define when a security policy violation (e.g. against a DANE record) has occurred and state the consequences. Mandating a particular response is not appropriate. It is highly unlikely that browser implementations are going to get comfortable enough with DNS based security policy records to switch on hardfail immediately. If hardfail is mandated the likely outcome is going to be that the industry chooses other approaches. -- Website: http://hallambaker.com/ --0016368e2058a8d0d604ad05f834 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Sep 15, 2011 at 8:18 PM, Paul Ho= ffman <paul.h= offman@vpnc.org> wrote:
On Sep 15, 2011, at 2:36 PM, Phillip Hallam-Baker wrote:<= br>
> Martin uses the phrase 'DANE-aware impleme= ntations MUST'. That is a much weaker statement that the one you are pr= oposing which requires ALL TLS clients to abort the handshake.

It is assumed in IETF protocols that only systems that implement the = protocol actually care about the protocol. Your interpretation that RFC X m= ight affect RFC Y without saying so is "interesting", and not sup= ported by anything published the IETF that I know of.

Given that you have on previous occasions = led me to believe that you were prepared to accept a compromise which turne= d out not to be the case, I think it is in the interest of the group that t= here is total clarity on this point.


Having said that, your proposed change (adding "DANE-aware" to th= e spec) seems harmless. Unless we hear objections, we'll make that chan= ge in the next draft.

Actually that was Mar= tin's formulation. I suggested DANE-compliant.

DANE-aware might be taken to imply that if a client has the abili= ty to check for DANE compliance then it is obliged to do so in every case.<= br clear=3D"all">


I still think that mand= ating aborting the connection is inappropriate. That is a trust decision fo= r the client. In my (admittedly brief) reading on the TLS spec today we do = not appear to mandate that a client abort a connection if a cert is invalid= or revoked.

It is appropriate for a protocol standard to define whe= n a security policy violation (e.g. against a DANE record) has occurred and= state the consequences. Mandating a particular response is not appropriate= .

It is highly unlikely that browser implementations are = going to get comfortable enough with DNS based security policy records to s= witch on hardfail immediately. If hardfail is mandated the likely outcome i= s going to be that the industry chooses other approaches.

--
Website: http://h= allambaker.com/

--0016368e2058a8d0d604ad05f834-- From ietf@augustcellars.com Thu Sep 15 20:08:49 2011 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 F22FB21F8B15 for ; Thu, 15 Sep 2011 20:08:49 -0700 (PDT) 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 k6D6vQuT9y5a for ; Thu, 15 Sep 2011 20:08:49 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 23A2D21F8B13 for ; Thu, 15 Sep 2011 20:08:49 -0700 (PDT) Received: from TITUS (173-160-230-153-Washington.hfc.comcastbusiness.net [173.160.230.153]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id A6A8438F2A; Thu, 15 Sep 2011 20:11:02 -0700 (PDT) From: "Jim Schaad" To: References: <005201cc73d5$10689760$3139c620$@augustcellars.com> from "Jim Schaad" at Sep 15, 11 11:27:02 am <201109152246.p8FMkSFG018373@fs4113.wdf.sap.corp> In-Reply-To: <201109152246.p8FMkSFG018373@fs4113.wdf.sap.corp> Date: Thu, 15 Sep 2011 20:47:36 -0700 Message-ID: <000301cc7423$61caa690$255ff3b0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQKEfPC8hR7BugjjZAycFT/1gxATppPfS4VQ Cc: paul.hoffman@vpnc.org, dane@ietf.org Subject: Re: [dane] Reopening issue #22 for discussion.... 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, 16 Sep 2011 03:08:50 -0000 > -----Original Message----- > From: Martin Rex [mailto:mrex@sap.com] > Sent: Thursday, September 15, 2011 3:46 PM > To: Jim Schaad > Cc: paul.hoffman@vpnc.org; dane@ietf.org > Subject: Re: [dane] Reopening issue #22 for discussion.... > > Jim Schaad wrote: > > > > We do however need to say what a client is to do in the event that a > > record exists, but the client does not believe that it is a > > sufficiently strong matching. I.e. if my client says that SHA-1 will > > not do for anything, what happens if only a SHA-1 record exists. Is > > this considered to be an unusable statement or a failed statement. > > Like the situation that the DNS admin has configured only TLSA records with > SHA-512 hashes of certificates and a DANE client that does not support SHA- > 512 hashes connects to the server. > > Yes, the document should specify the desired client behaviour. > > Does the client "groom" the list of TLSA records first, removing all > unsupported types (such as those with SHA-512). Ending up with an empty > list of associations, should it continue with normal TLS server certificate > validation and server endpoint identification, or should it abort because it > could not perform a DANE validation due to the lack of TLA records with > supported types? My understanding is that yes, the client does "groom" the list of TLSA records first, removing all unsupported types (such as the apply strange logic or PGP cert type) from the list first. This is documented behavior as removing things which are unusable. If the list at that point is empty, then normal processing is done. My issue is a different one, we "support" the type, but say that it is for some reason not secure. (i.e. the 8-bit add all the bytes together hash function.) In this case I don't know what the behavior should be. I think it should be, this is a usable (I know what it means) but a record which always fails evaluation (i.e. the hash value never matches) and thus if no other usable records exist then the TLS handshake would be aborted. The behavior of grooming the list is required so that new records can be added in the future without causing sudden failures to occur. Jim > > > I see two possible behaviours: > (1) continue normal TLS server certificate validation and server > endpoint identification (as if there were no TLSA records) > > (2) fail the DANE server cert validation, which MUST (by default) > abort the handshake/connection > > and I'm having difficulties deciding which I would prefer personally. > I believe I'm leaning for (1), but wondering whether there should be a means > in DANE for the domain admin to ask for (2). > (No, I don't think that (2) should be unconditionally implied.) > > -Martin From ietf@augustcellars.com Thu Sep 15 20:11:28 2011 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 9127911E809A for ; Thu, 15 Sep 2011 20:11:27 -0700 (PDT) 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 lQzxh8n9xjTH for ; Thu, 15 Sep 2011 20:11:25 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id B29D111E8086 for ; Thu, 15 Sep 2011 20:11:25 -0700 (PDT) Received: from TITUS (173-160-230-153-Washington.hfc.comcastbusiness.net [173.160.230.153]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 704BC38F2A; Thu, 15 Sep 2011 20:13:39 -0700 (PDT) From: "Jim Schaad" To: "'Warren Kumari'" , "'DANE WG'" References: <1E08D85E-3E17-4E30-BF21-6C37E8CE3052@kumari.net> In-Reply-To: <1E08D85E-3E17-4E30-BF21-6C37E8CE3052@kumari.net> Date: Thu, 15 Sep 2011 20:50:15 -0700 Message-ID: <000401cc7423$bf343990$3d9cacb0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQIvRAZN9pNd4aM3kRlhjMUF1HjRoZSJv0WA Subject: Re: [dane] Opening issues #25, #26, #27 as a group. 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, 16 Sep 2011 03:11:28 -0000 I believe that #27 is a duplicate of #32. While I believe that this should be addressed, the current group consensus is that it will not be addressed. Jim > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of > Warren Kumari > Sent: Wednesday, September 14, 2011 2:39 PM > To: DANE WG > Subject: [dane] Opening issues #25, #26, #27 as a group. > > Hi all. > > These are all related issues: > #25: http://trac.tools.ietf.org/wg/dane/trac/ticket/25 - Independent > additive and restrictive assertions > #26: http://trac.tools.ietf.org/wg/dane/trac/ticket/26 - Restrictive assertions > a conformance requirement, additive ones not? > #27: http://trac.tools.ietf.org/wg/dane/trac/ticket/27 - Conjunction of > restrictions > > > It would be great if we could discuss them as a group, and come to some sort > of consensus by next Friday (September 23rd). > If commenting on a particular issue number, it would be awesome if you > could clearly state which :-P > > W > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From zack.weinberg@gmail.com Thu Sep 15 22:19:19 2011 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 2FA5121F8B8C for ; Thu, 15 Sep 2011 22:19:19 -0700 (PDT) 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 Pyn1eh7URKqR for ; Thu, 15 Sep 2011 22:19:18 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE4421F8B89 for ; Thu, 15 Sep 2011 22:19:18 -0700 (PDT) Received: by yxt33 with SMTP id 33so3129819yxt.31 for ; Thu, 15 Sep 2011 22:21:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=zd1B8v3pS5SLoJnkk0eEuSQ6hhfSlTcgjz1HZM2+uFY=; b=W944fVspxEf5/hYm2GJbnKF/0Bt1VzU2LG4nW+xk6tRaG/Ntred/QU/TSVmkPS2KJi OazdB2xlvouoUc149k/NvnRd17NQzx2t0ajDKiCU1aJxReWuK+4rCBDGwIgvT9Dn/Dyc YTjTKG75cpV3Hcc6WMkfynU4bn6oZ9bnrfhO4= Received: by 10.236.76.38 with SMTP id a26mr12042913yhe.53.1316150492007; Thu, 15 Sep 2011 22:21:32 -0700 (PDT) Received: from ardsley.local (99-113-32-219.lightspeed.sntcca.sbcglobal.net. [99.113.32.219]) by mx.google.com with ESMTPS id z23sm6546702yhl.1.2011.09.15.22.21.30 (version=SSLv3 cipher=OTHER); Thu, 15 Sep 2011 22:21:30 -0700 (PDT) Sender: Zack Weinberg Message-ID: <4E72DCD9.2040006@sv.cmu.edu> Date: Thu, 15 Sep 2011 22:21:29 -0700 From: Zack Weinberg User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: dane@ietf.org References: <201109151947.p8FJlQCH008049@fs4113.wdf.sap.corp> <8B4D8904-2FC4-4808-A99E-FCCA07972F61@vpnc.org> <01BDF4B9-9180-47BF-8BA6-0FCBA68488EF@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dane] #31: Multiple TLSA records in a response 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, 16 Sep 2011 05:19:19 -0000 On 2011-09-15 7:44 PM, Phillip Hallam-Baker wrote: > It is appropriate for a protocol standard to define when a security > policy violation (e.g. against a DANE record) has occurred and state the > consequences. Mandating a particular response is not appropriate. Mandating client behavior is the only way to avoid lack of interoperability. In this case, mandating hard failure is also the only way this spec does any damn good relative to the status quo, security-wise. > It is highly unlikely that browser implementations are going to get > comfortable enough with DNS based security policy records to switch on > hardfail immediately. If hardfail is mandated the likely outcome is > going to be that the industry chooses other approaches. I do not speak for Mozilla, but I am one of the guys who might be implementing DANE for Mozilla, and from my perspective, DANE ceases to be worth bothering to implement if it doesn't mandate hard failure. You're probably going to turn around and say it's perfectly within my power to code in hard failure even if the spec doesn't mandate it, but the thing is, if it's not a mandate, *some* browser is going to not do it, and then people will demand that their users switch to that browser rather than fix their sites, and the entire thing becomes worthless. In other regards, I mostly don't care what we have to do to avoid treading on the TLS and PKIX working groups' toes -- but I will fight tooth and nail for that one MUST. zw From gnu@toad.com Thu Sep 15 23:16:47 2011 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 0493121F84D9 for ; Thu, 15 Sep 2011 23:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.097 X-Spam-Level: X-Spam-Status: No, score=0.097 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_NJABL_RELAY=2.696] 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 Mzg18MqfWkgN for ; Thu, 15 Sep 2011 23:16:46 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id 53B6D21F84DA for ; Thu, 15 Sep 2011 23:16:46 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id p8G6IqQs005063; Thu, 15 Sep 2011 23:18:52 -0700 Message-Id: <201109160618.p8G6IqQs005063@new.toad.com> To: DANE WG In-reply-to: References: <201109151947.p8FJlQCH008049@fs4113.wdf.sap.corp> <8B4D8904-2FC4-4808-A99E-FCCA07972F61@vpnc.org> Comments: In-reply-to Phillip Hallam-Baker message dated "Thu, 15 Sep 2011 16:36:46 -0500." Date: Thu, 15 Sep 2011 23:18:52 -0700 From: John Gilmore Subject: Re: [dane] #31: Multiple TLSA records in a response 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, 16 Sep 2011 06:16:47 -0000 Phillip trolled: > DANE was sold to the IETF on the basis that it would provide a means of > using DNSSEC to publish keys. Instead it has developed a spec whose > principle design objective has been to restrict use of keys issued under > PKIX. DANE's certified keys would be useless if any of six hundred untrustworthy CA's anywhere in the world could "issue under PKIX" a man-in-the-middle certificate that every browser would accept in preference to the DANE certified key. You know this, Phillip; you aren't stupid. So please stop trolling us. Too-obvious efforts like this one are making us better at ignoring you and just getting the work of the committee done. The PKIX CA model is dead. Two major security incidents have killed it. One was a "warning shot", and the other involved a totalitarian country breaking into a CA in another country, issuing itself more than 500 fake certs, and using them to surveill their entire population's "https" web accesses to major infrastructural sites, for some as yet undetermined number of days or weeks. The world is damn lucky that IETF *has* an effort already in progress to design and deploy a replacement. Now that every bad guy in the world knows, by reading the newspaper, how vulnerable "secure" web sites are when "secured" by PKIX, nothing will prevent more and more serious security violations, ending only when the Internet community completely stops depending on the PKIX CA model. If we are lucky, and smart, we'll get the replacement rolled out before the Internet user community completely loses faith that that "https:" prefix and padlock image has any meaning at all. John From jakob@kirei.se Fri Sep 16 01:23:14 2011 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 606AB21F8BE9 for ; Fri, 16 Sep 2011 01:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.643 X-Spam-Level: X-Spam-Status: No, score=-0.643 tagged_above=-999 required=5 tests=[AWL=0.055, 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 Z9G9iUrBwkjV for ; Fri, 16 Sep 2011 01:23:13 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id E764B21F8BD7 for ; Fri, 16 Sep 2011 01:23:12 -0700 (PDT) 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=pfFlXyBgND/7C+Jixcw/iEeOxH0jsQDAf8qtmJoxJ3g=; b=z+nAAq+VTr5VhNwI70LUl1t16K+a1gYCnUwtwREhHOKu9cn/kfiijcLjCMHdH7tgmtJvh9jkPh9FO gThB/1sT5SKT4J36u/HnGxLq7vw1jOTV40W4B0jAs4xO17Kka+SPiVSYgznj9NOc2ltPFNgCZgP6Rh RovWTN3Eya45u3yg= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Fri, 16 Sep 2011 10:25:23 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Jakob Schlyter In-Reply-To: Date: Fri, 16 Sep 2011 10:25:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <21FEC5AD-359E-477D-BD58-5D8925849E31@kirei.se> References: <201109151947.p8FJlQCH008049@fs4113.wdf.sap.corp> <8B4D8904-2FC4-4808-A99E-FCCA07972F61@vpnc.org> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1244.3) Cc: DANE WG Subject: Re: [dane] #31: Multiple TLSA records in a response 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, 16 Sep 2011 08:23:14 -0000 On 15 sep 2011, at 23:36, Phillip Hallam-Baker wrote: > DANE was sold to the IETF on the basis that it would provide a means = of using DNSSEC to publish keys. Instead it has developed a spec whose = principle design objective has been to restrict use of keys issued under = PKIX. I do not agree on this statement. DANE as always been "sold" as a method = of limiting trust in the current public key infrastructure - either by = constraining trust of CA issued certificates (usages 0 and 1) or by = introducing trust to self-signed certificates (usage 2). jakob From hallam@gmail.com Fri Sep 16 04:28:49 2011 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 7C22921F8B9B for ; Fri, 16 Sep 2011 04:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.47 X-Spam-Level: X-Spam-Status: No, score=-3.47 tagged_above=-999 required=5 tests=[AWL=0.128, 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 yCbX6KVxk+Ci for ; Fri, 16 Sep 2011 04:28:48 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7102021F8B85 for ; Fri, 16 Sep 2011 04:28:48 -0700 (PDT) Received: by gxk19 with SMTP id 19so3388855gxk.31 for ; Fri, 16 Sep 2011 04:31:02 -0700 (PDT) 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=RieZAsCNn8vmhQRLBjPuuj39pFwm5frAu9Tz6qugqDw=; b=fIxdvg5YxrbGxvVylHkCoQ1ytEf36qJpJCBu3pg/DMaJakrdrXMWnvEemWXbunRhI4 KprvpS7zlSEGR6y5bjEvzWYjZyUedVCWz0tXUfyynF9pSGa8WsXWlf1RV3CxNw6PzSwO 5alOWH1Sq7iBLzG0STCZANmVaUrdAN3wPKA9Q= MIME-Version: 1.0 Received: by 10.101.11.36 with SMTP id o36mr2209596ani.74.1316172661121; Fri, 16 Sep 2011 04:31:01 -0700 (PDT) Received: by 10.100.120.20 with HTTP; Fri, 16 Sep 2011 04:31:00 -0700 (PDT) In-Reply-To: <201109160618.p8G6IqQs005063@new.toad.com> References: <201109151947.p8FJlQCH008049@fs4113.wdf.sap.corp> <8B4D8904-2FC4-4808-A99E-FCCA07972F61@vpnc.org> <201109160618.p8G6IqQs005063@new.toad.com> Date: Fri, 16 Sep 2011 06:31:00 -0500 Message-ID: From: Phillip Hallam-Baker To: John Gilmore Content-Type: multipart/alternative; boundary=0016e68ef457ede13c04ad0d5336 Cc: DANE WG Subject: Re: [dane] #31: Multiple TLSA records in a response 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, 16 Sep 2011 11:28:49 -0000 --0016e68ef457ede13c04ad0d5336 Content-Type: text/plain; charset=ISO-8859-1 I take objection to the objection in the first line If you want me to bother to read the rest of your post you will withdraw it immediately. On Fri, Sep 16, 2011 at 1:18 AM, John Gilmore wrote: > Phillip trolled: > > DANE was sold to the IETF on the basis that it would provide a means of > > using DNSSEC to publish keys. Instead it has developed a spec whose > > principle design objective has been to restrict use of keys issued under > > PKIX. > > DANE's certified keys would be useless if any of six hundred > untrustworthy CA's anywhere in the world could "issue under PKIX" a > man-in-the-middle certificate that every browser would accept in > preference to the DANE certified key. > > You know this, Phillip; you aren't stupid. So please stop trolling > us. Too-obvious efforts like this one are making us better at > ignoring you and just getting the work of the committee done. > > The PKIX CA model is dead. Two major security incidents have killed > it. One was a "warning shot", and the other involved a totalitarian > country breaking into a CA in another country, issuing itself more > than 500 fake certs, and using them to surveill their entire > population's "https" web accesses to major infrastructural sites, for > some as yet undetermined number of days or weeks. > > The world is damn lucky that IETF *has* an effort already in progress > to design and deploy a replacement. Now that every bad guy in the > world knows, by reading the newspaper, how vulnerable "secure" web > sites are when "secured" by PKIX, nothing will prevent more and more > serious security violations, ending only when the Internet community > completely stops depending on the PKIX CA model. > > If we are lucky, and smart, we'll get the replacement rolled out > before the Internet user community completely loses faith that that > "https:" prefix and padlock image has any meaning at all. > > John > > -- Website: http://hallambaker.com/ --0016e68ef457ede13c04ad0d5336 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I take objection to the objection in the first line

If y= ou want me to bother to read the rest of your post you will withdraw it imm= ediately.



On Fri, Sep 16, 2011 at 1:18 AM, John Gilmore <gnu@toad.com> wrote:
Phillip trolled:
> DANE was sold to the IETF on the basis that it would= provide a means of
> using DNSSEC to publish keys. Instead it has developed a spec whose > principle design objective has been to restrict use of keys issued und= er
> PKIX.

DANE's certified keys would be useless if any of six hundred
untrustworthy CA's anywhere in the world could "issue under PKIX&q= uot; a
man-in-the-middle certificate that every browser would accept in
preference to the DANE certified key.

You know this, Phillip; you aren't stupid. =A0So please stop trolling us. =A0Too-obvious efforts like this one are making us better at
ignoring you and just getting the work of the committee done.

The PKIX CA model is dead. =A0Two major security incidents have killed
it. =A0One was a "warning shot", and the other involved a totalit= arian
country breaking into a CA in another country, issuing itself more
than 500 fake certs, and using them to surveill their entire
population's "https" web accesses to major infrastructural si= tes, for
some as yet undetermined number of days or weeks.

The world is damn lucky that IETF *has* an effort already in progress
to design and deploy a replacement. =A0Now that every bad guy in the
world knows, by reading the newspaper, how vulnerable "secure" we= b
sites are when "secured" by PKIX, nothing will prevent more and m= ore
serious security violations, ending only when the Internet community
completely stops depending on the PKIX CA model.

If we are lucky, and smart, we'll get the replacement rolled out
before the Internet user community completely loses faith that that
"https:" prefix and padlock image has any meaning at all.

=A0 =A0 =A0 =A0John




--
Websi= te: http://hallambaker.com/

--0016e68ef457ede13c04ad0d5336-- From hallam@gmail.com Fri Sep 16 04:31:47 2011 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 9EA0421F85DB for ; Fri, 16 Sep 2011 04:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.471 X-Spam-Level: X-Spam-Status: No, score=-3.471 tagged_above=-999 required=5 tests=[AWL=0.127, 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 1tKCs0L0P9B8 for ; Fri, 16 Sep 2011 04:31:47 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id E09ED21F8591 for ; Fri, 16 Sep 2011 04:31:46 -0700 (PDT) Received: by yie12 with SMTP id 12so3321989yie.31 for ; Fri, 16 Sep 2011 04:34:01 -0700 (PDT) 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=VKKp1pqzR9dEVrkAS5u0QsBfGg4rn6k1/u23fK32N7A=; b=qVdwu4ZXfogeG9CrwtU1FLuoq7IlEuZQqoCNTTvu7gvZMlukPzLv/s1fo/7psyJDB4 dL1WAqWOnliykCEBPBiifbJndGrgbmQiMc4rFVwHPKivC3B2fOmNIJu5q3OcL5zYfDMb J8mEwHohM2vfaqYEPlmiZ5R/nhlpaxX3R/O7c= MIME-Version: 1.0 Received: by 10.101.28.40 with SMTP id f40mr393792anj.30.1316172841247; Fri, 16 Sep 2011 04:34:01 -0700 (PDT) Received: by 10.100.120.20 with HTTP; Fri, 16 Sep 2011 04:34:01 -0700 (PDT) In-Reply-To: <21FEC5AD-359E-477D-BD58-5D8925849E31@kirei.se> References: <201109151947.p8FJlQCH008049@fs4113.wdf.sap.corp> <8B4D8904-2FC4-4808-A99E-FCCA07972F61@vpnc.org> <21FEC5AD-359E-477D-BD58-5D8925849E31@kirei.se> Date: Fri, 16 Sep 2011 06:34:01 -0500 Message-ID: From: Phillip Hallam-Baker To: Jakob Schlyter Content-Type: multipart/alternative; boundary=001b2413b4c1aa62d604ad0d5ebc Cc: DANE WG Subject: Re: [dane] #31: Multiple TLSA records in a response 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, 16 Sep 2011 11:31:47 -0000 --001b2413b4c1aa62d604ad0d5ebc Content-Type: text/plain; charset=ISO-8859-1 On Fri, Sep 16, 2011 at 3:25 AM, Jakob Schlyter wrote: > On 15 sep 2011, at 23:36, Phillip Hallam-Baker wrote: > > > DANE was sold to the IETF on the basis that it would provide a means of > using DNSSEC to publish keys. Instead it has developed a spec whose > principle design objective has been to restrict use of keys issued under > PKIX. > > I do not agree on this statement. DANE as always been "sold" as a method of > limiting trust in the current public key infrastructure - either by > constraining trust of CA issued certificates (usages 0 and 1) or by > introducing trust to self-signed certificates (usage 2). That is simply not true. While it is arguable that the charter could be interpreted as permitting usages 0 or 1 it does not state that they are the objective. The only reason that usage became apparent at all was that I rooted it out from the original draft. -- Website: http://hallambaker.com/ --001b2413b4c1aa62d604ad0d5ebc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Sep 16, 2011 at 3:25 AM, Jakob S= chlyter <jakob@kirei= .se> wrote:
On 15 sep 2011, at 23:36, Phillip Hallam-Baker wrote:

> DANE was sold to the IETF on the basis that it would provide a means o= f using DNSSEC to publish keys. Instead it has developed a spec whose princ= iple design objective has been to restrict use of keys issued under PKIX.
I do not agree on this statement. DANE as always been "sold"= ; as a method of limiting trust in the current public key infrastructure - = either by constraining trust of CA issued certificates (usages 0 and 1) or = by introducing trust to self-signed certificates (usage 2).

That is simply not true.=A0

Wh= ile it is arguable that the charter could be interpreted as permitting usag= es 0 or 1 it does not state that they are the objective.

The only reason that usage became apparent at all was that I rooted it= out from the original draft.


-- <= br>Website: http://hallambaker.com/=

--001b2413b4c1aa62d604ad0d5ebc-- From hallam@gmail.com Fri Sep 16 04:58:51 2011 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 E869421F8B3C for ; Fri, 16 Sep 2011 04:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.472 X-Spam-Level: X-Spam-Status: No, score=-3.472 tagged_above=-999 required=5 tests=[AWL=0.126, 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 WQF891ln5sxF for ; Fri, 16 Sep 2011 04:58:51 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id D463321F8B29 for ; Fri, 16 Sep 2011 04:58:50 -0700 (PDT) Received: by yxt33 with SMTP id 33so3336616yxt.31 for ; Fri, 16 Sep 2011 05:01:05 -0700 (PDT) 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=QXReNk8FkRiQ/fbgEEzxTsN4z/3qoAaEMy2AaAAMdTU=; b=fpBKKiRtClD/vYrxNTGZQEo2fGZbqdq3miKf1Z5lliQWLwejnHZpeR/2j4SL4GHFLQ i7ULt9hc0yo4hHfa/LnubQew1+YiaoxPs1Zd1kWo0HL6fH0LIS9nl29Wv4jv0P/nfYL3 2Uq+82wsmMut3Ydrw3gp3JH3GgMAO+2Egy7dM= MIME-Version: 1.0 Received: by 10.101.63.5 with SMTP id q5mr2180832ank.140.1316174465151; Fri, 16 Sep 2011 05:01:05 -0700 (PDT) Received: by 10.100.120.20 with HTTP; Fri, 16 Sep 2011 05:01:04 -0700 (PDT) In-Reply-To: <4E72DCD9.2040006@sv.cmu.edu> References: <201109151947.p8FJlQCH008049@fs4113.wdf.sap.corp> <8B4D8904-2FC4-4808-A99E-FCCA07972F61@vpnc.org> <01BDF4B9-9180-47BF-8BA6-0FCBA68488EF@vpnc.org> <4E72DCD9.2040006@sv.cmu.edu> Date: Fri, 16 Sep 2011 07:01:04 -0500 Message-ID: From: Phillip Hallam-Baker To: Zack Weinberg Content-Type: multipart/alternative; boundary=001636eee26d75319204ad0dbfb8 Cc: dane@ietf.org Subject: Re: [dane] #31: Multiple TLSA records in a response 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, 16 Sep 2011 11:58:52 -0000 --001636eee26d75319204ad0dbfb8 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Sep 16, 2011 at 12:21 AM, Zack Weinberg wrote: > On 2011-09-15 7:44 PM, Phillip Hallam-Baker wrote: > >> It is appropriate for a protocol standard to define when a security >> policy violation (e.g. against a DANE record) has occurred and state the >> consequences. Mandating a particular response is not appropriate. >> > > Mandating client behavior is the only way to avoid lack of > interoperability. In this case, mandating hard failure is also the only way > this spec does any damn good relative to the status quo, security-wise. That is simply not true. The mandate is to BREAK. Explain which parties will not be able to function as a result of the client rather than the domain name holder making the choice. > It is highly unlikely that browser implementations are going to get >> comfortable enough with DNS based security policy records to switch on >> hardfail immediately. If hardfail is mandated the likely outcome is >> going to be that the industry chooses other approaches. >> > > I do not speak for Mozilla, but I am one of the guys who might be > implementing DANE for Mozilla, and from my perspective, DANE ceases to be > worth bothering to implement if it doesn't mandate hard failure. You're > probably going to turn around and say it's perfectly within my power to code > in hard failure even if the spec doesn't mandate it, but the thing is, if > it's not a mandate, *some* browser is going to not do it, and then people > will demand that their users switch to that browser rather than fix their > sites, and the entire thing becomes worthless. > The IETF does not have the power to mandate behavior in that fashion. What you are proposing here is that the specification mandate a behavior so that Microsoft, Google etc. are required to comply with your policy decision. That is not how the IETF works. When it has attempted to make such calls in the past the vendors have simply ignored them. As a result we now have firewalls. When the IETF has overstepped the mandate the vendors are willing to allow it they have formed alternative forums. I was involved in the formation of W3C and OASIS, I saw the politics there first hand. The problem you identify with 'interoperability' applies equally to the decision to deploy DANE in the first place. You will find it very hard to get your management to agree to deploy a DANE unless all the other browser vendors are considering it. Some years ago the industry was pretty much willing to follow Microsoft's lead on this type of issue and Microsoft was willing to be the leader. Over the past five years they have been much less willing to lead and no other company has stepped up to take that role. In other regards, I mostly don't care what we have to do to avoid treading > on the TLS and PKIX working groups' toes -- but I will fight tooth and nail > for that one MUST. Even if the result of doing so was that there were no compliant implementations? The IETF is not a process where a group of random people get together and decide what to order the vendors what to do. -- Website: http://hallambaker.com/ --001636eee26d75319204ad0dbfb8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Sep 16, 2011 at 12:21 AM, Zack W= einberg <z= ack.weinberg@sv.cmu.edu> wrote:
On 2011-09-15 7:44 PM, Phillip Hallam-Baker wrote:
It is appropriate for a protocol standard to define when a security
policy violation (e.g. against a DANE record) has occurred and state the consequences. Mandating a particular response is not appropriate.

Mandating client behavior is the only way to avoid lack of interoperability= . =A0In this case, mandating hard failure is also the only way this spec do= es any damn good relative to the status quo, security-wise.

That is simply not true.=A0

Th= e mandate is to BREAK. Explain which parties will not be able to function a= s a result of the client rather than the domain name holder making the choi= ce.

=A0
It is highly unlikely that browser implementations are going to get
comfortable enough with DNS based security policy records to switch on
hardfail immediately. If hardfail is mandated the likely outcome is
going to be that the industry chooses other approaches.

I do not speak for Mozilla, but I am one of the guys who might be implement= ing DANE for Mozilla, and from my perspective, DANE ceases to be worth both= ering to implement if it doesn't mandate hard failure. You're proba= bly going to turn around and say it's perfectly within my power to code= in hard failure even if the spec doesn't mandate it, but the thing is,= if it's not a mandate, *some* browser is going to not do it, and then = people will demand that their users switch to that browser rather than fix = their sites, and the entire thing becomes worthless.

The IETF does not have the power to mandat= e behavior in that fashion.

What you are proposing= here is that the specification mandate a behavior so that Microsoft, Googl= e etc. are required to comply with your policy decision.

That is not how the IETF works. When it has attempted t= o make such calls in the past the vendors have simply ignored them. As a re= sult we now have firewalls.

When the IETF has over= stepped the mandate the vendors are willing to allow it they have formed al= ternative forums. I was involved in the formation of W3C and OASIS, I saw t= he politics there first hand.=A0


The problem you identify with 'inter= operability' applies equally to the decision to deploy DANE in the firs= t place. You will find it very hard to get your management to agree to depl= oy a DANE unless all the other browser vendors are considering it.=A0

Some years ago the industry was pretty much willing to = follow Microsoft's lead on this type of issue and Microsoft was willing= to be the leader. Over the past five years they have been much less willin= g to lead and no other company has stepped up to take that role.=A0


In other regards, I mostly don't care what we have to do to avoid tread= ing on the TLS and PKIX working groups' toes -- but I will fight tooth = and nail for that one MUST.

=A0Even if the = result of doing so was that there were no compliant implementations?

The IETF is not a process where a group of random peopl= e get together and decide what to order the vendors what to do.
=

--
Website: http://h= allambaker.com/

--001636eee26d75319204ad0dbfb8-- From jakob@kirei.se Fri Sep 16 05:48:19 2011 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 0372021F8BA6 for ; Fri, 16 Sep 2011 05:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.644 X-Spam-Level: X-Spam-Status: No, score=-0.644 tagged_above=-999 required=5 tests=[AWL=0.054, 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 h2tB2VuDVbBf for ; Fri, 16 Sep 2011 05:48:18 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id B87D521F8B7E for ; Fri, 16 Sep 2011 05:48:17 -0700 (PDT) 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=wjZbWI23o0s6j0R5aFjKsBkX3kqBFhikU0uLhfxet7k=; b=LpIOxsFYP2OVDSTQH74t1XIcGIHodUFw22pZ7bhNv8N4sR29xHWI+boy9UtAuDzF72Ppouc96szSS fZut6X2O1R7uN5t0+GPb0pjIzllBGOxvDq6GfDYxNwY8idMlqgBEYhiR0mQrStFSXD1L60QnLyEViD 7ZC+UZ5JlooVeF/k= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Fri, 16 Sep 2011 14:50:28 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Jakob Schlyter In-Reply-To: Date: Fri, 16 Sep 2011 14:50:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4280E58A-A78C-4F7B-A51D-AE9688A5A13A@kirei.se> References: <201109151947.p8FJlQCH008049@fs4113.wdf.sap.corp> <8B4D8904-2FC4-4808-A99E-FCCA07972F61@vpnc.org> <21FEC5AD-359E-477D-BD58-5D8925849E31@kirei.se> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1244.3) Cc: DANE WG Subject: Re: [dane] #31: Multiple TLSA records in a response 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, 16 Sep 2011 12:48:19 -0000 Phil, If you do not agree with the current semantics of TLSA (which implements = restriction only), I suggest you provide some proposed changes (i.e., = text for the draft) so we can discuss that. jakob From pgut001@login01.cs.auckland.ac.nz Fri Sep 16 06:26:13 2011 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 0413C21F8C1B for ; Fri, 16 Sep 2011 06:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.568 X-Spam-Level: X-Spam-Status: No, score=-3.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 gWnk0OCI505d for ; Fri, 16 Sep 2011 06:26:11 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA9021F8C16 for ; Fri, 16 Sep 2011 06:26:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1316179706; x=1347715706; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20hallam@gmail.com,=20jakob@kirei.se|Subject:=20Re: =20[dane]=20#31:=20Multiple=20TLSA=20records=20in=20a=20r esponse|Cc:=20dane@ietf.org|In-Reply-To:=20 |Message-Id:=20|Date:=20Sat,=2017=20Sep=202011=2001:28:17=20+1200; bh=VXFIMnVmYSkXDiOSGBdc4F2zi5xP7S0oWg55aV66ODs=; b=HuIKi7+oGObtuwPWHBvmYMNAUl/WfJcrhQE+i4aYU7ZSTmwCVtmt6TL1 a/BBTDC3h/6DErI1qqbxKaOTD1NjLGH2pZ5n/1Xxe0XA30CyFrPzUXdrU 2LexQCln2qD+tt2ar297k3T9dP8NBfTKnWi1xzwMaS29rQ282qkDwI+hj 0=; X-IronPort-AV: E=Sophos;i="4.68,393,1312113600"; d="scan'208";a="84023093" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 17 Sep 2011 01:28:17 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1R4YSn-0001ue-Hj; Sat, 17 Sep 2011 01:28:17 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1R4YSn-00074T-Eg; Sat, 17 Sep 2011 01:28:17 +1200 From: Peter Gutmann To: hallam@gmail.com, jakob@kirei.se In-Reply-To: Message-Id: Date: Sat, 17 Sep 2011 01:28:17 +1200 Cc: dane@ietf.org Subject: Re: [dane] #31: Multiple TLSA records in a response 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, 16 Sep 2011 13:26:13 -0000 Phillip Hallam-Baker writes: >On Fri, Sep 16, 2011 at 3:25 AM, Jakob Schlyter wrote: > On 15 sep 2011, at 23:36, Phillip Hallam-Baker wrote: >> > For me, DANE does X! >> >> Well, for me, DANE does Y! > > That is simply not true. As far as I can tell, DANE was always sold as magic pixie dust, with the colour of dust varying depending on who was doing the selling (or buying). The only consistent part of the sales pitch was "DANE is not PKIX". Perhaps if everyone could agree on that point, we can then each choose our own preferred colour of dust. I choose fine red dust, the consistency of talcum powder. Peter. From hallam@gmail.com Fri Sep 16 09:40:57 2011 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 DECA821F8C28 for ; Fri, 16 Sep 2011 09:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 z9KYZJGhWcfW for ; Fri, 16 Sep 2011 09:40:57 -0700 (PDT) Received: from mail-vw0-f51.google.com (mail-vw0-f51.google.com [209.85.212.51]) by ietfa.amsl.com (Postfix) with ESMTP id 47DE221F8B87 for ; Fri, 16 Sep 2011 09:40:57 -0700 (PDT) Received: by vws20 with SMTP id 20so6260246vws.24 for ; Fri, 16 Sep 2011 09:43:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:references:from:content-transfer-encoding:content-type :in-reply-to:message-id:date:cc:to:mime-version:x-mailer; bh=FzXNkbV82VR2eyBWsomv1PbGhKwtL7jkfQI/Yivhhgk=; b=tjzTGg5Bi92P8xsx/9lzzA0LV45DmN/4pj/2N8jvC5OSRIRs8tAtl/zSpMzWnB3X8K aSkgeRRvnVGaFQzAms8y/+ZWtG9k2K2kNGJVnR1G67jyBoo3/RtyL86vSCL+i4N8aro0 PoVBjH+QfBGLhtCCZ1FuzK1eJ4ZKo/yQS8/2c= Received: by 10.52.92.77 with SMTP id ck13mr1279097vdb.73.1316191392039; Fri, 16 Sep 2011 09:43:12 -0700 (PDT) Received: from [10.78.90.232] (mobile-198-228-198-043.mycingular.net. [198.228.198.43]) by mx.google.com with ESMTPS id bp4sm7832579vdc.0.2011.09.16.09.43.08 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 16 Sep 2011 09:43:10 -0700 (PDT) References: <201109151947.p8FJlQCH008049@fs4113.wdf.sap.corp> <8B4D8904-2FC4-4808-A99E-FCCA07972F61@vpnc.org> <21FEC5AD-359E-477D-BD58-5D8925849E31@kirei.se> <4280E58A-A78C-4F7B-A51D-AE9688A5A13A@kirei.se> From: Phillip Hallam-Baker Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii In-Reply-To: <4280E58A-A78C-4F7B-A51D-AE9688A5A13A@kirei.se> Message-Id: Date: Fri, 16 Sep 2011 11:02:11 -0500 To: Jakob Schlyter Mime-Version: 1.0 (iPad Mail 8L1) X-Mailer: iPad Mail (8L1) Cc: DANE WG Subject: Re: [dane] #31: Multiple TLSA records in a response 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, 16 Sep 2011 16:40:58 -0000 Remove the MUST abort the connection and replace with 'a DANE security polic= y violation has been detected. Then add a section headed "responding to a DANE security protocol violation"= and first state the consequeces (either the security policy statement is in= error or the channel is compromised) and list the possible client responses= These include : * abort the connection * notify some party that the violation has been detected * continue with indication that connection is compromised At the moment we do not even have hardfail for expired certs, let alone revo= ked. There is a much higher chance of having abort respected if it is an idepende= nt option. But even then it is something the CAs have been asking for for fi= fteen years, something most of the security guys at the browsers would likel= y do if it was their sole choice. But it is not an argument the ultimate dec= ision makers are likely to accept even now. If we had had hardfail on revoked certs there would not have been a relying p= arty issue with the first breach. So why is there this pretense that the onl= y part of the system that is at fault here are the CAs? Sure that is what we= signed up for, but that does not change the fact that the significant chang= e you are proposing here is in the BROWSER security model, the change to har= dfail.=20 The second breach resulted in the CA concerned being shut down completely. I= don't know what VASCO paid but they almost certainly took at least a five t= o ten million dollar hit.=20 It is OK to beat on CAs. That is what we signed up for. I do not see ICANN s= igning up for the same program. Who is going to respond when this new mouset= rap you are proposing also fails? Not ICANN, that is for sure. The only part= y with really solid crypto background is VeriSign and some of the other top t= ier registries. But their business model is thin registry. The parts of the s= ystem that are responsible for customer management are the registrars. And t= hey get their crypto management input from the CAs. Who audits this mousetrap? If you dont think you need audits then you don't u= nderstand the problem. Not that auditors are a panacea, they dont guaratee c= ompliance with policy, the policy may be inadequate. But if you dont have au= ditors you can guarantee that your policy is going to be breached. Contrary to what some here think. DANE does not change the model. You merely= force a game of musical chairs on everyone and the result would be a system= that is more complex and has more points of failure.=20 Sent from my iPad On Sep 16, 2011, at 7:50, Jakob Schlyter wrote: > Phil, >=20 > If you do not agree with the current semantics of TLSA (which implements r= estriction only), I suggest you provide some proposed changes (i.e., text fo= r the draft) so we can discuss that. >=20 > jakob >=20 From hallam@gmail.com Fri Sep 16 09:41:02 2011 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 D804621F8C78 for ; Fri, 16 Sep 2011 09:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 PXPnE0cmIBm8 for ; Fri, 16 Sep 2011 09:41:02 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1411221F8C72 for ; Fri, 16 Sep 2011 09:41:01 -0700 (PDT) Received: by eye4 with SMTP id 4so2184156eye.31 for ; Fri, 16 Sep 2011 09:43:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:references:cc:from:content-type:in-reply-to:message-id:date :to:content-transfer-encoding:mime-version:x-mailer; bh=aE1SfjBV0DNO7locun3RQQZWBd7GHr9gp4JciqGULlk=; b=h/S+6EfLuNJBmkQCumaLeje88EkjOdt7TpTdE6jR2iAk+/GTSBiSiHhqGhhq0L3dpZ H1XAONpEZAWMbbLVFYTF4zW6jeOEgU/EPTnrPpuiO/hBECJ3mzqEKHekV32DKi31bnv+ f937HkgHYX3Sd3NkoI8WxPoaNpaxO2HFmpJLk= Received: by 10.52.172.202 with SMTP id be10mr1405928vdc.47.1316191396176; Fri, 16 Sep 2011 09:43:16 -0700 (PDT) Received: from [10.78.90.232] (mobile-198-228-198-043.mycingular.net. [198.228.198.43]) by mx.google.com with ESMTPS id bp4sm7832579vdc.0.2011.09.16.09.43.12 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 16 Sep 2011 09:43:14 -0700 (PDT) References: From: Phillip Hallam-Baker Content-Type: text/plain; charset=us-ascii In-Reply-To: Message-Id: <818B5737-219C-4950-8FA5-5B244BF7F692@gmail.com> Date: Fri, 16 Sep 2011 10:22:20 -0500 To: Peter Gutmann Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (iPad Mail 8L1) X-Mailer: iPad Mail (8L1) Cc: "dane@ietf.org" Subject: Re: [dane] #31: Multiple TLSA records in a response 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, 16 Sep 2011 16:41:03 -0000 That is not my choice. Glimore wants us to swap the old pixie dust for some new dust.=20 I want to have a layer of the new dust on top of the old. Those are very different approches. Gilmore is arguing that the respose to t= he breach should be to throw away the system we have built over the past twe= nty years and replace it with a new syntax and a design that merely replaces= one set of trust providers with another set that have not even comitted to p= rovide third party trust services. We do not know the failure modes of the ICANN-DANE trust system yet. We do k= now that they are going to face the same risks, what we do not yet know is w= hat the threats will be. I don't think I am the only person who will object t= o the idea of responding to a breach with a leap into the unknown. This is going to be a high wire tight rope act however it is done and whoeve= r does it. It seems a lot easier until you try it. You can suggest changing t= he performer, but who do you think is going to listen? Better to build a net= . Or several nets. Heck half of you here accused me of hype and scaremongering when I said the t= hreat came from the Iranian government. Anyone still want to argue that we s= hould believe TehranBob on this? If so how did TehranBob redirect the entire= Iranian Internet as well? How come he isn't dacing on the end of a crane fo= r doing so? How could the Iranian govt know he isn't Mossad or CIA? The claim that there are 600 cas is not true. There are 600 RAs of which onl= y about 20 were public RAs. The issue that seems to have allowed them to avo= id audit was that there was no distinction made between a validating RA (bei= ng essentially a public CA minus signing) an an enterprise RA.=20 This is being fixed. I expect that the browser providers will be requiring a= udits of all validating RAs. This will probably mean that validating RAs dis= appear completely as it appears that the audit was a bigger deterrent to bec= oming a CA than the signing part. But it is still a fact that there was never 600 places you could go to get a= cert for an arbitrary domain. One thing that this dicussion has raised is that the CA world should probabl= y invite the DNS people to some of the meetings we are having to discuss the= attacks and the response. Sent from my iPad On Sep 16, 2011, at 8:28, Peter Gutmann wrote: > Phillip Hallam-Baker writes: >> On Fri, Sep 16, 2011 at 3:25 AM, Jakob Schlyter wrote: >> On 15 sep 2011, at 23:36, Phillip Hallam-Baker wrote: >>>> For me, DANE does X! >>>=20 >>> Well, for me, DANE does Y! >>=20 >> That is simply not true. >=20 > As far as I can tell, DANE was always sold as magic pixie dust, with the=20= > colour of dust varying depending on who was doing the selling (or buying).= =20 > The only consistent part of the sales pitch was "DANE is not PKIX". Perha= ps=20 > if everyone could agree on that point, we can then each choose our own=20 > preferred colour of dust. I choose fine red dust, the consistency of talc= um > powder. >=20 > Peter. From paul@xelerance.com Fri Sep 16 09:57:50 2011 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 0268621F8B87 for ; Fri, 16 Sep 2011 09:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.493 X-Spam-Level: X-Spam-Status: No, score=-6.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 xHWm8SfnYL8J for ; Fri, 16 Sep 2011 09:57:49 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id D590D21F8B7E for ; Fri, 16 Sep 2011 09:57:48 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id CC924572ED; Fri, 16 Sep 2011 12:57:56 -0400 (EDT) Date: Fri, 16 Sep 2011 12:57:56 -0400 (EDT) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <201109151947.p8FJlQCH008049@fs4113.wdf.sap.corp> <8B4D8904-2FC4-4808-A99E-FCCA07972F61@vpnc.org> <21FEC5AD-359E-477D-BD58-5D8925849E31@kirei.se> <4280E58A-A78C-4F7B-A51D-AE9688A5A13A@kirei.se> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: DANE WG Subject: Re: [dane] #31: Multiple TLSA records in a response 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, 16 Sep 2011 16:57:50 -0000 On Fri, 16 Sep 2011, Phillip Hallam-Baker wrote: > The second breach resulted in the CA concerned being shut down completely. I don't know what VASCO paid but they almost certainly took at least a five to ten million dollar hit. This comment implies that the current CA system is good and free market ideals are the right governing system here, and bad CAs will lose money and die out, and good CAs make money and remain. Unforutnately, we do not know how many Iranians have been arrested, tortured or murdered based on Diginotar's and PriveWaterhouseCoopers negligence. And the free market will never take those lives into account. In fact, we don't even know if these things happened in the past WITHOUT any market punishment, because people simple did not know CAs were compromised. It is only thanks to Adam Langley and the Google Chrome people that we know this now. This is no longer your mothers playground. We're talking about lives, not money. > Who audits this mousetrap? > Contrary to what some here think. DANE does not change the model. You merely force a game of musical chairs on everyone and the result would be a system that is more complex and has more points of failure. Mostly, the individual companies involved. On top of them, the Registrars and the Registry. That's a whole lot less then in the CA model. I'm sure we will see DNS hacks, Registrar and Registry compromises. DANE is not the silver bullet, but the CA system is shooting soap bubbles. > Sent from my iPad Ironically, sent from a device that still has Diginoar's certificate on it. (AFAIK only OSX got the updates, not iOS) Paul From mrex@sap.com Fri Sep 16 14:33:30 2011 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 6162921F8D1A for ; Fri, 16 Sep 2011 14:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.027 X-Spam-Level: X-Spam-Status: No, score=-10.027 tagged_above=-999 required=5 tests=[AWL=0.222, 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 7JZPNOTHRdyg for ; Fri, 16 Sep 2011 14:33:30 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id A200621F8D17 for ; Fri, 16 Sep 2011 14:33:29 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p8GLZcJs003773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Sep 2011 23:35:43 +0200 (MEST) From: Martin Rex Message-Id: <201109162135.p8GLZb5s004573@fs4113.wdf.sap.corp> To: zack.weinberg@sv.cmu.edu (Zack Weinberg) Date: Fri, 16 Sep 2011 23:35:37 +0200 (MEST) In-Reply-To: <4E72DCD9.2040006@sv.cmu.edu> from "Zack Weinberg" at Sep 15, 11 10:21:29 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] #31: Multiple TLSA records in a response 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, 16 Sep 2011 21:33:30 -0000 Zack Weinberg wrote: > > In other regards, I mostly don't care what we have to do to avoid > treading on the TLS and PKIX working groups' toes -- but I will fight > tooth and nail for that one MUST. I prefer a "MUST (by default)" (or MUST ... UNLESS) to SHOUld, e.g. something like the current scary page in Web Browsers for PKIX server cert validation failures, but that still provides the user an option to override. An unconditional MUST would not make sense in combination with optional TLSA types that clients not implementing them will simply ignore (falling back to traditional PKIX server cert validation and server endpoint identification). -Martin From gnu@toad.com Sat Sep 17 16:00:07 2011 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 56D2321F86A4 for ; Sat, 17 Sep 2011 16:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.397 X-Spam-Level: * X-Spam-Status: No, score=1.397 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, RCVD_IN_NJABL_RELAY=2.696] 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 BHkwJCQc9jXc for ; Sat, 17 Sep 2011 16:00:06 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id E15E221F8678 for ; Sat, 17 Sep 2011 16:00:06 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id p8HN2MQs004813 for ; Sat, 17 Sep 2011 16:02:22 -0700 Message-Id: <201109172302.p8HN2MQs004813@new.toad.com> To: "dane@ietf.org" In-reply-to: <818B5737-219C-4950-8FA5-5B244BF7F692@gmail.com> References: <818B5737-219C-4950-8FA5-5B244BF7F692@gmail.com> Comments: In-reply-to Phillip Hallam-Baker message dated "Fri, 16 Sep 2011 10:22:20 -0500." Date: Sat, 17 Sep 2011 16:02:22 -0700 From: John Gilmore Subject: Re: [dane] #31: Multiple TLSA records in a response 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, 17 Sep 2011 23:00:07 -0000 > Gilmore is arguing that the respose to the breach should be to throw > away the system we have built over the past twenty years and replace > it with a new syntax and a design that merely replaces one set of > trust providers with another set that have not even comitted to > provide third party trust services. That's quite a run-on sentence. Let's see: Gilmore is arguing that the main failing of the CA system is that it allows ANY CA, worldwide, to subvert the security of ANY "secure" website by aiding an undetected MITM attack. DNSSEC/DANE limits the number of parties who can do that, to only the website's domain providers. It's along the lines of "put all your eggs in one basket, and guard that basket well". Gilmore is arguing that domain name users (including all web sites) must already trust their domain registrar and domain registry. Either of those parties could trivially aid in a MITM attack, merely by changing the "NS" or "A" records of the domain. So far we have only seen minimal attacks of this sort (mostly perpetuated by government agencies and courts, acting as censors, in the open, and with legitimate avenues of appeal to higher courts). If in general, domain registrars and registries cannot be trusted, the CA system is fatally broken too, since it too depends on domain names. > The claim that there are 600 cas is not true. There are 600 RAs of > which only about 20 were public RAs. ... But it is still a fact > that there was never 600 places you could go to get a cert for an > arbitrary domain. What is implied here is that only about 20 places could provide false keying material for any arbitrary website (e.g. "google.com"). That implication, I believe, is false; 600 could. What he actually seems to have said is that you can only ASK 20 of them to do so through a public interface (like their website). But I believe that if you break into them, or subvert their employees through bribery, blackmail, physical coercion, etc, any of the 600 are capable of providing false keying material for any website. If software authors of TLS-based programs, like browsers, are preparing to stop trusting 580 of those key-certifiers, then that's a positive step, but it's no reason to abandon the DANE effort. John From hallam@gmail.com Sat Sep 17 21:08:42 2011 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 558E211E807F for ; Sat, 17 Sep 2011 21:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.473 X-Spam-Level: X-Spam-Status: No, score=-3.473 tagged_above=-999 required=5 tests=[AWL=0.125, 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 vh+Kgpbl2SXP for ; Sat, 17 Sep 2011 21:08:41 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 24B9811E8073 for ; Sat, 17 Sep 2011 21:08:41 -0700 (PDT) Received: by yxt33 with SMTP id 33so4280494yxt.31 for ; Sat, 17 Sep 2011 21:11:00 -0700 (PDT) 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=bOLFhWTa080U0eLDR2rfWzFZUwOCYPJc1NEXtQ46SQw=; b=pZASr7Ai7I+m6OUsHdW6WghT2GjadA9J35D0MulysrPZvSjaqmArmL5x0Zvdmo07Bi wcVtvZyBTSoIQWDD/usLlEb1YDR+pftlivz5xw0U0bEfGGt6+6wDjQ6Tdl71tbJdY3B+ L3manufVdyv9BeShaoWy6KcwWEL4DlWN1gjLE= MIME-Version: 1.0 Received: by 10.101.27.34 with SMTP id e34mr982338anj.162.1316319060019; Sat, 17 Sep 2011 21:11:00 -0700 (PDT) Received: by 10.100.120.20 with HTTP; Sat, 17 Sep 2011 21:10:59 -0700 (PDT) In-Reply-To: <201109172302.p8HN2MQs004813@new.toad.com> References: <818B5737-219C-4950-8FA5-5B244BF7F692@gmail.com> <201109172302.p8HN2MQs004813@new.toad.com> Date: Sun, 18 Sep 2011 00:10:59 -0400 Message-ID: From: Phillip Hallam-Baker To: John Gilmore Content-Type: multipart/alternative; boundary=001636b2b893fbc92e04ad2f6908 Cc: "dane@ietf.org" Subject: Re: [dane] #31: Multiple TLSA records in a response 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, 18 Sep 2011 04:08:42 -0000 --001636b2b893fbc92e04ad2f6908 Content-Type: text/plain; charset=ISO-8859-1 That is quite a lot of wild claims. You clearly don't understand what the capabilities of the RAs in question are. You keep repeating an assertion that is false, so why on earth should the Internet trust you? On Sat, Sep 17, 2011 at 7:02 PM, John Gilmore wrote: > > Gilmore is arguing that the respose to the breach should be to throw > > away the system we have built over the past twenty years and replace > > it with a new syntax and a design that merely replaces one set of > > trust providers with another set that have not even comitted to > > provide third party trust services. > > That's quite a run-on sentence. Let's see: > > Gilmore is arguing that the main failing of the CA system is that it > allows ANY CA, worldwide, to subvert the security of ANY "secure" > website by aiding an undetected MITM attack. DNSSEC/DANE limits the > number of parties who can do that, to only the website's domain > providers. It's along the lines of "put all your eggs in one > basket, and guard that basket well". > > Gilmore is arguing that domain name users (including all web sites) > must already trust their domain registrar and domain registry. Either > of those parties could trivially aid in a MITM attack, merely by > changing the "NS" or "A" records of the domain. So far we have only > seen minimal attacks of this sort (mostly perpetuated by government > agencies and courts, acting as censors, in the open, and with > legitimate avenues of appeal to higher courts). If in general, domain > registrars and registries cannot be trusted, the CA system is fatally > broken too, since it too depends on domain names. > > > The claim that there are 600 cas is not true. There are 600 RAs of > > which only about 20 were public RAs. ... But it is still a fact > > that there was never 600 places you could go to get a cert for an > > arbitrary domain. > > What is implied here is that only about 20 places could provide false > keying material for any arbitrary website (e.g. "google.com"). That > implication, I believe, is false; 600 could. > > What he actually seems to have said is that you can only ASK 20 of > them to do so through a public interface (like their website). But I > believe that if you break into them, or subvert their employees > through bribery, blackmail, physical coercion, etc, any of the 600 > are capable of providing false keying material for any website. > > If software authors of TLS-based programs, like browsers, are > preparing to stop trusting 580 of those key-certifiers, then that's a > positive step, but it's no reason to abandon the DANE effort. > > John > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > -- Website: http://hallambaker.com/ --001636b2b893fbc92e04ad2f6908 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That is quite a lot of wild claims.

You clearly don'= t understand what the capabilities of the RAs in question are. You keep rep= eating an assertion that is false, so why on earth should the Internet trus= t you?





On Sat, Sep 17, 2011 at 7:02 PM, John Gilmore <gnu@toad.com> w= rote:
> Gilmore is arguing t= hat the respose to the breach should be to throw
> away the system we have built over the past twenty years and replace > it with a new syntax and a design that merely replaces one set of
> trust providers with another set that have not even comitted to
> provide third party trust services.

That's quite a run-on sentence. =A0Let's see:

Gilmore is arguing that the main failing of the CA system is that it
allows ANY CA, worldwide, to subvert the security of ANY "secure"=
website by aiding an undetected MITM attack. =A0DNSSEC/DANE limits the
number of parties who can do that, to only the website's domain
providers. =A0It's along the lines of "put all your eggs in one basket, and guard that basket well".

Gilmore is arguing that domain name users (including all web sites)
must already trust their domain registrar and domain registry. =A0Either of those parties could trivially aid in a MITM attack, merely by
changing the "NS" or "A" records of the domain. =A0So f= ar we have only
seen minimal attacks of this sort (mostly perpetuated by government
agencies and courts, acting as censors, in the open, and with
legitimate avenues of appeal to higher courts). =A0If in general, domain registrars and registries cannot be trusted, the CA system is fatally
broken too, since it too depends on domain names.

> The claim that there are 600 cas is not true. There are 600 RAs of
> which only about 20 were public RAs. =A0... =A0But it is still a= fact
> that there was never 600 places you could go to get = a cert for an
> arbitrary domain.

What is implied here is that only about 20 places could provide false=
keying material for any arbitrary website (e.g. "google.com"). =A0That
implication, I believe, is false; 600 could.

What he actually seems to have said is that you can only ASK 20 of
them to do so through a public interface (like their website). =A0But I
believe that if you break into them, or subvert their employees
through bribery, blackmail, physical coercion, etc, any of the 600
are capable of providing false keying material for any website.

If software authors of TLS-based programs, like browsers, are
preparing to stop trusting 580 of those key-certifiers, then that's a positive step, but it's no reason to abandon the DANE effort.

=A0 =A0 =A0 =A0John
__________________________________= _____________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane



--
= Website: http://hallambaker.com/
--001636b2b893fbc92e04ad2f6908-- From ahu@xs.powerdns.com Sun Sep 18 11:21:55 2011 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 8B08C21F84FC for ; Sun, 18 Sep 2011 11:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.664 X-Spam-Level: X-Spam-Status: No, score=-0.664 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_20=-0.74, 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 2ejdOO2XPzC2 for ; Sun, 18 Sep 2011 11:21:54 -0700 (PDT) Received: from xs.powerdns.com (xs.powerdns.com [IPv6:2001:888:2000:1d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 560B621F8512 for ; Sun, 18 Sep 2011 11:21:54 -0700 (PDT) Received: from ahu by xs.powerdns.com with local (Exim 4.71) (envelope-from ) id 1R5M2H-0002S3-3Q for dane@ietf.org; Sun, 18 Sep 2011 20:24:13 +0200 Date: Sun, 18 Sep 2011 20:24:13 +0200 From: bert hubert To: dane@ietf.org Message-ID: <20110918182412.GA8893@xs.powerdns.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [dane] hi & dane trac broken? 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, 18 Sep 2011 18:21:55 -0000 Hi everybody, At this late stage I'm joining the DANE mailing list. PowerDNS Authoritative 3.0 has some experimental support for an earlier draft of DANE, I hope that by the time 3.1 has arrived we can support the RFC or something close to it! One small thing, I was trying to go through the open issues on the 'trac', but I get an error about looping url's, for example on http://trac.tools.ietf.org/wg/dane/trac/ticket/25 I hope this can be resolved. I was tangentially involved with several CA breakin investigations, and while I'm unable to share anything about those investigations, I can safely say that I'm more than ever convinced that we need DANE, and that we need it quickly. I will also be addressing the Dutch Govcert symposium 2011 to this effect on the 15th or the 16th of November, http://www.govcert.nl/symposium If there is anything specific I could do to help speed things up, please let me know. Bert -- PowerDNS Website: http://www.powerdns.com/ PowerDNS Community Website: http://wiki.powerdns.com/ From paul.hoffman@vpnc.org Sun Sep 18 12:55:32 2011 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 1E55421F86F6 for ; Sun, 18 Sep 2011 12:55:32 -0700 (PDT) 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 As-5azOINFFm for ; Sun, 18 Sep 2011 12:55:31 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9642F21F86EE for ; Sun, 18 Sep 2011 12:55:31 -0700 (PDT) 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 p8IJv1bq076543 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 18 Sep 2011 12:57:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20110918182412.GA8893@xs.powerdns.com> Date: Sun, 18 Sep 2011 12:57:52 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <20110918182412.GA8893@xs.powerdns.com> To: bert hubert X-Mailer: Apple Mail (2.1244.3) Cc: dane@ietf.org Subject: Re: [dane] hi & dane trac broken? 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, 18 Sep 2011 19:55:32 -0000 > One small thing, I was trying to go through the open issues on the 'trac', > but I get an error about looping url's, for example on > http://trac.tools.ietf.org/wg/dane/trac/ticket/25 I have now reported this to the IETF Tools Team. --Paul Hoffman From ondrej.sury@nic.cz Mon Sep 19 00:08:14 2011 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 EB83E21F8B6F for ; Mon, 19 Sep 2011 00:08:14 -0700 (PDT) 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 qdPqCTHCqtit for ; Mon, 19 Sep 2011 00:08:14 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 44B5721F8B4A for ; Mon, 19 Sep 2011 00:08:13 -0700 (PDT) Received: from kimac.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id DED5F2A2D4B; Mon, 19 Sep 2011 09:10:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1316416232; bh=1DQOWWOnMWS/hh7pS4IypR+hg4XQu6lWdeqHCGQkTT0=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=R1wKimEP5moAKm/VpPmBhP7706uiYRE2Wxt8UBrd51m9aQCq/bpSmvW4YFrIlXFcA DwwT+go10Ynq83V+av5deQ0LXnpUByF5H1QRXfZDn3cE48d/MuYdwFjmYVBaI97+BQ IcTMothriOkk2Vjenkyi/SvHmFQWU/DxKh8ofvpA= Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: Date: Mon, 19 Sep 2011 09:10:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <818B5737-219C-4950-8FA5-5B244BF7F692@gmail.com> <201109172302.p8HN2MQs004813@new.toad.com> To: Phillip Hallam-Baker , Paul Wouters X-Mailer: Apple Mail (2.1244.3) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane-ads@tools.ietf.org, DANE WG Subject: Re: [dane] #31: Multiple TLSA records in a response 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, 19 Sep 2011 07:08:15 -0000 Hi all, could we please get back to technical discussion? The discussion seem to get very hot and personal, please could we _all_ try to stick with the problems opened in this thread (I would=20 like to fill them as separate issues) and not discuss CAs, RAs, Iran and other political and human rights stuff? We (Warren did) already asked our ADs (Ccing them again just to be sure) if we are overstepping our charter here, so let's wait if they respond. With my chair hat on, I don't think so, but their opinion may differ and it doesn't make sense to reiterate the arguments before we have = their opinion. I don't think this discussion helps any progress of the DANE protocol, so if we can stop it now and here (in the mailing list) I would really appreciate that. Thank you, -- 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 Mon Sep 19 00:13:58 2011 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 8E00521F8A66 for ; Mon, 19 Sep 2011 00:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.211 X-Spam-Level: X-Spam-Status: No, score=-0.211 tagged_above=-999 required=5 tests=[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 JezhgPIn0zHZ for ; Mon, 19 Sep 2011 00:13:58 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 2096221F8ADC for ; Mon, 19 Sep 2011 00:13:51 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:41b2:7ea4:9c05:8af1] (unknown [IPv6:2001:1488:ac14:1400:41b2:7ea4:9c05:8af1]) by mail.nic.cz (Postfix) with ESMTPSA id 1B21C2A2A0C; Mon, 19 Sep 2011 09:16:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1316416573; bh=tYxKGhEadP/FlBDINkyNy162KkEk1xCTFzdHsDdZd/A=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=NuM2Usw/fR3hDEPheGAWXsr6f+d3h3T3GdWaJqU3WubVjJ0Sic3hDNWGqCoiO0e6H MyAL0GJib1+LVH3/u6p+ePqFEqvpVK2iudt8aDcLSCS9zYvdoiGF9cpcyFHRBjYNTk MviRQqHKHXx4Ml5c40eWJDb+2Ejw1ZyeCJ9yO15M= Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <201109152246.p8FMkSFG018373@fs4113.wdf.sap.corp> Date: Mon, 19 Sep 2011 09:16:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <28830E48-0508-460A-8DE4-FE157BD7ECD5@nic.cz> References: <201109152246.p8FMkSFG018373@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1244.3) 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] Reopening issue #22 for discussion.... 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, 19 Sep 2011 07:13:58 -0000 On 16. 9. 2011, at 0:46, Martin Rex wrote: > I see two possible behaviours: > (1) continue normal TLS server certificate validation and server > endpoint identification (as if there were no TLSA records) >=20 > (2) fail the DANE server cert validation, which MUST (by default) > abort the handshake/connection I think we already established that we want (1) as general behaviour. =46rom the client point of view, there's no difference between receiving unknown hash algorithm and invalid hash. 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 Mon Sep 19 00:18:47 2011 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 6FA1221F8AD1 for ; Mon, 19 Sep 2011 00:18:47 -0700 (PDT) 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=[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 7BQyfT4cCWI8 for ; Mon, 19 Sep 2011 00:18:46 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 56A8121F86A0 for ; Mon, 19 Sep 2011 00:18:46 -0700 (PDT) Received: from kimac.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 52B472A2CFC; Mon, 19 Sep 2011 09:21:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1316416868; bh=y9jxtUpmf6mlrYV9srUh+gGeYax8sUxfNOaqwf4Gnu4=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=NDpzuBBKi/41VCaxzpNlgO64Rq4YPe11765sIl3IWUL8FG37FUnkg/IjLs9DyUARM ntz4VQBsX/C3M4OpiIRszq0iwQlLM4P6n8QWWC8pju+ucYZbKjAkI34eM30wgaUu1P ktru5inyM5/zMz94IrNdZpc9PV/s7Q0bG7j6T7U8= Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <2BBD5ABC-EB88-4419-B4F3-27BA2EF093A4@gmail.com> Date: Mon, 19 Sep 2011 09:21:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9D42A033-D5C7-40D5-92BE-70DDFBBB95CA@nic.cz> References: <20110915214614.GA14586@vacation.karoshi.com.> <201109152226.p8FMQ5kV016843@fs4113.wdf.sap.corp> <4e72886d.c413440a.6897.ffffaf2eSMTPIN_ADDED@mx.google.com> <2BBD5ABC-EB88-4419-B4F3-27BA2EF093A4@gmail.com> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1244.3) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: "bmanning@vacation.karoshi.com" , "paul.hoffman@vpnc.org" , "dane@ietf.org" Subject: Re: [dane] Reopening issue #22 for discussion.... 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, 19 Sep 2011 07:18:47 -0000 Hi, I think this is a very reasonable argument and I agree with Phil here. Anyway it seems that we are sidetracking (again), so can we _all_ please stick with #22 and respond if you agree with Warren's mail: On 14. 9. 2011, at 23:52, Warren Kumari wrote: > While it may be fun, we cannot / should not specify what the strongest = digest is, and so we cannot really dictate how sides choose the = "strongest", and so client implementations will sort / choose the digest = that they believe is strongest. rephrased by Bill as: On 15. 9. 2011, at 15:19, bmanning@vacation.karoshi.com wrote: > The server can't strong arm clients. Period. (think deployed = base and then making a > change... going to upgrade everything in the field? Good Luck = w/ that) So the group decision would be that we cannot and we should not enforce = "strongest" algorithm in the DANE protocol. Please really try to respond with +1 / -1, so we can get rid of the = issue fast. O. On 16. 9. 2011, at 2:33, Phillip Hallam-Baker wrote: > I dont see it as an issue. >=20 > Chrome and Firefox both autopatch. They are the only browsers by = companies attending DANE sessions. >=20 > By the time anyone with a static browser deploys Sha3 will have been = announced. >=20 >=20 > Legacy is a real hazzard in the browser world. But not for any = mainstream browser deployed in the past four years. The IE4 or Bind = thing does not apply. >=20 > I cant imagine any group that deployed DANE being asleep on sha3 = deployment. >=20 >=20 >=20 >=20 > Sent from my iPad >=20 > On Sep 15, 2011, at 18:21, bmanning@vacation.karoshi.com wrote: >=20 >> On Fri, Sep 16, 2011 at 12:26:05AM +0200, Martin Rex wrote: >>> bmanning@vacation.karoshi.com wrote: >>>>=20 >>> SHA-256 is mandatory to implement, SHA-512 is optional. >>>=20 >>> The primary reason for hash agility is being able to switch to a >>> different algorithm at some point in the future, when SHA-256 is no >>> longer deemed adequate. >>>=20 >>> The issues you're facing: >>> - for interop with the installed base DANE clients you'll have to = continue >>> providing TLSA records with SHA-256 hashes for many years (10+) to = come >>=20 >> -if- backward interoperablity is desired, yes (30+) years if BIND = is >> any predictor. >>=20 >>> - for new DANE clients to obtain security benefit from TLSA records = with >>> a stronger hash, new DANE clients will have to ignore all records = with >>> a weaker hash as soon as they find a records with a stronger hash = (that >>> they implement) for a given server host name. >>=20 >> thats not going to fly operationally. the server s going to have = to >> cease publication of all weaker hashes - forcing clients to = upgrade. >>=20 >> thats the proven operational method. if the weaker hash exists it = will >> get used. anything else is simply gyrations and conplex code paths = in >> the client to try and figure out what the server was trying to say = by=20 >> speaking spanglish, finnish, and mayan... is there a credible = reason to >> try and burden the client code with this goofy logic? seems like = an ideal >> breeding ground for security exploits. =20 >>=20 >>> - to provide smooth migration and interop for heterogeneous = installed >>> base of old and new DANE clients, the DNS admin must provide >>> TLSA records with certificate hashes consistently for all desired >>> hash algorithms for a given server host name. >>=20 >> can I have some of what you are smoking? please? >>=20 >>>=20 >>>=20 >>> -Martin >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- 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 ietf@augustcellars.com Mon Sep 19 11:12:55 2011 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 95D2021F8C7D for ; Mon, 19 Sep 2011 11:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.001 X-Spam-Level: X-Spam-Status: No, score=-3.001 tagged_above=-999 required=5 tests=[AWL=-0.302, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, 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 k5HD8TM4ZrRw for ; Mon, 19 Sep 2011 11:12:54 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5D821F8CA0 for ; Mon, 19 Sep 2011 11:12:54 -0700 (PDT) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id E7BFD2CA27; Mon, 19 Sep 2011 11:15:12 -0700 (PDT) From: "Jim Schaad" To: =?utf-8?Q?'Ondrej_Sur=C3=BD'?= References: <20110915214614.GA14586@vacation.karoshi.com.> <201109152226.p8FMQ5kV016843@fs4113.wdf.sap.corp> <4e72886d.c413440a.6897.ffffaf2eSMTPIN_ADDED@mx.google.com> <2BBD5ABC-EB88-4419-B4F3-27BA2EF093A4@gmail.com> <9D42A033-D5C7-40D5-92BE-70DDFBBB95CA@nic.cz> In-Reply-To: <9D42A033-D5C7-40D5-92BE-70DDFBBB95CA@nic.cz> Date: Mon, 19 Sep 2011 11:52:08 -0700 Message-ID: <007401cc76fd$3e2901a0$ba7b04e0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHz34+uWFBOREXWSBGXHWbM/d0XhwG/XdPPAif7IQ4CVZ88VwF+BOxplMhjP3A= Content-Language: en-us Cc: dane@ietf.org Subject: Re: [dane] Reopening issue #22 for discussion.... 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, 19 Sep 2011 18:12:55 -0000 +1 An algorithm either is or is not strong enough - thus no ranking needed. > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf = Of > Ondrej Sur=C3=BD > Sent: Monday, September 19, 2011 12:21 AM > To: Phillip Hallam-Baker > Cc: bmanning@vacation.karoshi.com; paul.hoffman@vpnc.org; > dane@ietf.org > Subject: Re: [dane] Reopening issue #22 for discussion.... >=20 > Hi, >=20 > I think this is a very reasonable argument and I agree with Phil here. >=20 > Anyway it seems that we are sidetracking (again), so can we _all_ = please stick > with #22 and respond if you agree with Warren's mail: >=20 > On 14. 9. 2011, at 23:52, Warren Kumari wrote: > > While it may be fun, we cannot / should not specify what the = strongest > digest is, and so we cannot really dictate how sides choose the = "strongest", > and so client implementations will sort / choose the digest that they = believe > is strongest. >=20 >=20 > rephrased by Bill as: >=20 > On 15. 9. 2011, at 15:19, bmanning@vacation.karoshi.com wrote: > > The server can't strong arm clients. Period. (think deployed base = and > then making a > > change... going to upgrade everything in the field? Good Luck w/ > > that) >=20 >=20 > So the group decision would be that we cannot and we should not = enforce > "strongest" algorithm in the DANE protocol. >=20 > Please really try to respond with +1 / -1, so we can get rid of the = issue fast. >=20 > O. >=20 > On 16. 9. 2011, at 2:33, Phillip Hallam-Baker wrote: >=20 > > I dont see it as an issue. > > > > Chrome and Firefox both autopatch. They are the only browsers by > companies attending DANE sessions. > > > > By the time anyone with a static browser deploys Sha3 will have been > announced. > > > > > > Legacy is a real hazzard in the browser world. But not for any = mainstream > browser deployed in the past four years. The IE4 or Bind thing does = not > apply. > > > > I cant imagine any group that deployed DANE being asleep on sha3 > deployment. > > > > > > > > > > Sent from my iPad > > > > On Sep 15, 2011, at 18:21, bmanning@vacation.karoshi.com wrote: > > > >> On Fri, Sep 16, 2011 at 12:26:05AM +0200, Martin Rex wrote: > >>> bmanning@vacation.karoshi.com wrote: > >>>> > >>> SHA-256 is mandatory to implement, SHA-512 is optional. > >>> > >>> The primary reason for hash agility is being able to switch to a > >>> different algorithm at some point in the future, when SHA-256 is = no > >>> longer deemed adequate. > >>> > >>> The issues you're facing: > >>> - for interop with the installed base DANE clients you'll have to > >>> continue providing TLSA records with SHA-256 hashes for many = years > >>> (10+) to come > >> > >> -if- backward interoperablity is desired, yes (30+) years if BIND = is > >> any predictor. > >> > >>> - for new DANE clients to obtain security benefit from TLSA = records > >>> with a stronger hash, new DANE clients will have to ignore all > >>> records with a weaker hash as soon as they find a records with a > >>> stronger hash (that they implement) for a given server host name. > >> > >> thats not going to fly operationally. the server s going to have = to > >> cease publication of all weaker hashes - forcing clients to = upgrade. > >> > >> thats the proven operational method. if the weaker hash exists = it will > >> get used. anything else is simply gyrations and conplex code = paths in > >> the client to try and figure out what the server was trying to = say by > >> speaking spanglish, finnish, and mayan... is there a credible = reason to > >> try and burden the client code with this goofy logic? seems like = an ideal > >> breeding ground for security exploits. > >> > >>> - to provide smooth migration and interop for heterogeneous > >>> installed base of old and new DANE clients, the DNS admin must > >>> provide TLSA records with certificate hashes consistently for all > >>> desired hash algorithms for a given server host name. > >> > >> can I have some of what you are smoking? please? > >> > >>> > >>> > >>> -Martin > >> _______________________________________________ > >> dane mailing list > >> dane@ietf.org > >> https://www.ietf.org/mailman/listinfo/dane > > _______________________________________________ > > dane mailing list > > dane@ietf.org > > https://www.ietf.org/mailman/listinfo/dane >=20 > -- > Ondrej Sur > vedouc v zkumu/Head of R&D department > ------------------------------------------- > CZ.NIC, z.s.p.o. -- Laboratore 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 Mon Sep 19 13:18:29 2011 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 49D2421F8D6B for ; Mon, 19 Sep 2011 13:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, 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 jr8w49+b+VGq for ; Mon, 19 Sep 2011 13:18:28 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id 1DBF021F8D6C for ; Mon, 19 Sep 2011 13:18:27 -0700 (PDT) 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=yubnqvOxH5wghrCpYkYGbKsY6Wx8HEC3NSs/FNvj738=; b=xl8XsUgE2Ov3QSjBf4nJRKncYncw+Q/7re3hSWtYFL65IqM9sIWSwL9TotQ9vJ9q/M+e6IaSbAg+r HBCtMOLJN7OSPkYGXP39nU7dKr8wAg8l26WJGDLt0xoYpIrr9LD2EiwckgnWP6+0mZ3VCGpsa0ujwb FBo416L8P1bchwxo= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Mon, 19 Sep 2011 22:20:50 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: <9D42A033-D5C7-40D5-92BE-70DDFBBB95CA@nic.cz> Date: Mon, 19 Sep 2011 22:20:47 +0200 Content-Transfer-Encoding: 7bit Message-Id: <79C50478-9979-4BED-8D5B-7A95C3EDDD35@kirei.se> References: <20110915214614.GA14586@vacation.karoshi.com.> <201109152226.p8FMQ5kV016843@fs4113.wdf.sap.corp> <4e72886d.c413440a.6897.ffffaf2eSMTPIN_ADDED@mx.google.com> <2BBD5ABC-EB88-4419-B4F3-27BA2EF093A4@gmail.com> <9D42A033-D5C7-40D5-92BE-70DDFBBB95CA@nic.cz> To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= X-Mailer: Apple Mail (2.1244.3) Cc: DANE WG Subject: Re: [dane] Reopening issue #22 for discussion.... 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, 19 Sep 2011 20:18:29 -0000 +1 From hallam@gmail.com Mon Sep 19 13:19:44 2011 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 EE3C421F8D9E for ; Mon, 19 Sep 2011 13:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.194 X-Spam-Level: X-Spam-Status: No, score=-2.194 tagged_above=-999 required=5 tests=[AWL=-1.156, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_BL_SPAMCOP_NET=1.96, 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 gJfrBHPK6T6K for ; Mon, 19 Sep 2011 13:19:43 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id AC30A21F8D83 for ; Mon, 19 Sep 2011 13:19:43 -0700 (PDT) Received: by gyd12 with SMTP id 12so5283605gyd.31 for ; Mon, 19 Sep 2011 13:22:07 -0700 (PDT) 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=9Nfk79yeR7Z6F/0k23Tuin/LMzEk6hVsk2DNq7F92TQ=; b=vKghmHMnqc5HCJzOaC0+kCZbkohEogUuuqiNObf1XPnNk1O53NzTljk4YeMTFkdapa dJjlPvqSOV8H72u2dieuQZTPZABz/rkfTH3+fkkpnBc1qDaUQMZPaYFgyRXA5JhXl5ZI VDDjT9MePuszke/sK5h1tl/D7iUef8T+yeuMU= MIME-Version: 1.0 Received: by 10.100.192.5 with SMTP id p5mr2636573anf.96.1316463727367; Mon, 19 Sep 2011 13:22:07 -0700 (PDT) Received: by 10.101.71.4 with HTTP; Mon, 19 Sep 2011 13:22:07 -0700 (PDT) In-Reply-To: <007401cc76fd$3e2901a0$ba7b04e0$@augustcellars.com> References: <20110915214614.GA14586@vacation.karoshi.com.> <201109152226.p8FMQ5kV016843@fs4113.wdf.sap.corp> <4e72886d.c413440a.6897.ffffaf2eSMTPIN_ADDED@mx.google.com> <2BBD5ABC-EB88-4419-B4F3-27BA2EF093A4@gmail.com> <9D42A033-D5C7-40D5-92BE-70DDFBBB95CA@nic.cz> <007401cc76fd$3e2901a0$ba7b04e0$@augustcellars.com> Date: Mon, 19 Sep 2011 16:22:07 -0400 Message-ID: From: Phillip Hallam-Baker To: Jim Schaad Content-Type: multipart/alternative; boundary=0016e6440216d4566f04ad511859 Cc: dane@ietf.org Subject: Re: [dane] Reopening issue #22 for discussion.... 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, 19 Sep 2011 20:19:45 -0000 --0016e6440216d4566f04ad511859 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1 And SHA-3 is either announced or not announced in time. If it is announced = I would argue for adding it to the spec as a MUST[*] but I would not argue fo= r delaying the spec to wait on the announcement. [*] I do not believe in SHOULD for crypto algorithms. My view is that the IETF should only give algids for required algorithms and that vanity crypto should be supported only through an exception mechanism. 2011/9/19 Jim Schaad > +1 > > An algorithm either is or is not strong enough - thus no ranking needed. > > > -----Original Message----- > > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of > > Ondrej Sur=FD > > Sent: Monday, September 19, 2011 12:21 AM > > To: Phillip Hallam-Baker > > Cc: bmanning@vacation.karoshi.com; paul.hoffman@vpnc.org; > > dane@ietf.org > > Subject: Re: [dane] Reopening issue #22 for discussion.... > > > > Hi, > > > > I think this is a very reasonable argument and I agree with Phil here. > > > > Anyway it seems that we are sidetracking (again), so can we _all_ pleas= e > stick > > with #22 and respond if you agree with Warren's mail: > > > > On 14. 9. 2011, at 23:52, Warren Kumari wrote: > > > While it may be fun, we cannot / should not specify what the stronges= t > > digest is, and so we cannot really dictate how sides choose the > "strongest", > > and so client implementations will sort / choose the digest that they > believe > > is strongest. > > > > > > rephrased by Bill as: > > > > On 15. 9. 2011, at 15:19, bmanning@vacation.karoshi.com wrote: > > > The server can't strong arm clients. Period. (think deployed bas= e > and > > then making a > > > change... going to upgrade everything in the field? Good Luck w= / > > > that) > > > > > > So the group decision would be that we cannot and we should not enforce > > "strongest" algorithm in the DANE protocol. > > > > Please really try to respond with +1 / -1, so we can get rid of the iss= ue > fast. > > > > O. > > > > On 16. 9. 2011, at 2:33, Phillip Hallam-Baker wrote: > > > > > I dont see it as an issue. > > > > > > Chrome and Firefox both autopatch. They are the only browsers by > > companies attending DANE sessions. > > > > > > By the time anyone with a static browser deploys Sha3 will have been > > announced. > > > > > > > > > Legacy is a real hazzard in the browser world. But not for any > mainstream > > browser deployed in the past four years. The IE4 or Bind thing does not > > apply. > > > > > > I cant imagine any group that deployed DANE being asleep on sha3 > > deployment. > > > > > > > > > > > > > > > Sent from my iPad > > > > > > On Sep 15, 2011, at 18:21, bmanning@vacation.karoshi.com wrote: > > > > > >> On Fri, Sep 16, 2011 at 12:26:05AM +0200, Martin Rex wrote: > > >>> bmanning@vacation.karoshi.com wrote: > > >>>> > > >>> SHA-256 is mandatory to implement, SHA-512 is optional. > > >>> > > >>> The primary reason for hash agility is being able to switch to a > > >>> different algorithm at some point in the future, when SHA-256 is no > > >>> longer deemed adequate. > > >>> > > >>> The issues you're facing: > > >>> - for interop with the installed base DANE clients you'll have to > > >>> continue providing TLSA records with SHA-256 hashes for many years > > >>> (10+) to come > > >> > > >> -if- backward interoperablity is desired, yes (30+) years if BIND = is > > >> any predictor. > > >> > > >>> - for new DANE clients to obtain security benefit from TLSA records > > >>> with a stronger hash, new DANE clients will have to ignore all > > >>> records with a weaker hash as soon as they find a records with a > > >>> stronger hash (that they implement) for a given server host name. > > >> > > >> thats not going to fly operationally. the server s going to have = to > > >> cease publication of all weaker hashes - forcing clients to upgrad= e. > > >> > > >> thats the proven operational method. if the weaker hash exists it > will > > >> get used. anything else is simply gyrations and conplex code path= s > in > > >> the client to try and figure out what the server was trying to say > by > > >> speaking spanglish, finnish, and mayan... is there a credible > reason to > > >> try and burden the client code with this goofy logic? seems like = an > ideal > > >> breeding ground for security exploits. > > >> > > >>> - to provide smooth migration and interop for heterogeneous > > >>> installed base of old and new DANE clients, the DNS admin must > > >>> provide TLSA records with certificate hashes consistently for all > > >>> desired hash algorithms for a given server host name. > > >> > > >> can I have some of what you are smoking? please? > > >> > > >>> > > >>> > > >>> -Martin > > >> _______________________________________________ > > >> dane mailing list > > >> dane@ietf.org > > >> https://www.ietf.org/mailman/listinfo/dane > > > _______________________________________________ > > > dane mailing list > > > dane@ietf.org > > > https://www.ietf.org/mailman/listinfo/dane > > > > -- > > Ondrej Sur > > vedouc v zkumu/Head of R&D department > > ------------------------------------------- > > CZ.NIC, z.s.p.o. -- Laboratore CZ.NIC > > Americka 23, 120 00 Praha 2, Czech Republic > > mailto:ondrej.sury@nic.cz http://nic.cz/ > > tel:+420.222745110 fax:+420.222745112 > > ------------------------------------------- > > > > _______________________________________________ > > dane mailing list > > dane@ietf.org > > https://www.ietf.org/mailman/listinfo/dane > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > --=20 Website: http://hallambaker.com/ --0016e6440216d4566f04ad511859 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+1

And SHA-3 is either announced or not announced = in time. If it is announced I would argue for adding it to the spec as a MU= ST[*] but I would not argue for delaying the spec to wait on the announceme= nt.


[*] I do not believe in SHOULD for crypto alg= orithms. My view is that the IETF should only give algids for required algo= rithms and that vanity crypto should be supported only through an exception= mechanism.=A0


2011/9/19 Jim Schaad <ietf@augustcellars.com>
+1

An algorithm either is or is not strong enough - thus no ranking needed.

> -----Original Message-----
> From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of
> Ondrej Sur=FD
> Sent: Monday, September 19, 2011 12:21 AM
> To: Phillip Hallam-Baker
> Cc: bmanning@vacation= .karoshi.com; paul.hoffman@vpn= c.org;
> dane@ietf.org > Subject: Re: [dane] Reopening issue #22 for discussion....
>
> Hi,
>
> I think this is a very reasonable argument and I agree with Phil here.=
>
> Anyway it seems that we are sidetracking (again), so can we _all_ plea= se stick
> with #22 and respond if you agree with Warren's mail:
>
> On 14. 9. 2011, at 23:52, Warren Kumari wrote:
> > While it may be fun, we cannot / should not specify what the stro= ngest
> digest is, and so we cannot really dictate how sides choose the "= strongest",
> and so client implementations will sort / choose the digest that they = believe
> is strongest.
>
>
> rephrased by Bill as:
>
> On 15. 9. 2011, at 15:19, bmanning@vacation.karoshi.com wrote:
> > =A0 =A0 The server can't strong arm clients. Period. =A0(thin= k deployed base and
> then making a
> > =A0 =A0 change... =A0going to upgrade everything in the field? = =A0Good Luck w/
> > that)
>
>
> So the group decision would be that we cannot and we should not enforc= e
> "strongest" algorithm in the DANE protocol.
>
> Please really try to respond with +1 / -1, so we can get rid of the is= sue fast.
>
> O.
>
> On 16. 9. 2011, at 2:33, Phillip Hallam-Baker wrote:
>
> > I dont see it as an issue.
> >
> > Chrome and Firefox both autopatch. They are the only browsers by<= br> > companies attending DANE sessions.
> >
> > By the time anyone with a static browser deploys Sha3 will have b= een
> announced.
> >
> >
> > Legacy is a real hazzard in the browser world. But not for any ma= instream
> browser deployed in the past four years. The IE4 or Bind thing does no= t
> apply.
> >
> > I cant imagine any group that deployed DANE being asleep on sha3<= br> > deployment.
> >
> >
> >
> >
> > Sent from my iPad
> >
> > On Sep 15, 2011, at 18:21, bmanning@vacation.karoshi.com wrote:
> >
> >> On Fri, Sep 16, 2011 at 12:26:05AM +0200, Martin Rex wrote: > >>> bmanning= @vacation.karoshi.com wrote:
> >>>>
> >>> SHA-256 is mandatory to implement, SHA-512 is optional. > >>>
> >>> The primary reason for hash agility is being able to swit= ch to a
> >>> different algorithm at some point in the future, when SHA= -256 is no
> >>> longer deemed adequate.
> >>>
> >>> The issues you're facing:
> >>> - for interop with the installed base DANE clients you= 9;ll have to
> >>> continue =A0providing TLSA records with SHA-256 hashes fo= r many years
> >>> (10+) to come
> >>
> >> =A0 -if- backward interoperablity is desired, yes (30+) years= if BIND is
> >> =A0 any predictor.
> >>
> >>> - for new DANE clients to obtain security benefit from TL= SA records
> >>> with =A0a stronger hash, new DANE clients will have to ig= nore all
> >>> records with =A0a weaker hash as soon as they find a reco= rds with a
> >>> stronger hash (that =A0they implement) for a given server= host name.
> >>
> >> =A0 thats not going to fly operationally. =A0the server s goi= ng to have to
> >> =A0 cease publication of all weaker hashes - forcing clients = to upgrade.
> >>
> >> =A0 thats the proven operational method. =A0if the weaker has= h exists it will
> >> =A0 get used. =A0anything else is simply gyrations and conple= x code paths in
> >> =A0 the client to try and figure out what the server was tryi= ng to say by
> >> =A0 speaking spanglish, finnish, and mayan... =A0 is there a = credible reason to
> >> =A0 try and burden the client code with this goofy logic? =A0= seems like an ideal
> >> =A0 breeding ground for security exploits.
> >>
> >>> - to provide smooth migration and interop for heterogeneo= us
> >>> installed =A0base of old and new DANE clients, the DNS ad= min must
> >>> provide =A0TLSA records with certificate hashes consisten= tly for all
> >>> desired =A0hash algorithms for a given server host name.<= br> > >>
> >> =A0 can I have some of what you are smoking? =A0please?
> >>
> >>>
> >>>
> >>> -Martin
> >> _______________________________________________
> >> dane mailing list
> >> dane@ietf.org
> >> https://www.ietf.org/mailman/listinfo/dane
> > _______________________________________________
> > dane mailing list
> > dane@ietf.org
> > https://www.ietf.org/mailman/listinfo/dane
>
> --
> =A0Ondrej Sur
> =A0vedouc =A0v zkumu/Head of R&D department
> =A0-------------------------------------------
> =A0CZ.NIC, z.s.p.o. =A0 =A0-- =A0 =A0Laboratore CZ.NIC
> =A0Americka 23, 120 00 Praha 2, Czech Republic
> =A0mailto:ondrej.sury@nic.cz= =A0 =A0http://nic.cz/
> =A0tel:+420.2= 22745110 =A0 =A0 =A0 fax:+420.222745112
> =A0-------------------------------------------
>
> ______________________________= _________________
> dane mailing list
> dane@ietf.org
> https://www.ietf.org/mailman/listinfo/dane

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



--
= Website: http://hallambaker.com/
--0016e6440216d4566f04ad511859-- From warren@kumari.net Tue Sep 20 16:33:09 2011 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 83A031F0C4F for ; Tue, 20 Sep 2011 16:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.023 X-Spam-Level: X-Spam-Status: No, score=-102.023 tagged_above=-999 required=5 tests=[AWL=-0.324, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, 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 eNHlIWtGoufC for ; Tue, 20 Sep 2011 16:33:08 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 2585A1F0C3D for ; Tue, 20 Sep 2011 16:33:03 -0700 (PDT) Received: from dhcp-172-19-119-117.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id C68011B4001D; Tue, 20 Sep 2011 19:35:19 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Warren Kumari In-Reply-To: <9D42A033-D5C7-40D5-92BE-70DDFBBB95CA@nic.cz> Date: Tue, 20 Sep 2011 19:35:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <419CBB88-EEEC-47A1-9D33-308AD2A1320E@kumari.net> References: <20110915214614.GA14586@vacation.karoshi.com.> <201109152226.p8FMQ5kV016843@fs4113.wdf.sap.corp> <4e72886d.c413440a.6897.ffffaf2eSMTPIN_ADDED@mx.google.com> <2BBD5ABC-EB88-4419-B4F3-27BA2EF093A4@gmail.com> <9D42A033-D5C7-40D5-92BE-70DDFBBB95CA@nic.cz> To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= X-Mailer: Apple Mail (2.1084) Cc: DANE WG Subject: Re: [dane] Reopening issue #22 for discussion.... 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, 20 Sep 2011 23:33:09 -0000 On Sep 19, 2011, at 3:21 AM, Ond=C5=99ej Sur=C3=BD wrote: > Hi, >=20 > I think this is a very reasonable argument and I agree with Phil here. >=20 > Anyway it seems that we are sidetracking (again), so can we _all_ = please > stick with #22 and respond if you agree with Warren's mail: >=20 > On 14. 9. 2011, at 23:52, Warren Kumari wrote: >> While it may be fun, we cannot / should not specify what the = strongest digest is, and so we cannot really dictate how sides choose = the "strongest", and so client implementations will sort / choose the = digest that they believe is strongest. >=20 >=20 > rephrased by Bill as: >=20 > On 15. 9. 2011, at 15:19, bmanning@vacation.karoshi.com wrote: >> The server can't strong arm clients. Period. (think deployed = base and then making a >> change... going to upgrade everything in the field? Good Luck = w/ that) >=20 >=20 > So the group decision would be that we cannot and we should not = enforce "strongest" algorithm in the DANE protocol. >=20 > Please really try to respond with +1 / -1, so we can get rid of the = issue fast. Ok, and we seem to be achieving consensus on this -- "DANE cannot (and = should not) try enforce a "strongest" algorithm" -- as it's the wee = hours of the morning in Prague my co-chair is (presumably) asleep and so = I'm calling this without his input. If he disagrees on the consensus = he'll poke me with a pointy clue stick and we'll reopen the issue = (again). W >=20 > O. >=20 > On 16. 9. 2011, at 2:33, Phillip Hallam-Baker wrote: >=20 >> I dont see it as an issue. >>=20 >> Chrome and Firefox both autopatch. They are the only browsers by = companies attending DANE sessions. >>=20 >> By the time anyone with a static browser deploys Sha3 will have been = announced. >>=20 >>=20 >> Legacy is a real hazzard in the browser world. But not for any = mainstream browser deployed in the past four years. The IE4 or Bind = thing does not apply. >>=20 >> I cant imagine any group that deployed DANE being asleep on sha3 = deployment. >>=20 >>=20 >>=20 >>=20 >> Sent from my iPad >>=20 >> On Sep 15, 2011, at 18:21, bmanning@vacation.karoshi.com wrote: >>=20 >>> On Fri, Sep 16, 2011 at 12:26:05AM +0200, Martin Rex wrote: >>>> bmanning@vacation.karoshi.com wrote: >>>>>=20 >>>> SHA-256 is mandatory to implement, SHA-512 is optional. >>>>=20 >>>> The primary reason for hash agility is being able to switch to a >>>> different algorithm at some point in the future, when SHA-256 is no >>>> longer deemed adequate. >>>>=20 >>>> The issues you're facing: >>>> - for interop with the installed base DANE clients you'll have to = continue >>>> providing TLSA records with SHA-256 hashes for many years (10+) to = come >>>=20 >>> -if- backward interoperablity is desired, yes (30+) years if BIND = is >>> any predictor. >>>=20 >>>> - for new DANE clients to obtain security benefit from TLSA records = with >>>> a stronger hash, new DANE clients will have to ignore all records = with >>>> a weaker hash as soon as they find a records with a stronger hash = (that >>>> they implement) for a given server host name. >>>=20 >>> thats not going to fly operationally. the server s going to have = to >>> cease publication of all weaker hashes - forcing clients to = upgrade. >>>=20 >>> thats the proven operational method. if the weaker hash exists it = will >>> get used. anything else is simply gyrations and conplex code paths = in >>> the client to try and figure out what the server was trying to say = by=20 >>> speaking spanglish, finnish, and mayan... is there a credible = reason to >>> try and burden the client code with this goofy logic? seems like = an ideal >>> breeding ground for security exploits. =20 >>>=20 >>>> - to provide smooth migration and interop for heterogeneous = installed >>>> base of old and new DANE clients, the DNS admin must provide >>>> TLSA records with certificate hashes consistently for all desired >>>> hash algorithms for a given server host name. >>>=20 >>> can I have some of what you are smoking? please? >>>=20 >>>>=20 >>>>=20 >>>> -Martin >>> _______________________________________________ >>> dane mailing list >>> dane@ietf.org >>> https://www.ietf.org/mailman/listinfo/dane >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >=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 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From trac+dane@trac.tools.ietf.org Tue Sep 20 16:56:23 2011 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 68D381F0C5B for ; Tue, 20 Sep 2011 16:56:23 -0700 (PDT) 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 QKZchrdvWc90 for ; Tue, 20 Sep 2011 16:56:22 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 944621F0C82 for ; Tue, 20 Sep 2011 16:56:18 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1R6AD0-0001gs-Lq; Tue, 20 Sep 2011 19:58:38 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: matt@mattmccutchen.net, mrex@sap.com, warren@kumari.net X-Trac-Project: dane Date: Tue, 20 Sep 2011 23:58:38 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/22#comment:5 Message-ID: <070.1844fb8093eb50aeadefb7c3f8b766cc@trac.tools.ietf.org> References: <061.e0845de87f7a8d8d863b8ef546890255@trac.tools.ietf.org> X-Trac-Ticket-ID: 22 In-Reply-To: <061.e0845de87f7a8d8d863b8ef546890255@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: matt@mattmccutchen.net, mrex@sap.com, 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] #22: Provide the security of the strongest digest supported by both sides 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: Tue, 20 Sep 2011 23:56:23 -0000 #22: Provide the security of the strongest digest supported by both sides Changes (by warren@…): * status: reopened => closed * resolution: => fixed Comment: It was decided that DANE cannot (and should not) dictate a view of "strongest" Please see long thread: http://www.ietf.org/mail- archive/web/dane/current/msg03412.html -- ------------------------------------+--------------------------------------- Reporter: matt@… | Owner: Type: defect | Status: closed Priority: major | Milestone: Component: protocol | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Ticket URL: dane From trac+dane@trac.tools.ietf.org Tue Sep 20 21:25:00 2011 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 4A4B71F0C3F for ; Tue, 20 Sep 2011 21:25:00 -0700 (PDT) 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 J9lJW++lh5QQ for ; Tue, 20 Sep 2011 21:24:59 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id C800D1F0C36 for ; Tue, 20 Sep 2011 21:24:59 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1R6EP1-00006O-HM; Wed, 21 Sep 2011 00:27:19 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: draft-ietf-dane-protocol@tools.ietf.org, matt@mattmccutchen.net X-Trac-Project: dane Date: Wed, 21 Sep 2011 04:27:19 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/33 Message-ID: <061.add9f922b5dfb2db7544981f78552e7e@trac.tools.ietf.org> X-Trac-Ticket-ID: 33 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dane-protocol@tools.ietf.org, 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 Resent-To: Resent-Message-Id: <20110921042459.C800D1F0C36@ietfa.amsl.com> Resent-Date: Tue, 20 Sep 2011 21:24:59 -0700 (PDT) Resent-From: trac+dane@trac.tools.ietf.org Cc: dane@ietf.org Subject: [dane] #33: Publish enough information for the client to achieve the security of its favorite digest 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: Wed, 21 Sep 2011 04:25:00 -0000 #33: Publish enough information for the client to achieve the security of its favorite digest There was a misunderstanding on ticket:22, so I'm restating the less controversial part of the proposal here. The possible solutions are still those in ticket:22#comment:1. -- ------------------------------------+--------------------------------------- Reporter: matt@… | Owner: draft-ietf-dane-protocol@… Type: defect | Status: new Priority: major | Milestone: Component: protocol | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Ticket URL: dane From matt@mattmccutchen.net Tue Sep 20 21:33:25 2011 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 248851F0C45 for ; Tue, 20 Sep 2011 21:33:25 -0700 (PDT) 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 qJXDJUHtIcFs for ; Tue, 20 Sep 2011 21:33:24 -0700 (PDT) Received: from homiemail-a38.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 4D41F1F0C3F for ; Tue, 20 Sep 2011 21:33:24 -0700 (PDT) Received: from homiemail-a38.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a38.g.dreamhost.com (Postfix) with ESMTP id D224810AFB4 for ; Tue, 20 Sep 2011 21:35:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:date:in-reply-to:references:content-type:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=hrzHgaci3UmGTDJgcTFnt93LemTW19/gpi7XAQNjmPV Hyc5WdT3cY8tmtROlx3Nys0UFx76z3tavEIQcGG3t7K3NxCALvYNtOpzBFApmKVI R9v+JvUDFfw3t2N4l53xKAfCgasPrTYecmqGMn40R3jimq7uXm+/y/CJITgYWZ+U = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:date:in-reply-to:references:content-type :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=9pjcCsdUt9V4K1i9tDux3+jKZ08=; b=vcPTWoi5q8 DVSVNJOm3fj0zO2HYjEO4/2hg0FPpEJmpwEJM6FjdHkrOPgk9NhWUsj4ojCIkvOV C90/XvJWZ5CFm0g/MpYaw6JQkP4LThZk18LVcBxG8P1q91Yprg0IztJnjbbMnI/c Gnl70Bddv8EoRZ4UG3CFTG9RPQ+FIxVTc= 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 A295110AFB0 for ; Tue, 20 Sep 2011 21:35:51 -0700 (PDT) From: Matt McCutchen To: dane Date: Tue, 20 Sep 2011 21:35:50 -0700 In-Reply-To: <9D42A033-D5C7-40D5-92BE-70DDFBBB95CA@nic.cz> References: <20110915214614.GA14586@vacation.karoshi.com.> <201109152226.p8FMQ5kV016843@fs4113.wdf.sap.corp> <4e72886d.c413440a.6897.ffffaf2eSMTPIN_ADDED@mx.google.com> <2BBD5ABC-EB88-4419-B4F3-27BA2EF093A4@gmail.com> <9D42A033-D5C7-40D5-92BE-70DDFBBB95CA@nic.cz> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 Message-ID: <1316579751.1941.19.camel@localhost> Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [dane] Reopening issue #22 for discussion.... 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, 21 Sep 2011 04:33:25 -0000 [Finally coming back to DANE discussion...] On Mon, 2011-09-19 at 09:21 +0200, Ond=C5=99ej Sur=C3=BD wrote: > I think this is a very reasonable argument and I agree with Phil here. >=20 > Anyway it seems that we are sidetracking (again), so can we _all_ pleas= e > stick with #22 and respond if you agree with Warren's mail: >=20 > On 14. 9. 2011, at 23:52, Warren Kumari wrote: > > While it may be fun, we cannot / should not specify what the > strongest digest is, and so we cannot really dictate how sides choose > the "strongest", and so client implementations will sort / choose the > digest that they believe is strongest. >=20 > rephrased by Bill as: >=20 > On 15. 9. 2011, at 15:19, bmanning@vacation.karoshi.com wrote: > > The server can't strong arm clients. Period. (think deployed base a= nd then making a > > change... going to upgrade everything in the field? Good Luck w/ t= hat) >=20 >=20 > So the group decision would be that we cannot and we should not enforce= "strongest" algorithm in the DANE protocol. >=20 > Please really try to respond with +1 / -1, so we can get rid of the iss= ue fast. There was a severe misunderstanding here. I should have better separated the two parts of the proposal: a. Publish enough information that the client /can/ achieve the security of the "strongest" digest offered by the server. b. State that clients SHOULD or MUST do so for a given definition of "strongest". The proposed decision is to not do "b". I do not feel strongly about that. But to not do "a" would undercut the notion that we have achieved algorithm agility. To me, algorithm agility means that peers that wish to use a new algorithm can immediately receive the security benefits while remaining fully interoperable with peers that do not support it. If we do not achieve this, then the only reason to support multiple algorithms at all would be in anticipation of a slow and/or breaking transition. I have moved "a" to https://trac.tools.ietf.org/wg/dane/trac/ticket/33 . --=20 Matt From trac+dane@trac.tools.ietf.org Tue Sep 20 21:36:25 2011 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 40AEA1F0C45 for ; Tue, 20 Sep 2011 21:36:25 -0700 (PDT) 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 ho3xPCHJnQ26 for ; Tue, 20 Sep 2011 21:36:24 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 9393A1F0C3F for ; Tue, 20 Sep 2011 21:36:24 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1R6Ea8-0003Ip-G3; Wed, 21 Sep 2011 00:38:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: matt@mattmccutchen.net, mrex@sap.com, warren@kumari.net X-Trac-Project: dane Date: Wed, 21 Sep 2011 04:38:48 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/22#comment:6 Message-ID: <070.7e9b6f809850af3e8122e936da87100f@trac.tools.ietf.org> References: <061.e0845de87f7a8d8d863b8ef546890255@trac.tools.ietf.org> X-Trac-Ticket-ID: 22 In-Reply-To: <061.e0845de87f7a8d8d863b8ef546890255@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: matt@mattmccutchen.net, mrex@sap.com, 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] #22: Provide the security of the strongest digest supported by both sides 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: Wed, 21 Sep 2011 04:36:25 -0000 #22: Provide the security of the strongest digest supported by both sides Changes (by matt@…): * status: closed => reopened * resolution: fixed => Comment: Please use "wontfix" for declined proposals. -- ------------------------------------+--------------------------------------- Reporter: matt@… | Owner: Type: defect | Status: reopened Priority: major | Milestone: Component: protocol | Version: Severity: - | Resolution: Keywords: | ------------------------------------+--------------------------------------- Ticket URL: dane From trac+dane@trac.tools.ietf.org Tue Sep 20 21:36:33 2011 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 931321F0C4C for ; Tue, 20 Sep 2011 21:36:33 -0700 (PDT) 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 5hKzVvtQkWmt for ; Tue, 20 Sep 2011 21:36:33 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 10EEF1F0C3F for ; Tue, 20 Sep 2011 21:36:33 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1R6EaI-0003Iw-K3; Wed, 21 Sep 2011 00:38:58 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: matt@mattmccutchen.net, mrex@sap.com, warren@kumari.net X-Trac-Project: dane Date: Wed, 21 Sep 2011 04:38:58 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/22#comment:7 Message-ID: <070.992acb4e61f4c492e5a6dc493a3554ba@trac.tools.ietf.org> References: <061.e0845de87f7a8d8d863b8ef546890255@trac.tools.ietf.org> X-Trac-Ticket-ID: 22 In-Reply-To: <061.e0845de87f7a8d8d863b8ef546890255@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: matt@mattmccutchen.net, mrex@sap.com, 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] #22: Provide the security of the strongest digest supported by both sides 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: Wed, 21 Sep 2011 04:36:33 -0000 #22: Provide the security of the strongest digest supported by both sides Changes (by matt@…): * status: reopened => closed * resolution: => wontfix -- ------------------------------------+--------------------------------------- Reporter: matt@… | Owner: Type: defect | Status: closed Priority: major | Milestone: Component: protocol | Version: Severity: - | Resolution: wontfix Keywords: | ------------------------------------+--------------------------------------- Ticket URL: dane From matt@mattmccutchen.net Tue Sep 20 21:57:09 2011 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 6395D21F87C9 for ; Tue, 20 Sep 2011 21:57:09 -0700 (PDT) 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 2Uu6c99nagFu for ; Tue, 20 Sep 2011 21:57:08 -0700 (PDT) Received: from homiemail-a37.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id C265621F85CE for ; Tue, 20 Sep 2011 21:57:08 -0700 (PDT) Received: from homiemail-a37.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTP id 6724A208069; Tue, 20 Sep 2011 21:59:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; q=dns; s= mattmccutchen.net; b=LfZqlJ23fJvxxBQYBrFvkHimmzm6F1gr98zwcu3zIqW /Cpb6vxsP2nCwYNtSJIZ5KG9IWWhojlEZpdiDtKfA4jo2Lu+fzYrlnb9BxQkbap7 LkcTcV0LR0KRnD9RndRNqKkch8IoQdTdQkSDFVKF98fBCrKgpokY4LDc9+pYuwK0 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; s= mattmccutchen.net; bh=2Yo/15EyBSAa7UDg+ClimZ2muoA=; b=J94AtwXFpt 3DFRe4jho2M2j5a5RC19bdy03mvXAMkmV/ZZILvtShC2gvdooQuIc7lMkKDY02w1 mj1TD580aZrIO10GH/U7f9/iclxCHXsHCm7d3y/FeA36meitowEChuBCuhnpR+Qy 6e0c+NUjcxwCOhmB5wKu0Hg/JXit0uq6A= 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-a37.g.dreamhost.com (Postfix) with ESMTPSA id 357D4208063; Tue, 20 Sep 2011 21:59:35 -0700 (PDT) From: Matt McCutchen To: Jakob Schlyter Date: Tue, 20 Sep 2011 21:59:34 -0700 In-Reply-To: References: <4CBA8AED-F76D-46DF-A2A0-0B1608E3C8C2@kirei.se> <201109011639444268036@163.com> <20110902225200.GA6521@vacation.karoshi.com.> <20110903112732.GA14712@vacation.karoshi.com.> <812921FE-6CA6-4B80-A7C0-E3410428BED6@kirei.se> <557EBC88-0EB5-49EA-8ED1-A93EF0E5BEF5@kumari.net> <0FBA90D5-79E6-4826-9B41-2F04E01F83B0@bbn.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 Content-Transfer-Encoding: 7bit Message-ID: <1316581175.1941.36.camel@localhost> Mime-Version: 1.0 Cc: DANE WG Subject: Re: [dane] #31: Multiple TLSA records in a response - really conjunctions 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, 21 Sep 2011 04:57:09 -0000 On Fri, 2011-09-09 at 09:07 +0200, Jakob Schlyter wrote: > On 8 sep 2011, at 17:54, Paul Hoffman wrote: > > While this change does meet the "combination" use case, it also > makes the protocol more complex. It requires that domain > administrators who don't care about combination still pick a group ID > (even if it is 0). Is the use case actually worth the additional > complexity? If so, I think that Richard's proposal is probably the > least complex way to implement it. > > I do not believe that supporting "combination" is worth the additional complexity and I urge the WG to keep DANE as simple as possible. Let me first point out that the "combination" referred to here is the same "conjunction" as in ticket 27. -1. I agree that conjunctions like "EE certificate match && CA certificate match" do not have enough substantive benefit to justify the feature. But conjunctions also provide a natural solution for: - Restrictive assertions (#25): "traditional && my_DANE_predicates". - Full hash agility (#33): put all the hashes of the same cert in a conjunction and let the client check one or more of them as it wishes. I agree that the group ID is a little ugly, and would instead propose to concatenate all the predicates of each conjunction ("profile") in a single RR. Then the RRset would be a pure disjunction of the RRs, in the same spirit as the A RRset. Rollover would involve addition or removal of whole RRs, which is more intuitive to the DNS admin who is not a DANE expert. I regret coming late to this discussion, due to limited Internet connectivity for the last two weeks. I imagine my vote won't flip the consensus, but please note it. -- Matt From matt@mattmccutchen.net Tue Sep 20 22:03:48 2011 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 957C521F8B7B for ; Tue, 20 Sep 2011 22:03:48 -0700 (PDT) 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 xYwgECcaDzdl for ; Tue, 20 Sep 2011 22:03:48 -0700 (PDT) Received: from homiemail-a5.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 0374321F8B78 for ; Tue, 20 Sep 2011 22:03:47 -0700 (PDT) Received: from homiemail-a5.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a5.g.dreamhost.com (Postfix) with ESMTP id B6D1970406E; Tue, 20 Sep 2011 22:06:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; q=dns; s= mattmccutchen.net; b=exZ2l5OgIdmfIgpTGtMy4iHzsGJ49S1JEc8evgj3Zwt GhfKePEEO4seQ2h90ER96LKSyDKBJaDUGGhJcmBCd44dIAfkn6B5Sdwkv4GNNy7K 1DmUn0EptzSggjgxmuioBiaxPCnbjZwqVudsXjDA9C3B0Zlhmi8mdDABUE4qh0yk = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; s= mattmccutchen.net; bh=H2uVpSNiM3MofuifLSIkjMAkrak=; b=h7qDZaqW6C F4KCdw/p63BXQGQt3ZkCvLJn1V5o+3xqX5om1yAeH+G3eSIw1OMv/pXMV/M77dJf 8s+cIvgkkq7835kYbtIEO2G0KLsdDPr9a00M5mgNWwBX4S+PvUwARKQXIZ5DnAXa LLTpYdWFVjd/S96HVixzPURDZNLTOo8+8= 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-a5.g.dreamhost.com (Postfix) with ESMTPSA id 8F92070406A; Tue, 20 Sep 2011 22:06:15 -0700 (PDT) From: Matt McCutchen To: Paul Hoffman Date: Tue, 20 Sep 2011 22:06:14 -0700 In-Reply-To: <1FC517BE-41AD-449F-8864-3770A15D760E@vpnc.org> References: <05701F4C-3419-40DF-A2E7-8BFF8A3434CA@kumari.net> <20110915131937.GC13546@vacation.karoshi.com.> <1FC517BE-41AD-449F-8864-3770A15D760E@vpnc.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 Content-Transfer-Encoding: 7bit Message-ID: <1316581575.1941.41.camel@localhost> Mime-Version: 1.0 Cc: DANE WG Subject: Re: [dane] Reopening issue #22 for discussion.... 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, 21 Sep 2011 05:03:48 -0000 On Thu, 2011-09-15 at 08:34 -0700, Paul Hoffman wrote: > I would prefer that we do not adopt the proposed design change. Do you have an articulable objection to the "provide enough information" part of the proposal, now moved to ticket #33, or do you just believe it is not worth the effort? > Further, I disagree with the part of the problem statement that says > "clients that support SHA-512 will still accept any certificate that > matches the SHA-256 digest". Clients that care about different > strengths can be configured not to do this. Sure, but the mass-market browsers will never do that. Whereas, with the proposal, they would be able to achieve what they believe is the strongest possible security with every server. I don't care how much you disdain browsers; we are missing an opportunity to do a greater service to this large segment of the public. -- Matt From trac+dane@trac.tools.ietf.org Tue Sep 20 22:18:54 2011 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 6E55221F8C88 for ; Tue, 20 Sep 2011 22:18:54 -0700 (PDT) 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 75aiOXnAVv6x for ; Tue, 20 Sep 2011 22:18:53 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id B7C1121F8C83 for ; Tue, 20 Sep 2011 22:18:53 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1R6FFD-0001ic-2i; Wed, 21 Sep 2011 01:21:15 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: draft-ietf-dane-protocol@tools.ietf.org, matt@mattmccutchen.net X-Trac-Project: dane Date: Wed, 21 Sep 2011 05:21:15 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/34 Message-ID: <061.49734f1d5b95ca0435edf0ff85ccea22@trac.tools.ietf.org> X-Trac-Ticket-ID: 34 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dane-protocol@tools.ietf.org, 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 Resent-To: Resent-Message-Id: <20110921051853.B7C1121F8C83@ietfa.amsl.com> Resent-Date: Tue, 20 Sep 2011 22:18:53 -0700 (PDT) Resent-From: trac+dane@trac.tools.ietf.org Cc: dane@ietf.org Subject: [dane] #34: Use with wildcards (i.e. *.googleusercontent.com) 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: Wed, 21 Sep 2011 05:18:54 -0000 #34: Use with wildcards (i.e. *.googleusercontent.com) This was the outstanding piece of ticket:24. It needs a redirection/rewriting mechanism that could be framed as either TLSA- specific or an RRtype-agnostic layer above the existing DNS. -- ------------------------------------+--------------------------------------- Reporter: matt@… | Owner: draft-ietf-dane-protocol@… Type: enhancement | Status: new Priority: major | Milestone: Component: protocol | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Ticket URL: dane From trac+dane@trac.tools.ietf.org Tue Sep 20 22:19:49 2011 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 0688A21F8C95 for ; Tue, 20 Sep 2011 22:19:49 -0700 (PDT) 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 id+ctih2EU-a for ; Tue, 20 Sep 2011 22:19:48 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id E009E21F8C99 for ; Tue, 20 Sep 2011 22:19:47 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1R6FG7-0003bQ-1Y; Wed, 21 Sep 2011 01:22:11 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: draft-ietf-dane-protocol@tools.ietf.org, matt@mattmccutchen.net, ondrej.sury@nic.cz X-Trac-Project: dane Date: Wed, 21 Sep 2011 05:22:11 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/24#comment:2 Message-ID: <070.3071878b641db2a02e2610c2233435c0@trac.tools.ietf.org> References: <061.ee73b0a357f1a46b8aa646a4c36057d4@trac.tools.ietf.org> X-Trac-Ticket-ID: 24 In-Reply-To: <061.ee73b0a357f1a46b8aa646a4c36057d4@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dane-protocol@tools.ietf.org, matt@mattmccutchen.net, ondrej.sury@nic.cz, 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: <20110921051947.E009E21F8C99@ietfa.amsl.com> Resent-Date: Tue, 20 Sep 2011 22:19:47 -0700 (PDT) Resent-From: trac+dane@trac.tools.ietf.org Cc: dane@ietf.org Subject: Re: [dane] #24: Use with CNAME, DNAME (was: Use with wildcards, CNAME, DNAME) 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: Wed, 21 Sep 2011 05:19:49 -0000 #24: Use with CNAME, DNAME Changes (by matt@…): * status: closed => reopened * resolution: fixed => Comment: [http://www.ietf.org/mail-archive/web/dane/current/msg03169.html What was actually decided] was to decline a proposal to (attempt to) look up TLSA at the DNS-canonicalized host name, because the functionality (as opposed to convenience) that it added was not great and it introduced a layering violation and a risk of unintended delegation. I'm narrowing this ticket to the CNAME/DNAME cases covered by that decision and changing the resolution to "worksforme" to reflect that TLSA can generally be used in such cases, though it may be less convenient. The wildcard cases move to ticket:34. -- ------------------------------------+--------------------------------------- Reporter: matt@… | Owner: draft-ietf-dane-protocol@… Type: enhancement | Status: reopened Priority: major | Milestone: Component: protocol | Version: Severity: - | Resolution: Keywords: | ------------------------------------+--------------------------------------- Ticket URL: dane From trac+dane@trac.tools.ietf.org Tue Sep 20 22:19:57 2011 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 B946F21F8CB3 for ; Tue, 20 Sep 2011 22:19:57 -0700 (PDT) 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 IL+63ZBp5PfL for ; Tue, 20 Sep 2011 22:19:57 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 2720E21F8CAE for ; Tue, 20 Sep 2011 22:19:56 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1R6FGH-0003rC-4q; Wed, 21 Sep 2011 01:22:21 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: draft-ietf-dane-protocol@tools.ietf.org, matt@mattmccutchen.net, ondrej.sury@nic.cz X-Trac-Project: dane Date: Wed, 21 Sep 2011 05:22:21 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/24#comment:3 Message-ID: <070.a6867f8f3aada10ce5698093dfc7d573@trac.tools.ietf.org> References: <061.ee73b0a357f1a46b8aa646a4c36057d4@trac.tools.ietf.org> X-Trac-Ticket-ID: 24 In-Reply-To: <061.ee73b0a357f1a46b8aa646a4c36057d4@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dane-protocol@tools.ietf.org, matt@mattmccutchen.net, ondrej.sury@nic.cz, 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: <20110921051957.2720E21F8CAE@ietfa.amsl.com> Resent-Date: Tue, 20 Sep 2011 22:19:56 -0700 (PDT) Resent-From: trac+dane@trac.tools.ietf.org Cc: dane@ietf.org Subject: Re: [dane] #24: Use with CNAME, DNAME 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: Wed, 21 Sep 2011 05:19:57 -0000 #24: Use with CNAME, DNAME Changes (by matt@…): * status: reopened => closed * resolution: => worksforme -- ------------------------------------+--------------------------------------- Reporter: matt@… | Owner: draft-ietf-dane-protocol@… Type: enhancement | Status: closed Priority: major | Milestone: Component: protocol | Version: Severity: - | Resolution: worksforme Keywords: | ------------------------------------+--------------------------------------- Ticket URL: dane From trac+dane@trac.tools.ietf.org Tue Sep 20 22:21:53 2011 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 7189E21F848D for ; Tue, 20 Sep 2011 22:21:53 -0700 (PDT) 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 rdrYk3B-vvnx for ; Tue, 20 Sep 2011 22:21:52 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9BE21F8511 for ; Tue, 20 Sep 2011 22:21:46 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1R6FI5-00008I-VS; Wed, 21 Sep 2011 01:24:13 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: matt@mattmccutchen.net X-Trac-Project: dane Date: Wed, 21 Sep 2011 05:24:13 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/34#comment:1 Message-ID: <070.3edb172e144038335c2aecbdddf69c99@trac.tools.ietf.org> References: <061.49734f1d5b95ca0435edf0ff85ccea22@trac.tools.ietf.org> X-Trac-Ticket-ID: 34 In-Reply-To: <061.49734f1d5b95ca0435edf0ff85ccea22@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: 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] #34: Use with wildcards (i.e. *.googleusercontent.com) 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: Wed, 21 Sep 2011 05:21:53 -0000 #34: Use with wildcards (i.e. *.googleusercontent.com) Changes (by matt@…): * owner: draft-ietf-dane-protocol@… => matt@… * status: new => assigned Comment: This is waiting on me to make either one or the other proposal public... -- ------------------------------------+--------------------------------------- Reporter: matt@… | Owner: matt@… Type: enhancement | Status: assigned Priority: major | Milestone: Component: protocol | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Ticket URL: dane From trac+dane@trac.tools.ietf.org Tue Sep 20 22:37:12 2011 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 552CE21F8B72 for ; Tue, 20 Sep 2011 22:37:12 -0700 (PDT) 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 pZcHB1+X3F6s for ; Tue, 20 Sep 2011 22:37:11 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 57EC321F8B59 for ; Tue, 20 Sep 2011 22:37:10 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1R6FWv-0001sb-Rr; Wed, 21 Sep 2011 01:39:33 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: draft-ietf-dane-protocol@tools.ietf.org, matt@mattmccutchen.net X-Trac-Project: dane Date: Wed, 21 Sep 2011 05:39:33 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/27#comment:1 Message-ID: <070.6ca68ed30ec57393fd971d442d5d3dda@trac.tools.ietf.org> References: <061.254317ee74b1f48610b85d0859eda94a@trac.tools.ietf.org> X-Trac-Ticket-ID: 27 In-Reply-To: <061.254317ee74b1f48610b85d0859eda94a@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dane-protocol@tools.ietf.org, 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 Resent-To: Resent-Message-Id: <20110921053711.57EC321F8B59@ietfa.amsl.com> Resent-Date: Tue, 20 Sep 2011 22:37:10 -0700 (PDT) Resent-From: trac+dane@trac.tools.ietf.org Cc: dane@ietf.org Subject: Re: [dane] #27: Conjunction of restrictions 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: Wed, 21 Sep 2011 05:37:12 -0000 #27: Conjunction of restrictions Comment(by matt@…): So apparently a proposal to achieve this goal via a "group ID" field was declined in ticket:32 in rather a hurry. Now I've given [http://www.ietf.org/mail-archive/web/dane/current/msg03418.html a different version of the proposal and some additional motivation]. Shall we have a new consensus call or does the previous one apply? -- ------------------------------------+--------------------------------------- Reporter: matt@… | Owner: draft-ietf-dane-protocol@… Type: defect | Status: new Priority: major | Milestone: Component: protocol | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Ticket URL: dane From trac+dane@trac.tools.ietf.org Tue Sep 20 22:38:29 2011 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 DF27421F8C83 for ; Tue, 20 Sep 2011 22:38:29 -0700 (PDT) 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 I62qgIDAqvUg for ; Tue, 20 Sep 2011 22:38:29 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 7226321F8B71 for ; Tue, 20 Sep 2011 22:38:29 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1R6FYD-0001vQ-8d; Wed, 21 Sep 2011 01:40:53 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: draft-ietf-dane-protocol@tools.ietf.org, matt@mattmccutchen.net, warren@kumari.net X-Trac-Project: dane Date: Wed, 21 Sep 2011 05:40:53 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/32#comment:2 Message-ID: <065.f40fe61a490f44604164d620181a9ab8@trac.tools.ietf.org> References: <056.419ff55228378ebc0a4553cb4374780d@trac.tools.ietf.org> X-Trac-Ticket-ID: 32 In-Reply-To: <056.419ff55228378ebc0a4553cb4374780d@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dane-protocol@tools.ietf.org, 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 Resent-To: Resent-Message-Id: <20110921053829.7226321F8B71@ietfa.amsl.com> Resent-Date: Tue, 20 Sep 2011 22:38:29 -0700 (PDT) Resent-From: trac+dane@trac.tools.ietf.org Cc: dane@ietf.org Subject: Re: [dane] #32: Grouping / combinations of certificates 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: Wed, 21 Sep 2011 05:38:30 -0000 #32: Grouping / combinations of certificates Changes (by matt@…): * status: closed => reopened * resolution: fixed => -- -------------------------------+-------------------------------------------- Reporter: warren@… | Owner: draft-ietf-dane-protocol@… Type: enhancement | Status: reopened Priority: minor | Milestone: Component: protocol | Version: Severity: - | Resolution: Keywords: | -------------------------------+-------------------------------------------- Ticket URL: dane From trac+dane@trac.tools.ietf.org Tue Sep 20 22:38:37 2011 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 D244421F8C9F for ; Tue, 20 Sep 2011 22:38:37 -0700 (PDT) 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 0vQHXpkz3l0S for ; Tue, 20 Sep 2011 22:38:37 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 5B22621F8B71 for ; Tue, 20 Sep 2011 22:38:37 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1R6FYL-0001vX-Fi; Wed, 21 Sep 2011 01:41:01 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: draft-ietf-dane-protocol@tools.ietf.org, matt@mattmccutchen.net, warren@kumari.net X-Trac-Project: dane Date: Wed, 21 Sep 2011 05:41:01 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/32#comment:3 Message-ID: <065.822399ca21f44df703c1fbf66e53db2e@trac.tools.ietf.org> References: <056.419ff55228378ebc0a4553cb4374780d@trac.tools.ietf.org> X-Trac-Ticket-ID: 32 In-Reply-To: <056.419ff55228378ebc0a4553cb4374780d@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dane-protocol@tools.ietf.org, 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 Resent-To: Resent-Message-Id: <20110921053837.5B22621F8B71@ietfa.amsl.com> Resent-Date: Tue, 20 Sep 2011 22:38:37 -0700 (PDT) Resent-From: trac+dane@trac.tools.ietf.org Cc: dane@ietf.org Subject: Re: [dane] #32: Grouping / combinations of certificates 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: Wed, 21 Sep 2011 05:38:37 -0000 #32: Grouping / combinations of certificates Changes (by matt@…): * status: reopened => closed * resolution: => wontfix -- -------------------------------+-------------------------------------------- Reporter: warren@… | Owner: draft-ietf-dane-protocol@… Type: enhancement | Status: closed Priority: minor | Milestone: Component: protocol | Version: Severity: - | Resolution: wontfix Keywords: | -------------------------------+-------------------------------------------- Ticket URL: dane From ondrej.sury@nic.cz Wed Sep 21 07:41:46 2011 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 C1AB021F8B46 for ; Wed, 21 Sep 2011 07:41:46 -0700 (PDT) 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_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 7oqRHW+mBCKb for ; Wed, 21 Sep 2011 07:41:46 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id EDAF521F8AFD for ; Wed, 21 Sep 2011 07:41:45 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:b929:8340:a3e:deff] (unknown [IPv6:2001:1488:ac14:1400:b929:8340:a3e:deff]) by mail.nic.cz (Postfix) with ESMTPSA id 921952A2CFC; Wed, 21 Sep 2011 16:44:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1316616249; bh=tFeV/V27PDrbFhRe4lH/VPwQZnrPV8WhA7zP0tbGtQU=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=oiUcS4Ss3cQgWdM5aG4Kgp5hbuG3YJfGCoqhnsfJrplb1kS8uChLN6nC2+QFkpWby 7SfAV6DVMCOfc68MOGinM0jfENrSoy37ibdQrDE5ZCV+Vxz2eMo4upW1jZUWhKyilR D6C4BOcW9AlXhgPWoRooV3GPmudJSquukdAgEni0= Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <1316581575.1941.41.camel@localhost> Date: Wed, 21 Sep 2011 16:44:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2419F790-A5E0-4A77-B575-D7D695B9B5F8@nic.cz> References: <05701F4C-3419-40DF-A2E7-8BFF8A3434CA@kumari.net> <20110915131937.GC13546@vacation.karoshi.com.> <1FC517BE-41AD-449F-8864-3770A15D760E@vpnc.org> <1316581575.1941.41.camel@localhost> To: Matt McCutchen X-Mailer: Apple Mail (2.1244.3) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Paul Hoffman , DANE WG Subject: Re: [dane] Reopening issue #22 for discussion.... 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, 21 Sep 2011 14:41:46 -0000 Matt, my understanding of the consensus is that the DANE WG cannot decide strength of the algorithms. As said by somebody before me: "algorithm is either strong-enough or not strong-enough". > a. Publish enough information that the client /can/ achieve the = security > of the "strongest" digest offered by the server. As for #33 (or #22 comment#1) I didn't notice that before, but there's nothing in the DNSSEC protocol about choosing the strongest algorithm (there's only the mess about Carthesian product in the draft). I think we addressed #22 and #33 in one go and both should be closed. Could I receive few +1/-1 from other WG members, so we can either decide this needs more discussion (-1s) or it's already solved as part of #22 (+1s). O. On 21. 9. 2011, at 7:06, Matt McCutchen wrote: > On Thu, 2011-09-15 at 08:34 -0700, Paul Hoffman wrote: >> I would prefer that we do not adopt the proposed design change. >=20 > Do you have an articulable objection to the "provide enough = information" > part of the proposal, now moved to ticket #33, or do you just believe = it > is not worth the effort? >=20 >> Further, I disagree with the part of the problem statement that says >> "clients that support SHA-512 will still accept any certificate that >> matches the SHA-256 digest". Clients that care about different >> strengths can be configured not to do this. >=20 > Sure, but the mass-market browsers will never do that. Whereas, with > the proposal, they would be able to achieve what they believe is the > strongest possible security with every server. I don't care how much > you disdain browsers; we are missing an opportunity to do a greater > service to this large segment of the public. >=20 > --=20 > Matt >=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 warren@kumari.net Wed Sep 21 07:41:54 2011 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 A1DCC21F8AFD for ; Wed, 21 Sep 2011 07:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.165 X-Spam-Level: X-Spam-Status: No, score=-102.165 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, J_CHICKENPOX_23=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 bUEShbZ5O8+v for ; Wed, 21 Sep 2011 07:41:53 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id AA52321F8B58 for ; Wed, 21 Sep 2011 07:41:53 -0700 (PDT) Received: from dhcp-172-19-119-117.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id F14C21B4001D; Wed, 21 Sep 2011 10:44:21 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Warren Kumari In-Reply-To: Date: Wed, 21 Sep 2011 10:44:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7EC3A30D-832A-4B86-92D3-AE391B7454B3@kumari.net> References: <818B5737-219C-4950-8FA5-5B244BF7F692@gmail.com> <201109172302.p8HN2MQs004813@new.toad.com> To: DANE WG X-Mailer: Apple Mail (2.1084) Cc: dane-ads@tools.ietf.org Subject: Re: [dane] #31: Multiple TLSA records in a response 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, 21 Sep 2011 14:41:54 -0000 The chairs have conferred and have decided to call this -- while it is = not unanimous, we do see strong consensus for the "MUST" behavior = described in the text (and our ADs (CCed) have not informed us that we = are overstepping our charter[0]). In order to address Phillip's concerns regarding the "TLS client" = wording, we ask the authors to modify the text to clarify that the = behavior described in the DANE protocol doc only applies things actually = doing DANE and to post a new version of the draft with this = clarification. Some discussions occurred regarding the specific error to returned = ("access_denied") and meaning of "application" -- no better error / = text was provided and so that is how the text currently stands. Warren and Ondrej. [0]: Obviously, if they do, we'll reopen this issue / discussion. On Sep 19, 2011, at 3:10 AM, Ond=C5=99ej Sur=C3=BD wrote: > Hi all, >=20 > could we please get back to technical discussion? >=20 > The discussion seem to get very hot and personal, please could we > _all_ try to stick with the problems opened in this thread (I would=20 > like to fill them as separate issues) and not discuss CAs, RAs, Iran > and other political and human rights stuff? >=20 > We (Warren did) already asked our ADs (Ccing them again just to be = sure) > if we are overstepping our charter here, so let's wait if they = respond. > With my chair hat on, I don't think so, but their opinion may differ > and it doesn't make sense to reiterate the arguments before we have = their > opinion. >=20 > I don't think this discussion helps any progress of the DANE protocol, > so if we can stop it now and here (in the mailing list) I would really > appreciate that. >=20 > Thank you, > -- > 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 rbarnes@bbn.com Wed Sep 21 07:59:16 2011 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 497EE1F0C70 for ; Wed, 21 Sep 2011 07:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.564 X-Spam-Level: X-Spam-Status: No, score=-106.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 HOHEsqYtNNF8 for ; Wed, 21 Sep 2011 07:59:15 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id DB0D51F0C75 for ; Wed, 21 Sep 2011 07:59:14 -0700 (PDT) Received: from ros-dhcp192-1-51-76.bbn.com ([192.1.51.76]:56769) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1R6OIw-000Mr9-Tt; Wed, 21 Sep 2011 11:01:42 -0400 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1084) From: "Richard L. Barnes" In-Reply-To: <061.add9f922b5dfb2db7544981f78552e7e@trac.tools.ietf.org> Date: Wed, 21 Sep 2011 11:01:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6EB199FD-63B2-4FEA-88ED-67DB559148A0@bbn.com> References: <061.add9f922b5dfb2db7544981f78552e7e@trac.tools.ietf.org> To: Matt McCutchen , DANE WG X-Mailer: Apple Mail (2.1084) Subject: Re: [dane] #33: Publish enough information for the client to achieve the security of its favorite digest 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, 21 Sep 2011 14:59:16 -0000 Could you clarify what you mean by "the security of its favorite = digest"? =20 On Sep 21, 2011, at 12:27 AM, dane issue tracker wrote: > #33: Publish enough information for the client to achieve the security = of its > favorite digest >=20 > There was a misunderstanding on ticket:22, so I'm restating the less > controversial part of the proposal here. The possible solutions are = still > those in ticket:22#comment:1. >=20 > --=20 > = ------------------------------------+-------------------------------------= -- > Reporter: matt@=85 | Owner: = draft-ietf-dane-protocol@=85 =20 > Type: defect | Status: new = =20 > Priority: major | Milestone: = =20 > Component: protocol | Version: = =20 > Severity: - | Keywords: = =20 > = ------------------------------------+-------------------------------------= -- >=20 > Ticket URL: > dane >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From paul.hoffman@vpnc.org Wed Sep 21 08:25:40 2011 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 4A0831F0C65 for ; Wed, 21 Sep 2011 08:25:40 -0700 (PDT) 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.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 JMf6u2mUQ0aG for ; Wed, 21 Sep 2011 08:25:39 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id A59AA1F0C5A for ; Wed, 21 Sep 2011 08:25:39 -0700 (PDT) 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 p8LFS7Fe013410 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 21 Sep 2011 08:28:08 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=windows-1252 From: Paul Hoffman In-Reply-To: <6EB199FD-63B2-4FEA-88ED-67DB559148A0@bbn.com> Date: Wed, 21 Sep 2011 08:28:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <061.add9f922b5dfb2db7544981f78552e7e@trac.tools.ietf.org> <6EB199FD-63B2-4FEA-88ED-67DB559148A0@bbn.com> To: Matt McCutchen X-Mailer: Apple Mail (2.1244.3) Cc: DANE WG Subject: Re: [dane] #33: Publish enough information for the client to achieve the security of its favorite digest 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, 21 Sep 2011 15:25:40 -0000 On Sep 21, 2011, at 8:01 AM, Richard L. Barnes wrote: > Could you clarify what you mean by "the security of its favorite = digest"? =20 +1 to the request for clarification. The current protocol says what = digest function is being used by DANE. --Paul Hoffman From warren@kumari.net Wed Sep 21 08:36:40 2011 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 75DA25E800F for ; Wed, 21 Sep 2011 08:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.461 X-Spam-Level: X-Spam-Status: No, score=-102.461 tagged_above=-999 required=5 tests=[AWL=0.138, 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 0afhaHeqX3K7 for ; Wed, 21 Sep 2011 08:36:39 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id BE30E5E800A for ; Wed, 21 Sep 2011 08:36:39 -0700 (PDT) Received: from dhcp-172-19-119-117.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 217741B4001D; Wed, 21 Sep 2011 11:39:08 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: Date: Wed, 21 Sep 2011 11:39:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <670A864B-567A-4351-AB6D-0A373AF66B9B@kumari.net> References: <061.add9f922b5dfb2db7544981f78552e7e@trac.tools.ietf.org> <6EB199FD-63B2-4FEA-88ED-67DB559148A0@bbn.com> To: Paul Hoffman X-Mailer: Apple Mail (2.1084) Cc: DANE WG Subject: Re: [dane] #33: Publish enough information for the client to achieve the security of its favorite digest 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, 21 Sep 2011 15:36:40 -0000 On Sep 21, 2011, at 11:28 AM, Paul Hoffman wrote: > On Sep 21, 2011, at 8:01 AM, Richard L. Barnes wrote: >=20 >> Could you clarify what you mean by "the security of its favorite = digest"? =20 >=20 > +1 to the request for clarification. The current protocol says what = digest function is being used by DANE. +1 again -- and the client gets the TLSA records and can choose "its = favorite" already... W >=20 > --Paul Hoffman >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 From warren@kumari.net Wed Sep 21 09:04:46 2011 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 30FD111E80C7 for ; Wed, 21 Sep 2011 09:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.464 X-Spam-Level: X-Spam-Status: No, score=-102.464 tagged_above=-999 required=5 tests=[AWL=0.135, 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 XGhxCAWkj30e for ; Wed, 21 Sep 2011 09:04:45 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 9C58211E809C for ; Wed, 21 Sep 2011 09:04:45 -0700 (PDT) Received: from dhcp-172-19-119-117.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id E55981B4001B; Wed, 21 Sep 2011 12:07:12 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <000401cc7423$bf343990$3d9cacb0$@augustcellars.com> Date: Wed, 21 Sep 2011 12:07:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <881C47F4-FDE0-43DC-BF7E-D85729D057AE@kumari.net> References: <1E08D85E-3E17-4E30-BF21-6C37E8CE3052@kumari.net> <000401cc7423$bf343990$3d9cacb0$@augustcellars.com> To: DANE WG X-Mailer: Apple Mail (2.1084) Subject: Re: [dane] Opening issues #25, #26, #27 as a group. 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, 21 Sep 2011 16:04:46 -0000 It appears to the chairs that issues #25, #26, #27 are all variations on = a theme and are all predicated on DANE doing [ conjunctive / = disjunctive / grouping / sets ] -- see issue #32, Matt's proposed schema = ( https://www.ietf.org/mail-archive/web/dane/current/msg02637.html ), = etc. We believe that this was viewed by the WG as cool and sexy, but adding = too much additional complexity to the protocol (see the thread around: = http://www.ietf.org/mail-archive/web/dane/current/msg03351.html ). Unless we hear that the WG would like to reconsider this, we are = planning on calling these issues closed. W On Sep 15, 2011, at 11:50 PM, Jim Schaad wrote: > I believe that #27 is a duplicate of #32. >=20 > While I believe that this should be addressed, the current group = consensus > is that it will not be addressed. >=20 > Jim >=20 >=20 >> -----Original Message----- >> From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf = Of >> Warren Kumari >> Sent: Wednesday, September 14, 2011 2:39 PM >> To: DANE WG >> Subject: [dane] Opening issues #25, #26, #27 as a group. >>=20 >> Hi all. >>=20 >> These are all related issues: >> #25: http://trac.tools.ietf.org/wg/dane/trac/ticket/25 - Independent >> additive and restrictive assertions >> #26: http://trac.tools.ietf.org/wg/dane/trac/ticket/26 - Restrictive > assertions >> a conformance requirement, additive ones not? >> #27: http://trac.tools.ietf.org/wg/dane/trac/ticket/27 - Conjunction = of >> restrictions >>=20 >>=20 >> It would be great if we could discuss them as a group, and come to = some > sort >> of consensus by next Friday (September 23rd). >> If commenting on a particular issue number, it would be awesome if = you >> could clearly state which :-P >>=20 >> W >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >=20 From hallam@gmail.com Wed Sep 21 09:15:59 2011 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 BC6871F0CAD for ; Wed, 21 Sep 2011 09:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_QP_LONG_LINE=1.396, 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 Fkbah5E45MS8 for ; Wed, 21 Sep 2011 09:15:59 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id F2D931F0CA9 for ; Wed, 21 Sep 2011 09:15:58 -0700 (PDT) Received: by gyd12 with SMTP id 12so1566035gyd.31 for ; Wed, 21 Sep 2011 09:18:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=SZbp/XZD7THiPSRyqxc7m9iq0p2BRs06vF6XIgCs2eQ=; b=uy5v6Vo2OeFIubmYSo2eVy8KQOGwXILysVfun65NPhzL9nukVibuNtTzzqTrE1vyfG o9WYVBbtZBLTsvMt93zLuzf85l8n+a0LhXWrc50BkJbuBr6vuTjaaqpnf/7LAJxCE3F8 K4H3is9sJ3IkTiZSlIRogC2OcjxwborUp9MjE= Received: by 10.52.20.73 with SMTP id l9mr802953vde.270.1316621905743; Wed, 21 Sep 2011 09:18:25 -0700 (PDT) Received: from [10.0.1.7] (c-66-30-5-63.hsd1.ma.comcast.net. [66.30.5.63]) by mx.google.com with ESMTPS id ie2sm4196757vdb.1.2011.09.21.09.18.23 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 21 Sep 2011 09:18:24 -0700 (PDT) References: <818B5737-219C-4950-8FA5-5B244BF7F692@gmail.com> <201109172302.p8HN2MQs004813@new.toad.com> <7EC3A30D-832A-4B86-92D3-AE391B7454B3@kumari.net> In-Reply-To: <7EC3A30D-832A-4B86-92D3-AE391B7454B3@kumari.net> Mime-Version: 1.0 (iPhone Mail 8C148) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <12168EE8-3402-4D60-B077-62641ADDF5EB@gmail.com> X-Mailer: iPhone Mail (8C148) From: Phillip Hallam-Baker Date: Wed, 21 Sep 2011 12:18:22 -0400 To: Warren Kumari Cc: "dane-ads@tools.ietf.org" , DANE WG Subject: Re: [dane] #31: Multiple TLSA records in a response 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, 21 Sep 2011 16:15:59 -0000 This will be revisited then in IETF last call. Sent from my iPhone On 21 Sep 2011, at 10:44, Warren Kumari wrote: > The chairs have conferred and have decided to call this -- while it is not= unanimous, we do see strong consensus for the "MUST" behavior described in t= he text (and our ADs (CCed) have not informed us that we are overstepping ou= r charter[0]). >=20 > In order to address Phillip's concerns regarding the "TLS client" wording,= we ask the authors to modify the text to clarify that the behavior describe= d in the DANE protocol doc only applies things actually doing DANE and to po= st a new version of the draft with this clarification. >=20 > Some discussions occurred regarding the specific error to returned ("acces= s_denied") and meaning of "application" -- no better error / text was provi= ded and so that is how the text currently stands. >=20 >=20 > Warren and Ondrej. > [0]: Obviously, if they do, we'll reopen this issue / discussion. >=20 >=20 >=20 > On Sep 19, 2011, at 3:10 AM, Ond=C5=99ej Sur=C3=BD wrote: >=20 >> Hi all, >>=20 >> could we please get back to technical discussion? >>=20 >> The discussion seem to get very hot and personal, please could we >> _all_ try to stick with the problems opened in this thread (I would=20 >> like to fill them as separate issues) and not discuss CAs, RAs, Iran >> and other political and human rights stuff? >>=20 >> We (Warren did) already asked our ADs (Ccing them again just to be sure) >> if we are overstepping our charter here, so let's wait if they respond. >> With my chair hat on, I don't think so, but their opinion may differ >> and it doesn't make sense to reiterate the arguments before we have their= >> opinion. >>=20 >> I don't think this discussion helps any progress of the DANE protocol, >> so if we can stop it now and here (in the mailing list) I would really >> appreciate that. >>=20 >> Thank you, >> -- >> 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 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From warren@kumari.net Wed Sep 21 09:16:47 2011 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 DAFFF1F0CA9 for ; Wed, 21 Sep 2011 09:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.167 X-Spam-Level: X-Spam-Status: No, score=-102.167 tagged_above=-999 required=5 tests=[AWL=-0.168, BAYES_00=-2.599, J_CHICKENPOX_23=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 SGZQ2Uxlo-KO for ; Wed, 21 Sep 2011 09:16:47 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 1873C21F8A58 for ; Wed, 21 Sep 2011 09:16:45 -0700 (PDT) Received: from dhcp-172-19-119-117.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 518891B4001B; Wed, 21 Sep 2011 12:19:13 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Warren Kumari In-Reply-To: <12168EE8-3402-4D60-B077-62641ADDF5EB@gmail.com> Date: Wed, 21 Sep 2011 12:19:11 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6CC4D510-78FD-474E-9FB4-E53DB87C08E4@kumari.net> References: <818B5737-219C-4950-8FA5-5B244BF7F692@gmail.com> <201109172302.p8HN2MQs004813@new.toad.com> <7EC3A30D-832A-4B86-92D3-AE391B7454B3@kumari.net> <12168EE8-3402-4D60-B077-62641ADDF5EB@gmail.com> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1084) Cc: "dane-ads@tools.ietf.org" , DANE WG Subject: Re: [dane] #31: Multiple TLSA records in a response 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, 21 Sep 2011 16:16:48 -0000 On Sep 21, 2011, at 12:18 PM, Phillip Hallam-Baker wrote: > This will be revisited then in IETF last call. >=20 Noted. W > Sent from my iPhone >=20 > On 21 Sep 2011, at 10:44, Warren Kumari wrote: >=20 >> The chairs have conferred and have decided to call this -- while it = is not unanimous, we do see strong consensus for the "MUST" behavior = described in the text (and our ADs (CCed) have not informed us that we = are overstepping our charter[0]). >>=20 >> In order to address Phillip's concerns regarding the "TLS client" = wording, we ask the authors to modify the text to clarify that the = behavior described in the DANE protocol doc only applies things actually = doing DANE and to post a new version of the draft with this = clarification. >>=20 >> Some discussions occurred regarding the specific error to returned = ("access_denied") and meaning of "application" -- no better error / = text was provided and so that is how the text currently stands. >>=20 >>=20 >> Warren and Ondrej. >> [0]: Obviously, if they do, we'll reopen this issue / discussion. >>=20 >>=20 >>=20 >> On Sep 19, 2011, at 3:10 AM, Ond=C5=99ej Sur=C3=BD wrote: >>=20 >>> Hi all, >>>=20 >>> could we please get back to technical discussion? >>>=20 >>> The discussion seem to get very hot and personal, please could we >>> _all_ try to stick with the problems opened in this thread (I would=20= >>> like to fill them as separate issues) and not discuss CAs, RAs, Iran >>> and other political and human rights stuff? >>>=20 >>> We (Warren did) already asked our ADs (Ccing them again just to be = sure) >>> if we are overstepping our charter here, so let's wait if they = respond. >>> With my chair hat on, I don't think so, but their opinion may differ >>> and it doesn't make sense to reiterate the arguments before we have = their >>> opinion. >>>=20 >>> I don't think this discussion helps any progress of the DANE = protocol, >>> so if we can stop it now and here (in the mailing list) I would = really >>> appreciate that. >>>=20 >>> Thank you, >>> -- >>> 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 >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >=20 From trac+dane@trac.tools.ietf.org Wed Sep 21 15:16:38 2011 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 1805611E813C for ; Wed, 21 Sep 2011 15:16:38 -0700 (PDT) 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 6nKexfLX2XNh for ; Wed, 21 Sep 2011 15:16:37 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5CD11E80DA for ; Wed, 21 Sep 2011 15:16:37 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1R6V8A-0002NC-DO; Wed, 21 Sep 2011 18:19:02 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: draft-ietf-dane-protocol@tools.ietf.org, warren@kumari.net X-Trac-Project: dane Date: Wed, 21 Sep 2011 22:19:02 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/35 Message-ID: <056.1a974588106d5c2e6a6fd25a8a0d7236@trac.tools.ietf.org> X-Trac-Ticket-ID: 35 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: <20110921221637.6B5CD11E80DA@ietfa.amsl.com> Resent-Date: Wed, 21 Sep 2011 15:16:37 -0700 (PDT) Resent-From: trac+dane@trac.tools.ietf.org Cc: dane@ietf.org Subject: [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: Wed, 21 Sep 2011 22:16:38 -0000 #35: Behavior for a supported algorithm that is not considered "strong" by the client. This was entwined in discussions on Issue #22 and was not fully addressed, so I am opening it to be tracked. From http://www.ietf.org/mail-archive/web/dane/current/msg03366.html : "We do however need to say what a client is to do in the event that a record exists, but the client does not believe that it is a sufficiently strong matching. I.e. if my client says that SHA-1 will not do for anything, what happens if only a SHA-1 record exists. Is this considered to be an unusable statement or a failed statement." -- Jim Schaad and from http://www.ietf.org/mail-archive/web/dane/current/msg03388.html : "My issue is a different one, we "support" the type, but say that it is for some reason not secure. (i.e. the 8-bit add all the bytes together hash function.) In this case I don't know what the behavior should be. I think it should be, this is a usable (I know what it means) but a record which always fails evaluation (i.e. the hash value never matches) and thus if no other usable records exist then the TLS handshake would be aborted." -- Jim Schaad -- -------------------------------+-------------------------------------------- Reporter: warren@… | Owner: draft-ietf-dane-protocol@… Type: enhancement | Status: new Priority: minor | Milestone: Component: protocol | Version: Severity: - | Keywords: -------------------------------+-------------------------------------------- Ticket URL: dane From warren@kumari.net Wed Sep 21 15:22:16 2011 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 29CC31F0CF6 for ; Wed, 21 Sep 2011 15:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.463 X-Spam-Level: X-Spam-Status: No, score=-102.463 tagged_above=-999 required=5 tests=[AWL=0.136, 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 XlsVJygyRGQ7 for ; Wed, 21 Sep 2011 15:22:15 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 584AA1F0CF1 for ; Wed, 21 Sep 2011 15:22:15 -0700 (PDT) Received: from dhcp-172-19-119-117.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 1F80A1B4001B for ; Wed, 21 Sep 2011 18:24:44 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1084) From: Warren Kumari In-Reply-To: <056.1a974588106d5c2e6a6fd25a8a0d7236@trac.tools.ietf.org> Date: Wed, 21 Sep 2011 18:24:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1D25BD4E-3D9A-4B9F-BF63-0204CE89534B@kumari.net> References: <056.1a974588106d5c2e6a6fd25a8a0d7236@trac.tools.ietf.org> To: DANE WG X-Mailer: Apple Mail (2.1084) 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 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, 21 Sep 2011 22:22:16 -0000 Hello all, This will hopefully be short and drama free. Jim raised an interesting question during the Issue #22 discussions = (that was not addressed in #22), and has proposed an answer: " I think it should be, this is a usable (I know what it means) but a = record which always fails evaluation (i.e. the hash value never matches) = and thus if no other usable records exist then the TLS handshake would = be aborted." Does the WG feel that this is the correct behavior *for this case*? (+1 = / -1 ) If so, does the WG feel that text to this effect should be added to the = draft ? (+1 / -1)=20 W On Sep 21, 2011, at 6:19 PM, dane issue tracker wrote: > #35: Behavior for a supported algorithm that is not considered = "strong" by the > client. >=20 > This was entwined in discussions on Issue #22 and was not fully = addressed, > so I am opening it to be tracked. >=20 > =46rom http://www.ietf.org/mail-archive/web/dane/current/msg03366.html = : > "We do however need to say what a client is to do in the event that a > record > exists, but the client does not believe that it is a sufficiently = strong > matching. I.e. if my client says that SHA-1 will not do for anything, > what > happens if only a SHA-1 record exists. Is this considered to be an > unusable > statement or a failed statement." -- Jim Schaad >=20 >=20 >=20 > and from = http://www.ietf.org/mail-archive/web/dane/current/msg03388.html : > "My issue is a different one, we "support" the type, but say that it = is > for > some reason not secure. (i.e. the 8-bit add all the bytes together = hash > function.) In this case I don't know what the behavior should be. I > think > it should be, this is a usable (I know what it means) but a record = which > always fails evaluation (i.e. the hash value never matches) and thus = if no > other usable records exist then the TLS handshake would be aborted." = -- > Jim Schaad >=20 > --=20 > = -------------------------------+------------------------------------------= -- > Reporter: warren@=85 | Owner: = draft-ietf-dane-protocol@=85 =20 > Type: enhancement | Status: new = =20 > Priority: minor | Milestone: = =20 > Component: protocol | Version: = =20 > Severity: - | Keywords: = =20 > = -------------------------------+------------------------------------------= -- >=20 > Ticket URL: > dane >=20 From paul.hoffman@vpnc.org Wed Sep 21 15:44:05 2011 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 492281F0CF9 for ; Wed, 21 Sep 2011 15:44:05 -0700 (PDT) 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 XB0mRWxYgB3F for ; Wed, 21 Sep 2011 15:44:04 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id BAC5B1F0CE4 for ; Wed, 21 Sep 2011 15:44:04 -0700 (PDT) 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 p8LMkXMa063899 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 21 Sep 2011 15:46:34 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=windows-1252 From: Paul Hoffman In-Reply-To: <1D25BD4E-3D9A-4B9F-BF63-0204CE89534B@kumari.net> Date: Wed, 21 Sep 2011 15:46:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <337DB9C1-F674-48B9-8B65-6BD7A34C8E18@vpnc.org> References: <056.1a974588106d5c2e6a6fd25a8a0d7236@trac.tools.ietf.org> <1D25BD4E-3D9A-4B9F-BF63-0204CE89534B@kumari.net> To: Warren Kumari X-Mailer: Apple Mail (2.1244.3) Cc: DANE WG 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 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, 21 Sep 2011 22:44:05 -0000 On Sep 21, 2011, at 3:24 PM, Warren Kumari wrote: > Hello all, >=20 > This will hopefully be short and drama free. >=20 > Jim raised an interesting question during the Issue #22 discussions = (that was not addressed in #22), and has proposed an answer: > " I think it should be, this is a usable (I know what it means) but a = record which always fails evaluation (i.e. the hash value never matches) = and thus if no other usable records exist then the TLS handshake would = be aborted." The relevant text from the current draft says: 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. An application that requests TLS certificate associations using the method described in this document obtains zero or more usable certificate associations. If the application receives zero usable certificate associations, it processes TLS in the normal fashion. On the first match between one of the certificate association(s) and the server's end entity certificate in TLS is found, the TLS client continues the TLS handshake, ignoring remaining certificate associations. If no match between the usable certificate association(s) and the server's end entity certificate in TLS is found, the TLS client MUST abort the handshake with an "access_denied" error. > Does the WG feel that this is the correct behavior *for this case*? = (+1 / -1 ) -1. If you don't trust a hash function, you don't use it to create an = untrusted comparison: you pretend that you don't know the hash function. = Thus, the record is unusable. If there are no other records, then the = text clearly says that the TLS handshake goes on in the normal fashion. > If so, does the WG feel that text to this effect should be added to = the draft ? (+1 / -1)=20 +1, even though this is not "if so". It should be clarified. --Paul Hoffman From hallam@gmail.com Wed Sep 21 17:00:46 2011 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 DDFDF11E80E4 for ; Wed, 21 Sep 2011 17:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.469 X-Spam-Level: X-Spam-Status: No, score=-3.469 tagged_above=-999 required=5 tests=[AWL=0.129, 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 uOe7q3H6+6sN for ; Wed, 21 Sep 2011 17:00:45 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7FFC311E80E7 for ; Wed, 21 Sep 2011 17:00:45 -0700 (PDT) Received: by gxk19 with SMTP id 19so1939713gxk.31 for ; Wed, 21 Sep 2011 17:03:10 -0700 (PDT) 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=1F5+DV1R1Ann3YQ0NXEkaOvG6L8eo28HHnLLMBxzA38=; b=SJhJ1Giqyu/X5loagvfDuYAg3IFb0FfgvnXrtlAKvCCXGBrOD3+0ocPlEr9O4a4DcI S6jmDLhbq/CNIZD8MUR/rHDMQYVWXmQWJXpUrROa4AuJSts9UpC6zsnRkJP5aXx48jhq 2hY13zy2jbDGp1LPLd4h1Rmz/gzp8VMw6MS0M= MIME-Version: 1.0 Received: by 10.101.208.2 with SMTP id k2mr1382653anq.8.1316649789721; Wed, 21 Sep 2011 17:03:09 -0700 (PDT) Received: by 10.101.71.4 with HTTP; Wed, 21 Sep 2011 17:03:09 -0700 (PDT) In-Reply-To: <337DB9C1-F674-48B9-8B65-6BD7A34C8E18@vpnc.org> References: <056.1a974588106d5c2e6a6fd25a8a0d7236@trac.tools.ietf.org> <1D25BD4E-3D9A-4B9F-BF63-0204CE89534B@kumari.net> <337DB9C1-F674-48B9-8B65-6BD7A34C8E18@vpnc.org> Date: Wed, 21 Sep 2011 20:03:09 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=0016e68ee246028bd304ad7c6bf5 Cc: DANE WG 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 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, 22 Sep 2011 00:00:47 -0000 --0016e68ee246028bd304ad7c6bf5 Content-Type: text/plain; charset=ISO-8859-1 Why would anyone implement SHA1 for a new protocol specification? Remember that the DANE records are going to be signed using DNSSEC. Thus there will be two digests involved. If we are in a transition from algorithm A to algorithm B and there is a point to it, then the DNSSEC records and the DANE records must be both specified under both algorithms or there is no point to it. So from a DANE standpoint there should probably be a requirement that there is a digest value for all the algorithms used to sign the zone. Alternatively, it that is considered administratively impractical, there needs to be a DANE record that specifies the digests to expect in the DANE records. On Wed, Sep 21, 2011 at 6:46 PM, Paul Hoffman wrote: > On Sep 21, 2011, at 3:24 PM, Warren Kumari wrote: > > > Hello all, > > > > This will hopefully be short and drama free. > > > > Jim raised an interesting question during the Issue #22 discussions (that > was not addressed in #22), and has proposed an answer: > > " I think it should be, this is a usable (I know what it means) but a > record which always fails evaluation (i.e. the hash value never matches) and > thus if no other usable records exist then the TLS handshake would be > aborted." > > The relevant text from the current draft says: > 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. > > An application that requests TLS certificate associations using the > method described in this document obtains zero or more usable > certificate associations. If the application receives zero usable > certificate associations, it processes TLS in the normal fashion. > > On the first match between one of the certificate association(s) and > the server's end entity certificate in TLS is found, the TLS client > continues the TLS handshake, ignoring remaining certificate > associations. If no match between the usable certificate > association(s) and the server's end entity certificate in TLS is > found, the TLS client MUST abort the handshake with an > "access_denied" error. > > > Does the WG feel that this is the correct behavior *for this case*? (+1 / > -1 ) > > -1. If you don't trust a hash function, you don't use it to create an > untrusted comparison: you pretend that you don't know the hash function. > Thus, the record is unusable. If there are no other records, then the text > clearly says that the TLS handshake goes on in the normal fashion. > > > If so, does the WG feel that text to this effect should be added to the > draft ? (+1 / -1) > > +1, even though this is not "if so". It should be clarified. > > --Paul Hoffman > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > -- Website: http://hallambaker.com/ --0016e68ee246028bd304ad7c6bf5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Why would anyone implement SHA1 for a new protocol specification?

<= /div>

Remember that the DANE records are going to be sig= ned using DNSSEC. Thus there will be two digests involved.=A0
If we are in a transition from algorithm A to algorithm B and th= ere is a point to it, then the DNSSEC records and the DANE records must be = both specified under both algorithms or there is no point to it.


So from a DANE standpoint there should probab= ly be a requirement that there is a digest value for all the algorithms use= d to sign the zone. Alternatively, it that is considered administratively i= mpractical, there needs to be a DANE record that specifies the digests to e= xpect in the DANE records.





On Wed, Sep 21, 2011 at 6:46 PM, Paul Hoffman &= lt;paul.hoffman@vpnc.org> wrote:
On Sep 21, 2011, at 3:24 = PM, Warren Kumari wrote:

> Hello all,
>
> This will hopefully be short and drama free.
>
> Jim raised an interesting question during the Issue #22 discussions (t= hat was not addressed in #22), and has proposed an answer:
> " I think it should be, this is a usable (I know what it means) b= ut a record which always fails evaluation (i.e. the hash value never matche= s) and thus if no other usable records exist then the TLS handshake would b= e aborted."

The relevant text from the current draft says:
=A0 If a certificate association contains a certificate usage, selector, =A0 or matching type that is not understood by the TLS client, that
=A0 certificate association MUST be marked as unusable. =A0If the
=A0 comparison data for a certificate is malformed, the certificate
=A0 association MUST be marked as unusable.

=A0 An application that requests TLS certificate associations using the =A0 method described in this document obtains zero or more usable
=A0 certificate associations. =A0If the application receives zero usable =A0 certificate associations, it processes TLS in the normal fashion.

=A0 On the first match between one of the certificate association(s) and =A0 the server's end entity certificate in TLS is found, the TLS clien= t
=A0 continues the TLS handshake, ignoring remaining certificate
=A0 associations. =A0If no match between the usable certificate
=A0 association(s) and the server's end entity certificate in TLS is =A0 found, the TLS client MUST abort the handshake with an
=A0 "access_denied" error.

> Does the WG feel that this is the correct behavior *for this case*? (+= 1 / -1 )

-1. If you don't trust a hash function, you don't use it to c= reate an untrusted comparison: you pretend that you don't know the hash= function. Thus, the record is unusable. If there are no other records, the= n the text clearly says that the TLS handshake goes on in the normal fashio= n.

> If so, does the WG feel that text to this effect should be added to th= e draft ? (+1 / -1)

+1, even though this is not "if so". It should be clarified= .

--Paul Hoffman

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



--
= Website: http://hallambaker.com/
--0016e68ee246028bd304ad7c6bf5-- From matt@mattmccutchen.net Wed Sep 21 19:24:16 2011 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 EDAA121F86F6 for ; Wed, 21 Sep 2011 19:24:16 -0700 (PDT) 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 OErbkK-yXTUl for ; Wed, 21 Sep 2011 19:24:16 -0700 (PDT) Received: from homiemail-a2.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 53DCD21F86EE for ; Wed, 21 Sep 2011 19:24:16 -0700 (PDT) Received: from homiemail-a2.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a2.g.dreamhost.com (Postfix) with ESMTP id 8146F28006D; Wed, 21 Sep 2011 19:26:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; q=dns; s= mattmccutchen.net; b=SRaRu9kPt2m8Vk+GbIW/yrkVC4hF0wbEajQwF5+R+6D fVFQaedpPGJnk0BnVexAEP93K/e+mx0Wq/pbagoMtFqjd/QTo9wQfTa+9Hhf7+Rg yKmR4+sRXhOUrnVpIUQHSLUNi4ed9V/Sf90CvrOF9KezC1os3S/Pcnu2BE3BmLSg = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; s= mattmccutchen.net; bh=jlwiY+EFtqh8EjGwIiS1SsmQM8c=; b=dddiIX6/SF ufSisIM2hUgV2et4apPWvZ3h/yT/BCiWGJ33bKwdyQ79vpe/EjIRe+Ah5FVIewRi p3/tTffjRbGC6vchsfsFwcTtwDAVo7k7hjoFHMHSHjNLmZ7hVKBEU/tdkLTLWeBR ofi9tYGpFQ7710k1ruH69GqYjDPZRToh4= Received: from [IPv6:::1] (ps7180.dreamhost.com [75.119.218.76]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a2.g.dreamhost.com (Postfix) with ESMTPSA id 52390280063; Wed, 21 Sep 2011 19:26:46 -0700 (PDT) From: Matt McCutchen To: Warren Kumari Date: Wed, 21 Sep 2011 19:26:47 -0700 In-Reply-To: <881C47F4-FDE0-43DC-BF7E-D85729D057AE@kumari.net> References: <1E08D85E-3E17-4E30-BF21-6C37E8CE3052@kumari.net> <000401cc7423$bf343990$3d9cacb0$@augustcellars.com> <881C47F4-FDE0-43DC-BF7E-D85729D057AE@kumari.net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 Content-Transfer-Encoding: 7bit Message-ID: <1316658407.1941.58.camel@localhost> Mime-Version: 1.0 Cc: DANE WG Subject: Re: [dane] Opening issues #25, #26, #27 as a group. 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, 22 Sep 2011 02:24:17 -0000 On Wed, 2011-09-21 at 12:07 -0400, Warren Kumari wrote: > It appears to the chairs that issues #25, #26, #27 are all variations > on a theme and are all predicated on DANE doing [ conjunctive / > disjunctive / grouping / sets ] -- see issue #32, Matt's proposed > schema > ( https://www.ietf.org/mail-archive/web/dane/current/msg02637.html ), > etc. No... that is only true of #27. - #25 can alternatively be done with flags in the RRset. - #26 is purely a policy question, orthogonal to conjunction support. We have at least Phill's and my +1 to address #25. > We believe that this was viewed by the WG as cool and sexy, but adding > too much additional complexity to the protocol (see the thread around: > http://www.ietf.org/mail-archive/web/dane/current/msg03351.html ). > > Unless we hear that the WG would like to reconsider this, we are > planning on calling these issues closed. Does this determination stand (for #27) given my new proposal and remarks in http://www.ietf.org/mail-archive/web/dane/current/msg03418.html ? -- Matt From matt@mattmccutchen.net Wed Sep 21 19:32:41 2011 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 6B1C821F8B74 for ; Wed, 21 Sep 2011 19:32:41 -0700 (PDT) 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 7lyMbS7+A3o0 for ; Wed, 21 Sep 2011 19:32:40 -0700 (PDT) Received: from homiemail-a7.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id D3C2721F8B73 for ; Wed, 21 Sep 2011 19:32:40 -0700 (PDT) Received: from homiemail-a7.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a7.g.dreamhost.com (Postfix) with ESMTP id 318CD25C062; Wed, 21 Sep 2011 19:35:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=Bm08PzQBRPec02JqBUL4XQTwHqungQA+EtzCgx3rW4M JYGF7qleNvaZXRpxdmiMaMgcr+OmhckvpcXOeNwbm1ifBTKAz34tolyyGOZ3/MY1 hjEBvHgG/PhviZNu4EFF22vyZognUPZnbSj7L2/BnwZmfZLjxQx5DtjA0o2GZuGs = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=d2wmrDB4U4atSTY9DvwGtC4DOXU=; b=ApvuYzgBd3 5dtEoQ9sK+x25NyRsdQzDG1r+qD5hAGcCFah9CmmZxXpSQAzAVmBM7zREMWFPXkE U2RjaXC12rblikGsVKtLSAzmV8jdgDZUQoSEsAC3to86AyY5oI68NmrqDytSWLet BH+6/VjUGBd+LPS4ZJ8/9Jxx87+A4eljA= Received: from [IPv6:::1] (ps7180.dreamhost.com [75.119.218.76]) (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 070E625C061; Wed, 21 Sep 2011 19:35:10 -0700 (PDT) From: Matt McCutchen To: Warren Kumari In-Reply-To: <670A864B-567A-4351-AB6D-0A373AF66B9B@kumari.net> References: <061.add9f922b5dfb2db7544981f78552e7e@trac.tools.ietf.org> <6EB199FD-63B2-4FEA-88ED-67DB559148A0@bbn.com> <670A864B-567A-4351-AB6D-0A373AF66B9B@kumari.net> Content-Type: text/plain; charset="UTF-8" Date: Wed, 21 Sep 2011 19:35:06 -0700 Message-ID: <1316658906.1941.63.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 3.0.3 Content-Transfer-Encoding: 7bit Cc: Paul Hoffman , DANE WG Subject: Re: [dane] #33: Publish enough information for the client to achieve the security of its favorite digest 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, 22 Sep 2011 02:32:41 -0000 On Wed, 2011-09-21 at 11:39 -0400, Warren Kumari wrote: > On Sep 21, 2011, at 11:28 AM, Paul Hoffman wrote: > > > On Sep 21, 2011, at 8:01 AM, Richard L. Barnes wrote: > > > >> Could you clarify what you mean by "the security of its favorite digest"? > > > > +1 to the request for clarification. The current protocol says what digest function is being used by DANE. > > +1 again -- and the client gets the TLSA records and can choose "its favorite" already... Suppose I as the client prefer SHA-512 to SHA-256 and wish to achieve the security of SHA-512 whenever possible but still interoperate with servers that do not fully support SHA-512. I receive a TLSA RRset: _443._tcp.example.com TLSA 1 0 SHA-512 xxxx _443._tcp.example.com TLSA 1 0 SHA-256 yyyy And the cert has SHA-256 yyyy but does not have SHA-512 xxxx. Is this a rollover in progress, or is someone trying to attack me via a SHA-256 second preimage? If I try to choose my favorite digest, I fail against servers performing legitimate rollovers. Now do you get the point? -- Matt From paul@xelerance.com Wed Sep 21 20:08:25 2011 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 3AF5421F8B6F for ; Wed, 21 Sep 2011 20:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.495 X-Spam-Level: X-Spam-Status: No, score=-6.495 tagged_above=-999 required=5 tests=[AWL=0.104, 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 6KVUSzXwJOv5 for ; Wed, 21 Sep 2011 20:08:24 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id 9894A21F8B6D for ; Wed, 21 Sep 2011 20:08:24 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 8BDC4C6A6; Wed, 21 Sep 2011 23:09:02 -0400 (EDT) Date: Wed, 21 Sep 2011 23:09:02 -0400 (EDT) From: Paul Wouters To: Matt McCutchen In-Reply-To: <1316658906.1941.63.camel@localhost> Message-ID: References: <061.add9f922b5dfb2db7544981f78552e7e@trac.tools.ietf.org> <6EB199FD-63B2-4FEA-88ED-67DB559148A0@bbn.com> <670A864B-567A-4351-AB6D-0A373AF66B9B@kumari.net> <1316658906.1941.63.camel@localhost> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: DANE WG Subject: Re: [dane] #33: Publish enough information for the client to achieve the security of its favorite digest 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, 22 Sep 2011 03:08:25 -0000 On Wed, 21 Sep 2011, Matt McCutchen wrote: > Suppose I as the client prefer SHA-512 to SHA-256 and wish to achieve > the security of SHA-512 whenever possible but still interoperate with > servers that do not fully support SHA-512. I receive a TLSA RRset: > > _443._tcp.example.com TLSA 1 0 SHA-512 xxxx > _443._tcp.example.com TLSA 1 0 SHA-256 yyyy > > And the cert has SHA-256 yyyy but does not have SHA-512 xxxx. Is this a > rollover in progress, or is someone trying to attack me via a SHA-256 > second preimage? If you are doing a cert rollover, wouldn't you publish: _443._tcp.example.com TLSA 1 0 SHA-512 cert1 _443._tcp.example.com TLSA 1 0 SHA-512 cert2 _443._tcp.example.com TLSA 1 0 SHA-256 cert1 _443._tcp.example.com TLSA 1 0 SHA-256 cert2 (perhaps the last entry omitted if you really deemed the danger worse the losing the old clients) Paul From ietf@augustcellars.com Wed Sep 21 20:29:27 2011 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 BCB4211E80AD for ; Wed, 21 Sep 2011 20:29:27 -0700 (PDT) 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 XvUFgWn1eOWf for ; Wed, 21 Sep 2011 20:29:26 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id A4BE211E80A1 for ; Wed, 21 Sep 2011 20:29:26 -0700 (PDT) Received: from TITUS (173-160-230-153-Washington.hfc.comcastbusiness.net [173.160.230.153]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 082552C9EB; Wed, 21 Sep 2011 20:31:52 -0700 (PDT) From: "Jim Schaad" To: "'Paul Hoffman'" , "'Warren Kumari'" References: <056.1a974588106d5c2e6a6fd25a8a0d7236@trac.tools.ietf.org> <1D25BD4E-3D9A-4B9F-BF63-0204CE89534B@kumari.net> <337DB9C1-F674-48B9-8B65-6BD7A34C8E18@vpnc.org> In-Reply-To: <337DB9C1-F674-48B9-8B65-6BD7A34C8E18@vpnc.org> Date: Wed, 21 Sep 2011 21:09:07 -0700 Message-ID: <016e01cc78dd$600927a0$201b76e0$@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: AQF3oxSVx4We5496HZNtJnQAx78VkgJupxloAXu7tYaV4x9p8A== Content-Language: en-us Cc: 'DANE WG' 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 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, 22 Sep 2011 03:29:27 -0000 Paul, I can completely understand the position that you are taking, and I wish I had a really good reason for saying it is the "wrong" one. Unfortunately I don't. Just to be clear and to make sure that you understand what I believe the implications of you position are: Suppose a host publishes a TLSA record with a matching requirement of matching using the MUST-HASH1 algorithm (i.e. the algorithm is declared a MUST implement by the DANE specification). Suppose I have some super hacker who has come to me and given me a possible proof that MUST-HASH1 algorithm is/has been broken but we have not yet gone public (or any of a number of other reasons including the fact that I don't like the US government and believe that they put a back door into the algorithm). Thus I have stated it will not be used by my clients (thus making them unable to talk to half the world). My client down loads the TLSA records for the website that I am connecting to. It finds the TLSA record for MUST-HASH1 and no other ones and my client is fully DANE aware. Your position is that I should toss out the fact that there is a DANE record in existence and do normal TLS connection processing even though the operator has attempted to give me a piece of good information that have chosen not to believe. In this case it is probable that normal processing would fail rendering the whole thing moot as I would probably not accept the hash algorithm for doing certificate path validation either. As I said, I don't have a good reason for saying your position is incorrect. If the group says that is the correct position I would not argue. I just want the position to be clearly stated. Jim > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of > Paul Hoffman > Sent: Wednesday, September 21, 2011 3:47 PM > To: Warren Kumari > Cc: DANE WG > Subject: Re: [dane] #35: Behavior for a supported algorithm that is not > considered "strong" by the client. > > On Sep 21, 2011, at 3:24 PM, Warren Kumari wrote: > > > Hello all, > > > > This will hopefully be short and drama free. > > > > Jim raised an interesting question during the Issue #22 discussions (that > was not addressed in #22), and has proposed an answer: > > " I think it should be, this is a usable (I know what it means) but a record > which always fails evaluation (i.e. the hash value never matches) and thus if > no other usable records exist then the TLS handshake would be aborted." > > The relevant text from the current draft says: > 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. > > An application that requests TLS certificate associations using the > method described in this document obtains zero or more usable > certificate associations. If the application receives zero usable > certificate associations, it processes TLS in the normal fashion. > > On the first match between one of the certificate association(s) and > the server's end entity certificate in TLS is found, the TLS client > continues the TLS handshake, ignoring remaining certificate > associations. If no match between the usable certificate > association(s) and the server's end entity certificate in TLS is > found, the TLS client MUST abort the handshake with an > "access_denied" error. > > > Does the WG feel that this is the correct behavior *for this case*? (+1 / -1 ) > > -1. If you don't trust a hash function, you don't use it to create an untrusted > comparison: you pretend that you don't know the hash function. Thus, the > record is unusable. If there are no other records, then the text clearly says > that the TLS handshake goes on in the normal fashion. > > > If so, does the WG feel that text to this effect should be added to the draft > ? (+1 / -1) > > +1, even though this is not "if so". It should be clarified. > > --Paul Hoffman > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From ietf@augustcellars.com Wed Sep 21 20:29:30 2011 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 6615A11E80B7 for ; Wed, 21 Sep 2011 20:29:30 -0700 (PDT) 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=[AWL=-0.001, 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 vAcgclV6BZJI for ; Wed, 21 Sep 2011 20:29:26 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id A4A6411E80A0 for ; Wed, 21 Sep 2011 20:29:26 -0700 (PDT) Received: from TITUS (173-160-230-153-Washington.hfc.comcastbusiness.net [173.160.230.153]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 4B9092C9EF; Wed, 21 Sep 2011 20:31:53 -0700 (PDT) From: "Jim Schaad" To: "'Phillip Hallam-Baker'" , "'Paul Hoffman'" References: <056.1a974588106d5c2e6a6fd25a8a0d7236@trac.tools.ietf.org> <1D25BD4E-3D9A-4B9F-BF63-0204CE89534B@kumari.net> <337DB9C1-F674-48B9-8B65-6BD7A34C8E18@vpnc.org> In-Reply-To: Date: Wed, 21 Sep 2011 21:09:07 -0700 Message-ID: <016f01cc78dd$602e89f0$208b9dd0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0170_01CC78A2.B3D3D0A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF3oxSVx4We5496HZNtJnQAx78VkgJupxloAXu7tYYCFsDiyJXSZAQQ Content-Language: en-us Cc: 'DANE WG' 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 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, 22 Sep 2011 03:29:30 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0170_01CC78A2.B3D3D0A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit It's not clear from this what position you are taking. Based on your message I could setup the following straw man proposals, but I doubt any of them would correspond to your actual position: 1. Either you read a message I missed where somebody has suggested that SHA1 be added to the DANE work, or you believe that the fact that I suggested an algorithm might go bad in the future and we should deal with this means that I believe that we should add SHA1 to the current work in order to justify my position. 2. None of the existing algorithms that have been suggested for inclusion in the DANE work will ever go bad and therefore the suggestion that it might go bad and we should address the issue is clear proof that I have no idea of what happens in the real world. 3. We would never be in a position of a catastrophic hash algorithm failure with the current hash algorithms and there is always going to be lots of time to do a transition and all operators are going to be efficient about doing the transition so that new algorithms will always be rolled out in sufficient time. While I am starting to come to the opinion that the DANE effort is truly going to need an operations document and I might be willing to be the author, unless you believe that an operational approach is a sufficient method of addressing the issue I raised, it would be more productive to say that we should do BLAH and additionally add the following to the operations recommendations. Jim From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of Phillip Hallam-Baker Sent: Wednesday, September 21, 2011 5:03 PM To: Paul Hoffman Cc: DANE WG Subject: Re: [dane] #35: Behavior for a supported algorithm that is not considered "strong" by the client. Why would anyone implement SHA1 for a new protocol specification? Remember that the DANE records are going to be signed using DNSSEC. Thus there will be two digests involved. If we are in a transition from algorithm A to algorithm B and there is a point to it, then the DNSSEC records and the DANE records must be both specified under both algorithms or there is no point to it. So from a DANE standpoint there should probably be a requirement that there is a digest value for all the algorithms used to sign the zone. Alternatively, it that is considered administratively impractical, there needs to be a DANE record that specifies the digests to expect in the DANE records. On Wed, Sep 21, 2011 at 6:46 PM, Paul Hoffman wrote: On Sep 21, 2011, at 3:24 PM, Warren Kumari wrote: > Hello all, > > This will hopefully be short and drama free. > > Jim raised an interesting question during the Issue #22 discussions (that was not addressed in #22), and has proposed an answer: > " I think it should be, this is a usable (I know what it means) but a record which always fails evaluation (i.e. the hash value never matches) and thus if no other usable records exist then the TLS handshake would be aborted." The relevant text from the current draft says: 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. An application that requests TLS certificate associations using the method described in this document obtains zero or more usable certificate associations. If the application receives zero usable certificate associations, it processes TLS in the normal fashion. On the first match between one of the certificate association(s) and the server's end entity certificate in TLS is found, the TLS client continues the TLS handshake, ignoring remaining certificate associations. If no match between the usable certificate association(s) and the server's end entity certificate in TLS is found, the TLS client MUST abort the handshake with an "access_denied" error. > Does the WG feel that this is the correct behavior *for this case*? (+1 / -1 ) -1. If you don't trust a hash function, you don't use it to create an untrusted comparison: you pretend that you don't know the hash function. Thus, the record is unusable. If there are no other records, then the text clearly says that the TLS handshake goes on in the normal fashion. > If so, does the WG feel that text to this effect should be added to the draft ? (+1 / -1) +1, even though this is not "if so". It should be clarified. --Paul Hoffman _______________________________________________ dane mailing list dane@ietf.org https://www.ietf.org/mailman/listinfo/dane -- Website: http://hallambaker.com/ ------=_NextPart_000_0170_01CC78A2.B3D3D0A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It’s not clear from this what position you are taking.  = Based on your message I could setup the following straw man proposals, = but I doubt any of them would correspond to your actual = position:

 

1.       =  Either you read a message I missed where somebody has suggested = that SHA1 be added to the DANE work, or you believe that the fact that I = suggested an algorithm might go bad in the future and we should deal = with this means that I believe that we should add SHA1 to the current = work in order to justify my position.

2.       = None of the existing algorithms that have been suggested for = inclusion in the DANE work will ever go bad and therefore the suggestion = that it might go bad and we should address the issue is clear proof that = I have no idea of what happens in the real = world.

3.       = We would never be in a position of a catastrophic hash algorithm = failure with the current hash algorithms and there is always going to be = lots of time to do a transition and all operators are going to be = efficient about doing the transition so that new algorithms will always = be rolled out in sufficient time.

 

While I am starting to come to the opinion that the DANE effort is = truly going to need an operations document and I might be willing to be = the author, unless you believe that an operational approach is a = sufficient method of addressing the issue I raised, it would be more = productive to say that we should do BLAH and additionally add the = following to the operations recommendations.

 

Jim

 

 

From:= = dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of = Phillip Hallam-Baker
Sent: Wednesday, September 21, 2011 = 5:03 PM
To: Paul Hoffman
Cc: DANE = WG
Subject: Re: [dane] #35: Behavior for a supported algorithm = that is not considered "strong" by the = client.

 

Why would = anyone implement SHA1 for a new protocol = specification?

 

 

Remember that the DANE records are going to be signed = using DNSSEC. Thus there will be two digests = involved. 

 

If we are in a transition from algorithm A to = algorithm B and there is a point to it, then the DNSSEC records and the = DANE records must be both specified under both algorithms or there is no = point to it.

 

 

So from a DANE standpoint there should probably be a = requirement that there is a digest value for all the algorithms used to = sign the zone. Alternatively, it that is considered administratively = impractical, there needs to be a DANE record that specifies the digests = to expect in the DANE records.

 

 

 

 

On Wed, Sep 21, 2011 at 6:46 PM, Paul Hoffman <paul.hoffman@vpnc.org> = wrote:

On Sep 21, 2011, at 3:24 PM, Warren = Kumari wrote:

> Hello all,
>
> This will hopefully = be short and drama free.
>
> Jim raised an interesting = question during the Issue #22 discussions (that was not addressed in = #22), and has proposed an answer:
> " I think it should be, = this is a usable (I know what it means) but a record which always fails = evaluation (i.e. the hash value never matches) and thus if no other = usable records exist then the TLS handshake would be = aborted."

The relevant = text from the current draft says:
  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.

  An application that requests TLS certificate = associations using the
  method described in this document = obtains zero or more usable
  certificate associations.  If = the application receives zero usable
  certificate associations, = it processes TLS in the normal fashion.

  On the first match = between one of the certificate association(s) and
  the server's = end entity certificate in TLS is found, the TLS client
  = continues the TLS handshake, ignoring remaining certificate
  = associations.  If no match between the usable certificate
  = association(s) and the server's end entity certificate in TLS = is
  found, the TLS client MUST abort the handshake with = an
  "access_denied" error.


> Does the WG = feel that this is the correct behavior *for this case*? (+1 / -1 = )

-1. If you don't trust a hash = function, you don't use it to create an untrusted comparison: you = pretend that you don't know the hash function. Thus, the record is = unusable. If there are no other records, then the text clearly says that = the TLS handshake goes on in the normal fashion.


> If so, does = the WG feel that text to this effect should be added to the draft ? (+1 = / -1)

+1, even though this is = not "if so". It should be clarified.

--Paul = Hoffman


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



 

--
Website: http://hallambaker.com/

------=_NextPart_000_0170_01CC78A2.B3D3D0A0-- From ietf@augustcellars.com Wed Sep 21 20:43:24 2011 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 EF3621F0C59 for ; Wed, 21 Sep 2011 20:43:24 -0700 (PDT) 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=[AWL=0.000, 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 n7ZRXdt5Hdp4 for ; Wed, 21 Sep 2011 20:43:24 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 788A21F0C44 for ; Wed, 21 Sep 2011 20:43:24 -0700 (PDT) Received: from TITUS (173-160-230-153-Washington.hfc.comcastbusiness.net [173.160.230.153]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id BC4162CA40; Wed, 21 Sep 2011 20:45:54 -0700 (PDT) From: "Jim Schaad" To: "'Matt McCutchen'" , "'Warren Kumari'" References: <061.add9f922b5dfb2db7544981f78552e7e@trac.tools.ietf.org> <6EB199FD-63B2-4FEA-88ED-67DB559148A0@bbn.com> <670A864B-567A-4351-AB6D-0A373AF66B9B@kumari.net> <1316658906.1941.63.camel@localhost> In-Reply-To: <1316658906.1941.63.camel@localhost> Date: Wed, 21 Sep 2011 21:23:09 -0700 Message-ID: <017a01cc78df$55d1e180$0175a480$@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: AQGqV/NYaMZUb0EGgPiIEwsDW0qOvQGQdNE5AbWWykYCjfgEigEVjonilWXBiSA= Content-Language: en-us Cc: 'Paul Hoffman' , 'DANE WG' Subject: Re: [dane] #33: Publish enough information for the client to achieve the security of its favorite digest 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, 22 Sep 2011 03:43:25 -0000 This demonstrates why I have said that an algorithm either is or is not good enough. While it could be doing a roll over, it could also be selecting the certificate based on the criteria that you gave in the TLS handshake and using the same hash algorithm for both the certificate and the TLSA statement. If your client wants to sort the TLSA records and process them in preferred order, there is nothing to prevent that. But you cannot assume that the host operator has the same feeling for the algorithm that you have. Jim > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of > Matt McCutchen > Sent: Wednesday, September 21, 2011 7:35 PM > To: Warren Kumari > Cc: Paul Hoffman; DANE WG > Subject: Re: [dane] #33: Publish enough information for the client to achieve > the security of its favorite digest > > On Wed, 2011-09-21 at 11:39 -0400, Warren Kumari wrote: > > On Sep 21, 2011, at 11:28 AM, Paul Hoffman wrote: > > > > > On Sep 21, 2011, at 8:01 AM, Richard L. Barnes wrote: > > > > > >> Could you clarify what you mean by "the security of its favorite digest"? > > > > > > +1 to the request for clarification. The current protocol says what digest > function is being used by DANE. > > > > +1 again -- and the client gets the TLSA records and can choose "its favorite" > already... > > Suppose I as the client prefer SHA-512 to SHA-256 and wish to achieve the > security of SHA-512 whenever possible but still interoperate with servers that > do not fully support SHA-512. I receive a TLSA RRset: > > _443._tcp.example.com TLSA 1 0 SHA-512 xxxx _443._tcp.example.com TLSA > 1 0 SHA-256 yyyy > > And the cert has SHA-256 yyyy but does not have SHA-512 xxxx. Is this a > rollover in progress, or is someone trying to attack me via a SHA-256 second > preimage? If I try to choose my favorite digest, I fail against servers > performing legitimate rollovers. > > > Now do you get the point? > > -- > Matt > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From matt@mattmccutchen.net Wed Sep 21 21:38:14 2011 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 51DD121F8BEB for ; Wed, 21 Sep 2011 21:38:14 -0700 (PDT) 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=[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 NoC2HKm-54d7 for ; Wed, 21 Sep 2011 21:38:13 -0700 (PDT) Received: from homiemail-a61.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9D70821F8BE7 for ; Wed, 21 Sep 2011 21:38:13 -0700 (PDT) Received: from homiemail-a61.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a61.g.dreamhost.com (Postfix) with ESMTP id D03D0578071; Wed, 21 Sep 2011 21:40:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; q=dns; s= mattmccutchen.net; b=mkLNufKE0NqMK1PjHDnQeyx7nI2hP7thEBGX2F1+rwZ a2VxusWF6cihY9R0deLZwOiax/z3lJl5pxva8/RIW0spQBrdAMRjHJfUhV5yrhKf HzTvE842Irm8+uU9judlvZ5kfk02DAq2XPEILw/+VkJs4+Y9f3UMl05al6R4vU8A = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; s= mattmccutchen.net; bh=uxPbK0IvaGQOq/g3Z0MOO9fac4I=; b=syK7AO4hE5 5iLpIGeQGepiWDVs6vSUfnmnxY9WB2JoEC8O/zUXF7vfgnTxlJfx7xFBKDCvbYGN sMpEswKSUsXeUS7H6lcdCynTFIDy0ez3YzfEIb1RhjW0FA9tHcw+yWmkOso8nM9e XV5Oukne0ozDoM/O3y5WJ7oEqGK3kc7WI= 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-a61.g.dreamhost.com (Postfix) with ESMTPSA id AA682578059; Wed, 21 Sep 2011 21:40:43 -0700 (PDT) From: Matt McCutchen To: Paul Wouters Date: Wed, 21 Sep 2011 21:40:43 -0700 In-Reply-To: References: <061.add9f922b5dfb2db7544981f78552e7e@trac.tools.ietf.org> <6EB199FD-63B2-4FEA-88ED-67DB559148A0@bbn.com> <670A864B-567A-4351-AB6D-0A373AF66B9B@kumari.net> <1316658906.1941.63.camel@localhost> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 Content-Transfer-Encoding: 7bit Message-ID: <1316666443.1941.66.camel@localhost> Mime-Version: 1.0 Cc: DANE WG Subject: Re: [dane] #33: Publish enough information for the client to achieve the security of its favorite digest 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, 22 Sep 2011 04:38:14 -0000 On Wed, 2011-09-21 at 23:09 -0400, Paul Wouters wrote: > On Wed, 21 Sep 2011, Matt McCutchen wrote: > > > Suppose I as the client prefer SHA-512 to SHA-256 and wish to achieve > > the security of SHA-512 whenever possible but still interoperate with > > servers that do not fully support SHA-512. I receive a TLSA RRset: > > > > _443._tcp.example.com TLSA 1 0 SHA-512 xxxx > > _443._tcp.example.com TLSA 1 0 SHA-256 yyyy > > > > And the cert has SHA-256 yyyy but does not have SHA-512 xxxx. Is this a > > rollover in progress, or is someone trying to attack me via a SHA-256 > > second preimage? > > If you are doing a cert rollover, wouldn't you publish: > > _443._tcp.example.com TLSA 1 0 SHA-512 cert1 > _443._tcp.example.com TLSA 1 0 SHA-512 cert2 > _443._tcp.example.com TLSA 1 0 SHA-256 cert1 > _443._tcp.example.com TLSA 1 0 SHA-256 cert2 > > (perhaps the last entry omitted if you really deemed the danger worse the > losing the old clients) Maybe... I guess I shouldn't have said "rollover", but rather "the server arbitrarily decides to publish the SHA-256 of one cert and the SHA-512 of a different cert and then send me the first cert". Stupid, but legitimate; nothing in the spec licenses me to assume that servers won't do that. Adding a Cartesian product requirement is one of the possible solutions. -- Matt From matt@mattmccutchen.net Wed Sep 21 21:57:54 2011 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 EF2DC21F8B1A for ; Wed, 21 Sep 2011 21:57:54 -0700 (PDT) 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 S9WSsYCwydN1 for ; Wed, 21 Sep 2011 21:57:54 -0700 (PDT) Received: from homiemail-a3.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE2521F8B04 for ; Wed, 21 Sep 2011 21:57:54 -0700 (PDT) Received: from homiemail-a3.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a3.g.dreamhost.com (Postfix) with ESMTP id DB3C3284071; Wed, 21 Sep 2011 22:00:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; q=dns; s= mattmccutchen.net; b=NOt499ZbASuu74vHQvtllh/wzzdMoRFJbXMG5V9meJz adAnp4X2BwAa4ozlxWiR/p6XscvbkUGcd31vL1DkKiM+0K88uoivazUtYlTM2pem 5pkX+ZMq0lajWlSMGlsinp9tD2bKMuNehGrulDprixbnqhSobKGktMyle7Rbetv8 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; s= mattmccutchen.net; bh=5CF2/KSkKZLexspSediPFNI/7/o=; b=fD36Ro+Ybl /XoetxMTp2KDD9Q3+nIHKKyX8WMtCl221kC5F5CAr9dMOwtkPHi+ugnq6FnG72tA TeumGxCtDDOg3vYE4BCJgRsdReNTKLYxhg2Oyk1TDSQnW1NVRS+8T6B6nUf/4PMz sz/VoPcnSzDVLDD1Ox6n7ohGcJfFG+/6A= 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 A783B28406E; Wed, 21 Sep 2011 22:00:24 -0700 (PDT) From: Matt McCutchen To: Jim Schaad Date: Wed, 21 Sep 2011 22:00:24 -0700 In-Reply-To: <017a01cc78df$55d1e180$0175a480$@augustcellars.com> References: <061.add9f922b5dfb2db7544981f78552e7e@trac.tools.ietf.org> <6EB199FD-63B2-4FEA-88ED-67DB559148A0@bbn.com> <670A864B-567A-4351-AB6D-0A373AF66B9B@kumari.net> <1316658906.1941.63.camel@localhost> <017a01cc78df$55d1e180$0175a480$@augustcellars.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 Content-Transfer-Encoding: 7bit Message-ID: <1316667624.1941.79.camel@localhost> Mime-Version: 1.0 Cc: 'DANE WG' Subject: Re: [dane] #33: Publish enough information for the client to achieve the security of its favorite digest 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, 22 Sep 2011 04:57:55 -0000 On Wed, 2011-09-21 at 21:23 -0700, Jim Schaad wrote: > This demonstrates why I have said that an algorithm either is or is not good > enough. If you have established minimum security requirements in advance and can simply enforce them, good for you. But most of the world does not operate that way. It's easier to just use the strongest algorithm supported by both sides, and independently work to ensure that both sides support sufficiently strong algorithms. Since the web browser market puts such a premium on availability against all the servers in the world, it will inevitably end up setting a bare-minimum security requirement unless we provide a downgrade-proof way to negotiate the algorithm. > While it could be doing a roll over, it could also be selecting the > certificate based on the criteria that you gave in the TLS handshake and > using the same hash algorithm for both the certificate and the TLSA > statement. Your point is lost on me. Could you write out an example? > If your client wants to sort the TLSA records and process them in preferred > order, there is nothing to prevent that. I don't know what you are getting at by "order"; disjunction is commutative. Did you mean "process only the RRs of the algorithm I consider strongest"? If I do that I'll fail against servers that have perverse but valid configurations, as in the example I gave. > But you cannot assume that the > host operator has the same feeling for the algorithm that you have. What do you mean? The proposals under consideration are: - Indicate which digests are of the same certificate, either via group IDs or by concatenating all the info about one certificate in one RR. - Require that the RRset be a Cartesian product of certs and algorithms. Neither of these involves the server's algorithm preferences in any way. -- Matt From ietf@augustcellars.com Wed Sep 21 22:14:10 2011 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 57FE721F8C1C for ; Wed, 21 Sep 2011 22:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.442 X-Spam-Level: X-Spam-Status: No, score=-3.442 tagged_above=-999 required=5 tests=[AWL=0.157, 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 aadmy3OFSKTc for ; Wed, 21 Sep 2011 22:14:09 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id AE35921F8C17 for ; Wed, 21 Sep 2011 22:14:09 -0700 (PDT) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 0CCEC38F0D; Wed, 21 Sep 2011 22:16:39 -0700 (PDT) From: "Jim Schaad" To: "'Matt McCutchen'" References: <061.add9f922b5dfb2db7544981f78552e7e@trac.tools.ietf.org> <6EB199FD-63B2-4FEA-88ED-67DB559148A0@bbn.com> <670A864B-567A-4351-AB6D-0A373AF66B9B@kumari.net> <1316658906.1941.63.camel@localhost> <017a01cc78df$55d1e180$0175a480$@augustcellars.com> <1316667624.1941.79.camel@localhost> In-Reply-To: <1316667624.1941.79.camel@localhost> Date: Wed, 21 Sep 2011 22:53:54 -0700 Message-ID: <017b01cc78ec$03581160$0a083420$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGqV/NYaMZUb0EGgPiIEwsDW0qOvQGQdNE5AbWWykYCjfgEigEVjoniAee4S/4CLOaLdJVFM5Aw Content-Language: en-us Cc: 'DANE WG' Subject: Re: [dane] #33: Publish enough information for the client to achieve the security of its favorite digest 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, 22 Sep 2011 05:14:10 -0000 > -----Original Message----- > From: Matt McCutchen [mailto:matt@mattmccutchen.net] > Sent: Wednesday, September 21, 2011 10:00 PM > To: Jim Schaad > Cc: 'DANE WG' > Subject: RE: [dane] #33: Publish enough information for the client to = achieve > the security of its favorite digest >=20 > On Wed, 2011-09-21 at 21:23 -0700, Jim Schaad wrote: > > This demonstrates why I have said that an algorithm either is or is > > not good enough. >=20 > If you have established minimum security requirements in advance and = can > simply enforce them, good for you. But most of the world does not = operate > that way. It's easier to just use the strongest algorithm supported = by both > sides, and independently work to ensure that both sides support = sufficiently > strong algorithms. Since the web browser market puts such a premium = on > availability against all the servers in the world, it will inevitably = end up setting a > bare-minimum security requirement unless we provide a downgrade-proof > way to negotiate the algorithm. >=20 > > While it could be doing a roll over, it could also be selecting the > > certificate based on the criteria that you gave in the TLS handshake > > and using the same hash algorithm for both the certificate and the > > TLSA statement. >=20 > Your point is lost on me. Could you write out an example? Suppose the server has an RSA-SHA-256 certificate set and an ECC-SHA-512 = certificate set. There is one SHA-256 TLSA record for the first certificate and one = SHA-512 TLSA record for the second certificate Based on what you state as the algorithms you accept, one or the other = of the certificates is returned as part of the TLS handshake. You then check the received certificate against the two TLSA records and = proceeded. >=20 > > If your client wants to sort the TLSA records and process them in > > preferred order, there is nothing to prevent that. >=20 > I don't know what you are getting at by "order"; disjunction is = commutative. > Did you mean "process only the RRs of the algorithm I consider = strongest"? If I > do that I'll fail against servers that have perverse but valid = configurations, as in > the example I gave. You can process SHA-512 records first and then SHA-256 if that is what = you want to do. You must decide either to process and accept SHA-256 = records or not. If you accept them then you will accept them. There is = no problems. If you choose not to accept them then you have the issue = that I raised and is being addressed under issue #35. Again there is no = configuration problem. =20 >=20 > > But you cannot assume that the > > host operator has the same feeling for the algorithm that you have. >=20 > What do you mean? The proposals under consideration are: >=20 > - Indicate which digests are of the same certificate, either via group = IDs or by > concatenating all the info about one certificate in one RR. > - Require that the RRset be a Cartesian product of certs and = algorithms. You are asking for a new item to be setup that the RRset be a product of = certs and algorithms. That is a new requirement and will cause future = problems. What happens when SHA3 algorithms are introduced. They will = not be in the complete product set and thus cause problems. There is no need to indicate which certificates are setup with which = hash algorithms as all of the TLSA disjoint statements would be = evaluated independently. If your favorite algorithm is not present then you are just out of luck = on wanting to use that algorithm in all cases. You either accept the = algorithm that is present or not. Jim >=20 > Neither of these involves the server's algorithm preferences in any = way. >=20 > -- > Matt From yzw_iplab@163.com Wed Sep 21 22:16:38 2011 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 2549021F8D29 for ; Wed, 21 Sep 2011 22:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.346 X-Spam-Level: *** X-Spam-Status: No, score=3.346 tagged_above=-999 required=5 tests=[AWL=1.741, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] 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 aHq8e2sV+0oI for ; Wed, 21 Sep 2011 22:16:36 -0700 (PDT) Received: from m50-133.163.com (m50-133.163.com [123.125.50.133]) by ietfa.amsl.com (Postfix) with ESMTP id 87A0721F8C00 for ; Wed, 21 Sep 2011 22:16:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=Received:Date:From:To:References:Subject:Message-ID: Mime-Version:Content-Type; bh=pjc/1CeRAkAR4dhm4dPjuJuFrvq+7+TW8g I42xxnfPY=; b=iI4lhFwXD3hQ6XhVHqMmX3dOWVBFRKxYSYBgcTcOEoK3a/3wcA Sk33ZxihFg+mNZRBXWXTlPXvc39BDn/3MhbA0Tzo5JiYeyYVGvDXFb5hqu6wZZgm H4r71P4GgG2Um8HqHQVbZV+pO3kPpWV8lbrSPzSBYCpzBkkWTkLVQe1iY= Received: from lenovo-THINK (unknown [218.241.111.47]) by smtp3 (Coremail) with SMTP id DdGowEA5+1lDxXpOVlrOAw--.987S2; Thu, 22 Sep 2011 13:19:00 +0800 (CST) Date: Thu, 22 Sep 2011 13:19:00 +0800 From: "yzw_iplab" To: "dane" References: Message-ID: <201109221319000027856@163.com> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon608467071305_=====" X-CM-TRANSID: DdGowEA5+1lDxXpOVlrOAw--.987S2 X-Coremail-Antispam: 1Uf129KBjvAXoW3Kw1fWF4xWr4DZw15WF17KFg_yoW8Gr15Xo WrZw4jya1UKw1DAF1DKFsrGrW5GF4rGr45Zr1jqw15G3ZaqF13K34rC3Z7W3s3Ar4Fgr4U J348JayrJrnrGF93n29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7v73VFW2AGmfu7bjvjm3 AaLaJ3UbIYCTnIWIevJa73UjIFyTuYvjxUfyvVDUUUU X-CM-SenderInfo: 512zsxhsoduqqrwthudrp/1tbiYxvCzk0vKeNdVgAAsX Subject: [dane] Optimize the processing of multiple TLSA RRs 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, 22 Sep 2011 05:16:38 -0000 This is a multi-part message in MIME format. --=====003_Dragon608467071305_===== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksYWxsDQpBY2NvcmRpbmcgdG8gdGhlIGJhc2ljIERBTkUgcHJvdG9jb2wsIG11bHRpcGxlIFRM U0EgUlJzIG1heSBiZSBtYWludGFpbmVkIGZvciBvbmUgbmFtZSBhbmQgdGhlIHJlbGF0ZWQgcHJv Y2Vzc2luZyBwcmluY2lwbGUgaXMgZGlzY3Vzc2VkIGluIHRoZSBwYXN0IHNldmVyYWwgZGF5cy4g DQpBbHRob3VnaCBhbnlvbmUgb2YgdGhlIG11bHRpcGxlIFRMU0EgUlJzIGNhbiBiZSB1c2VkIHRv IHN1Y2Nlc3NmdWxseSBhdXRoZW50aWNhdGUgdGhlIHNlcnZlciwgdGhlIHNlcnZlciBtYXkgZ2l2 ZSB0aGVtIGRpZmZlcmVudCBwcmVmZXJlbmNlIGluIHByYWN0aWNlLiANCkZvciBleGFtcGxlLCBf NDQzLl90Y3AuZXhhbXBsZS5jb20gaGFzIHRoZSBmb2xsb3dpbmcgdHdvIFRMU0EgUlJzOg0KXzQ0 My5fdGNwLmV4YW1wbGUuY29tIFRMU0EgMSAwICBwcmlvcml0eT0zICBTSEEtNTEyIHh4eHgNCl80 NDMuX3RjcC5leGFtcGxlLmNvbSBUTFNBIDEgMCAgcHJpb3JpdHk9NCAgU0hBLTI1NiB5eXl5DQpB bHRob3VnaCB0aGUgRE5TIHN5c3RlbSBoYXMgbm8gcmVzcG9uc2liaWxpdHkgdG8gcmFuayB0aGVt IGFjY29yZGluZyB0byB0aGVpciBkaWZmZXJlbnQgcHJpb3JpdGllcyAobWF5IGJlIHRoZSB3ZWln aHQgbWV0cmljIGlzIG5lZWRlZCBpbiBhZGRpdGlvbikgYnV0IGFsd2F5cyBzZW5kIGFsbCB0aGUg YXZhaWxhYmxlIGluZm9ybWF0aW9uIHRvIHRoZSBjbGllbnQsIHRoZSBjbGllbnQgY2FuIG9wdGlt aXplIHRoZSBhdXRoZW50aWNhdGlvbiBwcm9jZXNzIHVzaW5nIHRoZSBSUiB3aXRoIHRoZSBoaWdo ZXN0IHByaW9yaXR5IHdoaWNoIGlzIHNldCBieSB0aGUgVExTIHNlcnZlciBhY2NvcmRpbmcgdG8g aXRzIG93biByZWFsaXN0aWMgY29uc2lkZXJhdGlvbnMuDQpJIHRoaW5rIGl0IGlzIGEgdmVyeSBp bXBvcnRhbnQgYW5kIHVzZWZ1bCBleHRlbnNpb24gb2YgREFORSBwcm90b2NvbC4NCkoNCkJSLA0K Wmhpd2VpIFlhbg0KDQoNCjIwMTEtMDktMjIgDQoNCg0KDQp5endfaXBsYWIgDQoNCg0KDQq3orz+ yMujuiBkYW5lLXJlcXVlc3QgDQq3osvNyrG85KO6IDIwMTEtMDktMjIgIDExOjMyOjE3IA0KytW8 /sjLo7ogZGFuZSANCrOty82juiANCtb3zOKjuiBkYW5lIERpZ2VzdCwgVm9sIDYsIElzc3VlIDI3 IA0KIA0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBkaWdlc3Qgd2l0aG91dCBhbGwgdGhlIGlu ZGl2aWR1YWwgbWVzc2FnZQ0KYXR0YWNobWVudHMgeW91IHdpbGwgbmVlZCB0byB1cGRhdGUgeW91 ciBkaWdlc3Qgb3B0aW9ucyBpbiB5b3VyIGxpc3QNCnN1YnNjcmlwdGlvbi4gIFRvIGRvIHNvLCBn byB0byANCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGFuZQ0KQ2xpY2sg dGhlICdVbnN1YnNjcmliZSBvciBlZGl0IG9wdGlvbnMnIGJ1dHRvbiwgbG9nIGluLCBhbmQgc2V0 ICJHZXQNCk1JTUUgb3IgUGxhaW4gVGV4dCBEaWdlc3RzPyIgdG8gTUlNRS4gIFlvdSBjYW4gc2V0 IHRoaXMgb3B0aW9uDQpnbG9iYWxseSBmb3IgYWxsIHRoZSBsaXN0IGRpZ2VzdHMgeW91IHJlY2Vp dmUgYXQgdGhpcyBwb2ludC4NClNlbmQgZGFuZSBtYWlsaW5nIGxpc3Qgc3VibWlzc2lvbnMgdG8N CmRhbmVAaWV0Zi5vcmcNClRvIHN1YnNjcmliZSBvciB1bnN1YnNjcmliZSB2aWEgdGhlIFdvcmxk IFdpZGUgV2ViLCB2aXNpdA0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9k YW5lDQpvciwgdmlhIGVtYWlsLCBzZW5kIGEgbWVzc2FnZSB3aXRoIHN1YmplY3Qgb3IgYm9keSAn aGVscCcgdG8NCmRhbmUtcmVxdWVzdEBpZXRmLm9yZw0KWW91IGNhbiByZWFjaCB0aGUgcGVyc29u IG1hbmFnaW5nIHRoZSBsaXN0IGF0DQpkYW5lLW93bmVyQGlldGYub3JnDQpXaGVuIHJlcGx5aW5n LCBwbGVhc2UgZWRpdCB5b3VyIFN1YmplY3QgbGluZSBzbyBpdCBpcyBtb3JlIHNwZWNpZmljDQp0 aGFuICJSZTogQ29udGVudHMgb2YgZGFuZSBkaWdlc3QuLi4iDQpUb2RheSdzIFRvcGljczoNCiAg IDEuIFJlOiAjMzM6IFB1Ymxpc2ggZW5vdWdoIGluZm9ybWF0aW9uIGZvciB0aGUgY2xpZW50IHRv IGFjaGlldmUNCiAgICAgIHRoZSBzZWN1cml0eSBvZiBpdHMgZmF2b3JpdGUgZGlnZXN0IChQYXVs IFdvdXRlcnMpDQogICAyLiBSZTogIzM1OiBCZWhhdmlvciBmb3IgYSBzdXBwb3J0ZWQgYWxnb3Jp dGhtIHRoYXQgaXMgbm90DQogICAgICBjb25zaWRlcmVkICJzdHJvbmciIGJ5IHRoZSBjbGllbnQu IChKaW0gU2NoYWFkKQ0KICAgMy4gUmU6ICMzNTogQmVoYXZpb3IgZm9yIGEgc3VwcG9ydGVkIGFs Z29yaXRobSB0aGF0IGlzIG5vdA0KICAgICAgY29uc2lkZXJlZCAic3Ryb25nIiBieSB0aGUgY2xp ZW50LiAoSmltIFNjaGFhZCkNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KRnJvbTogIFBhdWwgV291dGVycyA8cGF1bEB4ZWxlcmFu Y2UuY29tPg0KVG86ICBNYXR0IE1jQ3V0Y2hlbiA8bWF0dEBtYXR0bWNjdXRjaGVuLm5ldD4NClN1 YmplY3Q6ICBSZTogW2RhbmVdICMzMzogUHVibGlzaCBlbm91Z2ggaW5mb3JtYXRpb24gZm9yIHRo ZSBjbGllbnQgdG9hY2hpZXZlIHRoZSBzZWN1cml0eSBvZiBpdHMgZmF2b3JpdGUgZGlnZXN0DQpE YXRlOiAgV2VkMjEgU2VwIDIwMTEgMjM6MDk6MDIgLTA0MDAgKEVEVCkNCk9uIFdlZCwgMjEgU2Vw IDIwMTEsIE1hdHQgTWNDdXRjaGVuIHdyb3RlOg0KPiBTdXBwb3NlIEkgYXMgdGhlIGNsaWVudCBw cmVmZXIgU0hBLTUxMiB0byBTSEEtMjU2IGFuZCB3aXNoIHRvIGFjaGlldmUNCj4gdGhlIHNlY3Vy aXR5IG9mIFNIQS01MTIgd2hlbmV2ZXIgcG9zc2libGUgYnV0IHN0aWxsIGludGVyb3BlcmF0ZSB3 aXRoDQo+IHNlcnZlcnMgdGhhdCBkbyBub3QgZnVsbHkgc3VwcG9ydCBTSEEtNTEyLiAgSSByZWNl aXZlIGEgVExTQSBSUnNldDoNCj4NCj4gXzQ0My5fdGNwLmV4YW1wbGUuY29tIFRMU0EgMSAwIFNI QS01MTIgeHh4eA0KPiBfNDQzLl90Y3AuZXhhbXBsZS5jb20gVExTQSAxIDAgU0hBLTI1NiB5eXl5 DQo+DQo+IEFuZCB0aGUgY2VydCBoYXMgU0hBLTI1NiB5eXl5IGJ1dCBkb2VzIG5vdCBoYXZlIFNI QS01MTIgeHh4eC4gIElzIHRoaXMgYQ0KPiByb2xsb3ZlciBpbiBwcm9ncmVzcywgb3IgaXMgc29t ZW9uZSB0cnlpbmcgdG8gYXR0YWNrIG1lIHZpYSBhIFNIQS0yNTYNCj4gc2Vjb25kIHByZWltYWdl Pw0KSWYgeW91IGFyZSBkb2luZyBhIGNlcnQgcm9sbG92ZXIsIHdvdWxkbid0IHlvdSBwdWJsaXNo Og0KXzQ0My5fdGNwLmV4YW1wbGUuY29tIFRMU0EgMSAwIFNIQS01MTIgY2VydDENCl80NDMuX3Rj cC5leGFtcGxlLmNvbSBUTFNBIDEgMCBTSEEtNTEyIGNlcnQyDQpfNDQzLl90Y3AuZXhhbXBsZS5j b20gVExTQSAxIDAgU0hBLTI1NiBjZXJ0MQ0KXzQ0My5fdGNwLmV4YW1wbGUuY29tIFRMU0EgMSAw IFNIQS0yNTYgY2VydDINCihwZXJoYXBzIHRoZSBsYXN0IGVudHJ5IG9taXR0ZWQgaWYgeW91IHJl YWxseSBkZWVtZWQgdGhlIGRhbmdlciB3b3JzZSB0aGUNCmxvc2luZyB0aGUgb2xkIGNsaWVudHMp DQpQYXVsDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KRnJvbTogICJKaW0gU2NoYWFkIiA8aWV0ZkBhdWd1c3RjZWxsYXJz LmNvbT4NClRvOiAgIidQYXVsIEhvZmZtYW4nIiA8cGF1bC5ob2ZmbWFuQHZwbmMub3JnPg0KICIn V2FycmVuIEt1bWFyaSciIDx3YXJyZW5Aa3VtYXJpLm5ldD4NClN1YmplY3Q6ICBSZTogW2RhbmVd ICMzNTogQmVoYXZpb3IgZm9yIGEgc3VwcG9ydGVkIGFsZ29yaXRobSB0aGF0IGlzbm90IGNvbnNp ZGVyZWQgInN0cm9uZyIgYnkgdGhlIGNsaWVudC4NCkRhdGU6ICBXZWQyMSBTZXAgMjAxMSAyMTow OTowNyAtMDcwMA0KUGF1bCwNCkkgY2FuIGNvbXBsZXRlbHkgdW5kZXJzdGFuZCB0aGUgcG9zaXRp b24gdGhhdCB5b3UgYXJlIHRha2luZywgYW5kIEkgd2lzaCBJDQpoYWQgYSByZWFsbHkgZ29vZCBy ZWFzb24gZm9yIHNheWluZyBpdCBpcyB0aGUgIndyb25nIiBvbmUuICBVbmZvcnR1bmF0ZWx5IEkN CmRvbid0Lg0KSnVzdCB0byBiZSBjbGVhciBhbmQgdG8gbWFrZSBzdXJlIHRoYXQgeW91IHVuZGVy c3RhbmQgd2hhdCBJIGJlbGlldmUgdGhlDQppbXBsaWNhdGlvbnMgb2YgeW91IHBvc2l0aW9uIGFy ZToNClN1cHBvc2UgYSBob3N0IHB1Ymxpc2hlcyBhIFRMU0EgcmVjb3JkIHdpdGggYSBtYXRjaGlu ZyByZXF1aXJlbWVudCBvZg0KbWF0Y2hpbmcgdXNpbmcgdGhlIE1VU1QtSEFTSDEgYWxnb3JpdGht IChpLmUuIHRoZSBhbGdvcml0aG0gaXMgZGVjbGFyZWQgYQ0KTVVTVCBpbXBsZW1lbnQgYnkgdGhl IERBTkUgc3BlY2lmaWNhdGlvbikuDQpTdXBwb3NlIEkgaGF2ZSBzb21lIHN1cGVyIGhhY2tlciB3 aG8gaGFzIGNvbWUgdG8gbWUgYW5kIGdpdmVuIG1lIGEgcG9zc2libGUNCnByb29mIHRoYXQgTVVT VC1IQVNIMSBhbGdvcml0aG0gaXMvaGFzIGJlZW4gYnJva2VuIGJ1dCB3ZSBoYXZlIG5vdCB5ZXQg Z29uZQ0KcHVibGljIChvciBhbnkgb2YgYSBudW1iZXIgb2Ygb3RoZXIgcmVhc29ucyBpbmNsdWRp bmcgdGhlIGZhY3QgdGhhdCBJIGRvbid0DQpsaWtlIHRoZSBVUyBnb3Zlcm5tZW50IGFuZCBiZWxp ZXZlIHRoYXQgdGhleSBwdXQgYSBiYWNrIGRvb3IgaW50byB0aGUNCmFsZ29yaXRobSkuICBUaHVz IEkgaGF2ZSBzdGF0ZWQgaXQgd2lsbCBub3QgYmUgdXNlZCBieSBteSBjbGllbnRzICh0aHVzDQpt YWtpbmcgdGhlbSB1bmFibGUgdG8gdGFsayB0byBoYWxmIHRoZSB3b3JsZCkuDQpNeSBjbGllbnQg ZG93biBsb2FkcyB0aGUgVExTQSByZWNvcmRzIGZvciB0aGUgd2Vic2l0ZSB0aGF0IEkgYW0gY29u bmVjdGluZw0KdG8uICBJdCBmaW5kcyB0aGUgVExTQSByZWNvcmQgZm9yIE1VU1QtSEFTSDEgYW5k IG5vIG90aGVyIG9uZXMgYW5kIG15IGNsaWVudA0KaXMgZnVsbHkgREFORSBhd2FyZS4gIFlvdXIg cG9zaXRpb24gaXMgdGhhdCBJIHNob3VsZCB0b3NzIG91dCB0aGUgZmFjdCB0aGF0DQp0aGVyZSBp cyBhIERBTkUgcmVjb3JkIGluIGV4aXN0ZW5jZSBhbmQgZG8gbm9ybWFsIFRMUyBjb25uZWN0aW9u IHByb2Nlc3NpbmcNCmV2ZW4gdGhvdWdoIHRoZSBvcGVyYXRvciBoYXMgYXR0ZW1wdGVkIHRvIGdp dmUgbWUgYSBwaWVjZSBvZiBnb29kDQppbmZvcm1hdGlvbiB0aGF0IGhhdmUgY2hvc2VuIG5vdCB0 byBiZWxpZXZlLg0KSW4gdGhpcyBjYXNlIGl0IGlzIHByb2JhYmxlIHRoYXQgbm9ybWFsIHByb2Nl c3Npbmcgd291bGQgZmFpbCByZW5kZXJpbmcgdGhlDQp3aG9sZSB0aGluZyBtb290IGFzIEkgd291 bGQgcHJvYmFibHkgbm90IGFjY2VwdCB0aGUgaGFzaCBhbGdvcml0aG0gZm9yIGRvaW5nDQpjZXJ0 aWZpY2F0ZSBwYXRoIHZhbGlkYXRpb24gZWl0aGVyLg0KQXMgSSBzYWlkLCBJIGRvbid0IGhhdmUg YSBnb29kIHJlYXNvbiBmb3Igc2F5aW5nIHlvdXIgcG9zaXRpb24gaXMgaW5jb3JyZWN0Lg0KSWYg dGhlIGdyb3VwIHNheXMgdGhhdCBpcyB0aGUgY29ycmVjdCBwb3NpdGlvbiBJIHdvdWxkIG5vdCBh cmd1ZS4gIEkganVzdA0Kd2FudCB0aGUgcG9zaXRpb24gdG8gYmUgY2xlYXJseSBzdGF0ZWQuDQpK aW0NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogZGFuZS1ib3VuY2VzQGll dGYub3JnIFttYWlsdG86ZGFuZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4gUGF1 bCBIb2ZmbWFuDQo+IFNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDIxLCAyMDExIDM6NDcgUE0N Cj4gVG86IFdhcnJlbiBLdW1hcmkNCj4gQ2M6IERBTkUgV0cNCj4gU3ViamVjdDogUmU6IFtkYW5l XSAjMzU6IEJlaGF2aW9yIGZvciBhIHN1cHBvcnRlZCBhbGdvcml0aG0gdGhhdCBpcyBub3QNCj4g Y29uc2lkZXJlZCAic3Ryb25nIiBieSB0aGUgY2xpZW50Lg0KPiANCj4gT24gU2VwIDIxLCAyMDEx LCBhdCAzOjI0IFBNLCBXYXJyZW4gS3VtYXJpIHdyb3RlOg0KPiANCj4gPiBIZWxsbyBhbGwsDQo+ ID4NCj4gPiBUaGlzIHdpbGwgaG9wZWZ1bGx5IGJlIHNob3J0IGFuZCBkcmFtYSBmcmVlLg0KPiA+ DQo+ID4gSmltIHJhaXNlZCBhbiBpbnRlcmVzdGluZyBxdWVzdGlvbiBkdXJpbmcgdGhlIElzc3Vl ICMyMiBkaXNjdXNzaW9ucw0KKHRoYXQNCj4gd2FzIG5vdCBhZGRyZXNzZWQgaW4gIzIyKSwgYW5k IGhhcyBwcm9wb3NlZCBhbiBhbnN3ZXI6DQo+ID4gIiBJIHRoaW5rIGl0IHNob3VsZCBiZSwgdGhp cyBpcyBhIHVzYWJsZSAoSSBrbm93IHdoYXQgaXQgbWVhbnMpIGJ1dCBhDQpyZWNvcmQNCj4gd2hp Y2ggYWx3YXlzIGZhaWxzIGV2YWx1YXRpb24gKGkuZS4gdGhlIGhhc2ggdmFsdWUgbmV2ZXIgbWF0 Y2hlcykgYW5kIHRodXMNCmlmDQo+IG5vIG90aGVyIHVzYWJsZSByZWNvcmRzIGV4aXN0IHRoZW4g dGhlIFRMUyBoYW5kc2hha2Ugd291bGQgYmUgYWJvcnRlZC4iDQo+IA0KPiBUaGUgcmVsZXZhbnQg dGV4dCBmcm9tIHRoZSBjdXJyZW50IGRyYWZ0IHNheXM6DQo+ICAgIElmIGEgY2VydGlmaWNhdGUg YXNzb2NpYXRpb24gY29udGFpbnMgYSBjZXJ0aWZpY2F0ZSB1c2FnZSwgc2VsZWN0b3IsDQo+ICAg IG9yIG1hdGNoaW5nIHR5cGUgdGhhdCBpcyBub3QgdW5kZXJzdG9vZCBieSB0aGUgVExTIGNsaWVu dCwgdGhhdA0KPiAgICBjZXJ0aWZpY2F0ZSBhc3NvY2lhdGlvbiBNVVNUIGJlIG1hcmtlZCBhcyB1 bnVzYWJsZS4gIElmIHRoZQ0KPiAgICBjb21wYXJpc29uIGRhdGEgZm9yIGEgY2VydGlmaWNhdGUg aXMgbWFsZm9ybWVkLCB0aGUgY2VydGlmaWNhdGUNCj4gICAgYXNzb2NpYXRpb24gTVVTVCBiZSBt YXJrZWQgYXMgdW51c2FibGUuDQo+IA0KPiAgICBBbiBhcHBsaWNhdGlvbiB0aGF0IHJlcXVlc3Rz IFRMUyBjZXJ0aWZpY2F0ZSBhc3NvY2lhdGlvbnMgdXNpbmcgdGhlDQo+ICAgIG1ldGhvZCBkZXNj cmliZWQgaW4gdGhpcyBkb2N1bWVudCBvYnRhaW5zIHplcm8gb3IgbW9yZSB1c2FibGUNCj4gICAg Y2VydGlmaWNhdGUgYXNzb2NpYXRpb25zLiAgSWYgdGhlIGFwcGxpY2F0aW9uIHJlY2VpdmVzIHpl cm8gdXNhYmxlDQo+ICAgIGNlcnRpZmljYXRlIGFzc29jaWF0aW9ucywgaXQgcHJvY2Vzc2VzIFRM UyBpbiB0aGUgbm9ybWFsIGZhc2hpb24uDQo+IA0KPiAgICBPbiB0aGUgZmlyc3QgbWF0Y2ggYmV0 d2VlbiBvbmUgb2YgdGhlIGNlcnRpZmljYXRlIGFzc29jaWF0aW9uKHMpIGFuZA0KPiAgICB0aGUg c2VydmVyJ3MgZW5kIGVudGl0eSBjZXJ0aWZpY2F0ZSBpbiBUTFMgaXMgZm91bmQsIHRoZSBUTFMg Y2xpZW50DQo+ICAgIGNvbnRpbnVlcyB0aGUgVExTIGhhbmRzaGFrZSwgaWdub3JpbmcgcmVtYWlu aW5nIGNlcnRpZmljYXRlDQo+ICAgIGFzc29jaWF0aW9ucy4gIElmIG5vIG1hdGNoIGJldHdlZW4g dGhlIHVzYWJsZSBjZXJ0aWZpY2F0ZQ0KPiAgICBhc3NvY2lhdGlvbihzKSBhbmQgdGhlIHNlcnZl cidzIGVuZCBlbnRpdHkgY2VydGlmaWNhdGUgaW4gVExTIGlzDQo+ICAgIGZvdW5kLCB0aGUgVExT IGNsaWVudCBNVVNUIGFib3J0IHRoZSBoYW5kc2hha2Ugd2l0aCBhbg0KPiAgICAiYWNjZXNzX2Rl bmllZCIgZXJyb3IuDQo+IA0KPiA+IERvZXMgdGhlIFdHIGZlZWwgdGhhdCB0aGlzIGlzIHRoZSBj b3JyZWN0IGJlaGF2aW9yICpmb3IgdGhpcyBjYXNlKj8gKCsxDQovIC0xICkNCj4gDQo+IC0xLiBJ ZiB5b3UgZG9uJ3QgdHJ1c3QgYSBoYXNoIGZ1bmN0aW9uLCB5b3UgZG9uJ3QgdXNlIGl0IHRvIGNy ZWF0ZSBhbg0KdW50cnVzdGVkDQo+IGNvbXBhcmlzb246IHlvdSBwcmV0ZW5kIHRoYXQgeW91IGRv bid0IGtub3cgdGhlIGhhc2ggZnVuY3Rpb24uIFRodXMsIHRoZQ0KPiByZWNvcmQgaXMgdW51c2Fi bGUuIElmIHRoZXJlIGFyZSBubyBvdGhlciByZWNvcmRzLCB0aGVuIHRoZSB0ZXh0IGNsZWFybHkN CnNheXMNCj4gdGhhdCB0aGUgVExTIGhhbmRzaGFrZSBnb2VzIG9uIGluIHRoZSBub3JtYWwgZmFz aGlvbi4NCj4gDQo+ID4gSWYgc28sIGRvZXMgdGhlIFdHIGZlZWwgdGhhdCB0ZXh0IHRvIHRoaXMg ZWZmZWN0IHNob3VsZCBiZSBhZGRlZCB0byB0aGUNCmRyYWZ0DQo+ID8gKCsxIC8gLTEpDQo+IA0K PiArMSwgZXZlbiB0aG91Z2ggdGhpcyBpcyBub3QgImlmIHNvIi4gSXQgc2hvdWxkIGJlIGNsYXJp ZmllZC4NCj4gDQo+IC0tUGF1bCBIb2ZmbWFuDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBkYW5lIG1haWxpbmcgbGlzdA0KPiBkYW5lQGll dGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGFuZQ0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCkZyb206ICAiSmltIFNjaGFhZCIgPGlldGZAYXVndXN0Y2VsbGFycy5jb20+DQpUbzog ICInUGhpbGxpcCBIYWxsYW0tQmFrZXInIiA8aGFsbGFtQGdtYWlsLmNvbT4NCiAiJ1BhdWwgSG9m Zm1hbiciIDxwYXVsLmhvZmZtYW5AdnBuYy5vcmc+DQpTdWJqZWN0OiAgUmU6IFtkYW5lXSAjMzU6 IEJlaGF2aW9yIGZvciBhIHN1cHBvcnRlZCBhbGdvcml0aG0gdGhhdCBpcyBub3Rjb25zaWRlcmVk ICJzdHJvbmciIGJ5IHRoZSBjbGllbnQuDQpEYXRlOiAgV2VkMjEgU2VwIDIwMTEgMjE6MDk6MDcg LTA3MDANCkl0J3Mgbm90IGNsZWFyIGZyb20gdGhpcyB3aGF0IHBvc2l0aW9uIHlvdSBhcmUgdGFr aW5nLiAgQmFzZWQgb24geW91cg0KbWVzc2FnZSBJIGNvdWxkIHNldHVwIHRoZSBmb2xsb3dpbmcg c3RyYXcgbWFuIHByb3Bvc2FscywgYnV0IEkgZG91YnQgYW55IG9mDQp0aGVtIHdvdWxkIGNvcnJl c3BvbmQgdG8geW91ciBhY3R1YWwgcG9zaXRpb246DQoNCjEuICAgICAgICBFaXRoZXIgeW91IHJl YWQgYSBtZXNzYWdlIEkgbWlzc2VkIHdoZXJlIHNvbWVib2R5IGhhcyBzdWdnZXN0ZWQNCnRoYXQg U0hBMSBiZSBhZGRlZCB0byB0aGUgREFORSB3b3JrLCBvciB5b3UgYmVsaWV2ZSB0aGF0IHRoZSBm YWN0IHRoYXQgSQ0Kc3VnZ2VzdGVkIGFuIGFsZ29yaXRobSBtaWdodCBnbyBiYWQgaW4gdGhlIGZ1 dHVyZSBhbmQgd2Ugc2hvdWxkIGRlYWwgd2l0aA0KdGhpcyBtZWFucyB0aGF0IEkgYmVsaWV2ZSB0 aGF0IHdlIHNob3VsZCBhZGQgU0hBMSB0byB0aGUgY3VycmVudCB3b3JrIGluDQpvcmRlciB0byBq dXN0aWZ5IG15IHBvc2l0aW9uLg0KMi4gICAgICAgTm9uZSBvZiB0aGUgZXhpc3RpbmcgYWxnb3Jp dGhtcyB0aGF0IGhhdmUgYmVlbiBzdWdnZXN0ZWQgZm9yDQppbmNsdXNpb24gaW4gdGhlIERBTkUg d29yayB3aWxsIGV2ZXIgZ28gYmFkIGFuZCB0aGVyZWZvcmUgdGhlIHN1Z2dlc3Rpb24NCnRoYXQg aXQgbWlnaHQgZ28gYmFkIGFuZCB3ZSBzaG91bGQgYWRkcmVzcyB0aGUgaXNzdWUgaXMgY2xlYXIg cHJvb2YgdGhhdCBJDQpoYXZlIG5vIGlkZWEgb2Ygd2hhdCBoYXBwZW5zIGluIHRoZSByZWFsIHdv cmxkLg0KMy4gICAgICAgV2Ugd291bGQgbmV2ZXIgYmUgaW4gYSBwb3NpdGlvbiBvZiBhIGNhdGFz dHJvcGhpYyBoYXNoIGFsZ29yaXRobQ0KZmFpbHVyZSB3aXRoIHRoZSBjdXJyZW50IGhhc2ggYWxn b3JpdGhtcyBhbmQgdGhlcmUgaXMgYWx3YXlzIGdvaW5nIHRvIGJlDQpsb3RzIG9mIHRpbWUgdG8g ZG8gYSB0cmFuc2l0aW9uIGFuZCBhbGwgb3BlcmF0b3JzIGFyZSBnb2luZyB0byBiZSBlZmZpY2ll bnQNCmFib3V0IGRvaW5nIHRoZSB0cmFuc2l0aW9uIHNvIHRoYXQgbmV3IGFsZ29yaXRobXMgd2ls bCBhbHdheXMgYmUgcm9sbGVkIG91dA0KaW4gc3VmZmljaWVudCB0aW1lLg0KDQpXaGlsZSBJIGFt IHN0YXJ0aW5nIHRvIGNvbWUgdG8gdGhlIG9waW5pb24gdGhhdCB0aGUgREFORSBlZmZvcnQgaXMg dHJ1bHkNCmdvaW5nIHRvIG5lZWQgYW4gb3BlcmF0aW9ucyBkb2N1bWVudCBhbmQgSSBtaWdodCBi ZSB3aWxsaW5nIHRvIGJlIHRoZQ0KYXV0aG9yLCB1bmxlc3MgeW91IGJlbGlldmUgdGhhdCBhbiBv cGVyYXRpb25hbCBhcHByb2FjaCBpcyBhIHN1ZmZpY2llbnQNCm1ldGhvZCBvZiBhZGRyZXNzaW5n IHRoZSBpc3N1ZSBJIHJhaXNlZCwgaXQgd291bGQgYmUgbW9yZSBwcm9kdWN0aXZlIHRvIHNheQ0K dGhhdCB3ZSBzaG91bGQgZG8gQkxBSCBhbmQgYWRkaXRpb25hbGx5IGFkZCB0aGUgZm9sbG93aW5n IHRvIHRoZSBvcGVyYXRpb25zDQpyZWNvbW1lbmRhdGlvbnMuDQoNCkppbQ0KDQoNCkZyb206IGRh bmUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmRhbmUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mDQpQaGlsbGlwIEhhbGxhbS1CYWtlcg0KU2VudDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIg MjEsIDIwMTEgNTowMyBQTQ0KVG86IFBhdWwgSG9mZm1hbg0KQ2M6IERBTkUgV0cNClN1YmplY3Q6 IFJlOiBbZGFuZV0gIzM1OiBCZWhhdmlvciBmb3IgYSBzdXBwb3J0ZWQgYWxnb3JpdGhtIHRoYXQg aXMgbm90DQpjb25zaWRlcmVkICJzdHJvbmciIGJ5IHRoZSBjbGllbnQuDQoNCldoeSB3b3VsZCBh bnlvbmUgaW1wbGVtZW50IFNIQTEgZm9yIGEgbmV3IHByb3RvY29sIHNwZWNpZmljYXRpb24/DQoN Cg0KUmVtZW1iZXIgdGhhdCB0aGUgREFORSByZWNvcmRzIGFyZSBnb2luZyB0byBiZSBzaWduZWQg dXNpbmcgRE5TU0VDLiBUaHVzDQp0aGVyZSB3aWxsIGJlIHR3byBkaWdlc3RzIGludm9sdmVkLiAN Cg0KSWYgd2UgYXJlIGluIGEgdHJhbnNpdGlvbiBmcm9tIGFsZ29yaXRobSBBIHRvIGFsZ29yaXRo bSBCIGFuZCB0aGVyZSBpcyBhDQpwb2ludCB0byBpdCwgdGhlbiB0aGUgRE5TU0VDIHJlY29yZHMg YW5kIHRoZSBEQU5FIHJlY29yZHMgbXVzdCBiZSBib3RoDQpzcGVjaWZpZWQgdW5kZXIgYm90aCBh bGdvcml0aG1zIG9yIHRoZXJlIGlzIG5vIHBvaW50IHRvIGl0Lg0KDQoNClNvIGZyb20gYSBEQU5F IHN0YW5kcG9pbnQgdGhlcmUgc2hvdWxkIHByb2JhYmx5IGJlIGEgcmVxdWlyZW1lbnQgdGhhdCB0 aGVyZQ0KaXMgYSBkaWdlc3QgdmFsdWUgZm9yIGFsbCB0aGUgYWxnb3JpdGhtcyB1c2VkIHRvIHNp Z24gdGhlIHpvbmUuDQpBbHRlcm5hdGl2ZWx5LCBpdCB0aGF0IGlzIGNvbnNpZGVyZWQgYWRtaW5p c3RyYXRpdmVseSBpbXByYWN0aWNhbCwgdGhlcmUNCm5lZWRzIHRvIGJlIGEgREFORSByZWNvcmQg dGhhdCBzcGVjaWZpZXMgdGhlIGRpZ2VzdHMgdG8gZXhwZWN0IGluIHRoZSBEQU5FDQpyZWNvcmRz Lg0KDQoNCg0KDQpPbiBXZWQsIFNlcCAyMSwgMjAxMSBhdCA2OjQ2IFBNLCBQYXVsIEhvZmZtYW4g PHBhdWwuaG9mZm1hbkB2cG5jLm9yZz4gd3JvdGU6DQpPbiBTZXAgMjEsIDIwMTEsIGF0IDM6MjQg UE0sIFdhcnJlbiBLdW1hcmkgd3JvdGU6DQo+IEhlbGxvIGFsbCwNCj4NCj4gVGhpcyB3aWxsIGhv cGVmdWxseSBiZSBzaG9ydCBhbmQgZHJhbWEgZnJlZS4NCj4NCj4gSmltIHJhaXNlZCBhbiBpbnRl cmVzdGluZyBxdWVzdGlvbiBkdXJpbmcgdGhlIElzc3VlICMyMiBkaXNjdXNzaW9ucyAodGhhdA0K d2FzIG5vdCBhZGRyZXNzZWQgaW4gIzIyKSwgYW5kIGhhcyBwcm9wb3NlZCBhbiBhbnN3ZXI6DQo+ ICIgSSB0aGluayBpdCBzaG91bGQgYmUsIHRoaXMgaXMgYSB1c2FibGUgKEkga25vdyB3aGF0IGl0 IG1lYW5zKSBidXQgYQ0KcmVjb3JkIHdoaWNoIGFsd2F5cyBmYWlscyBldmFsdWF0aW9uIChpLmUu IHRoZSBoYXNoIHZhbHVlIG5ldmVyIG1hdGNoZXMpIGFuZA0KdGh1cyBpZiBubyBvdGhlciB1c2Fi bGUgcmVjb3JkcyBleGlzdCB0aGVuIHRoZSBUTFMgaGFuZHNoYWtlIHdvdWxkIGJlDQphYm9ydGVk LiINClRoZSByZWxldmFudCB0ZXh0IGZyb20gdGhlIGN1cnJlbnQgZHJhZnQgc2F5czoNCiAgSWYg YSBjZXJ0aWZpY2F0ZSBhc3NvY2lhdGlvbiBjb250YWlucyBhIGNlcnRpZmljYXRlIHVzYWdlLCBz ZWxlY3RvciwNCiAgb3IgbWF0Y2hpbmcgdHlwZSB0aGF0IGlzIG5vdCB1bmRlcnN0b29kIGJ5IHRo ZSBUTFMgY2xpZW50LCB0aGF0DQogIGNlcnRpZmljYXRlIGFzc29jaWF0aW9uIE1VU1QgYmUgbWFy a2VkIGFzIHVudXNhYmxlLiAgSWYgdGhlDQogIGNvbXBhcmlzb24gZGF0YSBmb3IgYSBjZXJ0aWZp Y2F0ZSBpcyBtYWxmb3JtZWQsIHRoZSBjZXJ0aWZpY2F0ZQ0KICBhc3NvY2lhdGlvbiBNVVNUIGJl IG1hcmtlZCBhcyB1bnVzYWJsZS4NCiAgQW4gYXBwbGljYXRpb24gdGhhdCByZXF1ZXN0cyBUTFMg Y2VydGlmaWNhdGUgYXNzb2NpYXRpb25zIHVzaW5nIHRoZQ0KICBtZXRob2QgZGVzY3JpYmVkIGlu IHRoaXMgZG9jdW1lbnQgb2J0YWlucyB6ZXJvIG9yIG1vcmUgdXNhYmxlDQogIGNlcnRpZmljYXRl IGFzc29jaWF0aW9ucy4gIElmIHRoZSBhcHBsaWNhdGlvbiByZWNlaXZlcyB6ZXJvIHVzYWJsZQ0K ICBjZXJ0aWZpY2F0ZSBhc3NvY2lhdGlvbnMsIGl0IHByb2Nlc3NlcyBUTFMgaW4gdGhlIG5vcm1h bCBmYXNoaW9uLg0KICBPbiB0aGUgZmlyc3QgbWF0Y2ggYmV0d2VlbiBvbmUgb2YgdGhlIGNlcnRp ZmljYXRlIGFzc29jaWF0aW9uKHMpIGFuZA0KICB0aGUgc2VydmVyJ3MgZW5kIGVudGl0eSBjZXJ0 aWZpY2F0ZSBpbiBUTFMgaXMgZm91bmQsIHRoZSBUTFMgY2xpZW50DQogIGNvbnRpbnVlcyB0aGUg VExTIGhhbmRzaGFrZSwgaWdub3JpbmcgcmVtYWluaW5nIGNlcnRpZmljYXRlDQogIGFzc29jaWF0 aW9ucy4gIElmIG5vIG1hdGNoIGJldHdlZW4gdGhlIHVzYWJsZSBjZXJ0aWZpY2F0ZQ0KICBhc3Nv Y2lhdGlvbihzKSBhbmQgdGhlIHNlcnZlcidzIGVuZCBlbnRpdHkgY2VydGlmaWNhdGUgaW4gVExT IGlzDQogIGZvdW5kLCB0aGUgVExTIGNsaWVudCBNVVNUIGFib3J0IHRoZSBoYW5kc2hha2Ugd2l0 aCBhbg0KICAiYWNjZXNzX2RlbmllZCIgZXJyb3IuDQo+IERvZXMgdGhlIFdHIGZlZWwgdGhhdCB0 aGlzIGlzIHRoZSBjb3JyZWN0IGJlaGF2aW9yICpmb3IgdGhpcyBjYXNlKj8gKCsxIC8NCi0xICkN Ci0xLiBJZiB5b3UgZG9uJ3QgdHJ1c3QgYSBoYXNoIGZ1bmN0aW9uLCB5b3UgZG9uJ3QgdXNlIGl0 IHRvIGNyZWF0ZSBhbg0KdW50cnVzdGVkIGNvbXBhcmlzb246IHlvdSBwcmV0ZW5kIHRoYXQgeW91 IGRvbid0IGtub3cgdGhlIGhhc2ggZnVuY3Rpb24uDQpUaHVzLCB0aGUgcmVjb3JkIGlzIHVudXNh YmxlLiBJZiB0aGVyZSBhcmUgbm8gb3RoZXIgcmVjb3JkcywgdGhlbiB0aGUgdGV4dA0KY2xlYXJs eSBzYXlzIHRoYXQgdGhlIFRMUyBoYW5kc2hha2UgZ29lcyBvbiBpbiB0aGUgbm9ybWFsIGZhc2hp b24uDQo+IElmIHNvLCBkb2VzIHRoZSBXRyBmZWVsIHRoYXQgdGV4dCB0byB0aGlzIGVmZmVjdCBz aG91bGQgYmUgYWRkZWQgdG8gdGhlDQpkcmFmdCA/ICgrMSAvIC0xKQ0KKzEsIGV2ZW4gdGhvdWdo IHRoaXMgaXMgbm90ICJpZiBzbyIuIEl0IHNob3VsZCBiZSBjbGFyaWZpZWQuDQotLVBhdWwgSG9m Zm1hbg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmRh bmUgbWFpbGluZyBsaXN0DQpkYW5lQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2RhbmUNCg0KLS0gDQpXZWJzaXRlOiBodHRwOi8vaGFsbGFtYmFrZXIuY29t Lw0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K ZGFuZSBtYWlsaW5nIGxpc3QNCmRhbmVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vZGFuZQ0K --=====003_Dragon608467071305_===== Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBuYW1lPUdFTkVSQVRPUiBjb250 ZW50PSJNU0hUTUwgOS4wMC44MTEyLjE2NDM0Ij4NCjxTVFlMRT5AZm9udC1mYWNlIHsNCglmb250 LWZhbWlseTogy87M5TsNCn0NCkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBWZXJkYW5hOw0K fQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IEDLzszlOw0KfQ0KQHBhZ2UgU2VjdGlvbjEg e3NpemU6IDU5NS4zcHQgODQxLjlwdDsgbWFyZ2luOiA3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4w cHQ7IGxheW91dC1ncmlkOiAxNS42cHQ7IH0NClAuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJRlk6 IGludGVyLWlkZW9ncmFwaDsgVEVYVC1BTElHTjoganVzdGlmeTsgTUFSR0lOOiAwY20gMGNtIDBw dDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iOyBGT05ULVNJWkU6IDEwLjVwdA0KfQ0K TEkuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJRlk6IGludGVyLWlkZW9ncmFwaDsgVEVYVC1BTElH TjoganVzdGlmeTsgTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcg Um9tYW4iOyBGT05ULVNJWkU6IDEwLjVwdA0KfQ0KRElWLk1zb05vcm1hbCB7DQoJVEVYVC1KVVNU SUZZOiBpbnRlci1pZGVvZ3JhcGg7IFRFWFQtQUxJR046IGp1c3RpZnk7IE1BUkdJTjogMGNtIDBj bSAwcHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgRk9OVC1TSVpFOiAxMC41cHQN Cn0NCkE6bGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lDQp9 DQpTUEFOLk1zb0h5cGVybGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5k ZXJsaW5lDQp9DQpBOnZpc2l0ZWQgew0KCUNPTE9SOiBwdXJwbGU7IFRFWFQtREVDT1JBVElPTjog dW5kZXJsaW5lDQp9DQpTUEFOLk1zb0h5cGVybGlua0ZvbGxvd2VkIHsNCglDT0xPUjogcHVycGxl OyBURVhULURFQ09SQVRJT046IHVuZGVybGluZQ0KfQ0KU1BBTi5FbWFpbFN0eWxlMTcgew0KCUZP TlQtU1RZTEU6IG5vcm1hbDsgRk9OVC1GQU1JTFk6IFZlcmRhbmE7IENPTE9SOiB3aW5kb3d0ZXh0 OyBGT05ULVdFSUdIVDogbm9ybWFsOyBURVhULURFQ09SQVRJT046IG5vbmU7IG1zby1zdHlsZS10 eXBlOiBwZXJzb25hbC1jb21wb3NlDQp9DQpESVYuU2VjdGlvbjEgew0KCXBhZ2U6IFNlY3Rpb24x DQp9DQpVTktOT1dOIHsNCglGT05ULVNJWkU6IDEwcHQNCn0NCkJMT0NLUVVPVEUgew0KCU1BUkdJ Ti1UT1A6IDBweDsgTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tTEVGVDogMmVtDQp9DQpPTCB7 DQoJTUFSR0lOLVRPUDogMHB4OyBNQVJHSU4tQk9UVE9NOiAwcHgNCn0NClVMIHsNCglNQVJHSU4t VE9QOiAwcHg7IE1BUkdJTi1CT1RUT006IDBweA0KfQ0KPC9TVFlMRT4NCjwvSEVBRD4NCjxCT0RZ IHN0eWxlPSJNQVJHSU46IDEwcHg7IEZPTlQtRkFNSUxZOiB2ZXJkYW5hOyBGT05ULVNJWkU6IDEw cHQiPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwIHNpemU9MiBmYWNlPVZlcmRhbmE+DQo8UCBz dHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0Kc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOiBaSC1DTiIgbGFuZz1FTi1VUz48Rk9OVCBzaXplPTI+PEZP TlQgDQpjb2xvcj0jMDAwMDAwPkhpLGFsbDw/eG1sOm5hbWVzcGFjZSBwcmVmaXggPSBvIG5zID0g DQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiAvPjxvOnA+PC9vOnA+ PC9GT05UPjwvRk9OVD48L1NQQU4+PC9QPg0KPFAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQi IGNsYXNzPU1zb05vcm1hbD48U1BBTiANCnN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTogWkgt Q04iIGxhbmc9RU4tVVM+PEZPTlQgc2l6ZT0yPjxGT05UIA0KY29sb3I9IzAwMDAwMD5BY2NvcmRp bmcgdG8gdGhlIGJhc2ljIERBTkUgcHJvdG9jb2wsIG11bHRpcGxlIFRMU0EgUlJzIG1heSBiZSAN Cm1haW50YWluZWQgZm9yIG9uZSBuYW1lIGFuZCB0aGUgcmVsYXRlZCBwcm9jZXNzaW5nIHByaW5j aXBsZSBpcyBkaXNjdXNzZWQgaW4gdGhlIA0KcGFzdCBzZXZlcmFsIGRheXMuIDxvOnA+PC9vOnA+ PC9GT05UPjwvRk9OVD48L1NQQU4+PC9QPg0KPFAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQi IGNsYXNzPU1zb05vcm1hbD48U1BBTiANCnN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTogWkgt Q04iIGxhbmc9RU4tVVM+PEZPTlQgc2l6ZT0yPjxGT05UIA0KY29sb3I9IzAwMDAwMD5BbHRob3Vn aCBhbnlvbmUgb2YgdGhlIG11bHRpcGxlIFRMU0EgUlJzIGNhbiBiZSB1c2VkIHRvIA0Kc3VjY2Vz c2Z1bGx5IGF1dGhlbnRpY2F0ZSB0aGUgc2VydmVyLCB0aGUgc2VydmVyIG1heSBnaXZlIHRoZW0g ZGlmZmVyZW50IA0KcHJlZmVyZW5jZSBpbiBwcmFjdGljZS4gPG86cD48L286cD48L0ZPTlQ+PC9G T05UPjwvU1BBTj48L1A+DQo8UCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9TXNv Tm9ybWFsPjxTUEFOIA0Kc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOiBaSC1DTiIgbGFuZz1F Ti1VUz48Rk9OVCBzaXplPTI+PEZPTlQgDQpjb2xvcj0jMDAwMDAwPkZvciBleGFtcGxlLCBfNDQz Ll90Y3AuZXhhbXBsZS5jb20gaGFzIHRoZSBmb2xsb3dpbmcgdHdvIFRMU0EgDQpSUnM6PG86cD48 L286cD48L0ZPTlQ+PC9GT05UPjwvU1BBTj48L1A+DQo8UCBzdHlsZT0iVEVYVC1JTkRFTlQ6IDIx cHQ7IE1BUkdJTjogMGNtIDBjbSAwcHQiIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCnN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTogWkgtQ04iIGxhbmc9RU4tVVM+PEZPTlQgc2l6ZT0yPjxGT05U IA0KY29sb3I9IzAwMDAwMD5fNDQzLl90Y3AuZXhhbXBsZS5jb20gVExTQSAxIDAgPFNQQU4gDQpz dHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOzwvU1BBTj5wcmlvcml0eT08QiANCnN0eWxl PSJtc28tYmlkaS1mb250LXdlaWdodDogbm9ybWFsIj4zPC9CPjxTUEFOIHN0eWxlPSJtc28tc3Bh Y2VydW46IHllcyI+Jm5ic3A7IA0KPC9TUEFOPlNIQS01MTIgeHh4eDxvOnA+PC9vOnA+PC9GT05U PjwvRk9OVD48L1NQQU4+PC9QPg0KPFAgc3R5bGU9IlRFWFQtSU5ERU5UOiAyMXB0OyBNQVJHSU46 IDBjbSAwY20gMHB0IiBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQpzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6IFpILUNOIiBsYW5nPUVOLVVTPjxGT05UIHNpemU9Mj48Rk9OVCANCmNvbG9yPSMw MDAwMDA+XzQ0My5fdGNwLmV4YW1wbGUuY29tIFRMU0EgMSAwIDxTUEFOIA0Kc3R5bGU9Im1zby1z cGFjZXJ1bjogeWVzIj4mbmJzcDs8L1NQQU4+cHJpb3JpdHk9PEIgDQpzdHlsZT0ibXNvLWJpZGkt Zm9udC13ZWlnaHQ6IG5vcm1hbCI+NDwvQj48U1BBTiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMi PiZuYnNwOyANCjwvU1BBTj5TSEEtMjU2IHl5eXk8bzpwPjwvbzpwPjwvRk9OVD48L0ZPTlQ+PC9T UEFOPjwvUD4NCjxQIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz1Nc29Ob3JtYWw+ PFNQQU4gDQpzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IFpILUNOIiBsYW5nPUVOLVVTPjxG T05UIHNpemU9Mj48Rk9OVCANCmNvbG9yPSMwMDAwMDA+QWx0aG91Z2ggdGhlIEROUyBzeXN0ZW0g aGFzIG5vIHJlc3BvbnNpYmlsaXR5IHRvIHJhbmsgdGhlbSANCmFjY29yZGluZyB0byB0aGVpciBk aWZmZXJlbnQgcHJpb3JpdGllcyAobWF5IGJlIHRoZSB3ZWlnaHQgbWV0cmljIGlzIG5lZWRlZCBp biANCmFkZGl0aW9uKSBidXQgYWx3YXlzIHNlbmQgYWxsIHRoZSBhdmFpbGFibGUgaW5mb3JtYXRp b24gdG8gdGhlIGNsaWVudCwgdGhlIA0KY2xpZW50IGNhbiBvcHRpbWl6ZSB0aGUgYXV0aGVudGlj YXRpb24gcHJvY2VzcyB1c2luZyB0aGUgUlIgd2l0aCB0aGUgaGlnaGVzdCANCnByaW9yaXR5IHdo aWNoIGlzIHNldCBieSB0aGUgVExTIHNlcnZlciBhY2NvcmRpbmcgdG8gaXRzIG93biByZWFsaXN0 aWMgDQpjb25zaWRlcmF0aW9ucy48bzpwPjwvbzpwPjwvRk9OVD48L0ZPTlQ+PC9TUEFOPjwvUD4N CjxQIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQpz dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IFpILUNOIiBsYW5nPUVOLVVTPjxGT05UIHNpemU9 Mj48Rk9OVCANCmNvbG9yPSMwMDAwMDA+SSB0aGluayBpdCBpcyBhIHZlcnkgaW1wb3J0YW50IGFu ZCB1c2VmdWwgZXh0ZW5zaW9uIG9mIERBTkUgDQpwcm90b2NvbC48bzpwPjwvbzpwPjwvRk9OVD48 L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz1N c29Ob3JtYWw+PEZPTlQgc2l6ZT0yPjxGT05UIA0KY29sb3I9IzAwMDAwMD48U1BBTiANCnN0eWxl PSJGT05ULUZBTUlMWTogV2luZ2RpbmdzOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogWkgtQ047IG1z by1hc2NpaS1mb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1oYW5zaS1mb250LWZh bWlseTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1jaGFyLXR5cGU6IHN5bWJvbDsgbXNvLXN5bWJv bC1mb250LWZhbWlseTogV2luZ2RpbmdzIiANCmxhbmc9RU4tVVM+PFNQQU4gDQpzdHlsZT0ibXNv LWNoYXItdHlwZTogc3ltYm9sOyBtc28tc3ltYm9sLWZvbnQtZmFtaWx5OiBXaW5nZGluZ3MiPko8 L1NQQU4+PC9TUEFOPjxTUEFOIA0Kc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOiBaSC1DTiIg DQpsYW5nPUVOLVVTPjxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L0ZPTlQ+PC9QPg0KPFAgc3R5 bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCnN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTogWkgtQ04iIGxhbmc9RU4tVVM+PEZPTlQgc2l6ZT0yPjxGT05U IA0KY29sb3I9IzAwMDAwMD5CUiw8bzpwPjwvbzpwPjwvRk9OVD48L0ZPTlQ+PC9TUEFOPjwvUD4N CjxQIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0IiBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQpz dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IFpILUNOIiBsYW5nPUVOLVVTPjxGT05UIHNpemU9 Mj48Rk9OVCANCmNvbG9yPSMwMDAwMDA+Wmhpd2VpIFlhbjxvOnA+PC9vOnA+PC9GT05UPjwvRk9O VD48L1NQQU4+PC9QPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDA4MCBmYWNl PVZlcmRhbmE+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwIGZh Y2U9VmVyZGFuYT48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSNjMGMwYzAg ZmFjZT1WZXJkYW5hPjIwMTEtMDktMjIgPC9GT05UPjwvRElWPjxGT05UIA0KY29sb3I9IzAwMDA4 MCBmYWNlPVZlcmRhbmE+DQo8SFIgc3R5bGU9IldJRFRIOiAxMDBweCIgYWxpZ249bGVmdCBjb2xv cj0jYjVjNGRmIFNJWkU9MT4NCjwvRk9OVD4NCjxESVY+PEZPTlQgY29sb3I9I2MwYzBjMCBmYWNl PVZlcmRhbmE+PFNQQU4+eXp3X2lwbGFiPC9TUEFOPiA8L0ZPTlQ+PC9ESVY+DQo8SFIgY29sb3I9 I2I1YzRkZiBTSVpFPTE+DQoNCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hPjxTVFJPTkc+t6K8/sjL o7o8L1NUUk9ORz4gZGFuZS1yZXF1ZXN0IDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1W ZXJkYW5hPjxTVFJPTkc+t6LLzcqxvOSjujwvU1RST05HPiAyMDExLTA5LTIyJm5ic3A7IDExOjMy OjE3IA0KPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmE+PFNUUk9ORz7K1bz+ yMujujwvU1RST05HPiBkYW5lIDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5h PjxTVFJPTkc+s63LzaO6PC9TVFJPTkc+IDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1W ZXJkYW5hPjxTVFJPTkc+1vfM4qO6PC9TVFJPTkc+IGRhbmUgRGlnZXN0LCBWb2wgNiwgSXNzdWUg MjcgDQo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYT48L0ZPTlQ+IDwvRElW Pg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmE+DQo8RElWPklmJm5ic3A7eW91Jm5ic3A7aGF2ZSZu YnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2RpZ2VzdCZuYnNwO3dpdGhvdXQmbmJzcDthbGwm bmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7bWVzc2FnZTwvRElWPg0KPERJVj5hdHRhY2ht ZW50cyZuYnNwO3lvdSZuYnNwO3dpbGwmbmJzcDtuZWVkJm5ic3A7dG8mbmJzcDt1cGRhdGUmbmJz cDt5b3VyJm5ic3A7ZGlnZXN0Jm5ic3A7b3B0aW9ucyZuYnNwO2luJm5ic3A7eW91ciZuYnNwO2xp c3Q8L0RJVj4NCjxESVY+c3Vic2NyaXB0aW9uLiZuYnNwOyZuYnNwO1RvJm5ic3A7ZG8mbmJzcDtz bywmbmJzcDtnbyZuYnNwO3RvJm5ic3A7PC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RhbmU8L0RJVj4NCjxESVY+PC9ESVY+DQo8 RElWPkNsaWNrJm5ic3A7dGhlJm5ic3A7J1Vuc3Vic2NyaWJlJm5ic3A7b3ImbmJzcDtlZGl0Jm5i c3A7b3B0aW9ucycmbmJzcDtidXR0b24sJm5ic3A7bG9nJm5ic3A7aW4sJm5ic3A7YW5kJm5ic3A7 c2V0Jm5ic3A7IkdldDwvRElWPg0KPERJVj5NSU1FJm5ic3A7b3ImbmJzcDtQbGFpbiZuYnNwO1Rl eHQmbmJzcDtEaWdlc3RzPyImbmJzcDt0byZuYnNwO01JTUUuJm5ic3A7Jm5ic3A7WW91Jm5ic3A7 Y2FuJm5ic3A7c2V0Jm5ic3A7dGhpcyZuYnNwO29wdGlvbjwvRElWPg0KPERJVj5nbG9iYWxseSZu YnNwO2ZvciZuYnNwO2FsbCZuYnNwO3RoZSZuYnNwO2xpc3QmbmJzcDtkaWdlc3RzJm5ic3A7eW91 Jm5ic3A7cmVjZWl2ZSZuYnNwO2F0Jm5ic3A7dGhpcyZuYnNwO3BvaW50LjwvRElWPg0KPERJVj48 L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj5TZW5kJm5ic3A7ZGFuZSZuYnNw O21haWxpbmcmbmJzcDtsaXN0Jm5ic3A7c3VibWlzc2lvbnMmbmJzcDt0bzwvRElWPg0KPERJVj5k YW5lQGlldGYub3JnPC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj5UbyZuYnNwO3N1YnNjcmliZSZu YnNwO29yJm5ic3A7dW5zdWJzY3JpYmUmbmJzcDt2aWEmbmJzcDt0aGUmbmJzcDtXb3JsZCZuYnNw O1dpZGUmbmJzcDtXZWIsJm5ic3A7dmlzaXQ8L0RJVj4NCjxESVY+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9kYW5lPC9ESVY+DQo8RElWPm9yLCZuYnNwO3ZpYSZuYnNwO2Vt YWlsLCZuYnNwO3NlbmQmbmJzcDthJm5ic3A7bWVzc2FnZSZuYnNwO3dpdGgmbmJzcDtzdWJqZWN0 Jm5ic3A7b3ImbmJzcDtib2R5Jm5ic3A7J2hlbHAnJm5ic3A7dG88L0RJVj4NCjxESVY+ZGFuZS1y ZXF1ZXN0QGlldGYub3JnPC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj5Zb3UmbmJzcDtjYW4mbmJz cDtyZWFjaCZuYnNwO3RoZSZuYnNwO3BlcnNvbiZuYnNwO21hbmFnaW5nJm5ic3A7dGhlJm5ic3A7 bGlzdCZuYnNwO2F0PC9ESVY+DQo8RElWPmRhbmUtb3duZXJAaWV0Zi5vcmc8L0RJVj4NCjxESVY+ PC9ESVY+DQo8RElWPldoZW4mbmJzcDtyZXBseWluZywmbmJzcDtwbGVhc2UmbmJzcDtlZGl0Jm5i c3A7eW91ciZuYnNwO1N1YmplY3QmbmJzcDtsaW5lJm5ic3A7c28mbmJzcDtpdCZuYnNwO2lzJm5i c3A7bW9yZSZuYnNwO3NwZWNpZmljPC9ESVY+DQo8RElWPnRoYW4mbmJzcDsiUmU6Jm5ic3A7Q29u dGVudHMmbmJzcDtvZiZuYnNwO2RhbmUmbmJzcDtkaWdlc3QuLi4iPC9ESVY+DQo8RElWPjwvRElW Pg0KPERJVj5Ub2RheSdzJm5ic3A7VG9waWNzOjwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+Jm5i c3A7Jm5ic3A7Jm5ic3A7MS4mbmJzcDtSZTombmJzcDsjMzM6Jm5ic3A7UHVibGlzaCZuYnNwO2Vu b3VnaCZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7Y2xpZW50Jm5ic3A7 dG8mbmJzcDthY2hpZXZlPC9ESVY+DQo8RElWPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwO3RoZSZuYnNwO3NlY3VyaXR5Jm5ic3A7b2YmbmJzcDtpdHMmbmJzcDtmYXZvcml0ZSZu YnNwO2RpZ2VzdCZuYnNwOyhQYXVsJm5ic3A7V291dGVycyk8L0RJVj4NCjxESVY+Jm5ic3A7Jm5i c3A7Jm5ic3A7Mi4mbmJzcDtSZTombmJzcDsjMzU6Jm5ic3A7QmVoYXZpb3ImbmJzcDtmb3ImbmJz cDthJm5ic3A7c3VwcG9ydGVkJm5ic3A7YWxnb3JpdGhtJm5ic3A7dGhhdCZuYnNwO2lzIA0Kbm90 PC9ESVY+DQo8RElWPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2NvbnNpZGVy ZWQmbmJzcDsic3Ryb25nIiZuYnNwO2J5Jm5ic3A7dGhlJm5ic3A7Y2xpZW50LiZuYnNwOyhKaW0m bmJzcDtTY2hhYWQpPC9ESVY+DQo8RElWPiZuYnNwOyZuYnNwOyZuYnNwOzMuJm5ic3A7UmU6Jm5i c3A7IzM1OiZuYnNwO0JlaGF2aW9yJm5ic3A7Zm9yJm5ic3A7YSZuYnNwO3N1cHBvcnRlZCZuYnNw O2FsZ29yaXRobSZuYnNwO3RoYXQmbmJzcDtpcyZuYnNwO25vdDwvRElWPg0KPERJVj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtjb25zaWRlcmVkJm5ic3A7InN0cm9uZyImbmJz cDtieSZuYnNwO3RoZSZuYnNwO2NsaWVudC4mbmJzcDsoSmltJm5ic3A7U2NoYWFkKTwvRElWPg0K PERJVj48L0RJVj4NCjxESVY+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9ESVY+DQo8RElWPkZyb206Jm5ic3A7Jm5ic3A7UGF1bCZu YnNwO1dvdXRlcnMmbmJzcDsmbHQ7cGF1bEB4ZWxlcmFuY2UuY29tJmd0OzwvRElWPg0KPERJVj5U bzombmJzcDsmbmJzcDtNYXR0Jm5ic3A7TWNDdXRjaGVuJm5ic3A7Jmx0O21hdHRAbWF0dG1jY3V0 Y2hlbi5uZXQmZ3Q7PC9ESVY+DQo8RElWPlN1YmplY3Q6Jm5ic3A7Jm5ic3A7UmU6Jm5ic3A7W2Rh bmVdJm5ic3A7IzMzOiZuYnNwO1B1Ymxpc2gmbmJzcDtlbm91Z2gmbmJzcDtpbmZvcm1hdGlvbiZu YnNwO2ZvciZuYnNwO3RoZSZuYnNwO2NsaWVudCZuYnNwO3RvYWNoaWV2ZSZuYnNwO3RoZSZuYnNw O3NlY3VyaXR5Jm5ic3A7b2YmbmJzcDtpdHMmbmJzcDtmYXZvcml0ZSZuYnNwO2RpZ2VzdDwvRElW Pg0KPERJVj5EYXRlOiZuYnNwOyZuYnNwO1dlZDIxJm5ic3A7U2VwJm5ic3A7MjAxMSZuYnNwOzIz OjA5OjAyJm5ic3A7LTA0MDAmbmJzcDsoRURUKTwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+T24m bmJzcDtXZWQsJm5ic3A7MjEmbmJzcDtTZXAmbmJzcDsyMDExLCZuYnNwO01hdHQmbmJzcDtNY0N1 dGNoZW4mbmJzcDt3cm90ZTo8L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPiZndDsmbmJzcDtTdXBw b3NlJm5ic3A7SSZuYnNwO2FzJm5ic3A7dGhlJm5ic3A7Y2xpZW50Jm5ic3A7cHJlZmVyJm5ic3A7 U0hBLTUxMiZuYnNwO3RvJm5ic3A7U0hBLTI1NiZuYnNwO2FuZCZuYnNwO3dpc2gmbmJzcDt0byZu YnNwO2FjaGlldmU8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO3RoZSZuYnNwO3NlY3VyaXR5Jm5ic3A7 b2YmbmJzcDtTSEEtNTEyJm5ic3A7d2hlbmV2ZXImbmJzcDtwb3NzaWJsZSZuYnNwO2J1dCZuYnNw O3N0aWxsJm5ic3A7aW50ZXJvcGVyYXRlJm5ic3A7d2l0aDwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7 c2VydmVycyZuYnNwO3RoYXQmbmJzcDtkbyZuYnNwO25vdCZuYnNwO2Z1bGx5Jm5ic3A7c3VwcG9y dCZuYnNwO1NIQS01MTIuJm5ic3A7Jm5ic3A7SSZuYnNwO3JlY2VpdmUmbmJzcDthJm5ic3A7VExT QSZuYnNwO1JSc2V0OjwvRElWPg0KPERJVj4mZ3Q7PC9ESVY+DQo8RElWPiZndDsmbmJzcDtfNDQz Ll90Y3AuZXhhbXBsZS5jb20mbmJzcDtUTFNBJm5ic3A7MSZuYnNwOzAmbmJzcDtTSEEtNTEyJm5i c3A7eHh4eDwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7XzQ0My5fdGNwLmV4YW1wbGUuY29tJm5ic3A7 VExTQSZuYnNwOzEmbmJzcDswJm5ic3A7U0hBLTI1NiZuYnNwO3l5eXk8L0RJVj4NCjxESVY+Jmd0 OzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7QW5kJm5ic3A7dGhlJm5ic3A7Y2VydCZuYnNwO2hhcyZu YnNwO1NIQS0yNTYmbmJzcDt5eXl5Jm5ic3A7YnV0Jm5ic3A7ZG9lcyZuYnNwO25vdCZuYnNwO2hh dmUmbmJzcDtTSEEtNTEyJm5ic3A7eHh4eC4mbmJzcDsmbmJzcDtJcyZuYnNwO3RoaXMmbmJzcDth PC9ESVY+DQo8RElWPiZndDsmbmJzcDtyb2xsb3ZlciZuYnNwO2luJm5ic3A7cHJvZ3Jlc3MsJm5i c3A7b3ImbmJzcDtpcyZuYnNwO3NvbWVvbmUmbmJzcDt0cnlpbmcmbmJzcDt0byZuYnNwO2F0dGFj ayZuYnNwO21lJm5ic3A7dmlhJm5ic3A7YSZuYnNwO1NIQS0yNTY8L0RJVj4NCjxESVY+Jmd0OyZu YnNwO3NlY29uZCZuYnNwO3ByZWltYWdlPzwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+SWYmbmJz cDt5b3UmbmJzcDthcmUmbmJzcDtkb2luZyZuYnNwO2EmbmJzcDtjZXJ0Jm5ic3A7cm9sbG92ZXIs Jm5ic3A7d291bGRuJ3QmbmJzcDt5b3UmbmJzcDtwdWJsaXNoOjwvRElWPg0KPERJVj48L0RJVj4N CjxESVY+XzQ0My5fdGNwLmV4YW1wbGUuY29tJm5ic3A7VExTQSZuYnNwOzEmbmJzcDswJm5ic3A7 U0hBLTUxMiZuYnNwO2NlcnQxPC9ESVY+DQo8RElWPl80NDMuX3RjcC5leGFtcGxlLmNvbSZuYnNw O1RMU0EmbmJzcDsxJm5ic3A7MCZuYnNwO1NIQS01MTImbmJzcDtjZXJ0MjwvRElWPg0KPERJVj5f NDQzLl90Y3AuZXhhbXBsZS5jb20mbmJzcDtUTFNBJm5ic3A7MSZuYnNwOzAmbmJzcDtTSEEtMjU2 Jm5ic3A7Y2VydDE8L0RJVj4NCjxESVY+XzQ0My5fdGNwLmV4YW1wbGUuY29tJm5ic3A7VExTQSZu YnNwOzEmbmJzcDswJm5ic3A7U0hBLTI1NiZuYnNwO2NlcnQyPC9ESVY+DQo8RElWPjwvRElWPg0K PERJVj4ocGVyaGFwcyZuYnNwO3RoZSZuYnNwO2xhc3QmbmJzcDtlbnRyeSZuYnNwO29taXR0ZWQm bmJzcDtpZiZuYnNwO3lvdSZuYnNwO3JlYWxseSZuYnNwO2RlZW1lZCZuYnNwO3RoZSZuYnNwO2Rh bmdlciZuYnNwO3dvcnNlJm5ic3A7dGhlPC9ESVY+DQo8RElWPmxvc2luZyZuYnNwO3RoZSZuYnNw O29sZCZuYnNwO2NsaWVudHMpPC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj5QYXVsPC9ESVY+DQo8 RElWPjwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9ESVY+DQo8RElWPi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvRElWPg0K PERJVj5Gcm9tOiZuYnNwOyZuYnNwOyJKaW0mbmJzcDtTY2hhYWQiJm5ic3A7Jmx0O2lldGZAYXVn dXN0Y2VsbGFycy5jb20mZ3Q7PC9ESVY+DQo8RElWPlRvOiZuYnNwOyZuYnNwOyInUGF1bCZuYnNw O0hvZmZtYW4nIiZuYnNwOyZsdDtwYXVsLmhvZmZtYW5AdnBuYy5vcmcmZ3Q7PC9ESVY+DQo8RElW PiZuYnNwOyInV2FycmVuJm5ic3A7S3VtYXJpJyImbmJzcDsmbHQ7d2FycmVuQGt1bWFyaS5uZXQm Z3Q7PC9ESVY+DQo8RElWPlN1YmplY3Q6Jm5ic3A7Jm5ic3A7UmU6Jm5ic3A7W2RhbmVdJm5ic3A7 IzM1OiZuYnNwO0JlaGF2aW9yJm5ic3A7Zm9yJm5ic3A7YSZuYnNwO3N1cHBvcnRlZCZuYnNwO2Fs Z29yaXRobSZuYnNwO3RoYXQmbmJzcDtpc25vdCANCmNvbnNpZGVyZWQmbmJzcDsic3Ryb25nIiZu YnNwO2J5Jm5ic3A7dGhlJm5ic3A7Y2xpZW50LjwvRElWPg0KPERJVj5EYXRlOiZuYnNwOyZuYnNw O1dlZDIxJm5ic3A7U2VwJm5ic3A7MjAxMSZuYnNwOzIxOjA5OjA3Jm5ic3A7LTA3MDA8L0RJVj4N CjxESVY+PC9ESVY+DQo8RElWPlBhdWwsPC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj5JJm5ic3A7 Y2FuJm5ic3A7Y29tcGxldGVseSZuYnNwO3VuZGVyc3RhbmQmbmJzcDt0aGUmbmJzcDtwb3NpdGlv biZuYnNwO3RoYXQmbmJzcDt5b3UmbmJzcDthcmUmbmJzcDt0YWtpbmcsJm5ic3A7YW5kJm5ic3A7 SSZuYnNwO3dpc2gmbmJzcDtJPC9ESVY+DQo8RElWPmhhZCZuYnNwO2EmbmJzcDtyZWFsbHkmbmJz cDtnb29kJm5ic3A7cmVhc29uJm5ic3A7Zm9yJm5ic3A7c2F5aW5nJm5ic3A7aXQmbmJzcDtpcyZu YnNwO3RoZSZuYnNwOyJ3cm9uZyImbmJzcDtvbmUuJm5ic3A7Jm5ic3A7VW5mb3J0dW5hdGVseSZu YnNwO0k8L0RJVj4NCjxESVY+ZG9uJ3QuPC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj5KdXN0Jm5i c3A7dG8mbmJzcDtiZSZuYnNwO2NsZWFyJm5ic3A7YW5kJm5ic3A7dG8mbmJzcDttYWtlJm5ic3A7 c3VyZSZuYnNwO3RoYXQmbmJzcDt5b3UmbmJzcDt1bmRlcnN0YW5kJm5ic3A7d2hhdCZuYnNwO0km bmJzcDtiZWxpZXZlJm5ic3A7dGhlPC9ESVY+DQo8RElWPmltcGxpY2F0aW9ucyZuYnNwO29mJm5i c3A7eW91Jm5ic3A7cG9zaXRpb24mbmJzcDthcmU6PC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj5T dXBwb3NlJm5ic3A7YSZuYnNwO2hvc3QmbmJzcDtwdWJsaXNoZXMmbmJzcDthJm5ic3A7VExTQSZu YnNwO3JlY29yZCZuYnNwO3dpdGgmbmJzcDthJm5ic3A7bWF0Y2hpbmcmbmJzcDtyZXF1aXJlbWVu dCZuYnNwO29mPC9ESVY+DQo8RElWPm1hdGNoaW5nJm5ic3A7dXNpbmcmbmJzcDt0aGUmbmJzcDtN VVNULUhBU0gxJm5ic3A7YWxnb3JpdGhtJm5ic3A7KGkuZS4mbmJzcDt0aGUmbmJzcDthbGdvcml0 aG0mbmJzcDtpcyZuYnNwO2RlY2xhcmVkJm5ic3A7YTwvRElWPg0KPERJVj5NVVNUJm5ic3A7aW1w bGVtZW50Jm5ic3A7YnkmbmJzcDt0aGUmbmJzcDtEQU5FJm5ic3A7c3BlY2lmaWNhdGlvbikuPC9E SVY+DQo8RElWPjwvRElWPg0KPERJVj5TdXBwb3NlJm5ic3A7SSZuYnNwO2hhdmUmbmJzcDtzb21l Jm5ic3A7c3VwZXImbmJzcDtoYWNrZXImbmJzcDt3aG8mbmJzcDtoYXMmbmJzcDtjb21lJm5ic3A7 dG8mbmJzcDttZSZuYnNwO2FuZCZuYnNwO2dpdmVuJm5ic3A7bWUmbmJzcDthJm5ic3A7cG9zc2li bGU8L0RJVj4NCjxESVY+cHJvb2YmbmJzcDt0aGF0Jm5ic3A7TVVTVC1IQVNIMSZuYnNwO2FsZ29y aXRobSZuYnNwO2lzL2hhcyZuYnNwO2JlZW4mbmJzcDticm9rZW4mbmJzcDtidXQmbmJzcDt3ZSZu YnNwO2hhdmUmbmJzcDtub3QmbmJzcDt5ZXQmbmJzcDtnb25lPC9ESVY+DQo8RElWPnB1YmxpYyZu YnNwOyhvciZuYnNwO2FueSZuYnNwO29mJm5ic3A7YSZuYnNwO251bWJlciZuYnNwO29mJm5ic3A7 b3RoZXImbmJzcDtyZWFzb25zJm5ic3A7aW5jbHVkaW5nJm5ic3A7dGhlJm5ic3A7ZmFjdCZuYnNw O3RoYXQmbmJzcDtJJm5ic3A7ZG9uJ3Q8L0RJVj4NCjxESVY+bGlrZSZuYnNwO3RoZSZuYnNwO1VT Jm5ic3A7Z292ZXJubWVudCZuYnNwO2FuZCZuYnNwO2JlbGlldmUmbmJzcDt0aGF0Jm5ic3A7dGhl eSZuYnNwO3B1dCZuYnNwO2EmbmJzcDtiYWNrJm5ic3A7ZG9vciZuYnNwO2ludG8mbmJzcDt0aGU8 L0RJVj4NCjxESVY+YWxnb3JpdGhtKS4mbmJzcDsmbmJzcDtUaHVzJm5ic3A7SSZuYnNwO2hhdmUm bmJzcDtzdGF0ZWQmbmJzcDtpdCZuYnNwO3dpbGwmbmJzcDtub3QmbmJzcDtiZSZuYnNwO3VzZWQm bmJzcDtieSZuYnNwO215Jm5ic3A7Y2xpZW50cyZuYnNwOyh0aHVzPC9ESVY+DQo8RElWPm1ha2lu ZyZuYnNwO3RoZW0mbmJzcDt1bmFibGUmbmJzcDt0byZuYnNwO3RhbGsmbmJzcDt0byZuYnNwO2hh bGYmbmJzcDt0aGUmbmJzcDt3b3JsZCkuPC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj5NeSZuYnNw O2NsaWVudCZuYnNwO2Rvd24mbmJzcDtsb2FkcyZuYnNwO3RoZSZuYnNwO1RMU0EmbmJzcDtyZWNv cmRzJm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7d2Vic2l0ZSZuYnNwO3RoYXQmbmJzcDtJJm5ic3A7 YW0mbmJzcDtjb25uZWN0aW5nPC9ESVY+DQo8RElWPnRvLiZuYnNwOyZuYnNwO0l0Jm5ic3A7Zmlu ZHMmbmJzcDt0aGUmbmJzcDtUTFNBJm5ic3A7cmVjb3JkJm5ic3A7Zm9yJm5ic3A7TVVTVC1IQVNI MSZuYnNwO2FuZCZuYnNwO25vJm5ic3A7b3RoZXImbmJzcDtvbmVzJm5ic3A7YW5kJm5ic3A7bXkm bmJzcDtjbGllbnQ8L0RJVj4NCjxESVY+aXMmbmJzcDtmdWxseSZuYnNwO0RBTkUmbmJzcDthd2Fy ZS4mbmJzcDsmbmJzcDtZb3VyJm5ic3A7cG9zaXRpb24mbmJzcDtpcyZuYnNwO3RoYXQmbmJzcDtJ Jm5ic3A7c2hvdWxkJm5ic3A7dG9zcyZuYnNwO291dCZuYnNwO3RoZSZuYnNwO2ZhY3QmbmJzcDt0 aGF0PC9ESVY+DQo8RElWPnRoZXJlJm5ic3A7aXMmbmJzcDthJm5ic3A7REFORSZuYnNwO3JlY29y ZCZuYnNwO2luJm5ic3A7ZXhpc3RlbmNlJm5ic3A7YW5kJm5ic3A7ZG8mbmJzcDtub3JtYWwmbmJz cDtUTFMmbmJzcDtjb25uZWN0aW9uJm5ic3A7cHJvY2Vzc2luZzwvRElWPg0KPERJVj5ldmVuJm5i c3A7dGhvdWdoJm5ic3A7dGhlJm5ic3A7b3BlcmF0b3ImbmJzcDtoYXMmbmJzcDthdHRlbXB0ZWQm bmJzcDt0byZuYnNwO2dpdmUmbmJzcDttZSZuYnNwO2EmbmJzcDtwaWVjZSZuYnNwO29mJm5ic3A7 Z29vZDwvRElWPg0KPERJVj5pbmZvcm1hdGlvbiZuYnNwO3RoYXQmbmJzcDtoYXZlJm5ic3A7Y2hv c2VuJm5ic3A7bm90Jm5ic3A7dG8mbmJzcDtiZWxpZXZlLjwvRElWPg0KPERJVj48L0RJVj4NCjxE SVY+SW4mbmJzcDt0aGlzJm5ic3A7Y2FzZSZuYnNwO2l0Jm5ic3A7aXMmbmJzcDtwcm9iYWJsZSZu YnNwO3RoYXQmbmJzcDtub3JtYWwmbmJzcDtwcm9jZXNzaW5nJm5ic3A7d291bGQmbmJzcDtmYWls Jm5ic3A7cmVuZGVyaW5nJm5ic3A7dGhlPC9ESVY+DQo8RElWPndob2xlJm5ic3A7dGhpbmcmbmJz cDttb290Jm5ic3A7YXMmbmJzcDtJJm5ic3A7d291bGQmbmJzcDtwcm9iYWJseSZuYnNwO25vdCZu YnNwO2FjY2VwdCZuYnNwO3RoZSZuYnNwO2hhc2gmbmJzcDthbGdvcml0aG0mbmJzcDtmb3ImbmJz cDtkb2luZzwvRElWPg0KPERJVj5jZXJ0aWZpY2F0ZSZuYnNwO3BhdGgmbmJzcDt2YWxpZGF0aW9u Jm5ic3A7ZWl0aGVyLjwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+QXMmbmJzcDtJJm5ic3A7c2Fp ZCwmbmJzcDtJJm5ic3A7ZG9uJ3QmbmJzcDtoYXZlJm5ic3A7YSZuYnNwO2dvb2QmbmJzcDtyZWFz b24mbmJzcDtmb3ImbmJzcDtzYXlpbmcmbmJzcDt5b3VyJm5ic3A7cG9zaXRpb24mbmJzcDtpcyZu YnNwO2luY29ycmVjdC48L0RJVj4NCjxESVY+SWYmbmJzcDt0aGUmbmJzcDtncm91cCZuYnNwO3Nh eXMmbmJzcDt0aGF0Jm5ic3A7aXMmbmJzcDt0aGUmbmJzcDtjb3JyZWN0Jm5ic3A7cG9zaXRpb24m bmJzcDtJJm5ic3A7d291bGQmbmJzcDtub3QmbmJzcDthcmd1ZS4mbmJzcDsmbmJzcDtJJm5ic3A7 anVzdDwvRElWPg0KPERJVj53YW50Jm5ic3A7dGhlJm5ic3A7cG9zaXRpb24mbmJzcDt0byZuYnNw O2JlJm5ic3A7Y2xlYXJseSZuYnNwO3N0YXRlZC48L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPkpp bTwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPiZndDsmbmJzcDstLS0tLU9y aWdpbmFsJm5ic3A7TWVzc2FnZS0tLS0tPC9ESVY+DQo8RElWPiZndDsmbmJzcDtGcm9tOiZuYnNw O2RhbmUtYm91bmNlc0BpZXRmLm9yZyZuYnNwO1ttYWlsdG86ZGFuZS1ib3VuY2VzQGlldGYub3Jn XSZuYnNwO09uJm5ic3A7QmVoYWxmJm5ic3A7T2Y8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO1BhdWwm bmJzcDtIb2ZmbWFuPC9ESVY+DQo8RElWPiZndDsmbmJzcDtTZW50OiZuYnNwO1dlZG5lc2RheSwm bmJzcDtTZXB0ZW1iZXImbmJzcDsyMSwmbmJzcDsyMDExJm5ic3A7Mzo0NyZuYnNwO1BNPC9ESVY+ DQo8RElWPiZndDsmbmJzcDtUbzombmJzcDtXYXJyZW4mbmJzcDtLdW1hcmk8L0RJVj4NCjxESVY+ Jmd0OyZuYnNwO0NjOiZuYnNwO0RBTkUmbmJzcDtXRzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7U3Vi amVjdDombmJzcDtSZTombmJzcDtbZGFuZV0mbmJzcDsjMzU6Jm5ic3A7QmVoYXZpb3ImbmJzcDtm b3ImbmJzcDthJm5ic3A7c3VwcG9ydGVkJm5ic3A7YWxnb3JpdGhtJm5ic3A7dGhhdCZuYnNwO2lz Jm5ic3A7bm90PC9ESVY+DQo8RElWPiZndDsmbmJzcDtjb25zaWRlcmVkJm5ic3A7InN0cm9uZyIm bmJzcDtieSZuYnNwO3RoZSZuYnNwO2NsaWVudC48L0RJVj4NCjxESVY+Jmd0OyZuYnNwOzwvRElW Pg0KPERJVj4mZ3Q7Jm5ic3A7T24mbmJzcDtTZXAmbmJzcDsyMSwmbmJzcDsyMDExLCZuYnNwO2F0 Jm5ic3A7MzoyNCZuYnNwO1BNLCZuYnNwO1dhcnJlbiZuYnNwO0t1bWFyaSZuYnNwO3dyb3RlOjwv RElWPg0KPERJVj4mZ3Q7Jm5ic3A7PC9ESVY+DQo8RElWPiZndDsmbmJzcDsmZ3Q7Jm5ic3A7SGVs bG8mbmJzcDthbGwsPC9ESVY+DQo8RElWPiZndDsmbmJzcDsmZ3Q7PC9ESVY+DQo8RElWPiZndDsm bmJzcDsmZ3Q7Jm5ic3A7VGhpcyZuYnNwO3dpbGwmbmJzcDtob3BlZnVsbHkmbmJzcDtiZSZuYnNw O3Nob3J0Jm5ic3A7YW5kJm5ic3A7ZHJhbWEmbmJzcDtmcmVlLjwvRElWPg0KPERJVj4mZ3Q7Jm5i c3A7Jmd0OzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7Jmd0OyZuYnNwO0ppbSZuYnNwO3JhaXNlZCZu YnNwO2FuJm5ic3A7aW50ZXJlc3RpbmcmbmJzcDtxdWVzdGlvbiZuYnNwO2R1cmluZyZuYnNwO3Ro ZSZuYnNwO0lzc3VlJm5ic3A7IzIyJm5ic3A7ZGlzY3Vzc2lvbnM8L0RJVj4NCjxESVY+KHRoYXQ8 L0RJVj4NCjxESVY+Jmd0OyZuYnNwO3dhcyZuYnNwO25vdCZuYnNwO2FkZHJlc3NlZCZuYnNwO2lu Jm5ic3A7IzIyKSwmbmJzcDthbmQmbmJzcDtoYXMmbmJzcDtwcm9wb3NlZCZuYnNwO2FuJm5ic3A7 YW5zd2VyOjwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7Jmd0OyZuYnNwOyImbmJzcDtJJm5ic3A7dGhp bmsmbmJzcDtpdCZuYnNwO3Nob3VsZCZuYnNwO2JlLCZuYnNwO3RoaXMmbmJzcDtpcyZuYnNwO2Em bmJzcDt1c2FibGUmbmJzcDsoSSZuYnNwO2tub3cmbmJzcDt3aGF0Jm5ic3A7aXQmbmJzcDttZWFu cykmbmJzcDtidXQmbmJzcDthPC9ESVY+DQo8RElWPnJlY29yZDwvRElWPg0KPERJVj4mZ3Q7Jm5i c3A7d2hpY2gmbmJzcDthbHdheXMmbmJzcDtmYWlscyZuYnNwO2V2YWx1YXRpb24mbmJzcDsoaS5l LiZuYnNwO3RoZSZuYnNwO2hhc2gmbmJzcDt2YWx1ZSZuYnNwO25ldmVyJm5ic3A7bWF0Y2hlcykm bmJzcDthbmQmbmJzcDt0aHVzPC9ESVY+DQo8RElWPmlmPC9ESVY+DQo8RElWPiZndDsmbmJzcDtu byZuYnNwO290aGVyJm5ic3A7dXNhYmxlJm5ic3A7cmVjb3JkcyZuYnNwO2V4aXN0Jm5ic3A7dGhl biZuYnNwO3RoZSZuYnNwO1RMUyZuYnNwO2hhbmRzaGFrZSZuYnNwO3dvdWxkJm5ic3A7YmUmbmJz cDthYm9ydGVkLiI8L0RJVj4NCjxESVY+Jmd0OyZuYnNwOzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7 VGhlJm5ic3A7cmVsZXZhbnQmbmJzcDt0ZXh0Jm5ic3A7ZnJvbSZuYnNwO3RoZSZuYnNwO2N1cnJl bnQmbmJzcDtkcmFmdCZuYnNwO3NheXM6PC9ESVY+DQo8RElWPiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDtJZiZuYnNwO2EmbmJzcDtjZXJ0aWZpY2F0ZSZuYnNwO2Fzc29jaWF0aW9uJm5ic3A7 Y29udGFpbnMmbmJzcDthJm5ic3A7Y2VydGlmaWNhdGUmbmJzcDt1c2FnZSwmbmJzcDtzZWxlY3Rv ciw8L0RJVj4NCjxESVY+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO29yJm5ic3A7bWF0Y2hp bmcmbmJzcDt0eXBlJm5ic3A7dGhhdCZuYnNwO2lzJm5ic3A7bm90Jm5ic3A7dW5kZXJzdG9vZCZu YnNwO2J5Jm5ic3A7dGhlJm5ic3A7VExTJm5ic3A7Y2xpZW50LCZuYnNwO3RoYXQ8L0RJVj4NCjxE SVY+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2NlcnRpZmljYXRlJm5ic3A7YXNzb2NpYXRp b24mbmJzcDtNVVNUJm5ic3A7YmUmbmJzcDttYXJrZWQmbmJzcDthcyZuYnNwO3VudXNhYmxlLiZu YnNwOyZuYnNwO0lmJm5ic3A7dGhlPC9ESVY+DQo8RElWPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDtjb21wYXJpc29uJm5ic3A7ZGF0YSZuYnNwO2ZvciZuYnNwO2EmbmJzcDtjZXJ0aWZpY2F0 ZSZuYnNwO2lzJm5ic3A7bWFsZm9ybWVkLCZuYnNwO3RoZSZuYnNwO2NlcnRpZmljYXRlPC9ESVY+ DQo8RElWPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDthc3NvY2lhdGlvbiZuYnNwO01VU1Qm bmJzcDtiZSZuYnNwO21hcmtlZCZuYnNwO2FzJm5ic3A7dW51c2FibGUuPC9ESVY+DQo8RElWPiZn dDsmbmJzcDs8L0RJVj4NCjxESVY+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0FuJm5ic3A7 YXBwbGljYXRpb24mbmJzcDt0aGF0Jm5ic3A7cmVxdWVzdHMmbmJzcDtUTFMmbmJzcDtjZXJ0aWZp Y2F0ZSZuYnNwO2Fzc29jaWF0aW9ucyZuYnNwO3VzaW5nJm5ic3A7dGhlPC9ESVY+DQo8RElWPiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDttZXRob2QmbmJzcDtkZXNjcmliZWQmbmJzcDtpbiZu YnNwO3RoaXMmbmJzcDtkb2N1bWVudCZuYnNwO29idGFpbnMmbmJzcDt6ZXJvJm5ic3A7b3ImbmJz cDttb3JlJm5ic3A7dXNhYmxlPC9ESVY+DQo8RElWPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDtjZXJ0aWZpY2F0ZSZuYnNwO2Fzc29jaWF0aW9ucy4mbmJzcDsmbmJzcDtJZiZuYnNwO3RoZSZu YnNwO2FwcGxpY2F0aW9uJm5ic3A7cmVjZWl2ZXMmbmJzcDt6ZXJvJm5ic3A7dXNhYmxlPC9ESVY+ DQo8RElWPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtjZXJ0aWZpY2F0ZSZuYnNwO2Fzc29j aWF0aW9ucywmbmJzcDtpdCZuYnNwO3Byb2Nlc3NlcyZuYnNwO1RMUyZuYnNwO2luJm5ic3A7dGhl Jm5ic3A7bm9ybWFsJm5ic3A7ZmFzaGlvbi48L0RJVj4NCjxESVY+Jmd0OyZuYnNwOzwvRElWPg0K PERJVj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7T24mbmJzcDt0aGUmbmJzcDtmaXJzdCZu YnNwO21hdGNoJm5ic3A7YmV0d2VlbiZuYnNwO29uZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7Y2Vy dGlmaWNhdGUmbmJzcDthc3NvY2lhdGlvbihzKSZuYnNwO2FuZDwvRElWPg0KPERJVj4mZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7dGhlJm5ic3A7c2VydmVyJ3MmbmJzcDtlbmQmbmJzcDtlbnRp dHkmbmJzcDtjZXJ0aWZpY2F0ZSZuYnNwO2luJm5ic3A7VExTJm5ic3A7aXMmbmJzcDtmb3VuZCwm bmJzcDt0aGUmbmJzcDtUTFMmbmJzcDtjbGllbnQ8L0RJVj4NCjxESVY+Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwO2NvbnRpbnVlcyZuYnNwO3RoZSZuYnNwO1RMUyZuYnNwO2hhbmRzaGFrZSwm bmJzcDtpZ25vcmluZyZuYnNwO3JlbWFpbmluZyZuYnNwO2NlcnRpZmljYXRlPC9ESVY+DQo8RElW PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDthc3NvY2lhdGlvbnMuJm5ic3A7Jm5ic3A7SWYm bmJzcDtubyZuYnNwO21hdGNoJm5ic3A7YmV0d2VlbiZuYnNwO3RoZSZuYnNwO3VzYWJsZSZuYnNw O2NlcnRpZmljYXRlPC9ESVY+DQo8RElWPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDthc3Nv Y2lhdGlvbihzKSZuYnNwO2FuZCZuYnNwO3RoZSZuYnNwO3NlcnZlcidzJm5ic3A7ZW5kJm5ic3A7 ZW50aXR5Jm5ic3A7Y2VydGlmaWNhdGUmbmJzcDtpbiZuYnNwO1RMUyZuYnNwO2lzPC9ESVY+DQo8 RElWPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtmb3VuZCwmbmJzcDt0aGUmbmJzcDtUTFMm bmJzcDtjbGllbnQmbmJzcDtNVVNUJm5ic3A7YWJvcnQmbmJzcDt0aGUmbmJzcDtoYW5kc2hha2Um bmJzcDt3aXRoJm5ic3A7YW48L0RJVj4NCjxESVY+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyJhY2Nlc3NfZGVuaWVkIiZuYnNwO2Vycm9yLjwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7PC9ESVY+ DQo8RElWPiZndDsmbmJzcDsmZ3Q7Jm5ic3A7RG9lcyZuYnNwO3RoZSZuYnNwO1dHJm5ic3A7ZmVl bCZuYnNwO3RoYXQmbmJzcDt0aGlzJm5ic3A7aXMmbmJzcDt0aGUmbmJzcDtjb3JyZWN0Jm5ic3A7 YmVoYXZpb3ImbmJzcDsqZm9yJm5ic3A7dGhpcyZuYnNwO2Nhc2UqPyZuYnNwOygrMTwvRElWPg0K PERJVj4vJm5ic3A7LTEmbmJzcDspPC9ESVY+DQo8RElWPiZndDsmbmJzcDs8L0RJVj4NCjxESVY+ Jmd0OyZuYnNwOy0xLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7ZG9uJ3QmbmJzcDt0cnVzdCZuYnNw O2EmbmJzcDtoYXNoJm5ic3A7ZnVuY3Rpb24sJm5ic3A7eW91Jm5ic3A7ZG9uJ3QmbmJzcDt1c2Um bmJzcDtpdCZuYnNwO3RvJm5ic3A7Y3JlYXRlJm5ic3A7YW48L0RJVj4NCjxESVY+dW50cnVzdGVk PC9ESVY+DQo8RElWPiZndDsmbmJzcDtjb21wYXJpc29uOiZuYnNwO3lvdSZuYnNwO3ByZXRlbmQm bmJzcDt0aGF0Jm5ic3A7eW91Jm5ic3A7ZG9uJ3QmbmJzcDtrbm93Jm5ic3A7dGhlJm5ic3A7aGFz aCZuYnNwO2Z1bmN0aW9uLiZuYnNwO1RodXMsJm5ic3A7dGhlPC9ESVY+DQo8RElWPiZndDsmbmJz cDtyZWNvcmQmbmJzcDtpcyZuYnNwO3VudXNhYmxlLiZuYnNwO0lmJm5ic3A7dGhlcmUmbmJzcDth cmUmbmJzcDtubyZuYnNwO290aGVyJm5ic3A7cmVjb3JkcywmbmJzcDt0aGVuJm5ic3A7dGhlJm5i c3A7dGV4dCZuYnNwO2NsZWFybHk8L0RJVj4NCjxESVY+c2F5czwvRElWPg0KPERJVj4mZ3Q7Jm5i c3A7dGhhdCZuYnNwO3RoZSZuYnNwO1RMUyZuYnNwO2hhbmRzaGFrZSZuYnNwO2dvZXMmbmJzcDtv biZuYnNwO2luJm5ic3A7dGhlJm5ic3A7bm9ybWFsJm5ic3A7ZmFzaGlvbi48L0RJVj4NCjxESVY+ Jmd0OyZuYnNwOzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7Jmd0OyZuYnNwO0lmJm5ic3A7c28sJm5i c3A7ZG9lcyZuYnNwO3RoZSZuYnNwO1dHJm5ic3A7ZmVlbCZuYnNwO3RoYXQmbmJzcDt0ZXh0Jm5i c3A7dG8mbmJzcDt0aGlzJm5ic3A7ZWZmZWN0Jm5ic3A7c2hvdWxkJm5ic3A7YmUmbmJzcDthZGRl ZCZuYnNwO3RvJm5ic3A7dGhlPC9ESVY+DQo8RElWPmRyYWZ0PC9ESVY+DQo8RElWPiZndDsmbmJz cDs/Jm5ic3A7KCsxJm5ic3A7LyZuYnNwOy0xKTwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7PC9ESVY+ DQo8RElWPiZndDsmbmJzcDsrMSwmbmJzcDtldmVuJm5ic3A7dGhvdWdoJm5ic3A7dGhpcyZuYnNw O2lzJm5ic3A7bm90Jm5ic3A7ImlmJm5ic3A7c28iLiZuYnNwO0l0Jm5ic3A7c2hvdWxkJm5ic3A7 YmUmbmJzcDtjbGFyaWZpZWQuPC9ESVY+DQo8RElWPiZndDsmbmJzcDs8L0RJVj4NCjxESVY+Jmd0 OyZuYnNwOy0tUGF1bCZuYnNwO0hvZmZtYW48L0RJVj4NCjxESVY+Jmd0OyZuYnNwOzwvRElWPg0K PERJVj4mZ3Q7Jm5ic3A7X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188L0RJVj4NCjxESVY+Jmd0OyZuYnNwO2RhbmUmbmJzcDttYWlsaW5nJm5ic3A7bGlzdDwv RElWPg0KPERJVj4mZ3Q7Jm5ic3A7ZGFuZUBpZXRmLm9yZzwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7 aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kYW5lPC9ESVY+DQo8RElWPjwv RElWPg0KPERJVj48L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvRElWPg0KPERJVj4tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08 L0RJVj4NCjxESVY+RnJvbTombmJzcDsmbmJzcDsiSmltJm5ic3A7U2NoYWFkIiZuYnNwOyZsdDtp ZXRmQGF1Z3VzdGNlbGxhcnMuY29tJmd0OzwvRElWPg0KPERJVj5UbzombmJzcDsmbmJzcDsiJ1Bo aWxsaXAmbmJzcDtIYWxsYW0tQmFrZXInIiZuYnNwOyZsdDtoYWxsYW1AZ21haWwuY29tJmd0Ozwv RElWPg0KPERJVj4mbmJzcDsiJ1BhdWwmbmJzcDtIb2ZmbWFuJyImbmJzcDsmbHQ7cGF1bC5ob2Zm bWFuQHZwbmMub3JnJmd0OzwvRElWPg0KPERJVj5TdWJqZWN0OiZuYnNwOyZuYnNwO1JlOiZuYnNw O1tkYW5lXSZuYnNwOyMzNTombmJzcDtCZWhhdmlvciZuYnNwO2ZvciZuYnNwO2EmbmJzcDtzdXBw b3J0ZWQmbmJzcDthbGdvcml0aG0mbmJzcDt0aGF0Jm5ic3A7aXMmbmJzcDtub3Rjb25zaWRlcmVk Jm5ic3A7InN0cm9uZyImbmJzcDtieSZuYnNwO3RoZSZuYnNwO2NsaWVudC48L0RJVj4NCjxESVY+ RGF0ZTombmJzcDsmbmJzcDtXZWQyMSZuYnNwO1NlcCZuYnNwOzIwMTEmbmJzcDsyMTowOTowNyZu YnNwOy0wNzAwPC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj5JdCdzJm5ic3A7bm90Jm5ic3A7Y2xl YXImbmJzcDtmcm9tJm5ic3A7dGhpcyZuYnNwO3doYXQmbmJzcDtwb3NpdGlvbiZuYnNwO3lvdSZu YnNwO2FyZSZuYnNwO3Rha2luZy4mbmJzcDsmbmJzcDtCYXNlZCZuYnNwO29uJm5ic3A7eW91cjwv RElWPg0KPERJVj5tZXNzYWdlJm5ic3A7SSZuYnNwO2NvdWxkJm5ic3A7c2V0dXAmbmJzcDt0aGUm bmJzcDtmb2xsb3dpbmcmbmJzcDtzdHJhdyZuYnNwO21hbiZuYnNwO3Byb3Bvc2FscywmbmJzcDti dXQmbmJzcDtJJm5ic3A7ZG91YnQmbmJzcDthbnkmbmJzcDtvZjwvRElWPg0KPERJVj50aGVtJm5i c3A7d291bGQmbmJzcDtjb3JyZXNwb25kJm5ic3A7dG8mbmJzcDt5b3VyJm5ic3A7YWN0dWFsJm5i c3A7cG9zaXRpb246PC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+ PC9ESVY+DQo8RElWPjEuJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7RWl0aGVyJm5ic3A7eW91Jm5ic3A7cmVhZCZuYnNwO2EmbmJzcDttZXNzYWdlJm5ic3A7 SSZuYnNwO21pc3NlZCZuYnNwO3doZXJlJm5ic3A7c29tZWJvZHkmbmJzcDtoYXMmbmJzcDtzdWdn ZXN0ZWQ8L0RJVj4NCjxESVY+dGhhdCZuYnNwO1NIQTEmbmJzcDtiZSZuYnNwO2FkZGVkJm5ic3A7 dG8mbmJzcDt0aGUmbmJzcDtEQU5FJm5ic3A7d29yaywmbmJzcDtvciZuYnNwO3lvdSZuYnNwO2Jl bGlldmUmbmJzcDt0aGF0Jm5ic3A7dGhlJm5ic3A7ZmFjdCZuYnNwO3RoYXQmbmJzcDtJPC9ESVY+ DQo8RElWPnN1Z2dlc3RlZCZuYnNwO2FuJm5ic3A7YWxnb3JpdGhtJm5ic3A7bWlnaHQmbmJzcDtn byZuYnNwO2JhZCZuYnNwO2luJm5ic3A7dGhlJm5ic3A7ZnV0dXJlJm5ic3A7YW5kJm5ic3A7d2Um bmJzcDtzaG91bGQmbmJzcDtkZWFsJm5ic3A7d2l0aDwvRElWPg0KPERJVj50aGlzJm5ic3A7bWVh bnMmbmJzcDt0aGF0Jm5ic3A7SSZuYnNwO2JlbGlldmUmbmJzcDt0aGF0Jm5ic3A7d2UmbmJzcDtz aG91bGQmbmJzcDthZGQmbmJzcDtTSEExJm5ic3A7dG8mbmJzcDt0aGUmbmJzcDtjdXJyZW50Jm5i c3A7d29yayZuYnNwO2luPC9ESVY+DQo8RElWPm9yZGVyJm5ic3A7dG8mbmJzcDtqdXN0aWZ5Jm5i c3A7bXkmbmJzcDtwb3NpdGlvbi48L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPjIuJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Tm9uZSZuYnNwO29mJm5ic3A7dGhlJm5i c3A7ZXhpc3RpbmcmbmJzcDthbGdvcml0aG1zJm5ic3A7dGhhdCZuYnNwO2hhdmUmbmJzcDtiZWVu Jm5ic3A7c3VnZ2VzdGVkJm5ic3A7Zm9yPC9ESVY+DQo8RElWPmluY2x1c2lvbiZuYnNwO2luJm5i c3A7dGhlJm5ic3A7REFORSZuYnNwO3dvcmsmbmJzcDt3aWxsJm5ic3A7ZXZlciZuYnNwO2dvJm5i c3A7YmFkJm5ic3A7YW5kJm5ic3A7dGhlcmVmb3JlJm5ic3A7dGhlJm5ic3A7c3VnZ2VzdGlvbjwv RElWPg0KPERJVj50aGF0Jm5ic3A7aXQmbmJzcDttaWdodCZuYnNwO2dvJm5ic3A7YmFkJm5ic3A7 YW5kJm5ic3A7d2UmbmJzcDtzaG91bGQmbmJzcDthZGRyZXNzJm5ic3A7dGhlJm5ic3A7aXNzdWUm bmJzcDtpcyZuYnNwO2NsZWFyJm5ic3A7cHJvb2YmbmJzcDt0aGF0Jm5ic3A7STwvRElWPg0KPERJ Vj5oYXZlJm5ic3A7bm8mbmJzcDtpZGVhJm5ic3A7b2YmbmJzcDt3aGF0Jm5ic3A7aGFwcGVucyZu YnNwO2luJm5ic3A7dGhlJm5ic3A7cmVhbCZuYnNwO3dvcmxkLjwvRElWPg0KPERJVj48L0RJVj4N CjxESVY+My4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtXZSZuYnNw O3dvdWxkJm5ic3A7bmV2ZXImbmJzcDtiZSZuYnNwO2luJm5ic3A7YSZuYnNwO3Bvc2l0aW9uJm5i c3A7b2YmbmJzcDthJm5ic3A7Y2F0YXN0cm9waGljJm5ic3A7aGFzaCZuYnNwO2FsZ29yaXRobTwv RElWPg0KPERJVj5mYWlsdXJlJm5ic3A7d2l0aCZuYnNwO3RoZSZuYnNwO2N1cnJlbnQmbmJzcDto YXNoJm5ic3A7YWxnb3JpdGhtcyZuYnNwO2FuZCZuYnNwO3RoZXJlJm5ic3A7aXMmbmJzcDthbHdh eXMmbmJzcDtnb2luZyZuYnNwO3RvJm5ic3A7YmU8L0RJVj4NCjxESVY+bG90cyZuYnNwO29mJm5i c3A7dGltZSZuYnNwO3RvJm5ic3A7ZG8mbmJzcDthJm5ic3A7dHJhbnNpdGlvbiZuYnNwO2FuZCZu YnNwO2FsbCZuYnNwO29wZXJhdG9ycyZuYnNwO2FyZSZuYnNwO2dvaW5nJm5ic3A7dG8mbmJzcDti ZSZuYnNwO2VmZmljaWVudDwvRElWPg0KPERJVj5hYm91dCZuYnNwO2RvaW5nJm5ic3A7dGhlJm5i c3A7dHJhbnNpdGlvbiZuYnNwO3NvJm5ic3A7dGhhdCZuYnNwO25ldyZuYnNwO2FsZ29yaXRobXMm bmJzcDt3aWxsJm5ic3A7YWx3YXlzJm5ic3A7YmUmbmJzcDtyb2xsZWQmbmJzcDtvdXQ8L0RJVj4N CjxESVY+aW4mbmJzcDtzdWZmaWNpZW50Jm5ic3A7dGltZS48L0RJVj4NCjxESVY+PC9ESVY+DQo8 RElWPiZuYnNwOzwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+V2hpbGUmbmJzcDtJJm5ic3A7YW0m bmJzcDtzdGFydGluZyZuYnNwO3RvJm5ic3A7Y29tZSZuYnNwO3RvJm5ic3A7dGhlJm5ic3A7b3Bp bmlvbiZuYnNwO3RoYXQmbmJzcDt0aGUmbmJzcDtEQU5FJm5ic3A7ZWZmb3J0Jm5ic3A7aXMmbmJz cDt0cnVseTwvRElWPg0KPERJVj5nb2luZyZuYnNwO3RvJm5ic3A7bmVlZCZuYnNwO2FuJm5ic3A7 b3BlcmF0aW9ucyZuYnNwO2RvY3VtZW50Jm5ic3A7YW5kJm5ic3A7SSZuYnNwO21pZ2h0Jm5ic3A7 YmUmbmJzcDt3aWxsaW5nJm5ic3A7dG8mbmJzcDtiZSZuYnNwO3RoZTwvRElWPg0KPERJVj5hdXRo b3IsJm5ic3A7dW5sZXNzJm5ic3A7eW91Jm5ic3A7YmVsaWV2ZSZuYnNwO3RoYXQmbmJzcDthbiZu YnNwO29wZXJhdGlvbmFsJm5ic3A7YXBwcm9hY2gmbmJzcDtpcyZuYnNwO2EmbmJzcDtzdWZmaWNp ZW50PC9ESVY+DQo8RElWPm1ldGhvZCZuYnNwO29mJm5ic3A7YWRkcmVzc2luZyZuYnNwO3RoZSZu YnNwO2lzc3VlJm5ic3A7SSZuYnNwO3JhaXNlZCwmbmJzcDtpdCZuYnNwO3dvdWxkJm5ic3A7YmUm bmJzcDttb3JlJm5ic3A7cHJvZHVjdGl2ZSZuYnNwO3RvJm5ic3A7c2F5PC9ESVY+DQo8RElWPnRo YXQmbmJzcDt3ZSZuYnNwO3Nob3VsZCZuYnNwO2RvJm5ic3A7QkxBSCZuYnNwO2FuZCZuYnNwO2Fk ZGl0aW9uYWxseSZuYnNwO2FkZCZuYnNwO3RoZSZuYnNwO2ZvbGxvd2luZyZuYnNwO3RvJm5ic3A7 dGhlJm5ic3A7b3BlcmF0aW9uczwvRElWPg0KPERJVj5yZWNvbW1lbmRhdGlvbnMuPC9ESVY+DQo8 RElWPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPkppbTwvRElW Pg0KPERJVj48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj4mbmJz cDs8L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPkZyb206Jm5ic3A7ZGFuZS1ib3VuY2VzQGlldGYu b3JnJm5ic3A7W21haWx0bzpkYW5lLWJvdW5jZXNAaWV0Zi5vcmddJm5ic3A7T24mbmJzcDtCZWhh bGYmbmJzcDtPZjwvRElWPg0KPERJVj5QaGlsbGlwJm5ic3A7SGFsbGFtLUJha2VyPC9ESVY+DQo8 RElWPlNlbnQ6Jm5ic3A7V2VkbmVzZGF5LCZuYnNwO1NlcHRlbWJlciZuYnNwOzIxLCZuYnNwOzIw MTEmbmJzcDs1OjAzJm5ic3A7UE08L0RJVj4NCjxESVY+VG86Jm5ic3A7UGF1bCZuYnNwO0hvZmZt YW48L0RJVj4NCjxESVY+Q2M6Jm5ic3A7REFORSZuYnNwO1dHPC9ESVY+DQo8RElWPlN1YmplY3Q6 Jm5ic3A7UmU6Jm5ic3A7W2RhbmVdJm5ic3A7IzM1OiZuYnNwO0JlaGF2aW9yJm5ic3A7Zm9yJm5i c3A7YSZuYnNwO3N1cHBvcnRlZCZuYnNwO2FsZ29yaXRobSZuYnNwO3RoYXQmbmJzcDtpcyZuYnNw O25vdDwvRElWPg0KPERJVj5jb25zaWRlcmVkJm5ic3A7InN0cm9uZyImbmJzcDtieSZuYnNwO3Ro ZSZuYnNwO2NsaWVudC48L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJ Vj48L0RJVj4NCjxESVY+V2h5Jm5ic3A7d291bGQmbmJzcDthbnlvbmUmbmJzcDtpbXBsZW1lbnQm bmJzcDtTSEExJm5ic3A7Zm9yJm5ic3A7YSZuYnNwO25ldyZuYnNwO3Byb3RvY29sJm5ic3A7c3Bl Y2lmaWNhdGlvbj88L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48 L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj5SZW1lbWJlciZuYnNw O3RoYXQmbmJzcDt0aGUmbmJzcDtEQU5FJm5ic3A7cmVjb3JkcyZuYnNwO2FyZSZuYnNwO2dvaW5n Jm5ic3A7dG8mbmJzcDtiZSZuYnNwO3NpZ25lZCZuYnNwO3VzaW5nJm5ic3A7RE5TU0VDLiZuYnNw O1RodXM8L0RJVj4NCjxESVY+dGhlcmUmbmJzcDt3aWxsJm5ic3A7YmUmbmJzcDt0d28mbmJzcDtk aWdlc3RzJm5ic3A7aW52b2x2ZWQuJm5ic3A7PC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj4mbmJz cDs8L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPklmJm5ic3A7d2UmbmJzcDthcmUmbmJzcDtpbiZu YnNwO2EmbmJzcDt0cmFuc2l0aW9uJm5ic3A7ZnJvbSZuYnNwO2FsZ29yaXRobSZuYnNwO0EmbmJz cDt0byZuYnNwO2FsZ29yaXRobSZuYnNwO0ImbmJzcDthbmQmbmJzcDt0aGVyZSZuYnNwO2lzJm5i c3A7YTwvRElWPg0KPERJVj5wb2ludCZuYnNwO3RvJm5ic3A7aXQsJm5ic3A7dGhlbiZuYnNwO3Ro ZSZuYnNwO0ROU1NFQyZuYnNwO3JlY29yZHMmbmJzcDthbmQmbmJzcDt0aGUmbmJzcDtEQU5FJm5i c3A7cmVjb3JkcyZuYnNwO211c3QmbmJzcDtiZSZuYnNwO2JvdGg8L0RJVj4NCjxESVY+c3BlY2lm aWVkJm5ic3A7dW5kZXImbmJzcDtib3RoJm5ic3A7YWxnb3JpdGhtcyZuYnNwO29yJm5ic3A7dGhl cmUmbmJzcDtpcyZuYnNwO25vJm5ic3A7cG9pbnQmbmJzcDt0byZuYnNwO2l0LjwvRElWPg0KPERJ Vj48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJ Vj4NCjxESVY+PC9ESVY+DQo8RElWPlNvJm5ic3A7ZnJvbSZuYnNwO2EmbmJzcDtEQU5FJm5ic3A7 c3RhbmRwb2ludCZuYnNwO3RoZXJlJm5ic3A7c2hvdWxkJm5ic3A7cHJvYmFibHkmbmJzcDtiZSZu YnNwO2EmbmJzcDtyZXF1aXJlbWVudCZuYnNwO3RoYXQmbmJzcDt0aGVyZTwvRElWPg0KPERJVj5p cyZuYnNwO2EmbmJzcDtkaWdlc3QmbmJzcDt2YWx1ZSZuYnNwO2ZvciZuYnNwO2FsbCZuYnNwO3Ro ZSZuYnNwO2FsZ29yaXRobXMmbmJzcDt1c2VkJm5ic3A7dG8mbmJzcDtzaWduJm5ic3A7dGhlJm5i c3A7em9uZS48L0RJVj4NCjxESVY+QWx0ZXJuYXRpdmVseSwmbmJzcDtpdCZuYnNwO3RoYXQmbmJz cDtpcyZuYnNwO2NvbnNpZGVyZWQmbmJzcDthZG1pbmlzdHJhdGl2ZWx5Jm5ic3A7aW1wcmFjdGlj YWwsJm5ic3A7dGhlcmU8L0RJVj4NCjxESVY+bmVlZHMmbmJzcDt0byZuYnNwO2JlJm5ic3A7YSZu YnNwO0RBTkUmbmJzcDtyZWNvcmQmbmJzcDt0aGF0Jm5ic3A7c3BlY2lmaWVzJm5ic3A7dGhlJm5i c3A7ZGlnZXN0cyZuYnNwO3RvJm5ic3A7ZXhwZWN0Jm5ic3A7aW4mbmJzcDt0aGUmbmJzcDtEQU5F PC9ESVY+DQo8RElWPnJlY29yZHMuPC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJ Vj4NCjxESVY+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+Jm5i c3A7PC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PC9ESVY+DQo8 RElWPk9uJm5ic3A7V2VkLCZuYnNwO1NlcCZuYnNwOzIxLCZuYnNwOzIwMTEmbmJzcDthdCZuYnNw OzY6NDYmbmJzcDtQTSwmbmJzcDtQYXVsJm5ic3A7SG9mZm1hbiZuYnNwOyZsdDtwYXVsLmhvZmZt YW5AdnBuYy5vcmcmZ3Q7Jm5ic3A7d3JvdGU6PC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj5PbiZu YnNwO1NlcCZuYnNwOzIxLCZuYnNwOzIwMTEsJm5ic3A7YXQmbmJzcDszOjI0Jm5ic3A7UE0sJm5i c3A7V2FycmVuJm5ic3A7S3VtYXJpJm5ic3A7d3JvdGU6PC9ESVY+DQo8RElWPjwvRElWPg0KPERJ Vj4mZ3Q7Jm5ic3A7SGVsbG8mbmJzcDthbGwsPC9ESVY+DQo8RElWPiZndDs8L0RJVj4NCjxESVY+ Jmd0OyZuYnNwO1RoaXMmbmJzcDt3aWxsJm5ic3A7aG9wZWZ1bGx5Jm5ic3A7YmUmbmJzcDtzaG9y dCZuYnNwO2FuZCZuYnNwO2RyYW1hJm5ic3A7ZnJlZS48L0RJVj4NCjxESVY+Jmd0OzwvRElWPg0K PERJVj4mZ3Q7Jm5ic3A7SmltJm5ic3A7cmFpc2VkJm5ic3A7YW4mbmJzcDtpbnRlcmVzdGluZyZu YnNwO3F1ZXN0aW9uJm5ic3A7ZHVyaW5nJm5ic3A7dGhlJm5ic3A7SXNzdWUmbmJzcDsjMjImbmJz cDtkaXNjdXNzaW9ucyZuYnNwOyh0aGF0PC9ESVY+DQo8RElWPndhcyZuYnNwO25vdCZuYnNwO2Fk ZHJlc3NlZCZuYnNwO2luJm5ic3A7IzIyKSwmbmJzcDthbmQmbmJzcDtoYXMmbmJzcDtwcm9wb3Nl ZCZuYnNwO2FuJm5ic3A7YW5zd2VyOjwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7IiZuYnNwO0kmbmJz cDt0aGluayZuYnNwO2l0Jm5ic3A7c2hvdWxkJm5ic3A7YmUsJm5ic3A7dGhpcyZuYnNwO2lzJm5i c3A7YSZuYnNwO3VzYWJsZSZuYnNwOyhJJm5ic3A7a25vdyZuYnNwO3doYXQmbmJzcDtpdCZuYnNw O21lYW5zKSZuYnNwO2J1dCZuYnNwO2E8L0RJVj4NCjxESVY+cmVjb3JkJm5ic3A7d2hpY2gmbmJz cDthbHdheXMmbmJzcDtmYWlscyZuYnNwO2V2YWx1YXRpb24mbmJzcDsoaS5lLiZuYnNwO3RoZSZu YnNwO2hhc2gmbmJzcDt2YWx1ZSZuYnNwO25ldmVyJm5ic3A7bWF0Y2hlcykmbmJzcDthbmQ8L0RJ Vj4NCjxESVY+dGh1cyZuYnNwO2lmJm5ic3A7bm8mbmJzcDtvdGhlciZuYnNwO3VzYWJsZSZuYnNw O3JlY29yZHMmbmJzcDtleGlzdCZuYnNwO3RoZW4mbmJzcDt0aGUmbmJzcDtUTFMmbmJzcDtoYW5k c2hha2UmbmJzcDt3b3VsZCZuYnNwO2JlPC9ESVY+DQo8RElWPmFib3J0ZWQuIjwvRElWPg0KPERJ Vj48L0RJVj4NCjxESVY+VGhlJm5ic3A7cmVsZXZhbnQmbmJzcDt0ZXh0Jm5ic3A7ZnJvbSZuYnNw O3RoZSZuYnNwO2N1cnJlbnQmbmJzcDtkcmFmdCZuYnNwO3NheXM6PC9ESVY+DQo8RElWPiZuYnNw OyZuYnNwO0lmJm5ic3A7YSZuYnNwO2NlcnRpZmljYXRlJm5ic3A7YXNzb2NpYXRpb24mbmJzcDtj b250YWlucyZuYnNwO2EmbmJzcDtjZXJ0aWZpY2F0ZSZuYnNwO3VzYWdlLCZuYnNwO3NlbGVjdG9y LDwvRElWPg0KPERJVj4mbmJzcDsmbmJzcDtvciZuYnNwO21hdGNoaW5nJm5ic3A7dHlwZSZuYnNw O3RoYXQmbmJzcDtpcyZuYnNwO25vdCZuYnNwO3VuZGVyc3Rvb2QmbmJzcDtieSZuYnNwO3RoZSZu YnNwO1RMUyZuYnNwO2NsaWVudCwmbmJzcDt0aGF0PC9ESVY+DQo8RElWPiZuYnNwOyZuYnNwO2Nl cnRpZmljYXRlJm5ic3A7YXNzb2NpYXRpb24mbmJzcDtNVVNUJm5ic3A7YmUmbmJzcDttYXJrZWQm bmJzcDthcyZuYnNwO3VudXNhYmxlLiZuYnNwOyZuYnNwO0lmJm5ic3A7dGhlPC9ESVY+DQo8RElW PiZuYnNwOyZuYnNwO2NvbXBhcmlzb24mbmJzcDtkYXRhJm5ic3A7Zm9yJm5ic3A7YSZuYnNwO2Nl cnRpZmljYXRlJm5ic3A7aXMmbmJzcDttYWxmb3JtZWQsJm5ic3A7dGhlJm5ic3A7Y2VydGlmaWNh dGU8L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7YXNzb2NpYXRpb24mbmJzcDtNVVNUJm5ic3A7YmUm bmJzcDttYXJrZWQmbmJzcDthcyZuYnNwO3VudXNhYmxlLjwvRElWPg0KPERJVj48L0RJVj4NCjxE SVY+Jm5ic3A7Jm5ic3A7QW4mbmJzcDthcHBsaWNhdGlvbiZuYnNwO3RoYXQmbmJzcDtyZXF1ZXN0 cyZuYnNwO1RMUyZuYnNwO2NlcnRpZmljYXRlJm5ic3A7YXNzb2NpYXRpb25zJm5ic3A7dXNpbmcm bmJzcDt0aGU8L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7bWV0aG9kJm5ic3A7ZGVzY3JpYmVkJm5i c3A7aW4mbmJzcDt0aGlzJm5ic3A7ZG9jdW1lbnQmbmJzcDtvYnRhaW5zJm5ic3A7emVybyZuYnNw O29yJm5ic3A7bW9yZSZuYnNwO3VzYWJsZTwvRElWPg0KPERJVj4mbmJzcDsmbmJzcDtjZXJ0aWZp Y2F0ZSZuYnNwO2Fzc29jaWF0aW9ucy4mbmJzcDsmbmJzcDtJZiZuYnNwO3RoZSZuYnNwO2FwcGxp Y2F0aW9uJm5ic3A7cmVjZWl2ZXMmbmJzcDt6ZXJvJm5ic3A7dXNhYmxlPC9ESVY+DQo8RElWPiZu YnNwOyZuYnNwO2NlcnRpZmljYXRlJm5ic3A7YXNzb2NpYXRpb25zLCZuYnNwO2l0Jm5ic3A7cHJv Y2Vzc2VzJm5ic3A7VExTJm5ic3A7aW4mbmJzcDt0aGUmbmJzcDtub3JtYWwmbmJzcDtmYXNoaW9u LjwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7T24mbmJzcDt0aGUmbmJzcDtm aXJzdCZuYnNwO21hdGNoJm5ic3A7YmV0d2VlbiZuYnNwO29uZSZuYnNwO29mJm5ic3A7dGhlJm5i c3A7Y2VydGlmaWNhdGUmbmJzcDthc3NvY2lhdGlvbihzKSZuYnNwO2FuZDwvRElWPg0KPERJVj4m bmJzcDsmbmJzcDt0aGUmbmJzcDtzZXJ2ZXIncyZuYnNwO2VuZCZuYnNwO2VudGl0eSZuYnNwO2Nl cnRpZmljYXRlJm5ic3A7aW4mbmJzcDtUTFMmbmJzcDtpcyZuYnNwO2ZvdW5kLCZuYnNwO3RoZSZu YnNwO1RMUyZuYnNwO2NsaWVudDwvRElWPg0KPERJVj4mbmJzcDsmbmJzcDtjb250aW51ZXMmbmJz cDt0aGUmbmJzcDtUTFMmbmJzcDtoYW5kc2hha2UsJm5ic3A7aWdub3JpbmcmbmJzcDtyZW1haW5p bmcmbmJzcDtjZXJ0aWZpY2F0ZTwvRElWPg0KPERJVj4mbmJzcDsmbmJzcDthc3NvY2lhdGlvbnMu Jm5ic3A7Jm5ic3A7SWYmbmJzcDtubyZuYnNwO21hdGNoJm5ic3A7YmV0d2VlbiZuYnNwO3RoZSZu YnNwO3VzYWJsZSZuYnNwO2NlcnRpZmljYXRlPC9ESVY+DQo8RElWPiZuYnNwOyZuYnNwO2Fzc29j aWF0aW9uKHMpJm5ic3A7YW5kJm5ic3A7dGhlJm5ic3A7c2VydmVyJ3MmbmJzcDtlbmQmbmJzcDtl bnRpdHkmbmJzcDtjZXJ0aWZpY2F0ZSZuYnNwO2luJm5ic3A7VExTJm5ic3A7aXM8L0RJVj4NCjxE SVY+Jm5ic3A7Jm5ic3A7Zm91bmQsJm5ic3A7dGhlJm5ic3A7VExTJm5ic3A7Y2xpZW50Jm5ic3A7 TVVTVCZuYnNwO2Fib3J0Jm5ic3A7dGhlJm5ic3A7aGFuZHNoYWtlJm5ic3A7d2l0aCZuYnNwO2Fu PC9ESVY+DQo8RElWPiZuYnNwOyZuYnNwOyJhY2Nlc3NfZGVuaWVkIiZuYnNwO2Vycm9yLjwvRElW Pg0KPERJVj48L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPiZndDsmbmJzcDtEb2VzJm5ic3A7dGhl Jm5ic3A7V0cmbmJzcDtmZWVsJm5ic3A7dGhhdCZuYnNwO3RoaXMmbmJzcDtpcyZuYnNwO3RoZSZu YnNwO2NvcnJlY3QmbmJzcDtiZWhhdmlvciZuYnNwOypmb3ImbmJzcDt0aGlzJm5ic3A7Y2FzZSo/ Jm5ic3A7KCsxJm5ic3A7LzwvRElWPg0KPERJVj4tMSZuYnNwOyk8L0RJVj4NCjxESVY+PC9ESVY+ DQo8RElWPi0xLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7ZG9uJ3QmbmJzcDt0cnVzdCZuYnNwO2Em bmJzcDtoYXNoJm5ic3A7ZnVuY3Rpb24sJm5ic3A7eW91Jm5ic3A7ZG9uJ3QmbmJzcDt1c2UmbmJz cDtpdCZuYnNwO3RvJm5ic3A7Y3JlYXRlJm5ic3A7YW48L0RJVj4NCjxESVY+dW50cnVzdGVkJm5i c3A7Y29tcGFyaXNvbjombmJzcDt5b3UmbmJzcDtwcmV0ZW5kJm5ic3A7dGhhdCZuYnNwO3lvdSZu YnNwO2Rvbid0Jm5ic3A7a25vdyZuYnNwO3RoZSZuYnNwO2hhc2gmbmJzcDtmdW5jdGlvbi48L0RJ Vj4NCjxESVY+VGh1cywmbmJzcDt0aGUmbmJzcDtyZWNvcmQmbmJzcDtpcyZuYnNwO3VudXNhYmxl LiZuYnNwO0lmJm5ic3A7dGhlcmUmbmJzcDthcmUmbmJzcDtubyZuYnNwO290aGVyJm5ic3A7cmVj b3JkcywmbmJzcDt0aGVuJm5ic3A7dGhlJm5ic3A7dGV4dDwvRElWPg0KPERJVj5jbGVhcmx5Jm5i c3A7c2F5cyZuYnNwO3RoYXQmbmJzcDt0aGUmbmJzcDtUTFMmbmJzcDtoYW5kc2hha2UmbmJzcDtn b2VzJm5ic3A7b24mbmJzcDtpbiZuYnNwO3RoZSZuYnNwO25vcm1hbCZuYnNwO2Zhc2hpb24uPC9E SVY+DQo8RElWPjwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+Jmd0OyZuYnNwO0lmJm5ic3A7c28s Jm5ic3A7ZG9lcyZuYnNwO3RoZSZuYnNwO1dHJm5ic3A7ZmVlbCZuYnNwO3RoYXQmbmJzcDt0ZXh0 Jm5ic3A7dG8mbmJzcDt0aGlzJm5ic3A7ZWZmZWN0Jm5ic3A7c2hvdWxkJm5ic3A7YmUmbmJzcDth ZGRlZCZuYnNwO3RvJm5ic3A7dGhlPC9ESVY+DQo8RElWPmRyYWZ0Jm5ic3A7PyZuYnNwOygrMSZu YnNwOy8mbmJzcDstMSk8L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPisxLCZuYnNwO2V2ZW4mbmJz cDt0aG91Z2gmbmJzcDt0aGlzJm5ic3A7aXMmbmJzcDtub3QmbmJzcDsiaWYmbmJzcDtzbyIuJm5i c3A7SXQmbmJzcDtzaG91bGQmbmJzcDtiZSZuYnNwO2NsYXJpZmllZC48L0RJVj4NCjxESVY+PC9E SVY+DQo8RElWPi0tUGF1bCZuYnNwO0hvZmZtYW48L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPjwv RElWPg0KPERJVj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XzwvRElWPg0KPERJVj5kYW5lJm5ic3A7bWFpbGluZyZuYnNwO2xpc3Q8L0RJVj4NCjxESVY+ZGFu ZUBpZXRmLm9yZzwvRElWPg0KPERJVj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2RhbmU8L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj48L0RJVj4NCjxE SVY+PC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PC9ESVY+DQo8 RElWPi0tJm5ic3A7PC9ESVY+DQo8RElWPldlYnNpdGU6Jm5ic3A7aHR0cDovL2hhbGxhbWJha2Vy LmNvbS88L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj4tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L0RJVj4NCjxE SVY+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L0RJVj4N CjxESVY+ZGFuZSZuYnNwO21haWxpbmcmbmJzcDtsaXN0PC9ESVY+DQo8RElWPmRhbmVAaWV0Zi5v cmc8L0RJVj4NCjxESVY+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kYW5l PC9ESVY+DQo8RElWPjwvRElWPjwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K --=====003_Dragon608467071305_=====-- From matt@mattmccutchen.net Wed Sep 21 22:53:21 2011 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 3253E21F8CAB for ; Wed, 21 Sep 2011 22:53:21 -0700 (PDT) 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=[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 aE5+eDw6iFK5 for ; Wed, 21 Sep 2011 22:53:20 -0700 (PDT) Received: from homiemail-a60.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 5659921F8CAA for ; Wed, 21 Sep 2011 22:53:20 -0700 (PDT) Received: from homiemail-a60.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a60.g.dreamhost.com (Postfix) with ESMTP id 9C8963BC06A; Wed, 21 Sep 2011 22:55:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; q=dns; s= mattmccutchen.net; b=AwMsUrzzKI2c51I67wL7i/WQx1luKLaUKUbyslB1miU DUyx+gSfNQQHw3BBTJkccYJ5ogkYoUMutCTpoXBZsrF56LubulTZkfvmMb1cvZ29 n5nDsMyVONBVFJz3CmyPs4M4ecvaervz9ZXksV1wzV66ZyfFkMGTkUTGpWs1aqPw = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; s= mattmccutchen.net; bh=4GBAvNkSgP66W4Rl0gvT9b9nwvI=; b=d9r1VONnWA 05FDwyx9OAMibYn7v7LXIon1ttbdIc8Z06ZO4g04v+S8GWNxI3f60yZzbjKyCkWc xQTFTpOY/BjteI807ku8bCTlC2vs9Ad/ju/7WasPZi1eY/Ys6zM+joxtxjmBO4+d 0ZZIKFtPlJIj8bDhe/7g5T6/aGTo0fRIA= 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-a60.g.dreamhost.com (Postfix) with ESMTPSA id 72D4C3BC063; Wed, 21 Sep 2011 22:55:50 -0700 (PDT) From: Matt McCutchen To: Jim Schaad Date: Wed, 21 Sep 2011 22:55:49 -0700 In-Reply-To: <017b01cc78ec$03581160$0a083420$@augustcellars.com> References: <061.add9f922b5dfb2db7544981f78552e7e@trac.tools.ietf.org> <6EB199FD-63B2-4FEA-88ED-67DB559148A0@bbn.com> <670A864B-567A-4351-AB6D-0A373AF66B9B@kumari.net> <1316658906.1941.63.camel@localhost> <017a01cc78df$55d1e180$0175a480$@augustcellars.com> <1316667624.1941.79.camel@localhost> <017b01cc78ec$03581160$0a083420$@augustcellars.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 Content-Transfer-Encoding: 7bit Message-ID: <1316670950.1941.98.camel@localhost> Mime-Version: 1.0 Cc: 'DANE WG' Subject: Re: [dane] #33: Publish enough information for the client to achieve the security of its favorite digest 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, 22 Sep 2011 05:53:21 -0000 On Wed, 2011-09-21 at 22:53 -0700, Jim Schaad wrote: > > > -----Original Message----- > > From: Matt McCutchen [mailto:matt@mattmccutchen.net] > > Sent: Wednesday, September 21, 2011 10:00 PM > > To: Jim Schaad > > Cc: 'DANE WG' > > Subject: RE: [dane] #33: Publish enough information for the client to achieve > > the security of its favorite digest > > > > On Wed, 2011-09-21 at 21:23 -0700, Jim Schaad wrote: > > > This demonstrates why I have said that an algorithm either is or is > > > not good enough. > > > > If you have established minimum security requirements in advance and can > > simply enforce them, good for you. But most of the world does not operate > > that way. It's easier to just use the strongest algorithm supported by both > > sides, and independently work to ensure that both sides support sufficiently > > strong algorithms. Since the web browser market puts such a premium on > > availability against all the servers in the world, it will inevitably end up setting a > > bare-minimum security requirement unless we provide a downgrade-proof > > way to negotiate the algorithm. > > > > > While it could be doing a roll over, it could also be selecting the > > > certificate based on the criteria that you gave in the TLS handshake > > > and using the same hash algorithm for both the certificate and the > > > TLSA statement. > > > > Your point is lost on me. Could you write out an example? > > Suppose the server has an RSA-SHA-256 certificate set and an ECC-SHA-512 certificate set. > There is one SHA-256 TLSA record for the first certificate and one SHA-512 TLSA record for the second certificate > Based on what you state as the algorithms you accept, one or the other of the certificates is returned as part of the TLS handshake. > > You then check the received certificate against the two TLSA records and proceeded. Sure. So this is just another scenario with two authorized certificates for which the TLSA digest offerings are different. > > > If your client wants to sort the TLSA records and process them in > > > preferred order, there is nothing to prevent that. > > > > I don't know what you are getting at by "order"; disjunction is commutative. > > Did you mean "process only the RRs of the algorithm I consider strongest"? If I > > do that I'll fail against servers that have perverse but valid configurations, as in > > the example I gave. > > You can process SHA-512 records first and then SHA-256 if that is what > you want to do. What significance can there possibly be to doing that? Why do you bother to mention it? Disjunction is commutative? > You must decide either to process and accept SHA-256 records or not. > If you accept them then you will accept them. Yes, that is exactly the dilemma in which the current schema places clients. > There is no problems. The problem is that I can't achieve the security of SHA-512 with servers that provide SHA-512 digests while remaining interoperable with servers that don't. Maybe this is not a problem to you. Maybe MITM attacks are not a problem to some people either. > > > But you cannot assume that the > > > host operator has the same feeling for the algorithm that you have. > > > > What do you mean? The proposals under consideration are: > > > > - Indicate which digests are of the same certificate, either via group IDs or by > > concatenating all the info about one certificate in one RR. > > - Require that the RRset be a Cartesian product of certs and algorithms. > > You are asking for a new item to be setup that the RRset be a product > of certs and algorithms. That is a new requirement New with respect to what? > and will cause future problems. What happens when SHA3 algorithms are > introduced. They will not be in the complete product set and thus > cause problems. No, the requirement is that the RRset be a Cartesian product of a set of certs with *a set* of algorithms. This set of algorithms need not be the entire registry. You can have {cert1, cert2} x {SHA-256, SHA-512} even after SHA-3 is assigned a hash type or, indeed, becomes mandatory for clients to support. But I actually prefer the other approach, specifically the variant of concatenating all the info about a single certificate in a single RR. > There is no need to indicate which certificates are setup with which > hash algorithms as all of the TLSA disjoint "disjunct"? > statements would be evaluated independently. That is the current semantics. To solve the problem I stated above, there is a need to indicate which certs are setup with which hash algorithms, or alternatively guarantee that any hash algorithm that appears at all appears for all certs. > If your favorite algorithm is not present then you are just out of luck on wanting to use that algorithm in all cases. You either accept the algorithm that is present or not. Yes, of course. The problem is that I cannot distinguish a legitimate cert for which my favorite algorithm is not present from a downgrade attack. What is so hard about this? Other protocols such as TLS renegotiation indication get this right: if both peers support renegotiation indication, they will use it (an MITM cannot trick them into not using it), otherwise various fallback policies are applied. -- Matt From jakob@kirei.se Wed Sep 21 23:19:13 2011 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 0219321F8D34 for ; Wed, 21 Sep 2011 23:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.643 X-Spam-Level: X-Spam-Status: No, score=-0.643 tagged_above=-999 required=5 tests=[AWL=0.055, 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 uCvpFJiN0f3x for ; Wed, 21 Sep 2011 23:19:12 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id E091921F8D33 for ; Wed, 21 Sep 2011 23:19:11 -0700 (PDT) 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=YLb0dP8RXkK3myenKfsUU8P0k8S4l/G6RNoQ+xkcfUE=; b=YVtyD5FJxfM8AMXj47f+8gZPiM7Vi0aLAdaqpF9ROwS0tno0XbIyXvaqLH/E4AVOdryw2lUSkck0I xJMbEBHS4JEhI3RI8eS4ueabysTSZtTaZo58Drs2EyxqByLfE6jcW5vXd+sQeMM1G4bZH6VD4wc1AR TBGdPpCWR2fm+R+g= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Thu, 22 Sep 2011 08:21:38 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: <1316670950.1941.98.camel@localhost> Date: Thu, 22 Sep 2011 08:21:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <061.add9f922b5dfb2db7544981f78552e7e@trac.tools.ietf.org> <6EB199FD-63B2-4FEA-88ED-67DB559148A0@bbn.com> <670A864B-567A-4351-AB6D-0A373AF66B9B@kumari.net> <1316658906.1941.63.camel@localhost> <017a01cc78df$55d1e180$0175a480$@augustcellars.com> <1316667624.1941.79.camel@localhost> <017b01cc78ec$03581160$0a083420$@augustcellars.com> <1316670950.1941.98.camel@localhost> To: Matt McCutchen X-Mailer: Apple Mail (2.1244.3) Cc: 'DANE WG' Subject: Re: [dane] #33: Publish enough information for the client to achieve the security of its favorite digest 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, 22 Sep 2011 06:19:13 -0000 On 22 sep 2011, at 07:55, Matt McCutchen wrote: > But I actually prefer the other approach, specifically the variant of > concatenating all the info about a single certificate in a single RR. This has the disadvantage that the RR can be quite large when providing = multiple algorithms. It also makes the RR definition more complex - in = fact I know of no other RR that has this type of variable internal data = structure (except the CERT RR). My preference would be a) requirement for cartesian product (i.e., all associations for a given = domain name must be published with the same set of matching=20 b) add a association group field indicating what associations should be = considered equal (i.e., the client may pick one association out of a = given group) jakob From matt@mattmccutchen.net Wed Sep 21 23:56:05 2011 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 D237521F8D55 for ; Wed, 21 Sep 2011 23:56:05 -0700 (PDT) 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=[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 RMj4IezacSjs for ; Wed, 21 Sep 2011 23:56:05 -0700 (PDT) Received: from homiemail-a61.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 4447421F8D50 for ; Wed, 21 Sep 2011 23:56:05 -0700 (PDT) Received: from homiemail-a61.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a61.g.dreamhost.com (Postfix) with ESMTP id D777D578071; Wed, 21 Sep 2011 23:58:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; q=dns; s= mattmccutchen.net; b=vtNGh8L46qTj/hCGsmyymZLI+G6QDlxY089OoJN2bc4 FL9N3343Ne7nrDZ9jb9jwFI6YpCB2r7+ae0KhSyARRREDGHBJhWt1ZNIoFysyWf5 yyJIOR8RSg8Drj+CI2keFvzgVZkHCk8KgVvtdNrusV+tqTxJ1+iD2IJILoZz2kZ0 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; s= mattmccutchen.net; bh=7Zz3yY8GvobBWMJlkBLhtB9mBuo=; b=i2KeR5NPbx 0sTud4SHwv+2uYiwVCrAs6ITSGEakxlrA1356VSXfV2uTSes436qzvYzDONKFe8D 0ArflkIXVfksvpBcgHYSFjWW+IY6tByzs/9jRKbpbFVXH9H4X9Bf4abjQsp57BVj A7IvM3vddRQjpeEWKooznLVdB58QNgPlQ= 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-a61.g.dreamhost.com (Postfix) with ESMTPSA id B479A57806E; Wed, 21 Sep 2011 23:58:35 -0700 (PDT) From: Matt McCutchen To: Jakob Schlyter Date: Wed, 21 Sep 2011 23:58:34 -0700 In-Reply-To: References: <061.add9f922b5dfb2db7544981f78552e7e@trac.tools.ietf.org> <6EB199FD-63B2-4FEA-88ED-67DB559148A0@bbn.com> <670A864B-567A-4351-AB6D-0A373AF66B9B@kumari.net> <1316658906.1941.63.camel@localhost> <017a01cc78df$55d1e180$0175a480$@augustcellars.com> <1316667624.1941.79.camel@localhost> <017b01cc78ec$03581160$0a083420$@augustcellars.com> <1316670950.1941.98.camel@localhost> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 Content-Transfer-Encoding: 7bit Message-ID: <1316674715.1941.106.camel@localhost> Mime-Version: 1.0 Cc: 'DANE WG' Subject: Re: [dane] #33: Publish enough information for the client to achieve the security of its favorite digest 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, 22 Sep 2011 06:56:05 -0000 On Thu, 2011-09-22 at 08:21 +0200, Jakob Schlyter wrote: > On 22 sep 2011, at 07:55, Matt McCutchen wrote: > > > But I actually prefer the other approach, specifically the variant of > > concatenating all the info about a single certificate in a single RR. > > This has the disadvantage that the RR can be quite large when > providing multiple algorithms. How is this a disadvantage? DNSSEC clients have to retrieve the entire RRset no matter how it is structured. > It also makes the RR definition more complex - in fact I know of no > other RR that has this type of variable internal data structure > (except the CERT RR). > > My preference would be > > a) requirement for cartesian product (i.e., all associations for a given domain name must be published with the same set of matching > b) add a association group field indicating what associations should be considered equal (i.e., the client may pick one association out of a given group) But others will argue that (a) is limiting and less informative than it could be and (b) is too ugly for the admins that don't use grouping. There is no perfectly convenient solution. I do hope that the people who are +1 to solving #33 can form a coalition around the approach they consider the least evil rather than split their vote across the alternatives. -- Matt From jakob@kirei.se Wed Sep 21 23:58:34 2011 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 3BA4B21F8C16 for ; Wed, 21 Sep 2011 23:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.644 X-Spam-Level: X-Spam-Status: No, score=-0.644 tagged_above=-999 required=5 tests=[AWL=0.054, 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 Efa2a4TyaEsi for ; Wed, 21 Sep 2011 23:58:33 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id E869221F8BDE for ; Wed, 21 Sep 2011 23:58:32 -0700 (PDT) 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=Eni1G7B/DRb0dXmfvdGVb+natsdhV1Gfz5ul3/Dh/OY=; b=i7uvCGVOWNOqPrRj0mIypIwtSJxRUfR2flYqIA1gh3X+Vsz5vxYstAqZP6pek/sZ3+XD4WRKESbUa aM9313Tu84rqcKh+gbAYdWsw78uJD3CtXDYwCyYoFvQBq0mvqRvZZ4UdQi2iVgGii2HuLagt6HSbDz HknjzBw7/aFCOKdo= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Thu, 22 Sep 2011 09:01:01 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: <1316674715.1941.106.camel@localhost> Date: Thu, 22 Sep 2011 09:00:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <061.add9f922b5dfb2db7544981f78552e7e@trac.tools.ietf.org> <6EB199FD-63B2-4FEA-88ED-67DB559148A0@bbn.com> <670A864B-567A-4351-AB6D-0A373AF66B9B@kumari.net> <1316658906.1941.63.camel@localhost> <017a01cc78df$55d1e180$0175a480$@augustcellars.com> <1316667624.1941.79.camel@localhost> <017b01cc78ec$03581160$0a083420$@augustcellars.com> <1316670950.1941.98.camel@localhost> <1316674715.1941.106.camel@localhost> To: Matt McCutchen X-Mailer: Apple Mail (2.1244.3) Cc: 'DANE WG' Subject: Re: [dane] #33: Publish enough information for the client to achieve the security of its favorite digest 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, 22 Sep 2011 06:58:34 -0000 On 22 sep 2011, at 08:58, Matt McCutchen wrote: >> This has the disadvantage that the RR can be quite large when >> providing multiple algorithms. >=20 > How is this a disadvantage? DNSSEC clients have to retrieve the = entire > RRset no matter how it is structured. Keeping the complexity and readability of the RR itself low is, at least = for me as a DNS person, valuable. jakob From ondrej.sury@nic.cz Thu Sep 22 00:40:11 2011 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 6482A21F8D5A for ; Thu, 22 Sep 2011 00:40:11 -0700 (PDT) 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 cxuS6YWlG8XY for ; Thu, 22 Sep 2011 00:40:10 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDE821F8D59 for ; Thu, 22 Sep 2011 00:40:10 -0700 (PDT) Received: from kimac.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 8526F2A2C86; Thu, 22 Sep 2011 09:42:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1316677358; bh=141tSMoCHoEGy6e289sNOCnsBy0RLPQ6ZvLys8q6DqA=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=FriDJcVjHwd6gFjc3K3IsjX3NLnQk0ZiqcNvrFYeNc2ZhGOt2LPvnV7Gl3ZjQtaja ShXE99nWf2g/6DtoYngtYh8PKnjTeyNIMab0nmPgJmxGF9LuICcQ/LVwwn0mMCpAgg s+qIZnkInURxjzn1KqwIYWAP9GdE2T9fTO6TVpOI= Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <201109221319000027856@163.com> Date: Thu, 22 Sep 2011 09:42:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1F3F6BBA-E2C6-451B-BC07-2146B5662981@nic.cz> References: <201109221319000027856@163.com> To: "yzw_iplab" X-Mailer: Apple Mail (2.1244.3) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane Subject: Re: [dane] Optimize the processing of multiple TLSA RRs 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, 22 Sep 2011 07:40:11 -0000 Hi, On 22. 9. 2011, at 7:19, yzw_iplab wrote: > Hi,all > According to the basic DANE protocol, multiple TLSA RRs may be = maintained for one name and the related processing principle is = discussed in the past several days. > Although anyone of the multiple TLSA RRs can be used to successfully = authenticate the server, the server may give them different preference = in practice. > For example, _443._tcp.example.com has the following two TLSA RRs: > _443._tcp.example.com TLSA 1 0 priority=3D3 SHA-512 xxxx > _443._tcp.example.com TLSA 1 0 priority=3D4 SHA-256 yyyy > Although the DNS system has no responsibility to rank them according = to their different priorities (may be the weight metric is needed in = addition) but always send all the available information to the client, = the client can optimize the authentication process using the RR with the = highest priority which is set by the TLS server according to its own = realistic considerations. > I think it is a very important and useful extension of DANE protocol. I quite don't understand what problem this extension does solve? Could you please elaborate more on the use cases? O. [off-topic] P.S.: Could you please not use the tiny tiny font (plain text is just = fine). I had a hard time reading your email without enlarging it several times. Thanks [/off-topic] -- 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 yzw_iplab@163.com Thu Sep 22 02:43:35 2011 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 39C3F21F8D35 for ; Thu, 22 Sep 2011 02:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.19 X-Spam-Level: *** X-Spam-Status: No, score=3.19 tagged_above=-999 required=5 tests=[AWL=1.580, BAYES_50=0.001, FROM_EXCESS_BASE64=1.456, HTML_MESSAGE=0.001, SARE_SUB_ENC_UTF8=0.152] 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 6Ng+yVQ-VD66 for ; Thu, 22 Sep 2011 02:43:34 -0700 (PDT) Received: from m50-134.163.com (m50-134.163.com [123.125.50.134]) by ietfa.amsl.com (Postfix) with ESMTP id E85E121F8D32 for ; Thu, 22 Sep 2011 02:43:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=Received:Date:From:To:Cc:References:Subject: Message-ID:Mime-Version:Content-Type; bh=BCpG3V67a/ivn9VMCowuEDQ YK5e7kKxtiRA2Ltfcbj4=; b=VMfaSAOZDTopCrUZcasvNu6fnB5ml3a0RfglI1R vPPjCkxtkbYtfoAJLCcN6AAvw8BIDlwshn8dRYz1hIKZLw4p8vjO8rRQejOIaryu 4+5NSbPFWZH67V1vIof5sYFG0mYxZAxJuyTbdfYlVLi6qRWbYBfzTo3jpObun501 bzkU= Received: from lenovo-THINK (unknown [218.241.103.217]) by smtp4 (Coremail) with SMTP id DtGowEBZMk3WA3tOtQvwAw--.964S2; Thu, 22 Sep 2011 17:45:58 +0800 (CST) Date: Thu, 22 Sep 2011 17:45:59 +0800 From: "=?utf-8?B?eXp3X2lwbGFi?=" To: "=?utf-8?B?ZGFuZQ==?=" References: , <201109221319000027856@163.com>, <1F3F6BBA-E2C6-451B-BC07-2146B5662981@nic.cz> Message-ID: <201109221745590946667@163.com> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon053158655300_=====" X-CM-TRANSID: DtGowEBZMk3WA3tOtQvwAw--.964S2 X-Coremail-Antispam: 1Uf129KBjvdXoW7XFy8XF18urW5XF45XF18Krg_yoW3Jwb_Ka yrZr9rAayFkFn0g3W7Aw43ZFZxXay7GF1xWw10g3y3Z348AwsrWwnayr9xtr13Xr4rtFZ8 WrnxCrWIqwnFvjkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUvcSsGvfC2KfnxnUUI43ZEXa7IUjylk3UUUUU== X-CM-SenderInfo: 512zsxhsoduqqrwthudrp/1tbiGBLCzj-6aIHCkQAAs5 Subject: Re: [dane] =?utf-8?q?Optimize_the_processing_of_multiple_TLSA_RRs?= 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, 22 Sep 2011 09:43:35 -0000 This is a multi-part message in MIME format. --=====003_Dragon053158655300_===== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Dear all, I mean the TLS server may have multiple certificates registered in the DNS system. However, according to the efficiency and/or security consideration, the TLS server may have different preference for them to be used. Then a priority metric can be included in the RR and then the client can use the most recommended TLSA RR. Historically, the priority and weight in SRV do not be widely used in practice. However, I think it will certainly be adopted in the future with the widely development of Internet. For our TLSA RR, we should foresee this use case and work on it in advance. Maybe we can make this feature as an optional function at this early stage, but it is a necessary try. What's your opinion? BR, Zhiwei 2011-09-22 yzw_iplab --=====003_Dragon053158655300_===== Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0 PXV0Zi04IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIG5hbWU9R0VORVJBVE9SIGNv bnRlbnQ9Ik1TSFRNTCA5LjAwLjgxMTIuMTY0MzQiPg0KPFNUWUxFPkBmb250LWZhY2Ugew0KCWZv bnQtZmFtaWx5OiDlrovkvZM7DQp9DQpAZm9udC1mYWNlIHsNCglmb250LWZhbWlseTogVmVyZGFu YTsNCn0NCkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBA5a6L5L2TOw0KfQ0KQHBhZ2UgU2Vj dGlvbjEge3NpemU6IDU5NS4zcHQgODQxLjlwdDsgbWFyZ2luOiA3Mi4wcHQgOTAuMHB0IDcyLjBw dCA5MC4wcHQ7IGxheW91dC1ncmlkOiAxNS42cHQ7IH0NClAuTXNvTm9ybWFsIHsNCglURVhULUpV U1RJRlk6IGludGVyLWlkZW9ncmFwaDsgVEVYVC1BTElHTjoganVzdGlmeTsgTUFSR0lOOiAwY20g MGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iOyBGT05ULVNJWkU6IDEwLjVw dA0KfQ0KTEkuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJRlk6IGludGVyLWlkZW9ncmFwaDsgVEVY VC1BTElHTjoganVzdGlmeTsgTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1l cyBOZXcgUm9tYW4iOyBGT05ULVNJWkU6IDEwLjVwdA0KfQ0KRElWLk1zb05vcm1hbCB7DQoJVEVY VC1KVVNUSUZZOiBpbnRlci1pZGVvZ3JhcGg7IFRFWFQtQUxJR046IGp1c3RpZnk7IE1BUkdJTjog MGNtIDBjbSAwcHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgRk9OVC1TSVpFOiAx MC41cHQNCn0NCkE6bGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJs aW5lDQp9DQpTUEFOLk1zb0h5cGVybGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElP TjogdW5kZXJsaW5lDQp9DQpBOnZpc2l0ZWQgew0KCUNPTE9SOiBwdXJwbGU7IFRFWFQtREVDT1JB VElPTjogdW5kZXJsaW5lDQp9DQpTUEFOLk1zb0h5cGVybGlua0ZvbGxvd2VkIHsNCglDT0xPUjog cHVycGxlOyBURVhULURFQ09SQVRJT046IHVuZGVybGluZQ0KfQ0KU1BBTi5FbWFpbFN0eWxlMTcg ew0KCUZPTlQtU1RZTEU6IG5vcm1hbDsgRk9OVC1GQU1JTFk6IFZlcmRhbmE7IENPTE9SOiB3aW5k b3d0ZXh0OyBGT05ULVdFSUdIVDogbm9ybWFsOyBURVhULURFQ09SQVRJT046IG5vbmU7IG1zby1z dHlsZS10eXBlOiBwZXJzb25hbC1jb21wb3NlDQp9DQpESVYuU2VjdGlvbjEgew0KCXBhZ2U6IFNl Y3Rpb24xDQp9DQpVTktOT1dOIHsNCglGT05ULVNJWkU6IDEwcHQNCn0NCkJMT0NLUVVPVEUgew0K CU1BUkdJTi1UT1A6IDBweDsgTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tTEVGVDogMmVtDQp9 DQpPTCB7DQoJTUFSR0lOLVRPUDogMHB4OyBNQVJHSU4tQk9UVE9NOiAwcHgNCn0NClVMIHsNCglN QVJHSU4tVE9QOiAwcHg7IE1BUkdJTi1CT1RUT006IDBweA0KfQ0KPC9TVFlMRT4NCjwvSEVBRD4N CjxCT0RZIHN0eWxlPSJNQVJHSU46IDEwcHg7IEZPTlQtRkFNSUxZOiB2ZXJkYW5hOyBGT05ULVNJ WkU6IDEwcHQiPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwIHNpemU9MiBmYWNlPVZlcmRhbmE+ DQo8RElWPkRlYXImbmJzcDthbGwsPC9ESVY+DQo8RElWPkkmbmJzcDttZWFuJm5ic3A7dGhlJm5i c3A7VExTJm5ic3A7c2VydmVyJm5ic3A7bWF5Jm5ic3A7aGF2ZSZuYnNwO211bHRpcGxlJm5ic3A7 Y2VydGlmaWNhdGVzJm5ic3A7cmVnaXN0ZXJlZCZuYnNwO2luJm5ic3A7dGhlJm5ic3A7RE5TJm5i c3A7c3lzdGVtLjwvRElWPg0KPERJVj5Ib3dldmVyLCZuYnNwO2FjY29yZGluZyZuYnNwO3RvJm5i c3A7dGhlJm5ic3A7ZWZmaWNpZW5jeSZuYnNwO2FuZC9vciZuYnNwO3NlY3VyaXR5Jm5ic3A7Y29u c2lkZXJhdGlvbiwmbmJzcDt0aGUmbmJzcDtUTFMmbmJzcDtzZXJ2ZXI8L0RJVj4NCjxESVY+bWF5 Jm5ic3A7aGF2ZSZuYnNwO2RpZmZlcmVudCZuYnNwO3ByZWZlcmVuY2UmbmJzcDtmb3ImbmJzcDt0 aGVtJm5ic3A7dG8mbmJzcDtiZSZuYnNwO3VzZWQuJm5ic3A7VGhlbiZuYnNwO2EmbmJzcDtwcmlv cml0eSZuYnNwO21ldHJpYyZuYnNwO2NhbiZuYnNwO2JlJm5ic3A7PC9ESVY+DQo8RElWPmluY2x1 ZGVkJm5ic3A7aW4mbmJzcDt0aGUmbmJzcDtSUiZuYnNwO2FuZCZuYnNwO3RoZW4mbmJzcDt0aGUm bmJzcDtjbGllbnQmbmJzcDtjYW4mbmJzcDt1c2UmbmJzcDt0aGUmbmJzcDttb3N0Jm5ic3A7cmVj b21tZW5kZWQmbmJzcDtUTFNBJm5ic3A7UlIuPC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj4mbmJz cDs8L0RJVj4NCjxESVY+SGlzdG9yaWNhbGx5LCZuYnNwO3RoZSZuYnNwO3ByaW9yaXR5Jm5ic3A7 YW5kJm5ic3A7d2VpZ2h0Jm5ic3A7aW4mbmJzcDtTUlYmbmJzcDtkbyZuYnNwO25vdCZuYnNwO2Jl Jm5ic3A7d2lkZWx5Jm5ic3A7dXNlZCZuYnNwO2luJm5ic3A7cHJhY3RpY2UuPC9ESVY+DQo8RElW Pkhvd2V2ZXIsJm5ic3A7SSZuYnNwO3RoaW5rJm5ic3A7aXQmbmJzcDt3aWxsJm5ic3A7Y2VydGFp bmx5Jm5ic3A7YmUmbmJzcDthZG9wdGVkJm5ic3A7aW4mbmJzcDt0aGUmbmJzcDtmdXR1cmUmbmJz cDt3aXRoJm5ic3A7dGhlJm5ic3A7d2lkZWx5PC9ESVY+DQo8RElWPmRldmVsb3BtZW50Jm5ic3A7 b2YmbmJzcDtJbnRlcm5ldC48L0RJVj4NCjxESVY+Rm9yJm5ic3A7b3VyJm5ic3A7VExTQSZuYnNw O1JSLCZuYnNwO3dlJm5ic3A7c2hvdWxkJm5ic3A7Zm9yZXNlZSZuYnNwO3RoaXMmbmJzcDt1c2Um bmJzcDtjYXNlJm5ic3A7YW5kJm5ic3A7d29yayZuYnNwO29uJm5ic3A7aXQmbmJzcDtpbiZuYnNw O2FkdmFuY2UuPC9ESVY+DQo8RElWPk1heWJlJm5ic3A7d2UmbmJzcDtjYW4mbmJzcDttYWtlJm5i c3A7dGhpcyZuYnNwO2ZlYXR1cmUmbmJzcDthcyZuYnNwO2FuJm5ic3A7b3B0aW9uYWwmbmJzcDtm dW5jdGlvbiZuYnNwO2F0Jm5ic3A7dGhpcyZuYnNwO2Vhcmx5Jm5ic3A7c3RhZ2UsJm5ic3A7YnV0 PC9ESVY+DQo8RElWPml0Jm5ic3A7aXMmbmJzcDthJm5ic3A7bmVjZXNzYXJ5Jm5ic3A7dHJ5LiZu YnNwOzwvRElWPg0KPERJVj5XaGF0J3MmbmJzcDt5b3VyJm5ic3A7b3Bpbmlvbj88L0RJVj4NCjxE SVY+QlIsPC9ESVY+DQo8RElWPlpoaXdlaTwvRElWPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQg Y29sb3I9IzAwMDA4MCBzaXplPTIgZmFjZT1WZXJkYW5hPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxE SVY+PEZPTlQgY29sb3I9IzAwMDA4MCBzaXplPTIgZmFjZT1WZXJkYW5hPjwvRk9OVD4mbmJzcDs8 L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9I2MwYzBjMCBzaXplPTIgZmFjZT1WZXJkYW5hPjIwMTEt MDktMjIgPC9GT05UPjwvRElWPjxGT05UIA0KY29sb3I9IzAwMDA4MCBzaXplPTIgZmFjZT1WZXJk YW5hPg0KPEhSIHN0eWxlPSJXSURUSDogMTAwcHgiIGFsaWduPWxlZnQgY29sb3I9I2I1YzRkZiBT SVpFPTE+DQo8L0ZPTlQ+DQo8RElWPjxGT05UIGNvbG9yPSNjMGMwYzAgc2l6ZT0yIGZhY2U9VmVy ZGFuYT48U1BBTj55endfaXBsYWI8L1NQQU4+IA0KPC9GT05UPjwvRElWPg0KPEhSIGNvbG9yPSNi NWM0ZGYgU0laRT0xPg0KDQo8RElWPjxGT05UIHNpemU9MiBmYWNlPVZlcmRhbmE+Jm5ic3A7PC9E SVY+PC9GT05UPjwvQk9EWT48L0hUTUw+DQo= --=====003_Dragon053158655300_=====-- From hallam@gmail.com Thu Sep 22 06:34:08 2011 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 C580721F8CBE for ; Thu, 22 Sep 2011 06:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.47 X-Spam-Level: X-Spam-Status: No, score=-3.47 tagged_above=-999 required=5 tests=[AWL=0.128, 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 h-REm626DsSL for ; Thu, 22 Sep 2011 06:34:06 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9E2D421F8CA9 for ; Thu, 22 Sep 2011 06:34:06 -0700 (PDT) Received: by ywa6 with SMTP id 6so2383231ywa.31 for ; Thu, 22 Sep 2011 06:36:38 -0700 (PDT) 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=eWXUtNQN/PQU5Zu+zwaWi8pgntzX4UpWUvCkkd23JZI=; b=jFig53W8CBY3VbVuAJaMp5LQzE4enIRKJxqSsMYwbqCMFsV/71TUE4iMph/N87V6TK Gl+DGbwoi2yQjUwDNWBx+U4zWGQGgIiv/QIFxy79scxaJJXJdbAWVFpuBQeewsAVbBmK Mvg5Ow3QE/a3vJ4cLtUMjuV6kCvLScmWRwvVo= MIME-Version: 1.0 Received: by 10.101.27.34 with SMTP id e34mr1964406anj.162.1316698597796; Thu, 22 Sep 2011 06:36:37 -0700 (PDT) Received: by 10.101.71.4 with HTTP; Thu, 22 Sep 2011 06:36:37 -0700 (PDT) In-Reply-To: <017a01cc78df$55d1e180$0175a480$@augustcellars.com> References: <061.add9f922b5dfb2db7544981f78552e7e@trac.tools.ietf.org> <6EB199FD-63B2-4FEA-88ED-67DB559148A0@bbn.com> <670A864B-567A-4351-AB6D-0A373AF66B9B@kumari.net> <1316658906.1941.63.camel@localhost> <017a01cc78df$55d1e180$0175a480$@augustcellars.com> Date: Thu, 22 Sep 2011 09:36:37 -0400 Message-ID: From: Phillip Hallam-Baker To: Jim Schaad Content-Type: multipart/alternative; boundary=001636b2b89332a9bd04ad87c8d1 Cc: Paul Hoffman , DANE WG Subject: Re: [dane] #33: Publish enough information for the client to achieve the security of its favorite digest 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, 22 Sep 2011 13:34:08 -0000 --001636b2b89332a9bd04ad87c8d1 Content-Type: text/plain; charset=ISO-8859-1 I think that what it comes down to is that zones MUST provide a digest value for all certs under the digest used in the certificate and clients MUST support DANE processing for all the digests that are supported in certs. In other words, what is the point of insisting on SHA-512 in the DANE record if the cert itself is signed using SHA-256? Consider the following cases: Case #1 rollover Client accepts SHA256 and SHA512, so the rollover zone looks like this to the client: _443._tcp.example.com TLSA 1 0 SHA-512 cert1 _443._tcp.example.com TLSA 1 0 SHA-512 cert2 _443._tcp.example.com TLSA 1 0 SHA-256 cert1 _443._tcp.example.com TLSA 1 0 SHA-256 cert2 This gives the correct behavior for a cert that matches and a cert that does not match. Case #2 rollover - non SHA-512 capable client. The zone above become. _443._tcp.example.com TLSA 1 0 ????? _443._tcp.example.com TLSA 1 0 ????? _443._tcp.example.com TLSA 1 0 SHA-256 cert1 _443._tcp.example.com TLSA 1 0 SHA-256 cert2 This gives the correct behavior for a cert that matches and a cert that does not match. Provided that the SHA-512 records are ignored completely. Case #3 rollover - SHA-256 is untrusted This is essentially the same as case #2. The big difference is that insisting on a SHA-512 certificate has no point unless the client can also process SHA-512 in its cert handling. Now for the corner cases: Case #4, no digest is known. _443._tcp.example.com TLSA 1 0 ????? _443._tcp.example.com TLSA 1 0 ????? All the records are ignored and so the TLSA records become the null set and that means allow anything. Moral - zones must contain at least one widely supported digest (well duh!). Case #5, zone has different certificates for the same keys using the same digest as the cert in question: _443._tcp.example.com TLSA 1 0 SHA-512 cert1-512 _443._tcp.example.com TLSA 1 0 SHA-512 cert2-512 _443._tcp.example.com TLSA 1 0 SHA-256 cert1-256 _443._tcp.example.com TLSA 1 0 SHA-256 cert2-256 This is the rollover case that makes sense to me since a client that can process a digest in the cert should be able to process it in the DANE record as well. This is incidentally why you are still wrong about introducing a new registry for DANE digest identifiers that has to be kept in sync. This is only going to make sense once there is a deployed mechanism that allows the TLS client to negotiate the cert algorithm. Case #6 zone has digests for some keys but not others. _443._tcp.example.com TLSA 1 0 SHA-512 cert1 _443._tcp.example.com TLSA 1 0 SHA-256 cert1 _443._tcp.example.com TLSA 1 0 SHA-256 cert2 I think that the correct approach here is to tell the deployer why it won't work and let them hang themselves. The only real worry would be that nincompoops will deploy this type of record and then try to insist on clients still respecting the SHA-256 record. I don't see that as a problem really. On Thu, Sep 22, 2011 at 12:23 AM, Jim Schaad wrote: > This demonstrates why I have said that an algorithm either is or is not > good > enough. While it could be doing a roll over, it could also be selecting > the > certificate based on the criteria that you gave in the TLS handshake and > using the same hash algorithm for both the certificate and the TLSA > statement. > > If your client wants to sort the TLSA records and process them in preferred > order, there is nothing to prevent that. But you cannot assume that the > host operator has the same feeling for the algorithm that you have. > > Jim > > > > -----Original Message----- > > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of > > Matt McCutchen > > Sent: Wednesday, September 21, 2011 7:35 PM > > To: Warren Kumari > > Cc: Paul Hoffman; DANE WG > > Subject: Re: [dane] #33: Publish enough information for the client to > achieve > > the security of its favorite digest > > > > On Wed, 2011-09-21 at 11:39 -0400, Warren Kumari wrote: > > > On Sep 21, 2011, at 11:28 AM, Paul Hoffman wrote: > > > > > > > On Sep 21, 2011, at 8:01 AM, Richard L. Barnes wrote: > > > > > > > >> Could you clarify what you mean by "the security of its favorite > digest"? > > > > > > > > +1 to the request for clarification. The current protocol says what > digest > > function is being used by DANE. > > > > > > +1 again -- and the client gets the TLSA records and can choose "its > favorite" > > already... > > > > Suppose I as the client prefer SHA-512 to SHA-256 and wish to achieve the > > security of SHA-512 whenever possible but still interoperate with servers > that > > do not fully support SHA-512. I receive a TLSA RRset: > > > > _443._tcp.example.com TLSA 1 0 SHA-512 xxxx _443._tcp.example.com TLSA > > 1 0 SHA-256 yyyy > > > > And the cert has SHA-256 yyyy but does not have SHA-512 xxxx. Is this a > > rollover in progress, or is someone trying to attack me via a SHA-256 > second > > preimage? If I try to choose my favorite digest, I fail against servers > > performing legitimate rollovers. > > > > > > Now do you get the point? > > > > -- > > Matt > > > > _______________________________________________ > > dane mailing list > > dane@ietf.org > > https://www.ietf.org/mailman/listinfo/dane > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > -- Website: http://hallambaker.com/ --001636b2b89332a9bd04ad87c8d1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think that what it comes down to is that zones MUST provide a digest valu= e for all certs under the digest used in the certificate and clients MUST s= upport DANE processing for all the digests that are supported in certs.
In other words, what is the point of insisting on SHA-512 in= the DANE record if the cert itself is signed using SHA-256?
<= br>

Consider the following cases:

Case #1 rollover

Client accepts SHA256 and SHA512,= so the rollover zone looks like this to the client:

_443._tcp.example.com=A0TLSA 1 0 SHA-512 cert1<= br> _443._tcp.example.com=A0TLSA 1 0 SHA-512 cert2
_443._<= a href=3D"http://tcp.example.com/" target=3D"_blank" style=3D"color: rgb(54= , 84, 82); ">tcp.example.com=A0TLSA 1 0 SHA-256 cert1
_443._tcp.example.com=A0TLSA 1 0 SHA-256 cert2

This gives the correct behavior for a cert that matc= hes and a cert that does not match.


Case #2 rollover - non SHA-= 512 capable client.

The zone above become.

_443._tcp.exam= ple.com=A0TLSA 1 0 ?????
_443._tcp.example.com=A0TLSA 1 0 ?????
_443._tcp.example.com=A0TLSA 1 0 SHA-256 cert1
_443._tcp.example.com=A0TLSA 1 0 SHA-256 cert2

This gives the correct behavior for a cert = that matches and a cert that does not match. Provided that the SHA-512 reco= rds are ignored completely.


Case #3 rollover - SHA-256 is = untrusted

This is essentially the same as case #2.=

The big difference is that insisting on a SHA-512 certi= ficate has no point unless the client can also process SHA-512 in its cert = handling.


Now for the corner cases:=


Case #4, no digest is known.
<= br>
_443._tcp.example.com=A0TLSA 1 0 ?????=
_443._tcp.example.com=A0TLSA 1 0 ?????
<= span class=3D"Apple-style-span" style=3D"color: rgb(51, 51, 51); font-famil= y: arial, sans-serif; font-size: 13px; background-color: rgb(255, 255, 255)= ; ">
All the records are ignored and so the TLSA records = become the null set and that means allow anything.

Moral - zones must contain at least on= e widely supported digest (well duh!).



Case #5, zone has differe= nt certificates for the same keys using the same digest as the cert in ques= tion:

_443._tcp.example.com=A0TLSA 1 0 SHA-512 cert1-512
_443._tcp.example.com=A0TLSA 1 0 SHA-512 cert2-512
_44= 3._tcp.example.com=A0TLSA 1 0 SHA-256 cert1-256
_443._tcp.example.com=A0TLSA 1 0 SHA-256 cert2-256=

This is the rollover case that makes sense to me = since a client that can process a digest in the cert should be able to proc= ess it in the DANE record as well.

This is incidentally why you are still wrong about intr= oducing a new registry for DANE digest identifiers that has to be kept in s= ync.

This is only going to make sense once there i= s a deployed mechanism that allows the TLS client to negotiate the cert alg= orithm.


Case #6 zone has digests for some keys b= ut not others.

_443._tcp.exampl= e.com=A0TLSA 1 0 SHA-512 cert1
_443._tcp.example.com=A0TLSA 1 0 SHA-256 cert1
_443._<= a href=3D"http://tcp.example.com/" target=3D"_blank" style=3D"color: rgb(54= , 84, 82); ">tcp.example.com=A0TLSA 1 0 SHA-256 cert2

I think that the correct approach here is to tell the d= eployer why it won't work and let them hang themselves.

<= /div>
The only real worry would be that nincompoops will deploy this ty= pe of record and then try to insist on clients still respecting the SHA-256= record. I don't see that as a problem really.


On Thu, Sep 22, 2011 at 12:23 AM, J= im Schaad <i= etf@augustcellars.com> wrote:
This demonstrates why I have said that an algorithm either is or is not goo= d
enough. =A0While it could be doing a roll over, it could also be selecting = the
certificate based on the criteria that you gave in the TLS handshake and using the same hash algorithm for both the certificate and the TLSA
statement.

If your client wants to sort the TLSA records and process them in preferred=
order, there is nothing to prevent that. =A0But you cannot assume that the<= br> host operator has the same feeling for the algorithm that you have.

Jim


> -----Original Message-----
> From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of
> Matt McCutchen
> Sent: Wednesday, September 21, 2011 7:35 PM
> To: Warren Kumari
> Cc: Paul Hoffman; DANE WG
> Subject: Re: [dane] #33: Publish enough information for the client to<= br> achieve
> the security of its favorite digest
>
> On Wed, 2011-09-21 at 11:39 -0400, Warren Kumari wrote:
> > On Sep 21, 2011, at 11:28 AM, Paul Hoffman wrote:
> >
> > > On Sep 21, 2011, at 8:01 AM, Richard L. Barnes wrote:
> > >
> > >> Could you clarify what you mean by "the security of= its favorite
digest"?
> > >
> > > +1 to the request for clarification. The current protocol sa= ys what
digest
> function is being used by DANE.
> >
> > +1 again -- and the client gets the TLSA records and can choose &= quot;its
favorite"
> already...
>
> Suppose I as the client prefer SHA-512 to SHA-256 and wish to achieve = the
> security of SHA-512 whenever possible but still interoperate with serv= ers
that
> do not fully support SHA-512. =A0I receive a TLSA RRset:
>
> _443._tcp.example= .com TLSA 1 0 SHA-512 xxxx _443._tcp.example.com TLSA
> 1 0 SHA-256 yyyy
>
> And the cert has SHA-256 yyyy but does not have SHA-512 xxxx. =A0Is th= is a
> rollover in progress, or is someone trying to attack me via a SHA-256<= br> second
> preimage? =A0If I try to choose my favorite digest, I fail against ser= vers
> performing legitimate rollovers.
>
>
> Now do you get the point?
>
> --
> Matt
>
> _______________________________________________
> dane mailing list
> dane@ietf.org
> https://www.ietf.org/mailman/listinfo/dane

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



--
= Website: http://hallambaker.com/
--001636b2b89332a9bd04ad87c8d1-- From paul.hoffman@vpnc.org Thu Sep 22 07:53:04 2011 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 7EDFD21F8B10 for ; Thu, 22 Sep 2011 07:53:04 -0700 (PDT) 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 20F1Vc6y-5tV for ; Thu, 22 Sep 2011 07:53:03 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4B521F8B7C for ; Thu, 22 Sep 2011 07:53:02 -0700 (PDT) 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 p8MEtXkv020183 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 22 Sep 2011 07:55:34 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <1316658906.1941.63.camel@localhost> Date: Thu, 22 Sep 2011 07:55:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <042EE416-702E-47DF-8748-E5AD3E6583E1@vpnc.org> References: <061.add9f922b5dfb2db7544981f78552e7e@trac.tools.ietf.org> <6EB199FD-63B2-4FEA-88ED-67DB559148A0@bbn.com> <670A864B-567A-4351-AB6D-0A373AF66B9B@kumari.net> <1316658906.1941.63.camel@localhost> To: Matt McCutchen X-Mailer: Apple Mail (2.1244.3) Cc: DANE WG Subject: Re: [dane] #33: Publish enough information for the client to achieve the security of its favorite digest 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, 22 Sep 2011 14:53:04 -0000 On Sep 21, 2011, at 7:35 PM, Matt McCutchen wrote: > On Wed, 2011-09-21 at 11:39 -0400, Warren Kumari wrote: >> On Sep 21, 2011, at 11:28 AM, Paul Hoffman wrote: >>=20 >>> On Sep 21, 2011, at 8:01 AM, Richard L. Barnes wrote: >>>=20 >>>> Could you clarify what you mean by "the security of its favorite = digest"? =20 >>>=20 >>> +1 to the request for clarification. The current protocol says what = digest function is being used by DANE. >>=20 >> +1 again -- and the client gets the TLSA records and can choose "its = favorite" already... >=20 > Suppose I as the client prefer SHA-512 to SHA-256 and wish to achieve > the security of SHA-512 whenever possible but still interoperate with > servers that do not fully support SHA-512. I receive a TLSA RRset: >=20 > _443._tcp.example.com TLSA 1 0 SHA-512 xxxx > _443._tcp.example.com TLSA 1 0 SHA-256 yyyy >=20 > And the cert has SHA-256 yyyy but does not have SHA-512 xxxx. Is this = a > rollover in progress, or is someone trying to attack me via a SHA-256 > second preimage? =20 There is no sane way for a security protocol to fully deal with a = preimage weakening for any supported hash algorithm. If you believe that = this statement is incorrect, please point to the protocol that does. > If I try to choose my favorite digest, I fail against > servers performing legitimate rollovers. Others have already commented on this scenario, and I agree with them. > Now do you get the point? Yes, and I fully disagree with it. Your unstated assumption is that we = can predict which hash functions will be considered stronger or weaker, = and that is a false assumption. Typical clients will assume that all allowed hash types are secure = enough for their purposes. Atypical clients may have additional rules = for picking between different hash types, and such picking-and-choosing = is fully allowed by the protocol. Different atypical clients will have = different additional rules, so a domain cannot do anything about them. --Paul Hoffman From paul.hoffman@vpnc.org Thu Sep 22 08:04:59 2011 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 F081521F8C0E for ; Thu, 22 Sep 2011 08:04:58 -0700 (PDT) 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 qSGNNZuOSzYG for ; Thu, 22 Sep 2011 08:04:58 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7015F21F8BF9 for ; Thu, 22 Sep 2011 08:04:58 -0700 (PDT) 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 p8MF7TPf027258 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 22 Sep 2011 08:07:30 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1244.3) From: Paul Hoffman In-Reply-To: <016e01cc78dd$600927a0$201b76e0$@augustcellars.com> Date: Thu, 22 Sep 2011 08:07:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <48D0BA36-7FD5-4F99-9675-7602CCB50F72@vpnc.org> References: <056.1a974588106d5c2e6a6fd25a8a0d7236@trac.tools.ietf.org> <1D25BD4E-3D9A-4B9F-BF63-0204CE89534B@kumari.net> <337DB9C1-F674-48B9-8B65-6BD7A34C8E18@vpnc.org> <016e01cc78dd$600927a0$201b76e0$@augustcellars.com> To: DANE WG X-Mailer: Apple Mail (2.1244.3) 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 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, 22 Sep 2011 15:04:59 -0000 On Sep 21, 2011, at 9:09 PM, Jim Schaad wrote: > I can completely understand the position that you are taking, and I = wish I > had a really good reason for saying it is the "wrong" one. = Unfortunately I > don't. Noted. > Just to be clear and to make sure that you understand what I believe = the > implications of you position are: >=20 > Suppose a host publishes a TLSA record with a matching requirement of > matching using the MUST-HASH1 algorithm (i.e. the algorithm is = declared a > MUST implement by the DANE specification). >=20 > Suppose I have some super hacker who has come to me and given me a = possible > proof that MUST-HASH1 algorithm is/has been broken but we have not yet = gone > public (or any of a number of other reasons including the fact that I = don't > like the US government and believe that they put a back door into the > algorithm). Thus I have stated it will not be used by my clients = (thus > making them unable to talk to half the world). >=20 > My client down loads the TLSA records for the website that I am = connecting > to. It finds the TLSA record for MUST-HASH1 and no other ones and my = client > is fully DANE aware. Your position is that I should toss out the fact = that > there is a DANE record in existence and do normal TLS connection = processing > even though the operator has attempted to give me a piece of good > information that have chosen not to believe. Almost. The operator *did* give you a piece of good information; you = subsequently chose not to believe it due to local policy. > In this case it is probable that normal processing would fail = rendering the > whole thing moot as I would probably not accept the hash algorithm for = doing > certificate path validation either. Bingo. TLSA should not be in the business of saying "don't go forwards = with TLS" in cases where you have made a local TLSA policy. If you don't = trust a hash type, it is no different than you not understanding the = hash type. > As I said, I don't have a good reason for saying your position is = incorrect. > If the group says that is the correct position I would not argue. I = just > want the position to be clearly stated. Your example above is indeed clearer than the ones that started this = thread, so thank you. --Paul Hoffman From paul.hoffman@vpnc.org Thu Sep 22 08:13:45 2011 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 C071121F8B9D for ; Thu, 22 Sep 2011 08:13:45 -0700 (PDT) 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 TQSStzUi2emX for ; Thu, 22 Sep 2011 08:13:45 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 46FBE21F8B8C for ; Thu, 22 Sep 2011 08:13:45 -0700 (PDT) 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 p8MFGB5C032353 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 22 Sep 2011 08:16:13 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <201109221745590946667@163.com> Date: Thu, 22 Sep 2011 08:16:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: , <201109221319000027856@163.com>, <1F3F6BBA-E2C6-451B-BC07-2146B5662981@nic.cz> <201109221745590946667@163.com> To: yzw_iplab X-Mailer: Apple Mail (2.1244.3) Cc: dane Subject: Re: [dane] Optimize the processing of multiple TLSA RRs 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, 22 Sep 2011 15:13:45 -0000 On Sep 22, 2011, at 2:45 AM, yzw_iplab wrote: > Dear all, > I mean the TLS server may have multiple certificates registered in the = DNS system. > However, according to the efficiency and/or security consideration, = the TLS server > may have different preference for them to be used. Then a priority = metric can be=20 > included in the RR and then the client can use the most recommended = TLSA RR. This is at odds with the way that TLS works. TLS only allows the server = to present one EE certificate. Thus, there is no "priority" among = multiple certificates. The "Trusted CA Indication" extension can be used = by the client to say which trust anchor they want to chain to, but that = is a signal from the client to the server.=20 Even if, in the future, TLS has better facility for the server to have = multiple certs so that it might have a preference, I don't see why TLSA = would need to be in the business of expressing that preference: it = should *only* be part of TLS. That is, what would a client do if TLSA = says the preference was "A B C" but the (future) TLS server said the = preference was "C B A"? --Paul Hoffman From mrex@sap.com Thu Sep 22 08:25:38 2011 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 345C821F8C94 for ; Thu, 22 Sep 2011 08:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.056 X-Spam-Level: X-Spam-Status: No, score=-10.056 tagged_above=-999 required=5 tests=[AWL=0.193, 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 808MhVawEnhd for ; Thu, 22 Sep 2011 08:25:37 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 56B0B21F8C8B for ; Thu, 22 Sep 2011 08:25:37 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p8MFS6NN006278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Sep 2011 17:28:07 +0200 (MEST) From: Martin Rex Message-Id: <201109221528.p8MFS6bE017153@fs4113.wdf.sap.corp> To: paul.hoffman@vpnc.org (Paul Hoffman) Date: Thu, 22 Sep 2011 17:28:06 +0200 (MEST) In-Reply-To: <042EE416-702E-47DF-8748-E5AD3E6583E1@vpnc.org> from "Paul Hoffman" at Sep 22, 11 07:55:34 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] #33: Publish enough information for the client to 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, 22 Sep 2011 15:25:38 -0000 Paul, Paul Hoffman wrote: > > On Sep 21, 2011, at 7:35 PM, Matt McCutchen wrote: > > > > Suppose I as the client prefer SHA-512 to SHA-256 and wish to achieve > > the security of SHA-512 whenever possible but still interoperate with > > servers that do not fully support SHA-512. I receive a TLSA RRset: > > > > _443._tcp.example.com TLSA 1 0 SHA-512 xxxx > > _443._tcp.example.com TLSA 1 0 SHA-256 yyyy > > > > And the cert has SHA-256 yyyy but does not have SHA-512 xxxx. Is this a > > rollover in progress, or is someone trying to attack me via a SHA-256 > > second preimage? > > There is no sane way for a security protocol to fully deal with a preimage > weakening for any supported hash algorithm. "The way" is easy and straightforward: require the cartesian product so that DANE clients distrusting one algorithm can entirely ignore all records with that algorithm. It doesn't seem like there is consenus that a requirement for an cartesian product is a "sane way". The problem is that it scales so badly. > > If you believe that this > statement is incorrect, please point to the protocol that does. If a security protocol _protects_ the negotiation of common algorithm between peers, then it just works. Think of the TLS cipher suite negotiation. If DNSSEC ensures that an attacker can not hide only specific TLSA records from the DANE client's view, then a client's selection by own preference in combination with a cartesian product requirement would do the trick. > > Your unstated assumption is that we can predict which hash functions > will be considered stronger or weaker, and that is a false assumption. I do not believe that was asserted. A protected negotiation or protected selection by preference scheme will allow to securely choose a "weak" algorithm in exactly the same way as securely choosing a "strong" algorithm, the is no bias in that scheme. But as long as lots of the crypto stuff that is involved (TLS and DNSSEC) has SHA1 all over the place and no realistic perspective to move those protocols to somethings _stronger_ than SHA-256 anywhere soon, support for allegedly stronger hash algorithms in DANE than SHA-256, such as SHA-512 or SHA-3, amounts to bikeshedding. -Martin From rob.stradling@comodo.com Thu Sep 22 08:29:54 2011 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 8C50421F8C52 for ; Thu, 22 Sep 2011 08:29:54 -0700 (PDT) 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=[AWL=-0.001, 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 JlI-+wh1PSHI for ; Thu, 22 Sep 2011 08:29:54 -0700 (PDT) Received: from mmmail1.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 8F14821F8BDE for ; Thu, 22 Sep 2011 08:29:53 -0700 (PDT) Received: (qmail 28501 invoked from network); 22 Sep 2011 15:32:23 -0000 Received: from ian.bd.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 22 Sep 2011 15:32:23 -0000 Received: (qmail 6476 invoked by uid 1000); 22 Sep 2011 15:32:23 -0000 Received: from nigel.brad.office.comodo.net (HELO nigel.localnet) (192.168.0.58) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES256-SHA encrypted) ESMTPS; Thu, 22 Sep 2011 16:32:23 +0100 From: Rob Stradling To: dane@ietf.org Date: Thu, 22 Sep 2011 16:30:00 +0100 User-Agent: KMail/1.13.7 (Linux/2.6.39-gentoo-r3; KDE/4.6.5; i686; ; ) References: <201109221745590946667@163.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201109221630.07491.rob.stradling@comodo.com> Cc: yzw_iplab , Paul Hoffman Subject: Re: [dane] Optimize the processing of multiple TLSA RRs 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, 22 Sep 2011 15:29:54 -0000 On Thursday 22 Sep 2011 16:16:11 Paul Hoffman wrote: > On Sep 22, 2011, at 2:45 AM, yzw_iplab wrote: > > Dear all, > > I mean the TLS server may have multiple certificates registered in the > > DNS system. However, according to the efficiency and/or security > > consideration, the TLS server may have different preference for them to > > be used. Then a priority metric can be included in the RR and then the > > client can use the most recommended TLSA RR. > > This is at odds with the way that TLS works. TLS only allows the server to > present one EE certificate. It's true that a TLS Server may only "present one EE certificate" per handshake, but that doesn't mean it will always send the same "one EE certificate" in every handshake with every TLS Client. Some examples... Client specifies the SNI extension: $ openssl s_client -connect sni.velox.ch:443 -servername alice.sni.velox.ch 2> /dev/null | head -n 4 | tail -n 2 Certificate chain 0 s:/C=CH/ST=Zuerich/L=Zuerich/O=Kaspar Brand/CN=alice.sni.velox.ch $ openssl s_client -connect sni.velox.ch:443 -servername bob.sni.velox.ch 2> /dev/null | head -n 4 | tail -n 2 Certificate chain 0 s:/C=CH/ST=Zuerich/L=Zuerich/O=Kaspar Brand/CN=bob.sni.velox.ch Client specifies certain cipher(s): $ openssl s_client -connect tls.secg.org:40023 -cipher RSA 2> /dev/null | head -n 4 | tail -n 2 Certificate chain 0 s:/OU=SAMPLE ONLY/O=Certicom Corp./L=Toronto/SN=Ontario/CN=tls.secg.org RSA 1024 Server Certificate/C=CA $ openssl s_client -connect tls.secg.org:40023 -cipher ECDSA 2> /dev/null | head -n 4 | tail -n 2 Certificate chain 0 s:/OU=SAMPLE ONLY/O=Certicom Corp./L=Toronto/ST=Ontario/CN=tls.secg.org ECC secp256r1 Server Certificate/C=CA > Thus, there is no "priority" among multiple > certificates. The "Trusted CA Indication" extension can be used by the > client to say which trust anchor they want to chain to, but that is a > signal from the client to the server. > > Even if, in the future, TLS has better facility for the server to have > multiple certs so that it might have a preference, I don't see why TLSA > would need to be in the business of expressing that preference: it should > *only* be part of TLS. That is, what would a client do if TLSA says the > preference was "A B C" but the (future) TLS server said the preference was > "C B A"? > > --Paul Hoffman > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From mrex@sap.com Thu Sep 22 08:31:46 2011 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 1180621F8880 for ; Thu, 22 Sep 2011 08:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.057 X-Spam-Level: X-Spam-Status: No, score=-10.057 tagged_above=-999 required=5 tests=[AWL=0.192, 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 eUwC9kMBz8zL for ; Thu, 22 Sep 2011 08:31:45 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 59CD421F844D for ; Thu, 22 Sep 2011 08:31:45 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p8MFY2B0016055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Sep 2011 17:34:02 +0200 (MEST) From: Martin Rex Message-Id: <201109221534.p8MFY2eg017685@fs4113.wdf.sap.corp> To: paul.hoffman@vpnc.org (Paul Hoffman) Date: Thu, 22 Sep 2011 17:34:02 +0200 (MEST) In-Reply-To: from "Paul Hoffman" at Sep 22, 11 08:16:11 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: yzw_iplab@163.com, dane@ietf.org Subject: Re: [dane] Optimize the processing of multiple TLSA RRs 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, 22 Sep 2011 15:31:46 -0000 Paul Hoffman wrote: > > > I mean the TLS server may have multiple certificates registered > > in the DNS system. > > This is at odds with the way that TLS works. Existing PKIX/X.509 supports only one subject public key per certificate, so a TLS which wants to supports a large variety of TLS cipher suites (RSA, DSA, static-DH, ECDSA, GOST 34.10-2001), there is simply no other way for the TLS server than using distinct server certificates. And the former three PK algs/certs (RSA,DSA,static-DH) are as old as SSLv3. -Martin From mrex@sap.com Thu Sep 22 09:14:19 2011 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 916C221F8BC4 for ; Thu, 22 Sep 2011 09:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.058 X-Spam-Level: X-Spam-Status: No, score=-10.058 tagged_above=-999 required=5 tests=[AWL=0.191, 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 9BkhflLNjqHG for ; Thu, 22 Sep 2011 09:14:19 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id AEE2121F8BC3 for ; Thu, 22 Sep 2011 09:14:18 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p8MGGXrP021009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Sep 2011 18:16:33 +0200 (MEST) From: Martin Rex Message-Id: <201109221616.p8MGGWpp020098@fs4113.wdf.sap.corp> To: rob.stradling@comodo.com (Rob Stradling) Date: Thu, 22 Sep 2011 18:16:32 +0200 (MEST) In-Reply-To: <201109221630.07491.rob.stradling@comodo.com> from "Rob Stradling" at Sep 22, 11 04:30:00 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: yzw_iplab@163.com, paul.hoffman@vpnc.org, dane@ietf.org Subject: Re: [dane] Optimize the processing of multiple TLSA RRs 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, 22 Sep 2011 16:14:19 -0000 Rob Stradling wrote: > > It's true that a TLS Server may only "present one EE certificate" per > handshake, but that doesn't mean it will always send the same "one EE > certificate" in every handshake with every TLS Client. Some examples... > > Client specifies certain cipher(s): Correct! > > Client specifies the SNI extension: > > $ openssl s_client -connect sni.velox.ch:443 -servername alice.sni.velox.ch > > $ openssl s_client -connect sni.velox.ch:443 -servername bob.sni.velox.ch Inappropriate example for the original discussion (DNS TLSA lookup) A DANE client ought to lookup the DNS name of the host to which it _connects_, and likewise, a DANE-aware TLS client ought to look up the TLSA record for the exact same hostname that it uses for connect(), and when that client sends SNI, it should be sending exactly that name that it used for connect() and TLSA lookup. Therefore both of your openssl s_client command lines are _not_ using SNI in the fashion that it is supposed to be used by TLS client, because both use a different name for connect() than what they send in SNI. If a TLS client is doing what you do above, then I believe that it is impossible to perform any sensible DANE TLSA lookup and matching on the resulting server certificate! -Martin From mrex@sap.com Thu Sep 22 09:41:22 2011 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 998AB21F8C72 for ; Thu, 22 Sep 2011 09:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.059 X-Spam-Level: X-Spam-Status: No, score=-10.059 tagged_above=-999 required=5 tests=[AWL=0.190, 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 hYVTtBZbJ2xT for ; Thu, 22 Sep 2011 09:41:22 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id B7F5421F8C64 for ; Thu, 22 Sep 2011 09:41:21 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p8MGhaMx023505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Sep 2011 18:43:36 +0200 (MEST) From: Martin Rex Message-Id: <201109221643.p8MGhaWi021661@fs4113.wdf.sap.corp> To: mrex@sap.com Date: Thu, 22 Sep 2011 18:43:36 +0200 (MEST) In-Reply-To: <201109221616.p8MGGWpp020098@fs4113.wdf.sap.corp> from "Martin Rex" at Sep 22, 11 06:16:32 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: yzw_iplab@163.com, paul.hoffman@vpnc.org, dane@ietf.org Subject: Re: [dane] Optimize the processing of multiple TLSA RRs 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, 22 Sep 2011 16:41:22 -0000 I'm sorry for doing to many things at the same time... Fixing up my last my last message below. Martin Rex wrote: > > Rob Stradling wrote: > > > > It's true that a TLS Server may only "present one EE certificate" per > > handshake, but that doesn't mean it will always send the same "one EE > > certificate" in every handshake with every TLS Client. Some examples... > > > > Client specifies certain cipher(s): > > Correct! > > > > > Client specifies the SNI extension: > > > > $ openssl s_client -connect sni.velox.ch:443 -servername alice.sni.velox.ch > > > > $ openssl s_client -connect sni.velox.ch:443 -servername bob.sni.velox.ch > > Inappropriate example for the original discussion (DNS TLSA lookup) A DANE-aware TLS client ought to look up the TLSA record for the exact same hostname that it uses for connect(), and when that client sends SNI, it should be sending exactly that name that it used for connect() and TLSA lookup. > Therefore both of your openssl s_client command lines are _not_ using SNI > in the fashion that it is supposed to be used by TLS client, because both > use a different name for connect() than what they send in SNI. > > If a TLS client is doing what you do above, then I believe that > it is impossible to perform any sensible DANE TLSA lookup and > matching on the resulting server certificate! > -Martin From paul@xelerance.com Thu Sep 22 11:51:18 2011 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 D31D821F8B85 for ; Thu, 22 Sep 2011 11:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.497 X-Spam-Level: X-Spam-Status: No, score=-6.497 tagged_above=-999 required=5 tests=[AWL=0.102, 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 b-6ls6n+yatx for ; Thu, 22 Sep 2011 11:51:18 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id 10C7221F8B84 for ; Thu, 22 Sep 2011 11:51:17 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id BEE27572F1; Thu, 22 Sep 2011 14:51:47 -0400 (EDT) Date: Thu, 22 Sep 2011 14:51:47 -0400 (EDT) From: Paul Wouters To: Martin Rex In-Reply-To: <201109221528.p8MFS6bE017153@fs4113.wdf.sap.corp> Message-ID: References: <201109221528.p8MFS6bE017153@fs4113.wdf.sap.corp> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dane@ietf.org Subject: Re: [dane] #33: Publish enough information for the client to 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, 22 Sep 2011 18:51:19 -0000 On Thu, 22 Sep 2011, Martin Rex wrote: > If DNSSEC ensures that an attacker can not hide only specific TLSA records > from the DANE client's view, then a client's selection by own preference > in combination with a cartesian product requirement would do the trick. There is one RRSIG over the entire TLSA RRset. That RRSIG uses one algorithm. there will always be mismatches between hash algorithm used in multiple TLS certs with different algorithms, algorithms used in the TLSA record RData, and in the RRSIG. It's up to DNS administrators and TLS administrators to pick which ones to deploy and trust. It is up to the DNS and TLS clients to pick from that published list what they trust. No new bits in the TLSA record is going to change that. Paul From hallam@gmail.com Thu Sep 22 13:24:38 2011 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 D15A411E80A2 for ; Thu, 22 Sep 2011 13:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.44 X-Spam-Level: X-Spam-Status: No, score=-3.44 tagged_above=-999 required=5 tests=[AWL=0.158, 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 MsPK+VlAhx5i for ; Thu, 22 Sep 2011 13:24:38 -0700 (PDT) Received: from mail-gw0-f42.google.com (mail-gw0-f42.google.com [74.125.83.42]) by ietfa.amsl.com (Postfix) with ESMTP id E8C3B11E8091 for ; Thu, 22 Sep 2011 13:24:37 -0700 (PDT) Received: by gwj16 with SMTP id 16so2677154gwj.15 for ; Thu, 22 Sep 2011 13:27:10 -0700 (PDT) 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=FlVL7LER6vR3QZQi0IRHhSdQeHRyux+/oEYrNt1nc4E=; b=FZygAMhEt4xWM3QgVUdwfwT1ClI/LXB5rQ+OOmxmDBGR3iAXErUmLPMZc0Ptgu/JTJ K5WEDbcZE0Jlx8Bq0hhjRQb/YsuRBSe7CQDZl60tMQIrhNhnZWhvKInT/sx5rwY/J10t yLDdqg5iBqd3OwlX/CAwSRMORv8XT4fPyM6J8= MIME-Version: 1.0 Received: by 10.100.244.3 with SMTP id r3mr2413003anh.118.1316723230051; Thu, 22 Sep 2011 13:27:10 -0700 (PDT) Received: by 10.101.71.4 with HTTP; Thu, 22 Sep 2011 13:27:10 -0700 (PDT) In-Reply-To: References: <201109221528.p8MFS6bE017153@fs4113.wdf.sap.corp> Date: Thu, 22 Sep 2011 16:27:10 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Wouters Content-Type: multipart/alternative; boundary=001636c5bee8650ee304ad8d84ea Cc: dane@ietf.org Subject: Re: [dane] #33: Publish enough information for the client to 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, 22 Sep 2011 20:24:39 -0000 --001636c5bee8650ee304ad8d84ea Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 22, 2011 at 2:51 PM, Paul Wouters wrote: > On Thu, 22 Sep 2011, Martin Rex wrote: > > If DNSSEC ensures that an attacker can not hide only specific TLSA records >> from the DANE client's view, then a client's selection by own preference >> in combination with a cartesian product requirement would do the trick. >> > > There is one RRSIG over the entire TLSA RRset. That RRSIG uses one > algorithm. there will always be mismatches between hash algorithm used > in multiple TLS certs with different algorithms, algorithms used in the > TLSA record RData, and in the RRSIG. > > It's up to DNS administrators and TLS administrators to pick which ones to > deploy and trust. It is up to the DNS and TLS clients to pick from that > published list what they trust. No new bits in the TLSA record is going to > change that. Not quite, there can be more than one RRSIG as that can be rolling as well. In fact if there is a necessary roll for DANE there will almost certainly be one for DNSSEC at the same time. There are three separate places where a digest is relevant: A) The certificate signature B) The DANE record C) The DNSSEC RRSIG(s) The certificate signature and the DANE record are both specific to TLS and it makes sense to consider those together. I can think of cases where the DNSSEC digest algorithm might fall out of sync with the choice of algorithm for TLS. The DNSSEC digest algorithm is going to be a part of a chain and may well end up being ahead or behind. It is also quite possible that the DNSSEC processing gets done somewhere else entirely. But I cannot see a case where a TLS library would be able to do SHA-X for the TLS and not for DANE or vice versa. -- Website: http://hallambaker.com/ --001636c5bee8650ee304ad8d84ea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Thu, Sep 22, 2011 at 2:51 PM, Pa= ul Wouters <paul= @xelerance.com> wrote:
On Thu, 22 Sep 2011, Martin Rex wrote:

If DNSSEC ensures that an attacker can not hide only specific TLSA records<= br> from the DANE client's view, then a client's selection by own prefe= rence
in combination with a cartesian product requirement would do the trick.

There is one RRSIG over the entire TLSA RRset. That RRSIG uses one
algorithm. =A0there will always be mismatches between hash algorithm used in multiple TLS certs with different algorithms, algorithms used in the
TLSA record RData, and in the RRSIG.

It's up to DNS administrators and TLS administrators to pick which ones= to
deploy and trust. It is up to the DNS and TLS clients to pick from that
published list what they trust. No new bits in the TLSA record is going to<= br> change that.

Not quite, there can be more t= han one RRSIG as that can be rolling as well. In fact if there is a necessa= ry roll for DANE there will almost certainly be one for DNSSEC at the same = time.


There are three separate places where a diges= t is relevant:

A) The certificate signature
B)= The DANE record
C) The DNSSEC RRSIG(s)

The certificate signature and the DANE record are both specific to TLS and = it makes sense to consider those together.=A0

I ca= n think of cases where the DNSSEC digest algorithm might fall out of sync w= ith the choice of algorithm for TLS. The DNSSEC digest algorithm is going t= o be a part of a chain and may well end up being ahead or behind. It is als= o quite possible that the DNSSEC processing gets done somewhere else entire= ly.


But I cannot see a case where a TLS libr= ary would be able to do SHA-X for the TLS and not for DANE or vice versa.
=A0

--
Website: http://hallambaker.com/

--001636c5bee8650ee304ad8d84ea-- From paul@xelerance.com Thu Sep 22 14:23:51 2011 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 6887F1F0CAE for ; Thu, 22 Sep 2011 14:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 25a0csdb-Otr for ; Thu, 22 Sep 2011 14:23:50 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id 37DD31F0CA6 for ; Thu, 22 Sep 2011 14:23:50 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 8B31B572F3; Thu, 22 Sep 2011 17:24:33 -0400 (EDT) Date: Thu, 22 Sep 2011 17:24:33 -0400 (EDT) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <201109221528.p8MFS6bE017153@fs4113.wdf.sap.corp> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Cc: dane@ietf.org Subject: Re: [dane] #33: Publish enough information for the client to 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, 22 Sep 2011 21:23:51 -0000 On Thu, 22 Sep 2011, Phillip Hallam-Baker wrote: > Not quite, there can be more than one RRSIG as that can be rolling as well. True, but then you again publish two RRSIGs and its up to the client to decide to not trust RSASHA1 or whatever. But if the situation is that bad, you have a more serious problem, as everyone in your chain upto to root might be rolling their algorithm, and you're subverted with rogue TLSA records without your nameservers ever being contacted. We put in algorithm agility to migrate before shit hits the fan. We should not remain bikeshedding over theoretical doomsday scenario of global nuclear hash failing. > In fact if there is a necessary roll for DANE there will almost > certainly be one for DNSSEC at the same time. That totally depends on how the algorithm is broken. You might simple be fine with RRSIG lifetimes of 1 day, which would protect your RSASHA1 RRSIGs from attack, but which would not prevent an X.509 signature to be broken before it expires next year. Also, preimage attacks as MIT did on the getting bogus certs signed would not work on DNSSEC, so I really hope PKIX deployments would have moved to a stronger algorithm long before there is any danger to its use in DNSSEC. > The certificate signature and the DANE record are both specific to TLS and it makes sense to consider those together.  A DNS admin can decide to use SHA256 in and on the TLSA record while the cert has a SHA1 based signature. I don't see how they neccessarilly go together at all. Paul From ahu@xs.powerdns.com Thu Sep 22 14:33:01 2011 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 9119A11E80AB for ; Thu, 22 Sep 2011 14:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.632 X-Spam-Level: X-Spam-Status: No, score=-1.632 tagged_above=-999 required=5 tests=[AWL=0.968, 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 Bb3jMVUMbBcY for ; Thu, 22 Sep 2011 14:33:01 -0700 (PDT) Received: from xs.powerdns.com (xs.powerdns.com [IPv6:2001:888:2000:1d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB301F0C84 for ; Thu, 22 Sep 2011 14:32:48 -0700 (PDT) Received: from ahu by xs.powerdns.com with local (Exim 4.71) (envelope-from ) id 1R6qvN-0002Cg-4X; Thu, 22 Sep 2011 23:35:17 +0200 Date: Thu, 22 Sep 2011 23:35:17 +0200 From: bert hubert To: Paul Wouters Message-ID: <20110922213517.GC17677@xs.powerdns.com> References: <201109221528.p8MFS6bE017153@fs4113.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: dane@ietf.org Subject: Re: [dane] #33: Publish enough information for the client to 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, 22 Sep 2011 21:33:01 -0000 On Thu, Sep 22, 2011 at 05:24:33PM -0400, Paul Wouters wrote: > >The certificate signature and the DANE record are both specific to TLS and it makes sense to consider those together.  > > A DNS admin can decide to use SHA256 in and on the TLSA record while the cert has > a SHA1 based signature. I don't see how they neccessarilly go together at all. Also, much as a government that governs least governs best, standards should not overreach. One can see arguments going both ways, in which case it is probably best to leave it up to implementors. Additionally, implementors rarely limit themselves to what a standard says they MUST do where interoperability is not at stake, so it is futile anyhow. Bert From warren@kumari.net Thu Sep 22 14:37:46 2011 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 3C92711E80B4 for ; Thu, 22 Sep 2011 14:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.467 X-Spam-Level: X-Spam-Status: No, score=-102.467 tagged_above=-999 required=5 tests=[AWL=0.132, 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 WynjrZzyEwqE for ; Thu, 22 Sep 2011 14:37:45 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id BA06011E80B3 for ; Thu, 22 Sep 2011 14:37:45 -0700 (PDT) Received: from dhcp-172-19-119-117.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 7BC621B40019; Thu, 22 Sep 2011 17:40:17 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <1316658407.1941.58.camel@localhost> Date: Thu, 22 Sep 2011 17:40:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <47252F9C-9C79-4F27-BCCF-5FAF82932CF2@kumari.net> References: <1E08D85E-3E17-4E30-BF21-6C37E8CE3052@kumari.net> <000401cc7423$bf343990$3d9cacb0$@augustcellars.com> <881C47F4-FDE0-43DC-BF7E-D85729D057AE@kumari.net> <1316658407.1941.58.camel@localhost> To: Matt McCutchen X-Mailer: Apple Mail (2.1084) Cc: DANE WG Subject: Re: [dane] Opening issues #25, #26, #27 as a group. 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, 22 Sep 2011 21:37:46 -0000 On Sep 21, 2011, at 10:26 PM, Matt McCutchen wrote: > On Wed, 2011-09-21 at 12:07 -0400, Warren Kumari wrote: >> It appears to the chairs that issues #25, #26, #27 are all variations >> on a theme and are all predicated on DANE doing [ conjunctive / >> disjunctive / grouping / sets ] -- see issue #32, Matt's proposed >> schema >> ( https://www.ietf.org/mail-archive/web/dane/current/msg02637.html ), >> etc. >=20 > No... that is only true of #27. >=20 > - #25 can alternatively be done with flags in the RRset. >=20 > - #26 is purely a policy question, orthogonal to conjunction support. >=20 > We have at least Phill's and my +1 to address #25. >=20 >> We believe that this was viewed by the WG as cool and sexy, but = adding >> too much additional complexity to the protocol (see the thread = around: >> http://www.ietf.org/mail-archive/web/dane/current/msg03351.html ). >>=20 >> Unless we hear that the WG would like to reconsider this, we are >> planning on calling these issues closed. >=20 > Does this determination stand (for #27) given my new proposal and > remarks in > http://www.ietf.org/mail-archive/web/dane/current/msg03418.html ? "Unless we hear that the WG would like to reconsider...." So, working group, would you like to reconsider this, given Matt's new = proposal and referenced remarks? Please *clearly* indicate a preference. W >=20 > --=20 > Matt >=20 From ahu@xs.powerdns.com Thu Sep 22 14:43:35 2011 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 A9A3811E80BE for ; Thu, 22 Sep 2011 14:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.955 X-Spam-Level: X-Spam-Status: No, score=-1.955 tagged_above=-999 required=5 tests=[AWL=0.645, 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 UDZDhQgv+z9T for ; Thu, 22 Sep 2011 14:43:35 -0700 (PDT) Received: from xs.powerdns.com (xs.powerdns.com [IPv6:2001:888:2000:1d::2]) by ietfa.amsl.com (Postfix) with ESMTP id DF63E11E80A6 for ; Thu, 22 Sep 2011 14:43:34 -0700 (PDT) Received: from ahu by xs.powerdns.com with local (Exim 4.71) (envelope-from ) id 1R6r5n-0002Ut-Tw; Thu, 22 Sep 2011 23:46:03 +0200 Date: Thu, 22 Sep 2011 23:46:03 +0200 From: bert hubert To: Warren Kumari Message-ID: <20110922214603.GD17677@xs.powerdns.com> References: <1E08D85E-3E17-4E30-BF21-6C37E8CE3052@kumari.net> <000401cc7423$bf343990$3d9cacb0$@augustcellars.com> <881C47F4-FDE0-43DC-BF7E-D85729D057AE@kumari.net> <1316658407.1941.58.camel@localhost> <47252F9C-9C79-4F27-BCCF-5FAF82932CF2@kumari.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47252F9C-9C79-4F27-BCCF-5FAF82932CF2@kumari.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: DANE WG Subject: Re: [dane] Opening issues #25, #26, #27 as a group. 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, 22 Sep 2011 21:43:35 -0000 On Thu, Sep 22, 2011 at 05:40:15PM -0400, Warren Kumari wrote: > >> http://www.ietf.org/mail-archive/web/dane/current/msg03351.html ). > >> Unless we hear that the WG would like to reconsider this, we are > >> planning on calling these issues closed. > > > > Does this determination stand (for #27) given my new proposal and > > remarks in > > http://www.ietf.org/mail-archive/web/dane/current/msg03418.html ? > > "Unless we hear that the WG would like to reconsider...." > > So, working group, would you like to reconsider this, given Matt's new proposal and referenced remarks? > Please *clearly* indicate a preference. I'm with Jakob & Phillip here. I also urge the WG to keep DANE as simple as possible. So keep it closed please. -- PowerDNS Website: http://www.powerdns.com/ PowerDNS Community Website: http://wiki.powerdns.com/ From ahu@xs.powerdns.com Thu Sep 22 14:49:59 2011 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 5E45011E80BD for ; Thu, 22 Sep 2011 14:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.116 X-Spam-Level: X-Spam-Status: No, score=-2.116 tagged_above=-999 required=5 tests=[AWL=0.484, 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 RoKlbHFBTHll for ; Thu, 22 Sep 2011 14:49:58 -0700 (PDT) Received: from xs.powerdns.com (xs.powerdns.com [IPv6:2001:888:2000:1d::2]) by ietfa.amsl.com (Postfix) with ESMTP id A9CF011E809D for ; Thu, 22 Sep 2011 14:49:58 -0700 (PDT) Received: from ahu by xs.powerdns.com with local (Exim 4.71) (envelope-from ) id 1R6rBy-0002eU-MD; Thu, 22 Sep 2011 23:52:26 +0200 Date: Thu, 22 Sep 2011 23:52:26 +0200 From: bert hubert To: Jim Schaad Message-ID: <20110922215226.GE17677@xs.powerdns.com> References: <056.1a974588106d5c2e6a6fd25a8a0d7236@trac.tools.ietf.org> <1D25BD4E-3D9A-4B9F-BF63-0204CE89534B@kumari.net> <337DB9C1-F674-48B9-8B65-6BD7A34C8E18@vpnc.org> <016f01cc78dd$602e89f0$208b9dd0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <016f01cc78dd$602e89f0$208b9dd0$@augustcellars.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: 'Paul Hoffman' , 'DANE WG' 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 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, 22 Sep 2011 21:49:59 -0000 On Wed, Sep 21, 2011 at 09:09:07PM -0700, Jim Schaad wrote: > While I am starting to come to the opinion that the DANE effort is truly > going to need an operations document and I might be willing to be the > author, unless you believe that an operational approach is a sufficient This makes abundant amounts of sense. When the A record was standardized, the RFC also refrained from telling folks how to subnet their networks. I suggest the DANE RFC tries to keep it simple. DNSSEC and TLS are complicated enough as they are. Also, keep in mind that even if an RFC provides normative "guidance", as long as it is not vital for interoperability, this guidance is likely to be ignored or be applied confusingly. Bert -- PowerDNS Website: http://www.powerdns.com/ PowerDNS Community Website: http://wiki.powerdns.com/ From ahu@xs.powerdns.com Thu Sep 22 14:53:12 2011 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 2FA9F11E80B9 for ; Thu, 22 Sep 2011 14:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, J_CHICKENPOX_23=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 DmfWCocV90HO for ; Thu, 22 Sep 2011 14:53:11 -0700 (PDT) Received: from xs.powerdns.com (xs.powerdns.com [IPv6:2001:888:2000:1d::2]) by ietfa.amsl.com (Postfix) with ESMTP id A27F511E80A2 for ; Thu, 22 Sep 2011 14:53:11 -0700 (PDT) Received: from ahu by xs.powerdns.com with local (Exim 4.71) (envelope-from ) id 1R6rF3-0002m3-AC; Thu, 22 Sep 2011 23:55:37 +0200 Date: Thu, 22 Sep 2011 23:55:37 +0200 From: bert hubert To: yzw_iplab Message-ID: <20110922215537.GF17677@xs.powerdns.com> References: <201109221319000027856@163.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201109221319000027856@163.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: dane Subject: Re: [dane] Optimize the processing of multiple TLSA RRs 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, 22 Sep 2011 21:53:12 -0000 On Thu, Sep 22, 2011 at 01:19:00PM +0800, yzw_iplab wrote: > Hi,all > According to the basic DANE protocol, multiple TLSA RRs may be maintained > for one name and the related processing principle is discussed in the past > several days. Although anyone of the multiple TLSA RRs can be used to Compared to the cost of DH or RSA negotiation ("a millisecond", minus round trips even), certificate validation ("few microseconds") is nearly free. The complexity added by this proposal would not be however. So I suggest leaving out this optimization. Bert -- PowerDNS Website: http://www.powerdns.com/ PowerDNS Community Website: http://wiki.powerdns.com/ From hallam@gmail.com Thu Sep 22 14:58:09 2011 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 814D911E80C2 for ; Thu, 22 Sep 2011 14:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.445 X-Spam-Level: X-Spam-Status: No, score=-3.445 tagged_above=-999 required=5 tests=[AWL=0.153, 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 hKQrDbUZ8q9a for ; Thu, 22 Sep 2011 14:58:09 -0700 (PDT) Received: from mail-gw0-f42.google.com (mail-gw0-f42.google.com [74.125.83.42]) by ietfa.amsl.com (Postfix) with ESMTP id D56A011E80AA for ; Thu, 22 Sep 2011 14:58:08 -0700 (PDT) Received: by gwj16 with SMTP id 16so2799246gwj.15 for ; Thu, 22 Sep 2011 15:00:41 -0700 (PDT) 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=5ALGpiFFWhvyDZOiOuHGhqZKcHSQIlDGlqqIjK5rZek=; b=hcnV9ar+Jc1n8MpZkqC8fNsRkBrEHbe1//ypa8sqx1+n5NCFx29y4qnAVFPkM9NeTh NaGbatZq0i9NySDxgCZmsOizwBSwGljQi76rU61FJEpwK2CBq9k2LwYluNp3jpG5N7Da LFTK3jPbFy40Z8xKp6E5rc4Ppi4fvmrL660dk= MIME-Version: 1.0 Received: by 10.100.244.3 with SMTP id r3mr2503195anh.118.1316728841261; Thu, 22 Sep 2011 15:00:41 -0700 (PDT) Received: by 10.101.71.4 with HTTP; Thu, 22 Sep 2011 15:00:41 -0700 (PDT) In-Reply-To: References: <201109221528.p8MFS6bE017153@fs4113.wdf.sap.corp> Date: Thu, 22 Sep 2011 18:00:41 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Wouters Content-Type: multipart/alternative; boundary=001636c5bee8d952b404ad8ed203 Cc: dane@ietf.org Subject: Re: [dane] #33: Publish enough information for the client to 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, 22 Sep 2011 21:58:09 -0000 --001636c5bee8d952b404ad8ed203 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 22, 2011 at 5:24 PM, Paul Wouters wrote: > > A DNS admin can decide to use SHA256 in and on the TLSA record while the > cert has > a SHA1 based signature. I don't see how they neccessarilly go together at > all. > > Paul > A Web server can have more than one cert and the client can direct the choice of cert through the algorithm selection mechanism. So the rule should be that the client is willing to use any of the digests specified in the TLS algorithm negotiation for verifying the TLSA record or the mandatory to implement digest. So if the client tells the server that it will accept a cert with SHA512 then it has to be willing to accept a SHA512 digest in the TLSA record for that cert. In other words, we do not need to bother with any digest negotiation mechanism at the DNS level because the TLS or IPSEC or whatever negotiation will be sufficient. -- Website: http://hallambaker.com/ --001636c5bee8d952b404ad8ed203 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Sep 22, 2011 at 5:24 PM, Paul Wo= uters <paul@xele= rance.com> wrote:

A DNS admin can decide to use SHA256 in and on the TLSA record while the ce= rt has
a SHA1 based signature. I don't see how they neccessarilly go together = at all.

Paul

A Web server can have more than one cert and = the client can direct the choice of cert through the algorithm selection me= chanism.

So the rule should be that the client is willin= g to use any of the digests specified in the TLS algorithm negotiation for = verifying the TLSA record or the mandatory to implement digest.


So if the client tells the server that i= t will accept a cert with SHA512 then it has to be willing to accept a SHA5= 12 digest in the TLSA record for that cert.

In other words, we do no= t need to bother with any digest negotiation mechanism at the DNS level bec= ause the TLS or IPSEC or whatever negotiation will be sufficient.

--
Website: http://hallambaker.= com/

--001636c5bee8d952b404ad8ed203-- From paul.hoffman@vpnc.org Thu Sep 22 16:14:44 2011 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 962BD21F8B31 for ; Thu, 22 Sep 2011 16:14:44 -0700 (PDT) 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 U0+dOmfLNQjT for ; Thu, 22 Sep 2011 16:14:44 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2E18321F8B2F for ; Thu, 22 Sep 2011 16:14:44 -0700 (PDT) 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 p8MNHFOR094684 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 22 Sep 2011 16:17:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1244.3) From: Paul Hoffman In-Reply-To: Date: Thu, 22 Sep 2011 16:17:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1F3597E2-3120-40BB-BDA7-F932E2370158@vpnc.org> References: <201109221528.p8MFS6bE017153@fs4113.wdf.sap.corp> To: dane WG X-Mailer: Apple Mail (2.1244.3) Subject: Re: [dane] #33: Publish enough information for the client to 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, 22 Sep 2011 23:14:44 -0000 On Sep 22, 2011, at 3:00 PM, Phillip Hallam-Baker wrote: > In other words, we do not need to bother with any digest negotiation = mechanism at the DNS level because the TLS or IPSEC or whatever = negotiation will be sufficient. +1. Good, succinct answer. --Paul Hoffman From matt@mattmccutchen.net Thu Sep 22 19:29:17 2011 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 698CF1F0C5D for ; Thu, 22 Sep 2011 19:29:17 -0700 (PDT) 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 X8llucVusXLN for ; Thu, 22 Sep 2011 19:29:16 -0700 (PDT) Received: from homiemail-a5.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 974AF1F0C43 for ; Thu, 22 Sep 2011 19:29:16 -0700 (PDT) Received: from homiemail-a5.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a5.g.dreamhost.com (Postfix) with ESMTP id 583C570406E; Thu, 22 Sep 2011 19:31:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; q=dns; s= mattmccutchen.net; b=W8UrGW8o9hUlo0wPfakL7DcwCHJnwHA707V7ROARxYL nJH7lIzZ/JUcNbwN2u9uXaHw8a1IZ3dMKOGEq+tALwCB+/41HlUlXez/fKQUzFja ShtbWanKGbUNlbORJ/0uge79g22rN+lfmH0TxMoh4vOSS3HxvsS5JFFaV7xj5llw = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; s= mattmccutchen.net; bh=KiMyKKmDIK4Cm6slInd6LSGnWxo=; b=kaZA5eJHXl m438wnnMtLt3aQHgC5cTUQwmk2yGsvPfuhNLub/RCAWRekoeNeaeth6X/Ajj1vnC n5y27qiy6e5GDWAHQTo81vL1C3MCYR4a8g77vIsUHS3Y3mauvOzHToZbhRIy2pGs nyMbqQwNbr7UZPsIVvOUn2CtUAlQTeSrU= Received: from [IPv6:::1] (ps7180.dreamhost.com [75.119.218.76]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a5.g.dreamhost.com (Postfix) with ESMTPSA id 1F162704063; Thu, 22 Sep 2011 19:31:48 -0700 (PDT) From: Matt McCutchen To: Warren Kumari Date: Thu, 22 Sep 2011 19:31:45 -0700 In-Reply-To: <47252F9C-9C79-4F27-BCCF-5FAF82932CF2@kumari.net> References: <1E08D85E-3E17-4E30-BF21-6C37E8CE3052@kumari.net> <000401cc7423$bf343990$3d9cacb0$@augustcellars.com> <881C47F4-FDE0-43DC-BF7E-D85729D057AE@kumari.net> <1316658407.1941.58.camel@localhost> <47252F9C-9C79-4F27-BCCF-5FAF82932CF2@kumari.net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 Content-Transfer-Encoding: 7bit Message-ID: <1316745107.1941.107.camel@localhost> Mime-Version: 1.0 Cc: DANE WG Subject: Re: [dane] Opening issues #25, #26, #27 as a group. 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, 23 Sep 2011 02:29:17 -0000 On Thu, 2011-09-22 at 17:40 -0400, Warren Kumari wrote: > On Sep 21, 2011, at 10:26 PM, Matt McCutchen wrote: > > On Wed, 2011-09-21 at 12:07 -0400, Warren Kumari wrote: > >> It appears to the chairs that issues #25, #26, #27 are all variations > >> on a theme and are all predicated on DANE doing [ conjunctive / > >> disjunctive / grouping / sets ] -- see issue #32, Matt's proposed > >> schema > >> ( https://www.ietf.org/mail-archive/web/dane/current/msg02637.html ), > >> etc. > > > > No... that is only true of #27. > > > > - #25 can alternatively be done with flags in the RRset. > > > > - #26 is purely a policy question, orthogonal to conjunction support. > > > > We have at least Phill's and my +1 to address #25. > > > >> We believe that this was viewed by the WG as cool and sexy, but adding > >> too much additional complexity to the protocol (see the thread around: > >> http://www.ietf.org/mail-archive/web/dane/current/msg03351.html ). > >> > >> Unless we hear that the WG would like to reconsider this, we are > >> planning on calling these issues closed. > > > > Does this determination stand (for #27) given my new proposal and > > remarks in > > http://www.ietf.org/mail-archive/web/dane/current/msg03418.html ? > > "Unless we hear that the WG would like to reconsider...." > > So, working group, would you like to reconsider this, given Matt's new proposal and referenced remarks? > Please *clearly* indicate a preference. To clarify, this call is for #27, right? Because #25 and #26 are not, as you claimed, predicated on DANE doing conjunctions. -- Matt From matt@mattmccutchen.net Thu Sep 22 21:48:10 2011 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 6113121F87E2 for ; Thu, 22 Sep 2011 21:48:10 -0700 (PDT) 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 Thqxm7SVRjw8 for ; Thu, 22 Sep 2011 21:48:09 -0700 (PDT) Received: from homiemail-a5.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 791CD21F87D9 for ; Thu, 22 Sep 2011 21:48:09 -0700 (PDT) Received: from homiemail-a5.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a5.g.dreamhost.com (Postfix) with ESMTP id 8C92C70406F; Thu, 22 Sep 2011 21:50:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; q=dns; s= mattmccutchen.net; b=nU1aD/8JLNbkWndCNJQQ/n5PPsVnKoS3hmcnODmFnBM JtvS1J17SY7AirRIOWBTuwAMvnD9jXRaojzKPeXFYcGGzX8X9RtsK0OI162U8YJk rFpdouKHpEndzc+tyP84lONVPr7Glr7lY8RMFdhCPps4T7pdenb6qZbkAUljOStI = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; s= mattmccutchen.net; bh=r53n+v9YoB6VAUzgwh3TI6zMaik=; b=djeQ89lgJ5 o04nrClABjPhBlURfWK4td3H8fgOKcGWec3iHs6jy+Joft3cr0qqgaAbbOW/VE3+ V5NDGPGxU77KfLOiD5uJ4G2UVNH3e1dfeHPTMsuWgRWM87I1gDIchW9Pw6pJsdnt 1zfaIzh0uPX/wCFgpy/QzAYRV8yyF86ow= 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-a5.g.dreamhost.com (Postfix) with ESMTPSA id 5A51870406A; Thu, 22 Sep 2011 21:50:42 -0700 (PDT) From: Matt McCutchen To: Phillip Hallam-Baker Date: Thu, 22 Sep 2011 21:50:41 -0700 In-Reply-To: References: <061.add9f922b5dfb2db7544981f78552e7e@trac.tools.ietf.org> <6EB199FD-63B2-4FEA-88ED-67DB559148A0@bbn.com> <670A864B-567A-4351-AB6D-0A373AF66B9B@kumari.net> <1316658906.1941.63.camel@localhost> <017a01cc78df$55d1e180$0175a480$@augustcellars.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 Content-Transfer-Encoding: 7bit Message-ID: <1316753441.1941.118.camel@localhost> Mime-Version: 1.0 Cc: DANE WG Subject: Re: [dane] #33: Publish enough information for the client to achieve the security of its favorite digest 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, 23 Sep 2011 04:48:10 -0000 On Thu, 2011-09-22 at 09:36 -0400, Phillip Hallam-Baker wrote: > I think that what it comes down to is that zones MUST provide a digest > value for all certs under the digest used in the certificate and > clients MUST support DANE processing for all the digests that are > supported in certs. > > In other words, what is the point of insisting on SHA-512 in the DANE > record if the cert itself is signed using SHA-256? The DANE record may designate the cert directly, in which case the signature on the cert is not used for anything. [...] > Case #6 zone has digests for some keys but not others. > > > _443._tcp.example.com TLSA 1 0 SHA-512 cert1 > _443._tcp.example.com TLSA 1 0 SHA-256 cert1 > _443._tcp.example.com TLSA 1 0 SHA-256 cert2 > > > I think that the correct approach here is to tell the deployer why it > won't work and let them hang themselves. Except that it will work, because there is no Cartesian product requirement in the spec. That's the problem. -- Matt From matt@mattmccutchen.net Thu Sep 22 22:08:06 2011 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 1781121F85F7 for ; Thu, 22 Sep 2011 22:08:06 -0700 (PDT) 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 bv6OH8Yn6ZIK for ; Thu, 22 Sep 2011 22:08:05 -0700 (PDT) Received: from homiemail-a5.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB1321F85F2 for ; Thu, 22 Sep 2011 22:08:04 -0700 (PDT) Received: from homiemail-a5.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a5.g.dreamhost.com (Postfix) with ESMTP id 6007470406F; Thu, 22 Sep 2011 22:10:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; q=dns; s= mattmccutchen.net; b=NTpZ/4MWpFDlHEGhFjqNJN7OjghSPwNkbPKiBD8amsJ C+4hTKn9HlilAzee5RSGPeeNFPbBTyOckCmDKxlTKUR0IDX/wXdTlbKmS7S/jZtQ ey/1SMjiGw4xmGJQfXVCGHmizFwvUEEMKgNxR/xMYRMCSggAsb+bknqF8GBIgj34 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; s= mattmccutchen.net; bh=PxB7N5eKd9yhhqhH19NS1G4l0W4=; b=pxuOBf1tb+ PZKOEhr6NKFpQs1LD/IZ4HjfU5fmfG5BGAc7k0GHTjuxOb6UpmU78ejd5ax7Qv4c 3jORjQnbrgE8qeDR5tcNUflLsFSX5GNclCOvs1BH4+tpKuAEYKN81FLGvybya3mX O6SmEOG/Gq4DoWrtD8K0GxM9AV4H9eKlQ= 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-a5.g.dreamhost.com (Postfix) with ESMTPSA id 3395670406E; Thu, 22 Sep 2011 22:10:38 -0700 (PDT) From: Matt McCutchen To: Paul Hoffman Date: Thu, 22 Sep 2011 22:10:36 -0700 In-Reply-To: <042EE416-702E-47DF-8748-E5AD3E6583E1@vpnc.org> References: <061.add9f922b5dfb2db7544981f78552e7e@trac.tools.ietf.org> <6EB199FD-63B2-4FEA-88ED-67DB559148A0@bbn.com> <670A864B-567A-4351-AB6D-0A373AF66B9B@kumari.net> <1316658906.1941.63.camel@localhost> <042EE416-702E-47DF-8748-E5AD3E6583E1@vpnc.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 Content-Transfer-Encoding: 7bit Message-ID: <1316754637.1941.136.camel@localhost> Mime-Version: 1.0 Cc: DANE WG Subject: Re: [dane] #33: Publish enough information for the client to achieve the security of its favorite digest 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, 23 Sep 2011 05:08:06 -0000 On Thu, 2011-09-22 at 07:55 -0700, Paul Hoffman wrote: > There is no sane way for a security protocol to fully deal with a > preimage weakening for any supported hash algorithm. If you believe > that this statement is incorrect, please point to the protocol that > does. DNSSEC with respect to SHA-256 and SHA-1 ( https://tools.ietf.org/html/rfc4509#section-3 second sentence). It is poorly explained, but DNSSEC is essentially adopting the Cartesian product requirement. It's true that a real system is likely to have some links in the chain that are by their nature incapable of a downgrade-proof negotiation (e.g., the TLS cipher suite handshake when an active attacker forces a weak cipher suite and then forges the Finished messages, or verification of X.509 certificate signatures), but that is no excuse not to do a downgrade-proof negotiation every place we can. > > If I try to choose my favorite digest, I fail against > > servers performing legitimate rollovers. > > Others have already commented on this scenario, and I agree with them. I am not sure precisely what you are agreeing with. Link? > Your unstated assumption is that we can predict which hash functions > will be considered stronger or weaker, and that is a false assumption. I make no such assumption, see below. > Typical clients will assume that all allowed hash types are secure > enough for their purposes. Atypical clients may have additional rules > for picking between different hash types, and such > picking-and-choosing is fully allowed by the protocol. But impossible to do without breaking interop with old servers. > Different atypical clients will have different additional rules, so a > domain cannot do anything about them. No, a domain can do something very basic: for each cert, group all the digests of that cert, rather than publishing a flat mishmash of digests. This does not entail the domain assuming anything about the relative strength of digest algorithms, yet it gives clients everything they need to apply their own strength preferences. Now do you get the point? -- Matt From matt@mattmccutchen.net Thu Sep 22 22:14:24 2011 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 D1D7121F8B85 for ; Thu, 22 Sep 2011 22:14:23 -0700 (PDT) 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=[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 xyS8fYvDdmwt for ; Thu, 22 Sep 2011 22:14:23 -0700 (PDT) Received: from homiemail-a1.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 5D87221F8B7A for ; Thu, 22 Sep 2011 22:14:23 -0700 (PDT) Received: from homiemail-a1.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a1.g.dreamhost.com (Postfix) with ESMTP id DFA8F34806E; Thu, 22 Sep 2011 22:16:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; q=dns; s= mattmccutchen.net; b=h3PXIQRWcBJYAyRB5WA9bPOdDvkvrwDbp/9MCH8S8sn CDbNTl4Au3bg/YcecFJrON5w+w9E8k+kDnFD2V8q3v0T5McWTV2mBCLXywNM1UOD 3RWM4NCxV5vGx8ZtK77PcnM6eVh/tf57k/Vhk4DU4Svb00y5bXr66E1YXU/jIvYg = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; s= mattmccutchen.net; bh=1kvViKgil4yOHaVUW5rXbCQof40=; b=lJFs57Y2Wd f+K/df+bRmZsAGQQieZZf4/S3AwqkGX2N5+Q2DiJWmBAbX7AdZ92iWHjY4Inrg1G xZGeae2G0EdJ/8LtvwZPOXMLvPMqBEzZ0r5igOFQrBYntjnxL8PyTp5vWAT6QvkL d2iVMXzVHrY2a0aHKh8A736s9LXH+MWQE= 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-a1.g.dreamhost.com (Postfix) with ESMTPSA id BD82934806C; Thu, 22 Sep 2011 22:16:56 -0700 (PDT) From: Matt McCutchen To: Phillip Hallam-Baker Date: Thu, 22 Sep 2011 22:16:55 -0700 In-Reply-To: References: <201109221528.p8MFS6bE017153@fs4113.wdf.sap.corp> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 Content-Transfer-Encoding: 7bit Message-ID: <1316755016.1941.141.camel@localhost> Mime-Version: 1.0 Cc: dane Subject: Re: [dane] #33: Publish enough information for the client to 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, 23 Sep 2011 05:14:24 -0000 On Thu, 2011-09-22 at 16:27 -0400, Phillip Hallam-Baker wrote: > There are three separate places where a digest is relevant: > > > A) The certificate signature > B) The DANE record > C) The DNSSEC RRSIG(s) > > > The certificate signature and the DANE record are both specific to TLS > and it makes sense to consider those together. > > I can think of cases where the DNSSEC digest algorithm might fall out > of sync with the choice of algorithm for TLS. The DNSSEC digest > algorithm is going to be a part of a chain and may well end up being > ahead or behind. It is also quite possible that the DNSSEC processing > gets done somewhere else entirely. > > But I cannot see a case where a TLS library would be able to do SHA-X > for the TLS and not for DANE or vice versa. I've got one: the client processes TLSA digests locally but delegates all PKIX path validation (for non-TLSA servers as well as TLSA usage types 0 and 2) via SCVP. I wouldn't ever assume that the digest algorithms in different parts of a system are in sync. I recall complaints about TLS 1.2 imposing this kind of requirement. -- Matt From matt@mattmccutchen.net Thu Sep 22 22:20:21 2011 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 B28EA21F8B9C for ; Thu, 22 Sep 2011 22:20:21 -0700 (PDT) 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=[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 vjkwq1pl0NBJ for ; Thu, 22 Sep 2011 22:20:21 -0700 (PDT) Received: from homiemail-a7.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 40A2721F8B95 for ; Thu, 22 Sep 2011 22:20:21 -0700 (PDT) Received: from homiemail-a7.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a7.g.dreamhost.com (Postfix) with ESMTP id 7F52825C06A; Thu, 22 Sep 2011 22:22:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; q=dns; s= mattmccutchen.net; b=FmeEx00lKcQQQc2Z19kyOkvolM3szLsqSYZ+vNnyknn UCn/Xi/qk6U4tw/hDZZfY/1iXLAe7oPMdDBHvqGapUyi0SitIImDiCB3zCOh7QDW phl519bw7hN1Y8FWc9FtDT+Mk5G9Qd3+oHvp9chGf8jC7Ub+1s/GkaWY+LvLj4o8 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; s= mattmccutchen.net; bh=7mOqLoEWIZj57/8fXbLyagMHuH0=; b=GRjubFDjcr RZofmg+gufc39CRL6C2Dyuol0PcFdRK0WgFIP94PMxpfxBWQs9MJ+8hCoJ8ukPU4 YsZ4xQH6iygOhm/tuWzhuYs+/ECImpspzCWxAkgL4LF4Do8eKJK2hw7hWAm4kjl3 HPfRWHVCfEgo9fl2NVf8R9uROY2IFKvrw= 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 51C9B25C063; Thu, 22 Sep 2011 22:22:54 -0700 (PDT) From: Matt McCutchen To: Phillip Hallam-Baker Date: Thu, 22 Sep 2011 22:22:52 -0700 In-Reply-To: References: <201109221528.p8MFS6bE017153@fs4113.wdf.sap.corp> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 Content-Transfer-Encoding: 7bit Message-ID: <1316755373.1941.143.camel@localhost> Mime-Version: 1.0 Cc: dane@ietf.org Subject: Re: [dane] #33: Publish enough information for the client to 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, 23 Sep 2011 05:20:21 -0000 On Thu, 2011-09-22 at 18:00 -0400, Phillip Hallam-Baker wrote: > So the rule should be that the client is willing to use any of the > digests specified in the TLS algorithm negotiation for verifying the > TLSA record or the mandatory to implement digest. > > So if the client tells the server that it will accept a cert with > SHA512 then it has to be willing to accept a SHA512 digest in the TLSA > record for that cert. This feels like a layering violation. In addition, it is meaningless with TLSA usage type 1, where the client doesn't use the certificate signature for anything. > In other words, we do not need to bother with any digest negotiation > mechanism at the DNS level because the TLS or IPSEC or whatever > negotiation will be sufficient. I must have missed something. How does this solve the problem I stated at https://www.ietf.org/mail-archive/web/dane/current/msg03440.html ? Or do you object to that scenario? -- Matt From matt@mattmccutchen.net Thu Sep 22 23:48:36 2011 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 C8BD921F8B7A for ; Thu, 22 Sep 2011 23:48:36 -0700 (PDT) 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=[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 bt9Vou1LOX1i for ; Thu, 22 Sep 2011 23:48:36 -0700 (PDT) Received: from homiemail-a1.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 4083721F8B1D for ; Thu, 22 Sep 2011 23:48:36 -0700 (PDT) Received: from homiemail-a1.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a1.g.dreamhost.com (Postfix) with ESMTP id C10FC34806C; Thu, 22 Sep 2011 23:51:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; q=dns; s= mattmccutchen.net; b=PRn2Ci0B4ITCdL8GwXKGPGF6EPfynNCQl4QCzTJCU0u nmdTCLW08n9HhuMYnOhKaF74gxoWg731cfyU1zyoqBsfFKBW9zwMj87rMGiQp0Sb 57ffN5aw8BNMpl5gyZaNx2+vxfFIL55p39wMQHkau6NG+miYudINiaSpo6hJ/nsg = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; s= mattmccutchen.net; bh=OQqFc/CXqJgN9ftR8TSu9A+Xy7o=; b=eDrO5HvVRg B6/z+J77oOq6KmzRxhbL4EoMf52JFJtEPVE5kyfVD78b9yjk77l4qUVRJDi+x8u1 5b/DFTcLgWxBQ5gYixLjZU7z/hhl/9lhqLVZK98J9eQlmIG3HSBWsQEPYqkNHLNC CvTKcSRckcnbDWZydPW//XzF4MWTUXwzs= 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-a1.g.dreamhost.com (Postfix) with ESMTPSA id 93BA634806B; Thu, 22 Sep 2011 23:51:08 -0700 (PDT) From: Matt McCutchen To: Zack Weinberg Date: Thu, 22 Sep 2011 23:51:07 -0700 In-Reply-To: References: <1E08D85E-3E17-4E30-BF21-6C37E8CE3052@kumari.net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 Content-Transfer-Encoding: 7bit Message-ID: <1316760668.1941.153.camel@localhost> Mime-Version: 1.0 Cc: DANE WG Subject: [dane] Client policy, #26 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, 23 Sep 2011 06:48:36 -0000 On Wed, 2011-09-14 at 14:45 -0700, Zack Weinberg wrote: > As a general observation, I think leaving anything to "client policy" > is a recipe for interoperability disaster. There should be no wiggle > room for two different clients to behave differently in response to a > given set of TLSA records plus TLS handshake. Let's be realistic: the major browsers will implement whatever they judge is best for their users, regardless of what the spec says. (And so will I in my nss-dane, for what that's worth.) IETF cannot coerce anybody. I think we can most usefully view our role as defining a "model" or "ideal" DANE client behavior, from which the deviations of any implementation can be stated and their desirability evaluated. And indeed, there should be no wiggle room in the "model" behavior. I'm not sure whether this position constitutes agreement or disagreement with you. Separately, I would like to see us make explicit the semantics of the TLSA RRset as an assertion from which any party, not just a DANE-compliant TLS client, can draw conclusions about the TLS service. -- Matt From matt@mattmccutchen.net Thu Sep 22 23:55:23 2011 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 3E65021F8B2D for ; Thu, 22 Sep 2011 23:55:23 -0700 (PDT) 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=[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 7Q2GpxU7-pyb for ; Thu, 22 Sep 2011 23:55:22 -0700 (PDT) Received: from homiemail-a5.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id ADB5221F8B2A for ; Thu, 22 Sep 2011 23:55:22 -0700 (PDT) Received: from homiemail-a5.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a5.g.dreamhost.com (Postfix) with ESMTP id 666C770407B; Thu, 22 Sep 2011 23:57:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; q=dns; s= mattmccutchen.net; b=chYVjSAOO5Y/Fk6IPRD5UkCNjA8wzLO9ATPcWnWNC12 Jn/vbZCHoDuBWOZUkCj/SwG9Mb0Lh9Hsg9bUI8Tsd78WGYWYC1mcqqDGAJBzNnRa EV1dxdoEsNFYLw1+jk62gpujbeis1qsWzItomLW2PrO76hHiyN+vFjczUjUSY4u0 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; s= mattmccutchen.net; bh=qFq3A5jTYROV00usIuQL2F5t1Aw=; b=USjouFTKBO 6ZQclN7JaNDBVtavPirUTWeGwh3B7oTuJdDfThjk1iyoJ0zOj3VTq71GjgmNvdtA bk+/6Q/E3Ro8AKNX+gO46Rc2hcL7WTVLDpOASa8ZtpFnXG4CZzAwzXF7E1P+PZW4 JJD8aifFXwp3ApShwl0cz2cFVAE10MUOA= 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-a5.g.dreamhost.com (Postfix) with ESMTPSA id 39101704076; Thu, 22 Sep 2011 23:57:56 -0700 (PDT) From: Matt McCutchen To: Paul Wouters Date: Thu, 22 Sep 2011 23:57:55 -0700 In-Reply-To: References: <201109221528.p8MFS6bE017153@fs4113.wdf.sap.corp> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 Content-Transfer-Encoding: 7bit Message-ID: <1316761075.1941.159.camel@localhost> Mime-Version: 1.0 Cc: dane@ietf.org Subject: Re: [dane] #33: Publish enough information for the client to 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, 23 Sep 2011 06:55:23 -0000 On Thu, 2011-09-22 at 14:51 -0400, Paul Wouters wrote: > It's up to DNS administrators and TLS administrators to pick which ones to > deploy and trust. It is up to the DNS and TLS clients to pick from that > published list what they trust. No new bits in the TLSA record is going to > change that. Yes, but new bits could give clients the information to make a better decision by distinguishing an odd but valid server configuration from an attack, without the bits themselves saying anything about digest strength. -- Matt From ajs@anvilwalrusden.com Fri Sep 23 09:48:38 2011 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 50AF121F8CA1 for ; Fri, 23 Sep 2011 09:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 akohe0A-mk+o for ; Fri, 23 Sep 2011 09:48:37 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id CC9F721F8CB4 for ; Fri, 23 Sep 2011 09:48:37 -0700 (PDT) Received: from shinkuro.com (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 6EF601ECB41D for ; Fri, 23 Sep 2011 16:51:07 +0000 (UTC) Date: Fri, 23 Sep 2011 12:51:09 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20110923165109.GF18154@shinkuro.com> References: <056.1a974588106d5c2e6a6fd25a8a0d7236@trac.tools.ietf.org> <1D25BD4E-3D9A-4B9F-BF63-0204CE89534B@kumari.net> <337DB9C1-F674-48B9-8B65-6BD7A34C8E18@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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 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, 23 Sep 2011 16:48:38 -0000 On Wed, Sep 21, 2011 at 08:03:09PM -0400, Phillip Hallam-Baker wrote: > So from a DANE standpoint there should probably be a requirement that there > is a digest value for all the algorithms used to sign the zone. I think it would be extremely unwise to start conflating keys that are _in_ the zone, to be used for other purposes, and the mechanism of securing the zone communication itself. There is no reason that the TLSA record's algorithms and the DNSSEC algorithms need be aligned, and I don't understand why it might be considered a good idea. A -- Andrew Sullivan ajs@anvilwalrusden.com From mrex@sap.com Fri Sep 23 11:49:55 2011 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 8049F21F8C83 for ; Fri, 23 Sep 2011 11:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.057 X-Spam-Level: X-Spam-Status: No, score=-10.057 tagged_above=-999 required=5 tests=[AWL=0.192, 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 Rki9hEU2ZDna for ; Fri, 23 Sep 2011 11:49:55 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id B127721F8C7A for ; Fri, 23 Sep 2011 11:49:54 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p8NIqR3i007411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 23 Sep 2011 20:52:27 +0200 (MEST) From: Martin Rex Message-Id: <201109231852.p8NIqRv0021233@fs4113.wdf.sap.corp> To: paul.hoffman@vpnc.org (Paul Hoffman) Date: Fri, 23 Sep 2011 20:52:27 +0200 (MEST) In-Reply-To: <1F3597E2-3120-40BB-BDA7-F932E2370158@vpnc.org> from "Paul Hoffman" at Sep 22, 11 04:17:18 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] #33: Publish enough information for the client to 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, 23 Sep 2011 18:49:55 -0000 Paul Hoffman wrote: > > Phillip Hallam-Baker wrote: > > > > In other words, we do not need to bother with any digest > > negotiation mechanism at the DNS level because the TLS or > > IPSEC or whatever negotiation will be sufficient. > > +1. Good, succinct answer. Except that it does NOT apply to TLS, because TLS has no such thing as a hash algorithm negotiation. -Martin From paul.hoffman@vpnc.org Fri Sep 23 11:57:35 2011 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 8FBCD21F8B59 for ; Fri, 23 Sep 2011 11:57:35 -0700 (PDT) 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 KGoidVC6dPQr for ; Fri, 23 Sep 2011 11:57:35 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1061521F87FC for ; Fri, 23 Sep 2011 11:57:35 -0700 (PDT) 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 p8NJ095Z065421 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 23 Sep 2011 12:00:09 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <201109231852.p8NIqRv0021233@fs4113.wdf.sap.corp> Date: Fri, 23 Sep 2011 12:00:08 -0700 Content-Transfer-Encoding: 7bit Message-Id: <5CA44319-8BA7-43D4-880B-CC8EF9D5F6E0@vpnc.org> References: <201109231852.p8NIqRv0021233@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1244.3) Cc: dane@ietf.org Subject: Re: [dane] #33: Publish enough information for the client to 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, 23 Sep 2011 18:57:35 -0000 On Sep 23, 2011, at 11:52 AM, Martin Rex wrote: > Paul Hoffman wrote: >> >> Phillip Hallam-Baker wrote: >>> >>> In other words, we do not need to bother with any digest >>> negotiation mechanism at the DNS level because the TLS or >>> IPSEC or whatever negotiation will be sufficient. >> >> +1. Good, succinct answer. > > Except that it does NOT apply to TLS, because TLS has no such > thing as a hash algorithm negotiation. The digest in the ciphersuite isn't a hash algorithm? --Paul Hoffman From hallam@gmail.com Fri Sep 23 14:00:44 2011 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 E57C621F8C72 for ; Fri, 23 Sep 2011 14:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.45 X-Spam-Level: X-Spam-Status: No, score=-3.45 tagged_above=-999 required=5 tests=[AWL=0.148, 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 sISxJm0awVFZ for ; Fri, 23 Sep 2011 14:00:44 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 03E8221F8515 for ; Fri, 23 Sep 2011 14:00:43 -0700 (PDT) Received: by gwj15 with SMTP id 15so3797452gwj.31 for ; Fri, 23 Sep 2011 14:03:19 -0700 (PDT) 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=qYgWPcvWr5j96+/Pxloz61oBxVAPNCrDkzF/6w/WH5k=; b=G1IB49ABG4nAguUInS7qd7Dlf8LEx59L8XL0P4HdykGbMycqcjFV6BtT87k743tY59 l4Lj0fnvVf17PQveu1DgDN9kHqEPivmlRleZUeVkKiA7pFax6DYflkCU8PLdrkQk3vcT SWc0NdnqYUkS2KeZ3YR3Mj74vHGnTY2lGylCs= MIME-Version: 1.0 Received: by 10.101.218.6 with SMTP id v6mr3604954anq.140.1316811798238; Fri, 23 Sep 2011 14:03:18 -0700 (PDT) Received: by 10.101.71.4 with HTTP; Fri, 23 Sep 2011 14:03:18 -0700 (PDT) In-Reply-To: <20110923165109.GF18154@shinkuro.com> References: <056.1a974588106d5c2e6a6fd25a8a0d7236@trac.tools.ietf.org> <1D25BD4E-3D9A-4B9F-BF63-0204CE89534B@kumari.net> <337DB9C1-F674-48B9-8B65-6BD7A34C8E18@vpnc.org> <20110923165109.GF18154@shinkuro.com> Date: Fri, 23 Sep 2011 17:03:18 -0400 Message-ID: From: Phillip Hallam-Baker To: Andrew Sullivan Content-Type: multipart/alternative; boundary=001636ed746478565404ada22317 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 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, 23 Sep 2011 21:00:45 -0000 --001636ed746478565404ada22317 Content-Type: text/plain; charset=ISO-8859-1 The reason I see them as being linked is that either there is a problem with the security of SHA256 or there is not. If there is a problem discovered with SHA256 it may come in a desperately bad must patch the Internet variety or be like SHA1 and be a significant cause for concern but not of the hair on fire (yet) variety. The desperately bad situation is actually the easy one to fix. We can push out patches, force upgrades. It is do-able. Its the rising cause for concern situation that is the problem. If the client is still accepting SHA256 for the DNSSEC or the TLS security scheme then we are almost certainly not in the 'hair on fire' situation. The client is proposing to use a stronger algorithm because its the right thing to do, not because SHA256 has been found unsafe. That is why I think we can and should avoid complicating DANE by trying to second guess every last possible corner case on the transition. On Fri, Sep 23, 2011 at 12:51 PM, Andrew Sullivan wrote: > On Wed, Sep 21, 2011 at 08:03:09PM -0400, Phillip Hallam-Baker wrote: > > So from a DANE standpoint there should probably be a requirement that > there > > is a digest value for all the algorithms used to sign the zone. > > I think it would be extremely unwise to start conflating keys that are > _in_ the zone, to be used for other purposes, and the mechanism of > securing the zone communication itself. There is no reason that the > TLSA record's algorithms and the DNSSEC algorithms need be aligned, > and I don't understand why it might be considered a good idea. > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > -- Website: http://hallambaker.com/ --001636ed746478565404ada22317 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The reason I see them as being linked is that either there is a problem wit= h the security of SHA256 or there is not.


If there is a problem discovered with SHA256 it may come in a desperately = bad must patch the Internet variety or be like SHA1 and be a significant ca= use for concern but not of the hair on fire (yet) variety.=A0

The desperately bad situation is actually the easy one = to fix. We can push out patches, force upgrades. It is do-able. Its the ris= ing cause for concern situation that is the problem.


If the client is still accepting SHA256 for the DNSSEC = or the TLS security scheme then we are almost certainly not in the 'hai= r on fire' situation. The client is proposing to use a stronger algorit= hm because its the right thing to do, not because SHA256 has been found uns= afe.

That is why I think we can and should avoid complicatin= g DANE by trying to second guess every last possible corner case on the tra= nsition.



On Fri= , Sep 23, 2011 at 12:51 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wr= ote:
On Wed, Sep 21, 2011 at 0= 8:03:09PM -0400, Phillip Hallam-Baker wrote:
> So from a DANE standpoint there should probably be a requirement that = there
> is a digest value for all the algorithms used to sign the zone.

I think it would be extremely unwise to start conflating keys that ar= e
_in_ the zone, to be used for other purposes, and the mechanism of
securing the zone communication itself. =A0There is no reason that the
TLSA record's algorithms and the DNSSEC algorithms need be aligned,
and I don't understand why it might be considered a good idea.

A

--
Andrew Sullivan
ajs@anvilwalrusden.com

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



--
= Website: http://hallambaker.com/
--001636ed746478565404ada22317-- From matt@mattmccutchen.net Sun Sep 25 20:26:19 2011 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 C5C1821F8508 for ; Sun, 25 Sep 2011 20:26:19 -0700 (PDT) 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=[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 O7XF93H-nKXq for ; Sun, 25 Sep 2011 20:26:18 -0700 (PDT) Received: from homiemail-a60.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id E9C3F21F84FB for ; Sun, 25 Sep 2011 20:26:18 -0700 (PDT) Received: from homiemail-a60.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a60.g.dreamhost.com (Postfix) with ESMTP id 6A4473BC06B; Sun, 25 Sep 2011 20:29:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; q=dns; s= mattmccutchen.net; b=bWQKkMtxEPR1SO90ItZBbM9We+tD3mEItjceISy+0jD eURJzSdXDxfHvYbI2hkRD8lI74POSvMH4meBhcTjWnK9BluXYoF9i3VNX6A4DJg6 SLRK+yTcfUH8pwJkkN3TXpOukvNqWSbtj7McTpA/PJkuhfoZ7HZ+t+DRdjKOWX3M = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; s= mattmccutchen.net; bh=uZ7mZto4R2TSam6VXECVQHf5qUc=; b=k4kOqspYWe RkwDLh0r+r9iH+4fUVXMBOAahdOPnYRgEaTua/MUxfAM3a8NVo5ws1Q5AGbh47Co 5mjaPL4Lk1otZuCLb1/MTX0tgdFl3w3H3pY/7FfVlWsta/tnGC9xNGm4U085tYVm sW5oeMn5/mczGRIajE/u7yQQR/Yov+Hpo= 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-a60.g.dreamhost.com (Postfix) with ESMTPSA id 4602F3BC06A; Sun, 25 Sep 2011 20:29:00 -0700 (PDT) From: Matt McCutchen To: John Gilmore Date: Sun, 25 Sep 2011 20:28:59 -0700 In-Reply-To: <201109260127.p8Q1RiQs002055@new.toad.com> References: <201109260127.p8Q1RiQs002055@new.toad.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 Content-Transfer-Encoding: 7bit Message-ID: <1317007740.1982.9.camel@localhost> Mime-Version: 1.0 Cc: DANE WG Subject: Re: [dane] #33: Publish enough information for the client to achieve the security of its favorite digest 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, 26 Sep 2011 03:26:19 -0000 On Sun, 2011-09-25 at 18:27 -0700, John Gilmore wrote: > > No, a domain can do something very basic: for each cert, group all the > > digests of that cert, rather than publishing a flat mishmash of digests. > > This does not entail the domain assuming anything about the relative > > strength of digest algorithms, yet it gives clients everything they need > > to apply their own strength preferences. Now do you get the point? > > It's not clear to me what you mean by "group all the digests of that > cert". Group them how? In the TLSA RRSET published by the domain > owner? Yes, see https://trac.tools.ietf.org/wg/dane/trac/ticket/22#comment:1 solutions 1 and 3. Examples: 1. Each RR represents one cert and contains all the digests of that cert: _443._tcp.example.com TLSA 1 1 SHA-256 xxx SHA-512 yyy _443._tcp.example.com TLSA 1 1 SHA-512 uuu SHA-3 www 3. Each cert has an ID number assigned by the admin, which serves to cross-reference all RRs of that cert (which MUST have the same usage and selector): _443._tcp.example.com TLSA 0 1 1 SHA-256 xxx _443._tcp.example.com TLSA 0 1 1 SHA-512 yyy _443._tcp.example.com TLSA 1 1 1 SHA-512 uuu _443._tcp.example.com TLSA 1 1 1 SHA-3 www -- Matt From matt@mattmccutchen.net Sun Sep 25 21:04:45 2011 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 EDCF721F84D2 for ; Sun, 25 Sep 2011 21:04:44 -0700 (PDT) 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 2TUr5X+7MBJk for ; Sun, 25 Sep 2011 21:04:44 -0700 (PDT) Received: from homiemail-a4.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 27F5721F84D1 for ; Sun, 25 Sep 2011 21:04:44 -0700 (PDT) Received: from homiemail-a4.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a4.g.dreamhost.com (Postfix) with ESMTP id B5FF451C069 for ; Sun, 25 Sep 2011 21:07:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:date:references:content-type:content-transfer-encoding :message-id:mime-version; q=dns; s=mattmccutchen.net; b=qtzYXd6F y1yw+R+8nWAS/z8nIA6Jz9ey25Ml6HFv+ph60BqEfC3itGAMqPUck9cCQVlwKNHI GZ+VH44GIFWugY9no66POmlBIR/F7BAU7v4qKgPkXvZKdVQqS/MjzyjOeoXfoDUS Xc2Dk3sR5RiffiqGEtFpkBZ4FGfTp2DiobY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:date:references:content-type :content-transfer-encoding:message-id:mime-version; s= mattmccutchen.net; bh=8DGdmfXPnvtDAFMDjCFVEyG884c=; b=MviXr2ESDQ cVVO6iOWAusZDCj3vb11Ss2fOFkiaMWbhIBkGATgaOGIjbTnHkRuxVCzZI0uTZr8 087UwYRhVs5bSWSkYFYfHdP9tMDQOcRTl5MLmd/u99jDzvwQyLl5FoknFqHZTMZQ rHkgeggZcx45k7LQXDlTTsqcc+nYVJz98= 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-a4.g.dreamhost.com (Postfix) with ESMTPSA id 9BE7851C063 for ; Sun, 25 Sep 2011 21:07:25 -0700 (PDT) From: Matt McCutchen To: DANE WG Date: Sun, 25 Sep 2011 21:07:25 -0700 References: <201109260127.p8Q1RiQs002055@new.toad.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 Content-Transfer-Encoding: 7bit Message-ID: <1317010045.1982.35.camel@localhost> Mime-Version: 1.0 Subject: Re: [dane] #33: Publish enough information for the client to achieve the security of its favorite digest 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, 26 Sep 2011 04:04:45 -0000 On Sun, 2011-09-25 at 20:28 -0700, Matt McCutchen wrote: > 1. Each RR represents one cert and contains all the digests of that > cert: > > _443._tcp.example.com TLSA 1 1 SHA-256 xxx SHA-512 yyy > _443._tcp.example.com TLSA 1 1 SHA-512 uuu SHA-3 www > > 3. Each cert has an ID number assigned by the admin, which serves to > cross-reference all RRs of that cert (which MUST have the same usage and > selector): > > _443._tcp.example.com TLSA 0 1 1 SHA-256 xxx > _443._tcp.example.com TLSA 0 1 1 SHA-512 yyy > _443._tcp.example.com TLSA 1 1 1 SHA-512 uuu > _443._tcp.example.com TLSA 1 1 1 SHA-3 www I wanted to make sure everyone is clear on how I envision a general-purpose TLS client using this information. This is optional behavior, out of scope of the spec; Paul Hoffman's client is welcome not to do it. Here is the procedure for method 1; the analogue for method 3 should be clear. def DANE_Check(rrset, cert): for rr in rrset: A = strongest (per client preferences) digest algorithm in rr H = digest value for A in rr if A(cert) == H: return true return false To illustrate that this achieves complete algorithm agility, consider two clients: (a) Supports A1 and A2, and believes that A2 is stronger than A1 (b) Supports only algorithm A1 And three servers: (i) _443._tcp.example.com TLSA 1 1 A1 xxx A2 yyy Presented cert satisfies A1(cert) == xxx and A2(cert) == yyy. - (a) checks A2(cert) == yyy, success (with the security of A2) - (b) checks A1(cert) == xxx, success (ii) _443._tcp.example.com TLSA 1 1 A1 sss _443._tcp.example.com TLSA 1 1 A2 ttt Presented cert satisfies A1(cert) == sss. - (a) checks A1(cert) == sss, success - (b) checks A1(cert) == sss, success (iii) _443._tcp.example.com TLSA 1 1 A1 sss Presented cert satisfies A1(cert) == sss. - (a) checks A1(cert) == sss, success - (b) checks A1(cert) == sss, success Interoperability is maintained in all cases, and from the client's perspective, the authentication is at least as strong as the strongest algorithm fully supported by both sides. -- Matt From matt@mattmccutchen.net Sun Sep 25 23:58:20 2011 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 EC82C21F889A for ; Sun, 25 Sep 2011 23:58:20 -0700 (PDT) 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=[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 1PLhz6W5EkaY for ; Sun, 25 Sep 2011 23:58:20 -0700 (PDT) Received: from homiemail-a6.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 6C35421F888A for ; Sun, 25 Sep 2011 23:58:20 -0700 (PDT) Received: from homiemail-a6.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTP id 3AA24598077; Mon, 26 Sep 2011 00:01:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=cCsBIOKCh6nesgGSB/6VY5D+YY5Y9f2OCYYlTXOoF1s Rcd/rUTbq5hAKqEcCthbkv7YOKp1c2f/F+eOnJFMfF0YncxhBYUrOBY48ztFbCxP J6ugupPpf+CPstnaBlyQorvleYxp+OuuVdz9+asqK0IB9vUIANSQ7G/NHxQqreTc = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=LK2zaZJyki2qCkyq7IbwEcmYTbY=; b=PWTpurXYSl OflC+Tx4wXN5+NuKXfJc8LxXkBhSqw8NzA/lbUbL+wufLugbwZI6oQifQ91RSnBC YCzXPLZYqXM9ra7wz1Qq8kTv8Cji20yMysq/GDJFowkK96qTYDNrj3fQC1IueBHK Gz0HRdmhofraCxZgqcvqqHTUFF+uZDYwY= 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 D5454598069; Mon, 26 Sep 2011 00:01:01 -0700 (PDT) From: Matt McCutchen To: Paul Hoffman In-Reply-To: <1F3597E2-3120-40BB-BDA7-F932E2370158@vpnc.org> References: <201109221528.p8MFS6bE017153@fs4113.wdf.sap.corp> <1F3597E2-3120-40BB-BDA7-F932E2370158@vpnc.org> Content-Type: text/plain; charset="UTF-8" Date: Mon, 26 Sep 2011 00:00:55 -0700 Message-ID: <1317020455.1982.74.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 3.0.3 Content-Transfer-Encoding: 7bit Cc: DANE WG Subject: Re: [dane] #33: Publish enough information for the client to 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, 26 Sep 2011 06:58:21 -0000 On Thu, 2011-09-22 at 16:17 -0700, Paul Hoffman wrote: > On Sep 22, 2011, at 3:00 PM, Phillip Hallam-Baker wrote: > > > In other words, we do not need to bother with any digest negotiation mechanism at the DNS level because the TLS or IPSEC or whatever negotiation will be sufficient. > > +1. Good, succinct answer. Did you understand what you were agreeing with or did you just look for any statement that sounded good and appeared to be in opposition to me? Since the TLS cipher suite negotiation is authenticated by the server certificate itself, it cannot provide any defense against replacement of the certificate. A MITM will just present the lookalike cert and claim to support only the algorithm for which the cert is a second preimage, forcing that algorithm to be negotiated. I cannot speak for IPsec, but we are currently targeting TLS anyway. I know the TLS cipher suite negotiation as currently designed has inherent weaknesses that make the DANE issue less relevant, but that's no excuse not to get the DANE negotiation right, since I hope to use the same approach to go back and fix TLS. (I know you don't buy that there will ever come a time when a digest algorithm is weak but not broken; I am pursuing this argument for the sake of those in the WG who do and thus would be interested in a proposal that helps with that scenario.) -- Matt From peter@denic.de Mon Sep 26 01:43:12 2011 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 D5F4521F86FF for ; Mon, 26 Sep 2011 01:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 sS625Q6JA1k7 for ; Mon, 26 Sep 2011 01:43:12 -0700 (PDT) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::4]) by ietfa.amsl.com (Postfix) with ESMTP id 965D921F869E for ; Mon, 26 Sep 2011 01:43:12 -0700 (PDT) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1R86p0-0002bG-EC; Mon, 26 Sep 2011 10:45:54 +0200 Received: from localhost by x27.adm.denic.de with local id 1R86p0-0001iR-AZ; Mon, 26 Sep 2011 10:45:54 +0200 Date: Mon, 26 Sep 2011 10:45:54 +0200 From: Peter Koch To: IETF DANE WG Message-ID: <20110926084554.GC3290@x27.adm.denic.de> Mail-Followup-To: IETF DANE WG Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: Re: [dane] Reopening issue #22 for discussion.... 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, 26 Sep 2011 08:43:12 -0000 On Thu, Sep 15, 2011 at 01:23:25PM -0700, Paul Hoffman wrote: > Current wording in the spec: > DNS systems conforming to this specification MUST be able to create > TLSA records using matching type 0 (no hash used) and matching type 1 > (SHA-256), and SHOULD be able to create TLSA records using matching > type 2 (SHA-512). this text is misleading. The draft doesn't say what it considers a "DNS system", but to avoid ambiguity it should be clarified that there's no "conformance" issue for the DNS name server but rather what one had in mind here is some provisioning entity that will (be used to) feed data into the DNS zone. The RRSet content, signed or unsigned, is transparent to the name server as per RFC 3597. -Peter From paul.hoffman@vpnc.org Mon Sep 26 06:44:39 2011 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 3241A21F8C82 for ; Mon, 26 Sep 2011 06:44:39 -0700 (PDT) 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 vMwLdjkJxQkF for ; Mon, 26 Sep 2011 06:44:38 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id A80D721F8C80 for ; Mon, 26 Sep 2011 06:44:38 -0700 (PDT) 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 p8QDlKwr009290 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 26 Sep 2011 06:47:21 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <1317020455.1982.74.camel@localhost> Date: Mon, 26 Sep 2011 06:47:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201109221528.p8MFS6bE017153@fs4113.wdf.sap.corp> <1F3597E2-3120-40BB-BDA7-F932E2370158@vpnc.org> <1317020455.1982.74.camel@localhost> To: Matt McCutchen X-Mailer: Apple Mail (2.1244.3) Cc: DANE WG Subject: Re: [dane] #33: Publish enough information for the client to 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, 26 Sep 2011 13:44:39 -0000 On Sep 26, 2011, at 12:00 AM, Matt McCutchen wrote: > On Thu, 2011-09-22 at 16:17 -0700, Paul Hoffman wrote: >> On Sep 22, 2011, at 3:00 PM, Phillip Hallam-Baker wrote: >>=20 >>> In other words, we do not need to bother with any digest negotiation = mechanism at the DNS level because the TLS or IPSEC or whatever = negotiation will be sufficient. >>=20 >> +1. Good, succinct answer. >=20 > Did you understand what you were agreeing with or did you just look = for > any statement that sounded good and appeared to be in opposition to = me? Yes; no. > (I know you don't buy that there will ever come a time when a digest > algorithm is weak but not broken; Please don't put words in my mouth, particularly ones that are false; it = is exceedingly rude. I never said that. What I said was that if there is = a weakening in the preimage resistance of one of the hashes we use, (a) = it will likely happen slowly enough that everyone will stop using that = algorithm anywhere before the attack is useful and (b) if it happens = quickly, TLS authentication will be much, much less valuable than other = attacks for which there will be wide publicity. > I am pursuing this argument for the > sake of those in the WG who do and thus would be interested in a > proposal that helps with that scenario.) Fully understand. I do not object to you pursuing the topic, and I hope = I do not lie about what you say when you do. If there is rough consensus = in the WG that the complexity and fragility of the solution is justified = by the problem, you have at least proposed a solution. --Paul Hoffman From paul.hoffman@vpnc.org Mon Sep 26 06:48:05 2011 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 AAE5021F8B5B for ; Mon, 26 Sep 2011 06:48:05 -0700 (PDT) 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 D1CyD6M41Flw for ; Mon, 26 Sep 2011 06:48:05 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 33A1621F8B8D for ; Mon, 26 Sep 2011 06:48:05 -0700 (PDT) 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 p8QDok6m011004 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 26 Sep 2011 06:50:47 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20110926084554.GC3290@x27.adm.denic.de> Date: Mon, 26 Sep 2011 06:50:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <89D7BED4-1FE2-4A39-B5C8-C8CB2E0D59AA@vpnc.org> References: <20110926084554.GC3290@x27.adm.denic.de> To: Peter Koch X-Mailer: Apple Mail (2.1244.3) Cc: IETF DANE WG Subject: Re: [dane] Reopening issue #22 for discussion.... 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, 26 Sep 2011 13:48:05 -0000 On Sep 26, 2011, at 1:45 AM, Peter Koch wrote: > On Thu, Sep 15, 2011 at 01:23:25PM -0700, Paul Hoffman wrote: >=20 >> Current wording in the spec: >> DNS systems conforming to this specification MUST be able to create >> TLSA records using matching type 0 (no hash used) and matching type = 1 >> (SHA-256), and SHOULD be able to create TLSA records using matching >> type 2 (SHA-512). >=20 > this text is misleading. The draft doesn't say what it considers a = "DNS system", Good point. > but to avoid ambiguity it should be clarified that there's no = "conformance" > issue for the DNS name server but rather what one had in mind here is > some provisioning entity that will (be used to) feed data into the DNS = zone. Correct: that's is the entity where the conformance requirement applies. > The RRSet content, signed or unsigned, is transparent to the name = server as > per RFC 3597. Yep. Does "A system creating TLSA records that conforms to ... " work? Is = there some clearer wording we can use? --Paul Hoffman From matt@mattmccutchen.net Mon Sep 26 13:40:41 2011 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 A53381F0CFD for ; Mon, 26 Sep 2011 13:40:41 -0700 (PDT) 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=[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 gqgQTD2ggisC for ; Mon, 26 Sep 2011 13:40:41 -0700 (PDT) Received: from homiemail-a6.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA641F0CFC for ; Mon, 26 Sep 2011 13:40:40 -0700 (PDT) Received: from homiemail-a6.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTP id 3A15B598077; Mon, 26 Sep 2011 13:43:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; q=dns; s= mattmccutchen.net; b=H9Y7H8Ezc1D1Gru+Es6Y0agzFlBl19Zhy4rKHyY71Bo UWN0eg/AgwBR6C8VisAZ6QX5jo6EdLL3xLzv0WZBsL0oDMtRgOAXPH6V9pDhxKWW Yq5CLPCVvXBZuN16rqtw/Wc9i76UwmrOqdrAg5rbrJlC2nSp1drKSUqmwLQIP0U0 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; s= mattmccutchen.net; bh=sKxRxY83r/Y4++lSb8HeLVuaqvI=; b=jau0D+4eY3 Y+MKDOL6KaVHLBCqK8ayeheks/5bGhs4iP2c9UW3R178Vh+PBr5BRu7zJ+wtUido dLZQPGK10VeFTHIVkZaYdGFmi5Cti6FHCk9J4Y2jCqeycSp5NKNaOgvqkU7AK0/p TbolB4k/VOCUJbX2k9NtNjb7JusUriam0= Received: from [IPv6:::1] (ps7180.dreamhost.com [75.119.218.76]) (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 D4C14598084; Mon, 26 Sep 2011 13:43:23 -0700 (PDT) From: Matt McCutchen To: Paul Hoffman Date: Mon, 26 Sep 2011 13:43:22 -0700 In-Reply-To: References: <201109221528.p8MFS6bE017153@fs4113.wdf.sap.corp> <1F3597E2-3120-40BB-BDA7-F932E2370158@vpnc.org> <1317020455.1982.74.camel@localhost> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 Content-Transfer-Encoding: 7bit Message-ID: <1317069804.1998.15.camel@localhost> Mime-Version: 1.0 Cc: DANE WG Subject: Re: [dane] #33: Publish enough information for the client to 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, 26 Sep 2011 20:40:41 -0000 On Mon, 2011-09-26 at 06:47 -0700, Paul Hoffman wrote: > > (I know you don't buy that there will ever come a time when a digest > > algorithm is weak but not broken; > > Please don't put words in my mouth, particularly ones that are false; > it is exceedingly rude. I never said that. What I said was that if > there is a weakening in the preimage resistance of one of the hashes > we use, (a) it will likely happen slowly enough that everyone will > stop using that algorithm anywhere before the attack is useful and (b) > if it happens quickly, TLS authentication will be much, much less > valuable than other attacks for which there will be wide publicity. I was mistaken about your position. Thanks for the clarification. We have no precedent to suggest what the aftermath of a second preimage weakening might look like, but experience on all other issues suggests that some percentage of servers won't upgrade until a cattle prod is put to the sysadmins. For instance, lots of servers including my university's student information portal are still vulnerable to the TLS renegotiation attack. Hence my interest. -- Matt From internet-drafts@ietf.org Tue Sep 27 08:02:53 2011 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 0925721F8ABC; Tue, 27 Sep 2011 08:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 LKT6ae6TQe3F; Tue, 27 Sep 2011 08:02:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8324E21F8CCD; Tue, 27 Sep 2011 08:02:52 -0700 (PDT) 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.60 Message-ID: <20110927150252.8501.52446.idtracker@ietfa.amsl.com> Date: Tue, 27 Sep 2011 08:02:52 -0700 Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-protocol-12.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, 27 Sep 2011 15:02:53 -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-12.txt Pages : 19 Date : 2011-09-27 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-12.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-12.txt From paul.hoffman@vpnc.org Tue Sep 27 08:05:29 2011 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 5625F21F8E4B for ; Tue, 27 Sep 2011 08:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 on050ZfphHCV for ; Tue, 27 Sep 2011 08:05:29 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id D6AAF21F8E49 for ; Tue, 27 Sep 2011 08:05:28 -0700 (PDT) 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 p8RF8Dce049256 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 27 Sep 2011 08:08:14 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Sep 2011 08:08:14 -0700 Message-Id: To: IETF DANE WG Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) Subject: [dane] Draft -12 submitted 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, 27 Sep 2011 15:05:29 -0000 ...to deal with the recently-closed issues. Diff at = . We = expect more changes to come soon as more issues are closed and we get = closer to WG Last Call. --Paul Hoffman From trac+dane@trac.tools.ietf.org Tue Sep 27 08:07:31 2011 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 F346621F8D5C for ; Tue, 27 Sep 2011 08:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, J_CHICKENPOX_66=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 ajMl20PG7OUC for ; Tue, 27 Sep 2011 08:07:30 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 0B25221F8D5A for ; Tue, 27 Sep 2011 08:07:29 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1R8ZIP-0001h6-HR; Tue, 27 Sep 2011 11:10:09 -0400 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, paul.hoffman@vpnc.org X-Trac-Project: dane Date: Tue, 27 Sep 2011 15:10:09 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/36 Message-ID: <060.8aca11012e6c9583642ba071c54be972@trac.tools.ietf.org> X-Trac-Ticket-ID: 36 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dane-protocol@tools.ietf.org, paul.hoffman@vpnc.org, 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: <20110927150730.0B25221F8D5A@ietfa.amsl.com> Resent-Date: Tue, 27 Sep 2011 08:07:29 -0700 (PDT) Resent-From: trac+dane@trac.tools.ietf.org Cc: dane@ietf.org Subject: [dane] #36: Only requiring DNSSEC where it is needed 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: Tue, 27 Sep 2011 15:07:31 -0000 #36: Only requiring DNSSEC where it is needed #choose ticket.new #when True Recent articles that talk about DANE have talked about the need for DNSSEC to be ubiquitous all the way to the client before DANE can be adopted. However, as we discussed during the use cases discussion, DNSSEC is only needed when normal PKIX validation is not being performed. Jakob and I propose that the WG consider changing the need for DNSSEC in the TLSA protocol by saying that it is (currently) only required for certificate usage 2. This change would entail: - more precise wording about DNSSEC in section 1 - an explicit "MUST be protected by DNSSEC" for type 2 in 2.1.1 - an explicit "MUST be protected by DNSSEC" for type 2 in 4.3 - new wording in 4.4 about DNSSEC that points to the new text in the Security Considerations section - new text in the IANA Considerations in 7.2 that says that every new certificate type needs to say whether or not DNSSEC is required for that type - a new subsection in the Security Considerations in 8 that describes why DNSSEC is not needed for 0 and 1, and why it is needed for 2; this will be fairly detailed With such a change, we might see much earlier adoption of TLSA for certificate types 0 and 1 than we would have otherwise. This earlier adoption might lead to much faster adoption of type 2 when DNSSEC to the client is in place. On the other hand, earlier adoption of types 0 and 1 might delay the perceived need for type 2; however, we expect the fervor for type 2 to be strong regardless of deployment of type 0 and 1. #end #otherwise #if changes_body Changes (by ): #end #if changes_descr #if not changes_body and not change.comment and change.author Description changed by : #end -- #end #if change.comment Comment(by undefined): #end #end #end -- ----------------------------+---------------------------------------- Reporter: paul.hoffman@… | Owner: draft-ietf-dane-protocol@… Type: defect | Status: new Priority: major | Milestone: Component: protocol | Version: Severity: - | Keywords: ----------------------------+---------------------------------------- Ticket URL: dane From mrex@sap.com Tue Sep 27 15:20:48 2011 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 15C2D21F9073 for ; Tue, 27 Sep 2011 15:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.059 X-Spam-Level: X-Spam-Status: No, score=-10.059 tagged_above=-999 required=5 tests=[AWL=0.190, 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 6Gw02udJy7Rd for ; Tue, 27 Sep 2011 15:20:47 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 51F9621F9071 for ; Tue, 27 Sep 2011 15:20:47 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p8RMNQSW007724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 28 Sep 2011 00:23:31 +0200 (MEST) From: Martin Rex Message-Id: <201109272223.p8RMNPpA026467@fs4113.wdf.sap.corp> To: paul.hoffman@vpnc.org Date: Wed, 28 Sep 2011 00:23:25 +0200 (MEST) In-Reply-To: <060.8aca11012e6c9583642ba071c54be972@trac.tools.ietf.org> from "dane issue tracker" at Sep 27, 11 03:10:09 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] #36: Only requiring DNSSEC where it is needed 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, 27 Sep 2011 22:20:48 -0000 dane issue tracker wrote: > > #36: Only requiring DNSSEC where it is needed > > Recent articles that talk about DANE have talked about the > need for DNSSEC to be ubiquitous all the way to the client > before DANE can be adopted. However, as we discussed during > the use cases discussion, DNSSEC is only needed when > normal PKIX validation is not being performed. That looks like a serious security problem to me. The real benefit from confirmation of a PKIX-originating TLS Server certificate through DANE comes from enabling the DNS admin to to securely repudiate a server certificate for his domain. If DNSSEC protection is obviated, then an attacker could not only block the DANE repudiation, but even insert a false confirmation for a fraudulently issued cert and create a false sense of security. Neither coerced CAs (e.g. government agencies) nor CAs that have lost track about certs they issued (DigiNotar for the *.google.com cert) are going to quickly revoke such certs on their own -- and only clients that are attacked would see them, there is no means for the domain admin to find out about those certs. And even then, PKIX-based revocation is not a reliable mechanism. I feel very uncomfortable with the proposal to make DANE optional for PKIX-validated certs. -Martin From mrex@sap.com Tue Sep 27 15:50:45 2011 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 C71CF21F8D27 for ; Tue, 27 Sep 2011 15:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.06 X-Spam-Level: X-Spam-Status: No, score=-10.06 tagged_above=-999 required=5 tests=[AWL=0.189, 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 XREFYimcDuRS for ; Tue, 27 Sep 2011 15:50:45 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 1656721F8D26 for ; Tue, 27 Sep 2011 15:50:44 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p8RMrPmA009781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 28 Sep 2011 00:53:30 +0200 (MEST) From: Martin Rex Message-Id: <201109272253.p8RMrPuF028176@fs4113.wdf.sap.corp> To: mrex@sap.com Date: Wed, 28 Sep 2011 00:53:25 +0200 (MEST) In-Reply-To: <201109272223.p8RMNPpA026467@fs4113.wdf.sap.corp> from "Martin Rex" at Sep 28, 11 00:23:25 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] #36: Only requiring DNSSEC where it is needed 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, 27 Sep 2011 22:50:45 -0000 Sorry, typo (fixed below) Martin Rex wrote: > > dane issue tracker wrote: > > > > #36: Only requiring DNSSEC where it is needed > > > > Recent articles that talk about DANE have talked about the > > need for DNSSEC to be ubiquitous all the way to the client > > before DANE can be adopted. However, as we discussed during > > the use cases discussion, DNSSEC is only needed when > > normal PKIX validation is not being performed. > > That looks like a serious security problem to me. > > The real benefit from confirmation of a PKIX-originating TLS Server > certificate through DANE comes from enabling the DNS admin to > to securely repudiate a server certificate for his domain. > > If DNSSEC protection is obviated, then an attacker could not only > block the DANE repudiation, but even insert a false confirmation > for a fraudulently issued cert and create a false sense of security. > > Neither coerced CAs (e.g. government agencies) nor CAs that have lost > track about certs they issued (DigiNotar for the *.google.com cert) > are going to quickly revoke such certs on their own -- and only clients > that are attacked would see them, there is no means for the domain > admin to find out about those certs. And even then, PKIX-based > revocation is not a reliable mechanism. > - I feel very uncomfortable with the proposal to make DANE optional for - PKIX-validated certs. + I feel very uncomfortable with the proposal to make DNSSEC optional + in DANE for PKIX-validated certs. -Martin From paul.hoffman@vpnc.org Tue Sep 27 17:14:56 2011 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 BB72821F8FB3 for ; Tue, 27 Sep 2011 17:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 31JMcT356Ptg for ; Tue, 27 Sep 2011 17:14:56 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3513221F8FAC for ; Tue, 27 Sep 2011 17:14:56 -0700 (PDT) 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 p8S0Hfj4072003 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 27 Sep 2011 17:17:42 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <201109272223.p8RMNPpA026467@fs4113.wdf.sap.corp> Date: Tue, 27 Sep 2011 17:17:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201109272223.p8RMNPpA026467@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1244.3) Cc: dane@ietf.org Subject: Re: [dane] #36: Only requiring DNSSEC where it is needed 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, 28 Sep 2011 00:14:56 -0000 On Sep 27, 2011, at 3:23 PM, Martin Rex wrote: > dane issue tracker wrote: >>=20 >> #36: Only requiring DNSSEC where it is needed >>=20 >> Recent articles that talk about DANE have talked about the >> need for DNSSEC to be ubiquitous all the way to the client >> before DANE can be adopted. However, as we discussed during >> the use cases discussion, DNSSEC is only needed when >> normal PKIX validation is not being performed. >=20 > That looks like a serious security problem to me. Where, specifically? If we missed something in our proposal, we are = happy to nuke it. > The real benefit from confirmation of a PKIX-originating TLS Server > certificate through DANE comes from enabling the DNS admin to > to securely repudiate a server certificate for his domain. Certificate type 2 is *one* "real benefit", but many of us think it is = not the only one. Or are you proposing that we get rid of types 0 and 1 = because they have no real benefit? (If so, you should open a different = issue in the tracker...) > If DNSSEC protection is obviated, then an attacker could not only > block the DANE repudiation, but even insert a false confirmation > for a fraudulently issued cert and create a false sense of security. No, he can't. The attack you describe only applies to type 2 certs, = which still need to be covered by DNSSEC in our proposal. > Neither coerced CAs (e.g. government agencies) nor CAs that have lost > track about certs they issued (DigiNotar for the *.google.com cert) > are going to quickly revoke such certs on their own -- and only = clients > that are attacked would see them, there is no means for the domain > admin to find out about those certs. And even then, PKIX-based > revocation is not a reliable mechanism. Fully agree. If that is your concern, using type 0 and type 1 certs will = gain you nothing (but not expose you to anything new). > I feel very uncomfortable with the proposal to make DANE optional for > PKIX-validated certs.=20 Understood. Going back to your "false sense of security": would your = concern be dealt with if we added wording saying "if a type 0 or 1 cert = is received without DNSSEC, the application MUST NOT make any UI or log = assertion that the certificate is more trusted than it would normally = have been from TLS"? --Paul Hoffman From rbarnes@bbn.com Tue Sep 27 18:57:53 2011 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 70F0521F8B7E for ; Tue, 27 Sep 2011 18:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.592 X-Spam-Level: X-Spam-Status: No, score=-106.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 FnTu75dn+X17 for ; Tue, 27 Sep 2011 18:57:53 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 0342F21F8B7D for ; Tue, 27 Sep 2011 18:57:53 -0700 (PDT) Received: from [128.89.253.171] (port=64337 helo=[192.168.1.4]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1R8jRp-0002or-Aa; Tue, 27 Sep 2011 22:00:33 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Tue, 27 Sep 2011 22:00:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201109272223.p8RMNPpA026467@fs4113.wdf.sap.corp> To: Paul Hoffman X-Mailer: Apple Mail (2.1084) Cc: dane@ietf.org Subject: Re: [dane] #36: Only requiring DNSSEC where it is needed 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, 28 Sep 2011 01:57:53 -0000 >> If DNSSEC protection is obviated, then an attacker could not only >> block the DANE repudiation, but even insert a false confirmation >> for a fraudulently issued cert and create a false sense of security. >=20 > No, he can't. The attack you describe only applies to type 2 certs, = which still need to be covered by DNSSEC in our proposal. Paul beat me to it. With type 0/1 certs, the attacker can only block = the DANE repudiation. That's why there's not strictly a need for DNSSEC = in that case. --Richard= From rbarnes@bbn.com Tue Sep 27 19:27:12 2011 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 4BB891F0C3D for ; Tue, 27 Sep 2011 19:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.592 X-Spam-Level: X-Spam-Status: No, score=-106.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 Z3DLaKbvSKsL for ; Tue, 27 Sep 2011 19:27:11 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id C62511F0C3C for ; Tue, 27 Sep 2011 19:27:11 -0700 (PDT) Received: from [128.89.253.171] (port=64519 helo=[192.168.1.4]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1R8juH-0002zh-IW; Tue, 27 Sep 2011 22:29:57 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Tue, 27 Sep 2011 22:29:54 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201109272223.p8RMNPpA026467@fs4113.wdf.sap.corp> To: Richard L. Barnes X-Mailer: Apple Mail (2.1084) Cc: Paul Hoffman , dane@ietf.org Subject: Re: [dane] #36: Only requiring DNSSEC where it is needed 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, 28 Sep 2011 02:27:12 -0000 In other words, I support the authors' proposal. That's what I get for = not reading to the start of the thread. --Richard On Sep 27, 2011, at 10:00 PM, Richard L. Barnes wrote: >>> If DNSSEC protection is obviated, then an attacker could not only >>> block the DANE repudiation, but even insert a false confirmation >>> for a fraudulently issued cert and create a false sense of security. >>=20 >> No, he can't. The attack you describe only applies to type 2 certs, = which still need to be covered by DNSSEC in our proposal. >=20 > Paul beat me to it. With type 0/1 certs, the attacker can only block = the DANE repudiation. That's why there's not strictly a need for DNSSEC = in that case. >=20 > --Richard > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From hallam@gmail.com Tue Sep 27 19:37:36 2011 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 CBA8421F8BDE for ; Tue, 27 Sep 2011 19:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.47 X-Spam-Level: X-Spam-Status: No, score=-3.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 YmljuKSLJwZh for ; Tue, 27 Sep 2011 19:37:36 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 15F4421F8BDB for ; Tue, 27 Sep 2011 19:37:35 -0700 (PDT) Received: by yxt33 with SMTP id 33so7391149yxt.31 for ; Tue, 27 Sep 2011 19:40:23 -0700 (PDT) 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:content-transfer-encoding; bh=E0Q+Jork8jpTtv/10nJt+SvG10/jWOZsAIf6yLC+WO4=; b=qT8mNTFbVyJg0YB3SNJpDoiMBQuq+FSPdFzNcvvYNmR56MwExRsZqdmDzPzhMp9KmX QBAxcgidi0on+UfQ0ZOq3VOrG2rNTSPJc0SSBCWPEwQ9adGJXkAx4JrgWiGmkuShRkX3 KgzrItTjnE86EbrrF6MEMMsxK1tGGfW/a65gk= MIME-Version: 1.0 Received: by 10.100.82.6 with SMTP id f6mr7802488anb.52.1317177622849; Tue, 27 Sep 2011 19:40:22 -0700 (PDT) Received: by 10.100.212.14 with HTTP; Tue, 27 Sep 2011 19:40:22 -0700 (PDT) In-Reply-To: References: <201109272223.p8RMNPpA026467@fs4113.wdf.sap.corp> Date: Tue, 27 Sep 2011 22:40:22 -0400 Message-ID: From: Phillip Hallam-Baker To: "Richard L. Barnes" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Paul Hoffman , dane@ietf.org Subject: Re: [dane] #36: Only requiring DNSSEC where it is needed 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, 28 Sep 2011 02:37:36 -0000 Just leave off all the MUSTs. Instead tell implementers and deployers what the consequence is of not signing (record cannot be relied on for some purposes). On Tue, Sep 27, 2011 at 10:29 PM, Richard L. Barnes wrote= : > In other words, I support the authors' proposal. =A0That's what I get for= not reading to the start of the thread. > --Richard > > > > On Sep 27, 2011, at 10:00 PM, Richard L. Barnes wrote: > >>>> If DNSSEC protection is obviated, then an attacker could not only >>>> block the DANE repudiation, but even insert a false confirmation >>>> for a fraudulently issued cert and create a false sense of security. >>> >>> No, he can't. The attack you describe only applies to type 2 certs, whi= ch still need to be covered by DNSSEC in our proposal. >> >> Paul beat me to it. =A0With type 0/1 certs, the attacker can only block = the DANE repudiation. =A0That's why there's not strictly a need for DNSSEC = in that case. >> >> --Richard >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > --=20 Website: http://hallambaker.com/ From trac+dane@trac.tools.ietf.org Tue Sep 27 20:16:37 2011 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 000E721F8BD8 for ; Tue, 27 Sep 2011 20:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 MYdy9uOOCrJO for ; Tue, 27 Sep 2011 20:16:36 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 02A9421F8BC5 for ; Tue, 27 Sep 2011 20:16:35 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1R8kg6-0008Ve-2C; Tue, 27 Sep 2011 23:19:22 -0400 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: matt@mattmccutchen.net, warren@kumari.net X-Trac-Project: dane Date: Wed, 28 Sep 2011 03:19:22 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/dane/trac/ticket/17#comment:2 Message-ID: <071.bc8b455232f92bf20a527c7f6d014aa7@trac.tools.ietf.org> References: <056.534f3ec35086e995318eaaebe4d70a8d@trac.tools.ietf.org> X-Trac-Ticket-ID: 17 In-Reply-To: <056.534f3ec35086e995318eaaebe4d70a8d@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: 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] #17: Should draft-ietf-dane-protocol support TLS only or be more ambitious? 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: Wed, 28 Sep 2011 03:16:37 -0000 #17: Should draft-ietf-dane-protocol support TLS only or be more ambitious? Changes (by matt@…): * milestone: milestone1 => Comment: Clearing the Milestone and Version fields because they do not appear to be meaningful. -- --------------------------------+--------------------- Reporter: warren@… | Owner: Type: defect | Status: closed Priority: major | Milestone: Component: protocol | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+--------------------- Ticket URL: dane From trac+dane@trac.tools.ietf.org Tue Sep 27 20:19:00 2011 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 204F921F8C29 for ; Tue, 27 Sep 2011 20:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 roCJZ6ZD9pC3 for ; Tue, 27 Sep 2011 20:18:59 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA3321F8C2A for ; Tue, 27 Sep 2011 20:18:59 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1R8kiO-000555-Mg; Tue, 27 Sep 2011 23:21:44 -0400 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, matt@mattmccutchen.net X-Trac-Project: dane Date: Wed, 28 Sep 2011 03:21:44 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/dane/trac/ticket/37 Message-ID: <061.a8eeecd5d3e79d55021946fbc77943e1@trac.tools.ietf.org> X-Trac-Ticket-ID: 37 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dane-protocol@tools.ietf.org, 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 Resent-To: Resent-Message-Id: <20110928031859.2EA3321F8C2A@ietfa.amsl.com> Resent-Date: Tue, 27 Sep 2011 20:18:59 -0700 (PDT) Resent-From: trac+dane@trac.tools.ietf.org Cc: dane@ietf.org Subject: [dane] #37: Additive assertion of server certificate 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: Wed, 28 Sep 2011 03:19:00 -0000 #37: Additive assertion of server certificate In the refactoring of the certificate usages in draft-ietf-dane- protocol-11, we lost the ability to make an additive assertion of a server certificate (as opposed to a PKIX trust anchor). A significant fraction of the community will be up in arms when they realize this. -- ----------------------+---------------------------------------- Reporter: matt@… | Owner: draft-ietf-dane-protocol@… Type: defect | Status: new Priority: major | Milestone: Component: protocol | Version: Severity: - | Keywords: ----------------------+---------------------------------------- Ticket URL: dane From rbarnes@bbn.com Tue Sep 27 20:32:23 2011 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 767AB21F8B31 for ; Tue, 27 Sep 2011 20:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.592 X-Spam-Level: X-Spam-Status: No, score=-106.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 YSnHpCNfBJpE for ; Tue, 27 Sep 2011 20:32:22 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id CCA6E21F8B0E for ; Tue, 27 Sep 2011 20:32:22 -0700 (PDT) Received: from [128.89.253.171] (port=64783 helo=[192.168.1.4]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1R8kvN-0003Kx-9g; Tue, 27 Sep 2011 23:35:09 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Tue, 27 Sep 2011 23:35:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201109272223.p8RMNPpA026467@fs4113.wdf.sap.corp> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1084) Cc: Paul Hoffman , dane@ietf.org Subject: Re: [dane] #36: Only requiring DNSSEC where it is needed 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, 28 Sep 2011 03:32:23 -0000 I don't agree with that. It's actively harmful to use type 2 = certificates (TA assertions) without DNSSEC, so DNSSEC needs to be MUST = USE for that class of TLSA record. --Richard On Sep 27, 2011, at 10:40 PM, Phillip Hallam-Baker wrote: > Just leave off all the MUSTs. >=20 > Instead tell implementers and deployers what the consequence is of not > signing (record cannot be relied on for some purposes). >=20 >=20 >=20 > On Tue, Sep 27, 2011 at 10:29 PM, Richard L. Barnes = wrote: >> In other words, I support the authors' proposal. That's what I get = for not reading to the start of the thread. >> --Richard >>=20 >>=20 >>=20 >> On Sep 27, 2011, at 10:00 PM, Richard L. Barnes wrote: >>=20 >>>>> If DNSSEC protection is obviated, then an attacker could not only >>>>> block the DANE repudiation, but even insert a false confirmation >>>>> for a fraudulently issued cert and create a false sense of = security. >>>>=20 >>>> No, he can't. The attack you describe only applies to type 2 certs, = which still need to be covered by DNSSEC in our proposal. >>>=20 >>> Paul beat me to it. With type 0/1 certs, the attacker can only = block the DANE repudiation. That's why there's not strictly a need for = DNSSEC in that case. >>>=20 >>> --Richard >>> _______________________________________________ >>> dane mailing list >>> dane@ietf.org >>> https://www.ietf.org/mailman/listinfo/dane >>=20 >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >>=20 >=20 >=20 >=20 > --=20 > Website: http://hallambaker.com/ From rbarnes@bbn.com Tue Sep 27 20:37:24 2011 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 B6DF621F8C45 for ; Tue, 27 Sep 2011 20:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.592 X-Spam-Level: X-Spam-Status: No, score=-106.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 hEXpx9Ty4EQ8 for ; Tue, 27 Sep 2011 20:37:23 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 234DB21F8BF6 for ; Tue, 27 Sep 2011 20:37:23 -0700 (PDT) Received: from [128.89.253.171] (port=64790 helo=[192.168.1.4]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1R8l00-0003MU-8K; Tue, 27 Sep 2011 23:39:56 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: "Richard L. Barnes" In-Reply-To: <061.a8eeecd5d3e79d55021946fbc77943e1@trac.tools.ietf.org> Date: Tue, 27 Sep 2011 23:39:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <061.a8eeecd5d3e79d55021946fbc77943e1@trac.tools.ietf.org> To: "dane issue tracker" X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-dane-protocol@tools.ietf.org, dane@ietf.org Subject: Re: [dane] #37: Additive assertion of server certificate 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, 28 Sep 2011 03:37:24 -0000 This is a non-issue. Using the cert as a TA means that you accept any = chain starting with that cert. Since a server cert itself is a chain = starting with that cert (of length 1), if you put a server cert in a = type 2 record, it Just Works. =20 --Richard On Sep 27, 2011, at 11:21 PM, dane issue tracker wrote: > #37: Additive assertion of server certificate >=20 > In the refactoring of the certificate usages in draft-ietf-dane- > protocol-11, we lost the ability to make an additive assertion of a = server > certificate (as opposed to a PKIX trust anchor). A significant = fraction > of the community will be up in arms when they realize this. >=20 > --=20 > ----------------------+---------------------------------------- > Reporter: matt@=85 | Owner: draft-ietf-dane-protocol@=85 > Type: defect | Status: new > Priority: major | Milestone: > Component: protocol | Version: > Severity: - | Keywords: > ----------------------+---------------------------------------- >=20 > Ticket URL: > dane >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From trac+dane@trac.tools.ietf.org Tue Sep 27 20:42:28 2011 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 3766B21F8CA5 for ; Tue, 27 Sep 2011 20:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 UbO6jIIVBkJ5 for ; Tue, 27 Sep 2011 20:42:27 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id B1E5121F84DD for ; Tue, 27 Sep 2011 20:42:27 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1R8l55-0008Qc-14; Tue, 27 Sep 2011 23:45:11 -0400 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, matt@mattmccutchen.net X-Trac-Project: dane Date: Wed, 28 Sep 2011 03:45:11 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/dane/trac/ticket/36#comment:1 Message-ID: <075.e771c9a4f93afa495f330ae9d1ebfa5a@trac.tools.ietf.org> References: <060.8aca11012e6c9583642ba071c54be972@trac.tools.ietf.org> X-Trac-Ticket-ID: 36 In-Reply-To: <060.8aca11012e6c9583642ba071c54be972@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dane-protocol@tools.ietf.org, 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 Resent-To: Resent-Message-Id: <20110928034227.B1E5121F84DD@ietfa.amsl.com> Resent-Date: Tue, 27 Sep 2011 20:42:27 -0700 (PDT) Resent-From: trac+dane@trac.tools.ietf.org Cc: dane@ietf.org Subject: Re: [dane] #36: Only requiring DNSSEC where it is needed 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: Wed, 28 Sep 2011 03:42:28 -0000 #36: Only requiring DNSSEC where it is needed Comment (by matt@…): Let's be very clear what this means. A client MUST NOT process additive assertions (i.e., type 2) that are not DNSSEC "secure"; that would be an obvious hole. A client MAY process purely restrictive assertions (i.e., types 0 and 1) regardless of DNSSEC usage or state. However, users/implementers should realize that processing a restrictive assertion that is not DNSSEC "secure" is pointless security-wise except in unusual scenarios. A related issue is whether clients MUST (1) attempt a DNSSEC query, (2) fail the handshake unless the query completes with "secure" or "verified insecure" state, and (3) if a "secure" nonempty TLSA RRset is returned, process it as described in the spec. This requirement goes hand in hand with the current statement that clients MUST fail the handshake if the server cert does not match any TLSA RR; one is not meaningful without the other. So I think we should make both or neither of these behaviors conformance requirements (c.f. ticket:26). -- ----------------------------+----------------------------------------- Reporter: paul.hoffman@… | Owner: draft-ietf-dane-protocol@… Type: defect | Status: new Priority: major | Milestone: Component: protocol | Version: Severity: - | Resolution: Keywords: | ----------------------------+----------------------------------------- Ticket URL: dane From matt@mattmccutchen.net Tue Sep 27 20:48:27 2011 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 4AE2A11E8088 for ; Tue, 27 Sep 2011 20:48:27 -0700 (PDT) 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 x5WDK1Jd8zrn for ; Tue, 27 Sep 2011 20:48:26 -0700 (PDT) Received: from homiemail-a2.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 6908211E8085 for ; Tue, 27 Sep 2011 20:48:26 -0700 (PDT) Received: from homiemail-a2.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a2.g.dreamhost.com (Postfix) with ESMTP id AC6E4280063; Tue, 27 Sep 2011 20:51:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; q=dns; s= mattmccutchen.net; b=SKQp5Btet1xY4RTsS6ir4cbi8mUM0D59BJ44RfZUzf8 vFK/muBzQnKNaDDay3yk+lo0opS5wwyNYwru8wb4uVZq8PKo/KMgNEpIan2f7GOy RzI8GqP/khTz8PiJAepcRKfwykCkiVt7ei8r9hGlymKmQgb73rJDxa1lMASbgzMg = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; s= mattmccutchen.net; bh=GVnvh/qwguUb+bPOT3gs6QDX/fE=; b=D7hIDLMPj0 lL17BzXSnnX0aQBIojTyd9wcc8yQNtn7178MnzY9rIXW1s1EyA+0xoLZ+XQ1VWa+ nO1TPe9r8vtT8Y3sKMIEI9YW0iWELfayZbrG2d/TpB9bpx619RmNazaNg+twJtAx 2BLlFx9dW4FE5PIZIB4/1dEJJpTPqAAZc= 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-a2.g.dreamhost.com (Postfix) with ESMTPSA id 8B3E1280062; Tue, 27 Sep 2011 20:51:13 -0700 (PDT) From: Matt McCutchen To: "Richard L. Barnes" Date: Tue, 27 Sep 2011 20:51:11 -0700 In-Reply-To: References: <061.a8eeecd5d3e79d55021946fbc77943e1@trac.tools.ietf.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 Content-Transfer-Encoding: 7bit Message-ID: <1317181872.2975.13.camel@localhost> Mime-Version: 1.0 Cc: dane@ietf.org Subject: Re: [dane] #37: Additive assertion of server certificate 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, 28 Sep 2011 03:48:27 -0000 On Tue, 2011-09-27 at 23:39 -0400, Richard L. Barnes wrote: > This is a non-issue. Using the cert as a TA means that you accept any > chain starting with that cert. Since a server cert itself is a chain > starting with that cert (of length 1), if you put a server cert in a > type 2 record, it Just Works. Really? What happened to "PKIX doesn't support self-signed server certs"? And while I don't foresee any attacks based on presenting a cert that chains to the designated cert rather than the designated cert itself, I'd venture that I'm one of many server admins who would feel much better cutting the complexity of PKIX completely out of the TLS server authentication process. -- Matt From rbarnes@bbn.com Tue Sep 27 20:58:22 2011 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 2834B21F8CCC for ; Tue, 27 Sep 2011 20:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.592 X-Spam-Level: X-Spam-Status: No, score=-106.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 D1PpBLoJmVlc for ; Tue, 27 Sep 2011 20:58:21 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7AFC721F8CCA for ; Tue, 27 Sep 2011 20:58:21 -0700 (PDT) Received: from [128.89.253.171] (port=64828 helo=[192.168.1.4]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1R8lKT-0003W4-CN; Wed, 28 Sep 2011 00:01:05 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <1317181872.2975.13.camel@localhost> Date: Wed, 28 Sep 2011 00:01:04 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <444081ED-DF03-45E3-83FD-889EF53D6F03@bbn.com> References: <061.a8eeecd5d3e79d55021946fbc77943e1@trac.tools.ietf.org> <1317181872.2975.13.camel@localhost> To: Matt McCutchen X-Mailer: Apple Mail (2.1084) Cc: dane@ietf.org Subject: Re: [dane] #37: Additive assertion of server certificate 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, 28 Sep 2011 03:58:22 -0000 >> This is a non-issue. Using the cert as a TA means that you accept = any >> chain starting with that cert. Since a server cert itself is a chain >> starting with that cert (of length 1), if you put a server cert in a >> type 2 record, it Just Works. >=20 > Really? What happened to "PKIX doesn't support self-signed server > certs"? =20 PKIX support for self-signed server certs is a little hazy. On the one = hand, any cert that has the keyEncipherment and digitalSignature bits = set meets the requirements of RFC 5246, regardless of who issued it. On = the other hand, it is standard PKIX practice to use CA certs only for = signing certs, not for other purposes. =20 Practically speaking, if PKIX libraries didn't support self-signed = server certs, we wouldn't be having this discussion. > And while I don't foresee any attacks based on presenting a > cert that chains to the designated cert rather than the designated = cert > itself, If an attacker can issue himself a cert under your self-signed cert, = then you're already pwned. Nothing DANE can do about this case. > I'd venture that I'm one of many server admins who would feel > much better cutting the complexity of PKIX completely out of the TLS > server authentication process. In the self-signed case, PKIX validation reduces to equality of = certificates, so there's not really any complexity. And the idea of "cutting the complexity of PKIX completely out of TLS" = is kind of illusory, since as other folks have pointed out, there are = other reasons for keeping PKIX around. So by having a non-PKIX path, = you're actually *adding* complexity because you have to switch between = the two. --Richard From matt@mattmccutchen.net Tue Sep 27 21:25:34 2011 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 710AB11E808D for ; Tue, 27 Sep 2011 21:25:34 -0700 (PDT) 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=[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 ZgfrSuBj8d7q for ; Tue, 27 Sep 2011 21:25:33 -0700 (PDT) Received: from homiemail-a6.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id BC4CE11E8086 for ; Tue, 27 Sep 2011 21:25:33 -0700 (PDT) Received: from homiemail-a6.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTP id E4756598077; Tue, 27 Sep 2011 21:28:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; q=dns; s= mattmccutchen.net; b=A54hpipOqypn83l9CShwVULD28sPMxtAU/IFnPMupds f8CsC+e1mCvV+3j83vbkLdQY1bsb/81qqP0tQ1+qJm3U/movWynRsGPt2zj7mbDO MjgBBlHa/lryxui1RV89IQsDpPuL6UkcLxMZoMBo79Y+A4Q4uHstYoU6H6kaoa8Q = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; s= mattmccutchen.net; bh=Uxqhw1L/g/q6vnZdgfaX0DmzNVk=; b=vNJxNXvaZV Sps/CqrAbeoZk/z2r71Tkos/bElNh+xa+8lWaBAChme0eLD3EIETDb8q6nlQS+uV Oqn+N0AcfuY3zkpfpnaPqV2EAU7up1j2ftMgUF1B3Ppbx/tjEDDEPMjicOasRgA3 wIRVbidd+mrvznfz9mDwIqYZX9iK+Ea4g= 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 B63F0598070; Tue, 27 Sep 2011 21:28:20 -0700 (PDT) From: Matt McCutchen To: "Richard L. Barnes" Date: Tue, 27 Sep 2011 21:28:16 -0700 In-Reply-To: <444081ED-DF03-45E3-83FD-889EF53D6F03@bbn.com> References: <061.a8eeecd5d3e79d55021946fbc77943e1@trac.tools.ietf.org> <1317181872.2975.13.camel@localhost> <444081ED-DF03-45E3-83FD-889EF53D6F03@bbn.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 Content-Transfer-Encoding: 7bit Message-ID: <1317184098.2975.30.camel@localhost> Mime-Version: 1.0 Cc: dane@ietf.org Subject: Re: [dane] #37: Additive assertion of server certificate 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, 28 Sep 2011 04:25:34 -0000 On Wed, 2011-09-28 at 00:01 -0400, Richard L. Barnes wrote: > PKIX support for self-signed server certs is a little hazy. On the > one hand, any cert that has the keyEncipherment and digitalSignature > bits set meets the requirements of RFC 5246, regardless of who issued > it. On the other hand, it is standard PKIX practice to use CA certs > only for signing certs, not for other purposes. > > Practically speaking, if PKIX libraries didn't support self-signed > server certs, we wouldn't be having this discussion. You are confusing PKIX and TLS. Practically, TLS libraries support extracting the server public key from any cert, self-signed or not. But server authentication for self-signed certs is hardly ever achieved by the code path of "PKIX validation with a trust anchor" to which DANE cert usage 2 refers, so one cannot claim that this approach is well tested for use in DANE. E.g., in Firefox, one would mark the server cert as CERTDB_TRUSTED in NSS or use a PSM cert override; I doubt that marking the cert as CERTDB_TRUSTED_CA would work. > > And while I don't foresee any attacks based on presenting a > > cert that chains to the designated cert rather than the designated cert > > itself, > > If an attacker can issue himself a cert under your self-signed cert, > then you're already pwned. Nothing DANE can do about this case. Yes, that's what I was thinking, though I wonder if there are edge cases where an attacker in possession of an old signature of a weak hash could graft it onto a certificate or something like that. > > I'd venture that I'm one of many server admins who would feel > > much better cutting the complexity of PKIX completely out of the TLS > > server authentication process. > > In the self-signed case, PKIX validation reduces to equality of > certificates, so there's not really any complexity. Don't be silly. My concern is not about the happy case (though I would want to be clear that PKIX validity period, subject name, etc. are not checked), but that PKIX validation may present significant, avoidable attack surface. > And the idea of "cutting the complexity of PKIX completely out of TLS" > is kind of illusory, since as other folks have pointed out, there are > other reasons for keeping PKIX around. So by having a non-PKIX path, > you're actually *adding* complexity because you have to switch between > the two. That's a pretty skewed interpretation of the facts. You would rather have a complex code path taken 100% of the time than a switch between a trivially simple path (say) 50% of the time and a complex path the other 50%? -- Matt From matt@mattmccutchen.net Tue Sep 27 21:36:39 2011 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 118D821F8B17 for ; Tue, 27 Sep 2011 21:36:39 -0700 (PDT) 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 EM+0Uxlp1xSt for ; Tue, 27 Sep 2011 21:36:38 -0700 (PDT) Received: from homiemail-a61.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 82BD021F8B14 for ; Tue, 27 Sep 2011 21:36:38 -0700 (PDT) Received: from homiemail-a61.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a61.g.dreamhost.com (Postfix) with ESMTP id E47EF578071; Tue, 27 Sep 2011 21:39:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; q=dns; s= mattmccutchen.net; b=kKMI4pNpOQCU3u43Ss1xXZ/UuwpSVJyC/86rIuBGOIF wmxMrQXo5+hL8c2TKw7aD7lMnvYP132oiifwsV6+77gs8duLUrmf8WbdW32zftol 8LXFwfwogVCXYjg3aov9H76tjQ1fH9oK8g7PJDEIejotF8Bf8Eypt9aGLIBaPlnI = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; s= mattmccutchen.net; bh=DhCXMX01XpC6fd1Krq8fp8VSB1k=; b=gg7+0zyZwx u4t5vsoqSf8fjugRDtYNSYFYX+6VbnKesxFCEY42H5ODgWVTR+YyIGV+GuPXXtal 4XK206m6jeuxS6XWfsHfxVbUmSthWQB3nZz1mhB3OSQgqf3Fc8kZZkPM1iAZeurV NMN+sxqScGSH0aL9kg65DTJ4OH/dNFfsE= 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-a61.g.dreamhost.com (Postfix) with ESMTPSA id BF91A57806C; Tue, 27 Sep 2011 21:39:25 -0700 (PDT) From: Matt McCutchen To: "Richard L. Barnes" Date: Tue, 27 Sep 2011 21:39:21 -0700 In-Reply-To: <444081ED-DF03-45E3-83FD-889EF53D6F03@bbn.com> References: <061.a8eeecd5d3e79d55021946fbc77943e1@trac.tools.ietf.org> <1317181872.2975.13.camel@localhost> <444081ED-DF03-45E3-83FD-889EF53D6F03@bbn.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 Content-Transfer-Encoding: 7bit Message-ID: <1317184762.2975.36.camel@localhost> Mime-Version: 1.0 Cc: dane@ietf.org Subject: Re: [dane] #37: Additive assertion of server certificate 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, 28 Sep 2011 04:36:39 -0000 I forgot one point... On Wed, 2011-09-28 at 00:01 -0400, Richard L. Barnes wrote: > And the idea of "cutting the complexity of PKIX completely out of TLS" > is kind of illusory, since as other folks have pointed out, there are > other reasons for keeping PKIX around. That's pretty vague. Of course clients need a PKIX library to process the cert usages that involve PKIX. But if clients connect to https://mattmccutchen.net, which has a TLSA RRset consisting of a single server cert association that is both additive and restrictive, what reason is there to involve PKIX in that process? -- Matt From rbarnes@bbn.com Wed Sep 28 04:39:16 2011 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 D18F821F8CC1 for ; Wed, 28 Sep 2011 04:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.592 X-Spam-Level: X-Spam-Status: No, score=-106.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 ZbZinEAlTXtK for ; Wed, 28 Sep 2011 04:39:16 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 41F2121F8CC4 for ; Wed, 28 Sep 2011 04:39:16 -0700 (PDT) Received: from [128.89.254.81] (port=64937 helo=[192.168.1.4]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1R8sWa-0009Fp-4U; Wed, 28 Sep 2011 07:42:04 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <1317184098.2975.30.camel@localhost> Date: Wed, 28 Sep 2011 07:42:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <42D80BDE-458A-45F5-859C-CA955A6D7D4B@bbn.com> References: <061.a8eeecd5d3e79d55021946fbc77943e1@trac.tools.ietf.org> <1317181872.2975.13.camel@localhost> <444081ED-DF03-45E3-83FD-889EF53D6F03@bbn.com> <1317184098.2975.30.camel@localhost> To: Matt McCutchen X-Mailer: Apple Mail (2.1084) Cc: dane@ietf.org Subject: Re: [dane] #37: Additive assertion of server certificate 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, 28 Sep 2011 11:39:16 -0000 Responses inline. >> PKIX support for self-signed server certs is a little hazy. On the >> one hand, any cert that has the keyEncipherment and digitalSignature >> bits set meets the requirements of RFC 5246, regardless of who issued >> it. On the other hand, it is standard PKIX practice to use CA certs >> only for signing certs, not for other purposes. =20 >>=20 >> Practically speaking, if PKIX libraries didn't support self-signed >> server certs, we wouldn't be having this discussion. >=20 > You are confusing PKIX and TLS. Practically, TLS libraries support > extracting the server public key from any cert, self-signed or not.=20 > But server authentication for self-signed certs is hardly ever = achieved > by the code path of "PKIX validation with a trust anchor" to which = DANE > cert usage 2 refers, so one cannot claim that this approach is well > tested for use in DANE. E.g., in Firefox, one would mark the server > cert as CERTDB_TRUSTED in NSS or use a PSM cert override; I doubt that > marking the cert as CERTDB_TRUSTED_CA would work. I'm not confusing PKIX and TLS. The two are intertwined in the notion = of a "self-signed server cert". A type 2 certificate does not actually map to CERTDB_TRUSTED, since IIRC = that mark=20 >>> And while I don't foresee any attacks based on presenting a >>> cert that chains to the designated cert rather than the designated = cert >>> itself, >>=20 >> If an attacker can issue himself a cert under your self-signed cert, >> then you're already pwned. Nothing DANE can do about this case. >=20 > Yes, that's what I was thinking, though I wonder if there are edge = cases > where an attacker in possession of an old signature of a weak hash = could > graft it onto a certificate or something like that. >=20 >>> I'd venture that I'm one of many server admins who would feel >>> much better cutting the complexity of PKIX completely out of the TLS >>> server authentication process. >>=20 >> In the self-signed case, PKIX validation reduces to equality of >> certificates, so there's not really any complexity. >=20 > Don't be silly. My concern is not about the happy case (though I = would > want to be clear that PKIX validity period, subject name, etc. are not > checked), but that PKIX validation may present significant, avoidable > attack surface. Unless you can document some details of the attack you're proposing = above, I'm not really convinced that there's any additional attack = surface here. From paul.hoffman@vpnc.org Wed Sep 28 07:26:22 2011 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 5DDFD21F8CAF for ; Wed, 28 Sep 2011 07:26:22 -0700 (PDT) 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 UMCt8g7m5pjH for ; Wed, 28 Sep 2011 07:26:22 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id D402721F8C88 for ; Wed, 28 Sep 2011 07:26:21 -0700 (PDT) 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 p8SET9sf037635 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 28 Sep 2011 07:29:10 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1244.3) From: Paul Hoffman In-Reply-To: Date: Wed, 28 Sep 2011 07:29:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201109272223.p8RMNPpA026467@fs4113.wdf.sap.corp> To: IETF DANE WG X-Mailer: Apple Mail (2.1244.3) Subject: Re: [dane] #36: Only requiring DNSSEC where it is needed 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, 28 Sep 2011 14:26:22 -0000 On Sep 27, 2011, at 8:35 PM, Richard L. Barnes wrote: > I don't agree with that. It's actively harmful to use type 2 = certificates (TA assertions) without DNSSEC, so DNSSEC needs to be MUST = USE for that class of TLSA record. +1 --Paul Hoffman From matt@mattmccutchen.net Wed Sep 28 08:43:08 2011 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 4A33911E80A0 for ; Wed, 28 Sep 2011 08:43:08 -0700 (PDT) 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=[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 zWYPSEB8KwWI for ; Wed, 28 Sep 2011 08:43:07 -0700 (PDT) Received: from homiemail-a38.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 44E5B11E80B8 for ; Wed, 28 Sep 2011 08:43:07 -0700 (PDT) Received: from homiemail-a38.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a38.g.dreamhost.com (Postfix) with ESMTP id CEBFC10AFAD; Wed, 28 Sep 2011 08:45:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; q=dns; s= mattmccutchen.net; b=aquT6aFHGXj4+fmzfL+c72MV1AI4BuVRP+kKEEKQ8fB JlSPHIgdoeQY+zlwritSalnRGIvFpcAyO4YSUg0tvziSCNiAOD51dIvKRRxyuFlR Vb+1zoc43UAwWHy5Y0i0QdcKoHAmsGRric9ptj199HALyI8WN/7lDqGVijr9qS14 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; s= mattmccutchen.net; bh=W3PzI8j0svCpjkatRtOBDggfztY=; b=IfP8y3Y7Il x+ZbZ6I6z+rgUfoqMdBmC0OIxhGu2qd3xkxBAwM3jH6Q9qT/R+qmNeebpbwWbiVm E+shOEMVGxSjKHGzgERhwXZhb5MJDQ9coyvO9RthaWC+M8/fph6wS6kN+eCKW634 10H0P6zEvWf7JBW4+HOFs1vpHkEmaI40Q= 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 92F5B10AFAB; Wed, 28 Sep 2011 08:45:55 -0700 (PDT) From: Matt McCutchen To: "Richard L. Barnes" Date: Wed, 28 Sep 2011 08:45:48 -0700 In-Reply-To: <42D80BDE-458A-45F5-859C-CA955A6D7D4B@bbn.com> References: <061.a8eeecd5d3e79d55021946fbc77943e1@trac.tools.ietf.org> <1317181872.2975.13.camel@localhost> <444081ED-DF03-45E3-83FD-889EF53D6F03@bbn.com> <1317184098.2975.30.camel@localhost> <42D80BDE-458A-45F5-859C-CA955A6D7D4B@bbn.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 Content-Transfer-Encoding: 7bit Message-ID: <1317224748.2975.49.camel@localhost> Mime-Version: 1.0 Cc: dane@ietf.org Subject: Re: [dane] #37: Additive assertion of server certificate 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, 28 Sep 2011 15:43:08 -0000 On Wed, 2011-09-28 at 07:42 -0400, Richard L. Barnes wrote: > >> PKIX support for self-signed server certs is a little hazy. On the > >> one hand, any cert that has the keyEncipherment and digitalSignature > >> bits set meets the requirements of RFC 5246, regardless of who issued > >> it. On the other hand, it is standard PKIX practice to use CA certs > >> only for signing certs, not for other purposes. > >> > >> Practically speaking, if PKIX libraries didn't support self-signed > >> server certs, we wouldn't be having this discussion. > > > > You are confusing PKIX and TLS. Practically, TLS libraries support > > extracting the server public key from any cert, self-signed or not. > > But server authentication for self-signed certs is hardly ever achieved > > by the code path of "PKIX validation with a trust anchor" to which DANE > > cert usage 2 refers, so one cannot claim that this approach is well > > tested for use in DANE. E.g., in Firefox, one would mark the server > > cert as CERTDB_TRUSTED in NSS or use a PSM cert override; I doubt that > > marking the cert as CERTDB_TRUSTED_CA would work. > > I'm not confusing PKIX and TLS. The two are intertwined in the notion of a "self-signed server cert". > > A type 2 certificate does not actually map to CERTDB_TRUSTED, since IIRC that mark Please finish? > >>> And while I don't foresee any attacks based on presenting a > >>> cert that chains to the designated cert rather than the designated cert > >>> itself, > >> > >> If an attacker can issue himself a cert under your self-signed cert, > >> then you're already pwned. Nothing DANE can do about this case. > > > > Yes, that's what I was thinking, though I wonder if there are edge cases > > where an attacker in possession of an old signature of a weak hash could > > graft it onto a certificate or something like that. > > > >>> I'd venture that I'm one of many server admins who would feel > >>> much better cutting the complexity of PKIX completely out of the TLS > >>> server authentication process. > >> > >> In the self-signed case, PKIX validation reduces to equality of > >> certificates, so there's not really any complexity. > > > > Don't be silly. My concern is not about the happy case (though I would > > want to be clear that PKIX validity period, subject name, etc. are not > > checked), but that PKIX validation may present significant, avoidable > > attack surface. > > Unless you can document some details of the attack you're proposing > above, I'm not really convinced that there's any additional attack > surface here. The attack was just a thought; Martin Rex would probably have a better idea if such a thing might be possible. My greater concern is just about calling such a large piece of code: it might have memory safety vulnerabilities, or a bug where some bizarre combination of cert extensions can trigger a different path construction mode where it uses the default trust anchor set instead of the one specified for the operation, or it might simply pull intermediate certs from AIA when you would rather it didn't make arbitrary HTTP requests during the server authentication process. These issues are all unlikely or of secondary importance, but they are so easy to avoid by adding cert usage 3: "Exact certificate (or SubjectPublicKeyInfo) asserted to be that of the authentic TLS server". I would be surprised if WG consensus were against doing this. Certainly WG consensus was not established to remove the functionality in draft-ietf-dane-protocol-11. -- Matt From trac+dane@trac.tools.ietf.org Wed Sep 28 08:56:24 2011 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 72A8A11E80CD for ; Wed, 28 Sep 2011 08:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 u9BPC6VyhVWq for ; Wed, 28 Sep 2011 08:56:24 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id E54B511E80C9 for ; Wed, 28 Sep 2011 08:56:23 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1R8wXJ-0000oJ-79; Wed, 28 Sep 2011 11:59:05 -0400 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, matt@mattmccutchen.net X-Trac-Project: dane Date: Wed, 28 Sep 2011 15:59:05 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/33#comment:1 Message-ID: <076.bdd0467de056ddca69582bc0104dce57@trac.tools.ietf.org> References: <061.add9f922b5dfb2db7544981f78552e7e@trac.tools.ietf.org> X-Trac-Ticket-ID: 33 In-Reply-To: <061.add9f922b5dfb2db7544981f78552e7e@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dane-protocol@tools.ietf.org, 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 Resent-To: Resent-Message-Id: <20110928155623.E54B511E80C9@ietfa.amsl.com> Resent-Date: Wed, 28 Sep 2011 08:56:23 -0700 (PDT) Resent-From: trac+dane@trac.tools.ietf.org Cc: dane@ietf.org Subject: Re: [dane] #33: Publish enough information for the client to achieve the security of its favorite digest 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: Wed, 28 Sep 2011 15:56:24 -0000 #33: Publish enough information for the client to achieve the security of its favorite digest Comment (by matt@…): So... in list discussion, I think I successfully answered all the objections except the subjective one of "complexity". Are we ready for a preliminary consensus call? I would ask that each person indicate, for each of the three proposed solutions, whether they prefer it ''to the status quo''. If you want this problem solved, please do not -1 a solution simply because you prefer a different solution, or we are at risk of splitting the vote and not getting a solution at all. -- ----------------------+----------------------------------------- Reporter: matt@… | Owner: draft-ietf-dane-protocol@… Type: defect | Status: new Priority: major | Milestone: Component: protocol | Version: Severity: - | Resolution: Keywords: | ----------------------+----------------------------------------- Ticket URL: dane From peter@denic.de Wed Sep 28 09:32:30 2011 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 D832E21F8C0C for ; Wed, 28 Sep 2011 09:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.48 X-Spam-Level: X-Spam-Status: No, score=-101.48 tagged_above=-999 required=5 tests=[AWL=-0.893, BAYES_00=-2.599, FAKE_REPLY_C=2.012, 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 p1ZizTTM0Pd5 for ; Wed, 28 Sep 2011 09:32:30 -0700 (PDT) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::4]) by ietfa.amsl.com (Postfix) with ESMTP id 6362721F8BFE for ; Wed, 28 Sep 2011 09:32:30 -0700 (PDT) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1R8x6M-000612-Jn; Wed, 28 Sep 2011 18:35:18 +0200 Received: from localhost by x27.adm.denic.de with local id 1R8x6M-0000M3-GA; Wed, 28 Sep 2011 18:35:18 +0200 Date: Wed, 28 Sep 2011 18:35:18 +0200 From: Peter Koch To: IETF DANE WG Message-ID: <20110928163518.GL3290@x27.adm.denic.de> Mail-Followup-To: IETF DANE WG Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: Re: [dane] Reopening issue #22 for discussion.... 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, 28 Sep 2011 16:32:31 -0000 {we've probably left #22 already} On Mon, Sep 26, 2011 at 06:50:46AM -0700, Paul Hoffman wrote: > >> Current wording in the spec: > >> DNS systems conforming to this specification MUST be able to create > >> TLSA records using matching type 0 (no hash used) and matching type 1 > >> (SHA-256), and SHOULD be able to create TLSA records using matching > >> type 2 (SHA-512). > > > > this text is misleading. The draft doesn't say what it considers a "DNS system", > > Good point. > > > but to avoid ambiguity it should be clarified that there's no "conformance" > > issue for the DNS name server but rather what one had in mind here is > > some provisioning entity that will (be used to) feed data into the DNS zone. > > Correct: that's is the entity where the conformance requirement applies. > > > The RRSet content, signed or unsigned, is transparent to the name server as > > per RFC 3597. > > Yep. > > Does "A system creating TLSA records that conforms to ... " work? Is there some clearer wording we can use? avoiding 'DNS system' helps clarifying the issue. Whether the "system" or the data should be the target of the MUST depends on what you intend to achieve. Clearly, TLSA records could be crafted manually and would have to meet the syntax requirement. If there's some guidance or preference to be expressed for the actual use of one or the other format or some expectation regarding automated support for creating TLSA records, that may need more prose and i'm not sure the formal criteria for a MUST are met here. Summary: your proposed wording is an improvement IMHO, but the text as a whole needs another pass. -Peter From rbarnes@bbn.com Wed Sep 28 09:37:13 2011 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 99BA321F8B4E for ; Wed, 28 Sep 2011 09:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.592 X-Spam-Level: X-Spam-Status: No, score=-106.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 mYMMLMrSB8aD for ; Wed, 28 Sep 2011 09:37:13 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id CDDAD21F8B4A for ; Wed, 28 Sep 2011 09:37:12 -0700 (PDT) Received: from [128.89.253.226] (port=50950) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1R8xAv-000Cja-AZ; Wed, 28 Sep 2011 12:40:01 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <1317224748.2975.49.camel@localhost> Date: Wed, 28 Sep 2011 12:40:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <001F15D5-0861-4CE2-8148-3EBC9B55C2B0@bbn.com> References: <061.a8eeecd5d3e79d55021946fbc77943e1@trac.tools.ietf.org> <1317181872.2975.13.camel@localhost> <444081ED-DF03-45E3-83FD-889EF53D6F03@bbn.com> <1317184098.2975.30.camel@localhost> <42D80BDE-458A-45F5-859C-CA955A6D7D4B@bbn.com> <1317224748.2975.49.camel@localhost> To: Matt McCutchen X-Mailer: Apple Mail (2.1084) Cc: dane@ietf.org Subject: Re: [dane] #37: Additive assertion of server certificate 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, 28 Sep 2011 16:37:13 -0000 >>>> PKIX support for self-signed server certs is a little hazy. On the >>>> one hand, any cert that has the keyEncipherment and = digitalSignature >>>> bits set meets the requirements of RFC 5246, regardless of who = issued >>>> it. On the other hand, it is standard PKIX practice to use CA = certs >>>> only for signing certs, not for other purposes. =20 >>>>=20 >>>> Practically speaking, if PKIX libraries didn't support self-signed >>>> server certs, we wouldn't be having this discussion. >>>=20 >>> You are confusing PKIX and TLS. Practically, TLS libraries support >>> extracting the server public key from any cert, self-signed or not.=20= >>> But server authentication for self-signed certs is hardly ever = achieved >>> by the code path of "PKIX validation with a trust anchor" to which = DANE >>> cert usage 2 refers, so one cannot claim that this approach is well >>> tested for use in DANE. E.g., in Firefox, one would mark the server >>> cert as CERTDB_TRUSTED in NSS or use a PSM cert override; I doubt = that >>> marking the cert as CERTDB_TRUSTED_CA would work. >>=20 >> I'm not confusing PKIX and TLS. The two are intertwined in the = notion of a "self-signed server cert". >>=20 >> A type 2 certificate does not actually map to CERTDB_TRUSTED, since = IIRC that mark=20 >=20 > Please finish? Sorry, emailing before coffee. I was going to say that IIRC, the = CERTDB_TRUSTED and CERTDB_TRUSTED_CA marks apply across all domains, so = they're not constrained in the same way as a type 2 TLSA record is to = apply to a single domain only. But I might be wrong about that, in = which case, it could be very simple for Firefox to implement type 2 = certificates by setting CERTDB_TRUSTED_CA with some name constraints.=20 >>>>> And while I don't foresee any attacks based on presenting a >>>>> cert that chains to the designated cert rather than the designated = cert >>>>> itself, >>>>=20 >>>> If an attacker can issue himself a cert under your self-signed = cert, >>>> then you're already pwned. Nothing DANE can do about this case. >>>=20 >>> Yes, that's what I was thinking, though I wonder if there are edge = cases >>> where an attacker in possession of an old signature of a weak hash = could >>> graft it onto a certificate or something like that. >>>=20 >>>>> I'd venture that I'm one of many server admins who would feel >>>>> much better cutting the complexity of PKIX completely out of the = TLS >>>>> server authentication process. >>>>=20 >>>> In the self-signed case, PKIX validation reduces to equality of >>>> certificates, so there's not really any complexity. >>>=20 >>> Don't be silly. My concern is not about the happy case (though I = would >>> want to be clear that PKIX validity period, subject name, etc. are = not >>> checked), but that PKIX validation may present significant, = avoidable >>> attack surface. >>=20 >> Unless you can document some details of the attack you're proposing >> above, I'm not really convinced that there's any additional attack >> surface here. >=20 > The attack was just a thought; Martin Rex would probably have a better > idea if such a thing might be possible. My greater concern is just > about calling such a large piece of code: it might have memory safety > vulnerabilities, or a bug where some bizarre combination of cert > extensions can trigger a different path construction mode where it = uses > the default trust anchor set instead of the one specified for the > operation, or it might simply pull intermediate certs from AIA when = you > would rather it didn't make arbitrary HTTP requests during the server > authentication process. You seem to be missing the point that if PKIX libraries are broken, = we're all screwed already. Even though OpenSSL, NSS, and the like have = a non-trivial number of bugs, we seem to have gotten by with them for = many years now. The PKIX problems that DANE addresses are all about = asserting and limiting CAs, not about software. Regarding AIA in particular: If you've got a self-signed cert, you can = control whether or not there's an AIA extension or not, so that's not an = issue. If you've got a cert signed by a third-party, why would you not = expect someone to actually validate it? If you want to stop normal = validation, just use a self-signed cert. Please be concrete about the risk you're trying to address instead of = just waving your hands about complexity. > Certainly > WG consensus was not established to remove the functionality in > draft-ietf-dane-protocol-11. There is WG consensus on the current approach, in the sense that the = usage values in -11 map directly to the use cases in the use case = document. --Richard From paul.hoffman@vpnc.org Wed Sep 28 09:44:18 2011 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 16C8C11E80DD for ; Wed, 28 Sep 2011 09:44:18 -0700 (PDT) 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 X2McRQRX73wy for ; Wed, 28 Sep 2011 09:44:17 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7A73D11E80DC for ; Wed, 28 Sep 2011 09:44:17 -0700 (PDT) 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 p8SGl5Al008632 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 28 Sep 2011 09:47:05 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20110928163518.GL3290@x27.adm.denic.de> Date: Wed, 28 Sep 2011 09:47:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <42C98422-2077-4F7D-A080-25DDF62FD6FB@vpnc.org> References: <20110928163518.GL3290@x27.adm.denic.de> To: Peter Koch X-Mailer: Apple Mail (2.1244.3) Cc: IETF DANE WG Subject: Re: [dane] Reopening issue #22 for discussion.... 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, 28 Sep 2011 16:44:18 -0000 On Sep 28, 2011, at 9:35 AM, Peter Koch wrote: > {we've probably left #22 already} >=20 > On Mon, Sep 26, 2011 at 06:50:46AM -0700, Paul Hoffman wrote: >=20 >>>> Current wording in the spec: >>>> DNS systems conforming to this specification MUST be able to = create >>>> TLSA records using matching type 0 (no hash used) and matching = type 1 >>>> (SHA-256), and SHOULD be able to create TLSA records using = matching >>>> type 2 (SHA-512). >>>=20 >>> this text is misleading. The draft doesn't say what it considers a = "DNS system", >>=20 >> Good point. >>=20 >>> but to avoid ambiguity it should be clarified that there's no = "conformance" >>> issue for the DNS name server but rather what one had in mind here = is >>> some provisioning entity that will (be used to) feed data into the = DNS zone. >>=20 >> Correct: that's is the entity where the conformance requirement = applies. >>=20 >>> The RRSet content, signed or unsigned, is transparent to the name = server as >>> per RFC 3597. >>=20 >> Yep. >>=20 >> Does "A system creating TLSA records that conforms to ... " work? Is = there some clearer wording we can use? >=20 > avoiding 'DNS system' helps clarifying the issue. =20 Good. We can do that in the next draft. > Whether the "system" or the > data should be the target of the MUST depends on what you intend to = achieve. It is the system. The intention is "if you say that X does TLSA, X must = be able to do A, B, and C". > Clearly, TLSA records could be crafted manually and would have to meet = the > syntax requirement. If there's some guidance or preference to be = expressed > for the actual use of one or the other format or some expectation = regarding > automated support for creating TLSA records, that may need more prose = and > i'm not sure the formal criteria for a MUST are met here. The intention is that X must do A, B, and C, not that there are = preferences. > Summary: your proposed wording is an improvement IMHO, but the text as = a whole > needs another pass. I've marshaled new wording for the next draft, and am happy to work on = it more. --Paul Hoffman From mrex@sap.com Wed Sep 28 10:24:25 2011 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 E07361F0C84 for ; Wed, 28 Sep 2011 10:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.761 X-Spam-Level: X-Spam-Status: No, score=-9.761 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_25=0.6, 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 ASnaleVf4u7B for ; Wed, 28 Sep 2011 10:24:24 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 53DB51F0C56 for ; Wed, 28 Sep 2011 10:24:23 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p8SHR3Yg020976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 28 Sep 2011 19:27:03 +0200 (MEST) From: Martin Rex Message-Id: <201109281727.p8SHR32A000308@fs4113.wdf.sap.corp> To: matt@mattmccutchen.net (Matt McCutchen) Date: Wed, 28 Sep 2011 19:27:03 +0200 (MEST) In-Reply-To: <1317224748.2975.49.camel@localhost> from "Matt McCutchen" at Sep 28, 11 08:45:48 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] #37: Additive assertion of server certificate 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, 28 Sep 2011 17:24:26 -0000 Matt McCutchen wrote: > > Richard L. Barnes wrote: > > > > > >>> I'd venture that I'm one of many server admins who would feel > > >>> much better cutting the complexity of PKIX completely out of the TLS > > >>> server authentication process. > > >> > > >> In the self-signed case, PKIX validation reduces to equality of > > >> certificates, so there's not really any complexity. Personally, I would prefer if TLSA records were clearly seperated in whether they are supposed to validate under the existing TLS X.509 PKI, i.e. verified against existing TAs from the TLS X.509 PKI, or whether they originate from DNS, and their trust is based only and entirely on DNSSEC. Feeding a self-signed server certificate to X.509 certificate path validation currently results in undefined behaviour with respect to specifications and implementation defined behaviour with respect to the installed base. X.509 specifies, that all self-signed certificates in the (prospective) certification path processed by the certificate path validation algorithm are to be (unconditionally) ignored. Taken literally, there could be arbitrary numbers of completely unrelated self-signed certificates in the (prospective) certification path, and path validation conforming to X.509-2008 would mean that they all get ignored -- with the result that path validation ends up with an empty path and can not verify anything at all. PKIX (rfc3280/5280) is written in a slightly different fashion and assumes that PKIX certificate path validation is simply not called with any self-signed certificates still present in the (prospective) certification path ("deus ex machina") and the PKIX algorithm for processing the (prospective) certificate path lacks the X.509 provision ignore self-signed certs. So neither provides a real answer to the question of how to process self-signed End Entity certificates. non-CA self-signed X.509v1 certs and non-CA self-signed X.509v3 certs with BasicConstraints "cA=TRUE" seem(!) to work with many TLS implementations when passed as both, trust anchor and within the prospective certification path, usually because the TA cert can be used to verify the signature on the path certificate according to the certificate processing rules. However, non-CA self-signed X.509v3 certs without BasicConstraints or with empty BasicConstraints (equals to cA=FALSE in ASN.1 DER) may not work in that usage scenario for some implementations, in case the PKIX implementation honours (self-imposed) attributes in TA certs during certificate processing. -Martin PS: (OT) > > > Unless you can document some details of the attack you're proposing > > above, I'm not really convinced that there's any additional attack > > surface here. > > The attack was just a thought; Martin Rex would probably have a better > idea if such a thing might be possible. (Ouch. I probably deserve some level of bad reputation due to my occasional bad temper. ;-) I really prefer discussions an abstract architecture level, but it turns out that is difficult (may take a long time) until all participants in a discussion are have formed a sufficiently coherent model that one does not talk past each other at a meta level. Depicting attacks may sometimes help to shortcut discussions, but should primarily be seen as indicators of (potential) problems. If a specific attack does not, or no longer work, it does not proof the absence of problems. From paul@xelerance.com Wed Sep 28 11:01:13 2011 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 632D511E8108 for ; Wed, 28 Sep 2011 11:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.5 X-Spam-Level: X-Spam-Status: No, score=-6.5 tagged_above=-999 required=5 tests=[AWL=0.099, 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 3fZq35Lda-xl for ; Wed, 28 Sep 2011 11:01:13 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id C57C211E8089 for ; Wed, 28 Sep 2011 11:00:29 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 17A30572F9; Wed, 28 Sep 2011 14:01:46 -0400 (EDT) Date: Wed, 28 Sep 2011 14:01:45 -0400 (EDT) From: Paul Wouters To: Matt McCutchen In-Reply-To: <1317224748.2975.49.camel@localhost> Message-ID: References: <061.a8eeecd5d3e79d55021946fbc77943e1@trac.tools.ietf.org> <1317181872.2975.13.camel@localhost> <444081ED-DF03-45E3-83FD-889EF53D6F03@bbn.com> <1317184098.2975.30.camel@localhost> <42D80BDE-458A-45F5-859C-CA955A6D7D4B@bbn.com> <1317224748.2975.49.camel@localhost> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dane@ietf.org Subject: Re: [dane] #37: Additive assertion of server certificate 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, 28 Sep 2011 18:01:13 -0000 On Wed, 28 Sep 2011, Matt McCutchen wrote: > These issues are all unlikely or of secondary importance, but they are > so easy to avoid by adding cert usage 3: "Exact certificate (or > SubjectPublicKeyInfo) asserted to be that of the authentic TLS server". > I would be surprised if WG consensus were against doing this. Certainly > WG consensus was not established to remove the functionality in > draft-ietf-dane-protocol-11. Plus, the TLS WG suggested to change my draft to use a new cert type containing just a SubjectPublicKeyInfo, in which case the PKIX cert contains just the public key, so following the "full PKIX" path on the client would likely generate all kinds of errors about missing fields and signatures. You can't blindly follow the 20 year old path anymore. This new cert type would also require DNSSEC as it contains no signatures whatsoever. Paul From paul.hoffman@vpnc.org Wed Sep 28 11:19:23 2011 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 0BD5E1F0CB6 for ; Wed, 28 Sep 2011 11:19:23 -0700 (PDT) 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 qx42Edn20zhd for ; Wed, 28 Sep 2011 11:19:22 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6901F0CAA for ; Wed, 28 Sep 2011 11:19:22 -0700 (PDT) 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 p8SIMAIj065869 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 28 Sep 2011 11:22:11 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1244.3) From: Paul Hoffman In-Reply-To: Date: Wed, 28 Sep 2011 11:22:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7C347DBA-9F7B-4EE1-A2FD-EC351DAFE1F8@vpnc.org> References: <061.a8eeecd5d3e79d55021946fbc77943e1@trac.tools.ietf.org> <1317181872.2975.13.camel@localhost> <444081ED-DF03-45E3-83FD-889EF53D6F03@bbn.com> <1317184098.2975.30.camel@localhost> <42D80BDE-458A-45F5-859C-CA955A6D7D4B@bbn.com> <1317224748.2975.49.camel@localhost> To: IETF DANE WG X-Mailer: Apple Mail (2.1244.3) Subject: Re: [dane] #37: Additive assertion of server certificate 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, 28 Sep 2011 18:19:23 -0000 On Sep 28, 2011, at 11:01 AM, Paul Wouters wrote: > On Wed, 28 Sep 2011, Matt McCutchen wrote: >=20 >> These issues are all unlikely or of secondary importance, but they = are >> so easy to avoid by adding cert usage 3: "Exact certificate (or >> SubjectPublicKeyInfo) asserted to be that of the authentic TLS = server". >> I would be surprised if WG consensus were against doing this. = Certainly >> WG consensus was not established to remove the functionality in >> draft-ietf-dane-protocol-11. >=20 > Plus, the TLS WG suggested to change my draft to use a new cert type > containing just a SubjectPublicKeyInfo, in which case the PKIX cert > contains just the public key, so following the "full PKIX" path > on the client would likely generate all kinds of errors about missing > fields and signatures. Quite true. If you actually move your proposal through the TLS WG or = individual submission, and the identifier is just the = SubjectPublicKeyInfo, the certificate usage 3 that Matt suggests above = would be a completely logical addition. > You can't blindly follow the 20 year old path anymore. This new cert = type > would also require DNSSEC as it contains no signatures whatsoever. Fully agree. --Paul Hoffman From paul@xelerance.com Wed Sep 28 11:21:28 2011 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 8AFA61F0CCC for ; Wed, 28 Sep 2011 11:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.502 X-Spam-Level: X-Spam-Status: No, score=-6.502 tagged_above=-999 required=5 tests=[AWL=0.097, 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 xaVEmML3HsKl for ; Wed, 28 Sep 2011 11:21:28 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id A7FBE1F0CCB for ; Wed, 28 Sep 2011 11:21:27 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 36A63572F9; Wed, 28 Sep 2011 14:22:44 -0400 (EDT) Date: Wed, 28 Sep 2011 14:22:43 -0400 (EDT) From: Paul Wouters To: "Richard L. Barnes" In-Reply-To: <001F15D5-0861-4CE2-8148-3EBC9B55C2B0@bbn.com> Message-ID: References: <061.a8eeecd5d3e79d55021946fbc77943e1@trac.tools.ietf.org> <1317181872.2975.13.camel@localhost> <444081ED-DF03-45E3-83FD-889EF53D6F03@bbn.com> <1317184098.2975.30.camel@localhost> <42D80BDE-458A-45F5-859C-CA955A6D7D4B@bbn.com> <1317224748.2975.49.camel@localhost> <001F15D5-0861-4CE2-8148-3EBC9B55C2B0@bbn.com> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dane@ietf.org Subject: Re: [dane] #37: Additive assertion of server certificate 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, 28 Sep 2011 18:21:28 -0000 On Wed, 28 Sep 2011, Richard L. Barnes wrote: > You seem to be missing the point that if PKIX libraries are broken, we're all screwed already. Even though OpenSSL, NSS, and the like have a non-trivial number of bugs, we seem to have gotten by with them for many years now. The PKIX problems that DANE addresses are all about asserting and limiting CAs, not about software. Can we pleas leave out these kind of arguments. They are just plain wrong. Because PKIX was broken back in 1995, it lead people to look into the KEY record which lead to DNSSEC more then 15 years later. Let's put the myth of "20 years of proven PKIX security" behind us please. It's a really bad self-sustaining argument. If you really believe this last year saw a "success" of PKIX, then perhaps we can just agree to disasgree, and all be accomodating of each other instead of making up arguments about the dangerous "added complexity" of 1 switch statement in the total PKIX processing code. RFC-3445 prevented those who were some of the early architects of DNSSEC to use it as alternative for PKIX, one of the reasons aside from protecting the DNS to add crypto to DNS. We are now looking at TLSA records, and it is wrong to again limit people who have no desire for PKIX in the last 15 years to again be ignored. >> Certainly >> WG consensus was not established to remove the functionality in >> draft-ietf-dane-protocol-11. > > There is WG consensus on the current approach, in the sense that the usage values in -11 map directly to the use cases in the use case document. And the use-cases document ignored some of our comments and said "deal with those in the dane protocol document". Make up your mind how to mapping works, don't change it to suit your needs. Stop sending the people who want DANE to be usable without PKIX in circles. We are not telling you to stop using PKIX, so stop telling is we have to use PKIX. Or to make it more concrete, define what "PKIX validation" and "PKIX-formatted certificates" means for a certificate type that just contains a DER encoded subjectPublicKeyInfo, so that Certificate Usage 2 makes sense and covers the case for using DANE without PKIX trust anchors. Is it really that dreadful to give us a single bit you will never want to use? Paul From paul.hoffman@vpnc.org Wed Sep 28 11:47:19 2011 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 07D1D1F0C6E for ; Wed, 28 Sep 2011 11:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.554 X-Spam-Level: X-Spam-Status: No, score=-103.554 tagged_above=-999 required=5 tests=[AWL=1.045, BAYES_00=-2.599, GB_I_INVITATION=-2, 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 sH-Hk5nUTIAY for ; Wed, 28 Sep 2011 11:47:18 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2459721F8D7C for ; Wed, 28 Sep 2011 11:47:18 -0700 (PDT) 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 p8SIo6Kj082693 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 28 Sep 2011 11:50:07 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1244.3) From: Paul Hoffman In-Reply-To: Date: Wed, 28 Sep 2011 11:50:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <061.a8eeecd5d3e79d55021946fbc77943e1@trac.tools.ietf.org> <1317181872.2975.13.camel@localhost> <444081ED-DF03-45E3-83FD-889EF53D6F03@bbn.com> <1317184098.2975.30.camel@localhost> <42D80BDE-458A-45F5-859C-CA955A6D7D4B@bbn.com> <1317224748.2975.49.camel@localhost> <001F15D5-0861-4CE2-8148-3EBC9B55C2B0@bbn.com> To: IETF DANE WG X-Mailer: Apple Mail (2.1244.3) Subject: Re: [dane] #37: Additive assertion of server certificate 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, 28 Sep 2011 18:47:19 -0000 On Sep 28, 2011, at 11:22 AM, Paul Wouters wrote: > Is it really that dreadful to give us a single bit you will never want = to use? Some of us *want* to use it, drama aside. My opinion, though, is that it = is inappropriate for it to be in the TLSA spec until it can be used in = TLS. Until we can say how it is used in TLS in an interoperable fashion, = putting it in TLSA is an invitation for confusion and non-interoperable = use, probably in an insecure fashion. FWIW, if TLSA looks like it will be finished before the TLS extension = is, I see no problem with the proposed TLS extension document also = defining the new TLSA certificate type at the same time. This is = sometimes done in other IETF WGs, where one RFC updates multiple IANA = registries. --Paul Hoffman From rbarnes@bbn.com Wed Sep 28 12:14:44 2011 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 777451F0CDA for ; Wed, 28 Sep 2011 12:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.562 X-Spam-Level: X-Spam-Status: No, score=-106.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 iI1OEa36rs4k for ; Wed, 28 Sep 2011 12:14:44 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id F2D551F0C62 for ; Wed, 28 Sep 2011 12:14:43 -0700 (PDT) Received: from ros-dhcp192-1-51-76.bbn.com ([192.1.51.76]:51210) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1R8zdL-000FaS-79; Wed, 28 Sep 2011 15:17:31 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Wed, 28 Sep 2011 15:17:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <079E0098-C7A3-4361-A559-1CE511A37590@bbn.com> References: <061.a8eeecd5d3e79d55021946fbc77943e1@trac.tools.ietf.org> <1317181872.2975.13.camel@localhost> <444081ED-DF03-45E3-83FD-889EF53D6F03@bbn.com> <1317184098.2975.30.camel@localhost> <42D80BDE-458A-45F5-859C-CA955A6D7D4B@bbn.com> <1317224748.2975.49.camel@localhost> To: Paul Wouters X-Mailer: Apple Mail (2.1084) Cc: dane@ietf.org Subject: Re: [dane] #37: Additive assertion of server certificate 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, 28 Sep 2011 19:14:44 -0000 >> These issues are all unlikely or of secondary importance, but they = are >> so easy to avoid by adding cert usage 3: "Exact certificate (or >> SubjectPublicKeyInfo) asserted to be that of the authentic TLS = server". >> I would be surprised if WG consensus were against doing this. = Certainly >> WG consensus was not established to remove the functionality in >> draft-ietf-dane-protocol-11. >=20 > Plus, the TLS WG suggested to change my draft to use a new cert type > containing just a SubjectPublicKeyInfo, in which case the PKIX cert > contains just the public key, so following the "full PKIX" path > on the client would likely generate all kinds of errors about missing > fields and signatures. Note that this would no longer be a "PKIX cert". It would just be an = SPKI. So since the existing usage types are predicated on certs, you = would need new usage types anyway. --Richard= From warren@kumari.net Wed Sep 28 14:00:06 2011 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 6A5701F0D1B for ; Wed, 28 Sep 2011 14:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.719 X-Spam-Level: X-Spam-Status: No, score=-104.719 tagged_above=-999 required=5 tests=[AWL=1.880, 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 g4EJh6LauOtC for ; Wed, 28 Sep 2011 14:00:06 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id E2C291F0D19 for ; Wed, 28 Sep 2011 14:00:05 -0700 (PDT) Received: from dhcp-172-19-119-117.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id B61F81B4002B; Wed, 28 Sep 2011 17:02:53 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: <076.bdd0467de056ddca69582bc0104dce57@trac.tools.ietf.org> Date: Wed, 28 Sep 2011 17:02:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <061.add9f922b5dfb2db7544981f78552e7e@trac.tools.ietf.org> <076.bdd0467de056ddca69582bc0104dce57@trac.tools.ietf.org> To: "dane issue tracker" X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-dane-protocol@tools.ietf.org, dane@ietf.org Subject: Re: [dane] #33: Publish enough information for the client to achieve the security of its favorite digest 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, 28 Sep 2011 21:00:06 -0000 On Sep 28, 2011, at 11:59 AM, dane issue tracker wrote: > #33: Publish enough information for the client to achieve the security = of its > favorite digest >=20 >=20 > Comment (by matt@=85): >=20 > So... in list discussion, I think I successfully answered all the > objections except the subjective one of "complexity". Are we ready = for a > preliminary consensus call? =20 Well, it would appear that you have decided to start one.... > I would ask that each person indicate, for > each of the three proposed solutions, whether they prefer it ''to the > status quo''. If you want this problem solved, please do not -1 a > solution simply because you prefer a different solution, or we are at = risk > of splitting the vote and not getting a solution at all. And if folk do wish to show support for any of the 3 solutions I ask = that they do it by Friday 13:00UTC. Explicitly stating that you do not wish to support any of the 3 would = also be helpful (even if you have already said do in the thread... W >=20 > --=20 > ----------------------+----------------------------------------- > Reporter: matt@=85 | Owner: draft-ietf-dane-protocol@=85 > Type: defect | Status: new > Priority: major | Milestone: > Component: protocol | Version: > Severity: - | Resolution: > Keywords: | > ----------------------+----------------------------------------- >=20 > Ticket URL: = > dane >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From paul.hoffman@vpnc.org Wed Sep 28 16:28:13 2011 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 2650C11E811C for ; Wed, 28 Sep 2011 16:28:13 -0700 (PDT) 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 s3tDHA+Q3tST for ; Wed, 28 Sep 2011 16:28:12 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 88E1F11E8088 for ; Wed, 28 Sep 2011 16:28:12 -0700 (PDT) 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 p8SNMUlH035853 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 28 Sep 2011 16:22:30 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=windows-1252 From: Paul Hoffman In-Reply-To: Date: Wed, 28 Sep 2011 16:22:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <061.add9f922b5dfb2db7544981f78552e7e@trac.tools.ietf.org> <076.bdd0467de056ddca69582bc0104dce57@trac.tools.ietf.org> To: Warren Kumari X-Mailer: Apple Mail (2.1244.3) Cc: IETF DANE WG Subject: Re: [dane] #33: Publish enough information for the client to achieve the security of its favorite digest 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, 28 Sep 2011 23:28:13 -0000 On Sep 28, 2011, at 2:02 PM, Warren Kumari wrote: > And if folk do wish to show support for any of the 3 solutions I ask = that they do it by Friday 13:00UTC. >=20 > Explicitly stating that you do not wish to support any of the 3 would = also be helpful (even if you have already said do in the thread... I do not support any of the three, for the reasons given before. --Paul Hoffman From matt@mattmccutchen.net Wed Sep 28 19:50:57 2011 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 5CBBA1F0D23 for ; Wed, 28 Sep 2011 19:50:57 -0700 (PDT) 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 PO8bXVb2nnmC for ; Wed, 28 Sep 2011 19:50:56 -0700 (PDT) Received: from homiemail-a5.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id CD8BF1F0C3E for ; Wed, 28 Sep 2011 19:50:56 -0700 (PDT) Received: from homiemail-a5.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a5.g.dreamhost.com (Postfix) with ESMTP id CBE6670407B for ; Wed, 28 Sep 2011 19:53:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; q=dns; s= mattmccutchen.net; b=gjhz/Zjl3rrm18Lxrhc3eJ4g1xWTCddRToa97tXvE3t nJ2hD7aQxCz+G9S2B4TjD92Wst9jAdd2gx8pcFV5weZ7DiuOnNV4mB0KHG7taZAT kivj+ITKRC7+l+YSw7IGpqlAjf230xZA5X1hy8zQXvqg/Wk1gsK9ApJImKDiie+E = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; s= mattmccutchen.net; bh=wZRg2dCsYDVZKeZJtgSK6oVcTk8=; b=NiQTZY6qCC UMBOFfXFQHDPBjYhLsoLF1dCVOtSPAL187EbNU44V99GofzAcx4oeRdy3AM8o0RG D9XVGqGHi/k6vP9BYVqZ5kxXHfBgp5KsBcegh2YRdbcxSKk7TmRoZgXLmkXrXzOj d2ys38U8MvzHylZvGxC4ACMqEhePXC9/I= Received: from [IPv6:::1] (ps7180.dreamhost.com [75.119.218.76]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a5.g.dreamhost.com (Postfix) with ESMTPSA id B44C870407A for ; Wed, 28 Sep 2011 19:53:46 -0700 (PDT) From: Matt McCutchen To: dane@ietf.org Date: Wed, 28 Sep 2011 19:53:39 -0700 In-Reply-To: References: <061.add9f922b5dfb2db7544981f78552e7e@trac.tools.ietf.org> <076.bdd0467de056ddca69582bc0104dce57@trac.tools.ietf.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 Content-Transfer-Encoding: 7bit Message-ID: <1317264820.2975.58.camel@localhost> Mime-Version: 1.0 Subject: Re: [dane] #33: Publish enough information for the client to achieve the security of its favorite digest 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, 29 Sep 2011 02:50:57 -0000 On Wed, 2011-09-28 at 17:02 -0400, Warren Kumari wrote: > And if folk do wish to show support for any of the 3 solutions I ask that they do it by Friday 13:00UTC. Man, that is a short consensus call. For others' convenience in replying: 1. All digests of one cert in one RR 2. Cartesian product requirement 3. Group ID -- Matt From matt@mattmccutchen.net Wed Sep 28 19:52:04 2011 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 268FA11E80F9 for ; Wed, 28 Sep 2011 19:52:04 -0700 (PDT) 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=[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 EHlqMSyjtfXz for ; Wed, 28 Sep 2011 19:52:03 -0700 (PDT) Received: from homiemail-a6.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id BA2F311E80D6 for ; Wed, 28 Sep 2011 19:52:03 -0700 (PDT) Received: from homiemail-a6.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTP id 9D1F1598083 for ; Wed, 28 Sep 2011 19:54:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:date:references:content-type:content-transfer-encoding :message-id:mime-version; q=dns; s=mattmccutchen.net; b=EDA8Q0lE VJMKbLgPQxsdCujtIkBRTAcvtGthSfdrH/GG8QcLacCqN7vrW2amlDzVWMrG77hk 1e/AQ057QFHOvAwbt0TMHq/P7r132O+jgYr3h20oUSSYf9V7GtA0z2KMJTz0jQBn 72tloevwx6QAhzC+YCm0Rk588RtN+xs6p9Y= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:date:references:content-type :content-transfer-encoding:message-id:mime-version; s= mattmccutchen.net; bh=dEHeGMN77EEK1gRhmM13esGIezw=; b=Pp6qs4D/GC n1X/2W+Z96Zxnlq5RBbgHHgkIA4y7bWjWDnhqIItWurRZCea3oYpqvwUfEBpW9su kWd5bGjT0/2pwDSHCTIdhiQP4T864I+wYW9mlRZD6gtypXTIJrkHCm15aerf1dtE csBEQ2EJXuL08XH+oai1i+tnvJhwSuTOY= Received: from [IPv6:::1] (ps7180.dreamhost.com [75.119.218.76]) (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 873CD59807A for ; Wed, 28 Sep 2011 19:54:53 -0700 (PDT) From: Matt McCutchen To: dane@ietf.org Date: Wed, 28 Sep 2011 19:54:46 -0700 References: <061.add9f922b5dfb2db7544981f78552e7e@trac.tools.ietf.org> <076.bdd0467de056ddca69582bc0104dce57@trac.tools.ietf.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 Content-Transfer-Encoding: 7bit Message-ID: <1317264886.2975.59.camel@localhost> Mime-Version: 1.0 Subject: Re: [dane] #33: Publish enough information for the client to achieve the security of its favorite digest 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, 29 Sep 2011 02:52:04 -0000 And this should surprise no one: 1. All digests of one cert in one RR: +1 2. Cartesian product requirement: +1 3. Group ID: +1 -- Matt From mrex@sap.com Wed Sep 28 20:20:28 2011 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 2C6A221F8DBB for ; Wed, 28 Sep 2011 20:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.064 X-Spam-Level: X-Spam-Status: No, score=-10.064 tagged_above=-999 required=5 tests=[AWL=0.185, 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 fX+iuHGf232n for ; Wed, 28 Sep 2011 20:20:27 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 25AAC21F8DBA for ; Wed, 28 Sep 2011 20:20:26 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p8T3NE7w004853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Sep 2011 05:23:14 +0200 (MEST) From: Martin Rex Message-Id: <201109290323.p8T3NEp8004786@fs4113.wdf.sap.corp> To: matt@mattmccutchen.net (Matt McCutchen) Date: Thu, 29 Sep 2011 05:23:14 +0200 (MEST) In-Reply-To: <1317264820.2975.58.camel@localhost> from "Matt McCutchen" at Sep 28, 11 07:53:39 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] #33: Publish enough information for the client to 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, 29 Sep 2011 03:20:28 -0000 Matt McCutchen wrote: > > Warren Kumari wrote: > > > > And if folk do wish to show support for any of the 3 solutions > > I ask that they do it by Friday 13:00UTC. > > For others' convenience in replying: -.5 1. All digests of one cert in one RR -.5 2. Cartesian product requirement -.5 3. Group ID (yes, that's negatives) Based on how *I* interpret NIST SP800-57 (Table3 pg.64 + Table4 pg.66) the use of SHA-256 (and SHA-256 alone) is expected safe until at least 2030. With that in mind, *I* am fine with no strong hash agility in place in order to cut down on complexity. Repeating my previous conclusion (at the end) of this message: http://www.ietf.org/mail-archive/web/dane/current/msg03459.html But as long as lots of the crypto stuff that is involved (TLS and DNSSEC) has SHA1 all over the place and no realistic perspective to move those protocols to something _stronger_ than SHA-256 anywhere soon, support for allegedly stronger hash algorithms in DANE than SHA-256, such as SHA-512 or SHA-3, amounts to bikeshedding. -Martin From matt@mattmccutchen.net Wed Sep 28 20:42:02 2011 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 098051F0C46 for ; Wed, 28 Sep 2011 20:42:02 -0700 (PDT) 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 9zu4w+a9UhZ1 for ; Wed, 28 Sep 2011 20:42:01 -0700 (PDT) Received: from homiemail-a2.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4A91F0C45 for ; Wed, 28 Sep 2011 20:42:01 -0700 (PDT) Received: from homiemail-a2.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a2.g.dreamhost.com (Postfix) with ESMTP id 585F7280069; Wed, 28 Sep 2011 20:44:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=vif5HBbk9FLc+KMY6c+3dYx8TxnD3Jcvb71zB4tPE2F o4SyUnsy4EL3Eu8HtwkpLteVV15zl0kHiP1QKtvOdFhgrYYywQZVSzVCQDLow34Q rGzgkIkjU7vKhj2MoRL8Z0mJF1AzHoN41LphbNaV1WVZlJxMOgESotc40VCnz2iM = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=H8GhR7Yq9/7x3HedyjvSq7QKSHw=; b=jF4K1NndKE YTc7h7bznbihknKR7oQiSFg3c2HgCMI3yJPyTXJW8xTpizddvB0KgrxIFx+EEOVl +A4fFJPgw02+I7ehIUDhuSgdUkypadTIjune/8AtcwEKtemQt575jPbRJ8CiE3tD utsBZs3wutGlo1gNufFxRz7hfaGLyLOxY= 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-a2.g.dreamhost.com (Postfix) with ESMTPSA id 1B683280062; Wed, 28 Sep 2011 20:44:51 -0700 (PDT) From: Matt McCutchen To: Martin Rex In-Reply-To: <201109290323.p8T3NEp8004786@fs4113.wdf.sap.corp> References: <201109290323.p8T3NEp8004786@fs4113.wdf.sap.corp> Content-Type: text/plain; charset="UTF-8" Date: Wed, 28 Sep 2011 20:44:39 -0700 Message-ID: <1317267879.2975.61.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 3.0.3 Content-Transfer-Encoding: 7bit Cc: dane@ietf.org Subject: Re: [dane] #33: Publish enough information for the client to 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, 29 Sep 2011 03:42:02 -0000 On Thu, 2011-09-29 at 05:23 +0200, Martin Rex wrote: > Based on how *I* interpret NIST SP800-57 (Table3 pg.64 + Table4 pg.66) > the use of SHA-256 (and SHA-256 alone) is expected safe until at least 2030. > > With that in mind, *I* am fine with no strong hash agility in place > in order to cut down on complexity. If that is the case, why support multiple hash algorithms at all? Just so Russia can use GOST? We either will or will not need to move away from SHA-256 during the lifetime of DANE. I do not see the situation in which the halfway job of algorithm agility we have now makes sense. -- Matt From matt@mattmccutchen.net Thu Sep 29 00:16:59 2011 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 60B8A21F8B0A for ; Thu, 29 Sep 2011 00:16:59 -0700 (PDT) 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=[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 9wD9A9E+kt0n for ; Thu, 29 Sep 2011 00:16:58 -0700 (PDT) Received: from homiemail-a61.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id C330021F8B09 for ; Thu, 29 Sep 2011 00:16:58 -0700 (PDT) Received: from homiemail-a61.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a61.g.dreamhost.com (Postfix) with ESMTP id 2F2C357806C; Thu, 29 Sep 2011 00:19:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; q=dns; s= mattmccutchen.net; b=fC4g0GOJSBuegTkSdZxsWMueCiQeDIzzSxJHgEAAVon fsBNNd7YCU1cAVVjCdJf1iLGJctl2g5ZgXrZWuauHfsqc9dMCzY4r9egOJrn6gG7 9khXxqWWZBKYVwldKKd4jWNSRqPksJrQmYW04thZs1wwiuOsOwzP4DgUrCfhsw1Q = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; s= mattmccutchen.net; bh=fCPUXq4/wgWyOz8CJJJI8KMlnSM=; b=SUwm/lW5kk 1LWWLAr4ioG4eYa/n4ubokaQHyPtT/o04KP6djpJaZj23xc0xRvIG+M1+oCWn3gG gjJ5IU2RX8ruNcZ8LmerMkOS6n4dpfrGTWcgKMCEJLLmCnJN7JD8DuZutROpYmBG baAkVJZHWiGg5C803oTHzuH48ieS+6JcA= 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-a61.g.dreamhost.com (Postfix) with ESMTPSA id 05AC7578059; Thu, 29 Sep 2011 00:19:48 -0700 (PDT) From: Matt McCutchen To: Jim Schaad Date: Thu, 29 Sep 2011 00:19:47 -0700 In-Reply-To: <019001cc7e6d$6934ba20$3b9e2e60$@augustcellars.com> References: <201109290323.p8T3NEp8004786@fs4113.wdf.sap.corp> <1317267879.2975.61.camel@localhost> <019001cc7e6d$6934ba20$3b9e2e60$@augustcellars.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 Content-Transfer-Encoding: 7bit Message-ID: <1317280789.1974.4.camel@localhost> Mime-Version: 1.0 Cc: dane@ietf.org Subject: Re: [dane] #33: Publish enough information for the client to 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, 29 Sep 2011 07:16:59 -0000 On Wed, 2011-09-28 at 23:02 -0700, Jim Schaad wrote: > You may not think it makes sense, however some of us do. Care to explain, or are we just reduced to a tug of votes? For some complexity, you buy the ability to drop a weak algorithm, gaining security against new servers and breaking against old ones, while for slightly more complexity, you can gain the security against the new servers without breaking against the old ones. That's what it comes down to. I guess depending on how you evaluate complexity, the first approach could come out as better. I am disappointed though. -- Matt From matt@mattmccutchen.net Thu Sep 29 00:20:05 2011 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 0716821F8B5E for ; Thu, 29 Sep 2011 00:20:05 -0700 (PDT) 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=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2] 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 bNvkmfqs9QPp for ; Thu, 29 Sep 2011 00:20:04 -0700 (PDT) Received: from homiemail-a6.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 6728B21F8B46 for ; Thu, 29 Sep 2011 00:20:04 -0700 (PDT) Received: from homiemail-a6.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTP id E06E459807D; Thu, 29 Sep 2011 00:22:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; q=dns; s= mattmccutchen.net; b=d5f8NONtxzgZUoXz9geDPQ/K8OFGA8lkMgtfOy33Ssx ggfJVjvdWkYD9MGOfYtD866N7rbdt2KQZcJ8fmpMx0p5lZagqEMZStC9+ClGY6Fe Nk2HkGfoWSSIzwaP2GYH9NJtP/9ZIn9OBk/ZaX0cQoDXf76rWXr2NW92pFoTbX5U = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; s= mattmccutchen.net; bh=8lO+EEanZwgxoe5VHRhaAhSczWw=; b=c8EZgqnK3+ 3bIiw1tPdS/WRt5Emxzftwk5Qu8oJmEUCUzZSS2YwQib4ohOaCw08vHvL+Pe/X7r o8pCUtVzYuLNzKprl+FEeQPiZV7bNPEMLEp10yZoOo7W8ZJEcu3qdLxOdYA+Gv1t ojggcd+pgr2RN6OaZLp3mq9myy3A4V7WI= 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 A62E1598070; Thu, 29 Sep 2011 00:22:54 -0700 (PDT) From: Matt McCutchen To: Paul Hoffman Date: Thu, 29 Sep 2011 00:22:48 -0700 In-Reply-To: References: <061.a8eeecd5d3e79d55021946fbc77943e1@trac.tools.ietf.org> <1317181872.2975.13.camel@localhost> <444081ED-DF03-45E3-83FD-889EF53D6F03@bbn.com> <1317184098.2975.30.camel@localhost> <42D80BDE-458A-45F5-859C-CA955A6D7D4B@bbn.com> <1317224748.2975.49.camel@localhost> <001F15D5-0861-4CE2-8148-3EBC9B55C2B0@bbn.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 Content-Transfer-Encoding: 7bit Message-ID: <1317280974.1974.7.camel@localhost> Mime-Version: 1.0 Cc: IETF DANE WG Subject: Re: [dane] #37: Additive assertion of server certificate 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, 29 Sep 2011 07:20:05 -0000 On Wed, 2011-09-28 at 11:50 -0700, Paul Hoffman wrote: > On Sep 28, 2011, at 11:22 AM, Paul Wouters wrote: > > > Is it really that dreadful to give us a single bit you will never want to use? > > Some of us *want* to use it, drama aside. My opinion, though, is that > it is inappropriate for it to be in the TLSA spec until it can be used > in TLS. Until we can say how it is used in TLS in an interoperable > fashion, putting it in TLSA is an invitation for confusion and > non-interoperable use, probably in an insecure fashion. There are two orthogonal bits; please do not confuse them: (a) Putative cert usage 3, "exact server credential" additive + restrictive association. (b) SubjectPublicKeyInfo selector. Your objection above is to (b), while ticket #37 is asking for (a). I believe Paul Wouters is asking for (a) as well and the mention of SubjectPublicKeyInfo was incidental. -- Matt From matt@mattmccutchen.net Thu Sep 29 00:21:49 2011 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 DDDA221F8B7F for ; Thu, 29 Sep 2011 00:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.641 X-Spam-Level: X-Spam-Status: No, score=-2.641 tagged_above=-999 required=5 tests=[AWL=-0.042, 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 yAzZV8WJGQ+Q for ; Thu, 29 Sep 2011 00:21:49 -0700 (PDT) Received: from homiemail-a60.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 575F321F8AF1 for ; Thu, 29 Sep 2011 00:21:49 -0700 (PDT) Received: from homiemail-a60.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a60.g.dreamhost.com (Postfix) with ESMTP id 98EE23BC070; Thu, 29 Sep 2011 00:24:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; q=dns; s= mattmccutchen.net; b=jm/b4Y4OPncaO9VlAqy6gaLEQyMgZIgpl7IJCqGDH9c Vam5zNFbZ4WVYVCpFr2xBhisHZet4a7A01rJbQQEI4d3COoEAiUKPGHtLkbqkUNW h2gCgMJZxAZe8lRxi1FMxBSSFzDf7pyp2I6zh8wQATL/DaZP+g4kZpPNUnogcOeo = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; s= mattmccutchen.net; bh=rl48eEgYNcaVYe+fhW4PoxqueHY=; b=Mp/aC6ILPc /bTSX8gGolryJtrc2Ww36N+ULZaiI7oYXfKS2n5QudNlHD85768zdENT4V74ga33 kqsjrZuvGBU7VIAsxzgHZhYo5hBQqC+8kbAV/0aw7YpSAGNy02AM+4qR7saElGLx JnUKXPe4T/MMNxhOPcni9/xHLsXqB5F74= 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-a60.g.dreamhost.com (Postfix) with ESMTPSA id 5B6463BC06D; Thu, 29 Sep 2011 00:24:39 -0700 (PDT) From: Matt McCutchen To: "Richard L. Barnes" Date: Thu, 29 Sep 2011 00:24:38 -0700 In-Reply-To: <001F15D5-0861-4CE2-8148-3EBC9B55C2B0@bbn.com> References: <061.a8eeecd5d3e79d55021946fbc77943e1@trac.tools.ietf.org> <1317181872.2975.13.camel@localhost> <444081ED-DF03-45E3-83FD-889EF53D6F03@bbn.com> <1317184098.2975.30.camel@localhost> <42D80BDE-458A-45F5-859C-CA955A6D7D4B@bbn.com> <1317224748.2975.49.camel@localhost> <001F15D5-0861-4CE2-8148-3EBC9B55C2B0@bbn.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 Content-Transfer-Encoding: 7bit Message-ID: <1317281079.1974.9.camel@localhost> Mime-Version: 1.0 Cc: dane@ietf.org Subject: Re: [dane] #37: Additive assertion of server certificate 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, 29 Sep 2011 07:21:50 -0000 On Wed, 2011-09-28 at 12:40 -0400, Richard L. Barnes wrote: > >>> You are confusing PKIX and TLS. Practically, TLS libraries support > >>> extracting the server public key from any cert, self-signed or not. > >>> But server authentication for self-signed certs is hardly ever achieved > >>> by the code path of "PKIX validation with a trust anchor" to which DANE > >>> cert usage 2 refers, so one cannot claim that this approach is well > >>> tested for use in DANE. E.g., in Firefox, one would mark the server > >>> cert as CERTDB_TRUSTED in NSS or use a PSM cert override; I doubt that > >>> marking the cert as CERTDB_TRUSTED_CA would work. > >> > >> I'm not confusing PKIX and TLS. The two are intertwined in the notion of a "self-signed server cert". > >> > >> A type 2 certificate does not actually map to CERTDB_TRUSTED, since IIRC that mark > > > > Please finish? > > Sorry, emailing before coffee. I was going to say that IIRC, the > CERTDB_TRUSTED and CERTDB_TRUSTED_CA marks apply across all domains, > so they're not constrained in the same way as a type 2 TLSA record is > to apply to a single domain only. Yes of course, you would need name constraints or (more likely) to use an alternative set of marks for the single validation operation. I was just making the point that CERTDB_TRUSTED and CERTDB_TRUSTED_CA are different. -- Matt From kent@bbn.com Thu Sep 29 00:41:44 2011 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 29DB421F8D14 for ; Thu, 29 Sep 2011 00:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.555 X-Spam-Level: X-Spam-Status: No, score=-106.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 q9KuN4pSqG4y for ; Thu, 29 Sep 2011 00:41:43 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id A5E1C21F8D06 for ; Thu, 29 Sep 2011 00:41:43 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:36214 helo=[196.40.177.154]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1R9BIH-000LuF-Pa for dane@ietf.org; Thu, 29 Sep 2011 03:44:34 -0400 Mime-Version: 1.0 Message-Id: Date: Thu, 29 Sep 2011 03:44:18 -0400 To: dane@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: Re: [dane] #33: Publish enough information for the client to achieve the security of its favorite digest 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, 29 Sep 2011 07:41:44 -0000 I am not in favor of any of these three options for dealing with hash alg agility. Steve From warren@kumari.net Thu Sep 29 06:29:23 2011 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 AC23E21F8C4D for ; Thu, 29 Sep 2011 06:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.755 X-Spam-Level: X-Spam-Status: No, score=-104.755 tagged_above=-999 required=5 tests=[AWL=1.844, 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 XZpTJ5V7yXHS for ; Thu, 29 Sep 2011 06:29:23 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id EBB5021F8C44 for ; Thu, 29 Sep 2011 06:29:22 -0700 (PDT) Received: from dhcp-172-19-119-117.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 34D261B4001D; Thu, 29 Sep 2011 09:32:11 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <1317264820.2975.58.camel@localhost> Date: Thu, 29 Sep 2011 09:32:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8C0CD951-CEC6-4313-A3FC-A325D9BC558A@kumari.net> References: <061.add9f922b5dfb2db7544981f78552e7e@trac.tools.ietf.org> <076.bdd0467de056ddca69582bc0104dce57@trac.tools.ietf.org> <1317264820.2975.58.camel@localhost> To: Matt McCutchen X-Mailer: Apple Mail (2.1084) Cc: dane@ietf.org Subject: Re: [dane] #33: Publish enough information for the client to achieve the security of its favorite digest 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, 29 Sep 2011 13:29:23 -0000 On Sep 28, 2011, at 10:53 PM, Matt McCutchen wrote: > On Wed, 2011-09-28 at 17:02 -0400, Warren Kumari wrote: >> And if folk do wish to show support for any of the 3 solutions I ask = that they do it by Friday 13:00UTC. >=20 > Man, that is a short consensus call. If you had spoken to the chairs before kicking this off.... But I realize I'm being petty, so fine, lets extend it till Wednesday, = that will be 7 days. W > =20 >=20 > For others' convenience in replying: >=20 > 1. All digests of one cert in one RR > 2. Cartesian product requirement > 3. Group ID >=20 > --=20 > Matt >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 From ondrej.sury@nic.cz Thu Sep 29 06:46:29 2011 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 4725F21F8B18 for ; Thu, 29 Sep 2011 06:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2, 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 tEJa6+tp5WNG for ; Thu, 29 Sep 2011 06:46:24 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 2963E21F8B16 for ; Thu, 29 Sep 2011 06:46:24 -0700 (PDT) Received: from kimac.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 166272A2D6E; Thu, 29 Sep 2011 15:49:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1317304154; bh=oJLa9CySnD16uUU+lasqIlXnkWxmJT8moADZuMh1Yg8=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=cDssqyvHLCihR9WzrZHO0G+Lt6HU8IaeWU8nxkB42TK83H/w1nCnov5jbB8kSdcW1 3PnxFJ+Bbqy4JKGiJh64kdUuxfl0tsGKwfZjvDZoc7kaMtUSWlwaghjbior2AZmYCG L0qN6pF3WAyzT/GDlb0OgmBmDN5pS3pPPcx6oDrc= Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <1317280974.1974.7.camel@localhost> Date: Thu, 29 Sep 2011 15:49:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9F73DA44-F065-4DCE-A89D-6C929569F364@nic.cz> References: <061.a8eeecd5d3e79d55021946fbc77943e1@trac.tools.ietf.org> <1317181872.2975.13.camel@localhost> <444081ED-DF03-45E3-83FD-889EF53D6F03@bbn.com> <1317184098.2975.30.camel@localhost> <42D80BDE-458A-45F5-859C-CA955A6D7D4B@bbn.com> <1317224748.2975.49.camel@localhost> <001F15D5-0861-4CE2-8148-3EBC9B55C2B0@bbn.com> <1317280974.1974.7.camel@localhost> To: Matt McCutchen , Paul Wouters X-Mailer: Apple Mail (2.1244.3) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Paul Hoffman , IETF DANE WG Subject: Re: [dane] #37: Additive assertion of server certificate 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, 29 Sep 2011 13:46:29 -0000 On 29. 9. 2011, at 9:22, Matt McCutchen wrote: > On Wed, 2011-09-28 at 11:50 -0700, Paul Hoffman wrote: >> On Sep 28, 2011, at 11:22 AM, Paul Wouters wrote: >>=20 >>> Is it really that dreadful to give us a single bit you will never = want to use? >>=20 >> Some of us *want* to use it, drama aside. My opinion, though, is that >> it is inappropriate for it to be in the TLSA spec until it can be = used >> in TLS. Until we can say how it is used in TLS in an interoperable >> fashion, putting it in TLSA is an invitation for confusion and >> non-interoperable use, probably in an insecure fashion. >=20 > There are two orthogonal bits; please do not confuse them: >=20 > (a) Putative cert usage 3, "exact server credential" additive + > restrictive association. >=20 > (b) SubjectPublicKeyInfo selector. >=20 > Your objection above is to (b), while ticket #37 is asking for (a). I > believe Paul Wouters is asking for (a) as well and the mention of > SubjectPublicKeyInfo was incidental. I would prefer that you (or Paul) could propose a text to prevent this kind of confusion and also so WG can vote on the specific proposal. This discussion starts to lead nowhere and we are going in circles. 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 jakob@kirei.se Thu Sep 29 06:53:39 2011 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 8857721F8D66 for ; Thu, 29 Sep 2011 06:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.646 X-Spam-Level: X-Spam-Status: No, score=-0.646 tagged_above=-999 required=5 tests=[AWL=0.052, 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 9UAuty0xBiKe for ; Thu, 29 Sep 2011 06:53:35 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id D96F821F8D1D for ; Thu, 29 Sep 2011 06:53:34 -0700 (PDT) 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=vL3I6E8cjGNNfbVbdgCKOrTkObbhg+yDhXtYRAWzu8M=; b=e5AdDmdukoUwdf08lo6NdpbwZT6xoIywcWlGJcmZWzz4UPKsYNdqd7BpuiePf6YfuJbtYlXzy84JH 0vOoUYa1Z3zxBUicVO/6u6tgsgROBKW0pvSWj4+NtiUaYO4BB+QsuJkWK7n8vH9MrbKIaOu3b58+d7 yeU9j+GZDWUc/ofw= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Thu, 29 Sep 2011 15:56:23 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=windows-1252 From: Jakob Schlyter In-Reply-To: Date: Thu, 29 Sep 2011 15:56:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <061.add9f922b5dfb2db7544981f78552e7e@trac.tools.ietf.org> <076.bdd0467de056ddca69582bc0104dce57@trac.tools.ietf.org> To: Warren Kumari X-Mailer: Apple Mail (2.1244.3) Cc: draft-ietf-dane-protocol@tools.ietf.org, DANE WG , dane issue tracker Subject: Re: [dane] #33: Publish enough information for the client to achieve the security of its favorite digest 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, 29 Sep 2011 13:53:39 -0000 On 28 sep 2011, at 23:02, Warren Kumari wrote: > And if folk do wish to show support for any of the 3 solutions I ask = that they do it by Friday 13:00UTC. no support from me. jakob From rbarnes@bbn.com Thu Sep 29 06:56:34 2011 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 CDA6721F8D71 for ; Thu, 29 Sep 2011 06:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.562 X-Spam-Level: X-Spam-Status: No, score=-106.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 OScL3hO3D9QB for ; Thu, 29 Sep 2011 06:56:34 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id EB0E921F8D70 for ; Thu, 29 Sep 2011 06:56:33 -0700 (PDT) Received: from [192.1.255.224] (port=55350 helo=col-dhcp-192-1-255-224.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1R9H8w-0000Ee-Bg; Thu, 29 Sep 2011 09:59:18 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Thu, 29 Sep 2011 09:59:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6AFD9333-B910-4534-BAB0-93C9A3096B42@bbn.com> References: <061.add9f922b5dfb2db7544981f78552e7e@trac.tools.ietf.org> <076.bdd0467de056ddca69582bc0104dce57@trac.tools.ietf.org> To: Jakob Schlyter X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-dane-protocol@tools.ietf.org, dane issue tracker , DANE WG Subject: Re: [dane] #33: Publish enough information for the client to achieve the security of its favorite digest 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, 29 Sep 2011 13:56:34 -0000 +1 (-3?) On Sep 29, 2011, at 9:56 AM, Jakob Schlyter wrote: > On 28 sep 2011, at 23:02, Warren Kumari wrote: >=20 >> And if folk do wish to show support for any of the 3 solutions I ask = that they do it by Friday 13:00UTC. >=20 > no support from me. >=20 > jakob >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From ondrej.sury@nic.cz Thu Sep 29 07:08:02 2011 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 D9DA321F8D89 for ; Thu, 29 Sep 2011 07:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.328 X-Spam-Level: X-Spam-Status: No, score=-1.328 tagged_above=-999 required=5 tests=[AWL=0.372, 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 r99RMUNPbjQT for ; Thu, 29 Sep 2011 07:07:56 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 2420221F8D87 for ; Thu, 29 Sep 2011 07:07:56 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:ccc0:dc2a:c0d8:f842] (unknown [IPv6:2001:1488:ac14:1400:ccc0:dc2a:c0d8:f842]) by mail.nic.cz (Postfix) with ESMTPSA id D42852A0DCC; Thu, 29 Sep 2011 16:10:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1317305446; bh=n9QtDDv4Kla7R6SMNVdf1AObQVuWTqrcB40ef+PCMkU=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Sk4L2AEHGivkTRwCi8lLPfeXPosjtjZ1ehhHVmfxw7hfSYsFZP5Tw9bQlqQsyTftp NNObBrJcUrM1+soK4Tu3nEBxRBIDJXK0EWwFNREu3VjdOJfQ0JlX9YMpzdiircUc6j FKTu2KMsUsQpIwnoN4Wxh/3CFE0gsARH4jfoTnQ4= Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <1316754637.1941.136.camel@localhost> Date: Thu, 29 Sep 2011 16:10:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <513EED68-99A7-47DB-9ED1-55CFD7C9BF4B@nic.cz> References: <061.add9f922b5dfb2db7544981f78552e7e@trac.tools.ietf.org> <6EB199FD-63B2-4FEA-88ED-67DB559148A0@bbn.com> <670A864B-567A-4351-AB6D-0A373AF66B9B@kumari.net> <1316658906.1941.63.camel@localhost> <042EE416-702E-47DF-8748-E5AD3E6583E1@vpnc.org> <1316754637.1941.136.camel@localhost> To: Matt McCutchen X-Mailer: Apple Mail (2.1244.3) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: DANE WG Subject: Re: [dane] #33: Publish enough information for the client to achieve the security of its favorite digest 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, 29 Sep 2011 14:08:03 -0000 On 23. 9. 2011, at 7:10, Matt McCutchen wrote: > On Thu, 2011-09-22 at 07:55 -0700, Paul Hoffman wrote: >> There is no sane way for a security protocol to fully deal with a >> preimage weakening for any supported hash algorithm. If you believe >> that this statement is incorrect, please point to the protocol that >> does. >=20 > DNSSEC with respect to SHA-256 and SHA-1 > (https://tools.ietf.org/html/rfc4509#section-3 second sentence). It = is > poorly explained, but DNSSEC is essentially adopting the Cartesian > product requirement. Just a side note. I really don't want to sidetrack, but I have to = comment. DNSEXT is/has been arguing that this is a server requirement (a = requirement for the zone owner) and not a client (a DNSSEC Validator) requirement. See recent Wouter's email to unbound-dev: https://unbound.net/pipermail/unbound-users/2011-September/002039.html And status of DNS client (DNS validator) implementations is that Bind = doesn't enforce the Cartesian product, Unbound doesn't. (I don't know status = for others.) 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 Sep 29 07:13:23 2011 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 885DC21F8CA7 for ; Thu, 29 Sep 2011 07:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.824 X-Spam-Level: X-Spam-Status: No, score=-1.824 tagged_above=-999 required=5 tests=[AWL=-0.125, 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 zc9hPcgTUqPS for ; Thu, 29 Sep 2011 07:13:23 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id D9EE521F8CA2 for ; Thu, 29 Sep 2011 07:13:22 -0700 (PDT) Received: from kimac.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 8232D2A296E for ; Thu, 29 Sep 2011 16:16:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1317305773; bh=vGGYu2WGkKWMj+wTtIPfSpL6YrMmKSvU48FonySstl0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=lkfTdXfeNRHtM0wplUIcgdo6HbMhndvEuJnRXRBUQTUWBVwTGzsTWdLJB7IbCb3PP XnVWfAxrYnU8QGtMmAWFLsqfSi9nWooqNhGNxyy7Uqy9zd3jdhjD4l2kOLkzX+iVsX Syjqxmae+Yybj4aAcl3I4NBpRp1sJKQNmlOaeadI= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Apple Message framework v1244.3) From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <1317264820.2975.58.camel@localhost> Date: Thu, 29 Sep 2011 16:16:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2CB5A330-61BB-48A2-8E51-D5406C0A7676@nic.cz> References: <061.add9f922b5dfb2db7544981f78552e7e@trac.tools.ietf.org> <076.bdd0467de056ddca69582bc0104dce57@trac.tools.ietf.org> <1317264820.2975.58.camel@localhost> To: DANE WG X-Mailer: Apple Mail (2.1244.3) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: Re: [dane] #33: Publish enough information for the client to achieve the security of its favorite digest 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, 29 Sep 2011 14:13:23 -0000 > 1. All digests of one cert in one RR (-1) > 2. Cartesian product requirement (-1) > 3. Group ID (-1) -- 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 Sep 29 07:15:52 2011 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 415FB21F8DD6 for ; Thu, 29 Sep 2011 07:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.81 X-Spam-Level: X-Spam-Status: No, score=-1.81 tagged_above=-999 required=5 tests=[AWL=-0.111, 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 dO8XvnxQvilO for ; Thu, 29 Sep 2011 07:15:49 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA2D21F8DD1 for ; Thu, 29 Sep 2011 07:15:49 -0700 (PDT) Received: from kimac.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 501982A29CA; Thu, 29 Sep 2011 16:18:40 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1317305920; bh=yLrFbcxIFrUjbNQBRkKLTwAHbLs3YhdNC0SciMjkHbI=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=PcMdZtAGVDRattZbK0UWuq7/H/U7RT8sTMUpvnG7PUR7M/1Fhs3FFr3Nz2q3Bs/P7 ItbaKrMQBvziDLFTmXJsTb3xi/h6I16+kywfz120/y1NvYJ4MQjoMOiUMdPxALlxZN 2FHqgLZUm9lHq5yzEf8jaglX3Kp1hwcxvHV2bW7I= Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <6AFD9333-B910-4534-BAB0-93C9A3096B42@bbn.com> Date: Thu, 29 Sep 2011 16:18:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <386290C9-69A9-484B-9450-D3EBB4FCB30C@nic.cz> References: <061.add9f922b5dfb2db7544981f78552e7e@trac.tools.ietf.org> <076.bdd0467de056ddca69582bc0104dce57@trac.tools.ietf.org> <6AFD9333-B910-4534-BAB0-93C9A3096B42@bbn.com> To: "Richard L. Barnes" X-Mailer: Apple Mail (2.1244.3) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: DANE WG Subject: Re: [dane] #33: Publish enough information for the client to achieve the security of its favorite digest 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, 29 Sep 2011 14:15:52 -0000 Richard, is that +1 for "no support" (it's quite confusion to vote +1 as a = negative vote)? E.g. it's -1 to all three proposed solutions? O. On 29. 9. 2011, at 15:59, Richard L. Barnes wrote: > +1 >=20 > (-3?) >=20 >=20 > On Sep 29, 2011, at 9:56 AM, Jakob Schlyter wrote: >=20 >> On 28 sep 2011, at 23:02, Warren Kumari wrote: >>=20 >>> And if folk do wish to show support for any of the 3 solutions I ask = that they do it by Friday 13:00UTC. >>=20 >> no support from me. >>=20 >> jakob >>=20 >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >=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 rbarnes@bbn.com Thu Sep 29 07:26:26 2011 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 16D2F21F8DE0 for ; Thu, 29 Sep 2011 07:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.113 X-Spam-Level: X-Spam-Status: No, score=-106.113 tagged_above=-999 required=5 tests=[AWL=-0.414, 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 9qcbiNcwc7r1 for ; Thu, 29 Sep 2011 07:26:25 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6981821F8DC8 for ; Thu, 29 Sep 2011 07:26:25 -0700 (PDT) Received: from [192.1.255.224] (port=55703 helo=col-dhcp-192-1-255-224.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1R9Hbw-0000tq-2p; Thu, 29 Sep 2011 10:29:16 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: "Richard L. Barnes" In-Reply-To: <386290C9-69A9-484B-9450-D3EBB4FCB30C@nic.cz> Date: Thu, 29 Sep 2011 10:29:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <061.add9f922b5dfb2db7544981f78552e7e@trac.tools.ietf.org> <076.bdd0467de056ddca69582bc0104dce57@trac.tools.ietf.org> <6AFD9333-B910-4534-BAB0-93C9A3096B42@bbn.com> <386290C9-69A9-484B-9450-D3EBB4FCB30C@nic.cz> To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= X-Mailer: Apple Mail (2.1084) Cc: DANE WG Subject: Re: [dane] #33: Publish enough information for the client to achieve the security of its favorite digest 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, 29 Sep 2011 14:26:26 -0000 That's a +1 for "no support". I included the -3 to try and clarify that = it was three negative votes :) --Richard On Sep 29, 2011, at 10:18 AM, Ond=C5=99ej Sur=C3=BD wrote: > Richard, >=20 > is that +1 for "no support" (it's quite confusion to vote +1 as a = negative vote)? > E.g. it's -1 to all three proposed solutions? >=20 > O. >=20 > On 29. 9. 2011, at 15:59, Richard L. Barnes wrote: >=20 >> +1 >>=20 >> (-3?) >>=20 >>=20 >> On Sep 29, 2011, at 9:56 AM, Jakob Schlyter wrote: >>=20 >>> On 28 sep 2011, at 23:02, Warren Kumari wrote: >>>=20 >>>> And if folk do wish to show support for any of the 3 solutions I = ask that they do it by Friday 13:00UTC. >>>=20 >>> no support from me. >>>=20 >>> jakob >>>=20 >>> _______________________________________________ >>> dane mailing list >>> dane@ietf.org >>> https://www.ietf.org/mailman/listinfo/dane >>=20 >> _______________________________________________ >> 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 paul.hoffman@vpnc.org Thu Sep 29 08:47:52 2011 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 55F5121F8D69 for ; Thu, 29 Sep 2011 08:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.56 X-Spam-Level: X-Spam-Status: No, score=-103.56 tagged_above=-999 required=5 tests=[AWL=1.039, BAYES_00=-2.599, GB_I_INVITATION=-2, 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 YdGxxVxB7OhB for ; Thu, 29 Sep 2011 08:47:51 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id C416B21F8D66 for ; Thu, 29 Sep 2011 08:47:51 -0700 (PDT) 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 p8TFogNc087521 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 29 Sep 2011 08:50:43 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <1317280974.1974.7.camel@localhost> Date: Thu, 29 Sep 2011 08:50:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9D9F3143-3C99-4B55-8708-274790D6CD93@vpnc.org> References: <061.a8eeecd5d3e79d55021946fbc77943e1@trac.tools.ietf.org> <1317181872.2975.13.camel@localhost> <444081ED-DF03-45E3-83FD-889EF53D6F03@bbn.com> <1317184098.2975.30.camel@localhost> <42D80BDE-458A-45F5-859C-CA955A6D7D4B@bbn.com> <1317224748.2975.49.camel@localhost> <001F15D5-0861-4CE2-8148-3EBC9B55C2B0@bbn.com> <1317280974.1974.7.camel@localhost> To: Matt McCutchen X-Mailer: Apple Mail (2.1244.3) Cc: IETF DANE WG Subject: Re: [dane] #37: Additive assertion of server certificate 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, 29 Sep 2011 15:47:52 -0000 On Sep 29, 2011, at 12:22 AM, Matt McCutchen wrote: > On Wed, 2011-09-28 at 11:50 -0700, Paul Hoffman wrote: >> On Sep 28, 2011, at 11:22 AM, Paul Wouters wrote: >>=20 >>> Is it really that dreadful to give us a single bit you will never = want to use? >>=20 >> Some of us *want* to use it, drama aside. My opinion, though, is that >> it is inappropriate for it to be in the TLSA spec until it can be = used >> in TLS. Until we can say how it is used in TLS in an interoperable >> fashion, putting it in TLSA is an invitation for confusion and >> non-interoperable use, probably in an insecure fashion. >=20 > There are two orthogonal bits; please do not confuse them: >=20 > (a) Putative cert usage 3, "exact server credential" additive + > restrictive association. >=20 > (b) SubjectPublicKeyInfo selector. >=20 > Your objection above is to (b), while ticket #37 is asking for (a). =20= Again: putting words in other people's mouths is really rude. My = objection is to (a). (b) is already in the draft, and has been for at = least two versions. > I > believe Paul Wouters is asking for (a) as well and the mention of > SubjectPublicKeyInfo was incidental. That was my impression as well. --Paul Hoffman From zack.weinberg@gmail.com Thu Sep 29 09:24:52 2011 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 50EDE21F8E05 for ; Thu, 29 Sep 2011 09:24:52 -0700 (PDT) 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 dHjnXvBzMEby for ; Thu, 29 Sep 2011 09:24:51 -0700 (PDT) Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id C5D5D21F8E06 for ; Thu, 29 Sep 2011 09:24:51 -0700 (PDT) Received: by pzk37 with SMTP id 37so2031190pzk.9 for ; Thu, 29 Sep 2011 09:27:43 -0700 (PDT) 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=enyJLJFu8iuVRsySwewk483/Bd2tSUme4P/Yv2S/0eI=; b=DDSZAjc+v7gmYCLbFWGOl4UfvP2JOWQpS1IIrEdFXq3n5R16lvrg7p+95PNIdefqYa Q0RfcSBCd3jyjdMuXutwH0lu+dtCYaVr1pJdOJPCUNJfrgaAeSX8doM4gor1PTLqIiDr 8gZNGQly//SWizXk7wzWyjKgbmHIxwX6Qv8AI= MIME-Version: 1.0 Received: by 10.68.14.231 with SMTP id s7mr52059108pbc.87.1317313663227; Thu, 29 Sep 2011 09:27:43 -0700 (PDT) Sender: zack.weinberg@gmail.com Received: by 10.68.59.105 with HTTP; Thu, 29 Sep 2011 09:27:43 -0700 (PDT) In-Reply-To: <1317264820.2975.58.camel@localhost> References: <061.add9f922b5dfb2db7544981f78552e7e@trac.tools.ietf.org> <076.bdd0467de056ddca69582bc0104dce57@trac.tools.ietf.org> <1317264820.2975.58.camel@localhost> Date: Thu, 29 Sep 2011 09:27:43 -0700 X-Google-Sender-Auth: 3HSOZOR62YnrYgVX77xgfnVNQV0 Message-ID: From: Zack Weinberg To: dane@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: Re: [dane] #33: Publish enough information for the client to achieve the security of its favorite digest 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, 29 Sep 2011 16:24:52 -0000 On Wed, Sep 28, 2011 at 7:53 PM, Matt McCutchen wrote: > For others' convenience in replying: I am +1 on the use case -- that is, I am in favor of providing for (what I understand to be) Matt's goals in *some* fashion. Of the available options: > 1. All digests of one cert in one RR -1: unwieldy, complicates client-side processing. > 2. Cartesian product requirement -0: simple and reliable, but imposes potentially enormous wire overhead. > 3. Group ID +1 zw From zack.weinberg@gmail.com Thu Sep 29 09:36:41 2011 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 EFBE921F8CE4 for ; Thu, 29 Sep 2011 09:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.977 X-Spam-Level: X-Spam-Status: No, score=-3.977 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, 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 X1SxEh-tRW65 for ; Thu, 29 Sep 2011 09:36:41 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 40E7921F8B92 for ; Thu, 29 Sep 2011 09:36:41 -0700 (PDT) Received: by eye4 with SMTP id 4so655367eye.31 for ; Thu, 29 Sep 2011 09:39:29 -0700 (PDT) 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=M1B3qedRsHOX+WfVVt7nRXFrVme5LZKbHG1OaSLYUys=; b=EnTsuj0r/5m8zZgiEPOxfkJSoMDbjHZyHRl33ZjAy7nDJEQLGL/bo39QUqr8jmQKWL 3gYft99mnXAVqGXvtAqgaCOde2V0QCumeLo66nyNfNgTjLPeV1qMieR88G0tMQ8UUYHi zNNv2Xs/5ROg4djauF6s58e6ooJDfH9BXHO2A= MIME-Version: 1.0 Received: by 10.68.6.98 with SMTP id z2mr52821880pbz.36.1317314368808; Thu, 29 Sep 2011 09:39:28 -0700 (PDT) Sender: zack.weinberg@gmail.com Received: by 10.68.59.105 with HTTP; Thu, 29 Sep 2011 09:39:28 -0700 (PDT) In-Reply-To: <9D9F3143-3C99-4B55-8708-274790D6CD93@vpnc.org> References: <061.a8eeecd5d3e79d55021946fbc77943e1@trac.tools.ietf.org> <1317181872.2975.13.camel@localhost> <444081ED-DF03-45E3-83FD-889EF53D6F03@bbn.com> <1317184098.2975.30.camel@localhost> <42D80BDE-458A-45F5-859C-CA955A6D7D4B@bbn.com> <1317224748.2975.49.camel@localhost> <001F15D5-0861-4CE2-8148-3EBC9B55C2B0@bbn.com> <1317280974.1974.7.camel@localhost> <9D9F3143-3C99-4B55-8708-274790D6CD93@vpnc.org> Date: Thu, 29 Sep 2011 09:39:28 -0700 X-Google-Sender-Auth: V2Hl7Xxpoca2RcOSuONmNwuFGj4 Message-ID: From: Zack Weinberg To: IETF DANE WG Content-Type: text/plain; charset=UTF-8 Subject: Re: [dane] #37: Additive assertion of server certificate 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, 29 Sep 2011 16:36:42 -0000 On Thu, Sep 29, 2011 at 8:50 AM, Paul Hoffman wrote: > On Sep 29, 2011, at 12:22 AM, Matt McCutchen wrote: >> On Wed, 2011-09-28 at 11:50 -0700, Paul Hoffman wrote: >>> Some of us *want* to use it, drama aside. My opinion, though, is that >>> it is inappropriate for it to be in the TLSA spec until it can be used >>> in TLS. Until we can say how it is used in TLS in an interoperable >>> fashion, putting it in TLSA is an invitation for confusion and >>> non-interoperable use, probably in an insecure fashion. ... >> (a) Putative cert usage 3, "exact server credential" additive + >> restrictive association. ... > My objection is to (a). It is not clear to me what you mean when you say "until [(a)] can be used in TLS," and therefore I do not understand your objection. From my perspective, using (a) in TLS alone is logically impossible, because there's nowhere to put the constraint that (a) specifies! Please elaborate. zw From paul.hoffman@vpnc.org Thu Sep 29 09:41:58 2011 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 893BD21F8C81 for ; Thu, 29 Sep 2011 09:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.564 X-Spam-Level: X-Spam-Status: No, score=-103.564 tagged_above=-999 required=5 tests=[AWL=1.035, BAYES_00=-2.599, GB_I_INVITATION=-2, 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 oIMMl-DLmpmf for ; Thu, 29 Sep 2011 09:41:58 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 14A2B21F8C08 for ; Thu, 29 Sep 2011 09:41:58 -0700 (PDT) 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 p8TGimGO018659 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 29 Sep 2011 09:44:49 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Thu, 29 Sep 2011 09:44:49 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <061.a8eeecd5d3e79d55021946fbc77943e1@trac.tools.ietf.org> <1317181872.2975.13.camel@localhost> <444081ED-DF03-45E3-83FD-889EF53D6F03@bbn.com> <1317184098.2975.30.camel@localhost> <42D80BDE-458A-45F5-859C-CA955A6D7D4B@bbn.com> <1317224748.2975.49.camel@localhost> <001F15D5-0861-4CE2-8148-3EBC9B55C2B0@bbn.com> <1317280974.1974.7.camel@localhost> <9D9F3143-3C99-4B55-8708-274790D6CD93@vpnc.org> To: Zack Weinberg X-Mailer: Apple Mail (2.1244.3) Cc: IETF DANE WG Subject: Re: [dane] #37: Additive assertion of server certificate 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, 29 Sep 2011 16:41:58 -0000 On Sep 29, 2011, at 9:39 AM, Zack Weinberg wrote: > On Thu, Sep 29, 2011 at 8:50 AM, Paul Hoffman = wrote: >> On Sep 29, 2011, at 12:22 AM, Matt McCutchen wrote: >>> On Wed, 2011-09-28 at 11:50 -0700, Paul Hoffman wrote: >>>> Some of us *want* to use it, drama aside. My opinion, though, is = that >>>> it is inappropriate for it to be in the TLSA spec until it can be = used >>>> in TLS. Until we can say how it is used in TLS in an interoperable >>>> fashion, putting it in TLSA is an invitation for confusion and >>>> non-interoperable use, probably in an insecure fashion. > ... >>> (a) Putative cert usage 3, "exact server credential" additive + >>> restrictive association. > ... >> My objection is to (a). >=20 > It is not clear to me what you mean when you say "until [(a)] can be > used in TLS," and therefore I do not understand your objection. From > my perspective, using (a) in TLS alone is logically impossible, > because there's nowhere to put the constraint that (a) specifies! >=20 > Please elaborate. That's exactly correct. In current TLS, there is no way to use a bare = SPKI. Paul Wouters and others have begun work on an extension to TLS = that would allow a bare SPKI to be used in TLS as the server's = authenticator. When (hopefully not just "if") that extension is = standardized, it would make sense for TLSA to have a bare SPKI as a = certificate type. --Paul Hoffman From zack.weinberg@gmail.com Thu Sep 29 09:51:27 2011 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 0D8D821F8E9E for ; Thu, 29 Sep 2011 09:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.077 X-Spam-Level: X-Spam-Status: No, score=-3.077 tagged_above=-999 required=5 tests=[AWL=-0.100, 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 yWBkTErJgJdz for ; Thu, 29 Sep 2011 09:51:26 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 844F021F8E94 for ; Thu, 29 Sep 2011 09:51:26 -0700 (PDT) Received: by gyd12 with SMTP id 12so899220gyd.31 for ; Thu, 29 Sep 2011 09:54:18 -0700 (PDT) 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=g+TtBt7KAc58ygfZo2S90A+B2AAwFGaWqHP4B34BcYM=; b=Kc/rSjkXB0bAiFJQLg28KHAvN8Coh9J/KgscFRDZVPEOn5o23Bi3hnrvm7EJL5y+Ux hOwE6fsRHxCd3tpySzS6XTSjQg9QT+Va5iuk/G0AVEB9//N56absw5yiprESshTXdaLk t6gYdlaocN7W93a7bOKgpwPp7nma2gWYndohk= MIME-Version: 1.0 Received: by 10.68.27.199 with SMTP id v7mr52197789pbg.2.1317315257428; Thu, 29 Sep 2011 09:54:17 -0700 (PDT) Sender: zack.weinberg@gmail.com Received: by 10.68.59.105 with HTTP; Thu, 29 Sep 2011 09:54:16 -0700 (PDT) In-Reply-To: References: <201109272223.p8RMNPpA026467@fs4113.wdf.sap.corp> Date: Thu, 29 Sep 2011 09:54:16 -0700 X-Google-Sender-Auth: oHd98Xt5BW2JCARTxtZZCYP5WJM 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] #36: Only requiring DNSSEC where it is needed 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, 29 Sep 2011 16:51:27 -0000 On Tue, Sep 27, 2011 at 7:00 PM, Richard L. Barnes wrote: > Paul beat me to it. =C2=A0With type 0/1 certs, the attacker can only bloc= k the DANE repudiation. > That's why there's not strictly a need for DNSSEC in that case. Even though this is the case, I do not like the idea of relaxing the requirement for DNSSEC to just some types of TLSA record. I prefer the operational simplicity of "MUST use DNSSEC" and the client-side implementation simplicity of "MUST ignore all TLSA records that are DNSSEC-insecure". zw From zack.weinberg@gmail.com Thu Sep 29 09:53:30 2011 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 58C2621F8ECE for ; Thu, 29 Sep 2011 09:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.068 X-Spam-Level: X-Spam-Status: No, score=-3.068 tagged_above=-999 required=5 tests=[AWL=-0.091, 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 uVCeBZCuiMQr for ; Thu, 29 Sep 2011 09:53:29 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 00DBD21F8ECF for ; Thu, 29 Sep 2011 09:53:22 -0700 (PDT) Received: by vws5 with SMTP id 5so940100vws.31 for ; Thu, 29 Sep 2011 09:56:13 -0700 (PDT) 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=8Y1mGv/hngEPuusAhL5jxv3WH9NnCX8IBbQzA0yOT4Q=; b=b3b19u60SMHhZpB10cmV7GV4zlF/lCn74u+u6C3IKU+uJ6+66TQFyZBIEvtNJLU6b+ pl14m4O0y53xP3arnwy0qmTsMf58D4m2l9p3gCv9tIpOaRCtWvt2ncAF6O7VnhMPHapq OHXcdpOeBIkVYOPekrZuex5MxBMRX+kng+DgY= MIME-Version: 1.0 Received: by 10.68.6.98 with SMTP id z2mr52902332pbz.36.1317315372712; Thu, 29 Sep 2011 09:56:12 -0700 (PDT) Sender: zack.weinberg@gmail.com Received: by 10.68.59.105 with HTTP; Thu, 29 Sep 2011 09:56:11 -0700 (PDT) In-Reply-To: <075.e771c9a4f93afa495f330ae9d1ebfa5a@trac.tools.ietf.org> References: <060.8aca11012e6c9583642ba071c54be972@trac.tools.ietf.org> <075.e771c9a4f93afa495f330ae9d1ebfa5a@trac.tools.ietf.org> Date: Thu, 29 Sep 2011 09:56:11 -0700 X-Google-Sender-Auth: AOTtXAzlmb2IuLo8OuWk-XwsHUU Message-ID: From: Zack Weinberg To: dane@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [dane] #36: Only requiring DNSSEC where it is needed 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, 29 Sep 2011 16:53:30 -0000 On Tue, Sep 27, 2011 at 8:45 PM, dane issue tracker wrote: > =C2=A0A related issue is whether clients MUST (1) attempt a DNSSEC query,= (2) > =C2=A0fail the handshake unless the query completes with "secure" or "ver= ified > =C2=A0insecure" state, and (3) if a "secure" nonempty TLSA RRset is retur= ned, > =C2=A0process it as described in the spec. =C2=A0This requirement goes ha= nd in hand > =C2=A0with the current statement that clients MUST fail the handshake if = the > =C2=A0server cert does not match any TLSA RR; one is not meaningful witho= ut the > =C2=A0other. =C2=A0So I think we should make both or neither of these beh= aviors > =C2=A0conformance requirements (c.f. ticket:26). Agree entirely (and I vote for "both"). Might want some wiggle room in the wording to allow for Adam's DANE-stapling scheme instead of client doing its own DNSSEC processing. zw From zack.weinberg@gmail.com Thu Sep 29 09:56:13 2011 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 898E221F8EDC for ; Thu, 29 Sep 2011 09:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.06 X-Spam-Level: X-Spam-Status: No, score=-3.06 tagged_above=-999 required=5 tests=[AWL=-0.083, 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 5VTGDYtO8U3G for ; Thu, 29 Sep 2011 09:56:13 -0700 (PDT) Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id 1E4D321F8ED4 for ; Thu, 29 Sep 2011 09:56:13 -0700 (PDT) Received: by pzk37 with SMTP id 37so2102372pzk.9 for ; Thu, 29 Sep 2011 09:59:04 -0700 (PDT) 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=Yqi7YxQ3W+NYnHRm+nU3YtnaoYaROFS6o4pJGfDEwOM=; b=IvMNxGF+7wInvV1ZSb/wJPHIceSFvxF5iV0LBpiFEB3n4/rfX4QOWjGR1EUmT0RZcN RcvcZ7+zhPLTngnu63hw8dxwXd6NgKI0lnrowljkgKrVvQwDRLUB3DClp0OXS+SAaZAD 88YfbgJMugz6UxqN0/+fk6jBSEEL64BhIV8eg= MIME-Version: 1.0 Received: by 10.68.27.199 with SMTP id v7mr52220088pbg.2.1317315544637; Thu, 29 Sep 2011 09:59:04 -0700 (PDT) Sender: zack.weinberg@gmail.com Received: by 10.68.59.105 with HTTP; Thu, 29 Sep 2011 09:59:04 -0700 (PDT) In-Reply-To: References: <061.a8eeecd5d3e79d55021946fbc77943e1@trac.tools.ietf.org> <1317181872.2975.13.camel@localhost> <444081ED-DF03-45E3-83FD-889EF53D6F03@bbn.com> <1317184098.2975.30.camel@localhost> <42D80BDE-458A-45F5-859C-CA955A6D7D4B@bbn.com> <1317224748.2975.49.camel@localhost> <001F15D5-0861-4CE2-8148-3EBC9B55C2B0@bbn.com> <1317280974.1974.7.camel@localhost> <9D9F3143-3C99-4B55-8708-274790D6CD93@vpnc.org> Date: Thu, 29 Sep 2011 09:59:04 -0700 X-Google-Sender-Auth: FpggiWsq4HAHbNQZqWv8KaaePoM 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] #37: Additive assertion of server certificate 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, 29 Sep 2011 16:56:13 -0000 On Thu, Sep 29, 2011 at 9:44 AM, Paul Hoffman wrote= : >>>> (a) Putative cert usage 3, "exact server credential" additive + >>>> restrictive association. >> ... >>> My objection is to (a). >> >> It is not clear to me what you mean when you say "until [(a)] can be >> used in TLS," and therefore I do not understand your objection. =C2=A0Fr= om >> my perspective, using (a) in TLS alone is logically impossible, >> because there's nowhere to put the constraint that (a) specifies! > > That's exactly correct. In current TLS, there is no way to use a > bare SPKI. Paul Wouters and others have begun work on an > extension to TLS that would allow a bare SPKI to be used in > TLS as the server's authenticator. When (hopefully not just "if") > that extension is standardized, it would make sense for TLSA > to have a bare SPKI as a certificate type. But that's Matt's (b)! (a) is "accept this end-entity certificate and no other" in the DANE record, as I understand it, which is independent of whether bare SPKI is possible, and doesn't make sense to put into TLS. zw From paul.hoffman@vpnc.org Thu Sep 29 10:26:49 2011 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 7E4AA21F8B8C for ; Thu, 29 Sep 2011 10:26:49 -0700 (PDT) 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 CGzSTWwANAJA for ; Thu, 29 Sep 2011 10:26:48 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id CB58121F8B80 for ; Thu, 29 Sep 2011 10:26:48 -0700 (PDT) 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 p8THTXjN045157 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 29 Sep 2011 10:29:37 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Thu, 29 Sep 2011 10:29:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <061.a8eeecd5d3e79d55021946fbc77943e1@trac.tools.ietf.org> <1317181872.2975.13.camel@localhost> <444081ED-DF03-45E3-83FD-889EF53D6F03@bbn.com> <1317184098.2975.30.camel@localhost> <42D80BDE-458A-45F5-859C-CA955A6D7D4B@bbn.com> <1317224748.2975.49.camel@localhost> <001F15D5-0861-4CE2-8148-3EBC9B55C2B0@bbn.com> <1317280974.1974.7.camel@localhost> <9D9F3143-3C99-4B55-8708-274790D6CD93@vpnc.org> To: Zack Weinberg X-Mailer: Apple Mail (2.1244.3) Cc: IETF DANE WG list Subject: Re: [dane] #37: Additive assertion of server certificate 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, 29 Sep 2011 17:26:49 -0000 On Sep 29, 2011, at 9:59 AM, Zack Weinberg wrote: > On Thu, Sep 29, 2011 at 9:44 AM, Paul Hoffman = wrote: >>>>> (a) Putative cert usage 3, "exact server credential" additive + >>>>> restrictive association. >>> ... >>>> My objection is to (a). >>>=20 >>> It is not clear to me what you mean when you say "until [(a)] can be >>> used in TLS," and therefore I do not understand your objection. = From >>> my perspective, using (a) in TLS alone is logically impossible, >>> because there's nowhere to put the constraint that (a) specifies! >>=20 >> That's exactly correct. In current TLS, there is no way to use a >> bare SPKI. Paul Wouters and others have begun work on an >> extension to TLS that would allow a bare SPKI to be used in >> TLS as the server's authenticator. When (hopefully not just "if") >> that extension is standardized, it would make sense for TLSA >> to have a bare SPKI as a certificate type. >=20 > But that's Matt's (b)! (a) is "accept this end-entity certificate and > no other" in the DANE record, as I understand it, which is independent > of whether bare SPKI is possible, and doesn't make sense to put into > TLS. I'm not sure what is happening here. (b) is a *matching* rule, not the = format of what is in (a). =46rom the draft: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 2.1.1. The Certificate Usage Field A one-octet value, called "certificate usage" or just "usage", specifying the provided association that will be used to match the target certificate. This will be an IANA registry in order to make it easier to add additional certificate usages in the future. The usages defined in this document are: 0 -- Certificate MUST pass PKIX validation and MUST chain through a CA certificate matching the TLSA record 1 -- Certificate MUST pass PKIX validation and MUST match the TLSA record 2 -- Certificate MUST pass PKIX validation, with any certificate matching the TLSA record considered to be a trust anchor for this validation The three certificate usages defined in this document explicitly only apply to PKIX-formatted certificates. If TLS allows other formats later, or if extensions to this protocol are made that accept other formats for certificates, those certificates will need their own certificate types. 2.1.2. The Selector Field A one-octet value, called "selector", specifying what will be matched. This value is defined in a new IANA registry. The selectors defined in this document are: 0 -- Full certificate 1 -- SubjectPublicKeyInfo =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D In the case of (a), a putative new type 3 might be worded as " type = used as the server's certificate MUST match the TLSA record". I think I see where some of the confusion may come from. The current = text for 2.1.4 says: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 2.1.4. The Certificate for Association Field The "certificate for association". This is the bytes containing the full certificate, SubjectPublicKeyInfo or the hash of the associated certificate or SubjectPublicKeyInfo. This is the certificate or the hash of the certificate itself, not of the TLS ASN.1 Certificate object. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This is incorrect. The second sentence should be "This is the bytes = containing the full certificate or the hash of the associated = certificate." We'll fix that in the next version of the draft. (And, if = Paul's extension to TLS moves faster than TLSA, we can add those back = later.) --Paul Hoffman From paul@xelerance.com Thu Sep 29 10:52:51 2011 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 A055511E80A3 for ; Thu, 29 Sep 2011 10:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.505 X-Spam-Level: X-Spam-Status: No, score=-4.505 tagged_above=-999 required=5 tests=[AWL=-1.906, 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 9UHxekMqT4qN for ; Thu, 29 Sep 2011 10:52:51 -0700 (PDT) Received: from mx.xelerance.com (mx.xelerance.com [193.110.157.188]) by ietfa.amsl.com (Postfix) with ESMTP id A89F511E809F for ; Thu, 29 Sep 2011 10:52:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx.xelerance.com (Postfix) with ESMTP id 509D9F53; Thu, 29 Sep 2011 13:55:39 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xelerance.com; h= content-type:content-type:mime-version:user-agent:references :message-id:in-reply-to:subject:subject:from:from:date:date :received:received:received:received; s=smtp; t=1317318937; x= 1317923737; bh=IKRgoUL/lhebvgM2Xsa1jG8B5xb12tjNQQTQzsy6PSs=; b=O otLlobMbFkuQdyIwXweRW8T/KQHmdSrCYzsnvRLcpfc4qPw5367MNUpx1pbse8tT ck8SwBwa7BH73ko0C8fKhS9xxkIcGEv+W/oDnD4nJn1GUJey0fJ8/VE1Ufedugvm ZZc9gc0Fyeh4ZZX76oNPkAONeYn9TAxtQXKbQfVN8A= Received: from mx.xelerance.com ([127.0.0.1]) by localhost (mx.xelerance.com [127.0.0.1]) (amavisd-new, port 10026) with LMTP id N-iqpwtSZhIx; Thu, 29 Sep 2011 13:55:37 -0400 (EDT) Received: from mail.xelerance.com (mail.xelerance.com [193.110.157.189]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.xelerance.com (Postfix) with ESMTPS id E05C5F27; Thu, 29 Sep 2011 13:55:36 -0400 (EDT) Received: by mail.xelerance.com (Postfix, from userid 1001) id 4764819E7; Thu, 29 Sep 2011 13:55:34 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.xelerance.com (Postfix) with ESMTP id 35889F0B; Thu, 29 Sep 2011 13:55:34 -0400 (EDT) Date: Thu, 29 Sep 2011 13:55:33 -0400 (EDT) From: Paul Wouters To: Paul Hoffman In-Reply-To: Message-ID: References: <061.a8eeecd5d3e79d55021946fbc77943e1@trac.tools.ietf.org> <1317181872.2975.13.camel@localhost> <444081ED-DF03-45E3-83FD-889EF53D6F03@bbn.com> <1317184098.2975.30.camel@localhost> <42D80BDE-458A-45F5-859C-CA955A6D7D4B@bbn.com> <1317224748.2975.49.camel@localhost> <001F15D5-0861-4CE2-8148-3EBC9B55C2B0@bbn.com> <1317280974.1974.7.camel@localhost> <9D9F3143-3C99-4B55-8708-274790D6CD93@vpnc.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IETF DANE WG list Subject: Re: [dane] #37: Additive assertion of server certificate 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, 29 Sep 2011 17:52:51 -0000 On Thu, 29 Sep 2011, Paul Hoffman wrote: [ not sure if my messages are making it to the list, due to mail.ietf.org insisting on valid reverse for IPv6 ] > ========== > 2.1.1. The Certificate Usage Field > > A one-octet value, called "certificate usage" or just "usage", > specifying the provided association that will be used to match the > target certificate. This will be an IANA registry in order to make > it easier to add additional certificate usages in the future. The > usages defined in this document are: > > 0 -- Certificate MUST pass PKIX validation and MUST chain through > a CA certificate matching the TLSA record > > 1 -- Certificate MUST pass PKIX validation and MUST match the TLSA > record > > 2 -- Certificate MUST pass PKIX validation, with any certificate > matching the TLSA record considered to be a trust anchor for this > validation > > The three certificate usages defined in this document explicitly only > apply to PKIX-formatted certificates. I think that "self signed certificates" are "PKIX-formatted certificates", though I seem some people suggest it is formally not the case. Can this be clarified in the text? Specifically, if someone is using a self signed certificate, this part should be clear as to which category such a certificate falls. This is for those who want a PKIX container for backwards compatibility, but have no CA for "PKIX validation". Ideally, I would like to see a new term for "PKIX validation". I think what is meant is: a) contains a valid PKIX structure, and b) contains a valid PKIX signature Where in case 2) we have for b) "valid self-signed PKIX signature" and in case 0) we have for b) "valid PKIX signature chain to the CA specified in the TLA record"? Paul From zack.weinberg@gmail.com Thu Sep 29 11:02:23 2011 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 8454221F8C46 for ; Thu, 29 Sep 2011 11:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.054 X-Spam-Level: X-Spam-Status: No, score=-3.054 tagged_above=-999 required=5 tests=[AWL=-0.077, 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 nW5ciXh10uBw for ; Thu, 29 Sep 2011 11:02:23 -0700 (PDT) Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id DBB4D21F8C44 for ; Thu, 29 Sep 2011 11:02:22 -0700 (PDT) Received: by pzk37 with SMTP id 37so2235084pzk.9 for ; Thu, 29 Sep 2011 11:05:13 -0700 (PDT) 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=eUrzA25OxHTZ8S+2KJUNFW8RhUKfKCaCo5ikiCYzCEc=; b=A2xoHvcAWM7yyzzumv23YPax9x6EHWOnX7Q+fiHi4O9KoSKxdFqyE9CjbP2grDpPQC IOFC+XyRljOdnDx9yIzeSuDcFFuvecRaamGfcYJtWfbRxEvJXVd9YWQg5DaOG5Wrwguh CbU0cprGH0kGMIPKtIp9XgW9QazIBm8tloQ38= MIME-Version: 1.0 Received: by 10.68.14.231 with SMTP id s7mr52526950pbc.87.1317319513316; Thu, 29 Sep 2011 11:05:13 -0700 (PDT) Sender: zack.weinberg@gmail.com Received: by 10.68.59.105 with HTTP; Thu, 29 Sep 2011 11:05:13 -0700 (PDT) In-Reply-To: References: <061.a8eeecd5d3e79d55021946fbc77943e1@trac.tools.ietf.org> <1317181872.2975.13.camel@localhost> <444081ED-DF03-45E3-83FD-889EF53D6F03@bbn.com> <1317184098.2975.30.camel@localhost> <42D80BDE-458A-45F5-859C-CA955A6D7D4B@bbn.com> <1317224748.2975.49.camel@localhost> <001F15D5-0861-4CE2-8148-3EBC9B55C2B0@bbn.com> <1317280974.1974.7.camel@localhost> <9D9F3143-3C99-4B55-8708-274790D6CD93@vpnc.org> Date: Thu, 29 Sep 2011 11:05:13 -0700 X-Google-Sender-Auth: sqMGZrOSp7l88IlERhuzbBLn9N8 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] #37: Additive assertion of server certificate 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, 29 Sep 2011 18:02:23 -0000 On Thu, Sep 29, 2011 at 10:29 AM, Paul Hoffman wrot= e: > On Sep 29, 2011, at 9:59 AM, Zack Weinberg wrote: > >> On Thu, Sep 29, 2011 at 9:44 AM, Paul Hoffman wr= ote: >>>>>> (a) Putative cert usage 3, "exact server credential" additive + >>>>>> restrictive association. >>>> ... >>>>> My objection is to (a). >>>> >>>> It is not clear to me what you mean when you say "until [(a)] can be >>>> used in TLS," and therefore I do not understand your objection. =C2=A0= From >>>> my perspective, using (a) in TLS alone is logically impossible, >>>> because there's nowhere to put the constraint that (a) specifies! >>> >>> That's exactly correct. In current TLS, there is no way to use a >>> bare SPKI. Paul Wouters and others have begun work on an >>> extension to TLS that would allow a bare SPKI to be used in >>> TLS as the server's authenticator. When (hopefully not just "if") >>> that extension is standardized, it would make sense for TLSA >>> to have a bare SPKI as a certificate type. >> >> But that's Matt's (b)! =C2=A0(a) is "accept this end-entity certificate = and >> no other" in the DANE record, as I understand it, which is independent >> of whether bare SPKI is possible, and doesn't make sense to put into >> TLS. > > I'm not sure what is happening here. (b) is a *matching* rule, not the fo= rmat of what is in (a). From the draft: [...] I'm afraid you've only made me more confused. Part of the problem is that I don't know what "PKIX validation" is (and this is after spending an entire day trying to figure it out; I'm not convinced *anyone* knows what it is), and the other part is that you continue to appear to be conflating three entirely orthogonal things, only one of which makes any sense as part of the TLS spec. Those three things are:- (x): a TLSA record which restricts the server to precisely one end-entity public key (using any of the supported reference modes) and possibly also requires that a DANE-compliant client accept the record whether or not its in-band signature chain leads to a CA certificate in the client's trusted root pool. [This is Matt's (a) as I understand it, and is not covered by the current draft.] (y) a TLSA record which matches certificates by their SPKI rather than their complete contents. [Matt's (b) aiui, Selector Type 1 in the current draft.] (z) an X.509 certificate construct that contains only the SubjectPublicKeyInfo, not all the rest of the usual gunk. [This is logically a TLS extension.] If I understand you at all -- and I'm not sure I do -- you're saying that DANE can't do (x) without TLS doing (z) first. But this seems ridiculous to me: (z) is about the format and contents of the certificate presented in the TLS handshake, and affects its semantics only insofar as a (z) cert has no in-band signatures (or does it?); (x) is purely a question of the semantics *of the TLSA record*, and can be specified without any reference to the contents or semantics of the *certificate*. zw From zack.weinberg@gmail.com Thu Sep 29 11:05:12 2011 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 769AF1F0C48 for ; Thu, 29 Sep 2011 11:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.048 X-Spam-Level: X-Spam-Status: No, score=-3.048 tagged_above=-999 required=5 tests=[AWL=-0.071, 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 7pa9sqrFZalr for ; Thu, 29 Sep 2011 11:05:12 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id E19B71F0C41 for ; Thu, 29 Sep 2011 11:05:11 -0700 (PDT) Received: by vws5 with SMTP id 5so1027190vws.31 for ; Thu, 29 Sep 2011 11:08:03 -0700 (PDT) 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=/CEt2hx8/cftF2iPb88rsFqwwPKWpm5ritQ4sIs5aLU=; b=HY4kNRSSE+7H9V3wh5SnE6ikCRKyk8acHXsTtWJSnuSDJzQePnwulhoeKNog4KcXqf MyaWTXDPLH3jFVWYKnfvJQam2wPrLq3LKdWX8+Ovcfqai2oF3/DkBu5zf2039zOxZfJy OUZZL1R7f/qL6eJkIBR433BvJVTMAXIWi9jOY= MIME-Version: 1.0 Received: by 10.68.6.98 with SMTP id z2mr53250755pbz.36.1317319682976; Thu, 29 Sep 2011 11:08:02 -0700 (PDT) Sender: zack.weinberg@gmail.com Received: by 10.68.59.105 with HTTP; Thu, 29 Sep 2011 11:08:02 -0700 (PDT) In-Reply-To: References: <061.a8eeecd5d3e79d55021946fbc77943e1@trac.tools.ietf.org> <1317181872.2975.13.camel@localhost> <444081ED-DF03-45E3-83FD-889EF53D6F03@bbn.com> <1317184098.2975.30.camel@localhost> <42D80BDE-458A-45F5-859C-CA955A6D7D4B@bbn.com> <1317224748.2975.49.camel@localhost> <001F15D5-0861-4CE2-8148-3EBC9B55C2B0@bbn.com> <1317280974.1974.7.camel@localhost> <9D9F3143-3C99-4B55-8708-274790D6CD93@vpnc.org> Date: Thu, 29 Sep 2011 11:08:02 -0700 X-Google-Sender-Auth: P4_4TNv1VXb_SOWZEqGghP1uWK8 Message-ID: From: Zack Weinberg To: IETF DANE WG list Content-Type: text/plain; charset=UTF-8 Subject: Re: [dane] #37: Additive assertion of server certificate 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, 29 Sep 2011 18:05:12 -0000 On Thu, Sep 29, 2011 at 11:05 AM, Zack Weinberg wrote: > (x): a TLSA record which restricts the server to precisely one > end-entity public key (using any of the supported reference modes) and > possibly also requires that a DANE-compliant client accept the record ^^^^^^ I meant to say "accept a matching end-entity certificate" here. From mrex@sap.com Thu Sep 29 11:58:38 2011 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 ED37B21F8EBF for ; Thu, 29 Sep 2011 11:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.068 X-Spam-Level: X-Spam-Status: No, score=-10.068 tagged_above=-999 required=5 tests=[AWL=0.181, 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 zWJjaknxsa+C for ; Thu, 29 Sep 2011 11:58:38 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 1685821F8C8B for ; Thu, 29 Sep 2011 11:58:37 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p8TJ1QgY029080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Sep 2011 21:01:26 +0200 (MEST) From: Martin Rex Message-Id: <201109291901.p8TJ1QAR027684@fs4113.wdf.sap.corp> To: paul.hoffman@vpnc.org (Paul Hoffman) Date: Thu, 29 Sep 2011 21:01:26 +0200 (MEST) In-Reply-To: from "Paul Hoffman" at Sep 29, 11 10:29:33 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] #37: Additive assertion of server certificate 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, 29 Sep 2011 18:58:39 -0000 I'm slightly confused about the description of usage (2), because the description is backwards to how it must be implemented. Paul Hoffman wrote: > > ========== > 2.1.1. The Certificate Usage Field > > A one-octet value, called "certificate usage" or just "usage", > specifying the provided association that will be used to match the > target certificate. This will be an IANA registry in order to make > it easier to add additional certificate usages in the future. The > usages defined in this document are: > > 0 -- Certificate MUST pass PKIX validation and MUST chain through > a CA certificate matching the TLSA record > > 1 -- Certificate MUST pass PKIX validation and MUST match the TLSA > record > > 2 -- Certificate MUST pass PKIX validation, with any certificate > matching the TLSA record considered to be a trust anchor for this > validation In order to call a "PKIX [certificate path] validation" function, you will need to provide (at least) two input parameters: ( I) a (prospective) certification path (II) a trust anchor (which may be provide in form of a certificate) For the PKIX certificate path validation __function__ itself it is not relevant whether the trust anchor originates from a persistent local trust anchor store, or whether it has been dynamically determined --such as through DANE and verified by DNSSEC (or dynamically downloaded from Microsoft's central trust anchor store, which is what Vista&Win7 will do). Based on the assumption that Certificate usage (2) above refers to this: http://tools.ietf.org/html/draft-ietf-dane-use-cases-05#section-3.3 the processing should look like this: For TLS and the use of DANE for TLS server cert verification, the TLS client will obtain the server certificate (plus optional path certificates) from the server's TLS Certificate handshake message. TLS _requires_ the Server certificate path to be in order (but some TLS implementations re-sort path certificates on the receiver side to accomodate occasionally misconfigured servers that use a buggy TLS implementation which is sending and unordered path. The DANE client needs search the list/path of certificates conveyed by the TLS Server in the server's Certificate handshake message from the end-entity cert (first in the list) to then end of the list and compare each cert to each of the TLSA records. When a match is found and the match is the servers end-entity cert, then no certificate path validation can be performed for usage (2). If a match with a TLS record is found on any later certificate in the list, then this certificate must be provided as "trust anchor" to the PKIX certificate path validation function, and the server's certificate path up to, but not including that matching cert, must be passed as "prospective certification path" input to the PKIX certificate path validation function. -Martin From matt@mattmccutchen.net Thu Sep 29 22:17:24 2011 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 C21EB21F8A62 for ; Thu, 29 Sep 2011 22:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.639 X-Spam-Level: X-Spam-Status: No, score=-2.639 tagged_above=-999 required=5 tests=[AWL=-0.040, 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 iW2rKWSwfHVQ for ; Thu, 29 Sep 2011 22:17:24 -0700 (PDT) Received: from homiemail-a1.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 104A121F8A58 for ; Thu, 29 Sep 2011 22:17:23 -0700 (PDT) Received: from homiemail-a1.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a1.g.dreamhost.com (Postfix) with ESMTP id 7322334806C; Thu, 29 Sep 2011 22:20:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; q=dns; s= mattmccutchen.net; b=MagRZ81sD3PHJKZDO/EXDOUuFd+YMkCDQBWr5pwyc1I Di/UfoQTHI8qJhsrbvsklQOkgius3UNak61UzWQ2fChhaBFYrxeoXTghvbwOkQlv mf9tcudU/nPispzZOlli4ur9tMaXAhdsxiziH67ltniDWfhy8Ir099Mgv0rn6xI8 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; s= mattmccutchen.net; bh=aJWiGYVFRQx0rRdPsXcz2pMUgvw=; b=a91kTbYlZV ka9gYDp+pIILjRs/pdXfZeGVxClJQtR2l3qa8uRXd1w3HYnrrcQBvDs9MtvVa7sO CPHV65xA8494VIH7Fuz+T3YEG2qmQxqecQNgbpYAsvVLoejkEIgpP0RNnrtcoQWi q9Yn/Cl9up4i20/Q5gnjYVsbRmRE/z6r8= 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-a1.g.dreamhost.com (Postfix) with ESMTPSA id 5039134806A; Thu, 29 Sep 2011 22:20:12 -0700 (PDT) From: Matt McCutchen To: Zack Weinberg Date: Thu, 29 Sep 2011 22:20:11 -0700 In-Reply-To: References: <061.add9f922b5dfb2db7544981f78552e7e@trac.tools.ietf.org> <076.bdd0467de056ddca69582bc0104dce57@trac.tools.ietf.org> <1317264820.2975.58.camel@localhost> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 Content-Transfer-Encoding: 7bit Message-ID: <1317360012.2130.8.camel@localhost> Mime-Version: 1.0 Cc: dane@ietf.org Subject: Re: [dane] #33: Publish enough information for the client to achieve the security of its favorite digest 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, 30 Sep 2011 05:17:24 -0000 On Thu, 2011-09-29 at 09:27 -0700, Zack Weinberg wrote: > > 1. All digests of one cert in one RR > > -1: unwieldy, complicates client-side processing. I'm curious why you say this. This approach provides exactly the same data as the group ID approach, just in a different format that avoids the redundancy in the cert usage and selector fields and avoids the need for admins using only one digest to think about group IDs. The complexity of the client-side processing is essentially the same: instead of iterating over the group IDs and then the RRs with each group ID, you would iterate over the RRs and then the digests within each RR. -- Matt From matt@mattmccutchen.net Thu Sep 29 23:00:30 2011 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 4F1C621F8BA2 for ; Thu, 29 Sep 2011 23:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.637 X-Spam-Level: X-Spam-Status: No, score=-2.637 tagged_above=-999 required=5 tests=[AWL=-0.038, 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 BYH5B3MOkWRl for ; Thu, 29 Sep 2011 23:00:29 -0700 (PDT) Received: from homiemail-a7.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id BD69121F8B9E for ; Thu, 29 Sep 2011 23:00:29 -0700 (PDT) Received: from homiemail-a7.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a7.g.dreamhost.com (Postfix) with ESMTP id ACD9F25C063; Thu, 29 Sep 2011 23:03:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; q=dns; s= mattmccutchen.net; b=dJV/x7VEGABMu9D1i20UjnCbkDXjPMeUEO/bhtNRUZd dU+Ai9GOIROpG2Xyh5cehouMPavgE94mwUGlReVlRHK5dQTdiQTZly+c6pPXBmLk m7vMGiIhEB3c98lWrXS32GbfPcq3MSMS1MBXn7+y2Xdu9CcwLjtOo2cfaSjgZteU = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; s= mattmccutchen.net; bh=Cm8eaovP4y+hJ/fFWAzvbpXla9Q=; b=Z7Xu73+Hj1 PwomGSpmGralnUYgCZpC0ZVOHq9PNovyITLGuWG9gHmE5jq4ntpLbCpACfEZUkrF riJVrrv9OgaVNdmbkVZcNchctHHQitwJ0lP0ZBSYVmz0i+4saM/e6glS7ZpreYJd fwpefxqDlWS77wLKxQxlMues4mEKjKvRI= 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 893DB25C062; Thu, 29 Sep 2011 23:03:22 -0700 (PDT) From: Matt McCutchen To: Paul Wouters Date: Thu, 29 Sep 2011 23:03:21 -0700 In-Reply-To: References: <201109221528.p8MFS6bE017153@fs4113.wdf.sap.corp> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 Content-Transfer-Encoding: 7bit Message-ID: <1317362602.2130.14.camel@localhost> Mime-Version: 1.0 Cc: dane@ietf.org Subject: Re: [dane] #33: Publish enough information for the client to 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, 30 Sep 2011 06:00:30 -0000 On Thu, 2011-09-22 at 17:24 -0400, Paul Wouters wrote: > We put in algorithm agility to migrate before shit hits the fan. We should > not remain bikeshedding over theoretical doomsday scenario of global > nuclear hash failing. If the servers did indeed migrate before the hash algorithm became unacceptably weak, it would be fine. But all the evidence we have from similar scenarios suggests that some percentage of servers won't, inevitably leaving the mainstream browsers between a rock and a hard place. So I'm so glad to see comment from someone involved more directly in browser development than myself. -- Matt From matt@mattmccutchen.net Thu Sep 29 23:12:44 2011 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 29ED721F86AA for ; Thu, 29 Sep 2011 23:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.636 X-Spam-Level: X-Spam-Status: No, score=-3.636 tagged_above=-999 required=5 tests=[AWL=0.963, BAYES_00=-2.599, GB_I_INVITATION=-2] 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 1sKAlyQdhwzD for ; Thu, 29 Sep 2011 23:12:43 -0700 (PDT) Received: from homiemail-a60.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC4021F86A4 for ; Thu, 29 Sep 2011 23:12:43 -0700 (PDT) Received: from homiemail-a60.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a60.g.dreamhost.com (Postfix) with ESMTP id AE7C83BC065; Thu, 29 Sep 2011 23:15:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; q=dns; s= mattmccutchen.net; b=L6ee+BMTz3mc5fvyvUm7xTlz7n4mQr8n+ox3PhV7xjg /s81mrIzzcxK041lOeo9/yjx45FN7D/SKfOSudfb497ju2b4KvaVV2zLmezWYuc2 gWJDm2ItEoPtAZf5e+1wArsz2HouVAdyjoSrIB5ZQ8rC++T9Hp9DIAg+eVe0OvJo = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; s= mattmccutchen.net; bh=3TwunqAGTItS5BYVQNBVzstxLCc=; b=eda+nMLjAb kOqmPNlig+QndbKJRewWQ5yeRbXdqsEAx2o4xEiGac4q1Vueu24MrKd9m7gDncTB VnSdGfGJ5vV7e5ujN9Lq+mQYO4yEkJFBFIe+8vlrA6mUjo2RBHdFasHJfqMwgwcY g3crIL74ei2m+/EzF1uIvY4dj8C2zCfqA= 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-a60.g.dreamhost.com (Postfix) with ESMTPSA id 7B8C53BC062; Thu, 29 Sep 2011 23:15:36 -0700 (PDT) From: Matt McCutchen To: Paul Hoffman Date: Thu, 29 Sep 2011 23:15:35 -0700 In-Reply-To: References: <061.a8eeecd5d3e79d55021946fbc77943e1@trac.tools.ietf.org> <1317181872.2975.13.camel@localhost> <444081ED-DF03-45E3-83FD-889EF53D6F03@bbn.com> <1317184098.2975.30.camel@localhost> <42D80BDE-458A-45F5-859C-CA955A6D7D4B@bbn.com> <1317224748.2975.49.camel@localhost> <001F15D5-0861-4CE2-8148-3EBC9B55C2B0@bbn.com> <1317280974.1974.7.camel@localhost> <9D9F3143-3C99-4B55-8708-274790D6CD93@vpnc.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 Content-Transfer-Encoding: 7bit Message-ID: <1317363336.2130.24.camel@localhost> Mime-Version: 1.0 Cc: IETF DANE WG Subject: Re: [dane] #37: Additive assertion of server certificate 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, 30 Sep 2011 06:12:44 -0000 On Thu, 2011-09-29 at 09:44 -0700, Paul Hoffman wrote: > On Sep 29, 2011, at 9:39 AM, Zack Weinberg wrote: > > On Thu, Sep 29, 2011 at 8:50 AM, Paul Hoffman wrote: > >> On Sep 29, 2011, at 12:22 AM, Matt McCutchen wrote: > >>> On Wed, 2011-09-28 at 11:50 -0700, Paul Hoffman wrote: > >>>> Some of us *want* to use it, drama aside. My opinion, though, is that > >>>> it is inappropriate for it to be in the TLSA spec until it can be used > >>>> in TLS. Until we can say how it is used in TLS in an interoperable > >>>> fashion, putting it in TLSA is an invitation for confusion and > >>>> non-interoperable use, probably in an insecure fashion. > > ... > >>> (a) Putative cert usage 3, "exact server credential" additive + > >>> restrictive association. > > ... > >> My objection is to (a). > > > > It is not clear to me what you mean when you say "until [(a)] can be > > used in TLS," and therefore I do not understand your objection. From > > my perspective, using (a) in TLS alone is logically impossible, > > because there's nowhere to put the constraint that (a) specifies! > > > > Please elaborate. > > That's exactly correct. In current TLS, there is no way to use a bare > SPKI. Paul Wouters and others have begun work on an extension to TLS > that would allow a bare SPKI to be used in TLS as the server's > authenticator. When (hopefully not just "if") that extension is > standardized, it would make sense for TLSA to have a bare SPKI as a > certificate type. I don't understand your concern. (a) is orthogonal to the use of SPKI for matching. I will be satisfied if there is some way I can make an additive and restrictive association of the server credential, like I have on https://mattmccutchen.net now based on an earlier draft: "accept the server's X.509 cert if and only if its SHA256 is D5D73FCEBCBA047528DA062A108DD5A955F9AD8F6F7E1618E5D172DFCB12980E". -- Matt From Antoin.Verschuren@sidn.nl Fri Sep 30 00:26:02 2011 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 2E8AE21F8BEC for ; Fri, 30 Sep 2011 00:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.504 X-Spam-Level: X-Spam-Status: No, score=-4.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, 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 WTJUW3EuzWyA for ; Fri, 30 Sep 2011 00:26:01 -0700 (PDT) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [94.198.152.69]) by ietfa.amsl.com (Postfix) with ESMTP id 09D1021F8BE8 for ; Fri, 30 Sep 2011 00:26:00 -0700 (PDT) Received: from kahubcas1.SIDN.local ([192.168.2.41]) by ede1-kamx.sidn.nl with ESMTP id p8U7SqZP015582 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Fri, 30 Sep 2011 09:28:52 +0200 Received: from [192.168.129.134] (192.168.129.134) by KAHUBCAS1.SIDN.local (192.168.2.41) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 30 Sep 2011 09:28:52 +0200 Message-ID: <4E856FB8.9000301@sidn.nl> Date: Fri, 30 Sep 2011 09:28:56 +0200 From: Antoin Verschuren User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: References: <201109272223.p8RMNPpA026467@fs4113.wdf.sap.corp> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [192.168.129.134] Subject: Re: [dane] #36: Only requiring DNSSEC where it is needed 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, 30 Sep 2011 07:26:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 29-09-11 18:54, Zack Weinberg wrote: > On Tue, Sep 27, 2011 at 7:00 PM, Richard L. Barnes wrote: >> Paul beat me to it. With type 0/1 certs, the attacker can only block the DANE repudiation. >> That's why there's not strictly a need for DNSSEC in that case. > > Even though this is the case, I do not like the idea of relaxing the > requirement for DNSSEC to just some types of TLSA record. I prefer > the operational simplicity of "MUST use DNSSEC" and the client-side > implementation simplicity of "MUST ignore all TLSA records that are > DNSSEC-insecure". +1 Maintaining when and in what circumstances TLSA should/should not/must/must not be signed is adding complexity that is more likely to become broken than the simple rule now that it MUST allways be signed, - -- Antoin Verschuren Technical Policy Advisor SIDN Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 F: +31 26 3525505 M: +31 6 23368970 mailto:antoin.verschuren@sidn.nl xmpp:antoin@jabber.sidn.nl http://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJOhW+4AAoJEDqHrM883AgnygQH/3wDHVNC3F/Yo1ceQXlEYtzA QHOwoCweIfyq8OqK4RNxewQQBM9flh1IaN2la0/cOYQ12+q+AGE0cVVrb9Gx1HIQ uareDMKjz9yq1mcIU8ykEZW2QIzSj8PtqX2NY/r9qr32GGyhEPEwRI55xAR2XPH4 R5LvYyEytSdXiXsepO6WW1sPX5JEhqqo17ojcWvCH10xM6wdHILYG30uvJZdzPuk R7TXii8pK7VDxX+wheIKio2Wcbx8CfWqC+mMR1dfUwu+s9e5jBODO8FINQcEBsPN GAZiOWf8fdibl4jIaQEnhxyiCO9CnWwP+Y5gAJCSVd7zn0eWWKwIh7hKUAh+kCo= =M6/T -----END PGP SIGNATURE----- From kent@bbn.com Fri Sep 30 01:10:49 2011 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 5C15C21F8C68 for ; Fri, 30 Sep 2011 01:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.556 X-Spam-Level: X-Spam-Status: No, score=-106.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 mkaWcl0Ulnia for ; Fri, 30 Sep 2011 01:10:48 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id C0A4D21F8C65 for ; Fri, 30 Sep 2011 01:10:48 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:36451 helo=[196.40.177.154]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1R9YE0-0009WX-Qh; Fri, 30 Sep 2011 04:13:41 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <061.a8eeecd5d3e79d55021946fbc77943e1@trac.tools.ietf.org> <1317181872.2975.13.camel@localhost> <444081ED-DF03-45E3-83FD-889EF53D6F03@bbn.com> <1317184098.2975.30.camel@localhost> <42D80BDE-458A-45F5-859C-CA955A6D7D4B@bbn.com> <1317224748.2975.49.camel@localhost> <001F15D5-0861-4CE2-8148-3EBC9B55C2B0@bbn.com> <1317280974.1974.7.camel@localhost> <9D9F3143-3C99-4B55-8708-274790D6CD93@vpnc.org> Date: Fri, 30 Sep 2011 03:53:50 -0400 To: Zack Weinberg From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: IETF DANE WG list Subject: Re: [dane] #37: Additive assertion of server certificate 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, 30 Sep 2011 08:10:49 -0000 At 11:05 AM -0700 9/29/11, Zack Weinberg wrote: >... > > I'm not sure what is happening here. (b) is a *matching* rule, >not the format of what is in (a). From the draft: >[...] > >I'm afraid you've only made me more confused. Part of the problem is >that I don't know what "PKIX validation" is (and this is after >spending an entire day trying to figure it out; I'm not convinced >*anyone* knows what it is), and the other part is that you continue to >appear to be conflating three entirely orthogonal things, only one of >which makes any sense as part of the TLS spec. A reasonable definition for "PKIX validation" is cert path validation that complies with RFC 5280. Steve From i.grok@comcast.net Fri Sep 30 04:25:59 2011 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 B1B9621F8B56 for ; Fri, 30 Sep 2011 04:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.594 X-Spam-Level: X-Spam-Status: No, score=-103.594 tagged_above=-999 required=5 tests=[AWL=1.005, BAYES_00=-2.599, GB_I_INVITATION=-2, 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 RHV+D3YoyWb7 for ; Fri, 30 Sep 2011 04:25:58 -0700 (PDT) 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 E2D9A21F8B54 for ; Fri, 30 Sep 2011 04:25:58 -0700 (PDT) Received: from omta02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by qmta05.emeryville.ca.mail.comcast.net with comcast id ezUW1h0030QkzPwA5zUmVS; Fri, 30 Sep 2011 11:28:46 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta02.emeryville.ca.mail.comcast.net with comcast id ezUn1h00T00PQ6U8NzUow7; Fri, 30 Sep 2011 11:28:48 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.4/8.14.3) with ESMTP id p8UBSmcB019165 for ; Fri, 30 Sep 2011 07:28:48 -0400 Received: (from draco@localhost) by odin.ulthar.us (8.14.4/8.14.4/Submit) id p8UBSmC4019163 for dane@ietf.org; Fri, 30 Sep 2011 07:28:48 -0400 Date: Fri, 30 Sep 2011 07:28:48 -0400 From: Scott Schmit To: dane@ietf.org Message-ID: <20110930112848.GA11338@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <42D80BDE-458A-45F5-859C-CA955A6D7D4B@bbn.com> <1317224748.2975.49.camel@localhost> <001F15D5-0861-4CE2-8148-3EBC9B55C2B0@bbn.com> <1317280974.1974.7.camel@localhost> <9D9F3143-3C99-4B55-8708-274790D6CD93@vpnc.org> <1317363336.2130.24.camel@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1317363336.2130.24.camel@localhost> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] #37: Additive assertion of server certificate 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, 30 Sep 2011 11:25:59 -0000 On Thu, Sep 29, 2011 at 11:15:35PM -0700, Matt McCutchen wrote: > On Thu, 2011-09-29 at 09:44 -0700, Paul Hoffman wrote: > > On Sep 29, 2011, at 9:39 AM, Zack Weinberg wrote: > > > On Thu, Sep 29, 2011 at 8:50 AM, Paul Hoffman wrote: > > >> On Sep 29, 2011, at 12:22 AM, Matt McCutchen wrote: > > >>> On Wed, 2011-09-28 at 11:50 -0700, Paul Hoffman wrote: > > >>>> Some of us *want* to use it, drama aside. My opinion, though, is that > > >>>> it is inappropriate for it to be in the TLSA spec until it can be used > > >>>> in TLS. Until we can say how it is used in TLS in an interoperable > > >>>> fashion, putting it in TLSA is an invitation for confusion and > > >>>> non-interoperable use, probably in an insecure fashion. > > > ... > > >>> (a) Putative cert usage 3, "exact server credential" additive + > > >>> restrictive association. > > > ... > > >> My objection is to (a). > > > > > > It is not clear to me what you mean when you say "until [(a)] can be > > > used in TLS," and therefore I do not understand your objection. From > > > my perspective, using (a) in TLS alone is logically impossible, > > > because there's nowhere to put the constraint that (a) specifies! > > > > > > Please elaborate. > > > > That's exactly correct. In current TLS, there is no way to use a bare > > SPKI. Paul Wouters and others have begun work on an extension to TLS > > that would allow a bare SPKI to be used in TLS as the server's > > authenticator. When (hopefully not just "if") that extension is > > standardized, it would make sense for TLSA to have a bare SPKI as a > > certificate type. > > I don't understand your concern. (a) is orthogonal to the use of SPKI > for matching. I will be satisfied if there is some way I can make an > additive and restrictive association of the server credential, like I > have on https://mattmccutchen.net now based on an earlier draft: "accept > the server's X.509 cert if and only if its SHA256 is > D5D73FCEBCBA047528DA062A108DD5A955F9AD8F6F7E1618E5D172DFCB12980E". Why does: $ORIGIN mattmccutchen.net. _443._tcp IN TLSA 2 0 1 ( D5D73FCEBCBA047528DA062A108DD5A9 55F9AD8F6F7E1618E5D172DFCB12980E ) Not satisfy your statement? Yes, it'll do path validation, but with the TA set to your EE cert. AIUI, that basically means "accept exactly this cert, regardless of what other TAs you have." If that's NOT what it means, that I agree that there's a problem. That said, rereading the text for usage 2, the wording is wrong: 2 -- Certificate MUST pass PKIX validation, with any certificate matching the TLSA record considered to be a trust anchor for this validation Which means that if some *other* TA will validate the certificate recieved, we'll still accept that the association matched. However, in 4.3, it says: Certificate usage 2 is used to specify a certificate, or the public key of such a certificate, that must be used as a trust anchor when validating the end entity certificate given by the server in TLS. This usage is sometimes referred to as "domain-issued certificate" because it allows for a domain name administrator to issue certificates for a domain without involving a third-party CA. However, "must" isn't in all-caps. I think that certificate usage 2 needs to say this instead, and then all will be ok again (to me): 2 -- Certificate MUST pass PKIX validation, with any certificate matching the TLSA record considered to be the only trust anchor to be used for this validation Hope this helps, -- Scott Schmit From hallam@gmail.com Fri Sep 30 05:50:11 2011 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 E255721F8AFE for ; Fri, 30 Sep 2011 05:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.481 X-Spam-Level: X-Spam-Status: No, score=-3.481 tagged_above=-999 required=5 tests=[AWL=0.118, 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 bepKQSYJRHLV for ; Fri, 30 Sep 2011 05:50:11 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 69F7321F8AF0 for ; Fri, 30 Sep 2011 05:50:10 -0700 (PDT) Received: by yic13 with SMTP id 13so1843282yic.31 for ; Fri, 30 Sep 2011 05:53:04 -0700 (PDT) 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:content-transfer-encoding; bh=bzSR+sU3IfyrnXkGWkPLARusb8JePULIt+HjKjXHJoA=; b=FGhfFHuZOyoD74DSpMwTNndXX/e4HcRgSjaZ9pbCDVb0DHsJU3a+ePnZKuuWFeBcbS stIdnIT2GsFJOXSqxF/us4fDLsBoQJvr7GGFT22EVtjjrV8rybq1R/serBnCzfIugJFw htQbJngtUDgtrWW285V+aYDtINt4mpv0186Gs= MIME-Version: 1.0 Received: by 10.100.82.6 with SMTP id f6mr10674641anb.52.1317387183289; Fri, 30 Sep 2011 05:53:03 -0700 (PDT) Received: by 10.100.212.14 with HTTP; Fri, 30 Sep 2011 05:53:03 -0700 (PDT) In-Reply-To: <444081ED-DF03-45E3-83FD-889EF53D6F03@bbn.com> References: <061.a8eeecd5d3e79d55021946fbc77943e1@trac.tools.ietf.org> <1317181872.2975.13.camel@localhost> <444081ED-DF03-45E3-83FD-889EF53D6F03@bbn.com> Date: Fri, 30 Sep 2011 08:53:03 -0400 Message-ID: From: Phillip Hallam-Baker To: "Richard L. Barnes" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dane@ietf.org Subject: Re: [dane] #37: Additive assertion of server certificate 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, 30 Sep 2011 12:50:12 -0000 PKIX attempts to maintain a separation between keys that can be used to sign keys and keys that are not. This makes a lot of sense, EE keys need to be in environments that are not well controlled. A cert signing key should not. Self signed EE certs are not part of the PKIX model. They are part of the X.509 model but not of PKIX. There is absolutely no point in checking the signature on a self-signed EE cert. On a CA root the signature validates the policy constraints (or lack thereof). On a self-signed EE cert there is no policy. As a practical matter I much prefer to see a self signed cert NOT have the cert signing bit enabled. That would be consistent with the principle of least privilege. I believe that the reason that PKIX leaves this out is that there was a consensus to encourage everyone who is managing crypto to divide their keys between key signing and EE keys. The administrative realities of Web server management will strongly favor using a separate self-signed root to create EE keys. That decouples the Web server crypto management from the DNS side. Doing it that way will make it harder for people to make mistakes. But I don't see why folk have this wrapped round their axles as nobody checks that stuff. And as for PKIX being 'complex', the world is complex. Don't fool yourselves into thinking that you are all soo much smarter than the people who did PKIX. The reason PKIX got complex was that people tried to make the scheme too simple and then it grew barnacles as necessary features were retro-fitted. You are doing exactly the same thing as the PKIX folk did in the same way and you are completely determined to learn nothing from their experience. Designing a PKI is really easy when you start from the assumption that there is one absolutely trustworthy and incorruptible party who can provide ground truth and that nobody ever makes administrative mistakes. Here we have a process where we are not even allowed to discuss the real issues that make PKI hard. The administrative model is precisely the type of thing that you need to consider now and act on if you want to have a scheme that is simpler. On Wed, Sep 28, 2011 at 12:01 AM, Richard L. Barnes wrote= : >>> This is a non-issue. =A0Using the cert as a TA means that you accept an= y >>> chain starting with that cert. =A0Since a server cert itself is a chain >>> starting with that cert (of length 1), if you put a server cert in a >>> type 2 record, it Just Works. >> >> Really? =A0What happened to "PKIX doesn't support self-signed server >> certs"? > > PKIX support for self-signed server certs is a little hazy. =A0On the one= hand, any cert that has the keyEncipherment and digitalSignature bits set = meets the requirements of RFC 5246, regardless of who issued it. =A0On the = other hand, it is standard PKIX practice to use CA certs only for signing c= erts, not for other purposes. > > Practically speaking, if PKIX libraries didn't support self-signed server= certs, we wouldn't be having this discussion. > > >> And while I don't foresee any attacks based on presenting a >> cert that chains to the designated cert rather than the designated cert >> itself, > > If an attacker can issue himself a cert under your self-signed cert, then= you're already pwned. =A0Nothing DANE can do about this case. > > >> I'd venture that I'm one of many server admins who would feel >> much better cutting the complexity of PKIX completely out of the TLS >> server authentication process. > > In the self-signed case, PKIX validation reduces to equality of certifica= tes, so there's not really any complexity. > > And the idea of "cutting the complexity of PKIX completely out of TLS" is= kind of illusory, since as other folks have pointed out, there are other r= easons for keeping PKIX around. =A0So by having a non-PKIX path, you're act= ually *adding* complexity because you have to switch between the two. > > --Richard > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > --=20 Website: http://hallambaker.com/ From bmanning@karoshi.com Fri Sep 30 06:06:18 2011 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 9EE3921F8B11 for ; Fri, 30 Sep 2011 06:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.207 X-Spam-Level: X-Spam-Status: No, score=-6.207 tagged_above=-999 required=5 tests=[AWL=0.392, 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 4Z4eLZ3JEEHC for ; Fri, 30 Sep 2011 06:06:18 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id 2DBE521F8B0F for ; Fri, 30 Sep 2011 06:06:18 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com. (8.12.8/8.12.8) with ESMTP id p8TJeF3w009966; Thu, 29 Sep 2011 19:40:22 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id p8TJeEWj009965; Thu, 29 Sep 2011 19:40:14 GMT Date: Thu, 29 Sep 2011 19:40:13 +0000 From: bmanning@vacation.karoshi.com To: dane@ietf.org Message-ID: <20110929194013.GA9948@vacation.karoshi.com.> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: bmanning@vacation.karoshi.com Subject: Re: [dane] #33: Publish enough information for the client to achieve the security of its favorite digest 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, 30 Sep 2011 13:06:18 -0000 i agree w/ steve here. No support for any of the three options. /bill On Thu, Sep 29, 2011 at 03:44:18AM -0400, Stephen Kent wrote: > > I am not in favor of any of these three options for dealing > with hash alg agility. > > Steve > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From hallam@gmail.com Fri Sep 30 06:16:43 2011 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 D919321F8B5B for ; Fri, 30 Sep 2011 06:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.482 X-Spam-Level: X-Spam-Status: No, score=-3.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 TiwEJFMnSGzw for ; Fri, 30 Sep 2011 06:16:43 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8D02621F8B54 for ; Fri, 30 Sep 2011 06:16:41 -0700 (PDT) Received: by yic13 with SMTP id 13so1867750yic.31 for ; Fri, 30 Sep 2011 06:19:35 -0700 (PDT) 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:content-transfer-encoding; bh=JPYT37nS+HRM97RXLTjCvUuJvCSKCCSF4cmlbrlBb28=; b=cvAF8g2EiKbKkGFvirNSUtqXGpSFn7CNa1Z05ZSab7w/Q0PByPqmPHsNvbm+xMKoLV WoAN8v+VGsnHfM0fZtpJ7xvUKQcjjoE8r3TaI6yAK00D0J4L5s1FdQaYqA3LIkzSNB55 5hq8fk97M3a+Z0g8G4crcMw0PbyVWzRXdsMmY= MIME-Version: 1.0 Received: by 10.101.154.22 with SMTP id g22mr6129534ano.96.1317388775211; Fri, 30 Sep 2011 06:19:35 -0700 (PDT) Received: by 10.100.212.14 with HTTP; Fri, 30 Sep 2011 06:19:34 -0700 (PDT) In-Reply-To: <4e85bf7b.1320650a.1a0e.ffffe014SMTPIN_ADDED@mx.google.com> References: <4e85bf7b.1320650a.1a0e.ffffe014SMTPIN_ADDED@mx.google.com> Date: Fri, 30 Sep 2011 09:19:34 -0400 Message-ID: From: Phillip Hallam-Baker To: bmanning@vacation.karoshi.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dane@ietf.org Subject: Re: [dane] #33: Publish enough information for the client to achieve the security of its favorite digest 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, 30 Sep 2011 13:16:44 -0000 I agree with Steve, no support for any of the mechanisms. There are two ways in which SHA-2 can break, gradually or catastrophically. If the break is gradual we will have 10-20 years to manage a transition, just like we have had with SHA-1. The reason that I beat on people mentioning SHA1 in new protocol proposals is not because I have any immediate concern for security but because we have to start getting rid of it now if we are going to succeed in completing the transition in ten years time. If the break is catastrophic then the ONLY option for remediation will be out of band updates of executables. So much other stuff will be being fixed as a result that DANE's problems will be irrelevant. On Thu, Sep 29, 2011 at 3:40 PM, wrote: > > =A0i agree w/ steve here. =A0No support for any of the three options. > > /bill > > > On Thu, Sep 29, 2011 at 03:44:18AM -0400, Stephen Kent wrote: >> >> I am not in favor of any of these three options for dealing >> with hash alg agility. >> >> Steve >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > --=20 Website: http://hallambaker.com/ From matt@mattmccutchen.net Fri Sep 30 08:41:02 2011 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 8815B21F8C20 for ; Fri, 30 Sep 2011 08:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.67 X-Spam-Level: X-Spam-Status: No, score=-2.67 tagged_above=-999 required=5 tests=[AWL=-0.071, 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 qG9kT54MLL1M for ; Fri, 30 Sep 2011 08:41:01 -0700 (PDT) Received: from homiemail-a6.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id E950321F8BF8 for ; Fri, 30 Sep 2011 08:41:01 -0700 (PDT) Received: from homiemail-a6.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTP id 1F56E598086; Fri, 30 Sep 2011 08:43:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; q=dns; s= mattmccutchen.net; b=URyEyCINEQbYe9f6yItWD2cuhkM/lEOfXA69RMspARX 0M8iUfDmek7Y8qunOHfW2R/Q5BjDZtZffXad+AEIQ8qoKYGZgZwwmTQ/4Ic6b4Z2 OFJXFSk/4XEfePywoeSXPBXKqXpa4UvbxomQNACBYfZjUeBQ5Iv0k4eVA72negM0 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; s= mattmccutchen.net; bh=fxAvyO67ExBCu6MxupcZQ+jSIPs=; b=g+rMVNuIIV 9MmxPBs6S34NLyyRTu1ppBLizuMT7cotOG20YyL4f4PaxSCI4MuydAyExKHi5B/I mnfZrzFoRnlxCBKuH/UiUQEEtTkAHezcvQrsU7TzuFjnyZG0hafW1+8gePh6xwUJ kaDa2zEWpNItHYgjmKY2hE/5UrGiEcWN8= 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 CD974598084; Fri, 30 Sep 2011 08:43:55 -0700 (PDT) From: Matt McCutchen To: Scott Schmit Date: Fri, 30 Sep 2011 08:43:54 -0700 In-Reply-To: <20110930112848.GA11338@odin.ulthar.us> References: <42D80BDE-458A-45F5-859C-CA955A6D7D4B@bbn.com> <1317224748.2975.49.camel@localhost> <001F15D5-0861-4CE2-8148-3EBC9B55C2B0@bbn.com> <1317280974.1974.7.camel@localhost> <9D9F3143-3C99-4B55-8708-274790D6CD93@vpnc.org> <1317363336.2130.24.camel@localhost> <20110930112848.GA11338@odin.ulthar.us> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 Content-Transfer-Encoding: 7bit Message-ID: <1317397436.2130.31.camel@localhost> Mime-Version: 1.0 Cc: dane@ietf.org Subject: Re: [dane] #37: Additive assertion of server certificate 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, 30 Sep 2011 15:41:02 -0000 On Fri, 2011-09-30 at 07:28 -0400, Scott Schmit wrote: > Why does: > > $ORIGIN mattmccutchen.net. > _443._tcp IN TLSA 2 0 1 ( D5D73FCEBCBA047528DA062A108DD5A9 > 55F9AD8F6F7E1618E5D172DFCB12980E ) > > Not satisfy your statement? Yes, it'll do path validation, but with the > TA set to your EE cert. AIUI, that basically means "accept exactly this > cert, regardless of what other TAs you have." Like I said before in this thread, we have to make sure this approach actually works with the PKIX library, and I would be exposed to any bugs in the library by which someone could make it think that another cert chains to mine or any unpleasant effects of the validation process itself (AIA fetching). -- Matt From paul.hoffman@vpnc.org Fri Sep 30 09:21:44 2011 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 DBAA921F8CEE for ; Fri, 30 Sep 2011 09:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 mQCD+Ibhllx7 for ; Fri, 30 Sep 2011 09:21:44 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0BAF221F8CEA for ; Fri, 30 Sep 2011 09:21:43 -0700 (PDT) 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 p8UGObr0022693 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 30 Sep 2011 09:24:38 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1244.3) From: Paul Hoffman In-Reply-To: <4E856FB8.9000301@sidn.nl> Date: Fri, 30 Sep 2011 09:24:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201109272223.p8RMNPpA026467@fs4113.wdf.sap.corp> <4E856FB8.9000301@sidn.nl> To: IETF DANE WG list X-Mailer: Apple Mail (2.1244.3) Subject: Re: [dane] #36: Only requiring DNSSEC where it is needed 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, 30 Sep 2011 16:21:45 -0000 On Sep 30, 2011, at 12:28 AM, Antoin Verschuren wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 29-09-11 18:54, Zack Weinberg wrote: >> On Tue, Sep 27, 2011 at 7:00 PM, Richard L. Barnes = wrote: >>> Paul beat me to it. With type 0/1 certs, the attacker can only = block the DANE repudiation. >>> That's why there's not strictly a need for DNSSEC in that case. >>=20 >> Even though this is the case, I do not like the idea of relaxing the >> requirement for DNSSEC to just some types of TLSA record. I prefer >> the operational simplicity of "MUST use DNSSEC" and the client-side >> implementation simplicity of "MUST ignore all TLSA records that are >> DNSSEC-insecure". >=20 > +1 > Maintaining when and in what circumstances TLSA should/should > not/must/must not be signed is adding complexity that is more likely = to > become broken than the simple rule now that it MUST allways be signed, On the topic of complexity, I note that this only adds one bit that must = be checked for one certificate type. Under the proposal, for certificate = type 2, you must also check if DNSSEC was used. If you receive a type 0 = or 1, you don't even check if DNSSEC was used. (I will nudge Martin on = my proposed addition to make that clearer.) --Paul Hoffman From paul.hoffman@vpnc.org Fri Sep 30 09:23:22 2011 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 96D8521F8B1A for ; Fri, 30 Sep 2011 09:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 vh6ZT+m9HNXt for ; Fri, 30 Sep 2011 09:23:22 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF4021F8AE9 for ; Fri, 30 Sep 2011 09:23:21 -0700 (PDT) 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 p8UGQEx9023587 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 30 Sep 2011 09:26:15 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <201109272253.p8RMrPuF028176@fs4113.wdf.sap.corp> Date: Fri, 30 Sep 2011 09:26:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201109272253.p8RMrPuF028176@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1244.3) Cc: dane@ietf.org Subject: Re: [dane] #36: Only requiring DNSSEC where it is needed 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, 30 Sep 2011 16:23:22 -0000 A nudge on one part of message. On Sep 27, 2011, at 3:53 PM, Martin Rex wrote: >> If DNSSEC protection is obviated, then an attacker could not only >> block the DANE repudiation, but even insert a false confirmation >> for a fraudulently issued cert and create a false sense of security. Would your concern be dealt with if we added wording saying "if a type 0 = or 1 cert is received without DNSSEC, the application MUST NOT make any = UI or log assertion that the certificate is more trusted than it would = normally have been from TLS"? --Paul Hoffman From paul@xelerance.com Fri Sep 30 09:44:49 2011 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 82CF921F8BB5 for ; Fri, 30 Sep 2011 09:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.474 X-Spam-Level: X-Spam-Status: No, score=-4.474 tagged_above=-999 required=5 tests=[AWL=-1.875, 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 HMVLLQRVp9GD for ; Fri, 30 Sep 2011 09:44:48 -0700 (PDT) Received: from mx.xelerance.com (mx.xelerance.com [193.110.157.188]) by ietfa.amsl.com (Postfix) with ESMTP id A49CE21F8B53 for ; Fri, 30 Sep 2011 09:44:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx.xelerance.com (Postfix) with ESMTP id 79173F29; Fri, 30 Sep 2011 12:47:36 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xelerance.com; h= content-type:content-type:mime-version:user-agent:references :message-id:in-reply-to:subject:subject:from:from:date:date :received:received:received:received; s=smtp; t=1317401255; x= 1318006055; bh=AJR15EBKxnQBZz0t0o8J+2v051N45xZEhAZYLfdPmsA=; b=C /nl0qiSoa/q41KPTS167qG12WO9b1ujfPQMCnZxjKIzNjpPE7E0FC/dzYC4Zmjnu qukKl1yh9JM6k/b8cy1jhlwGUNdGEIbkM8qL6HGqi++eQO1fNFsLefPRI1MQcIjc pjaKIZ9qzjF5BnMmaP+uH+VLHNcmpJzdnogNnxymPM= Received: from mx.xelerance.com ([127.0.0.1]) by localhost (mx.xelerance.com [127.0.0.1]) (amavisd-new, port 10026) with LMTP id NwlY-12ODYjg; Fri, 30 Sep 2011 12:47:35 -0400 (EDT) Received: from mail.xelerance.com (mail.xelerance.com [193.110.157.189]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.xelerance.com (Postfix) with ESMTPS id 04322F24; Fri, 30 Sep 2011 12:47:35 -0400 (EDT) Received: by mail.xelerance.com (Postfix, from userid 1001) id C872019E7; Fri, 30 Sep 2011 12:47:32 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.xelerance.com (Postfix) with ESMTP id C74D1F17; Fri, 30 Sep 2011 12:47:32 -0400 (EDT) Date: Fri, 30 Sep 2011 12:47:32 -0400 (EDT) From: Paul Wouters To: Paul Hoffman In-Reply-To: Message-ID: References: <201109272253.p8RMrPuF028176@fs4113.wdf.sap.corp> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dane@ietf.org Subject: Re: [dane] #36: Only requiring DNSSEC where it is needed 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, 30 Sep 2011 16:44:49 -0000 On Fri, 30 Sep 2011, Paul Hoffman wrote: > A nudge on one part of message. > > On Sep 27, 2011, at 3:53 PM, Martin Rex wrote: > >>> If DNSSEC protection is obviated, then an attacker could not only >>> block the DANE repudiation, but even insert a false confirmation >>> for a fraudulently issued cert and create a false sense of security. > > Would your concern be dealt with if we added wording saying "if a type 0 or 1 cert is received without DNSSEC, the application MUST NOT make any UI or log assertion that the certificate is more trusted than it would normally have been from TLS"? That comes close to "An application SHOULD ignore a TLSA record if received without DNSSEC". At which point, the step to MUST is pretty small. Paul From paul.hoffman@vpnc.org Fri Sep 30 09:57:06 2011 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 EF12721F8A80 for ; Fri, 30 Sep 2011 09:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 xdXkmzt2UEwb for ; Fri, 30 Sep 2011 09:57:06 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE1521F84AC for ; Fri, 30 Sep 2011 09:57:06 -0700 (PDT) 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 p8UGxxMT040935 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 30 Sep 2011 10:00:00 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Fri, 30 Sep 2011 10:00:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3E15A865-0F60-484C-A27E-FBED2F755406@vpnc.org> References: <201109272253.p8RMrPuF028176@fs4113.wdf.sap.corp> To: Paul Wouters X-Mailer: Apple Mail (2.1244.3) Cc: dane@ietf.org Subject: Re: [dane] #36: Only requiring DNSSEC where it is needed 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, 30 Sep 2011 16:57:07 -0000 On Sep 30, 2011, at 9:47 AM, Paul Wouters wrote: > On Fri, 30 Sep 2011, Paul Hoffman wrote: >=20 >> A nudge on one part of message. >>=20 >> On Sep 27, 2011, at 3:53 PM, Martin Rex wrote: >>=20 >>>> If DNSSEC protection is obviated, then an attacker could not only >>>> block the DANE repudiation, but even insert a false confirmation >>>> for a fraudulently issued cert and create a false sense of = security. >>=20 >> Would your concern be dealt with if we added wording saying "if a = type 0 or 1 cert is received without DNSSEC, the application MUST NOT = make any UI or log assertion that the certificate is more trusted than = it would normally have been from TLS"? >=20 > That comes close to "An application SHOULD ignore a TLSA record if = received without DNSSEC". Oh, please. First, it is only about type 0 and 1. Second, there is = nothing about ignoring, just about not highlighting the security. There = is nothing "close" at all. It's clear that all you care about is type 2 and, in the future, type = 3ish that is for non-cert keys. No one is forcing you to implement a = client that accepts type 0 or 1. Others have expressed a strong interest = in types 0 and 1, and that's what this proposal addresses. --Paul Hoffman From zack.weinberg@gmail.com Fri Sep 30 10:53:30 2011 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 2D40C21F8B00 for ; Fri, 30 Sep 2011 10:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.044 X-Spam-Level: X-Spam-Status: No, score=-3.044 tagged_above=-999 required=5 tests=[AWL=-0.067, 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 l51vME7nRG6Y for ; Fri, 30 Sep 2011 10:53:29 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8688321F8AFE for ; Fri, 30 Sep 2011 10:53:29 -0700 (PDT) Received: by qadb12 with SMTP id b12so669932qad.31 for ; Fri, 30 Sep 2011 10:56:23 -0700 (PDT) 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=q644wYx0JonL9qB0ZEUh8B1/tfOeD7AHEsuRO46ndlc=; b=n0dweGx+/dZjSn2a0/4nx2aVttDMMtGfo+H7VOke6QSb8n6Vtsm87zWYDmfx6VLDLr lT5Wz82sm/gYR/03Mve7iu9dQDH1zEmdmpOmpSApiDml2AiCbyQbyMx9KXlEu2J4X2gG BJZs7limoIjcyQLVv1MHhxT4UFC0GH1VbAYb0= MIME-Version: 1.0 Received: by 10.68.14.231 with SMTP id s7mr59452612pbc.87.1317405383477; Fri, 30 Sep 2011 10:56:23 -0700 (PDT) Sender: zack.weinberg@gmail.com Received: by 10.68.59.105 with HTTP; Fri, 30 Sep 2011 10:56:23 -0700 (PDT) In-Reply-To: References: <201109272223.p8RMNPpA026467@fs4113.wdf.sap.corp> <4E856FB8.9000301@sidn.nl> Date: Fri, 30 Sep 2011 10:56:23 -0700 X-Google-Sender-Auth: wL2FXmoFV1iKjlIGR0_iVcq4FFg 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] #36: Only requiring DNSSEC where it is needed 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, 30 Sep 2011 17:53:30 -0000 On Fri, Sep 30, 2011 at 9:24 AM, Paul Hoffman wrote= : > On Sep 30, 2011, at 12:28 AM, Antoin Verschuren wrote: >> On 29-09-11 18:54, Zack Weinberg wrote: >>> [...] I do not like the idea of relaxing the >>> requirement for DNSSEC to just some types of TLSA record. =C2=A0I prefe= r >>> the operational simplicity of "MUST use DNSSEC" and the client-side >>> implementation simplicity of "MUST ignore all TLSA records that are >>> DNSSEC-insecure". >> >> +1 >> Maintaining when and in what circumstances TLSA should/should >> not/must/must not be signed is adding complexity that is more likely to >> become broken than the simple rule now that it MUST allways be signed, > > On the topic of complexity, I note that this only adds one bit that must = be > checked for one certificate type. Under the proposal, for certificate typ= e 2, > you must also check if DNSSEC was used. If you receive a type 0 or 1, > you don't even check if DNSSEC was used. No, because the DANE client has to reject the TLS handshake regardless of cert type if it gets a DNSSEC-bogus or DNSSEC-stripped response. Therefore, your proposal involves looking at DNSSEC status twice: first before parsing the record, and then again afterward. (Obviously the actual signature check only has to happen once.) Under my/Antoin/Paul W's preferred scheme, you only have to look at DNSSEC status once, before parsing the record. Fewer steps, easier to code correctly. zw From mrex@sap.com Fri Sep 30 10:54:05 2011 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 4171021F8AFE for ; Fri, 30 Sep 2011 10:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.068 X-Spam-Level: X-Spam-Status: No, score=-10.068 tagged_above=-999 required=5 tests=[AWL=0.181, 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 sJ5S6Xr0OvTg for ; Fri, 30 Sep 2011 10:54:04 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 2868721F8AEC for ; Fri, 30 Sep 2011 10:54:03 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p8UHuuGl027649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 30 Sep 2011 19:56:56 +0200 (MEST) From: Martin Rex Message-Id: <201109301756.p8UHutP0028352@fs4113.wdf.sap.corp> To: paul.hoffman@vpnc.org (Paul Hoffman) Date: Fri, 30 Sep 2011 19:56:55 +0200 (MEST) In-Reply-To: from "Paul Hoffman" at Sep 30, 11 09:26:14 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] #36: Only requiring DNSSEC where it is needed 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, 30 Sep 2011 17:54:05 -0000 Paul Hoffman wrote: > > Martin Rex wrote: > > > > > If DNSSEC protection is obviated, then an attacker could not only > > > block the DANE repudiation, but even insert a false confirmation > > > for a fraudulently issued cert and create a false sense of security. > > Would your concern be dealt with if we added wording saying > "if a type 0 or 1 cert is received without DNSSEC, the application > MUST NOT make any UI or log assertion that the certificate is > more trusted than it would normally have been from TLS"? I may have to think a little more about the details, but it somehow does not feel right. This suggestion would make a DANE-aware TLS client behave equivalent to a pre-DANE client for such servers. Although this would not *add* any additional false sense of security, there is the underlying expectation "my TLS client is DANE-aware", creating a level of expectation that could then no longer be met. One of these expectations (my personal favourite) is that fraudulently or accidentally issued TLS server cert will never be considered valid by the TLS client if the DNS admin has published TLSA records for his server. With respect to (additional) UI chrome for DANE-confirmed server certs, we might have to distinguish specific DNSSEC failure cases. - is the TLS client DNSSEC capable, but can not obtain the necessary DNSSEC records? (due to a home gateway, firewall ... or an attacker) - did the TLS client obtain all existing DNSSEC records, but there simply are not any TLSA records provided by the DNS admin - the client obtained TLSA records without DNSSEC protection, but none of those TLSA records are supported by the TLS clients DANE implementation -- what does it mean (and is that what consumers will expect)? -Martin From zack.weinberg@gmail.com Fri Sep 30 11:00:53 2011 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 68D4721F84D6 for ; Fri, 30 Sep 2011 11:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.04 X-Spam-Level: X-Spam-Status: No, score=-3.04 tagged_above=-999 required=5 tests=[AWL=-0.062, 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 NkfZGe5OMGZQ for ; Fri, 30 Sep 2011 11:00:53 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id D337B21F8BE8 for ; Fri, 30 Sep 2011 11:00:52 -0700 (PDT) Received: by qadb12 with SMTP id b12so676454qad.31 for ; Fri, 30 Sep 2011 11:03:47 -0700 (PDT) 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=m7tflwHx3j+FKlqcwiSblH51skqR2M5f4cUGR1/u6Qk=; b=jXaO5fahXjIlpWVT/H7ytZWzaQKQRw66H447GHwAmilqhfuWU2kRUKQHC9wjl8Ve1g FAvx3V6oCMBVbuD40cyyY6WVJKXW4akg7C0DwgTy6uRxWEYP+TJZH8aX1iLeYEGp09ZM XXYTKzRuisbbK9vczNPdqnaIqd9de4K2CfoEM= MIME-Version: 1.0 Received: by 10.68.11.168 with SMTP id r8mr7230152pbb.19.1317405826719; Fri, 30 Sep 2011 11:03:46 -0700 (PDT) Sender: zack.weinberg@gmail.com Received: by 10.68.59.105 with HTTP; Fri, 30 Sep 2011 11:03:46 -0700 (PDT) In-Reply-To: <1317360012.2130.8.camel@localhost> References: <061.add9f922b5dfb2db7544981f78552e7e@trac.tools.ietf.org> <076.bdd0467de056ddca69582bc0104dce57@trac.tools.ietf.org> <1317264820.2975.58.camel@localhost> <1317360012.2130.8.camel@localhost> Date: Fri, 30 Sep 2011 11:03:46 -0700 X-Google-Sender-Auth: h1DC4O7Q1_1bwa_7URyelcV4ZHI 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] #33: Publish enough information for the client to achieve the security of its favorite digest 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, 30 Sep 2011 18:00:53 -0000 On Thu, Sep 29, 2011 at 10:20 PM, Matt McCutchen w= rote: > On Thu, 2011-09-29 at 09:27 -0700, Zack Weinberg wrote: >> > 1. All digests of one cert in one RR >> -1: unwieldy, complicates client-side processing. > > I'm curious why you say this. =C2=A0This approach provides exactly the sa= me > data as the group ID approach, just in a different format that avoids > the redundancy in the cert usage and selector fields and avoids the need > for admins using only one digest to think about group IDs. Right now, the data portion of the RR is an opaque blob of known length, which regardless of the opcodes, will be fed to memcmp(). (What you do to get the *other* argument to memcmp() varies with selector and reference type, and what you do after the check varies with usage type.) To put all digests of one cert in one RR, you would need to define a parseable format for the data portion. As far as I know there is no other RR that needs this treatment, so we'd be making up something new and adding code to all clients. If we keep it to one digest per RR, we get the same functionality for free. You make a good point about the redundant opcodes and extra work for admins, but right now I don't think it outweighs the disadvantage of more parsing code. zw From paul.hoffman@vpnc.org Fri Sep 30 11:16:37 2011 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 97B8721F8BEC for ; Fri, 30 Sep 2011 11:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 9GCQ8ayZF++O for ; Fri, 30 Sep 2011 11:16:37 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id D6A8E21F8BBB for ; Fri, 30 Sep 2011 11:16:36 -0700 (PDT) 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 p8UIJU9l085394 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 30 Sep 2011 11:19:31 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Fri, 30 Sep 2011 11:19:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201109272223.p8RMNPpA026467@fs4113.wdf.sap.corp> <4E856FB8.9000301@sidn.nl> To: Zack Weinberg X-Mailer: Apple Mail (2.1244.3) Cc: IETF DANE WG list Subject: Re: [dane] #36: Only requiring DNSSEC where it is needed 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, 30 Sep 2011 18:16:37 -0000 On Sep 30, 2011, at 10:56 AM, Zack Weinberg wrote: > On Fri, Sep 30, 2011 at 9:24 AM, Paul Hoffman = wrote: >> On Sep 30, 2011, at 12:28 AM, Antoin Verschuren wrote: >>> On 29-09-11 18:54, Zack Weinberg wrote: >>>> [...] I do not like the idea of relaxing the >>>> requirement for DNSSEC to just some types of TLSA record. I prefer >>>> the operational simplicity of "MUST use DNSSEC" and the client-side >>>> implementation simplicity of "MUST ignore all TLSA records that are >>>> DNSSEC-insecure". >>>=20 >>> +1 >>> Maintaining when and in what circumstances TLSA should/should >>> not/must/must not be signed is adding complexity that is more likely = to >>> become broken than the simple rule now that it MUST allways be = signed, >>=20 >> On the topic of complexity, I note that this only adds one bit that = must be >> checked for one certificate type. Under the proposal, for certificate = type 2, >> you must also check if DNSSEC was used. If you receive a type 0 or 1, >> you don't even check if DNSSEC was used. >=20 > No, because the DANE client has to reject the TLS handshake regardless > of cert type if it gets a DNSSEC-bogus or DNSSEC-stripped response. I don't think that is right, but I want to check your logic. Is your = scenario that an attacker injects a type 0 or type 1 TLSA record and = either leaves in DNSSEC (bogus) or strips it (stripped)? If so, what is = the attacker's motive? He will not achieve anything because TLS was = dropped. This attack is no different than sending a bogus A record to a = TLS proxy that cannot impersonate the intended server, or to anyplace = where TLS won't happen correctly. If that isn't your attack scenario, what is? > Therefore, your proposal involves looking at DNSSEC status twice: > first before parsing the record, and then again afterward. (Obviously > the actual signature check only has to happen once.) No, our proposal doesn't involve looking at DNSSEC ever if the type is 0 = or 1. > Under my/Antoin/Paul W's preferred scheme, you only have to look at > DNSSEC status once, before parsing the record. =20 Agree. > Fewer steps, easier to > code correctly. Again, I believe the new proposal adds one step: "if you received a type = 2 response, make sure it was covered with DNSSEC". That's the same = number of steps as "if you received any response, make sure it was = covered with DNSSEC". --Paul Hoffman From paul.hoffman@vpnc.org Fri Sep 30 11:24:31 2011 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 2352221F8B35 for ; Fri, 30 Sep 2011 11:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 o-WrlwHiZm8O for ; Fri, 30 Sep 2011 11:24:30 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7204F21F8B29 for ; Fri, 30 Sep 2011 11:24:30 -0700 (PDT) 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 p8UIRNg4089643 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 30 Sep 2011 11:27:24 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <201109301756.p8UHutP0028352@fs4113.wdf.sap.corp> Date: Fri, 30 Sep 2011 11:27:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <496D847F-7D67-41E2-9751-DE34B6200E40@vpnc.org> References: <201109301756.p8UHutP0028352@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1244.3) Cc: dane@ietf.org Subject: Re: [dane] #36: Only requiring DNSSEC where it is needed 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, 30 Sep 2011 18:24:31 -0000 On Sep 30, 2011, at 10:56 AM, Martin Rex wrote: > Paul Hoffman wrote: >>=20 >> Martin Rex wrote: >>>=20 >>>> If DNSSEC protection is obviated, then an attacker could not only >>>> block the DANE repudiation, but even insert a false confirmation >>>> for a fraudulently issued cert and create a false sense of = security. >>=20 >> Would your concern be dealt with if we added wording saying >> "if a type 0 or 1 cert is received without DNSSEC, the application >> MUST NOT make any UI or log assertion that the certificate is >> more trusted than it would normally have been from TLS"? >=20 > I may have to think a little more about the details, but it somehow > does not feel right. >=20 > This suggestion would make a DANE-aware TLS client behave equivalent > to a pre-DANE client for such servers. Although this would not > *add* any additional false sense of security, there is the underlying > expectation "my TLS client is DANE-aware", creating a level of > expectation that could then no longer be met. One of these > expectations (my personal favourite) is that fraudulently or = accidentally > issued TLS server cert will never be considered valid by the TLS = client > if the DNS admin has published TLSA records for his server. OK, I can start to see your concern. Would "my browser is now TLSA = aware, so it is protecting me against things which I don't understand" = be a reasonable paraphrase? If so, I agree that not forcing every = response to be DNSSEC-assured would probably not meet the expectations = of those users. Having said that, *every* security improvement that is being discussed = won't meet those expectations. Any TOFU-based proposals in the websec WG = have the same problems. For that matter, all versions of TLS that allow = fallback have the same problems. This seems like too high of a bar for = some, but others might want the bar that high. > With respect to (additional) UI chrome for DANE-confirmed server > certs, we might have to distinguish specific DNSSEC failure cases. >=20 > - is the TLS client DNSSEC capable, but can not obtain the necessary > DNSSEC records? (due to a home gateway, firewall ... or an attacker) >=20 > - did the TLS client obtain all existing DNSSEC records, but there = simply > are not any TLSA records provided by the DNS admin >=20 > - the client obtained TLSA records without DNSSEC protection, but > none of those TLSA records are supported by the TLS clients DANE > implementation -- what does it mean (and is that what consumers > will expect)? That kind of list is exactly what I want to avoid. It leads to the same = madness as the UI chrome for plain PKIX: "that cert was valid yesterday, = but it expired today, and even though I have no indication that the key = has been compromised, I'm suggesting you reject it" and its ilk. --Paul Hoffman From ajs@anvilwalrusden.com Fri Sep 30 11:28:45 2011 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 E252921F8B00 for ; Fri, 30 Sep 2011 11:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 nhcEnHmb93TC for ; Fri, 30 Sep 2011 11:28:45 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 5714C21F8AEC for ; Fri, 30 Sep 2011 11:28:41 -0700 (PDT) Received: from shinkuro.com (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 03E921ECB41C for ; Fri, 30 Sep 2011 18:31:29 +0000 (UTC) Date: Fri, 30 Sep 2011 14:31:33 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20110930183133.GB38562@shinkuro.com> References: <201109272223.p8RMNPpA026467@fs4113.wdf.sap.corp> <4E856FB8.9000301@sidn.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] #36: Only requiring DNSSEC where it is needed 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, 30 Sep 2011 18:28:46 -0000 On Fri, Sep 30, 2011 at 11:19:30AM -0700, Paul Hoffman wrote: > > No, our proposal doesn't involve looking at DNSSEC ever if the type is 0 or 1. A validating resolver is going to look at the DNSSEC anyway, isn't it? A -- Andrew Sullivan ajs@crankycanuck.ca From paul.hoffman@vpnc.org Fri Sep 30 11:50:07 2011 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 BE32221F8B76 for ; Fri, 30 Sep 2011 11:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 nyTmboiXE6TR for ; Fri, 30 Sep 2011 11:50:07 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 20FA621F8B58 for ; Fri, 30 Sep 2011 11:50:07 -0700 (PDT) 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 p8UIqtbc005170 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 30 Sep 2011 11:52:56 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20110930183133.GB38562@shinkuro.com> Date: Fri, 30 Sep 2011 11:52:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5D2103D1-64E4-48CD-BF65-B0EF351622DC@vpnc.org> References: <201109272223.p8RMNPpA026467@fs4113.wdf.sap.corp> <4E856FB8.9000301@sidn.nl> <20110930183133.GB38562@shinkuro.com> To: Andrew Sullivan X-Mailer: Apple Mail (2.1244.3) Cc: dane@ietf.org Subject: Re: [dane] #36: Only requiring DNSSEC where it is needed 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, 30 Sep 2011 18:50:07 -0000 On Sep 30, 2011, at 11:31 AM, Andrew Sullivan wrote: > On Fri, Sep 30, 2011 at 11:19:30AM -0700, Paul Hoffman wrote: >>=20 >> No, our proposal doesn't involve looking at DNSSEC ever if the type = is 0 or 1. >=20 > A validating resolver is going to look at the DNSSEC anyway, isn't it? Certainly. The question is whether the *application* needs to know = whether or not DNSSEC validated on the DNS records, such as through some = future DNS API or through the application itself being a DNS validating = resolver. --Paul Hoffman From zack.weinberg@gmail.com Fri Sep 30 13:37:29 2011 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 8932121F8876 for ; Fri, 30 Sep 2011 13:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.036 X-Spam-Level: X-Spam-Status: No, score=-3.036 tagged_above=-999 required=5 tests=[AWL=-0.059, 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 T5cOtrCEnVcC for ; Fri, 30 Sep 2011 13:37:29 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id DB91821F886A for ; Fri, 30 Sep 2011 13:37:28 -0700 (PDT) Received: by yxt33 with SMTP id 33so2358248yxt.31 for ; Fri, 30 Sep 2011 13:40:23 -0700 (PDT) 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=EkCEZaKq4FDH2kZnPsvORhhb+XeCjJpIKVOiSmorWvc=; b=kCa3zioDQnAzn2jvepnkBAxBKDZQpLC/iUWIvOSnaT7d2ASBvdldLARvb8A6V/eg+Z /WeqTzfddeM5oCX0twWlWWB3Z5aOWnQ0yKyVifNse0fz1i6kHXIJJt8EcwYg7M71q/Kz mNcdZcxXXqdyISh9HISXf486auTzcRS8qCVbI= MIME-Version: 1.0 Received: by 10.68.17.1 with SMTP id k1mr61034924pbd.53.1317415223175; Fri, 30 Sep 2011 13:40:23 -0700 (PDT) Sender: zack.weinberg@gmail.com Received: by 10.68.59.105 with HTTP; Fri, 30 Sep 2011 13:40:23 -0700 (PDT) In-Reply-To: References: <201109272223.p8RMNPpA026467@fs4113.wdf.sap.corp> <4E856FB8.9000301@sidn.nl> Date: Fri, 30 Sep 2011 13:40:23 -0700 X-Google-Sender-Auth: v9WyUyWDW38G58FkUf4okoIuL0k Message-ID: From: Zack Weinberg To: IETF DANE WG list Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [dane] Fwd: #36: Only requiring DNSSEC where it is needed 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, 30 Sep 2011 20:37:29 -0000 Meant to send this to the list. ---------- Forwarded message ---------- From: Zack Weinberg Date: Fri, Sep 30, 2011 at 1:39 PM Subject: Re: [dane] #36: Only requiring DNSSEC where it is needed To: Paul Hoffman On Fri, Sep 30, 2011 at 11:19 AM, Paul Hoffman wrot= e: > On Sep 30, 2011, at 10:56 AM, Zack Weinberg wrote: >>> On the topic of complexity, I note that this only adds one bit that mus= t be >>> checked for one certificate type. Under the proposal, for certificate t= ype 2, >>> you must also check if DNSSEC was used. If you receive a type 0 or 1, >>> you don't even check if DNSSEC was used. >> >> No, because the DANE client has to reject the TLS handshake regardless >> of cert type if it gets a DNSSEC-bogus or DNSSEC-stripped response. > > I don't think that is right, but I want to check your logic. Is your scen= ario that > an attacker injects a type 0 or type 1 TLSA record and either leaves in > DNSSEC (bogus) or strips it (stripped)? If so, what is the attacker's mot= ive? > He will not achieve anything because TLS was dropped. This attack is no > different than sending a bogus A record to a TLS proxy that cannot > impersonate the intended server, or to anyplace where TLS won't happen > correctly. In the hypothetical, we're allowing unauthenticated type 0 or type 1 records; however, a site admin who chooses to deploy DNSSEC with those record types reasonably expects that this will prevent an attacker from removing said records or substituting their own. Suppose that victim.example has deployed DNSSEC, and the zone contains a type 0 TLSA record limiting www.victim.example's server certificates to CA "alpha". =C2=A0Suppose a network attacker who has, somehow, obtained a certificate for www.victim.example signed by CA "beta". =C2=A0Both "alpha" and "beta" are in the root pool of all clients of interest. The attacker interposes on DNS traffic for www.victim.example, strips all DNSSEC and TLSA records, and modifies the A record to point to its own server, which claims to be www.victim.example and provides the certificate from CA "beta" as authentication. A DANE client that ignores DNSSEC validation under any circumstances -- note that in this scenario, it doesn't get any TLSA records back at all! -- will not defend against this attack; but a client that treats DNSSEC "bogus" or "stripped" states as a hard failure, regardless of TLSA contents, will defend. > Again, I believe the new proposal adds one step: "if you received a type = 2 > response, make sure it was covered with DNSSEC". That's the same > number of steps as "if you received any response, make sure it was > covered with DNSSEC". I hope I have demonstrated that this is inadequate. zw From ietf@augustcellars.com Fri Sep 30 17:13:02 2011 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 1029921F8A55 for ; Fri, 30 Sep 2011 17:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.946 X-Spam-Level: X-Spam-Status: No, score=-2.946 tagged_above=-999 required=5 tests=[AWL=-0.347, 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 BMUMBgp9IJCx for ; Fri, 30 Sep 2011 17:13:01 -0700 (PDT) Received: from samuel.augustcellars.com (exodus.augustcellars.com [207.202.179.27]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA0B21F8A4B for ; Fri, 30 Sep 2011 17:13:01 -0700 (PDT) Received: from JUDGES.augustcellars.com (192.168.2.1) by samuel.augustcellars.com (192.168.2.2) with Microsoft SMTP Server (TLS) id 14.0.722.0; Wed, 28 Sep 2011 22:28:10 -0700 Received: from Tobias (192.168.2.67) by JUDGES.augustcellars.com (192.168.2.1) with Microsoft SMTP Server (TLS) id 14.0.639.21; Wed, 28 Sep 2011 23:01:34 -0700 From: Jim Schaad To: 'Warren Kumari' References: <061.add9f922b5dfb2db7544981f78552e7e@trac.tools.ietf.org> <076.bdd0467de056ddca69582bc0104dce57@trac.tools.ietf.org> In-Reply-To: Date: Wed, 28 Sep 2011 23:01:34 -0700 Message-ID: <018f01cc7e6d$3e5bcb40$bb1361c0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us thread-index: AQGqV/NYaMZUb0EGgPiIEwsDW0qOvQGqlXZOAkimwEmViJCcsA== Cc: dane@ietf.org Subject: Re: [dane] #33: Publish enough information for the client to achieve the security of its favorite digest 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, 01 Oct 2011 00:13:02 -0000 I do not support this modification. Jim -----Original Message----- From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of Warren Kumari Sent: Wednesday, September 28, 2011 2:03 PM To: dane issue tracker Cc: draft-ietf-dane-protocol@tools.ietf.org; dane@ietf.org Subject: Re: [dane] #33: Publish enough information for the client to achieve the security of its favorite digest On Sep 28, 2011, at 11:59 AM, dane issue tracker wrote: > #33: Publish enough information for the client to achieve the security > of its favorite digest > > > Comment (by matt@.): > > So... in list discussion, I think I successfully answered all the > objections except the subjective one of "complexity". Are we ready > for a preliminary consensus call? Well, it would appear that you have decided to start one.... > I would ask that each person indicate, for each of the three proposed > solutions, whether they prefer it ''to the status quo''. If you want > this problem solved, please do not -1 a solution simply because you > prefer a different solution, or we are at risk of splitting the vote > and not getting a solution at all. And if folk do wish to show support for any of the 3 solutions I ask that they do it by Friday 13:00UTC. Explicitly stating that you do not wish to support any of the 3 would also be helpful (even if you have already said do in the thread... W > > -- > ----------------------+----------------------------------------- > Reporter: matt@. | Owner: draft-ietf-dane-protocol@. > Type: defect | Status: new > Priority: major | Milestone: > Component: protocol | Version: > Severity: - | Resolution: > Keywords: | > ----------------------+----------------------------------------- > > Ticket URL: > > dane > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane _______________________________________________ dane mailing list dane@ietf.org https://www.ietf.org/mailman/listinfo/dane From ietf@augustcellars.com Fri Sep 30 17:13:02 2011 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 4BB7A21F8A4B for ; Fri, 30 Sep 2011 17:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.936 X-Spam-Level: X-Spam-Status: No, score=-2.936 tagged_above=-999 required=5 tests=[AWL=-0.337, 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 pMHFrw4IuR9T for ; Fri, 30 Sep 2011 17:13:01 -0700 (PDT) Received: from samuel.augustcellars.com (exodus.augustcellars.com [207.202.179.27]) by ietfa.amsl.com (Postfix) with ESMTP id A4A9921F8A4E for ; Fri, 30 Sep 2011 17:13:01 -0700 (PDT) Received: from JUDGES.augustcellars.com (192.168.2.1) by samuel.augustcellars.com (192.168.2.2) with Microsoft SMTP Server (TLS) id 14.0.722.0; Wed, 28 Sep 2011 22:29:43 -0700 Received: from Tobias (192.168.2.67) by JUDGES.augustcellars.com (192.168.2.1) with Microsoft SMTP Server (TLS) id 14.0.639.21; Wed, 28 Sep 2011 23:02:46 -0700 From: Jim Schaad To: 'Matt McCutchen' References: <201109290323.p8T3NEp8004786@fs4113.wdf.sap.corp> <1317267879.2975.61.camel@localhost> In-Reply-To: <1317267879.2975.61.camel@localhost> Date: Wed, 28 Sep 2011 23:02:46 -0700 Message-ID: <019001cc7e6d$6934ba20$3b9e2e60$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us thread-index: AQF/L7m4CPUMGbkU/2EHpAdfhFDRFwJ625ZLleqkcIA= Cc: dane@ietf.org Subject: Re: [dane] #33: Publish enough information for the client to 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, 01 Oct 2011 00:13:02 -0000 You may not think it makes sense, however some of us do. -----Original Message----- From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of Matt McCutchen Sent: Wednesday, September 28, 2011 8:45 PM To: Martin Rex Cc: dane@ietf.org Subject: Re: [dane] #33: Publish enough information for the client to On Thu, 2011-09-29 at 05:23 +0200, Martin Rex wrote: > Based on how *I* interpret NIST SP800-57 (Table3 pg.64 + Table4 pg.66) > the use of SHA-256 (and SHA-256 alone) is expected safe until at least 2030. > > With that in mind, *I* am fine with no strong hash agility in place in > order to cut down on complexity. If that is the case, why support multiple hash algorithms at all? Just so Russia can use GOST? We either will or will not need to move away from SHA-256 during the lifetime of DANE. I do not see the situation in which the halfway job of algorithm agility we have now makes sense. -- Matt _______________________________________________ dane mailing list dane@ietf.org https://www.ietf.org/mailman/listinfo/dane From matt@mattmccutchen.net Fri Sep 30 22:24:54 2011 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 385F921F8B29 for ; Fri, 30 Sep 2011 22:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.668 X-Spam-Level: X-Spam-Status: No, score=-2.668 tagged_above=-999 required=5 tests=[AWL=-0.069, 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 FNOJnE50XFYM for ; Fri, 30 Sep 2011 22:24:53 -0700 (PDT) Received: from homiemail-a37.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 7164021F851A for ; Fri, 30 Sep 2011 22:24:53 -0700 (PDT) Received: from homiemail-a37.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTP id 39E2B208069; Fri, 30 Sep 2011 22:27:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; q=dns; s= mattmccutchen.net; b=OI5BVrms93BL40JneuF8JRGodtyVBKtlBXP+/0tF0DI I9R3y5o0EhmYJrVy4WNvwOSerVbLFjGTmWshv/AFCjBvZG62zkzWtKNo3b9sCuEl wuW19qPx3qZjwUWQC4zn3TnoOdmARTud0DlOLFOKBU2jxJcV84FNEvg6miRY5/e0 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; s= mattmccutchen.net; bh=hu7+JoQBS0Irahbzh/LzjCfRNPg=; b=tCQai8r1wO /6+EesBFGnCc6tjHY6fCv51SRPwcKZkXuAWSj5fYCwow3d2rpkw8CYWzdQeCQTt1 iWKZ9hArFhi+FxPe3im6ZmzkcfJ4gQHzyZa48m8oBwMvsJeWmNnRSfxmiOSpyd/U DVRC4HYUjkJOQqYebcA+Y+FF4ftMEpaMo= 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-a37.g.dreamhost.com (Postfix) with ESMTPSA id 00BC1208063; Fri, 30 Sep 2011 22:27:48 -0700 (PDT) From: Matt McCutchen To: Zack Weinberg Date: Fri, 30 Sep 2011 22:27:49 -0700 In-Reply-To: References: <061.add9f922b5dfb2db7544981f78552e7e@trac.tools.ietf.org> <076.bdd0467de056ddca69582bc0104dce57@trac.tools.ietf.org> <1317264820.2975.58.camel@localhost> <1317360012.2130.8.camel@localhost> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 Content-Transfer-Encoding: 7bit Message-ID: <1317446870.2130.49.camel@localhost> Mime-Version: 1.0 Cc: IETF DANE WG list Subject: Re: [dane] #33: Publish enough information for the client to achieve the security of its favorite digest 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, 01 Oct 2011 05:24:54 -0000 On Fri, 2011-09-30 at 11:03 -0700, Zack Weinberg wrote: > Right now, the data portion of the RR is an opaque blob of known > length, which regardless of the opcodes, will be fed to memcmp(). > (What you do to get the *other* argument to memcmp() varies with > selector and reference type, and what you do after the check varies > with usage type.) To put all digests of one cert in one RR, you would > need to define a parseable format for the data portion. Yes, it could be something trivial like: (cert usage, selector, (algorithm ID, 16-bit length, value)*) > As far as I > know there is no other RR that needs this treatment, so we'd be making > up something new and adding code to all clients. If we keep it to one > digest per RR, we get the same functionality for free. What functionality are you envisioning reusing? For RR pretty-printing in DNS libraries, it's true that using group IDs would leave us with less to change with respect to DS. But DNS libraries do not generally parse RRs for applications (aside from CNAME and DNAME, which operate beneath the level of a DNS query), so either way, we would be implementing the parsing in the DANE client code. > You make a good point about the redundant opcodes and extra work for > admins, but right now I don't think it outweighs the disadvantage of > more parsing code. I'm not convinced that solution 1 does in fact require more code. I'd imagine the code to parse the RDATA into individual digest values would be comparable in size to the code to collate RRs by group ID for solution 3. The rest is two levels of iteration, either way. -- Matt From matt@mattmccutchen.net Fri Sep 30 22:41:06 2011 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 B2FD321F8B59 for ; Fri, 30 Sep 2011 22:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.666 X-Spam-Level: X-Spam-Status: No, score=-2.666 tagged_above=-999 required=5 tests=[AWL=-0.067, 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 VwZVp5hdu6le for ; Fri, 30 Sep 2011 22:41:06 -0700 (PDT) Received: from homiemail-a61.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 2170421F8B3E for ; Fri, 30 Sep 2011 22:41:06 -0700 (PDT) Received: from homiemail-a61.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a61.g.dreamhost.com (Postfix) with ESMTP id 8D6ED57806E; Fri, 30 Sep 2011 22:44:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; q=dns; s= mattmccutchen.net; b=LSUW+Nm0O7K7xS1BengZsVZCCpPClzbL39iWmYAtrvx RwQOYxZcvAXUO/e0Rxd04ROtr5pwCu7I4sbsZ3giv8OBLIBAcmOAS6TMvtMIrM2F E710fxL5NUlllmPCdFZ2qvopNUAXgRfmduZvUCWRdIprfQIuti+8Rcnie63OH4mM = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; s= mattmccutchen.net; bh=5spiP9WmZXMmy1fn51B7+4UtOiA=; b=A0dQoNc6QD Fvr9rFL3pZ4Lr/ZQm96ZtA9HrFlcwlFtBqfEGQ5Kd5OkSTm0PgurKm4U2UpAAuL6 DqtseYETXRV5zlkusqOOo3oRsUcY7t4c8DkTAtKYsbySy/5tDVa+mKzJTFmdqZ7P V4+kd22xhHPwis0lsHIBE9Dq2OWHJgteE= 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-a61.g.dreamhost.com (Postfix) with ESMTPSA id 5065657806C; Fri, 30 Sep 2011 22:44:01 -0700 (PDT) From: Matt McCutchen To: Phillip Hallam-Baker Date: Fri, 30 Sep 2011 22:44:00 -0700 In-Reply-To: References: <4e85bf7b.1320650a.1a0e.ffffe014SMTPIN_ADDED@mx.google.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 Content-Transfer-Encoding: 7bit Message-ID: <1317447841.2130.61.camel@localhost> Mime-Version: 1.0 Cc: dane@ietf.org Subject: Re: [dane] #33: Publish enough information for the client to achieve the security of its favorite digest 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, 01 Oct 2011 05:41:06 -0000 On Fri, 2011-09-30 at 09:19 -0400, Phillip Hallam-Baker wrote: > There are two ways in which SHA-2 can break, gradually or catastrophically. > > If the break is gradual we will have 10-20 years to manage a > transition, just like we have had with SHA-1. The reason that I beat > on people mentioning SHA1 in new protocol proposals is not because I > have any immediate concern for security but because we have to start > getting rid of it now if we are going to succeed in completing the > transition in ten years time. As I said, I don't care how many years we have: if the uptake of the TLS renegotiation fix is any indication, some percentage of sites won't upgrade before SHA-1 becomes unacceptably weak, and mainstream browsers will drag their feet on dropping SHA-1 support for fear of losing users of those sites. But the TLS handshake at least tries to choose the strongest algorithm supported by both sides, for some opinion of strength. Contrast to X.509 certificate signatures, which by their nature cannot support downgrade-proof algorithm negotiation; in that area, the public would be stuck with exposure to SHA-1 for a while, even when they use upgraded browsers against upgraded servers. With a small extension to the DANE schema, we can at least avoid expanding this problem. > If the break is catastrophic then the ONLY option for remediation will > be out of band updates of executables. So much other stuff will be > being fixed as a result that DANE's problems will be irrelevant. Agreed. -- Matt From matt@mattmccutchen.net Fri Sep 30 23:01:21 2011 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 8D11B21F8B91 for ; Fri, 30 Sep 2011 23:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[AWL=-0.835, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_LWSHORTT=1.24] 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 EnMG84kUVWmo for ; Fri, 30 Sep 2011 23:01:20 -0700 (PDT) Received: from homiemail-a3.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id B8A5C21F8B8E for ; Fri, 30 Sep 2011 23:01:20 -0700 (PDT) Received: from homiemail-a3.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a3.g.dreamhost.com (Postfix) with ESMTP id 9097D28406C; Fri, 30 Sep 2011 23:04:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:date:in-reply-to:references:content-type:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=X+N8jReQBu4nphndnaWkT1MEVVVZIRHh02wSU3AorRw Bh17XCkUfzCwQNiGRh8TEFZ/lku7yVMhUwDFenyt44ymCOBwG9w+3p2K46fZbTjq kEGegf7mCNar461mjMEhGYLhNgZidxf2t52nwsPGqMJoGQ2vOlRcNFpd44smNw8I = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:date:in-reply-to:references:content-type :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=TJdnstzC5LV6B4SnQhc+rLUBLLw=; b=O/Ce638L4j TQory7rBNDys6eIkW7Dwnnkq5RGVQe/B0WARPovOpmiv/0z1sROWYKyX9NTMFe79 YwPpavPipwRlEDpTdRCpFstyGeNzIpTt7t72iuvmRwelKEm3LUdpy9l1lYF0GNPw YgmMpLGjJXH+qflLaiScZLG1HMHPHenOA= 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 63B1928406A; Fri, 30 Sep 2011 23:04:16 -0700 (PDT) From: Matt McCutchen To: =?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?= Date: Fri, 30 Sep 2011 23:04:15 -0700 In-Reply-To: <513EED68-99A7-47DB-9ED1-55CFD7C9BF4B@nic.cz> References: <061.add9f922b5dfb2db7544981f78552e7e@trac.tools.ietf.org> <6EB199FD-63B2-4FEA-88ED-67DB559148A0@bbn.com> <670A864B-567A-4351-AB6D-0A373AF66B9B@kumari.net> <1316658906.1941.63.camel@localhost> <042EE416-702E-47DF-8748-E5AD3E6583E1@vpnc.org> <1316754637.1941.136.camel@localhost> <513EED68-99A7-47DB-9ED1-55CFD7C9BF4B@nic.cz> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 Message-ID: <1317449056.2130.72.camel@localhost> Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Cc: DANE WG Subject: Re: [dane] #33: Publish enough information for the client to achieve the security of its favorite digest 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, 01 Oct 2011 06:01:21 -0000 On Thu, 2011-09-29 at 16:10 +0200, Ond=C5=99ej Sur=C3=BD wrote: > On 23. 9. 2011, at 7:10, Matt McCutchen wrote: > > On Thu, 2011-09-22 at 07:55 -0700, Paul Hoffman wrote: > >> There is no sane way for a security protocol to fully deal with a > >> preimage weakening for any supported hash algorithm. If you believe > >> that this statement is incorrect, please point to the protocol that > >> does. > >=20 > > DNSSEC with respect to SHA-256 and SHA-1 > > (https://tools.ietf.org/html/rfc4509#section-3 second sentence). It = is > > poorly explained, but DNSSEC is essentially adopting the Cartesian > > product requirement. >=20 > Just a side note. I really don't want to sidetrack, but I have to comm= ent. No, thank you for bringing this to my (and the WG's) attention. > DNSEXT is/has been arguing that this is a server requirement (a require= ment > for the zone owner) and not a client (a DNSSEC Validator) requirement. That's fine. Ticket #33 does not propose any client requirements, it just seeks to give clients that want to be smart the information they need. > See recent Wouter's email to unbound-dev: > https://unbound.net/pipermail/unbound-users/2011-September/002039.html >=20 > And status of DNS client (DNS validator) implementations is that Bind d= oesn't > enforce the Cartesian product, Unbound doesn't. (I don't know status f= or others.) Interesting, so virginia.gov botched the Cartesian product requirement and Unbound failed secure, and Paul Hoffman et al. argued that algorithm downgrade protection was more trouble than it is worth: http://dnssec-deployment.org/pipermail/dnssec-deployment/2011-September/0= 05455.html I'm not sure how I feel about that. But FWIW, I think that solution 1 for DANE (all digests of a single cert in a single RR) is very unlikely to go wrong in the way we've seen with the Cartesian product. Implementations are likely to generate that RR from a cert as a single operation with flags for the digest algorithm(s) to include, and having the data in a single RR (especially in the short term before pretty-printing support is widespread) will strongly discourage DNS admins to attempt the rearrangements of individual digests that could break things. --=20 Matt From matt@mattmccutchen.net Fri Sep 30 23:25:24 2011 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 8B9A521F8B44 for ; Fri, 30 Sep 2011 23:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.637 X-Spam-Level: X-Spam-Status: No, score=-2.637 tagged_above=-999 required=5 tests=[AWL=-0.038, 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 8XiNwUob2OJR for ; Fri, 30 Sep 2011 23:25:23 -0700 (PDT) Received: from homiemail-a62.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id E4BF421F8B42 for ; Fri, 30 Sep 2011 23:25:23 -0700 (PDT) Received: from homiemail-a62.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTP id 7626F634073; Fri, 30 Sep 2011 23:28:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; q=dns; s= mattmccutchen.net; b=kM+5pZjWN0wklCfCiq4M9gKJ1k28jRPKsREozN6DD4p JlyCIa2SaIm0FxLN8NnPo5Oth1hExDjqc7aGYvRRK+lW/ZXw/KPmS1jrs9z1PrHm WBFoBVpXibUXKdqMDsb9nK1onz+83vPACTtW+GwUMm+vdT9syxe+WLLOHGFVF5Vg = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; s= mattmccutchen.net; bh=UkW09FwEdFbg+a48MU5HkQHIvJY=; b=E/imsTLwOu XSn8pxEiTNv6PI8IDQGcnmHQ0BK8AaLBnt4/Te3K+8honvwSlIuM3Oy3ySWQ6V5v rVFI1BAk9yiKFcucfbxxstD5a8U1epgJkHq/WWYqEMLbRzDYSRYnajZqBOY3SIcV AmuLwk2VqXBjj5KmDLwASCx/2wHFWJilY= 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 4FC9163406F; Fri, 30 Sep 2011 23:28:19 -0700 (PDT) From: Matt McCutchen To: Phillip Hallam-Baker Date: Fri, 30 Sep 2011 23:28:13 -0700 In-Reply-To: References: <061.a8eeecd5d3e79d55021946fbc77943e1@trac.tools.ietf.org> <1317181872.2975.13.camel@localhost> <444081ED-DF03-45E3-83FD-889EF53D6F03@bbn.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 Content-Transfer-Encoding: 7bit Message-ID: <1317450499.2130.80.camel@localhost> Mime-Version: 1.0 Cc: dane@ietf.org Subject: Re: [dane] #37: Additive assertion of server certificate 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, 01 Oct 2011 06:25:24 -0000 On Fri, 2011-09-30 at 08:53 -0400, Phillip Hallam-Baker wrote: > And as for PKIX being 'complex', the world is complex. Don't fool > yourselves into thinking that you are all soo much smarter than the > people who did PKIX. The reason PKIX got complex was that people tried > to make the scheme too simple and then it grew barnacles as necessary > features were retro-fitted. > > You are doing exactly the same thing as the PKIX folk did in the same > way and you are completely determined to learn nothing from their > experience. The reason PKIX got complex was that it tried to be everything to everyone. There is nothing complex about TLS server authentication: the domain owner has one or more authentic TLS servers, which may bear equal or different public keys. If a list of the public keys (really, their digests) is published in DNSSEC, then you proceed with the connection if and only if the public key you were offered is on the list. Tell me what I am missing. > Designing a PKI is really easy when you start from the assumption that > there is one absolutely trustworthy and incorruptible party who can > provide ground truth Yep, and that assumption holds: for IANA DNS names, the IANA hierarchy is the truth, by definition. If you don't want to be dependent on that hierarchy, you need a different namespace. I'm working on it. > and that nobody ever makes administrative > mistakes. I don't see how DANE is any worse about this than any other system. -- Matt From matt@mattmccutchen.net Fri Sep 30 23:46:30 2011 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 0172821F8B81 for ; Fri, 30 Sep 2011 23:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.636 X-Spam-Level: X-Spam-Status: No, score=-2.636 tagged_above=-999 required=5 tests=[AWL=-0.037, 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 itco2Gg19Pss for ; Fri, 30 Sep 2011 23:46:29 -0700 (PDT) Received: from homiemail-a7.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 4312021F8B5E for ; Fri, 30 Sep 2011 23:46:29 -0700 (PDT) Received: from homiemail-a7.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a7.g.dreamhost.com (Postfix) with ESMTP id 2249E25C063; Fri, 30 Sep 2011 23:49:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; q=dns; s= mattmccutchen.net; b=pv5NZpRPDDJ6YZk/RaXiEZUXjSqYfSrDygKFWWcir+7 aFRY4Z/WNUunDe0r5zISlAVh3wEC93bABoyURYNQ1+eMY3zP8SeSHWB2/BaQPriS 9nDUgWvcg4iOgnmcG8MtlAnESnl7ipQiopVn6uL4GBgAQkNJlQ6AcJl47yxF62K8 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; s= mattmccutchen.net; bh=yErit4vvY6zEVZtjmZLOXQJ/vQg=; b=BOqsKf7juU mK2qwsnk2NguXk6bg+Edbtg4Qk/4wJy2QTz2ctVxD51wzYkoF7MicZBgMMdmkIMV C5KAaEEHngoCE/JwznJvTfG99i1ClM++g/K0VvI/I2SHxUThhWyy6tOz1BL0Dr+n Zhs+RpOsm+xjmgEHzp7CyIbYpTl2MgS0w= 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 EB82E25C062; Fri, 30 Sep 2011 23:49:24 -0700 (PDT) From: Matt McCutchen To: Zack Weinberg Date: Fri, 30 Sep 2011 23:49:23 -0700 In-Reply-To: References: <201109272223.p8RMNPpA026467@fs4113.wdf.sap.corp> <4E856FB8.9000301@sidn.nl> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 Content-Transfer-Encoding: 7bit Message-ID: <1317451765.2130.94.camel@localhost> Mime-Version: 1.0 Cc: IETF DANE WG list Subject: Re: [dane] Fwd: #36: Only requiring DNSSEC where it is needed 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, 01 Oct 2011 06:46:30 -0000 On Fri, 2011-09-30 at 13:40 -0700, Zack Weinberg wrote: > On Fri, Sep 30, 2011 at 11:19 AM, Paul Hoffman wrote: > > I don't think that is right, but I want to check your logic. Is your scenario that > > an attacker injects a type 0 or type 1 TLSA record and either leaves in > > DNSSEC (bogus) or strips it (stripped)? If so, what is the attacker's motive? > > He will not achieve anything because TLS was dropped. This attack is no > > different than sending a bogus A record to a TLS proxy that cannot > > impersonate the intended server, or to anyplace where TLS won't happen > > correctly. > > In the hypothetical, we're allowing unauthenticated type 0 or type 1 > records; however, a site admin who chooses to deploy DNSSEC with those > record types reasonably expects that this will prevent an attacker > from removing said records or substituting their own. > > Suppose that victim.example has deployed DNSSEC, and the zone contains > a type 0 TLSA record limiting www.victim.example's server certificates > to CA "alpha". Suppose a network attacker who has, somehow, obtained > a certificate for www.victim.example signed by CA "beta". Both > "alpha" and "beta" are in the root pool of all clients of interest. > The attacker interposes on DNS traffic for www.victim.example, strips > all DNSSEC and TLSA records, and modifies the A record to point to its > own server, which claims to be www.victim.example and provides the > certificate from CA "beta" as authentication. > > A DANE client that ignores DNSSEC validation under any circumstances > -- note that in this scenario, it doesn't get any TLSA records back at > all! -- will not defend against this attack; but a client that treats > DNSSEC "bogus" or "stripped" states as a hard failure, regardless of > TLSA contents, will defend. To simplify matters a bit, note that RFC 4033 "bogus" includes what you are calling "stripped". > > Again, I believe the new proposal adds one step: "if you received a type 2 > > response, make sure it was covered with DNSSEC". That's the same > > number of steps as "if you received any response, make sure it was > > covered with DNSSEC". > > I hope I have demonstrated that this is inadequate. You and Paul are arguing past each other. Paul is assuming a validating resolver that doesn't even give you a response unless it is "secure" or "verified insecure"; in that case, you're already protected from tampering with signed TLSA records. If you get verified-insecure records of usage 0 or 1, you do not gain or lose any security by processing them, so it hardly matters whether you do. (This is in the general case where you don't have a better-protected path to DNS than to the TLS server.) What is easiest to implement in practice depends on the DNS library. In light of that, I would not stipulate that clients MUST NOT process verified insecure records of usage 0 or 1. I think we may be better off stating and justifying what is actually needed, rather than putting in a MUST because we feel like it and running the risk that implementors second-guess us incorrectly. -- Matt From matt@mattmccutchen.net Fri Sep 30 23:52:02 2011 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 C700C21F8AF3 for ; Fri, 30 Sep 2011 23:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.635 X-Spam-Level: X-Spam-Status: No, score=-2.635 tagged_above=-999 required=5 tests=[AWL=-0.036, 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 xCG2bx8HuJfg for ; Fri, 30 Sep 2011 23:52:02 -0700 (PDT) Received: from homiemail-a5.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id E9A3121F8AE9 for ; Fri, 30 Sep 2011 23:52:01 -0700 (PDT) Received: from homiemail-a5.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a5.g.dreamhost.com (Postfix) with ESMTP id CFE2770406E; Fri, 30 Sep 2011 23:54:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; q=dns; s= mattmccutchen.net; b=Kuyqg6fbk7QSwZmePf7b6+tbMnWwFuYpMdu0rTLgTHN XZ7cYJatZSp3wCcTBrVkkra4WERtSJzc0Gu4jFjKt1I07I/nQTTWDaNoyP7S/APm KU3fKFPuWUAiFVynSm3/fs5+XNSRRyojtoYwUb4kHIfX2SIFYcWEg/edMpyZrF4A = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; s= mattmccutchen.net; bh=IWZbgv+rYax/uPPuqrNr8HR3OvE=; b=B5UQ7isPTp cp+Uutqh8D0LbFkVThgSSPMaDbMvdarDvzQpbFC1kvk4LQngcgnPMhOyaOD9Fswm 9ynUo4KAMRpjfGJnKtglRxgryL29ybk2v4r6aYg0b8ecqEu5ht7OM6ykBJ/lsz2R aW2u8NtBAk60EvTAFKoE0Ey2AQHkbUYJk= 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-a5.g.dreamhost.com (Postfix) with ESMTPSA id 97D6E70406A; Fri, 30 Sep 2011 23:54:56 -0700 (PDT) From: Matt McCutchen To: Paul Hoffman Date: Fri, 30 Sep 2011 23:54:51 -0700 In-Reply-To: <5D2103D1-64E4-48CD-BF65-B0EF351622DC@vpnc.org> References: <201109272223.p8RMNPpA026467@fs4113.wdf.sap.corp> <4E856FB8.9000301@sidn.nl> <20110930183133.GB38562@shinkuro.com> <5D2103D1-64E4-48CD-BF65-B0EF351622DC@vpnc.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 Content-Transfer-Encoding: 7bit Message-ID: <1317452096.2130.98.camel@localhost> Mime-Version: 1.0 Cc: dane@ietf.org Subject: Re: [dane] #36: Only requiring DNSSEC where it is needed 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, 01 Oct 2011 06:52:02 -0000 On Fri, 2011-09-30 at 11:52 -0700, Paul Hoffman wrote: > On Sep 30, 2011, at 11:31 AM, Andrew Sullivan wrote: > > > On Fri, Sep 30, 2011 at 11:19:30AM -0700, Paul Hoffman wrote: > >> > >> No, our proposal doesn't involve looking at DNSSEC ever if the type is 0 or 1. > > > > A validating resolver is going to look at the DNSSEC anyway, isn't it? > > Certainly. The question is whether the *application* needs to know > whether or not DNSSEC validated on the DNS records, such as through > some future DNS API or through the application itself being a DNS > validating resolver. Be a little careful with this... libunbound gives you the RRset regardless and makes you check that the "bogus" flag in the result structure is unset. This is a design weakness in libunbound, but that's what we have to work with. -- Matt