From warren@kumari.net Wed Nov 2 13:16: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 2A82B11E8172 for ; Wed, 2 Nov 2011 13:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKo3qrtGiNzl for ; Wed, 2 Nov 2011 13:16:31 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 9046711E8122 for ; Wed, 2 Nov 2011 13:16:31 -0700 (PDT) Received: from [192.168.0.105] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 0B0F81B407FF; Wed, 2 Nov 2011 16:16:16 -0400 (EDT) From: Warren Kumari Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Nov 2011 16:16:15 -0400 Message-Id: <0607ABDB-4D47-489B-8272-04C555B89FAB@kumari.net> To: IETF DANE WG list Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [dane] Closing some more (non-)issues. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 20:16:32 -0000 Hi there all, I am attempting to do some cleanup before the face to face meeting in = Taipei and so am trying to close some issues that I think have been = addressed in newer version of the documents, in general discussions, or = are not really applicable any more. Many of these were opened back when the protocol doc was at -01 and have = been addressed over time, folded into newer versions of the document. It = is your chairs fault for not having closed these earlier... Please clearly object, preferably by Friday if you feel that any of = these are still issues that need to stay open / need to be addressed.... #6. I believe that this is addressed in draft-ietf-dane-protocol-12 in = Sections 1.2 Section 4.4, para. 4, 5 and Appendix B.=20 #13 I believe that this addressed in draft-ietf-dane-protocol-12 in Sections = 2.1, 2.2, 2.3, most of section 4 and Appendix B. #18. This was a somewhat exploratory question, and has been addressed in = multiple discussion, and in the protocol document, Version -12, Section = 4.x, Section 1.2 and Appendix B. #34: This issue is low on details ("waiting on me to make either one or the = other proposal public..."), but much of this was discussed in #24 = (http://www.ietf.org/mail-archive/web/dane/current/msg03169.html) and we = think that the text in draft-ietf-dane-protocol-12 Appendix A.1, A.1.1 = addresses it. Going to close it as worksforme,=20 Open issues on which there was only vague consensus:=20 #28: Interaction of SRV and TLSA records The chairs *think* that the consensus is that this is adequately = addressed in draft-ietf-dane-protocol-12, but the discussion just sort = of petered out. Get your final knocks in now, or it will be "closed as = addressed in -12". Open issues on which there may have been consensus, but we were not able = to figure out what it was :-P=20 #35: Behavior for a supported algorithm that is not considered "strong" = by the client.=20 We will be reopening this discussion for a quick summary... We are planning on going ahead with all this on Monday / Tuesday -- = sorry for the short call... Please *clearly* and *concisely* indicate if = you disagree with the above issues / resolutions, what *specifically* = you are objecting to, and a proposed solution. I will be on a plane for most of Sunday / Monday (IAD -> NRT -> TPE) and = so will not be available. W= From matt@mattmccutchen.net Thu Nov 3 00:45: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 123B411E80A6 for ; Thu, 3 Nov 2011 00:45: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 Hod5gJUWMMcD for ; Thu, 3 Nov 2011 00:45:56 -0700 (PDT) Received: from homiemail-a4.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 8D87F11E809F for ; Thu, 3 Nov 2011 00:45:56 -0700 (PDT) Received: from homiemail-a4.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a4.g.dreamhost.com (Postfix) with ESMTP id 23D3551C062; Thu, 3 Nov 2011 00:45: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:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=DiSbH71q64MxIzXK8ysxo46WNy8N1LnPpCAM/KejKYm NVRxx2nVFUMjgHAhuSdg1Qscf2KPOEMJtYpzPNdEl0czyzNHAKmdUEGcnivEMPNj EjJwLbq0YKgMjJSrtQcBMUOqTa63uI98Oa54DG1FQgGimXyrEyIBA9FX1SYpZ7h0 = 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=LDGFdUKa37syQqCcm/E+0UmO+6o=; b=iG1wXfcSRi VNfgyNTlNrF5exrSSn16i1M/inqGfbWoNUm+iLGLky73jD4a4IMGJiJz5CD/3cET lc6ZXdQueHEBlLdafXMk2rBp1pHJZuEVrwDpHz1Q9+2oC6TsjbX5aF5wyWlqbyJE LmRpkIa7P/+KEcq3leKJZWYWC/o4G5uO4= 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 F264451C070; Thu, 3 Nov 2011 00:45:55 -0700 (PDT) From: Matt McCutchen To: Warren Kumari Date: Thu, 03 Nov 2011 00:45:54 -0700 In-Reply-To: <0607ABDB-4D47-489B-8272-04C555B89FAB@kumari.net> References: <0607ABDB-4D47-489B-8272-04C555B89FAB@kumari.net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 Message-ID: <1320306356.4785.11.camel@localhost> Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Cc: IETF DANE WG list Subject: Re: [dane] Closing some more (non-)issues. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 07:45:57 -0000 On Wed, 2011-11-02 at 16:16 -0400, Warren Kumari wrote: > #34: > This issue is low on details ("waiting on me to make either one or the > other proposal public..."), but much of this was discussed in #24 > (http://www.ietf.org/mail-archive/web/dane/current/msg03169.html) and > we think that the text in draft-ietf-dane-protocol-12 Appendix A.1, > A.1.1 addresses it. Going to close it as worksforme,=20 As I discussed with Ond=C5=99ej back when we were considering ticket #24,= the problem is not solved: you cannot have different TLSA RRsets for different ports in combination with wildcard hostnames. However, I've been slow in advancing either proposed solution, and it's not fair for this to hold the document up. The functionality can be added in a later update, or even provided via a separate mechanism that composes with DANE. So please feel free to mark the issue as not to be addressed in the initial DANE standard, but understand that it is not solved, nor have we made the decision not to ever solve it. --=20 Matt From warren@kumari.net Thu Nov 3 11:36: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 8C01A11E80DA for ; Thu, 3 Nov 2011 11:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id buj-Uk7PCVVV for ; Thu, 3 Nov 2011 11:36:48 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 143B011E80AE for ; Thu, 3 Nov 2011 11:36:47 -0700 (PDT) Received: from dhcp-172-19-119-189.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id E08EC1B40923; Thu, 3 Nov 2011 14:36:45 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Warren Kumari In-Reply-To: <1320306356.4785.11.camel@localhost> Date: Thu, 3 Nov 2011 14:36:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <161F04ED-5655-4F9F-B803-DC4C512FE0BB@kumari.net> References: <0607ABDB-4D47-489B-8272-04C555B89FAB@kumari.net> <1320306356.4785.11.camel@localhost> To: Matt McCutchen X-Mailer: Apple Mail (2.1084) Cc: IETF DANE WG list Subject: Re: [dane] Closing some more (non-)issues. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 18:36:48 -0000 On Nov 3, 2011, at 3:45 AM, Matt McCutchen wrote: > On Wed, 2011-11-02 at 16:16 -0400, Warren Kumari wrote: >> #34: >> This issue is low on details ("waiting on me to make either one or = the >> other proposal public..."), but much of this was discussed in #24 >> (http://www.ietf.org/mail-archive/web/dane/current/msg03169.html) and >> we think that the text in draft-ietf-dane-protocol-12 Appendix A.1, >> A.1.1 addresses it. Going to close it as worksforme,=20 >=20 > As I discussed with Ond=C5=99ej back when we were considering ticket = #24, the > problem is not solved: you cannot have different TLSA RRsets for > different ports in combination with wildcard hostnames. However, I've > been slow in advancing either proposed solution, and it's not fair for > this to hold the document up. =20 Thank you, appreciate it. > The functionality can be added in a later > update, or even provided via a separate mechanism that composes with > DANE. =20 > So please feel free to mark the issue as not to be addressed in > the initial DANE standard, but understand that it is not solved, nor > have we made the decision not to ever solve it. Understood. We were originally hoping that DANE could be spun up, pound out a doc or = two, declare victory and shut down, never to meet again... but it is = becoming increasingly apparent that we are going to learn things as this = gets deployed, that there are likely to be extensions / updates, / new = uses, etc.=20 This does means that we don't have to solve every problem in this round, = and can punt some things to DANEbis (or a new WG, with new chairs). W >=20 > --=20 > Matt >=20 From trac+dane@trac.tools.ietf.org Thu Nov 3 11:39: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 EEEE111E80DA for ; Thu, 3 Nov 2011 11:39:59 -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 m-Jea87BxZEv for ; Thu, 3 Nov 2011 11:39: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 7692F11E80AE for ; Thu, 3 Nov 2011 11:39:58 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RM2Ch-0007Jy-S0; Thu, 03 Nov 2011 14:39:55 -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: Thu, 03 Nov 2011 18:39:55 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/34#comment:2 Message-ID: <076.ae2745751dff357a047f203ac5b00912@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, 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] #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: Thu, 03 Nov 2011 18:40:00 -0000 #34: Use with wildcards (i.e. *.googleusercontent.com) Changes (by warren@…): * status: assigned => closed * resolution: => wontfix Comment: Closing as per: http://www.ietf.org/mail-archive/web/dane/current/msg03712.html On Wed, 2011-11-02 at 16:16 -0400, Warren Kumari wrote: > #34: > This issue is low on details ("waiting on me to make either one or the > other proposal public..."), but much of this was discussed in #24 > (http://www.ietf.org/mail-archive/web/dane/current/msg03169.html) and > we think that the text in draft-ietf-dane-protocol-12 Appendix A.1, > A.1.1 addresses it. Going to close it as worksforme, As I discussed with OndÅej back when we were considering ticket #24, the problem is not solved: you cannot have different TLSA RRsets for different ports in combination with wildcard hostnames. However, I've been slow in advancing either proposed solution, and it's not fair for this to hold the document up. The functionality can be added in a later update, or even provided via a separate mechanism that composes with DANE. So please feel free to mark the issue as not to be addressed in the initial DANE standard, but understand that it is not solved, nor have we made the decision not to ever solve it. -- Matt -- -------------------------+---------------------- Reporter: matt@… | Owner: matt@… Type: enhancement | Status: closed Priority: major | Milestone: Component: protocol | Version: Severity: - | Resolution: wontfix Keywords: | -------------------------+---------------------- Ticket URL: dane From zack.weinberg@gmail.com Fri Nov 4 21:21: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 E6DCD1F0C52 for ; Fri, 4 Nov 2011 21:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_47=0.6, J_CHICKENPOX_57=0.6, 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 x4J8OdSHF4az for ; Fri, 4 Nov 2011 21:21:18 -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 EADF91F0C50 for ; Fri, 4 Nov 2011 21:21:17 -0700 (PDT) Received: by gye5 with SMTP id 5so3661851gye.31 for ; Fri, 04 Nov 2011 21:21:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=VqFg0zI36W9is+yIMV5NB7xpOV/M7lqAM3OBHT1tR9k=; b=U51bfPPtJoToYnV6ybD8I8gOZptnfm+0nzT9DWPB/BJQw6MDx3+wv/gqGbblndryd+ BtTTKs4ez7odhsXv46gcyoQviZkFRlWVheXCYADmeDD7vCLLKvIkydP4ZcuJlmYw6WGH ceMyYjNEInm/0VHrjJPndOsGZHrBSH4MhQ8tE= MIME-Version: 1.0 Received: by 10.182.77.196 with SMTP id u4mr3632576obw.19.1320466877422; Fri, 04 Nov 2011 21:21:17 -0700 (PDT) Sender: zack.weinberg@gmail.com Received: by 10.182.88.103 with HTTP; Fri, 4 Nov 2011 21:21:17 -0700 (PDT) Date: Fri, 4 Nov 2011 21:21:17 -0700 X-Google-Sender-Auth: 3e2n2ZQ-VA2hsRpQXfjUImyRLMc Message-ID: From: Zack Weinberg To: IETF DANE WG list Content-Type: multipart/mixed; boundary=f46d044473c32a9c1a04b0f52796 Cc: Paul Hoffman Subject: [dane] DANE protocol spec complete rewrite X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 05 Nov 2011 04:21:21 -0000 --f46d044473c32a9c1a04b0f52796 Content-Type: text/plain; charset=UTF-8 With the WG face-to-face meeting next Monday (alas, I cannot attend), now seemed like a good time to finish and post that complete spec rewrite that I've been threatening to do for months :) Despite the radical changes to the document, it is not my intention to take over the editor's hat from the present team, merely to offer improvements. I have tried not to make any normative changes, except where draft 12 was ambiguous. One notable exception to that is the code numbers in the RR, which have been rationalized. Where I consciously made normative changes, I indicated them with [[comments in double square brackets]]; these also indicate spots where there are remaining ambiguities or omissions that I either don't know enough about to produce text, or do not feel it is appropriate for me to resolve unilaterally. All open issues except #10, #35, and #38 are at least mentioned in these annotations, and most of them have suggested resolutions. Editorially, however, I have changed everything from the terminology on up. My principal goal was clarity, particularly relating to how the client is supposed to behave. To that end, I have replaced the non-normative pseudocode Appendix B with a normative section 3 that states a prose algorithm which clients must match in results, although not in implementation. Given the well-known ambiguities and controversies surrounding the interpretation of PKIX, I have also removed as many dependencies on that spec as possible, even in terminology. Appendix A has been cut down a bit and moved into the main body of the document. Finally, I added some items to the various "considerations" sections on my own motion, and a new "usage scenarios" section. Since I have not been able to find the (presumed) xml2rfc source of draft 12 anywhere, I did not preserve all of the formatting (particularly not the page headers and footers), the IESG boilerplate, or the bibliography. If the present editors of the document are willing to provide me with the source, I will happily do the legwork to finish out the draft. zw --f46d044473c32a9c1a04b0f52796 Content-Type: text/plain; charset=US-ASCII; name="draft-ietf-dane-protocol-12+zw.txt" Content-Disposition: attachment; filename="draft-ietf-dane-protocol-12+zw.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gum3rajo0 QWJzdHJhY3QKCiAgIFRMUyBpZGVudGlmaWVzIGVhY2ggc2VydmVyIHdpdGggYSBfY2VydGlmaWNh dGVfIHRoYXQgYmluZHMgaXRzCiAgIHB1YmxpYyBrZXkgdG8gaXRzIGhvc3RuYW1lLiAgQW55b25l IGNhbiBmYWJyaWNhdGUgYSBjZXJ0aWZpY2F0ZQogICBiaW5kaW5nIHRoZWlyIHB1YmxpYyBrZXkg dG8gYW55IGhvc3RuYW1lIHRoZXkgbGlrZSwgYnV0IGNsaWVudHMKICAgd2lsbCBvbmx5IGhvbm9y IGNlcnRpZmljYXRlcyB0aGF0IGFyZSBzaWduZWQgYnkgYSByZWxpYWJsZSB0aGlyZAogICBwYXJ0 eS4gIFRoaXMgZG9jdW1lbnQgcHJlc2VudHMgYSBtZWNoYW5pc20gd2hlcmVieSB0aGF0IHRoaXJk IHBhcnR5CiAgIGNhbiBiZSB0aGUgRE5TLCBzdXBwbGVtZW50aW5nIG9yIHJlcGxhY2luZyB0aGUg ZXhpc3Rpbmcgc3lzdGVtIG9mCiAgICJjZXJ0aWZpY2F0ZSBhdXRob3JpdGllcy4iCgoxLiAgSW50 cm9kdWN0aW9uCgogICBUaGlzIGRvY3VtZW50IHByZXNlbnRzIGEgc2NoZW1lIGZvciB1c2luZyB0 aGUgRE5TIGFzIGFuIGFkZGl0aW9uYWwKICAgb3IgYWx0ZXJuYXRpdmUgcmVsaWFibGUgdGhpcmQg cGFydHkgZm9yIHZlcmlmeWluZyBUTFMgc2VydmVyCiAgIGlkZW50aXR5LiAgV2UgYWxyZWFkeSBy ZWx5IHVwb24gdGhlIEROUyB0byBwcm92aWRlIHRoZSBJUCBhZGRyZXNzCiAgIG9mIHRoZSBzZXJ2 ZXIsIGFuZCBUTFMgcHVibGljIGtleXMgYXJlIGJvdW5kIHRvIGEgaG9zdG5hbWUsIHNvIHRoZQog ICBETlMgaXMgYSBuYXR1cmFsIHByb3ZpZGVyIG9mIHRoaXMgaW5mb3JtYXRpb24uICBJbiB0aGUg cGFzdCwgRE5TCiAgIHJlY29yZHMgY291bGQgZWFzaWx5IGJlIGZvcmdlZCwgYnV0IEROU1NFQyBb UkZDNDAzM10gbm93IHByb3ZpZGVzCiAgIGNsaWVudHMgd2l0aCBhc3N1cmFuY2UgdGhhdCBpbmZv cm1hdGlvbiBmcm9tIHNpZ25lZCB6b25lcyBpcwogICBhdXRob3JpdGF0aXZlLgoKICAgVGhpcyBk b2N1bWVudCBhcHBsaWVzIHRvIGJvdGggVExTIFtSRkM1MjQ2XSBhbmQgRFRMUyBbUkZDNDM0N2Jp c10uCiAgIEZvciByZWFkYWJpbGl0eSdzIHNha2UsIHdlIHJlZmVyIG9ubHkgdG8gIlRMUyIgdGhy b3VnaG91dCB0aGUKICAgZG9jdW1lbnQsIGJ1dCB0aGlzIHNob3VsZCBiZSByZWFkIHRvIGluY2x1 ZGUgRFRMUywgYW5kIGFsc28gYW55CiAgIGZ1dHVyZSBhcHBsaWNhdGlvbnMgb2YgdGhlIFRMUyBw cm90b2NvbCB0byBvdGhlciB0cmFuc3BvcnQgbGF5ZXIKICAgcHJvdG9jb2xzLiAgT3RoZXIgc2Vj dXJpdHkgcHJvdG9jb2xzIGFuZCBvdGhlciBmb3JtcyBvZgogICBpZGVudGlmaWNhdGlvbiBmb3Ig VExTIHNlcnZlcnMgKHN1Y2ggYXMgSVAgYWRkcmVzc2VzKSBhcmUgaGFuZGxlZAogICBpbiBvdGhl ciBkb2N1bWVudHMuICBGb3IgZXhhbXBsZSwga2V5cyBmb3IgSVBzZWMgYXJlIGNvdmVyZWQgaW4K ICAgW1JGQzQwMjVdIGFuZCBrZXlzIGZvciBTU0ggYXJlIGNvdmVyZWQgaW4gW1JGQzQyNTVdLgoK ICAgQXQgdGhlIHRpbWUgb2Ygd3JpdGluZywgb25seSBQS0lYIGNlcnRpZmljYXRlcyBbUkZDNTI4 MF0gYXJlIHVzZWQKICAgd2l0aCBUTFM7IGhvd2V2ZXIsIHdoZXJlIFBLSVggaXMgbm90IHNwZWNp ZmljYWxseSBtZW50aW9uZWQgaW4gdGhpcwogICBkb2N1bWVudCwgdGhlIHRlcm0gImNlcnRpZmlj YXRlIiBzaG91bGQgYmUgcmVhZCB0byBpbmNsdWRlIGFueSBuZXcKICAgcHVibGljLWtleSB0cmFu c3BvcnQgZm9ybWF0cyB0aGF0IG1heSBiZSBkZWZpbmVkIGZvciB1c2Ugd2l0aCBUTFMKICAgaW4g dGhlIGZ1dHVyZS4gIFRoZXNlIGh5cG90aGV0aWNhbCBuZXcgZm9ybWF0cyB3aWxsIHJlcXVpcmUK ICAgYWRkaXRpb25zIHRvIHRoZSBJQU5BIGNvZGUgbnVtYmVyIHJlZ2lzdHJpZXMgZGVmaW5lZCBp biB0aGlzCiAgIGRvY3VtZW50LCBidXQgdGhlIGRvY3VtZW50IGl0c2VsZiBzaG91bGQgbm90IG5l ZWQgdG8gYmUgdXBkYXRlZCB0bwogICBhY2NvbW1vZGF0ZSB0aGVtLgoKMS4xLiAgVExTIENlcnRp ZmljYXRlIENoYWlucwoKICAgVExTIHNlcnZlcnMgaWRlbnRpZnkgdGhlbXNlbHZlcyB0byBjbGll bnRzIHdpdGggYSBfY2VydGlmaWNhdGUKICAgY2hhaW5fOiBhbiBvcmRlcmVkIHNlcXVlbmNlIG9m IGNlcnRpZmljYXRlcywgZWFjaCBzaWduZWQgYnkgdGhlCiAgIHB1YmxpYyBrZXkgaW4gdGhlIHN1 YnNlcXVlbnQgY2VydGlmaWNhdGUuIFRoZSBjaGFpbiBiZWdpbnMgd2l0aCBhbgogICBfZW5kLWVu dGl0eSBjZXJ0aWZpY2F0ZV8sIHdoaWNoIGNvbnRhaW5zIHRoZSBwdWJsaWMga2V5IHRoYXQKICAg YmVsb25ncyB0byB0aGUgc2VydmVyICh0aGF0IGlzLCB0aGUgc2VydmVyIHBvc3Nlc3NlcyB0aGUK ICAgY29ycmVzcG9uZGluZyBwcml2YXRlIGtleSk7IGl0IGVuZHMgaW4gYSBfdHJ1c3QgYW5jaG9y Xywgd2hpY2gKICAgaWRlbnRpZmllcyBhIHJlbGlhYmxlIHRoaXJkIHBhcnR5IChyZWZlcnJlZCB0 byBhcyBhICJjZXJ0aWZpY2F0ZQogICBhdXRob3JpdHkiIG9yICJDQSIpLiAgQnkgc2lnbmluZyB0 aGUgZW5kLWVudGl0eSBjZXJ0aWZpY2F0ZSwgdGhlc2UKICAgdGhpcmQgcGFydGllcyBhdHRlc3Qg dGhhdCBib3RoIGhhbHZlcyBvZiBhIHBhcnRpY3VsYXIga2V5cGFpciBhcmUKICAgY29udHJvbGxl ZCBieSB0aGUgbGVnaXRpbWF0ZSBvd25lcnMgb2YgYSBwYXJ0aWN1bGFyIGRvbWFpbiBuYW1lLgoK ICAgQ2xpZW50IHNvZnR3YXJlIGRldmVsb3BlcnMgZGVjaWRlIHdoaWNoIENBcyB0aGV5IGNvbnNp ZGVyIHJlbGlhYmxlLAogICBhbmQgZW1iZWQgY29waWVzIG9mIGFsbCB0aGUgdHJ1c3QgYW5jaG9y cyBiZWxvbmdpbmcgdG8gdGhvc2UgQ0FzCiAgIGludG8gdGhlaXIgc29mdHdhcmUuICBUaGUgZW5k IHVzZXIgY2FuIGFkZCBvciByZW1vdmUgY2VydGlmaWNhdGVzCiAgIGZyb20gdGhpcyBlbWJlZGRl ZCBsaXN0ICh1c3VhbGx5IHJlZmVycmVkIHRvIGFzIHRoZSAidHJ1c3QgcG9vbCIuKQogICBUaGUg c29mdHdhcmUgd2lsbCBhY2NlcHQgYSBUTFMgc2VydmVyJ3MgY2xhaW0gb2YgaWRlbnRpdHkgaWYg aXRzCiAgIGVuZC1lbnRpdHkgY2VydGlmaWNhdGUgbWF0Y2hlcyBpdHMgaG9zdG5hbWUgYW5kIGl0 cyBjZXJ0aWZpY2F0ZQogICBjaGFpbiBlbmRzIGluIGEgdHJ1c3QgYW5jaG9yIGluIHRoZSB0cnVz dCBwb29sLgoKICAgQ2VydGlmaWNhdGUgY2hhaW5zIG1heSBoYXZlIG1vcmUgdGhhbiB0d28gZWxl bWVudHM7IHRoaXMgYWxsb3dzIENBcwogICB0byBrZWVwIHRoZWlyIGxvbmctbGl2ZWQgcHJpdmF0 ZSBrZXlzIHNhZmVseSBvZmZsaW5lIGFuZCBvbmx5IHNpZ24KICAgc2hvcnRlci1saXZlZCAiaW50 ZXJtZWRpYXRlIiBjZXJ0aWZpY2F0ZXMgd2l0aCB0aGVtLiAgVGhlc2UKICAgc2hvcnRlci1saXZl ZCBwcml2YXRlIGtleXMsIGluIHR1cm4sIHNpZ24gdGhlIGVuZC1lbnRpdHkKICAgY2VydGlmaWNh dGVzLiAgU29tZXRpbWVzIHRoZXJlIGFyZSBtYW55IGludGVybWVkaWF0ZSBjZXJ0aWZpY2F0ZXMs CiAgIGFsdGhvdWdoIGZvciBiYW5kd2lkdGgncyBzYWtlLCBwZW9wbGUgdHJ5IHRvIGtlZXAgaXQg dG8gYSBtaW5pbXVtLgoKICAgQ2VydGlmaWNhdGUgY2hhaW5zIG1heSBhbHNvIGhhdmUgb25seSBf b25lXyBlbGVtZW50LCB3aGljaCBpcwogICBzaW11bHRhbmVvdXNseSB0aGUgZW5kLWVudGl0eSBj ZXJ0aWZpY2F0ZSBhbmQgdGhlIHRydXN0IGFuY2hvcjsKICAgdGhpcyBpcyByZWZlcnJlZCB0byBh cyBhICJzZWxmLXNpZ25lZCIgY2VydGlmaWNhdGUuICBXaGVuIGEKICAgc2VsZi1zaWduZWQgY2Vy dGlmaWNhdGUgaXMgaW4gdXNlLCB0aGUgVExTIHNlY3VyZSBjaGFubmVsIGlzCiAgIHByb3RlY3Rl ZCBmcm9tIGVhdmVzZHJvcHBlcnMsIGJ1dCBub3QgZnJvbSBtZW4gaW4gdGhlIG1pZGRsZSwgd2hv CiAgIGNvdWxkIGZhYnJpY2F0ZSB0aGVpciBvd24gc2VsZi1zaWduZWQgY2VydGlmaWNhdGVzIGFz IG5lY2Vzc2FyeS4KICAgVGhlcmVmb3JlLCBjbGllbnQgc29mdHdhcmUgZG9lcyBub3QgYWNjZXB0 IGNsYWltcyBvZiBpZGVudGl0eQogICBiYWNrZWQgYnkgc2VsZi1zaWduZWQgY2VydGlmaWNhdGVz IHdpdGhvdXQgdXNlciBpbnRlcnZlbnRpb247CiAgIGRlc3BpdGUgdGhpcywgdGhleSBhcmUgd2lk ZWx5IHVzZWQgW1tjaXRhdGlvbiBuZWVkZWRdXS4KCiAgIFRoZSBtZWNoYW5pc20gZGVmaW5lZCBp biB0aGlzIGRvY3VtZW50IGFsbG93cyB0aGUgRE5TIGFkbWluaXN0cmF0b3IKICAgZm9yIGEgem9u ZSB0byBuYW1lIGNlcnRpZmljYXRlcyB0aGF0IHNob3VsZCBhcHBlYXIgYXQgcGFydGljdWxhcgog ICBwb3NpdGlvbnMgaW4gdGhlIGNoYWlucyBwcmVzZW50ZWQgYnkgVExTIHNlcnZlcnMgaW4gdGhh dCB6b25lLgogICBXaGVuIHVzZWQgd2l0aCBhIENBLXNpZ25lZCBjZXJ0aWZpY2F0ZSwgdGhpcyBw cm92aWRlcyBhZGRpdGlvbmFsCiAgIHZlcmlmaWNhdGlvbiBvZiB0aGUgc2VydmVyJ3MgaWRlbnRp dHksIHByb3RlY3RpbmcgYWdhaW5zdCB0aGUKICAgcG9zc2liaWxpdHkgdGhhdCBzb21lIENBIG1p Z2h0IGlzc3VlIF9hbm90aGVyXyBjZXJ0aWZpY2F0ZSBmb3IgdGhlCiAgIHNhbWUgaG9zdG5hbWU7 IHdoZW4gdXNlZCB3aXRoIGEgc2VsZi1zaWduZWQgY2VydGlmaWNhdGUsIGl0CiAgIHByb3ZpZGVz IHJvdWdobHkgdGhlIHNhbWUgbGV2ZWwgb2YgdmVyaWZpY2F0aW9uIGFzIGEgYmFzaWMgQ0EKICAg c2lnbmF0dXJlLCBwcm90ZWN0aW5nIGFnYWluc3QgbWVuIGluIHRoZSBtaWRkbGUuCgoxLjIuICBN YXRjaGVzIGFuZCBDb25jbHVzaW9ucwoKICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgbmV3IERO UyByZWNvcmQgdHlwZSwgIlRMU0EiOyBhIHN1YnJvdXRpbmUKICAgd2hpY2ggZGVjaWRlcyB3aGV0 aGVyIGFuIGluc3RhbmNlIG9mIHRoaXMgcmVjb3JkIHR5cGUgX21hdGNoZXNfIG9uZQogICBvZiB0 aGUgY2VydGlmaWNhdGVzIHByZXNlbnRlZCBieSB0aGUgVExTIHNlcnZlcjsgYW5kIGEgbGFyZ2Vy CiAgIGFsZ29yaXRobSB3aGljaCBkcmF3cyBhIF9jb25jbHVzaW9uXyBhYm91dCBhIGNlcnRpZmlj YXRlIGNoYWluLAogICBiYXNlZCBvbiB3aGV0aGVyIGFueSBvZiB0aGUgVExTQSByZWNvcmRzIGlu IGFuIFJSc2V0IG1hdGNoZWQgYW55IG9mCiAgIHRoZSBjZXJ0aWZpY2F0ZXMgaW4gdGhhdCBjaGFp bi4gIFRoaXMgY29uY2x1c2lvbiBtYXkgYmUgaW4gZmF2b3Igb2YKICAgYWNjZXB0aW5nIHRoZSBz ZXJ2ZXIncyBjbGFpbSBvZiBpZGVudGl0eSwgYWdhaW5zdCBpdCwgb3IgaW5kaWNhdGUKICAgdGhh dCBtb3JlIGRhdGEgaXMgbmVlZGVkOyBpdHMgbnVhbmNlcyB3aWxsIGJlIGRpc2N1c3NlZCBiZWxv dy4KCjEuMy4gIE90aGVyIFRlcm1pbm9sb2d5CgogICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1V U1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsCiAgICJTSE9VTEQiLCAi U0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlz CiAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gUkZDIDIx MTkgW1JGQzIxMTldLgoKICAgVGhpcyBkb2N1bWVudCBhbHNvIG1ha2VzIHVzZSBvZiBzdGFuZGFy ZCBETlNTRUMgYW5kIFRMUyB0ZXJtaW5vbG9neSwKICAgZGVmaW5lZCByZXNwZWN0aXZlbHkgaW4g W1JGQzQwMzNdIGFuZCBbUkZDNTI0Nl0uICBTb21lIHRlcm1zCiAgIHJlbGF0ZWQgdG8gVExTLXBy b3RlY3RlZCBhcHBsaWNhdGlvbiBzZXJ2aWNlcyBhbmQgRE5TIG5hbWVzIGFyZQogICB0YWtlbiBm cm9tIFtSRkM2MTI1XS4gIEEgZmV3IHRlcm1zIHJlbGF0ZWQgdG8gUEtJWC1mb3JtYXQKICAgY2Vy dGlmaWNhdGVzIGFyZSB0YWtlbiBmcm9tIFtSRkM1MjgwXS4KCiAgIFdoZW4gYXBwbGllZCB0byBh bGdvcml0aG1zLCB0aGUgdGVybSAiYXMgaWYiIGlzIHRvIGJlIGludGVycHJldGVkCiAgIGFzIGRl ZmluZWQgaW4gSVNPL0lFQyA5ODk5OjE5OTkgIlByb2dyYW1taW5nIExhbmd1YWdlczogQyIgW0M5 OV0uCiAgIFtbIFRoaXMgbWlnaHQgbm90IGJlIG5lY2Vzc2FyeSAtLSBpcyBJRVRGIHN0YW5kYXJk IHVzYWdlIGFsaWduZWQKICAgICAgd2l0aCBDIGluIHRoaXMgcmVnYXJkPyBdXQoKMi4gIFRoZSBU TFNBIFJlc291cmNlIFJlY29yZAoKICAgVGhlICJUTFNBIiByZXNvdXJjZSByZWNvcmQgKFJSKSBw cm92aWRlcyBpbmZvcm1hdGlvbiBhYm91dCB0aGUKICAgY2VydGlmaWNhdGUgY2hhaW4gdGhhdCBh IFRMUyBzZXJ2ZXIgYXQgYSBwYXJ0aWN1bGFyIGRvbWFpbiBuYW1lCiAgIHNob3VsZCBwcmVzZW50 LiAgSXRzIHNlbWFudGljcyBhcmUgZGVmaW5lZCBpbiBkZXRhaWwgYmVsb3cuCgogICBUaGUgdHlw ZSB2YWx1ZSBmb3IgdGhlIFRMU0EgUlIgaXMgVEJELiAgSXQgaXMgY2xhc3MtaW5kZXBlbmRlbnQs CiAgIGFuZCBoYXMgbm8gc3BlY2lhbCBUVEwgcmVxdWlyZW1lbnRzLgoKMi4xLiAgVExTQSBSREFU QSBXaXJlIEZvcm1hdAoKICAgVGhlIFJEQVRBIGZvciBhIFRMU0EgUlIgY29uc2lzdHMgb2YgYSBv bmUtb2N0ZXQgc2VsZWN0b3IgZmllbGQsIGEKICAgb25lLW9jdGV0IGNlcnRpZmljYXRlIGZvcm1h dCBmaWVsZCwgYSBvbmUtb2N0ZXQgaWRlbnRpZmllciBmb3JtYXQKICAgZmllbGQsIGFuZCBhIHZh cmlhYmxlLWxlbmd0aCBjZXJ0aWZpY2F0ZSBpZGVudGlmaWVyIGZpZWxkLiAgQWxsCiAgIHRocmVl IG9mIHRoZSBvbmUtb2N0ZXQgZmllbGRzIGFyZSBjb2RlIG51bWJlcnMsIHdoaWNoIHdpbGwgaGF2 ZQogICBJQU5BIHJlZ2lzdHJpZXMgZm9yIGZ1dHVyZSBleHBhbnNpb24gKHNlZSBTZWN0aW9uIDkp LgoKICAgICAgICAgICAgICAgICAgICAgICAgMSAxIDEgMSAxIDEgMSAxIDEgMSAyIDIgMiAyIDIg MiAyIDIgMiAyIDMgMwogICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5 IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgICBTZWxlY3RvciAgICB8 ICBDZXJ0IEZvcm1hdCAgfCAgIElkIEZvcm1hdCAgIHwgICAgICAgICAgICAgICAvCiAgICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgICAgICAgICAgICAg ICAvCiAgIC8gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAvCiAgIC8gICAgICAgICAgICAgICAgICAgIENlcnRpZmljYXRlIElkZW50 aWZpZXIgICAgICAgICAgICAgICAgICAgICAvCiAgIC8gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAvCiAgICstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCgogICBb WyBJbiB3aGF0IGZvbGxvd3MsIGNvZGUgMCBpcyBjb25zaXN0ZW50bHkgInJlc2VydmVkIiBmb3Ig cG9zc2libGUKICAgZnV0dXJlIHVzZSBpbiBhICJtYXRjaCBub3RoaW5nIiByZWNvcmQsIHdoaWNo IHdvdWxkIGhhdmUgdGhlIGVmZmVjdAogICBvZiBwcm9tb3RpbmcgImZhbGxiYWNrIiB0byAiYm9n dXMiIGZvciBhbnkgVExTIHNlcnZlciBwdXJwb3J0aW5nIHRvCiAgIG9wZXJhdGUgYXQgYSBwYXJ0 aWN1bGFyIG5hbWUuICBTZWUgaXNzdWUgIzIzLiBdXQoKMi4xLjIuICBUaGUgU2VsZWN0b3IgRmll bGQKCiAgIFRoZSBjb2RlIG51bWJlciBpbiB0aGlzIGZpZWxkIHNwZWNpZmllcyB3aGljaCBjZXJ0 aWZpY2F0ZXMgaW4gYQogICBjaGFpbiBjYW4gbWF0Y2ggdGhpcyBUTFNBIHJlY29yZC4gIEl0IGFs c28gY29udHJvbHMgdGhlIHByZWNpc2UKICAgc2VtYW50aWNzIG9mIHRoZSBjb25jbHVzaW9uIHRo YXQgd2lsbCBiZSBkcmF3biBmcm9tIGEgc3VjY2Vzc2Z1bAogICBtYXRjaDsgdGhpcyB3aWxsIGJl IGRpc2N1c3NlZCBmdXJ0aGVyIGluIFNlY3Rpb24gNC4KCiAgICAgIDAgLS0gUmVzZXJ2ZWQuCiAg ICAgIDEgLS0gVGhlIGVuZC1lbnRpdHkgY2VydGlmaWNhdGUuCiAgICAgIDIgLS0gQW55IGF1dGhv cml0eSBjZXJ0aWZpY2F0ZSAoaW5jbHVkaW5nIHRoZSB0cnVzdCBhbmNob3IpLgogICAgICAzIC0t IFRoZSB0cnVzdCBhbmNob3IuCgoyLjEuMy4gIFRoZSBDZXJ0aWZpY2F0ZSBGb3JtYXQgRmllbGQK CiAgIFRoZSBjb2RlIG51bWJlciBpbiB0aGlzIGZpZWxkIHNwZWNpZmllcyBob3cgZWFjaCBjZXJ0 aWZpY2F0ZSBpbiB0aGUKICAgY2hhaW4gc2hvdWxkIGJlIGZvcm1hdHRlZCBmb3IgaW5wdXQgdG8g dGhlIG1hdGNoaW5nIGFsZ29yaXRobS4KCiAgICAgIDAgLS0gUmVzZXJ2ZWQuCiAgICAgIDEgLS0g SW5wdXQgYSBQS0lYIENlcnRpZmljYXRlIGJsb2NrIGluIEFTTi4xIERFUiBmb3JtYXQuCiAgICAg IDIgLS0gSW5wdXQgYSBQS0lYIFN1YmplY3RQdWJsaWNLZXlJbmZvIGJsb2NrIGluIEFTTi4xIERF UiBmb3JtYXQuCgogICBJZiBuZXcgcHVibGljLWtleSB0cmFuc3BvcnQgZm9ybWF0cyBhcmUgZGVm aW5lZCBmb3IgdXNlIHdpdGggVExTIGluCiAgIHRoZSBmdXR1cmUsIG5ldyBjZXJ0aWZpY2F0ZSBm b3JtYXQgY29kZXMgc2hvdWxkIGJlIHJlZ2lzdGVyZWQgZm9yCiAgIHRoZW0gYXQgdGhhdCB0aW1l LgoKICAgTm90ZSB0aGF0IHRoZSBBU04uMSBwcm9kdWN0aW9uIGZvciBhICJQS0lYIENlcnRpZmlj YXRlIGJsb2NrIiBpcwogICB0aGUgIkNlcnRpZmljYXRlIiBwcm9kdWN0aW9uIGRlZmluZWQgaW4g W1JGQzUyODBdLCBfbm90XyB0aGUKICAgcHJvZHVjdGlvbiBvZiB0aGUgc2FtZSBuYW1lIGRlZmlu ZWQgaW4gVExTIFtSRkM1MjQ2XS4gIChUaGUgbGF0dGVyCiAgIGlzIGEgd3JhcHBlciBhcm91bmQg dGhlIGZvcm1lci4pCgoyLjEuNC4gIFRoZSBJZGVudGlmaWVyIEZvcm1hdCBGaWVsZAoKICAgVGhl IGNvZGUgbnVtYmVyIGluIHRoaXMgZmllbGQgc3BlY2lmaWVzIHRoZSBjb250ZW50cyBvZiB0aGUK ICAgY2VydGlmaWNhdGUgaWRlbnRpZmllciBmaWVsZC4KCiAgICAgIDAgLS0gUmVzZXJ2ZWQuCiAg ICAgIDEgLS0gQSBmb3JtYXR0ZWQgY2VydGlmaWNhdGUuCiAgICAgIDIgLS0gVGhlIFNIQS0yNTYg aGFzaCBvZiBhIGZvcm1hdHRlZCBjZXJ0aWZpY2F0ZS4KICAgICAgMyAtLSBUaGUgU0hBLTUxMiBo YXNoIG9mIGEgZm9ybWF0dGVkIGNlcnRpZmljYXRlLgoKICAgVGhlIHRlcm0gImZvcm1hdHRlZCBj ZXJ0aWZpY2F0ZSIgbWVhbnMgYSBjZXJ0aWZpY2F0ZSBmb3JtYXR0ZWQgYXMKICAgc3BlY2lmaWVk IGJ5IHRoZSBjZXJ0aWZpY2F0ZSBmb3JtYXQgZmllbGQuICBGb3IgaW5zdGFuY2UsIGlmIHRoZQog ICBjZXJ0aWZpY2F0ZSBmb3JtYXQgZmllbGQgaGFzIHRoZSB2YWx1ZSAyIGFuZCB0aGUgaWRlbnRp ZmllciBmb3JtYXQKICAgZmllbGQgaGFzIHRoZSB2YWx1ZSAxLCB0aGVuIHRoZSBjb250ZW50cyBv ZiB0aGUgY2VydGlmaWNhdGUKICAgaWRlbnRpZmllciBmaWVsZCB3aWxsIGJlIGEgUEtJWCBTdWJq ZWN0UHVibGljS2V5SW5mbyBibG9jay4KCjIuMi4gIFRMU0EgUlIgUHJlc2VudGF0aW9uIEZvcm1h dAoKICAgVGhlIHByZXNlbnRhdGlvbiBmb3JtYXQgb2YgdGhlIFJEQVRBIHBvcnRpb24gaXMgYXMg Zm9sbG93czoKCiAgIG8gIFRoZSBzZWxlY3RvciBmaWVsZCBNVVNUIGJlIHJlcHJlc2VudGVkIGFz IGFuIHVuc2lnbmVkCiAgICAgIGRlY2ltYWwgaW50ZWdlci4KCiAgIG8gIFRoZSBjZXJ0aWZpY2F0 ZSBmb3JtYXQgZmllbGQgTVVTVCBiZSByZXByZXNlbnRlZCBhcyBhbiB1bnNpZ25lZAogICAgICBk ZWNpbWFsIGludGVnZXIuCgogICBvICBUaGUgaWRlbnRpZmllciBmb3JtYXQgZmllbGQgTVVTVCBi ZSByZXByZXNlbnRlZCBhcyBhbiB1bnNpZ25lZAogICAgICBkZWNpbWFsIGludGVnZXIuCgogICBv ICBUaGUgY2VydGlmaWNhdGUgaWRlbnRpZmllciBmaWVsZCBNVVNUIGJlIHJlcHJlc2VudGVkIGFz IGEgc3RyaW5nCiAgICAgIG9mIGhleGFkZWNpbWFsIGNoYXJhY3RlcnMuICBXaGl0ZXNwYWNlLCBp bmNsdWRpbmcgbmV3bGluZXMsIGlzCiAgICAgIGFsbG93ZWQgd2l0aGluIHRoaXMgc3RyaW5nIG9m IGhleGFkZWNpbWFsIGNoYXJhY3RlcnMuCgogICBbWyBDZXJ0aWZpY2F0ZSBpZGVudGlmaWVycyBt YXkgYmUgcXVpdGUgbG9uZy4gU2hvdWxkIHdlIGFsbG93CiAgICAgIGJhc2U2NCBhcyB3ZWxsPyBd XQoKMi4zLiAgRG9tYWluIE5hbWVzIGZvciBUTFNBIFJlY29yZHMKCiAgIEluIG9yZGVyIHRvIGFj Y29tbW9kYXRlIG11bHRpcGxlIFRMUyBzZXJ2ZXJzIG9uIHRoZSBzYW1lIGhvc3QsIFRMU0EKICAg cmVjb3JkcyBhcHBlYXIgYXQgRE5TIG5hbWVzIHdoaWNoIGNhcnJ5IGluZm9ybWF0aW9uIGFib3V0 IHRoZQogICB0cmFuc3BvcnQgcHJvdG9jb2wgYW5kIHNlcnZpY2UgcG9ydCwgYXMgcHJlZml4ZXMg dG8gdGhlIGhvc3RuYW1lLgogICBUbyBjb25zdHJ1Y3QgdGhlIGZ1bGwgRE5TIG5hbWUgYXQgd2hp Y2ggdG8gZmluZCBhIFRMU0EgcmVjb3JkLAogICBmb2xsb3cgdGhpcyBhbGdvcml0aG06CgogICAx LiAgU3RhcnQgd2l0aCB0aGUgZnVsbCBob3N0bmFtZSBvZiB0aGUgc2VydmVyLgoKICAgMi4gIFRv IHRoaXMgaG9zdG5hbWUsIHByZXBlbmQgYSBETlMgPGxhYmVsPiBjb25zaXN0aW5nIG9mIGFuCiAg ICAgICB1bmRlcnNjb3JlIGNoYXJhY3RlciAoIl8iKSBmb2xsb3dlZCBieSB0aGUgbmFtZSBvZiB0 aGUKICAgICAgIHRyYW5zcG9ydCBwcm90b2NvbCB1c2VkIGJ5IHRoZSBzZXJ2aWNlLiAgQW55IHRy YW5zcG9ydCBwcm90b2NvbAogICAgICAgbmFtZSBhbGxvd2VkIGluIHRoZSBTZXJ2aWNlIE5hbWUg YW5kIFRyYW5zcG9ydCBQcm90b2NvbCBQb3J0CiAgICAgICBOdW1iZXIgUmVnaXN0cnkgW1JGQzYz MzVdIG1heSBiZSB1c2VkOyBhdCB0aW1lIG9mIHdyaXRpbmcsCiAgICAgICB0aGVzZSBhcmUgInRj cCIsICJ1ZHAiLCAic2N0cCIsIGFuZCAiZGNjcCIuCgogICAzLiAgVG8gdGhlIGhvc3RuYW1lIGZv cm1lZCBpbiBzdGVwIDIsIHByZXBlbmQgYSBETlMgPGxhYmVsPgogICAgICAgY29uc2lzdGluZyBv ZiBhbiB1bmRlcnNjb3JlIGZvbGxvd2VkIGJ5IHRoZSBkZWNpbWFsCiAgICAgICByZXByZXNlbnRh dGlvbiBvZiB0aGUgcG9ydCBudW1iZXIgYXQgd2hpY2ggdGhlIHNlcnZpY2UgaXMgdG8gYmUKICAg ICAgIGZvdW5kLiAgVGhpcyBkZWNpbWFsIHJlcHJlc2VudGF0aW9uIE1VU1QgaGF2ZSBubyBsZWFk aW5nCiAgICAgICB6ZXJvZXMuCgogICBGb3IgZXhhbXBsZSwgdGhlIFRMU0EgcmVjb3JkIGZvciBh IHNlcnZlciBhY2NlcHRpbmcgVExTIGNvbm5lY3Rpb25zCiAgIG9uIFRDUCBwb3J0IDQ0MyBvZiAi d3d3LmV4YW1wbGUuY29tIiB3aWxsIGJlIGZvdW5kIGF0CiAgICJfNDQzLl90Y3Aud3d3LmV4YW1w bGUuY29tIiwgYW5kIHRoZSByZWNvcmQgZm9yIGEgc2VydmVyIGFjY2VwdGluZwogICBEVExTIGRh dGFncmFtcyBvbiBVRFAgcG9ydCAyMDQ5IG9mICJuZnMuZXhhbXBsZS5jb20iIHdpbGwgYmUgZm91 bmQKICAgYXQgIl8yMDQ5Ll91ZHAubmZzLmV4YW1wbGUuY29tIi4KCiAgIE5vdGUgdGhhdCB0aGVz ZSBwcmVmaXhlcyBhcmUgZGVsaWJlcmF0ZWx5IGRpZmZlcmVudCBmcm9tIHRoZQogICBwcmVmaXhl cyB1c2VkIGZvciBTUlYgcmVjb3Jkcywgd2hpY2ggdXNlIHRoZSBtbmVtb25pYyBuYW1lIG9mIGEK ICAgc2VydmljZSBwcm90b2NvbCByYXRoZXIgdGhhbiBhIHBvcnQgbnVtYmVyLiAgVGhpcyBpcyB0 byBhY2NvbW1vZGF0ZQogICBob3N0cyB0aGF0IHByb3ZpZGUgdGhlIHNhbWUgc2VydmljZSBvbiBt b3JlIHRoYW4gb25lIHBvcnQsIHVzaW5nCiAgIGRpZmZlcmVudCBwdWJsaWMga2V5cyBmb3IgZWFj aC4gIENsaWVudHMgZm9yIHNlcnZpY2VzIHRoYXQgdXNlIFNSVgogICBkaXNjb3ZlcnkgYXJlIGV4 cGVjdGVkIHRvIGxvb2sgdXAgU1JWIHJlY29yZHMgZmlyc3QsIGFuZCB0aGVuIHVzZQogICB0aGUg aG9zdG5hbWUocykgYW5kIHBvcnQocykgdGhhdCB0aGV5IHByb3ZpZGUgdG8gZm9ybSBUTFNBIHJl Y29yZHMuCgogICBbWyBUaGlzIGNvcnJlc3BvbmRzIHRvIHByb3Bvc2FsIChiKSBmb3IgaXNzdWUg IzI4LCB3aGljaCAqc2VlbXMqIHRvCiAgICAgIGJlIHRoZSBjb25zZW5zdXMgaW4gdGhlIHRyYWNr ZXIsIGFuZCBJIHRoaW5rIHdhcyBhbHNvIHRoZSBzdGF0dXMKICAgICAgcXVvIGFudGUuIF1dCgoy LjQuICBUTFNBIFJSIEV4YW1wbGVzCgogIFRoaXMgVExTQSByZWNvcmQgbWF0Y2hlcyBhbiBhdXRo b3JpdHkgY2VydGlmaWNhdGUgYnkgdGhlIFNIQS0yNTYKICBoYXNoIG9mIGEgU3ViamVjdFB1Ymxp Y0tleUluZm8gYmxvY2s6CgogICAgICBfNDQzLl90Y3Aud3d3LmV4YW1wbGUuY29tLiBJTiBUTFNB ICgKICAgICAgICAgMiAyIDIgZDJhYmRlMjQwZDdjZDNlZTZiNGIyOGM1NGRmMDM0YjkKICAgICAg ICAgICAgICAgNzk4M2ExZDE2ZThhNDEwZTQ1NjFjYjEwNjYxOGU5NzEgKQoKICAgVGhpcyBUTFNB IHJlY29yZCBtYXRjaGVzIGFuIGVuZC1lbnRpdHkgY2VydGlmaWNhdGUgYnkgdGhlIFNIQS01MTIK ICAgaGFzaCBvZiBhIENlcnRpZmljYXRlIGJsb2NrOgoKICAgICAgXzQ0My5fdGNwLnd3dy5leGFt cGxlLmNvbS4gSU4gVExTQSAoCiAgICAgICAgIDEgMSAzIDkyMDAzYmEzNDk0MmRjNzQxNTJlMmYy YzQwOGQyOWVjCiAgICAgICAgICAgICAgIGE1YTUyMGU3ZjJlMDZiYjk0NGY0ZGNhMzQ2YmFmNjNj CiAgICAgICAgICAgICAgIDFiMTc3NjE1ZDQ2NmY2YzRiNzFjMjE2YTUwMjkyYmQ1CiAgICAgICAg ICAgICAgIDhjOWViZGQyZjc0ZTM4ZmU1MWZmZDQ4YzQzMzI2Y2JjICkKCiAgIFRoaXMgVExTQSBy ZWNvcmQgbWF0Y2hlcyBhIHRydXN0IGFuY2hvciBjZXJ0aWZpY2F0ZSBieSBkaXJlY3QKICAgY29t cGFyaXNvbiB3aXRoIGEgQ2VydGlmaWNhdGUgYmxvY2s6CgogICAgICBfNDQzLl90Y3Aud3d3LmV4 YW1wbGUuY29tLiBJTiBUTFNBICgKICAgICAgICAgMyAxIDEgMzA4MjAzMDczMDgyMDFlZmEwMDMw MjAxMDIwMjAKICAgICAgICAgICAgICAgLi4ubWFueSBtb3JlIGJ5dGVzLi4uICkKCjMuICBBbGdv cml0aG0gZm9yIEludGVycHJldGF0aW9uIG9mIFRMU0EgUmVjb3JkcwoKICAgVGhlIGlucHV0cyB0 byB0aGlzIGFsZ29yaXRobSBhcmUgdGhlIChwb3NzaWJseSBlbXB0eSkgVExTQSBSUnNldAogICBm b3IgdGhlIHByZWZpeGVkIGRvbWFpbiBuYW1lIGNvcnJlc3BvbmRpbmcgdG8gdGhlIFRMUyBzZXJ2 ZXIncwogICBjb250YWN0IGluZm9ybWF0aW9uOyB0aGUgRE5TU0VDIHZhbGlkYXRpb24gc3RhdGVz IGZvciB0aGF0IFJSc2V0CiAgIGFuZCBmb3IgdGhlIFJSc2V0IG9mIGFkZHJlc3MgcmVjb3JkcyAo QSwgQUFBQSwgZXRjLikgdGhhdCB3YXMgdXNlZAogICB0byBkZXRlcm1pbmUgdGhlIFRMUyBzZXJ2 ZXIncyBuZXR3b3JrIGFkZHJlc3M7IGFuZCB0aGUgY2VydGlmaWNhdGUKICAgY2hhaW4gdGhlIFRM UyBzZXJ2ZXIgaGFzIHByZXNlbnRlZCBpbiBpdHMgaGFuZHNoYWtlIChpbmNsdWRpbmcgdGhlCiAg IHRydXN0IGFuY2hvciwgZXZlbiBpZiB0aGUgdHJ1c3QgYW5jaG9yIHdhcyBvbWl0dGVkIGZyb20g dGhlIGRhdGEgb24KICAgdGhlIHdpcmUpLiAgVGhlIG91dHB1dCBpcyBvbmUgb2YgZm91ciBfY29u Y2x1c2lvbnNfOgoKICAgICAgbyAgRmFsbCBCYWNrOiBObyB1c2FibGUgVExTQSBpbmZvcm1hdGlv biBpcyBhdmFpbGFibGUuCgogICAgICBvICBCb2d1czogVGhlIFRMUyBzZXJ2ZXIncyBjbGFpbSBv ZiBpZGVudGl0eSBpcyBmYWxzZS4KCiAgICAgIG8gIFZhbGlkOiBUaGUgVExTIHNlcnZlcidzIGNs YWltIG9mIGlkZW50aXR5IGlzIHRydWUuCgogICAgICBvICBWYWxpZCBSZXN0cmljdGlvbjogVGhl IFRMUyBzZXJ2ZXIncyBjbGFpbSBvZiBpZGVudGl0eSBpcwogICAgICAgICBwcm9iYWJseSB0cnVl LgoKICAgVGhlIHNlbWFudGljcyBvZiB0aGVzZSBjb25jbHVzaW9ucyB3aWxsIGJlIGRpc2N1c3Nl ZCBmdXJ0aGVyIGluCiAgIHNlY3Rpb24gNC4KCiAgIFRoZSBJQU5BIHJlZ2lzdHJpZXMgZm9yIGFk ZGl0aW9uYWwgY29kZXMgZm9yIHRoZSBzZWxlY3RvciwKICAgY2VydGlmaWNhdGUgZm9ybWF0LCBv ciBpZGVudGlmaWVyIGZvcm1hdCBmaWVsZHMgd2lsbCBhbHNvIHJlZ2lzdGVyCiAgIGFkZGl0aW9u YWwgcnVsZXMgZm9yIHRoZWlyIGludGVycHJldGF0aW9uLCB3aGljaCBzaGFsbCBiZQogICB1bmRl cnN0b29kIHRvIGF1Z21lbnQgdGhpcyBhbGdvcml0aG0gYXBwcm9wcmlhdGVseS4KCjMuMS4gIERO U1NFQyBWYWxpZGF0aW9uCgogICBCZWZvcmUgcHJvY2Vzc2luZyB0aGUgY29udGVudHMgb2YgdGhl IFRMU0EgcmVjb3JkcyBpbiBhbnkgd2F5LCBvcgogICBldmVuIGNvbnNpZGVyaW5nIGhvdyBtYW55 IG9mIHRoZW0gdGhlcmUgYXJlLCBjaGVjayB0aGUgRE5TU0VDCiAgIHZhbGlkYXRpb24gc3RhdGUg W1JGQzQwMzNdIGZvciB0aGUgVExTQSBSUnNldCBhbmQgdGhlIGFkZHJlc3MKICAgUlJzZXQuCgog ICBvICBJZiBlaXRoZXIgdmFsaWRhdGlvbiBzdGF0ZSBpcyAiYm9ndXMiLCBjb25jbHVkZSAiYm9n dXMiLgoKICAgbyAgSWYgZWl0aGVyIHZhbGlkYXRpb24gc3RhdGUgaXMgImluc2VjdXJlIiBvciAi aW5kZXRlcm1pbmF0ZSIsCiAgICAgIGNvbmNsdWRlICJmYWxsIGJhY2siLgoKICAgbyAgSWYgYm90 aCB2YWxpZGF0aW9uIHN0YXRlcyBhcmUgInNlY3VyZSIsIGNvbnRpbnVlLgoKICAgSXQgaXMgaW1w bGljaXQgaW4gdGhlIGFib3ZlIHJ1bGVzLCBidXQgd2UgZW1waGFzaXplIHRoYXQgaWYgdGhlCiAg IFRMU0EgUlJzZXQgaXMgZW1wdHksIGJ1dCB0aGUgcXVlcnkgZGlkIG5vdCByZXR1cm4gYXBwcm9w cmlhdGUsCiAgIHNpZ25lZCwgTlNFQyBvciBOU0VDMyByZWNvcmRzIHByb3ZpbmcgdGhhdCBubyBU TFNBIHJlY29yZHMgZXhpc3QsCiAgIGFuZCB0aGUgem9uZSBpcyBrbm93biB0byBiZSBzaWduZWQs IHRoZSBjb25jbHVzaW9uIGlzICJib2d1cyIuCgogICBbWyBJdCBpcyBteSBjb25zaWRlcmVkIGFu ZCB2ZWhlbWVudCBvcGluaW9uIHRoYXQgaXNzdWUgIzM2IHNob3VsZAogICAgICBiZSByZWplY3Rl ZC4gIEkgaGF2ZSBwbGFjZWQgYSByYXRpb25hbGUgZm9yIHRoaXMgZGVjaXNpb24gaW4KICAgICAg c2VjdGlvbiA3LiBdXQoKMy4yLiAgUHJ1bmluZwoKICAgTmV4dCwgaW5zcGVjdCB0aGUgc2VsZWN0 b3IsIGNlcnRpZmljYXRlIGZvcm1hdCwgYW5kIGlkZW50aWZpZXIKICAgZm9ybWF0IGZpZWxkcyBv ZiBlYWNoIFRMU0EgUlIuICBJZiBhbnkgb2YgdGhlc2UgZmllbGRzIGNvbnRhaW5zCiAgIGEgdmFs dWUgdGhhdCBpcyBub3QgcmVjb2duaXplZCBvciBub3Qgc3VwcG9ydGVkLCBkaXNjYXJkIHRoYXQg UlIuCiAgIElmIGFsbCBvZiB0aGUgZmllbGRzIGNvbnRhaW4gcmVjb2duaXphYmxlIHZhbHVlcywg YnV0IHRoZSBkYXRhIGluCiAgIHRoZSBjZXJ0aWZpY2F0ZSBpZGVudGlmaWVyIGZpZWxkIGlzIGlu Y29uc2lzdGVudCB3aXRoIHRoZQogICByZXF1aXJlbWVudHMgb2YgdGhlIGNlcnRpZmljYXRlIGZv cm1hdCBhbmQgaWRlbnRpZmllciBmb3JtYXQKICAgZmllbGRzLCBhbHNvIGRpc2NhcmQgdGhhdCBS Ui4KCiAgIElmIG5vIFJScyBzdXJ2aXZlIHRoaXMgc3RlcCwgY29uY2x1ZGUgImZhbGwgYmFjayIu CgozLjMuICBNYXRjaGluZwoKICAgQ29tcGFyZSBlYWNoIGNlcnRpZmljYXRlIGluIHRoZSBjaGFp biB0byBlYWNoIHN1cnZpdmluZyBSUi4gIEZpcnN0CiAgIGNoZWNrIHRoZSBzZWxlY3RvcjoKCiAg IG8gIElmIHRoZSByZWNvcmQgc2VsZWN0b3IgZmllbGQgaXMgMSBhbmQgdGhlIGNlcnRpZmljYXRl CiAgICAgIGlzIG5vdCBhbiBlbmQtZW50aXR5IGNlcnRpZmljYXRlLCB0aGV5IGRvIG5vdCBtYXRj aC4KICAgbyAgSWYgdGhlIHJlY29yZCBzZWxlY3RvciBmaWVsZCBpcyAyIGFuZCB0aGUgY2VydGlm aWNhdGUKICAgICAgaXMgbm90IGFuIGF1dGhvcml0eSBjZXJ0aWZpY2F0ZSwgdGhleSBkbyBub3Qg bWF0Y2guCiAgIG8gIElmIHRoZSByZWNvcmQgc2VsZWN0b3IgZmllbGQgaXMgMyBhbmQgdGhlIGNl cnRpZmljYXRlCiAgICAgIGlzIG5vdCBhIHRydXN0LWFuY2hvciBjZXJ0aWZpY2F0ZSwgdGhleSBk byBub3QgbWF0Y2guCgogICBBIHNlbGYtc2lnbmVkIGNlcnRpZmljYXRlIGlzIGNvbnNpZGVyZWQg dG8gYmUgc2ltdWx0YW5lb3VzbHkgYW4KICAgZW5kLWVudGl0eSBjZXJ0aWZpY2F0ZSBhbmQgYSB0 cnVzdC1hbmNob3IgY2VydGlmaWNhdGUuICBbWyBJIHRoaW5rCiAgIHRoaXMgc2VudGVuY2UsIHBs dXMgdGhlIHJ1bGVzIGZvciBjb25jbHVzaW9ucyBiYXNlZCBvbiBzZWxlY3RvciAzLAogICBwbHVz IHRoZSBleGFtcGxlIGluIHNlY3Rpb24gNi41LCB0b2dldGhlciBzaG91bGQgcmVzb2x2ZSBpc3N1 ZSAjMzcuIF1dCgogICBJZiB0aGUgcGFpciBvZiBjYW5kaWRhdGVzIHN1cnZpdmVkIHRoYXQgc3Rl cCwgZm9ybWF0IHRoZSBjZXJ0aWZpY2F0ZToKCiAgIG8gIElmIHRoZSBjZXJ0aWZpY2F0ZSBmb3Jt YXQgZmllbGQgaXMgMSwgZXh0cmFjdCB0aGUgQ2VydGlmaWNhdGUKICAgICAgYmxvY2sgYW5kIHJl Zm9ybWF0IGl0IHRvIEFTTi4xIERFUi4KICAgbyAgSWYgdGhlIGNlcnRpZmljYXRlIGZvcm1hdCBm aWVsZCBpcyAyLCBleHRyYWN0IHRoZQogICAgICBTdWJqZWN0UHVibGljS2V5SW5mbyBibG9jayBh bmQgcmVmb3JtYXQgaXQgdG8gQVNOLjEgREVSLgoKICAgUG9zc2libHkgaGFzaCB0aGUgY2VydGlm aWNhdGU6CgogICBvICBJZiB0aGUgaWRlbnRpZmllciBmb3JtYXQgZmllbGQgaXMgMSwgZG8gbm90 aGluZy4KICAgbyAgSWYgdGhlIGlkZW50aWZpZXIgZm9ybWF0IGZpZWxkIGlzIDIsIGNvbXB1dGUg dGhlIFNIQS0yNTYgaGFzaCBvZgogICAgICB0aGUgb3V0cHV0IGZyb20gdGhlIHByZXZpb3VzIHN0 ZXAuCiAgIG8gIElmIHRoZSBpZGVudGlmaWVyIGZvcm1hdCBmaWVsZCBpcyAzLCBjb21wdXRlIHRo ZSBTSEEtNTEyIGhhc2ggb2YKICAgICAgdGhlIG91dHB1dCBmcm9tIHRoZSBwcmV2aW91cyBzdGVw LgoKICAgRm91cnRoLCBjb21wYXJlIHRoZSByZXN1bHQgd2l0aCB0aGUgY29udGVudHMgb2YgdGhl IGNlcnRpZmljYXRlCiAgIGlkZW50aWZpZXIgZmllbGQuICBJZiB0aGV5IGFyZSBieXRlLWZvci1i eXRlIGlkZW50aWNhbCwgdGhlCiAgIGNlcnRpZmljYXRlIGFuZCB0aGUgVExTQSByZWNvcmQgbWF0 Y2guICBPdGhlcndpc2UsIHRoZXkgZG8gbm90IG1hdGNoLgoKMy40LiAgQ29uY2x1c2lvbgoKICAg QWZ0ZXIgY29tcGFyaW5nIGFsbCBUTFNBIHJlY29yZHMgdG8gYWxsIGNlcnRpZmljYXRlczoKCiAg IElmIGF0IGxlYXN0IG9uZSBUTFNBIHJlY29yZCB3aG9zZSByZWNvcmQgc2VsZWN0b3IgZmllbGQg d2FzIDMgbWF0Y2hlZAogICBhIGNlcnRpZmljYXRlLCBjb25jbHVkZSAidmFsaWQiLgoKICAgSWYg YXQgbGVhc3Qgb25lIFRMU0EgcmVjb3JkIHdob3NlIHJlY29yZCBzZWxlY3RvciBmaWVsZCB3YXMg MSBvciAyCiAgIG1hdGNoZWQgYSBjZXJ0aWZpY2F0ZSwgY29uY2x1ZGUgInZhbGlkIHJlc3RyaWN0 aW9uIi4KCiAgIE90aGVyd2lzZSBjb25jbHVkZSAiYm9ndXMiLgoKNC4gIENsaWVudCBSZXF1aXJl bWVudHMKCiAgIENsaWVudHMgY29uZm9ybWluZyB0byB0aGlzIHNwZWNpZmljYXRpb24gU0hPVUxE LCBwcmlvciB0bwogICBpbnRlcnByZXRpbmcgVExTQSByZWNvcmRzLCB2YWxpZGF0ZSB0aGUgY2Vy dGlmaWNhdGUgY2hhaW4gYXMgdGhleQogICB3b3VsZCBoYXZlIGlmIHRoZXkgd2VyZSBub3QgYXdh cmUgb2YgVExTQSBpbmZvcm1hdGlvbiAoZm9yCiAgIGluc3RhbmNlLCByZWplY3RpbmcgY2VydGlm aWNhdGVzIHdoaWNoIGFyZSBpbGwtZm9ybWVkLCBleHBpcmVkLCBvcgogICBoYXZlIGludmFsaWQg c2lnbmF0dXJlcykgd2l0aCB0aGUgZXhjZXB0aW9uIHRoYXQgdGhleSBNVVNUIGRlbGF5CiAgIGRl Y2lkaW5nIHdoZXRoZXIgdGhlIGNoYWluIHRlcm1pbmF0ZXMgaW4gYW4gYWNjZXB0YWJsZSB0cnVz dCBhbmNob3IKICAgdW50aWwgYWZ0ZXIgVExTQSByZWNvcmRzIGhhdmUgYmVlbiBpbnRlcnByZXRl ZC4KCiAgIFtbIEkgYmVsaWV2ZSB0aGUgYWJvdmUgcGFyYWdyYXBoIGFkZHJlc3NlcyBpc3N1ZSAj MTguIF1dCgogICBbWyBBTUJJR1VJVFk6IFdoYXQgc2hvdWxkIGEgREFORS1jb21wbGlhbnQgY2xp ZW50IGRvIHdpdGggYW4KICAgICAgZW5kLWVudGl0eSBjZXJ0aWZpY2F0ZSB3aG9zZSBlbWJlZGRl ZCBuYW1lIGluZm9ybWF0aW9uIGRvZXMKICAgICAgbm90IGNvcnJlc3BvbmQgdG8gdGhlIGhvc3Ru YW1lIGl0IGNvbm5lY3RlZCB0bz8gIFNob3VsZCBUTFNBCiAgICAgIHJlY29yZHMgb3ZlcnJpZGUg ZW1iZWRkZWQgbmFtZSBpbmZvcm1hdGlvbiwgYW5kIGlmIHNvLCBmb3Igd2hpY2gKICAgICAgc2Vs ZWN0b3IgY29kZXM/ICBUaGlzIGlzIGlzc3VlICMxMy4gXV0KCiAgIENsaWVudHMgTVVTVCBpbnRl cnByZXQgVExTQSByZWNvcmRzIGFzIGlmIHRoZXkgaW1wbGVtZW50ZWQgdGhlCiAgIGFsZ29yaXRo bSBkZXNjcmliZWQgaW4gc2VjdGlvbiAzLgoKICAgQ2xpZW50cyBNVVNUIGJlIGFibGUgdG8gaW50 ZXJwcmV0IFRMU0EgcmVjb3JkcyB3aXRoIHNlbGVjdG9yIGNvZGVzCiAgIDEsIDIsIGFuZCAzOyBj ZXJ0aWZpY2F0ZSBmb3JtYXQgY29kZXMgMSBhbmQgMjsgYW5kIGlkZW50aWZpZXIKICAgZm9ybWF0 IGNvZGVzIDEgYW5kIDIuICBUaGV5IFNIT1VMRCBhbHNvIGJlIGFibGUgdG8gaW50ZXJwcmV0IFRM U0EKICAgcmVjb3JkcyB3aXRoIGlkZW50aWZpZXIgZm9ybWF0IGNvZGUgMyAoU0hBLTUxMikuCgog ICBJbiBvcmRlciB0byBjYXJyeSBvdXQgdGhlIGFsZ29yaXRobSBkZXNjcmliZWQgaW4gc2VjdGlv biAzLCBjbGllbnRzCiAgIE1VU1QgaGF2ZSBhY2Nlc3MgdG8gRE5TU0VDIHZhbGlkYXRpb24gaW5m b3JtYXRpb24gZm9yIFJSc2V0cy4KICAgRXhhY3RseSBob3cgdGhpcyBpcyBhY2NvbXBsaXNoZWQs IGhvd2V2ZXIsIGlzIGJleW9uZCB0aGUgc2NvcGUgb2YKICAgdGhpcyBkb2N1bWVudC4gIFNvbWUg cG9zc2liaWxpdGllcyBrbm93biB0byB0aGUgYXV0aG9ycyBhcmU6IHRoZQogICBjbGllbnQgbWF5 IGRvIGFsbCB0aGUgbmVjZXNzYXJ5IEROUyBxdWVyaWVzIGFuZCB2ZXJpZmljYXRpb24KICAgaXRz ZWxmOyBpdCBtYXkgcmVseSB1cG9uIGEgcmVjdXJzaXZlIG5hbWUgc2VydmVyIHRvIGRvIHRoZQog ICB2YWxpZGF0aW9uIGZvciBpdCwgYXMgZGlzY3Vzc2VkIGluIFtSRkM0MDMzXSwgaW4gd2hpY2gg Y2FzZSB0aGUKICAgY29tbXVuaWNhdGlvbnMgY2hhbm5lbCBiZXR3ZWVuIHRoZSBjbGllbnQgYW5k IHRoZSBuYW1lIHNlcnZlciBNVVNUCiAgIGJlIHRhbXBlci1wcm9vZjsgb3IgaXQgbWF5IGRlbGVn YXRlIHRoZSBfcmV0cmlldmFsXyBvZiBhbGwgdGhlCiAgIG5lY2Vzc2FyeSBETlNTRUMgUlJzIHRv IHRoZSBUTFMgc2VydmVyLCBidXQgZG8gdGhlIHZhbGlkYXRpb24KICAgaXRzZWxmLCBhcyBkaXNj dXNzZWQgaW4gW2RyYWZ0LWFnbC1kYW5lLXNlcmlhbGl6ZWNoYWluXS4KCiAgIFtbIFRoZSBhYm92 ZSBwYXJhZ3JhcGggbWF5IGJlIHN1ZmZpY2llbnQgdG8gYWRkcmVzcyBpc3N1ZSAjODsKICAgICB0 aG91Z2h0cz8gXV0KCiAgIEF0IHRoZSB0aW1lIG9mIHdyaXRpbmcsIGEgbmV3IGZhbWlseSBvZiBo YXNoIGFsZ29yaXRobXMgY2FsbGVkCiAgIFNIQS0zIGlzIHVuZGVyIGRldmVsb3BtZW50LiAgSXQg aXMgZXhwZWN0ZWQgdGhhdCBjbGllbnRzIHdpbGwgYmUKICAgcmVxdWlyZWQgdG8gc3VwcG9ydCBU TFNBIHJlY29yZHMgdXNpbmcgYWxnb3JpdGhtcyBmcm9tIHRoYXQgZmFtaWx5CiAgIGFmdGVyIHRo ZXkgYXJlIGZ1bGx5IGRlZmluZWQuICBBdCB0aGF0IHRpbWUsIHRoaXMgc3BlY2lmaWNhdGlvbgog ICB3aWxsIGJlIHVwZGF0ZWQuCgo0LjEuICBTZW1hbnRpY3Mgb2YgQ29uY2x1c2lvbnMKCiAgIEEg ImZhbGwgYmFjayIgY29uY2x1c2lvbiBwcm92aWRlcyBubyBpbmZvcm1hdGlvbiBhYm91dCB0aGUK ICAgY2VydGlmaWNhdGUgY2hhaW4uICBBICJib2d1cyIgY29uY2x1c2lvbiBpcyBkZWZpbml0aXZl IGV2aWRlbmNlCiAgIHRoYXQgdGhlIGNlcnRpZmljYXRlIGNoYWluIGlzIGEgZm9yZ2VyeTsgYSAi dmFsaWQgcmVzdHJpY3Rpb24iCiAgIGNvbmNsdXNpb24gaXMgZXZpZGVuY2UgaW4gZmF2b3Igb2Yg aXRzIGJlaW5nIGxlZ2l0aW1hdGU7IGFuZCBhCiAgICJ2YWxpZCIgY29uY2x1c2lvbiBpcyBkZWZp bml0aXZlIGV2aWRlbmNlIHRoYXQgaXQgaXMgbGVnaXRpbWF0ZS4KICAgVGhlcmVmb3JlOgoKICAg QSBjbGllbnQgdGhhdCBjb25jbHVkZXMgImZhbGwgYmFjayIgTVVTVCBiZWhhdmUgZXhhY3RseSBh cyBhIFRMUwogICBjbGllbnQgdGhhdCB3YXMgdW5hd2FyZSBvZiBEQU5FIHdvdWxkIGhhdmUgYmVo YXZlZCBpbiB0aGUgc2FtZQogICBzaXR1YXRpb24uCgogICBBIGNsaWVudCB0aGF0IGNvbmNsdWRl cyAiYm9ndXMiIE1VU1QgcmVqZWN0IHRoZSBzZXJ2ZXIncyBjbGFpbSBvZgogICBpZGVudGl0eS4K CiAgIEEgY2xpZW50IHRoYXQgY29uY2x1ZGVzICJ2YWxpZCByZXN0cmljdGlvbiIgU0hPVUxEIHBy b2NlZWQgdG8KICAgY29uc3VsdCBpdHMgbGlzdCBvZiB0cnVzdCBhbmNob3JzIGZvciByZWxpYWJs ZSBDQXMsIGFuZCBkZXRlcm1pbmUKICAgd2hldGhlciB0byBhY2NlcHQgdGhlIHNlcnZlcidzIGNs YWltIG9mIGlkZW50aXR5IGJhc2VkIG9uIHdoZXRoZXIKICAgdGhlIGNoYWluIHRlcm1pbmF0ZXMg aW4gYW4gYW5jaG9yIG9uIHRoYXQgbGlzdC4KCiAgIEEgY2xpZW50IHRoYXQgY29uY2x1ZGVzICJ2 YWxpZCIgU0hPVUxEIGFjY2VwdCB0aGUgc2VydmVyJ3MgY2xhaW0gb2YKICAgaWRlbnRpdHksIHdo ZXRoZXIgb3Igbm90IHRoZSB0cnVzdCBhbmNob3IgaXMgaW4gaXRzIHRydXN0IHBvb2wuCiAgIEhv d2V2ZXIsIGlmIHRoZSBjbGllbnQgaGFzIGEgc2Vjb25kIHBvb2wgb2YgdHJ1c3QgYW5jaG9ycyB0 aGF0IGFyZQogICBrbm93biB0byBiZSBfdW5yZWxpYWJsZV8sIGFuZCB0aGUgdHJ1c3QgYW5jaG9y IGlzIGluIF90aGF0XyBwb29sLAogICB0aGVuIHRoZSBjbGllbnQgU0hPVUxEIHN0aWxsIHJlamVj dCB0aGUgY2xhaW0gb2YgaWRlbnRpdHkuCgogICBDbGllbnRzIE1VU1QgTk9UIGludGVycHJldCBw b3NpdGl2ZSBjb25jbHVzaW9ucyAoInZhbGlkIiBhbmQgInZhbGlkCiAgIHJlc3RyaWN0aW9uIikg YXMgdmVyaWZ5aW5nIGFueSBuYW1lIGluZm9ybWF0aW9uIGluIHRoZSBjZXJ0aWZpY2F0ZQogICBv dGhlciB0aGFuIHRoZSBzcGVjaWZpYyBob3N0bmFtZSBhdCB3aGljaCB0aGUgbWF0Y2hpbmcgVExT QSByZWNvcmQKICAgd2FzIGZvdW5kLiAgRm9yIGV4YW1wbGUsIGFuIGVuZC1lbnRpdHkgY2VydGlm aWNhdGUgd2l0aCBtYW55CiAgIGhvc3RuYW1lcyBpbiBpdHMgc3ViamVjdEFsdE5hbWUgZXh0ZW5z aW9uLCBjb25maXJtZWQgdG8gYmUKICAgbGVnaXRpbWF0ZSBmb3Igb25lIG9mIHRob3NlIGhvc3Ru YW1lcyBieSBUTFNBIGluZm9ybWF0aW9uLCBNVVNUIE5PVAogICBiZSBhc3N1bWVkIHRvIGJlIHZh bGlkIGZvciB0aG9zZSBvdGhlciBob3N0bmFtZXMgYXMgd2VsbC4gIE5hbWVzCiAgIHRoYXQgYXJl IG5vdCBob3N0bmFtZXMgYXJlIGNvbXBsZXRlbHkgb3V0IG9mIHRoZSBzY29wZSBvZiBEQU5FLCBh bmQKICAgTVVTVCBiZSB2YWxpZGF0ZWQgYnkgb3RoZXIgbWVhbnMgaWYgbmVjZXNzYXJ5LgoKNS4g IEROUyBTZXJ2aWNlIFJlcXVpcmVtZW50cwoKICAgRE5TIHN5c3RlbXMgY29uZm9ybWluZyB0byB0 aGlzIHNwZWNpZmljYXRpb24gTVVTVCBiZSBhYmxlIHRvIGNyZWF0ZQogICBhbmQgc2VydmUgVExT QSByZWNvcmRzIHdpdGggc2VsZWN0b3IgY29kZXMgMSwgMiwgYW5kIDM7IGNlcnRpZmljYXRlCiAg IGZvcm1hdCBjb2RlcyAxIGFuZCAyOyBhbmQgaWRlbnRpZmllciBmb3JtYXQgY29kZXMgMSBhbmQg Mi4KICAgVGhleSBTSE9VTEQgYWxzbyBiZSBhYmxlIHRvIGNyZWF0ZSBhbmQgc2VydmUgVExTQSBy ZWNvcmRzIHdpdGgKICAgaWRlbnRpZmllciBmb3JtYXQgY29kZSAzIChTSEEtNTEyKS4KCiAgIENs aWVudHMgYXJlIHJlcXVpcmVkIHRvIGlnbm9yZSBhbGwgVExTQSByZWNvcmRzIGZvdW5kIGluIGFu CiAgIHVuc2lnbmVkIHpvbmU7IHRoZXJlZm9yZSwgVExTQSByZWNvcmRzIE1VU1QgTk9UIGJlIGRl cGxveWVkCiAgIGluIGFuIHVuc2lnbmVkIHpvbmUuCgogICBUaGUgY29udGVudHMgb2YgYSBUTFNB IHJlY29yZCdzIGNlcnRpZmljYXRlIGlkZW50aWZpZXIgZmllbGQgTVVTVAogICBiZSBjb25zaXN0 ZW50IHdpdGggdGhlIGNvbnRlbnRzIG9mIGl0cyBpZGVudGlmaWVyIGZvcm1hdCBhbmQKICAgY2Vy dGlmaWNhdGUgZm9ybWF0IGZpZWxkcywgdG8gdGhlIGV4dGVudCB0aGF0IHRoaXMgY2FuIGJlCiAg IG1lY2hhbmljYWxseSB2ZXJpZmllZC4gIEZvciB0aGUgY29kZXMgZGVmaW5lZCBpbiB0aGlzCiAg IGRvY3VtZW50LCB0aGF0IG1lYW5zOgoKICAgbyAgSWYgdGhlIGlkZW50aWZpZXIgZm9ybWF0IGlz IDMsIHRoZSBjZXJ0aWZpY2F0ZSBpZGVudGlmaWVyIE1VU1QKICAgICAgY29udGFpbiBleGFjdGx5 IDY0IGJ5dGVzIG9mIGRhdGEuCiAgIG8gIElmIHRoZSBpZGVudGlmaWVyIGZvcm1hdCBpcyAyLCB0 aGUgY2VydGlmaWNhdGUgaWRlbnRpZmllciBNVVNUCiAgICAgIGNvbnRhaW4gZXhhY3RseSAzMiBi eXRlcyBvZiBkYXRhLgogICBvICBJZiB0aGUgaWRlbnRpZmllciBmb3JtYXQgaXMgMSBhbmQgdGhl IGNlcnRpZmljYXRlIGZvcm1hdCBpcyAyLAogICAgICB0aGUgY2VydGlmaWNhdGUgaWRlbnRpZmll ciBNVVNUIGNvbnRhaW4gYSB2YWxpZCBBU04uMSBERVIKICAgICAgZW5jb2Rpbmcgb2YgYSBTdWJq ZWN0UHVibGljS2V5SW5mbyBibG9jay4KICAgbyAgSWYgdGhlIGlkZW50aWZpZXIgZm9ybWF0IGlz IDEgYW5kIHRoZSBjZXJ0aWZpY2F0ZSBmb3JtYXQgaXMgMSwKICAgICAgdGhlIGNlcnRpZmljYXRl IGlkZW50aWZpZXIgTVVTVCBjb250YWluIGEgdmFsaWQgQVNOLjEgREVSCiAgICAgIGVuY29kaW5n IG9mIGEgQ2VydGlmaWNhdGUgYmxvY2suCgogICBBcyB3aXRoIGNsaWVudHMsIGl0IGlzIGV4cGVj dGVkIHRoYXQgRE5TIHNlcnZpY2VzIHdpbGwgYmUgcmVxdWlyZWQKICAgdG8gc3VwcG9ydCBUTFNB IHJlY29yZHMgdXNpbmcgaGFzaCBhbGdvcml0aG1zIGZyb20gdGhlIFNIQS0zIGZhbWlseQogICBh ZnRlciB0aG9zZSBhbGdvcml0aG1zIGFyZSBmdWxseSBkZWZpbmVkLiAgQXQgdGhhdCB0aW1lLCB0 aGlzCiAgIHNwZWNpZmljYXRpb24gd2lsbCBiZSB1cGRhdGVkLgoKNS4xLiAgWm9uZSBPcGVyYXRv ciBSZWNvbW1lbmRhdGlvbnMKCiAgIEJlY2F1c2UgY2VydGlmaWNhdGVzIGNhbiBiZSB2ZXJ5IGxh cmdlLCBUTFNBIHJlY29yZHMgU0hPVUxEIE5PVCB1c2UKICAgaWRlbnRpZmllciBmb3JtYXQgMSwg ZXhjZXB0IHdoZW4gdGhlIGNsaWVudCBpcyB1bmxpa2VseSB0byBhbHJlYWR5CiAgIGhhdmUgdGhl IGZ1bGwgY2VydGlmaWNhdGUgYW5kIHdpbGwgbm90IHJlY2VpdmUgaXQgYXMgcGFydCBvZiB0aGUK ICAgaGFuZHNoYWtlLgoKICAgV2hlbmV2ZXIgcG9zc2libGUsIFRMU0EgcmVjb3JkcyBTSE9VTEQg dXNlIHRoZSBpZGVudGlmaWVyIGZvcm1hdAogICB0aGF0IHNwZWNpZmllcyB0aGUgc2FtZSBoYXNo IGZ1bmN0aW9uIGFzIGlzIHVzZWQgZm9yIHRoZSBzaWduYXR1cmUKICAgb24gdGhlIGNlcnRpZmlj YXRlLgoKICAgQ0FzIGZyZXF1ZW50bHkgcmUtaXNzdWUgY2VydGlmaWNhdGVzLCBpbmNsdWRpbmcg dHJ1c3QgYW5jaG9ycywgd2l0aAogICBtb2RpZmllZCBhbmNpbGxhcnkgZGF0YS4gIFNlcnZlciBv cGVyYXRvcnMgbWF5IHdpc2ggdG8gdXBkYXRlIHRoZWlyCiAgIGVuZC1lbnRpdHkgY2VydGlmaWNh dGUgd2l0aG91dCBhbHNvIHVwZGF0aW5nIHRoZSB6b25lLiAgSXQgaXMKICAgaW1wb3NzaWJsZSB0 byBwcmVkaWN0IGV4YWN0bHkgd2hpY2ggdmVyc2lvbiBvZiBhIHRydXN0IGFuY2hvciBhbnkKICAg Z2l2ZW4gY2xpZW50IHdpbGwgaGF2ZS4gIFNvbWUgY2xpZW50cyBpbiB3aWRlIHVzZSB0b2RheSBz aWxlbnRseQogICByZXBsYWNlIGludGVybWVkaWF0ZSBhdXRob3JpdHkgY2VydGlmaWNhdGVzIHBy b3ZpZGVkIGJ5IHRoZSBzZXJ2ZXIKICAgd2l0aCBuZXdlciB2ZXJzaW9ucyBmcm9tIGFuIGludGVy bmFsIGNhY2hlIGJlZm9yZSBkb2luZyBhbnkgb3RoZXIKICAgcHJvY2Vzc2luZy4gIE5vbmUgb2Yg dGhlc2Ugc291cmNlcyBvZiB2YXJpYXRpb24gY2hhbmdlIHRoZQogICBTdWJqZWN0UHVibGljS2V5 SW5mbyBibG9jay4gIFRoZXJlZm9yZSwgVExTQSByZWNvcmRzIFNIT1VMRCB1c2UKICAgY2VydGlm aWNhdGUgZm9ybWF0IDIsIGV4Y2VwdCBpbiB0aGUgc2FtZSBjYXNlIHdoZXJlIGlkZW50aWZpZXIK ICAgZm9ybWF0IDEgaXMgYXBwcm9wcmlhdGUuCgo2LiAgRXhhbXBsZSBVc2FnZSBTY2VuYXJpb3MK CiAgIEZvciBzaW1wbGljaXR5J3Mgc2FrZSwgdGhlc2Ugc2NlbmFyaW9zIGFsbCByZWxhdGUgdG8g dGhlIG9wZXJhdGlvbgogICBvZiBIVFRQUyBzZXJ2ZXJzIG9uIFRDUCBwb3J0IDQ0MyBvZiBhIGRv bWFpbiBuYW1lIG9yIGRvbWFpbiBuYW1lcywKICAgYW5kIGFsbCBvZiB0aGUgZXhhbXBsZSByZWNv cmRzIHVzZSBpZGVudGlmaWVyIGZvcm1hdCAyIChTSEEyNTYpIGFuZAogICBjZXJ0aWZpY2F0ZSBm b3JtYXQgMiAoU1BLSSkuICBDaG9pY2Ugb2YgaWRlbnRpZmllciBhbmQgY2VydGlmaWNhdGUKICAg Zm9ybWF0IGlzIGRpc2N1c3NlZCBpbiBzZWN0aW9uIDUuMS4gIElzc3VlcyByZWxhdGluZyB0byBv cGVyYXRpb24KICAgb2YgbXVsdGlwbGUgc2VydmVycyBvbiB0aGUgc2FtZSBob3N0IGFyZSBkaXNj dXNzZWQgaW4gc2VjdGlvbiA4LgogICBGb3IgbW9yZSBkaXNjdXNzaW9uIG9mIHVzZSBjYXNlcyBh bmQgcmVxdWlyZW1lbnRzLCBzZWUgW1JGQzYzOTRdLgoKICAgVGhpcyBzZWN0aW9uIGZyZXF1ZW50 bHkgcmVmZXJzIHRvICJhY3F1aXJpbmcgKGFuKSBpbGxlZ2l0aW1hdGUKICAgY2VydGlmaWNhdGUo cykgZnJvbSAoYS90aGUpIENBIi4gIFRoaXMgcGhyYXNlIGlzIG1lYW50IHRvIGVuY29tcGFzcwog ICBhbGwgb2YgdGhlIHBvc3NpYmxlIHdheXMgdGhhdCBhbiBhdHRhY2tlciBjb3VsZCBkbyB0aGlz LCB3aXRoIG9yCiAgIHdpdGhvdXQgdGhlIGNvbGx1c2lvbiBvZiB0aGUgQ0Egb3IgaW5zaWRlcnMg dGhlcmUuCgo2LjEuICBDZXJ0aWZpY2F0ZSBQaW5uaW5nCgogICBBbGljZSBvcGVyYXRlcyBhIHNp bmdsZSBIVFRQUyBzZXJ2ZXIgYXQgd3d3LmFsaWNlLmV4YW1wbGUuLCBhbmQgaGFzCiAgIGEgY2Vy dGlmaWNhdGUgc2lnbmVkIGJ5IGEgQ0EgZm9yIHRoaXMgc2VydmVyLiAgU2hlIHdpc2hlcyB0byBk ZWZlbmQKICAgYWdhaW5zdCBhdHRhY2tlcnMgd2hvIGhhdmUgYWNxdWlyZWQgYW4gaWxsZWdpdGlt YXRlIGNlcnRpZmljYXRlIGZvcgogICBoZXIgaG9zdG5hbWUsIGZyb20gYW55IENBLCBhbmQgbWVh biB0byByZWRpcmVjdCB0cmFmZmljIGF3YXkgZnJvbQogICBoZXIgc2VydmVyLiAgQmVjYXVzZSBB bGljZSBoYXMgb25seSBvbmUgc2VydmVyLCBzaGUgY2FuIGVhc2lseQogICB1cGRhdGUgaGVyIERO UyB6b25lIHdoZW5ldmVyIGl0cyBrZXkgY2hhbmdlcy4KCiAgIEFsaWNlIHB1Ymxpc2hlcyBhIFRM U0EgcmVjb3JkIHdpdGggc2VsZWN0b3IgY29kZSAxLCBzcGVjaWZ5aW5nIGhlcgogICBzZXJ2ZXIn cyBjZXJ0aWZpY2F0ZToKCiAgICAgIF80NDMuX3RjcC53d3cuYWxpY2UuZXhhbXBsZS4gSU4gVExT QSAoIDEgMiAyIC4uLi4uLiApCgogICBEQU5FLWNvbXBsaWFudCBjbGllbnRzIHdpbGwgb25seSBh Y2NlcHQgYSBjbGFpbSBvZiBpZGVudGl0eSBmcm9tIGEKICAgc2VydmVyIHB1cnBvcnRpbmcgdG8g YmUgd3d3LmFsaWNlLmV4YW1wbGUuIGlmIGl0cyBjZXJ0aWZpY2F0ZSBjaGFpbgogICBiZWdpbnMg d2l0aCB0aGUgc3BlY2lmaWVkIGVuZC1lbnRpdHkgY2VydGlmaWNhdGUuCgo2LjIuICBDQSBQaW5u aW5nCgogICBBbW9zIG9wZXJhdGVzIGEgbGFyZ2UgcG9vbCBvZiBIVFRQUyBzZXJ2ZXJzIGFueSBv ZiB3aGljaCBtYXkgYW5zd2VyCiAgIHJlcXVlc3RzIGZvciB3d3cuYW1vcy5leGFtcGxlLiAgRWFj aCBvZiB0aGVtIHVzZXMgYSBkaXN0aW5jdCBwdWJsaWMKICAga2V5LCBhbmQgdGhlcmVmb3JlIGhh cyBpdHMgb3duIGNlcnRpZmljYXRlLiAgQWxsIG9mIHRoZXNlIGFyZQogICBzaWduZWQgYnkgdGhl IHNhbWUgaW50ZXJtZWRpYXRlIGF1dGhvcml0eSBjZXJ0aWZpY2F0ZS4gIEFtb3MgaXMKICAgY29u ZmlkZW50IHRoYXQgbm8gYXR0YWNrZXIgd2lsbCBiZSBhYmxlIHRvIGFjcXVpcmUgaWxsZWdpdGlt YXRlCiAgIGNlcnRpZmljYXRlcyBmb3IgaGlzIGhvc3RuYW1lIGZyb20gX2hpc18gQ0EsIGJ1dCBp cyBub3QgY29uZmlkZW50CiAgIG9mIG90aGVyIENBcyB0byB0aGUgc2FtZSBleHRlbnQuICBBbW9z IGZyZXF1ZW50bHkgYWRkcyBuZXcgc2VydmVycwogICB0byBoaXMgcG9vbCwgYW5kIGRvZXMgbm90 IHdhbnQgdG8gaGF2ZSB0byB1cGRhdGUgaGlzIHpvbmUgZXZlcnkKICAgdGltZSB0aGlzIGhhcHBl bnMuCgogICBBbW9zIHB1Ymxpc2hlcyBhIFRMU0EgcmVjb3JkIHdpdGggc2VsZWN0b3IgY29kZSAy LCBzcGVjaWZ5aW5nIHRoZQogICBpbnRlcm1lZGlhdGUgYXV0aG9yaXR5IGNlcnRpZmljYXRlIHRo YXQgc2lnbnMgYWxsIG9mIGhpcyBzZXJ2ZXJzJwogICBjZXJ0aWZpY2F0ZXM6CgogICAgICBfNDQz Ll90Y3Aud3d3LmFtb3MuZXhhbXBsZS4gSU4gVExTQSAoIDIgMiAyIC4uLi4uLiApCgogICBEQU5F LWNvbXBsaWFudCBjbGllbnRzIHdpbGwgb25seSBhY2NlcHQgYSBjbGFpbSBvZiBpZGVudGl0eSBm cm9tIGEKICAgc2VydmVyIHB1cnBvcnRpbmcgdG8gYmUgd3d3LmFtb3MuZXhhbXBsZS4gaWYgaXRz IGNlcnRpZmljYXRlCiAgIGNoYWluIHBhc3NlcyB0aHJvdWdoIHRoZSBzcGVjaWZpZWQgYXV0aG9y aXR5IGNlcnRpZmljYXRlLgoKNi4zLiAgRGVsZWdhdGVkIEF1dGhvcml0eSBQaW5uaW5nCgogICBB bml0YSBvcGVyYXRlcyBhIHBvb2wgb2YgSFRUUFMgc2VydmVycyBzaW1pbGFyIHRvIEFtb3Mncywg YW5zd2VyaW5nCiAgIHJlcXVlc3RzIGZvciB3d3cuYW5pdGEuZXhhbXBsZS4gIFVubGlrZSBBbW9z LCBBbml0YSBpcyBfbm90XwogICBjb25maWRlbnQgdGhhdCBhdHRhY2tlcnMgd2lsbCBub3QgYmUg YWJsZSB0byBhY3F1aXJlIGlsbGVnaXRpbWF0ZQogICBjZXJ0aWZpY2F0ZXMgZm9yIGhlciBob3N0 bmFtZSBmcm9tIGhlciBDQSwgYnV0IHNoZSBoYXMgYWxsIHRoZSBzYW1lCiAgIG9wZXJhdGlvbmFs IGNvbnN0cmFpbnRzIHRoYXQgaGUgZG9lcy4KCiAgIEFuaXRhIHBlcnN1YWRlcyBoZXIgQ0EgdG8g aXNzdWUgaGVyIGEgX2RlbGVnYXRlZCBhdXRob3JpdHlfCiAgIGNlcnRpZmljYXRlLCBzaWduZWQg Ynkgb25lIG9mIHRoZWlyIGludGVybWVkaWF0ZXMsIGF1dGhvcml6ZWQgb25seQogICB0byBzaWdu IGNlcnRpZmljYXRlcyB0aGF0IGJpbmQga2V5cyB0byBob3N0bmFtZXMgZW5kaW5nIHdpdGgKICAg LmFuaXRhLmV4YW1wbGUuICAoUEtJWCBpbmNsdWRlcyBhIG1lY2hhbmlzbSB0byBlbmZvcmNlIHN1 Y2gKICAgcmVzdHJpY3Rpb25zLikgIEFuaXRhIHNpZ25zIGFsbCBoZXIgc2VydmVycycgY2VydGlm aWNhdGVzIHdpdGggdGhhdAogICBjZXJ0aWZpY2F0ZSwgYW5kIHB1Ymxpc2hlcyBhIFRMU0EgcmVj b3JkIHdpdGggc2VsZWN0b3IgY29kZSAyLAogICBzcGVjaWZ5aW5nIHRoYXQgY2VydGlmaWNhdGUg aW5zdGVhZCBvZiB0aGUgQ0EncyBpbnRlcm1lZGlhdGUKICAgYXV0aG9yaXR5LgoKICAgQWdhaW4s IERBTkUtY29tcGxpYW50IGNsaWVudHMgd2lsbCBvbmx5IGFjY2VwdCBhIGNsYWltIG9mIGlkZW50 aXR5CiAgIGZyb20gYSBzZXJ2ZXIgcHVycG9ydGluZyB0byBiZSB3d3cuYW5pdGEuZXhhbXBsZS4g aWYgaXRzCiAgIGNlcnRpZmljYXRlIGNoYWluIHBhc3NlcyB0aHJvdWdoIHRoZSBzcGVjaWZpZWQg YXV0aG9yaXR5CiAgIGNlcnRpZmljYXRlLiAgQmVjYXVzZSB0aGUgYXV0aG9yaXR5IGNlcnRpZmlj YXRlIGlzIGNvbnRyb2xsZWQgYnkKICAgQW5pdGEgcmF0aGVyIHRoYW4gaGVyIENBLCBzaGUgY2Fu IGJlIGNvbmZpZGVudCB0aGF0IGNsaWVudHMgd2lsbAogICByZWplY3QgaWxsZWdpdGltYXRlIGNl cnRpZmljYXRlcyBldmVuIGlmIHRoZXkgd2VyZSBzaWduZWQgYnkgaGVyIENBLgoKNi40LiAgVHJ1 c3QgUG9vbCBFeHBhbnNpb24KCiAgIEFwcmlsIG9wZXJhdGVzIGEgc2V0IG9mIEhUVFBTIHNlcnZl cnMgKGZvby5hcHJpbC5leGFtcGxlLiwKICAgYmFyLmFwcmlsLmV4YW1wbGUuLCBldGMuKSB0aGF0 IHdlcmUgb3JpZ2luYWxseSBpbnRlbmRlZCBmb3IgaW50ZXJuYWwKICAgdXNlIHdpdGhpbiBoZXIg b3JnYW5pemF0aW9uLCBidXQgYXJlIG5vdyBiZWluZyBtYWRlIGFjY2Vzc2libGUgdG8KICAgdGhl IHB1YmxpYy4gIFRoZWlyIGV4aXN0aW5nIHNlcnZlciBjZXJ0aWZpY2F0ZXMgYXJlIGFsbCBzaWdu ZWQgYnkgYQogICB0cnVzdCBhbmNob3IgY3JlYXRlZCBieSBoZXIgb3JnYW5pemF0aW9uJ3MgSVQg ZGVwYXJ0bWVudC4KICAgTWFuYWdlbWVudCB3aXNoZXMgdG8gY29udGludWUgdXNpbmcgdGhpcyBh bmNob3IgcmF0aGVyIHRoYW4gcmVseWluZwogICBvbiBhbnkgZXh0ZXJuYWwgQ0EgdG8gdm91Y2gg Zm9yIHRoZXNlIHNlcnZlcnMuCgogICBBcHJpbCBtYWtlcyBzdXJlIHRoYXQgYWxsIG9mIHRoZSBz ZXJ2ZXJzIGFyZSBjb25maWd1cmVkIHRvIGluY2x1ZGUKICAgdGhpcyBwcml2YXRlIHRydXN0IGFu Y2hvciBpbiB0aGUgY2hhaW4gdGhleSB0cmFuc21pdCAoc28gc2hlIGRvZXMKICAgbm90IGhhdmUg dG8gcHV0IHRoZSBjb21wbGV0ZSBjZXJ0aWZpY2F0ZSBpbiB0aGUgRE5TKSBhbmQgdGhlbgogICBw dWJsaXNoZXMgVExTQSByZWNvcmRzIHdpdGggc2VsZWN0b3IgY29kZSAzIGZvciBlYWNoOgoKICAg ICAgXzQ0My5fdGNwLmZvby5hcHJpbC5leGFtcGxlLiBJTiBUTFNBICggMyAyIDIgLi4uZm9vLi4u ICkKICAgICAgXzQ0My5fdGNwLmJhci5hcHJpbC5leGFtcGxlLiBJTiBUTFNBICggMyAyIDIgLi4u YmFyLi4uICkKICAgICAgLi4uIGV0YyAuLi4KCiAgIERBTkUtY29tcGxpYW50IGNsaWVudHMgd2ls bCBhY2NlcHQgYSBjbGFpbSBvZiBpZGVudGl0eSBmcm9tIGEKICAgc2VydmVyIHB1cnBvcnRpbmcg dG8gaGF2ZSBvbmUgb2YgdGhlc2UgbmFtZXMgaWYgYW5kIG9ubHkgaWYgaXRzCiAgIGNlcnRpZmlj YXRlIGNoYWluIGVuZHMgaW4gdGhlIHNwZWNpZmllZCB0cnVzdCBhbmNob3IsIGV2ZW4gdGhvdWdo CiAgIHRoZXkgZG8gbm90IGFscmVhZHkgY29uc2lkZXIgdGhpcyBwcml2YXRlIHRydXN0IGFuY2hv ciB0byBiZQogICByZWxpYWJsZS4KCjYuNS4gIFNlbGYtU2lnbmVkIENlcnRpZmljYXRlcwoKICAg QXJtYW5kLCBsaWtlIEFsaWNlLCBvcGVyYXRlcyBqdXN0IG9uZSBIVFRQUyBzZXJ2ZXIsIGJ1dCBo ZSBkb2VzIG5vdAogICBmZWVsIHRoYXQgX2FueV8gQ0EgaXMgcmVsaWFibGUgZW5vdWdoIHRvIGRv IGJ1c2luZXNzIHdpdGggYXQgYWxsLAogICBzbyBoZSB1c2VzIGEgc2VsZi1zaWduZWQgY2VydGlm aWNhdGUgYW5kIGluc3RydWN0cyBoaXMgdmlzaXRvcnMgdG8KICAgY2hlY2sgaXRzIGhhc2ggbWFu dWFsbHkuICBBcm1hbmQgY2FuIGF1dG9tYXRlIHRoaXMgcHJvY2VzcyBmb3IKICAgREFORS1jb21w bGlhbnQgY2xpZW50cyBieSBwdWJsaXNoaW5nIGEgVExTQSByZWNvcmQgd2l0aCBzZWxlY3Rvcgog ICBjb2RlIDM6CgogICAgICBfNDQzLl90Y3AuYXIubWFuZC5leGFtcGxlLiBJTiBUTFNBICggMyAy IDIgLi4uLi4uICkKCiAgIEEgc2VsZi1zaWduZWQgY2VydGlmaWNhdGUgaXMgc2ltdWx0YW5lb3Vz bHkgYSB0cnVzdCBhbmNob3IgYW5kIGFuCiAgIGVuZC1lbnRpdHkgY2VydGlmaWNhdGUsIHNvIERB TkUtY29tcGxpYW50IGNsaWVudHMgd2lsbCBhY2NlcHQgYQogICBjbGFpbSBvZiBpZGVudGl0eSBm cm9tIGEgc2VydmVyIHB1cnBvcnRpbmcgdG8gYmUgYXIubWFuZC5leGFtcGxlLgogICBpZiBhbmQg b25seSBpZiBpdCBwcmVzZW50cyB0aGUgc3BlY2lmaWVkIGNlcnRpZmljYXRlIGFzIHRoZSBzb2xl CiAgIGNlcnRpZmljYXRlIGluIGl0cyBjaGFpbiwgZXZlbiB0aG91Z2ggdGhleSBkbyBub3QgYWxy ZWFkeSBjb25zaWRlcgogICBpdCBhIHJlbGlhYmxlIHRydXN0IGFuY2hvci4KCjcuICBTZWN1cml0 eSBDb25zaWRlcmF0aW9ucwoKICAgVGhlIHNlY3VyaXR5IG9mIHRoZSBtZWNoYW5pc20gZGVzY3Jp YmVkIGluIHRoaXMgZG9jdW1lbnQKICAgZnVuZGFtZW50YWxseSByZWxpZXMgb24gdGhlIHNlY3Vy aXR5IG9mIEROU1NFQyBhcyB1c2VkIGJ5IHRoZQogICBjbGllbnQgcmVxdWVzdGluZyBhZGRyZXNz IGFuZCBUTFNBIHJlY29yZHMuICBBIGNsaWVudCB0aGF0IGhhcyBubwogICBhY2Nlc3MgdG8gRE5T U0VDIGluZm9ybWF0aW9uIGNhbm5vdCByZWx5IG9uIERBTkUgaW5mb3JtYXRpb24uCiAgIFNpbmNl IHNlbGVjdG9yIGNvZGVzIDEgYW5kIDIgZXhwcmVzcyBzdXBwbGVtZW50YWwgcmVzdHJpY3Rpb25z IGZvcgogICB0aGUgZXhpc3RpbmcgQ0Egc3lzdGVtLCBpdCBjb3VsZCBiZSBhcmd1ZWQgdGhhdCBE TlNTRUMgdmFsaWRhdGlvbgogICBpcyB1bm5lY2Vzc2FyeSBmb3IgdGhlc2UgY29kZXMuICBIb3dl dmVyLCB3ZSB3aXNoIHRvIHJ1bGUgb3V0IHRoZQogICBwb3NzaWJpbGl0eSB0aGF0IGFuIHVuc2ln bmVkIFRMU0EgcmVjb3JkIHdpdGggc2VsZWN0b3IgY29kZSAxIG9yIDIKICAgbWlnaHQgc29tZWhv dyBjYXVzZSBhbiBpbGxlZ2l0aW1hdGUgY2VydGlmaWNhdGUgdG8gYmUgYWNjZXB0ZWQKICAgKHBl cmhhcHMgaW4gY29uanVuY3Rpb24gd2l0aCBleG90aWMgY2VydGlmaWNhdGUgY29udGVudHMgYW5k L29yCiAgIGNsaWVudCBidWdzKS4gIEZ1cnRoZXJtb3JlLCB3ZSB0aGluayB0aGUgb3BlcmF0aW9u YWwgYW5kCiAgIGltcGxlbWVudGF0aW9uIHNpbXBsaWNpdHkgb2YgcmVxdWlyaW5nIGEgc2lnbmVk IHpvbmUgZm9yIGFsbCBUTFNBCiAgIHJlY29yZHMgb3V0d2VpZ2hzIHRoZSBhZGRlZCBjb252ZW5p ZW5jZSBmb3Igem9uZSBvcGVyYXRvcnMgb2YKICAgYWxsb3dpbmcgc29tZSBUTFNBIHJlY29yZHMg aW4gdW5zaWduZWQgem9uZXMsIGFuZCB3ZSB0aGluayB0aGUKICAgZGVzaWduZXJzIG9mIGZ1dHVy ZSBzZWxlY3RvciBjb2RlcyBhZGRlZCB2aWEgdGhlIElBTkEgcmVnaXN0cnkKICAgc2hvdWxkIG5v dCBoYXZlIHRvIHdvcnJ5IGFib3V0IHdoZXRoZXIgYSBzaWduZWQgem9uZSBpcyBzdHJpY3RseQog ICBuZWNlc3NhcnkuCgogICBBIHJvZ3VlIHBhcmVudCB6b25lIGNhbiByZXBsYWNlIHRoZSBjb250 ZW50cyBvZiBhIGRlbGVnYXRlZCB6b25lCiAgIHdpdGggbWF0ZXJpYWwgZW50aXJlbHkgdW5kZXIg aXRzIGNvbnRyb2wsIGV2ZW4gaWYgaXQgaGFzIG5vIGFjY2VzcwogICB0byB0aGUgbGVnaXRpbWF0 ZSBzaWduaW5nIGtleSBmb3IgdGhhdCB6b25lLiAgSXQgbWF5IGV2ZW4gYmUgYWJsZQogICB0byBk byBzbyBzZWxlY3RpdmVseSwgZGVwZW5kaW5nIG9uIHRoZSBzb3VyY2Ugb2YgdGhlIHF1ZXJ5LiAg U29tZQogICBvZiB0aGUgb3JnYW5pemF0aW9ucyB0aGF0IGFkbWluaXN0ZXIgZ2xvYmFsIHRvcC1s ZXZlbCBkb21haW5zIG1heQogICBub3QgYmUgYWJvdmUgdGhlIHRlbXB0YXRpb24gb2YgZG9pbmcg dGhpcyB0byBzdWJkb21haW5zIHRoZXkgZG9uJ3QKICAgbGlrZS4gIEZvciBpbnN0YW5jZSwgYSBz aXRlIHdob3NlIGRvbWFpbiBuYW1lIGVuZHMgd2l0aCBhIGNjVExEIGlzCiAgIGF0IHRoZSBtZXJj eSBvZiB0aGUgZ292ZXJubWVudCB3aXRoIHRoYXQgY291bnRyeSBjb2RlLCBldmVuIGlmIGl0CiAg IGlzIG90aGVyd2lzZSBvdXRzaWRlIHRoYXQgZ292ZXJubWVudCdzIGp1cmlzZGljdGlvbi4gIFRo aXMgaXMgbm90IGEKICAgbmV3IHByb2JsZW0gd2l0aCBEQU5FLCBob3dldmVyOyBpdCBpcyBmdW5k YW1lbnRhbCB0byB0aGUgZGVzaWduIG9mCiAgIHRoZSBETlMuCgogICBBIHJvZ3VlIEROUyBhZG1p bmlzdHJhdG9yIGZvciBhIHpvbmUgY2FuIGNoYW5nZSBib3RoIHRoZSBhZGRyZXNzCiAgIGFuZCBU TFNBIHJlY29yZHMgZm9yIGFueSBkb21haW4gbmFtZSBpbiB0aGF0IHpvbmUsIGFuZCBzbyByZWRp cmVjdAogICBjbGllbnQtdXNlcnMgdG8gYW4gdW5hdXRob3JpemVkIHNlcnZlciB0aGF0IHdpbGwg YXBwZWFyIGF1dGhvcml6ZWQuCiAgIFdpdGhvdXQgdGhlIFRMU0EgbWVjaGFuaXNtLCBhIHJvZ3Vl IEROUyBhZG1pbmlzdHJhdG9yIHdvdWxkIGhhdmUgdG8KICAgYWNxdWlyZSBhbiBpbGxlZ2l0aW1h dGUgY2VydGlmaWNhdGUgZm9yIHRoZSByZWRpcmVjdGVkIGRvbWFpbiBuYW1lCiAgIGFzIHdlbGwg YXMgcmVkaXJlY3RpbmcgdGhlIGFkZHJlc3MgcmVjb3JkczsgVExTQSdzIHNlbGVjdG9yIGNvZGUg MwogICBhbGxvd3MgdGhlbSB0byB1c2UgYSBjZXJ0aWZpY2F0ZSBub3Qgc2lnbmVkIGJ5IGFueSBD QSBpbnN0ZWFkLgogICBIb3dldmVyLCBhIEROUyBhZG1pbmlzdHJhdG9yIGlzIGFscmVhZHkgaW4g YSBwb3NpdGlvbiBvZiBncmVhdAogICBwcml2aWxlZ2Ugd2l0aGluIHRoZSBvcmdhbml6YXRpb24s IGFuZCBtYXkgd2VsbCBiZSBpbiBhIHBvc2l0aW9uIHRvCiAgIG9idGFpbiBpbGxlZ2l0aW1hdGUg Y2VydGlmaWNhdGVzIHdpdGhvdXQgdGhlIENBIGJlaW5nIGF3YXJlIHRoYXQKICAgYW55dGhpbmcg aXMgd3JvbmcuCgogICBJZiB0aGUgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtIGZvciBtb2RpZnlp bmcgVExTQSByZWNvcmRzIGluIGEKICAgem9uZSBpcyB3ZWFrZXIgdGhhbiB0aGUgYXV0aGVudGlj YXRpb24gbWVjaGFuaXNtIGZvciBtb2RpZnlpbmcKICAgYWRkcmVzcyByZWNvcmRzLCBhIG1hbi1p bi10aGUtbWlkZGxlIGF0dGFja2VyIHdobyB3b3VsZCBub3JtYWxseSBiZQogICBibG9ja2VkIGJ5 IFRMU0EgbWlnaHQgYmUgYWJsZSB0byBpbXBlcnNvbmF0ZSB0aGUgYXR0YWNrZWQgaG9zdCBieQog ICBleHBsb2l0aW5nIHRoZSB3ZWFrIGF1dGhlbnRpY2F0aW9uLiAgQWxsIEROUyBpbmZvcm1hdGlv biByZWxhdGluZwogICB0byBhIHBhcnRpY3VsYXIgaG9zdCBzaG91bGQgaGF2ZSB0aGUgc2FtZSBs ZXZlbCBvZiBhdXRoZW50aWNhdGlvbgogICByZXF1aXJlZC4KCiAgIEFueSBzb2Z0d2FyZSB0aGF0 IGhhcyBnb29kIHJlYXNvbiB0byBjb250aW51ZSBjb21tdW5pY2F0aW5nIHdpdGggYQogICBzZXJ2 ZXIgYWZ0ZXIgY29uY2x1ZGluZyB0aGF0IGl0cyBjZXJ0aWZpY2F0ZSBjaGFpbiBpcyAiYm9ndXMi CiAgIChzdWNoIGFzIGEgZm9yZW5zaWNzIHRvb2wpIG11c3QgYXNzdW1lIHRoYXQgYWxsIGRhdGEg aXQgcmVjZWl2ZXMgaXMKICAgbWFsaWNpb3VzLCBhbmQgc2hvdWxkIHRoZXJlZm9yZSB0YWtlIGV4 dHJhb3JkaW5hcnkgY2FyZSBpbiBpdHMKICAgcHJvY2Vzc2luZy4gIEZvciBpbnN0YW5jZSwgc2Ny aXB0cyBhbmQgb3RoZXIgYWN0aXZlIGNvbnRlbnQgc2hvdWxkCiAgIG5vdCBiZSBleGVjdXRlZCwg Y3JlZGVudGlhbHMgb2YgYW55IGtpbmQgc2hvdWxkIG5vdCBiZSB0cmFuc21pdHRlZCwKICAgYW5k IG5vdGhpbmcgaW4gdGhlIGRhdGEgcmVjZWl2ZWQgc2hvdWxkIGJlIGFsbG93ZWQgdG8gdHJpZ2dl cgogICBmdXJ0aGVyIG5ldHdvcmsgcmVxdWVzdHMgd2l0aG91dCBleHBsaWNpdCB1c2VyIGluc3Ry dWN0aW9ucyAobm90CiAgIGV2ZW4gYXBwYXJlbnRseS1oYXJtbGVzcyByZXF1ZXN0cywgc3VjaCBh cyBmb3IgaW1hZ2VzIHRvIGJlCiAgIGRpc3BsYXllZCBpbiBhIHJlbmRlcmVkIEhUTUwgZG9jdW1l bnQpLgoKICAgW1sgQ2xpZW50IHRyZWF0bWVudCBvZiBhbnkgaW5mb3JtYXRpb24gaW5jbHVkZWQg aW4gdGhlIHRydXN0IGFuY2hvcgogICBpcyBhIG1hdHRlciBvZiBsb2NhbCBwb2xpY3kuICBUaGlz IHNwZWNpZmljYXRpb24gZG9lcyBub3QgbWFuZGF0ZQogICB0aGF0IHN1Y2ggaW5mb3JtYXRpb24g YmUgaW5zcGVjdGVkIG9yIHZhbGlkYXRlZCBieSB0aGUgZG9tYWluIG5hbWUKICAgYWRtaW5pc3Ry YXRvci4gfHwgenc6IEkgYW0gaW5jbGluZWQgdG8gY3V0IHRoaXMgcGFyYWdyYXBoLCB3aGljaAog ICBjb21tdW5pY2F0ZXMgbm90aGluZyB0byBtZS4gIFdoaWNoIGluZm9ybWF0aW9uIGlzIHRoaXMg YW5kIHdoeSBpcwogICBpdCByZWxldmFudD8gXV0KCjguICBPcGVyYXRpb25hbCBDb25zaWRlcmF0 aW9ucwoKICAgVGhpcyBzZWN0aW9uIGlzIG5vdCBub3JtYXRpdmUuICBJdCBkaXNjdXNzZXMgaXNz dWVzIHRoYXQgbWF5IGJlCiAgIHJlbGV2YW50IHRvIHNpdGUgYWRtaW5pc3RyYXRvcnMgd2hvIHdp c2ggdG8gZGVwbG95IFRMU0EgcmVjb3Jkcywgb3IKICAgY2xpZW50cyB0aGF0IG1ha2UgdXNlIG9m IHRoZW0uCgo4LjEuICBBbGlhc2VzCgogICBETlMgcHJvdmlkZXMgc2V2ZXJhbCBkaWZmZXJlbnQg d2F5cyBvZiBtYWtpbmcgbmFtZXMgZXF1aXZhbGVudCB0bwogICBhbm90aGVyIChmb3IgZGlmZmVy ZW50IGRlZmluaXRpb25zIG9mICJlcXVpdmFsZW50IiBhbmQgIm5hbWUiKS4KICAgQWxsIG9mIHRo ZXNlIG1lY2hhbmlzbXMgYXJlIHRyYW5zcGFyZW50IHRvIEROUyBjbGllbnRzLCB3aGljaAogICBz aW1wbHkgcmVxdWVzdCB0aGUgcmVjb3JkcyB0aGV5IHdhbnQgYXQgdGhlIG5hbWUgdGhleSBleHBl Y3QuCiAgIChETlMgX3Jlc29sdmVyc18gbXVzdCBvZiBjb3Vyc2UgYmUgYXdhcmUgb2YgdGhlIHVu ZGVybHlpbmcKICAgbWVjaGFuaXNtcyB0byBzb21lIGRlZ3JlZS4pCgogICBUaGUgaW50ZXJhY3Rp b24gb2YgdGhlc2UgYWxpYXNpbmcgbWVjaGFuaXNtcyB3aXRoIFJScyB0aGF0IGFyZQogICBwbGFj ZWQgYXQgcHJlZml4ZWQgaG9zdG5hbWVzIChTUlYsIGZvciBpbnN0YW5jZSwgYW5kIG5vdyBUTFNB KSBpcwogICB3ZWxsLWRlZmluZWQgYW5kIHByZWRpY3RhYmxlIGJ1dCBjYW4gYmUgc3VycHJpc2lu ZyB0byBwZW9wbGUKICAgdW5mYW1pbGlhciB3aXRoIHRoZSBleGFjdCBzZW1hbnRpY3Mgb2YgRE5T IGFsaWFzaW5nLgoKICAgW1sgU2hvdWxkIHdlIG1lbnRpb24gdGhlIHByb3Bvc2VkIEJOQU1FIHJl Y29yZD8gXV0KCjguMS4xLiAgQ05BTUUgUmVjb3JkcwoKICAgQ05BTUUgYWxpYXNlcyBhIG5hbWUs IGJ1dCBub3QgYW55IHN1YmRvbWFpbnMgb2YgdGhhdCBuYW1lLgogICBGb3IgZXhhbXBsZSwgaWYg YSB6b25lIGZpbGUgaGFzIHRoZXNlIHJlY29yZHM6CgogICAgICBhbHBoYS5leGFtcGxlLiAgICAg ICAgICAgICAgIElOIENOQU1FIGJldGEuZXhhbXBsZS4KCiAgICAgIGJldGEuZXhhbXBsZS4gICAg ICAgICAgICAgICAgICAgQSAgICAgMTkyLjAuMi4xCiAgICAgIF80NDMuX3RjcC5iZXRhLmV4YW1w bGUuICAgICAgICAgVExTQSAgKCBzIGMgaSAuLi4uLi4gKQoKICAgYW4gYXBwbGljYXRpb24gdGhh dCBxdWVyaWVzIGZvciBUTFNBIHJlY29yZHMgYXQKICAgXzQ0My5fdGNwLmFscGhhLmV4YW1wbGUu IHdpbGwgZ2V0IGFuIGVtcHR5IHJlcGx5LiAgSWYgdGhlIFRMU0EKICAgcmVjb3JkIGlzIG1lYW50 IHRvIGFwcGx5IHRvIGJvdGggbmFtZXMgZm9yIHRoZSBob3N0IGF0IDE5Mi4wLjIuMSwKICAgdGhl cmUgbXVzdCBiZSBhIENOQU1FIGZvciB0aGUgcHJlZml4ZWQgbmFtZSBhcyB3ZWxsOgoKICAgICAg YWxwaGEuZXhhbXBsZS4gICAgICAgICAgICAgICBJTiBDTkFNRSBiZXRhLmV4YW1wbGUuCiAgICAg IF80NDMuX3RjcC5hbHBoYS5leGFtcGxlLiAgICAgICAgQ05BTUUgXzQ0My5fdGNwLmJldGEuZXhh bXBsZS4KCiAgICAgIGJldGEuZXhhbXBsZS4gICAgICAgICAgICAgICAgICAgQSAgICAgMTkyLjAu Mi4xCiAgICAgIF80NDMuX3RjcC5iZXRhLmV4YW1wbGUuICAgICAgICAgVExTQSAgKCBzIGMgaSAu Li4uLi4gKQoKICAgSWYgdGhlIHNlcnZlciB1c2VzIGRpZmZlcmVudCBjZXJ0aWZpY2F0ZXMgd2hl biBhZGRyZXNzZWQgYnkKICAgZGlmZmVyZW50IGhvc3RuYW1lcyAodmlhIFNOSSBbUkZDNjA2Nl0p LCB0aGVuIGl0IHdvdWxkIGluc3RlYWQgYmUKICAgYXBwcm9wcmlhdGUgdG8gaGF2ZSBzZXBhcmF0 ZSBUTFNBIHJlY29yZHMgZm9yIHRoZSB0d28gbmFtZXM6CgogICAgICBhbHBoYS5leGFtcGxlLiAg ICAgICAgICAgICAgIElOIENOQU1FIGJldGEuZXhhbXBsZS4KICAgICAgXzQ0My5fdGNwLmFscGhh LmV4YW1wbGUuICAgICAgICBUTFNBICAoIHMgYyBpIC4uLmFscGhhLi4uICkKCiAgICAgIGJldGEu ZXhhbXBsZS4gICAgICAgICAgICAgICAgICAgQSAgICAgMTkyLjAuMi4xCiAgICAgIF80NDMuX3Rj cC5iZXRhLmV4YW1wbGUuICAgICAgICAgVExTQSAgKCBzIGMgaSAuLi5iZXRhLi4uICkKCjguMS4y LiAgRE5BTUUgUmVjb3JkcwoKICAgRE5BTUUgYWxpYXNlcyBhbGwgc3ViZG9tYWlucyBvZiBhIG5h bWUsIGJ1dCBub3QgdGhlIG5hbWUgaXRzZWxmLgogICBGb3IgZXhhbXBsZSwgaWYgYSB6b25lIGhh cyB0aGVzZSByZWNvcmRzOgoKICAgICAgYWxwaGEuZXhhbXBsZS4gICAgICAgICAgICAgICBJTiBE TkFNRSBiZXRhLmV4YW1wbGUuCgogICAgICBiZXRhLmV4YW1wbGUuICAgICAgICAgICAgICAgICAg IEEgICAgIDE5Mi4wLjIuMQogICAgICBfNDQzLl90Y3AuYmV0YS5leGFtcGxlLiAgICAgICAgIFRM U0EgICggcyBjIGkgLi4uLi4uICkKCiAgIGFuIGFwcGxpY2F0aW9uIHRoYXQgcXVlcmllcyBmb3Ig VExTQSByZWNvcmRzIGF0CiAgIF80NDMuX3RjcC5hbHBoYS5leGFtcGxlLiB3aWxsIGdldCB0aGUg cmVjb3JkIHRoYXQgd2FzIHN0b3JlZCBhdAogICBfNDQzLl90Y3AuYmV0YS5leGFtcGxlLiAtLSBi dXQgcXVlcnlpbmcgZm9yIGFuIEEgcmVjb3JkIGF0CiAgIGFscGhhLmV4YW1wbGUuIHdpbGwgcmV0 dXJuIG5vdGhpbmchICBUbyBtYWtlIGFscGhhLmV4YW1wbGUuIGZ1bGx5CiAgIGVxdWl2YWxlbnQg dG8gYmV0YS5leGFtcGxlLiwgYSBDTkFNRSByZWNvcmQgaXMgYWxzbyByZXF1aXJlZDoKCiAgICAg IGFscGhhLmV4YW1wbGUuICAgICAgICAgICAgICAgSU4gQ05BTUUgYmV0YS5leGFtcGxlLgogICAg ICBhbHBoYS5leGFtcGxlLiAgICAgICAgICAgICAgICAgIEROQU1FIGJldGEuZXhhbXBsZS4KCiAg ICAgIGJldGEuZXhhbXBsZS4gICAgICAgICAgICAgICAgICAgQSAgICAgMTkyLjAuMi4xCiAgICAg IF80NDMuX3RjcC5iZXRhLmV4YW1wbGUuICAgICAgICAgVExTQSAgKCBzIGMgaSAuLi4uLi4gKQoK ICAgVGhpcyBzZXR1cCB3b3VsZCBiZSBhcHByb3ByaWF0ZSBpZiB0aGUgaG9zdCBhdCAxOTIuMC4y LjEgcHJvdmlkZXMKICAgc2V2ZXJhbCBUTFMtcHJvdGVjdGVkIHNlcnZpY2VzIHVuZGVyIGJvdGgg bmFtZXM7IHdpdGhvdXQgRE5BTUUgb25lCiAgIHdvdWxkIGhhdmUgdG8gd3JpdGUgb3V0IENOQU1F cyBmb3IgZXZlcnkgVExTQSByZWNvcmQuICBBZ2FpbiwgaWYKICAgU05JIGlzIGluIHVzZSwgaXQg bWF5IGJlIG1vcmUgYXBwcm9wcmlhdGUgdG8gdXNlIGFuIGluZGVwZW5kZW50IHNldAogICBvZiBU TFNBIHJlY29yZHMgdW5kZXIgYWxwaGEuZXhhbXBsZS4gcmF0aGVyIHRoYW4gdGhlIEROQU1FLgoK OC4xLjMuICBXaWxkY2FyZHMKCiAgIFdpbGRjYXJkcyBhcmUgZ2VuZXJhbGx5IG5vdCB0ZXJyaWJs eSB1c2VmdWwgZm9yIFJSdHlwZXMgdGhhdAogICByZXF1aXJlIHByZWZpeGluZywgYmVjYXVzZSB0 aGV5IGNhbiBvbmx5IGJlIGFwcGxpZWQgdG8gdGhlIGxlZnRtb3N0CiAgIGxhYmVsIGluIGEgZG9t YWluIG5hbWUuICBGb3IgZXhhbXBsZSwgdGhpcyByZWNvcmQgYXBwbGllcyB0aGUgc2FtZQogICBU TFNBIHJlY29yZCB0byBldmVyeSBUQ1AgcG9ydCBhdCBmb28uZXhhbXBsZS4sIHdoaWNoIG1pZ2h0 IGJlCiAgIHVzZWZ1bCBpZiB0aGUgc2FtZSBzZXJ2aWNlIGlzIG9mZmVyZWQgYXQgbWFueSBwb3J0 czoKCiAgICAgICouX3RjcC5mb28uZXhhbXBsZS4gICAgICAgICAgSU4gVExTQSAoIHMgYyBpIC4u Li4uLiApCgogICBIb3dldmVyLCB0aGlzIHJlY29yZCBkb2VzIG5vdGhpbmcgdXNlZnVsOgoKICAg ICAgXzQ0My5fdGNwLiouYmFyLmV4YW1wbGUuICAgICBJTiBUTFNBICggcyBjIGkgLi4uLi4uICkK CjguMi4gIE5TIFJlY29yZHMKCiAgIFtbIFRoaXMgd2FzIHByb3Bvc2VkLCBhbmQgcXVlc3Rpb25l ZCwgYW5kIG5vdCB5ZXQgZm9sbG93ZWQgdGhyb3VnaAogICBvbi4gfHwgenc6IElzIHRoaXMgYW5v dGhlciBhbGlhc2luZyBtZWNoYW5pc20/ICBJZiBzbywgaXQgc2hvdWxkIGJlCiAgIDguMS40IGlu c3RlYWQgb2YgOC4yLiBdXQoKOC4zLiAgQ2VydGlmaWNhdGUgUm9sbG92ZXIKCiAgIFtbIE5lZWQg dG8gYWRkIHRleHQgaGVyZSBhYm91dCBob3cgdG8gaGFuZGxlIGEgY2hhbmdlIGluIGNlcnRpZmlj YXRlLgogICBJdCB3b3VsZCBjb3ZlciB1c2luZyB0d28gVExTQSByZWNvcmRzIGF0IHRoZSBzYW1l IHRpbWUsIHRoZSBUVEwgb24KICAgdGhlIFJSc2V0LCBhbmQgY29vcmRpbmF0aW5nIHRoYXQgd2l0 aCB0aGUgdXNlIG9mIHRoZSBjZXJ0aWZpY2F0ZXMgaW4KICAgdGhlIFRMUyBzZXJ2ZXIuIF1dCgo4 LjQuICBQcm94aWVzCgogICBTb21lICJ0cmFuc3BhcmVudCBwcm94eSIgc2VydmVycyBhY3QgYXMg bWVuLWluLXRoZS1taWRkbGUgZm9yIFRMUwogICBjbGllbnRzLiAgVGhlIGNsaWVudCBpcyBjb25m aWd1cmVkIHRvIGFjY2VwdCBhIHRydXN0IGFuY2hvciB3aG9zZQogICBwcml2YXRlIGtleSBpcyBr ZXB0IG9uIHRoZSBwcm94eSBzZXJ2ZXI7IHRoZSBwcm94eSBzZXJ2ZXIKICAgaW50ZXJjZXB0cyBU TFMgcmVxdWVzdHMsIGJlZ2lucyBpdHMgb3duIFRMUyBzZXNzaW9uIHdpdGggdGhlCiAgIGludGVu ZGVkIGhvc3QsIGFuZCB1c2VzIHRoZSB0cnVzdCBhbmNob3IgaXQgY29udHJvbHMgdG8gZmFicmlj YXRlCiAgIGFuIGFjY2VwdGFibGUgY2VydGlmaWNhdGUgZm9yIHRoZSBzZXNzaW9uIHdpdGggdGhl IGNsaWVudC4gIFRoaXMKICAgYWxsb3dzIHRoZSBwcm94eSB0byBkZWNyeXB0LCBpbnNwZWN0LCBh bmQgcmUtZW5jcnlwdCB0cmFmZmljCiAgIGludmlzaWJseSB0byB0aGUgY2xpZW50LiAgVGhpcyB0 ZWNobmlxdWUgaXMgaW5jb21wYXRpYmxlIHdpdGggREFORTsKICAgdGhlIFRMUyBjbGllbnQgd2ls bCBiZSBub3RpZmllZCBvZiB0aGUgcHJvcGVyIGNlcnRpZmljYXRlIGNoYWluIGZvcgogICB0aGUg aW50ZW5kZWQgaG9zdCB2aWEgVExTQSByZWNvcmRzIGFuZCB3aWxsIHJlamVjdCB0aGUgcHJveHkn cwogICBjbGFpbSBvZiBpZGVudGl0eS4gIEVudmlyb25tZW50cyB0aGF0IHVzZSBzdWNoIHByb3hp ZXMgdG8gYQogICBsZWdpdGltYXRlIGVuZCBzaG91bGQgZGVwbG95IGV4cGxpY2l0IGFwcGxpY2F0 aW9uLWxheWVyIHByb3hpZXMKICAgaW5zdGVhZC4KCjkuICBJQU5BIENvbnNpZGVyYXRpb25zCgo5 LjEuICBUTFNBIFJSdHlwZQoKICAgVGhpcyBkb2N1bWVudCB1c2VzIGEgbmV3IEROUyBSUiB0eXBl LCBUTFNBLCB3aG9zZSB2YWx1ZSBpcyBUQkQuICBBCiAgIHNlcGFyYXRlIHJlcXVlc3QgZm9yIHRo ZSBSUiB0eXBlIHdpbGwgYmUgc3VibWl0dGVkIHRvIHRoZSBleHBlcnQKICAgcmV2aWV3ZXIsIGFu ZCBmdXR1cmUgdmVyc2lvbnMgb2YgdGhpcyBkb2N1bWVudCB3aWxsIGhhdmUgdGhhdCB2YWx1ZQog ICBpbnN0ZWFkIG9mIFRCRC4KCjkuMi4gIFRMU0EgU2VsZWN0b3JzCgogICBUaGlzIGRvY3VtZW50 IGNyZWF0ZXMgYSBuZXcgcmVnaXN0cnksICJTZWxlY3RvciBDb2RlcyBmb3IgVExTQQogICBSZXNv dXJjZSBSZWNvcmRzIi4gIFRoZSByZWdpc3RyeSBwb2xpY3kgaXMgIlJGQyBSZXF1aXJlZCIuICBU aGUKICAgaW5pdGlhbCBlbnRyaWVzIGluIHRoZSByZWdpc3RyeSBhcmU6CgogICBWYWx1ZSAgICBT aG9ydCBkZXNjcmlwdGlvbiAgICAgICAgICAgICAgICAgICAgICAgUmVmZXJlbmNlCiAgIC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KICAg MCAgICAgICAgUmVzZXJ2ZWQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtUaGlzXQog ICAxICAgICAgICBNYXRjaCBlbmQtZW50aXR5IGNlcnQgICAgICAgICAgICAgICAgICAgW1RoaXNd CiAgIDIgICAgICAgIE1hdGNoIGludGVybWVkaWF0ZSBvciBhbmNob3IgY2VydCAgICAgICBbVGhp c10KICAgMyAgICAgICAgTWF0Y2ggYW5jaG9yIGNlcnQsIGFkZCB0byB3aGl0ZWxpc3QgICAgIFtU aGlzXQogICA0LTI1NCAgICBVbmFzc2lnbmVkCiAgIDI1NSAgICAgIFByaXZhdGUgdXNlCgogICBB cHBsaWNhdGlvbnMgdG8gdGhlIHJlZ2lzdHJ5IGNhbiByZXF1ZXN0IHNwZWNpZmljIHZhbHVlcyB0 aGF0IGhhdmUKICAgeWV0IHRvIGJlIGFzc2lnbmVkLgoKOS4zLiAgVExTQSBDZXJ0aWZpY2F0ZSBG b3JtYXRzCgogICBUaGlzIGRvY3VtZW50IGNyZWF0ZXMgYSBuZXcgcmVnaXN0cnksICJDZXJ0aWZp Y2F0ZSBGb3JtYXQgQ29kZXMgZm9yCiAgIFRMU0EgUmVzb3VyY2UgUmVjb3JkcyIuICBUaGUgcmVn aXN0cnkgcG9saWN5IGlzICJTcGVjaWZpY2F0aW9uCiAgIFJlcXVpcmVkIi4gIFRoZSBpbml0aWFs IGVudHJpZXMgaW4gdGhlIHJlZ2lzdHJ5IGFyZToKCiAgIFZhbHVlICAgIFNob3J0IGRlc2NyaXB0 aW9uICAgICAgICAgICAgICAgICAgICAgICBSZWZlcmVuY2UKICAgLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQogICAwICAgICAgICBSZXNl cnZlZCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1RoaXNdCiAgIDEgICAgICAgIENl cnRpZmljYXRlIGJsb2NrICAgICAgICAgICAgICAgICAgICAgICBbVGhpc10KICAgMiAgICAgICAg U3ViamVjdFB1YmxpY0tleUluZm8gYmxvY2sgICAgICAgICAgICAgIFtUaGlzXQogICAzLTI1NCAg ICBVbmFzc2lnbmVkCiAgIDI1NSAgICAgIFByaXZhdGUgdXNlCgogICBBcHBsaWNhdGlvbnMgdG8g dGhlIHJlZ2lzdHJ5IGNhbiByZXF1ZXN0IHNwZWNpZmljIHZhbHVlcyB0aGF0IGhhdmUKICAgeWV0 IHRvIGJlIGFzc2lnbmVkLgoKOS40LiAgVExTQSBJZGVudGlmaWVyIEZvcm1hdHMKCiAgIFRoaXMg ZG9jdW1lbnQgY3JlYXRlcyBhIG5ldyByZWdpc3RyeSwgIklkZW50aWZpZXIgRm9ybWF0IENvZGVz IGZvcgogICBUTFNBIFJlc291cmNlIFJlY29yZHMiLiAgVGhlIHJlZ2lzdHJ5IHBvbGljeSBpcyAi U3BlY2lmaWNhdGlvbgogICBSZXF1aXJlZCIuICBUaGUgaW5pdGlhbCBlbnRyaWVzIGluIHRoZSBy ZWdpc3RyeSBhcmU6CgogICBWYWx1ZSAgICBTaG9ydCBkZXNjcmlwdGlvbiAgICBSZWZlcmVuY2UK ICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCiAgIDAgICAg ICAgIFJlc2VydmVkICAgICAgICAgICAgIFtUaGlzXQogICAxICAgICAgICBObyBoYXNoIHVzZWQg ICAgICAgICBbVGhpc10KICAgMiAgICAgICAgU0hBLTI1NiAgICAgICAgICAgICAgTklTVCBGSVBT IDE4MC0zCiAgIDMgICAgICAgIFNIQS01MTIgICAgICAgICAgICAgIE5JU1QgRklQUyAxODAtMwog ICA0LTI1NCAgICBVbmFzc2lnbmVkCiAgIDI1NSAgICAgIFByaXZhdGUgdXNlCgogICBBcHBsaWNh dGlvbnMgdG8gdGhlIHJlZ2lzdHJ5IGNhbiByZXF1ZXN0IHNwZWNpZmljIHZhbHVlcyB0aGF0IGhh dmUKICAgeWV0IHRvIGJlIGFzc2lnbmVkLgo= --f46d044473c32a9c1a04b0f52796-- From henry.story@bblfish.net Sat Nov 5 16:56: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 7C2BC21F84AB for ; Sat, 5 Nov 2011 16:56:33 -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 lY0sXGYGnqm1 for ; Sat, 5 Nov 2011 16:56:32 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2BB21F84AA for ; Sat, 5 Nov 2011 16:56:32 -0700 (PDT) Received: by wwf22 with SMTP id 22so3564487wwf.1 for ; Sat, 05 Nov 2011 16:56:31 -0700 (PDT) Received: by 10.216.131.85 with SMTP id l63mr2376122wei.1.1320537389752; Sat, 05 Nov 2011 16:56:29 -0700 (PDT) Received: from bblfish.home (AAubervilliers-651-1-244-93.w83-200.abo.wanadoo.fr. [83.200.75.93]) by mx.google.com with ESMTPS id eu16sm21876626wbb.7.2011.11.05.16.56.29 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 05 Nov 2011 16:56:29 -0700 (PDT) From: Henry Story Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 6 Nov 2011 00:56:28 +0100 Message-Id: <59053E03-56A8-43F8-86A3-D5C843CC3283@bblfish.net> To: "dane@ietf.org WG list" , WebID XG Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: [dane] Another use case for DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 05 Nov 2011 23:56:33 -0000 Hi, Inspired by the innovative thinking animating the BrowserId = authentication protocol [1], and seeing the logic developed there could = also be also applied to WebID over TLS [2], it occurred to me that one = could use keys published in DANE to prove that a client certificate had = been signed by a specific service - e.g., an https or an e-mail service. The BrowserId folk have not specified exactly how they wish to show = that their JSON certificates were signed by a specific e-mail provider, = and it seems this role could very reasonably fall to DNSsec. If it can = be done for BrowserId, then of course there is no reason why X509 client = certificates could not also be signed with such keys, where the Issuer = Alternative Name in the X509 certificate would be either an e-mail or an = https service. This would then allow Relying Parties to authenticate a = WebID in an X509 Certificate immediately without needing to dereference = the WebID itself - an issue that could speed up initial authentication = of X509 certificates coming from very large service providers - or even = allow certificates to be verified without them containing a WebID, as = the BrowserID folks seem to prefer.=20 There is also the advantage that if the signature is from the e-mail = providing service, then this could be used immediately to verify an = e-mail address in the Subject Alternative Name, just as it would help = prove an https WebID if the key were shown by DNSSEC to be the one used = to sign https services. This can clearly complement simple WebID authentication as we know it = now from http://webid.info/spec/ . WebID does have the advantage of = being able to return very rich and up to date graphs of information = about the user. Henry Story PS this is part of the WebID ISSUE-5: "Follow Work in publishing keys in = DNSSEC - DANE" [1] https://browserid.org/=20 though it still requires the work of the future Browser Cryptography = group to come to fruition = http://www.w3.org/wiki/IdentityCharter#Web_Cryptography_Working_Group_Char= ter if it is going to be truly decentralised [2] I wrote up a detailed comparison of WebID and BrowserID = http://security.stackexchange.com/questions/5406/what-are-the-main-advanta= ges-and-disadvantages-of-webid-compared-to-browserid Social Web Architect http://bblfish.net/ From rbarnes@bbn.com Sun Nov 6 19:18: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 C8C5421F86AA for ; Sun, 6 Nov 2011 19:18:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NcPmLzx7RrlQ for ; Sun, 6 Nov 2011 19:18:51 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 3C06E21F86A4 for ; Sun, 6 Nov 2011 19:18:51 -0800 (PST) Received: from [128.89.255.27] (port=62610) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RNFjU-000KGO-R2; Sun, 06 Nov 2011 22:18:48 -0500 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Richard Barnes In-Reply-To: Date: Sun, 6 Nov 2011 22:18:48 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Zack Weinberg X-Mailer: Apple Mail (2.1251.1) Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] DANE protocol spec complete rewrite X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 03:18:51 -0000 I have reviewed this document, and would not recommend that it serve as = the basis for further working group documents. It is much less clearly = written than the current document, in large part due to sloppy use of = terminology. =20 That said, there are some useful things in here. This document makes = the algorithm for evaluating a certificate in the context of TLSA = records much more explicit, and the usage examples could be helpful to = people. Rather than submitting a bunch of changes all at once like this, it = would be much more helpful to work with the editors on the specific = changes you think need to be made. For instance, I would support = efforts to make the processing/decision algorithm more explicit and to = incorporate some usage examples. --Richard On Nov 5, 2011, at 5:21 AM, Zack Weinberg wrote: > With the WG face-to-face meeting next Monday (alas, I cannot attend), > now seemed like a good time to finish and post that complete spec > rewrite that I've been threatening to do for months :) Despite the > radical changes to the document, it is not my intention to take over > the editor's hat from the present team, merely to offer improvements. >=20 > I have tried not to make any normative changes, except where draft 12 > was ambiguous. One notable exception to that is the code numbers in > the RR, which have been rationalized. Where I consciously made > normative changes, I indicated them with [[comments in double square > brackets]]; these also indicate spots where there are remaining > ambiguities or omissions that I either don't know enough about to > produce text, or do not feel it is appropriate for me to resolve > unilaterally. All open issues except #10, #35, and #38 are at least > mentioned in these annotations, and most of them have suggested > resolutions. >=20 > Editorially, however, I have changed everything from the terminology > on up. My principal goal was clarity, particularly relating to how > the client is supposed to behave. To that end, I have replaced the > non-normative pseudocode Appendix B with a normative section 3 that > states a prose algorithm which clients must match in results, although > not in implementation. Given the well-known ambiguities and > controversies surrounding the interpretation of PKIX, I have also > removed as many dependencies on that spec as possible, even in > terminology. Appendix A has been cut down a bit and moved into the > main body of the document. Finally, I added some items to the various > "considerations" sections on my own motion, and a new "usage > scenarios" section. >=20 > Since I have not been able to find the (presumed) xml2rfc source of > draft 12 anywhere, I did not preserve all of the formatting > (particularly not the page headers and footers), the IESG boilerplate, > or the bibliography. If the present editors of the document are > willing to provide me with the source, I will happily do the legwork > to finish out the draft. >=20 > zw > = ______________________________________= _________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From zack.weinberg@gmail.com Sun Nov 6 20:10: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 4910021F8442 for ; Sun, 6 Nov 2011 20:10:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=0.300, 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 9Edppawgn+2P for ; Sun, 6 Nov 2011 20:10:29 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id C046521F8441 for ; Sun, 6 Nov 2011 20:10:29 -0800 (PST) Received: by gye5 with SMTP id 5so5667634gye.31 for ; Sun, 06 Nov 2011 20:10:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=DKx1UxALN6U2tCURZkL6LOiPOdg9mvALZ+Ln96SvV+o=; b=gi4W4gJ9v6jRSFuHk1hb6uxk7PAQUllhYG8w14UO13quXhShtq2Fn6fQWX27lBttVN Db3F6Q4ZPsv4QbFfdER65Wa1WzaLUBpbwSLVcKPBJp7r03pB9p6I2smQWz1P9tMYAxK7 z1NUg/Af96xXeTz7oM6GL3edLOFMKtiNQVaeA= MIME-Version: 1.0 Received: by 10.182.164.74 with SMTP id yo10mr6662819obb.69.1320639029280; Sun, 06 Nov 2011 20:10:29 -0800 (PST) Sender: zack.weinberg@gmail.com Received: by 10.182.88.103 with HTTP; Sun, 6 Nov 2011 20:10:29 -0800 (PST) In-Reply-To: References: Date: Sun, 6 Nov 2011 20:10:29 -0800 X-Google-Sender-Auth: -KTL2IRaVN_CVWFxPdsIoSJXJgk Message-ID: From: Zack Weinberg To: Richard Barnes , IETF DANE WG list Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [dane] DANE protocol spec complete rewrite X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 04:10:30 -0000 On Sun, Nov 6, 2011 at 7:18 PM, Richard Barnes wrote: > I have reviewed this document, and would not recommend that it serve as t= he basis for further working group documents. =C2=A0It is much less clearly= written than the current document, in large part due to sloppy use of term= inology. A primary goal of the rewrite was to make the terminology much more precise than the present draft; therefore, I would appreciate an explanation of exactly what you find to be "sloppier" than the status quo. Note that I deliberately avoided terminology which people *think* has a precise meaning, but that meaning is contested among two or more usage groups, so it's not actually unambiguous; instead I used terminology that I made up, so that it would mean exactly what I wanted it to mean. Perhaps that is what you do not like? Unfortunately, under the circumstances, I don't think we have a choice. > Rather than submitting a bunch of changes all at once like this, it would= be much more helpful to work with the editors on the specific changes you = think need to be made. =C2=A0For instance, I would support efforts to make = the processing/decision algorithm more explicit and to incorporate some usa= ge examples. I do not think it is practical to make some of the changes that I want made without a wholesale rewrite, and this particularly goes for terminology. I cannot support the present draft's terminology; it is asking for incompatible implementations. zw From trac+dane@trac.tools.ietf.org Tue Nov 8 02: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 70DF521F84D2 for ; Tue, 8 Nov 2011 02:38:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7pq2EQxhly+L for ; Tue, 8 Nov 2011 02:38:28 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id D379921F84C9 for ; Tue, 8 Nov 2011 02:38:28 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RNj4S-0000M9-IL; Tue, 08 Nov 2011 05:38:24 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: matt@mattmccutchen.net, warren@kumari.net X-Trac-Project: dane Date: Tue, 08 Nov 2011 10:38:24 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/6#comment:3 Message-ID: <070.8b97cd9133234c0cf649ed1d7a89ed03@trac.tools.ietf.org> References: <055.1026e2cada5be186d7270ba0ee6f1627@trac.tools.ietf.org> X-Trac-Ticket-ID: 6 In-Reply-To: <055.1026e2cada5be186d7270ba0ee6f1627@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: 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] #6: Downgrade attacks : What to do if DANE fails X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 10:38:29 -0000 #6: Downgrade attacks : What to do if DANE fails Changes (by warren@…): * status: reopened => closed * resolution: => worksforme Comment: Please see email: http://www.ietf.org/mail- archive/web/dane/current/msg03711.html This is addressed in draft-ietf-dane-protocol-12 in Sections 1.2 Section 4.4, para. 4, 5 and Appendix B. -- --------------------------------+------------------------- Reporter: mlepinsk@… | Owner: Type: defect | Status: closed Priority: major | Milestone: Component: protocol | Version: Severity: Active WG Document | Resolution: worksforme Keywords: | --------------------------------+------------------------- Ticket URL: dane From trac+dane@trac.tools.ietf.org Tue Nov 8 02:39: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 8A99721F8CAE for ; Tue, 8 Nov 2011 02:39:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNircd4Zdfn4 for ; Tue, 8 Nov 2011 02:39:45 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 16BBF21F8CAD for ; Tue, 8 Nov 2011 02:39:45 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RNj5k-0001WR-Ak; Tue, 08 Nov 2011 05:39:44 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: matt@mattmccutchen.net, warren@kumari.net X-Trac-Project: dane Date: Tue, 08 Nov 2011 10:39:44 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/13#comment:2 Message-ID: <070.002a6c7c40d00f53beb16725176b7266@trac.tools.ietf.org> References: <055.95ec24e5e3679207360dec78550e2dcb@trac.tools.ietf.org> X-Trac-Ticket-ID: 13 In-Reply-To: <055.95ec24e5e3679207360dec78550e2dcb@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] #13: Server name check for certificate type 1 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, 08 Nov 2011 10:39:45 -0000 #13: Server name check for certificate type 1 Changes (by warren@…): * status: new => closed * resolution: => worksforme Comment: See email: http://www.ietf.org/mail-archive/web/dane/current/msg03711.html This addressed in draft-ietf-dane-protocol-12 in Sections 2.1, 2.2, 2.3, most of section 4 and Appendix B. -- --------------------------------+------------------------- Reporter: mlepinsk@… | Owner: Type: defect | Status: closed Priority: minor | Milestone: Component: protocol | Version: Severity: Active WG Document | Resolution: worksforme Keywords: | --------------------------------+------------------------- Ticket URL: dane From trac+dane@trac.tools.ietf.org Tue Nov 8 02:40: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 AAA9021F8CB8 for ; Tue, 8 Nov 2011 02:40:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LdQpB1Gwiziw for ; Tue, 8 Nov 2011 02:40:35 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 42BFA21F8CB7 for ; Tue, 8 Nov 2011 02:40:35 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RNj6Y-0001Zu-W1; Tue, 08 Nov 2011 05:40:34 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: warren@kumari.net X-Trac-Project: dane Date: Tue, 08 Nov 2011 10:40:34 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/18#comment:1 Message-ID: <070.650db38bafeff2f8ca6f3c7890d56307@trac.tools.ietf.org> References: <055.86f379a033db79a2bbf5a2451defb0df@trac.tools.ietf.org> X-Trac-Ticket-ID: 18 In-Reply-To: <055.86f379a033db79a2bbf5a2451defb0df@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: warren@kumari.net, dane@ietf.org X-SA-Exim-Mail-From: trac+dane@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: dane@ietf.org Subject: Re: [dane] #18: Certificate Properties and Relationship with PKIX 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, 08 Nov 2011 10:40:35 -0000 #18: Certificate Properties and Relationship with PKIX Changes (by warren@…): * status: new => closed * resolution: => worksforme Comment: See email: http://www.ietf.org/mail-archive/web/dane/current/msg03711.html This was a somewhat exploratory question, and has been addressed in multiple discussion, and in the protocol document, Version -12, Section 4.x, Section 1.2 and Appendix B. -- --------------------------------+------------------------- Reporter: mlepinsk@… | Owner: Type: task | Status: closed Priority: major | Milestone: Component: protocol | Version: Severity: Active WG Document | Resolution: worksforme Keywords: | --------------------------------+------------------------- Ticket URL: dane From zack.weinberg@gmail.com Tue Nov 8 08:10: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 EC46211E809B for ; Tue, 8 Nov 2011 08:10:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9-fsnhA8crk for ; Tue, 8 Nov 2011 08:10:33 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 95E8111E8099 for ; Tue, 8 Nov 2011 08:10:30 -0800 (PST) Received: by qyk32 with SMTP id 32so715720qyk.10 for ; Tue, 08 Nov 2011 08:10:26 -0800 (PST) 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=uhm21Kt+JyeUTZrKG/DLj/oxTdgEu+sdeEaVT2by5eU=; b=Ie9QxmFE9gxizkLi7nUL/Rr4JThqiSor/zMIsymQFMGdZFtAoKvOMHIH3sdAoYpIP6 /Phn8Zf52FUcwHWgsSDVF3pQS/CkW2sApCBNxh+MRgmv9C5k84QdOuE1J0OHisXV7Z/3 sEQikaPXpUtxbQT5xwqCbQn50+YXhmh5LRa1g= Received: by 10.68.74.40 with SMTP id q8mr1873473pbv.36.1320768626168; Tue, 08 Nov 2011 08:10:26 -0800 (PST) Received: from ardsley.local (99-113-32-219.lightspeed.sntcca.sbcglobal.net. [99.113.32.219]) by mx.google.com with ESMTPS id wf19sm5259309pbb.17.2011.11.08.08.10.24 (version=SSLv3 cipher=OTHER); Tue, 08 Nov 2011 08:10:24 -0800 (PST) Sender: Zack Weinberg Message-ID: <4EB95472.6020105@sv.cmu.edu> Date: Tue, 08 Nov 2011 08:10:26 -0800 From: Zack Weinberg User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: dane@ietf.org References: <055.95ec24e5e3679207360dec78550e2dcb@trac.tools.ietf.org> <070.002a6c7c40d00f53beb16725176b7266@trac.tools.ietf.org> In-Reply-To: <070.002a6c7c40d00f53beb16725176b7266@trac.tools.ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dane] #13: Server name check for certificate type 1 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 08 Nov 2011 16:10:55 -0000 On 2011-11-08 2:39 AM, dane issue tracker wrote: > #13: Server name check for certificate type 1 > This addressed in draft-ietf-dane-protocol-12 in Sections 2.1, 2.2, 2.3, > most of section 4 and Appendix B. I'm sorry I missed this when you sent out the call for comments. I do not believe this issue has been adequately addressed in -12. In particular, when the end-entity certificate matches a valid TLSA record but does NOT contain embedded name information matching the hostname under which the record was found, client behavior is unspecified. (It's possible that you think "pass PKIX validation" covers this case, but that term is ill-defined to the point where I think it needs to be eradicated from the spec.) (I was not able to resolve this issue in my rewrite because I don't know what the client *ought* to do in this circumstance, only that there needs to be a specified behavior.) zw From paul.hoffman@vpnc.org Tue Nov 8 09:07: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 569F721F8ACC for ; Tue, 8 Nov 2011 09:07:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yru1skYmgafG for ; Tue, 8 Nov 2011 09:07:27 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9912121F8569 for ; Tue, 8 Nov 2011 09:07:26 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id pA8H7P8u041211 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 8 Nov 2011 10:07:26 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4EB95472.6020105@sv.cmu.edu> Date: Tue, 8 Nov 2011 09:07:25 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <35B4CB5E-4433-416A-89A9-DDA92321085E@vpnc.org> References: <055.95ec24e5e3679207360dec78550e2dcb@trac.tools.ietf.org> <070.002a6c7c40d00f53beb16725176b7266@trac.tools.ietf.org> <4EB95472.6020105@sv.cmu.edu> To: Zack Weinberg X-Mailer: Apple Mail (2.1251.1) Cc: dane@ietf.org Subject: Re: [dane] #13: Server name check for certificate type 1 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 08 Nov 2011 17:07:27 -0000 On Nov 8, 2011, at 8:10 AM, Zack Weinberg wrote: > On 2011-11-08 2:39 AM, dane issue tracker wrote: >> #13: Server name check for certificate type 1 >> This addressed in draft-ietf-dane-protocol-12 in Sections 2.1, 2.2, = 2.3, >> most of section 4 and Appendix B. >=20 > I'm sorry I missed this when you sent out the call for comments. I do = not believe this issue has been adequately addressed in -12. In = particular, when the end-entity certificate matches a valid TLSA record = but does NOT contain embedded name information matching the hostname = under which the record was found, client behavior is unspecified. We should specify it. What is your preference? > (It's possible that you think "pass PKIX validation" covers this case, = but that term is ill-defined to the point where I think it needs to be = eradicated from the spec.) It is defined in the PKIX specification. You may not like it, but that's = the standard. > (I was not able to resolve this issue in my rewrite because I don't = know what the client *ought* to do in this circumstance, only that there = needs to be a specified behavior.) So, propose the one you like the best and see what the rest of the WG = thinks. --Paul Hoffman From rbarnes@bbn.com Tue Nov 8 09:13: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 7086721F8B3B for ; Tue, 8 Nov 2011 09:13:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCg7tNIW2xcx for ; Tue, 8 Nov 2011 09:13:46 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id EB01E21F8B31 for ; Tue, 8 Nov 2011 09:13:45 -0800 (PST) Received: from dhcp89-089-010.bbn.com ([128.89.89.10]:65067) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RNpF2-000FFa-Pj; Tue, 08 Nov 2011 12:13:44 -0500 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Richard Barnes In-Reply-To: <4EB95472.6020105@sv.cmu.edu> Date: Tue, 8 Nov 2011 12:13:44 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <56F1C4E4-91ED-410C-8D8B-52BDD2B63B3F@bbn.com> References: <055.95ec24e5e3679207360dec78550e2dcb@trac.tools.ietf.org> <070.002a6c7c40d00f53beb16725176b7266@trac.tools.ietf.org> <4EB95472.6020105@sv.cmu.edu> To: Zack Weinberg X-Mailer: Apple Mail (2.1251.1) Cc: dane@ietf.org Subject: Re: [dane] #13: Server name check for certificate type 1 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 08 Nov 2011 17:13:46 -0000 That is the correct behavior. The name matching algorithm is not a = TLS-layer issue, but an application-layer one. " Some specifications for applications that run under TLS, such as [RFC2818] for HTTP, require the server's certificate to have a domain name that matches the host name expected by the client. Some specifications such at [RFC6125] detail how to match the identify given in a PKIX certificate with those expected by the user. " On Nov 8, 2011, at 11:10 AM, Zack Weinberg wrote: > On 2011-11-08 2:39 AM, dane issue tracker wrote: >> #13: Server name check for certificate type 1 >> This addressed in draft-ietf-dane-protocol-12 in Sections 2.1, 2.2, = 2.3, >> most of section 4 and Appendix B. >=20 > I'm sorry I missed this when you sent out the call for comments. I do = not believe this issue has been adequately addressed in -12. In = particular, when the end-entity certificate matches a valid TLSA record = but does NOT contain embedded name information matching the hostname = under which the record was found, client behavior is unspecified. >=20 > (It's possible that you think "pass PKIX validation" covers this case, = but that term is ill-defined to the point where I think it needs to be = eradicated from the spec.) >=20 > (I was not able to resolve this issue in my rewrite because I don't = know what the client *ought* to do in this circumstance, only that there = needs to be a specified behavior.) >=20 > zw > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From paul@xelerance.com Tue Nov 8 14:11: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 B1D811F0C4A; Tue, 8 Nov 2011 14:11:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.537 X-Spam-Level: X-Spam-Status: No, score=-6.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 iZ3kPy-Fp36m; Tue, 8 Nov 2011 14:11:52 -0800 (PST) Received: from mx.xelerance.com (mx.xelerance.com [193.110.157.188]) by ietfa.amsl.com (Postfix) with ESMTP id B514521F8B5B; Tue, 8 Nov 2011 14:11:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx.xelerance.com (Postfix) with ESMTP id 5EF7E587; Tue, 8 Nov 2011 17:11:49 -0500 (EST) 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=1320790308; x= 1321395108; bh=CPhr9rwmy0k/uIuGQ2Skyu3MMiU7GzfxSRYnWXTpPBc=; b=P /VE1G/8tIoZYb8JJLYQkGf5b1u1biGHnEXg2qbFxGV/FKTJbw6nEFSZR1M43ISud GsEcPk9BQcndsk2FrLWgLG0XO1jXGNGhQkGEnFy+X6PLgP2h8f6P4EfgBVOyX6Jl BhvGpa1V8bTODzQMuU0AmBv76oazEeRH5eneHVA/GQ= 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 rFMFpbk9J2Wf; Tue, 8 Nov 2011 17:11:48 -0500 (EST) 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 CDE089E; Tue, 8 Nov 2011 17:11:45 -0500 (EST) Received: by mail.xelerance.com (Postfix, from userid 1001) id 0DB1E555; Tue, 8 Nov 2011 17:11:45 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.xelerance.com (Postfix) with ESMTP id 083DD554; Tue, 8 Nov 2011 17:11:45 -0500 (EST) Date: Tue, 8 Nov 2011 17:11:44 -0500 (EST) From: Paul Wouters To: Richard Barnes In-Reply-To: <56F1C4E4-91ED-410C-8D8B-52BDD2B63B3F@bbn.com> Message-ID: References: <055.95ec24e5e3679207360dec78550e2dcb@trac.tools.ietf.org> <070.002a6c7c40d00f53beb16725176b7266@trac.tools.ietf.org> <4EB95472.6020105@sv.cmu.edu> <56F1C4E4-91ED-410C-8D8B-52BDD2B63B3F@bbn.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: tls@ietf.org, dane@ietf.org Subject: Re: [dane] #13: Server name check for certificate type 1 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 08 Nov 2011 22:11:52 -0000 On Tue, 8 Nov 2011, Richard Barnes wrote: > That is the correct behavior. The name matching algorithm is not a TLS-layer issue, but an application-layer one. > " > Some specifications for applications that run under TLS, such as > [RFC2818] for HTTP, require the server's certificate to have a domain > name that matches the host name expected by the client. Some > specifications such at [RFC6125] detail how to match the identify > given in a PKIX certificate with those expected by the user. > " That will require an update anyway for http://tools.ietf.org/html/draft-wouters-tls-oob-pubkey-01 Perhap this update needs to be made explicit in that draft to reflect this change. However, it would be nice if we did not have to force people to use raw pubkeys if they do not want to maintain a subjectAltname= list in their certificates but still want to take advantage of PKIX validation. Paul > > > On Nov 8, 2011, at 11:10 AM, Zack Weinberg wrote: > >> On 2011-11-08 2:39 AM, dane issue tracker wrote: >>> #13: Server name check for certificate type 1 >>> This addressed in draft-ietf-dane-protocol-12 in Sections 2.1, 2.2, 2.3, >>> most of section 4 and Appendix B. >> >> I'm sorry I missed this when you sent out the call for comments. I do not believe this issue has been adequately addressed in -12. In particular, when the end-entity certificate matches a valid TLSA record but does NOT contain embedded name information matching the hostname under which the record was found, client behavior is unspecified. >> >> (It's possible that you think "pass PKIX validation" covers this case, but that term is ill-defined to the point where I think it needs to be eradicated from the spec.) >> >> (I was not able to resolve this issue in my rewrite because I don't know what the client *ought* to do in this circumstance, only that there needs to be a specified behavior.) >> >> zw >> _______________________________________________ >> 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 zack.weinberg@gmail.com Tue Nov 8 15:01: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 55FDC11E80A6 for ; Tue, 8 Nov 2011 15:01:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MX5nocZOErsF for ; Tue, 8 Nov 2011 15:01:48 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id B170211E80A3 for ; Tue, 8 Nov 2011 15:01:48 -0800 (PST) Received: by ywt2 with SMTP id 2so1301147ywt.31 for ; Tue, 08 Nov 2011 15:01:48 -0800 (PST) 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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=2LWaljuaMouaNzWNMgUYEEqid8b5/MweA9iXqMSPrg4=; b=iKOGHOid6NlqXF4ymXUeaB1Z7jiLm5t+QPAVYl8xtYZi38AomqSpjFzbH9lozWrghW tQR4ZSC9CJ5XIvelpgc/HuqfXYnkF7aH7+qRvtJuA6Y3uejZ1rpxGj3NM7lmhvTg+5S5 iGAIJyhMFKMcOtPI+jNYkzipMqKjFb55d3upQ= Received: by 10.68.38.71 with SMTP id e7mr202349pbk.88.1320793288437; Tue, 08 Nov 2011 15:01:28 -0800 (PST) Received: from ardsley.local (mozilla.vlan426.asr1.sfo1.gblx.net. [159.63.23.38]) by mx.google.com with ESMTPS id 3sm7704038pbx.14.2011.11.08.15.01.27 (version=SSLv3 cipher=OTHER); Tue, 08 Nov 2011 15:01:27 -0800 (PST) Sender: Zack Weinberg Message-ID: <4EB9B4C6.1030207@sv.cmu.edu> Date: Tue, 08 Nov 2011 15:01:26 -0800 From: Zack Weinberg User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Paul Hoffman References: <055.95ec24e5e3679207360dec78550e2dcb@trac.tools.ietf.org> <070.002a6c7c40d00f53beb16725176b7266@trac.tools.ietf.org> <4EB95472.6020105@sv.cmu.edu> <35B4CB5E-4433-416A-89A9-DDA92321085E@vpnc.org> In-Reply-To: <35B4CB5E-4433-416A-89A9-DDA92321085E@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dane@ietf.org Subject: Re: [dane] #13: Server name check for certificate type 1 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 08 Nov 2011 23:01:49 -0000 On 2011-11-08 9:07 AM, Paul Hoffman wrote: > On Nov 8, 2011, at 8:10 AM, Zack Weinberg wrote: > >> On 2011-11-08 2:39 AM, dane issue tracker wrote: >>> #13: Server name check for certificate type 1 >>> This addressed in draft-ietf-dane-protocol-12 in Sections 2.1, 2.2, 2.3, >>> most of section 4 and Appendix B. >> >> I'm sorry I missed this when you sent out the call for comments. I do not believe this issue has been adequately addressed in -12. In particular, when the end-entity certificate matches a valid TLSA record but does NOT contain embedded name information matching the hostname under which the record was found, client behavior is unspecified. > > We should specify it. What is your preference? It would certainly be operationally convenient for a type-1 match to override domain name information in the certificate (eliminate the need for those horrible CDN certificates with dozens of hostnames in the subjectAltName) but for backward compatibility's sake people are going to have to keep doing that anyway, so I don't see a strong case either way. I suppose we could split the difference and say that a DANE-compliant client MUST interpret a certificate with *no* embedded hostname information as if it had had embedded hostname information corresponding to the hostname where the TLSA record was, but SHOULD otherwise process embedded hostname information as it would have in the absence of TLSA records. I'd like to hear from people who actually operate TLS servers at scale, though. >> (It's possible that you think "pass PKIX validation" covers this case, but that term is ill-defined to the point where I think it needs to be eradicated from the spec.) > > It is defined in the PKIX specification. You may not like it, but that's the standard. The definition of "validation" in the PKIX specification is so ambiguous that it is unusable. Please see http://www.ietf.org/mail-archive/web/dane/current/msg03284.html and http://www.ietf.org/mail-archive/web/dane/current/msg03285.html -- I can't say it any better than Peter did. zw From paul.hoffman@vpnc.org Tue Nov 8 15:27: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 3F73A1F0C6F for ; Tue, 8 Nov 2011 15:27:14 -0800 (PST) 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 LRsUS0c7dzkm for ; Tue, 8 Nov 2011 15:27:13 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 87B7D1F0C47 for ; Tue, 8 Nov 2011 15:27:13 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id pA8NRCSl057728 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 8 Nov 2011 16:27:12 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Tue, 8 Nov 2011 15:27:11 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <5D0375A3-7DB8-4DF0-A8A0-49926E360CC4@vpnc.org> References: <055.95ec24e5e3679207360dec78550e2dcb@trac.tools.ietf.org> <070.002a6c7c40d00f53beb16725176b7266@trac.tools.ietf.org> <4EB95472.6020105@sv.cmu.edu> <56F1C4E4-91ED-410C-8D8B-52BDD2B63B3F@bbn.com> To: Paul Wouters X-Mailer: Apple Mail (2.1251.1) Cc: IETF DANE WG list Subject: Re: [dane] #13: Server name check for certificate type 1 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 08 Nov 2011 23:27:14 -0000 On Nov 8, 2011, at 2:11 PM, Paul Wouters wrote: > On Tue, 8 Nov 2011, Richard Barnes wrote: >=20 >> That is the correct behavior. The name matching algorithm is not a = TLS-layer issue, but an application-layer one. >> " >> Some specifications for applications that run under TLS, such as >> [RFC2818] for HTTP, require the server's certificate to have a = domain >> name that matches the host name expected by the client. Some >> specifications such at [RFC6125] detail how to match the identify >> given in a PKIX certificate with those expected by the user. >> " >=20 > That will require an update anyway for = http://tools.ietf.org/html/draft-wouters-tls-oob-pubkey-01 It would be unwise for this WG to get gated behind your draft. Instead, = your draft can update both TLS and DANE. > Perhap this update needs to be made explicit in that draft to reflect = this change. However, it would be nice if > we did not have to force people to use raw pubkeys if they do not want = to maintain a subjectAltname=3D list in their > certificates but still want to take advantage of PKIX validation. Correct. That is something that your draft should definitely deal with. --Paul Hoffman From paul.hoffman@vpnc.org Tue Nov 8 15:31: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 C04A11F0C70 for ; Tue, 8 Nov 2011 15:31:12 -0800 (PST) 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 VHJHtle-mFaw for ; Tue, 8 Nov 2011 15:31:12 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3DCE71F0C47 for ; Tue, 8 Nov 2011 15:31:12 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id pA8NVBc8057823 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 8 Nov 2011 16:31:11 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4EB9B4C6.1030207@sv.cmu.edu> Date: Tue, 8 Nov 2011 15:31:10 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <879AE341-3935-4599-9A0B-2325C2DF65E0@vpnc.org> References: <055.95ec24e5e3679207360dec78550e2dcb@trac.tools.ietf.org> <070.002a6c7c40d00f53beb16725176b7266@trac.tools.ietf.org> <4EB95472.6020105@sv.cmu.edu> <35B4CB5E-4433-416A-89A9-DDA92321085E@vpnc.org> <4EB9B4C6.1030207@sv.cmu.edu> To: Zack Weinberg X-Mailer: Apple Mail (2.1251.1) Cc: dane@ietf.org Subject: Re: [dane] #13: Server name check for certificate type 1 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 08 Nov 2011 23:31:12 -0000 On Nov 8, 2011, at 3:01 PM, Zack Weinberg wrote: > On 2011-11-08 9:07 AM, Paul Hoffman wrote: >> On Nov 8, 2011, at 8:10 AM, Zack Weinberg wrote: >>=20 >>> On 2011-11-08 2:39 AM, dane issue tracker wrote: >>>> #13: Server name check for certificate type 1 >>>> This addressed in draft-ietf-dane-protocol-12 in Sections 2.1, = 2.2, 2.3, >>>> most of section 4 and Appendix B. >>>=20 >>> I'm sorry I missed this when you sent out the call for comments. I = do not believe this issue has been adequately addressed in -12. In = particular, when the end-entity certificate matches a valid TLSA record = but does NOT contain embedded name information matching the hostname = under which the record was found, client behavior is unspecified. >>=20 >> We should specify it. What is your preference? >=20 > It would certainly be operationally convenient for a type-1 match to = override domain name information in the certificate (eliminate the need = for those horrible CDN certificates with dozens of hostnames in the = subjectAltName) but for backward compatibility's sake people are going = to have to keep doing that anyway, so I don't see a strong case either = way. Should we take that as that the current wording is good enough? > I suppose we could split the difference and say that a DANE-compliant = client MUST interpret a certificate with *no* embedded hostname = information as if it had had embedded hostname information corresponding = to the hostname where the TLSA record was, but SHOULD otherwise process = embedded hostname information as it would have in the absence of TLSA = records. That's not "splitting the difference", that is a technically separate = proposal.=20 Personally, I like the first part (if there is no host name, match = wherever you got the TLSA record from), but the second part is too = vague. What are the exceptions to the SHOULD? I would prefer a MUST or = nothing. > I'd like to hear from people who actually operate TLS servers at = scale, though. Yes, please. > The definition of "validation" in the PKIX specification is so = ambiguous that it is unusable. =20 Then you believe that PKIX itself is unusable. The WG has chosen = differently so far. --Paul Hoffman From zack.weinberg@gmail.com Tue Nov 8 15:44: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 8FF7221F8541 for ; Tue, 8 Nov 2011 15:44:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZqFFCNfM5xd for ; Tue, 8 Nov 2011 15:44:07 -0800 (PST) Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id 086A521F8540 for ; Tue, 8 Nov 2011 15:44:06 -0800 (PST) Received: by pzk4 with SMTP id 4so61216pzk.9 for ; Tue, 08 Nov 2011 15:44:06 -0800 (PST) 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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=b7Mv9A3FtuW2YpJilIRH6DPDh3/E0Vw9EEa+5xBhChs=; b=BUE1NCdvJgGkmtoskNOhE7LFeRyxTb5gp1DmwAxSXj3ak5cAgy9ucDSXa3+Y+LL41D ECN2nEGc4xYyPdE0KW6OEV8tCAQYJvbQcjslF04UUXmxr7k2EEUHnj9yQTafUuivsMoW MDOxtkMj2UZgKD89flj7zMemHPYi24KPnAF/0= Received: by 10.68.6.234 with SMTP id e10mr483307pba.90.1320795846765; Tue, 08 Nov 2011 15:44:06 -0800 (PST) Received: from ardsley.local (mozilla.vlan426.asr1.sfo1.gblx.net. [159.63.23.38]) by mx.google.com with ESMTPS id p6sm8017222pbf.3.2011.11.08.15.44.05 (version=SSLv3 cipher=OTHER); Tue, 08 Nov 2011 15:44:06 -0800 (PST) Sender: Zack Weinberg Message-ID: <4EB9BEC4.40107@sv.cmu.edu> Date: Tue, 08 Nov 2011 15:44:04 -0800 From: Zack Weinberg User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Paul Hoffman References: <055.95ec24e5e3679207360dec78550e2dcb@trac.tools.ietf.org> <070.002a6c7c40d00f53beb16725176b7266@trac.tools.ietf.org> <4EB95472.6020105@sv.cmu.edu> <35B4CB5E-4433-416A-89A9-DDA92321085E@vpnc.org> <4EB9B4C6.1030207@sv.cmu.edu> <879AE341-3935-4599-9A0B-2325C2DF65E0@vpnc.org> In-Reply-To: <879AE341-3935-4599-9A0B-2325C2DF65E0@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dane@ietf.org Subject: Re: [dane] #13: Server name check for certificate type 1 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 08 Nov 2011 23:44:07 -0000 On 2011-11-08 3:31 PM, Paul Hoffman wrote: > On Nov 8, 2011, at 3:01 PM, Zack Weinberg wrote: >> It would certainly be operationally convenient for a type-1 match to override domain name information in the certificate (eliminate the need for those horrible CDN certificates with dozens of hostnames in the subjectAltName) but for backward compatibility's sake people are going to have to keep doing that anyway, so I don't see a strong case either way. > > Should we take that as that the current wording is good enough? Absolutely not. I think we need to add wording that says either "TLSA hostname overrides in-certificate hostname" or "TLSA hostname must agree with in-certificate hostname" or "TLSA hostname overrides in-certificate hostname under circumstances X, Y, or Z, and must agree with in-certificate hostname otherwise." But I do not feel qualified to pick one of these options, or to define circumstances X, Y, or Z, unilaterally. >> I suppose we could split the difference and say that a DANE-compliant client MUST interpret a certificate with *no* embedded hostname information as if it had had embedded hostname information corresponding to the hostname where the TLSA record was, but SHOULD otherwise process embedded hostname information as it would have in the absence of TLSA records. > > That's not "splitting the difference", that is a technically separate proposal. I don't see why it matters whether it is a separate proposal or not. > Personally, I like the first part (if there is no host name, match wherever > you got the TLSA record from), but the second part is too vague. > What are the exceptions to the SHOULD? I would prefer a MUST or nothing. Well, Richard's language implies that there exist TLS-using application protocols that, as they are spoke, don't bother checking the in-certificate hostname(s) at all. We wouldn't want to break them. If there are no such protocols, then I would be happy to have a MUST. >> The definition of "validation" in the PKIX specification is so ambiguous that it is unusable. > > Then you believe that PKIX itself is unusable. Only its definition of validation. > The WG has chosen differently so far. Please consider this message an objection to that decision, at whatever level of formality is appropriate to the present stage of the process. zw From mrex@sap.com Tue Nov 8 15: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 44D0311E8088 for ; Tue, 8 Nov 2011 15:51:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.123 X-Spam-Level: X-Spam-Status: No, score=-10.123 tagged_above=-999 required=5 tests=[AWL=0.126, 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 FkjfOSP4bO8O for ; Tue, 8 Nov 2011 15:51:17 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 577CE11E8081 for ; Tue, 8 Nov 2011 15:51:17 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id pA8NpCOk026215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 9 Nov 2011 00:51:12 +0100 (MET) From: Martin Rex Message-Id: <201111082351.pA8NpBwS017073@fs4113.wdf.sap.corp> To: paul.hoffman@vpnc.org (Paul Hoffman) Date: Wed, 9 Nov 2011 00:51:11 +0100 (MET) In-Reply-To: <35B4CB5E-4433-416A-89A9-DDA92321085E@vpnc.org> from "Paul Hoffman" at Nov 8, 11 09:07:25 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] #13: Server name check for certificate type 1 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 23:51:18 -0000 Paul Hoffman wrote: > > Zack Weinberg wrote: > > > dane issue tracker wrote: > > > > > > #13: Server name check for certificate type 1 > > > This addressed in draft-ietf-dane-protocol-12 in > > > Sections 2.1, 2.2, 2.3, most of section 4 and Appendix B. > > > > I do not believe this issue has been adequately addressed in -12. > > In particular, when the end-entity certificate matches a valid > > TLSA record but does NOT contain embedded name information > > matching the hostname under which the record was found, > > client behavior is unspecified. > > We should specify it. What is your preference? I fully agree with Zack. It is underspecified and needs to be explicit. I believe that still performing the matching is preferable to provide consistent behaviour accross the installed base of future DANE-aware and existing, DANE-unware TLS clients. Where both should work, both should work (and fail) in the same way, unless the information from PKIX and DANE is in contradiction to each other. > > > > > (It's possible that you think "pass PKIX validation" covers this case, > > but that term is ill-defined to the point where I think it needs to > > be eradicated from the spec.) > > It is defined in the PKIX specification. > You may not like it, but that's the standard. As Richard mentions, this is statement factually wrong. PKIX validation has nothing to do with name matching for the purpose of "TLS server endpoint identification" as defined in rfc2818 section 3.1 or in rfc6125. rfc2818 was output of the TLS working group, rfc6125 was the output of an IETF mailing list called "certid" (that was not an official WG). rfc2818 is informational, documenting behaviour of the installed base, not standards track. -Martin From zack.weinberg@gmail.com Tue Nov 8 20:34: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 78B9F11E80A4 for ; Tue, 8 Nov 2011 20:34:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.777 X-Spam-Level: X-Spam-Status: No, score=-2.777 tagged_above=-999 required=5 tests=[AWL=0.200, 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 FU5JwK81Wifd for ; Tue, 8 Nov 2011 20:34:38 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id CBB1811E8096 for ; Tue, 8 Nov 2011 20:34:37 -0800 (PST) Received: by ywt2 with SMTP id 2so1586023ywt.31 for ; Tue, 08 Nov 2011 20:34:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=vHdZq5GA3U/yXa4wumLxrUYwjireSGY8o4tF6yejxLQ=; b=pDU3ASSVyKUJY133KlP8m+CEtrtP+vkFTfOuRtt4eXEuAc4+AshKxwFMQtMF/sa/hg VyVHYi1wl5EyxoVH7diO9Wk1mD7BxtXSlDqfWAeQrints9IuUBghnrXEGW/3oaqlEd6h W+1TSsI+HLctJ4X9VrXMeoMwMCR69GUMSuhi0= MIME-Version: 1.0 Received: by 10.182.164.74 with SMTP id yo10mr138032obb.69.1320813276331; Tue, 08 Nov 2011 20:34:36 -0800 (PST) Sender: zack.weinberg@gmail.com Received: by 10.182.88.103 with HTTP; Tue, 8 Nov 2011 20:34:36 -0800 (PST) In-Reply-To: References: Date: Tue, 8 Nov 2011 20:34:36 -0800 X-Google-Sender-Auth: DWvKp72lmfBoL1_cQ-u8aCMSEP8 Message-ID: From: Zack Weinberg To: Richard Barnes , IETF DANE WG list Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [dane] DANE protocol spec complete rewrite X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 04:34:38 -0000 On reflection, this message was too crabby. I apologize. Please allow me to try to rephrase the sentiment: I intended to produce a document that was more clearly written than the current draft, and obviously _I_ think I succeeded, otherwise I would not have posted it. That you think it is _less_ clearly written is a disappointment, but I would like to know in more detail what you think is wrong with the revision, so I can try to make it an improvement in everyone's eyes. zw On Sun, Nov 6, 2011 at 8:10 PM, Zack Weinberg wr= ote: > On Sun, Nov 6, 2011 at 7:18 PM, Richard Barnes wrote: >> I have reviewed this document, and would not recommend that it serve as = the basis for further working group documents. =C2=A0It is much less clearl= y written than the current document, in large part due to sloppy use of ter= minology. > > A primary goal of the rewrite was to make the terminology much more > precise than the present draft; therefore, I would appreciate an > explanation of exactly what you find to be "sloppier" than the status > quo. =C2=A0Note that I deliberately avoided terminology which people > *think* has a precise meaning, but that meaning is contested among two > or more usage groups, so it's not actually unambiguous; instead I used > terminology that I made up, so that it would mean exactly what I > wanted it to mean. =C2=A0Perhaps that is what you do not like? > Unfortunately, under the circumstances, I don't think we have a > choice. > >> Rather than submitting a bunch of changes all at once like this, it woul= d be much more helpful to work with the editors on the specific changes you= think need to be made. =C2=A0For instance, I would support efforts to make= the processing/decision algorithm more explicit and to incorporate some us= age examples. > > I do not think it is practical to make some of the changes that I want > made without a wholesale rewrite, and this particularly goes for > terminology. =C2=A0I cannot support the present draft's terminology; it i= s > asking for incompatible implementations. > > zw > From trac+dane@trac.tools.ietf.org Tue Nov 8 20:58: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 5EA3211E80F3 for ; Tue, 8 Nov 2011 20:58:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQBJzcWP60FJ for ; Tue, 8 Nov 2011 20:58:52 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id E22F211E80F2 for ; Tue, 8 Nov 2011 20:58:51 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RO0FN-0006jB-HG; Tue, 08 Nov 2011 23:58:49 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: matt@mattmccutchen.net, warren@kumari.net X-Trac-Project: dane Date: Wed, 09 Nov 2011 04:58:49 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/6#comment:4 Message-ID: <070.b33acc5d8289801bd9fe723f43a43378@trac.tools.ietf.org> References: <055.1026e2cada5be186d7270ba0ee6f1627@trac.tools.ietf.org> X-Trac-Ticket-ID: 6 In-Reply-To: <055.1026e2cada5be186d7270ba0ee6f1627@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: 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] #6: Downgrade attacks : What to do if DANE fails X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 04:58:52 -0000 #6: Downgrade attacks : What to do if DANE fails Changes (by matt@…): * status: closed => reopened * resolution: worksforme => Comment: I hate to reopen this again (and I apologize for missing the deadline of Friday), but the essential issue that I mentioned in comment:2 is not addressed in Section 4.4 or Appendix B, and only obliquely if at all in Section 1.2. Do we state that a client MUST fail the TLS handshake if it cannot get a secure or verified insecure response to the TLSA query? If we do not make this requirement, clients could leave themselves open to a trivial TLSA stripping attack that defeats any restrictive semantics DANE might provide. I understand we may want to leave room for local policy, but I'd argue that this requirement should have the same strength as the last MUST in section 4.4, because it is the conjunction of the two requirements that provides secure restriction. -- --------------------------------+----------------------- Reporter: mlepinsk@… | Owner: Type: defect | Status: reopened Priority: major | Milestone: Component: protocol | Version: Severity: Active WG Document | Resolution: Keywords: | --------------------------------+----------------------- Ticket URL: dane From trac+dane@trac.tools.ietf.org Tue Nov 8 21: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 C530A11E80D9 for ; Tue, 8 Nov 2011 21:06:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXSR7OMltTyb for ; Tue, 8 Nov 2011 21:06:17 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1E711E8096 for ; Tue, 8 Nov 2011 21:06:14 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RO0MX-0003au-JY; Wed, 09 Nov 2011 00:06:13 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: matt@mattmccutchen.net, warren@kumari.net X-Trac-Project: dane Date: Wed, 09 Nov 2011 05:06:13 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/13#comment:3 Message-ID: <070.3fce6cfa0466a68b9e66cee35d3a9a59@trac.tools.ietf.org> References: <055.95ec24e5e3679207360dec78550e2dcb@trac.tools.ietf.org> X-Trac-Ticket-ID: 13 In-Reply-To: <055.95ec24e5e3679207360dec78550e2dcb@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] #13: Hostnames in Certificates (was: Server name check for certificate type 1) 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, 09 Nov 2011 05:06:18 -0000 #13: Hostnames in Certificates Changes (by matt@…): * status: closed => reopened * resolution: worksforme => Comment: What is the answer to the question? I don't see any reference to a server name check in the document (as Martin will remind us, "PKIX validation" does not include server name checking); does this mean the requirement is not imposed? We certainly want it when the TLSA record contains a CA cert different from the server cert, to prevent MITM attackers from diverting TLS connections to unrelated servers with certs from the same CA. -- --------------------------------+----------------------- Reporter: mlepinsk@… | Owner: Type: defect | Status: reopened Priority: minor | Milestone: Component: protocol | Version: Severity: Active WG Document | Resolution: Keywords: | --------------------------------+----------------------- Ticket URL: dane From rbarnes@bbn.com Wed Nov 9 14:21: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 4C13911E8085 for ; Wed, 9 Nov 2011 14:21:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTlIE04hd3cZ for ; Wed, 9 Nov 2011 14:21:22 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 359E811E808C for ; Wed, 9 Nov 2011 14:21:22 -0800 (PST) Received: from [128.89.254.48] (port=53210) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1ROGWF-0005UP-59; Wed, 09 Nov 2011 17:21:19 -0500 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Richard Barnes In-Reply-To: <4EB9B4C6.1030207@sv.cmu.edu> Date: Wed, 9 Nov 2011 17:21:18 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <75129DA0-13D2-4E26-ACD3-C3F419DE42C4@bbn.com> References: <055.95ec24e5e3679207360dec78550e2dcb@trac.tools.ietf.org> <070.002a6c7c40d00f53beb16725176b7266@trac.tools.ietf.org> <4EB95472.6020105@sv.cmu.edu> <35B4CB5E-4433-416A-89A9-DDA92321085E@vpnc.org> <4EB9B4C6.1030207@sv.cmu.edu> To: Zack Weinberg X-Mailer: Apple Mail (2.1251.1) Cc: Paul Hoffman , dane@ietf.org Subject: Re: [dane] #13: Server name check for certificate type 1 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 22:21:23 -0000 I still disagree with this. Names are not considered at the = DANE/PKIX/TLS layer -- only the application considers the name. This = document should not place any constraints on what names should or should = not be in certificates. =20 In any case, it's not clear where such a constraint would fit in. = Consider the three use cases / usage we have: The "cert lock" and "CA = lock" usages place hard constraints on names -- the only name allowed in = the matching cert is the one in the record. In the "CA lock" case, the = end server certificate can also be constrained by X.509 name = constraints. =20 In the "TA assertion" case, name constraint is actually the opposite of = what you want in some cases. If you want to use the same CA certificate = as the basis for multiple hosts, you'll want to have the CA certificate = have a different name than the individual host certificates. =20 Now, all that said, there are some name-based risks. Certain = applications do rely on PKIX authorities as a stop-gap when DNSSEC isn't = available, so if we make PKIX authority rest on DNSSEC, then we might = create vulnerabilities for these applications. For example, XMPP uses = SRV to redirect between domains: _xmpp-server._tcp.example.com SRV xmpp1.provider.com 5222 When this record is not protected by DNSSEC, the server at = xmpp1.provider.com has to authenticate as "example.com", so that the = PKIX CA effectively attests to the delegation. However, if the client = uses a TLSA record under xmpp1.provider.com, the target server can = assume any identity it wants to by asserting a usage-2 certificate with = the proper name. I think the proper resolution here is to clarify which domain is used to = locate the TLSA records. In the terminology of RFC 6125, the proper = domain is the "source domain", the domain that the client expects the = server to authenticate. In the above example, "example.com". Suggested = change in Section 3: OLD: " TLSA resource records are stored at a prefixed DNS domain name. " NEW: " The "source domain" for a TLS connection is the name that a client = expects a server to present in the TLS handshake. When a client wishes = to connect to a given source domain, it searches for TLSA records under = a special name formed by appending a prefix to the source domain. " --Richard BTW, with regard to "those horrible CDN certificates with dozens of = hostnames in the subjectAltName": DANE is not the droid you're looking = for: On Nov 8, 2011, at 6:01 PM, Zack Weinberg wrote: > On 2011-11-08 9:07 AM, Paul Hoffman wrote: >> On Nov 8, 2011, at 8:10 AM, Zack Weinberg wrote: >>=20 >>> On 2011-11-08 2:39 AM, dane issue tracker wrote: >>>> #13: Server name check for certificate type 1 >>>> This addressed in draft-ietf-dane-protocol-12 in Sections 2.1, = 2.2, 2.3, >>>> most of section 4 and Appendix B. >>>=20 >>> I'm sorry I missed this when you sent out the call for comments. I = do not believe this issue has been adequately addressed in -12. In = particular, when the end-entity certificate matches a valid TLSA record = but does NOT contain embedded name information matching the hostname = under which the record was found, client behavior is unspecified. >>=20 >> We should specify it. What is your preference? >=20 > It would certainly be operationally convenient for a type-1 match to = override domain name information in the certificate (eliminate the need = for those horrible CDN certificates with dozens of hostnames in the = subjectAltName) but for backward compatibility's sake people are going = to have to keep doing that anyway, so I don't see a strong case either = way. >=20 > I suppose we could split the difference and say that a DANE-compliant = client MUST interpret a certificate with *no* embedded hostname = information as if it had had embedded hostname information corresponding = to the hostname where the TLSA record was, but SHOULD otherwise process = embedded hostname information as it would have in the absence of TLSA = records. >=20 > I'd like to hear from people who actually operate TLS servers at = scale, though. >=20 >>> (It's possible that you think "pass PKIX validation" covers this = case, but that term is ill-defined to the point where I think it needs = to be eradicated from the spec.) >>=20 >> It is defined in the PKIX specification. You may not like it, but = that's the standard. >=20 > The definition of "validation" in the PKIX specification is so = ambiguous that it is unusable. Please see = http://www.ietf.org/mail-archive/web/dane/current/msg03284.html and = http://www.ietf.org/mail-archive/web/dane/current/msg03285.html -- I = can't say it any better than Peter did. >=20 > zw > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From mrex@sap.com Wed Nov 9 14:43:15 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4464321F8491 for ; Wed, 9 Nov 2011 14:43:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.102 X-Spam-Level: X-Spam-Status: No, score=-10.102 tagged_above=-999 required=5 tests=[AWL=0.147, 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 S54RFjhq8pn6 for ; Wed, 9 Nov 2011 14:43:14 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8662B21F848F for ; Wed, 9 Nov 2011 14:43:14 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id pA9Mh5BK008731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 9 Nov 2011 23:43:06 +0100 (MET) From: Martin Rex Message-Id: <201111092243.pA9Mh5mc004793@fs4113.wdf.sap.corp> To: rbarnes@bbn.com (Richard Barnes) Date: Wed, 9 Nov 2011 23:43:05 +0100 (MET) In-Reply-To: <75129DA0-13D2-4E26-ACD3-C3F419DE42C4@bbn.com> from "Richard Barnes" at Nov 9, 11 05:21:18 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] #13: Server name check for certificate type 1 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 22:43:15 -0000 Richard Barnes wrote: > > I still disagree with this. Names are not considered at the > DANE/PKIX/TLS layer -- only the application considers the name. > This document should not place any constraints on what names should > or should not be in certificates. I strongly disagree. Matching of DNS names is an integral part of the security architecture of DANE, because the name is necessary in order to obtain the relevant DANE records. While you could use TLS with PKIX and arbitrary certs and use initial-leap-of-faith with cert-pinning (SSH-style) or out-of-band confirmation for server endpoint identification, and thus work without rfc2818 section 3.1 or rfc6125, this is impossible for DANE. -Martin From rbarnes@bbn.com Wed Nov 9 14:52: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 E14FE1F0C36 for ; Wed, 9 Nov 2011 14:52:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTdMD5oY-hA5 for ; Wed, 9 Nov 2011 14:52:44 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 73F161F0C34 for ; Wed, 9 Nov 2011 14:52:44 -0800 (PST) Received: from [128.89.254.48] (port=53534) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1ROH0a-0005wr-8t; Wed, 09 Nov 2011 17:52:40 -0500 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Richard Barnes In-Reply-To: <201111092243.pA9Mh5mc004793@fs4113.wdf.sap.corp> Date: Wed, 9 Nov 2011 17:52:39 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <91EDC182-2CC8-4B57-B451-8354B973956D@bbn.com> References: <201111092243.pA9Mh5mc004793@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1251.1) Cc: paul.hoffman@vpnc.org, dane@ietf.org Subject: Re: [dane] #13: Server name check for certificate type 1 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 22:52:45 -0000 >> I still disagree with this. Names are not considered at the >> DANE/PKIX/TLS layer -- only the application considers the name. >> This document should not place any constraints on what names should >> or should not be in certificates. =20 >=20 > I strongly disagree. >=20 > Matching of DNS names is an integral part of the security architecture > of DANE, because the name is necessary in order to obtain the relevant > DANE records. I certainly agree. The choice of domain name is critical. Hence the = suggestion at the bottom of my previous message, pasted here for your = convenience: OLD: " TLSA resource records are stored at a prefixed DNS domain name. " NEW: " The "source domain" for a TLS connection is the name that a client = expects a server to present in the TLS handshake. When a client wishes = to connect to a given source domain, it searches for TLSA records under = a special name formed by appending a prefix to the source domain. " That's the level at which we need to address domain names, not the = content of the certificate. --Richard= From mrex@sap.com Wed Nov 9 15:19: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 0A70811E809A for ; Wed, 9 Nov 2011 15:19:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.106 X-Spam-Level: X-Spam-Status: No, score=-10.106 tagged_above=-999 required=5 tests=[AWL=0.143, 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 mWU8+Nl0PhcN for ; Wed, 9 Nov 2011 15:19:35 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id D9D1311E809C for ; Wed, 9 Nov 2011 15:19:34 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id pA9NJRfH015837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 Nov 2011 00:19:27 +0100 (MET) From: Martin Rex Message-Id: <201111092319.pA9NJQwA007005@fs4113.wdf.sap.corp> To: rbarnes@bbn.com (Richard Barnes) Date: Thu, 10 Nov 2011 00:19:26 +0100 (MET) In-Reply-To: <91EDC182-2CC8-4B57-B451-8354B973956D@bbn.com> from "Richard Barnes" at Nov 9, 11 05:52:39 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] #13: Server name check for certificate type 1 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 23:19:36 -0000 Richard Barnes wrote: > > >> I still disagree with this. Names are not considered at the > >> DANE/PKIX/TLS layer -- only the application considers the name. > >> This document should not place any constraints on what names should > >> or should not be in certificates. > > > > I strongly disagree. > > > > Matching of DNS names is an integral part of the security architecture > > of DANE, because the name is necessary in order to obtain the relevant > > DANE records. > > I certainly agree. The choice of domain name is critical. > Hence the suggestion at the bottom of my previous message, > pasted here for your convenience: > > [...] > > That's the level at which we need to address domain names, not the > content of the certificate. Thinking about it, I might need to clarify and adjust my position about "PKIX validation" being unrelated to "server endpoint identification". While technically independent, there are certainly assumptions made on the part of the issuing CA and on the part of PKIX (at least those who still believe that Name Constraints are not a complete failure). If we allow skipping of the traditional server endpoint identification for type 1 certificates, then we would be actively creating new security problems and nullify the security value of commercial SSL certificates and the RA process behind it for TLS clients that implement DANE. Picture this: - a TLS client with the intention to connect to https://www.higlytrustedbank.x-z-z - being MiTMed by an attacker, who is in posession of a real server cert for https://www.realbadguy.x-y-y from a commercial CA. If we specify that traditional server endpoint matching is to be skipped when a DANE TLSA record for a type 1 certificate with a completely different server name exists, then we're completely subverting the original TLS X.509 PKI trust model for TLS clients that implement DANE. Personally, I really do _not_ like that idea. DANE adds value when both checks are performed. Doing the orginial (PKIX-based) server endpoint identification only half-assed IMHO renders the type 1 certificates useless. -Martin From rbarnes@bbn.com Wed Nov 9 19:46: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 C47191F0C3E for ; Wed, 9 Nov 2011 19:46:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0SQUZj+MBu2X for ; Wed, 9 Nov 2011 19:46:55 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 387D21F0C34 for ; Wed, 9 Nov 2011 19:46:55 -0800 (PST) Received: from [128.89.255.55] (port=53738) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1ROLbI-0009eW-6A; Wed, 09 Nov 2011 22:46:52 -0500 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Richard Barnes In-Reply-To: <201111092319.pA9NJQwA007005@fs4113.wdf.sap.corp> Date: Wed, 9 Nov 2011 22:46:51 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <03064DC5-77F7-4813-AF4C-517F0C107C1E@bbn.com> References: <201111092319.pA9NJQwA007005@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1251.1) Cc: paul.hoffman@vpnc.org, dane@ietf.org Subject: Re: [dane] #13: Server name check for certificate type 1 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 10 Nov 2011 03:46:55 -0000 >>>> I still disagree with this. Names are not considered at the >>>> DANE/PKIX/TLS layer -- only the application considers the name. >>>> This document should not place any constraints on what names should >>>> or should not be in certificates. =20 >>>=20 >>> I strongly disagree. >>>=20 >>> Matching of DNS names is an integral part of the security = architecture >>> of DANE, because the name is necessary in order to obtain the = relevant >>> DANE records. >>=20 >> I certainly agree. The choice of domain name is critical. >> Hence the suggestion at the bottom of my previous message, >> pasted here for your convenience: >>=20 >> [...] >>=20 >> That's the level at which we need to address domain names, not the >> content of the certificate. >=20 >=20 > Thinking about it, I might need to clarify and adjust my position = about > "PKIX validation" being unrelated to "server endpoint identification". >=20 > While technically independent, there are certainly assumptions made > on the part of the issuing CA and on the part of PKIX (at least those > who still believe that Name Constraints are not a complete failure). >=20 >=20 > If we allow skipping of the traditional server endpoint identification > for type 1 certificates, then we would be actively creating new > security problems and nullify the security value of commercial > SSL certificates and the RA process behind it for TLS clients that > implement DANE. >=20 >=20 > Picture this: > - a TLS client with the intention to connect to > https://www.higlytrustedbank.x-z-z > - being MiTMed by an attacker, who is in posession of > a real server cert for https://www.realbadguy.x-y-y > from a commercial CA. >=20 > If we specify that traditional server endpoint matching is to > be skipped when a DANE TLSA record for a type 1 certificate > with a completely different server name exists, then we're > completely subverting the original TLS X.509 PKI trust model > for TLS clients that implement DANE. >=20 > Personally, I really do _not_ like that idea. DANE adds value > when both checks are performed. Doing the orginial (PKIX-based) > server endpoint identification only half-assed IMHO renders > the type 1 certificates useless. Good point. I think we're in agreement here. Using the source domain = to locate TLSA records means you get both checks: -- Client only takes records from www.highlytrustedbank.x-z-z (due to = DANE) -- Client only accepts certs with name www.highlytrustedbank.x-z-z (due = to application) Since the various TLS-based applications already specify the latter, we = only need to address the former. --Richard From warren@kumari.net Sun Nov 13 02:37: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 ED52321F8B63 for ; Sun, 13 Nov 2011 02:37:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLPdaQxgZW-V for ; Sun, 13 Nov 2011 02:37:58 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 4069D21F8B5C for ; Sun, 13 Nov 2011 02:37:57 -0800 (PST) Received: from dhcp-172-30-214-228.tpe.corp.google.com (unknown [72.14.229.193]) by vimes.kumari.net (Postfix) with ESMTPSA id CE2BE1B40187; Sun, 13 Nov 2011 05:37:46 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: <03064DC5-77F7-4813-AF4C-517F0C107C1E@bbn.com> Date: Sun, 13 Nov 2011 18:37:44 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201111092319.pA9NJQwA007005@fs4113.wdf.sap.corp> <03064DC5-77F7-4813-AF4C-517F0C107C1E@bbn.com> To: Richard Barnes X-Mailer: Apple Mail (2.1084) Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] #13: Server name check for certificate type 1 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 13 Nov 2011 10:37:59 -0000 Ok, I am going to be re-closing this issue as I think this has been = cleared up.. As a process point the chairs ask that folk do not reopen issues = themselves -- if you feel that consensus was not correctly judged, or = that an issue was not fully addressed (or was misunderstood), please = feel free to let us know and we'll re-evaluate / poll the WG, etc=85=20 W On Nov 10, 2011, at 11:46 AM, Richard Barnes wrote: >>>>> I still disagree with this. Names are not considered at the >>>>> DANE/PKIX/TLS layer -- only the application considers the name. >>>>> This document should not place any constraints on what names = should >>>>> or should not be in certificates. =20 >>>>=20 >>>> I strongly disagree. >>>>=20 >>>> Matching of DNS names is an integral part of the security = architecture >>>> of DANE, because the name is necessary in order to obtain the = relevant >>>> DANE records. >>>=20 >>> I certainly agree. The choice of domain name is critical. >>> Hence the suggestion at the bottom of my previous message, >>> pasted here for your convenience: >>>=20 >>> [...] >>>=20 >>> That's the level at which we need to address domain names, not the >>> content of the certificate. >>=20 >>=20 >> Thinking about it, I might need to clarify and adjust my position = about >> "PKIX validation" being unrelated to "server endpoint = identification". >>=20 >> While technically independent, there are certainly assumptions made >> on the part of the issuing CA and on the part of PKIX (at least those >> who still believe that Name Constraints are not a complete failure). >>=20 >>=20 >> If we allow skipping of the traditional server endpoint = identification >> for type 1 certificates, then we would be actively creating new >> security problems and nullify the security value of commercial >> SSL certificates and the RA process behind it for TLS clients that >> implement DANE. >>=20 >>=20 >> Picture this: >> - a TLS client with the intention to connect to >> https://www.higlytrustedbank.x-z-z >> - being MiTMed by an attacker, who is in posession of >> a real server cert for https://www.realbadguy.x-y-y >> from a commercial CA. >>=20 >> If we specify that traditional server endpoint matching is to >> be skipped when a DANE TLSA record for a type 1 certificate >> with a completely different server name exists, then we're >> completely subverting the original TLS X.509 PKI trust model >> for TLS clients that implement DANE. >>=20 >> Personally, I really do _not_ like that idea. DANE adds value >> when both checks are performed. Doing the orginial (PKIX-based) >> server endpoint identification only half-assed IMHO renders >> the type 1 certificates useless. >=20 > Good point. I think we're in agreement here. Using the source domain = to locate TLSA records means you get both checks: > -- Client only takes records from www.highlytrustedbank.x-z-z (due to = DANE) > -- Client only accepts certs with name www.highlytrustedbank.x-z-z = (due to application) >=20 > Since the various TLS-based applications already specify the latter, = we only need to address the former. >=20 > --Richard >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 From warren@kumari.net Sun Nov 13 02:46: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 2684021F8B77 for ; Sun, 13 Nov 2011 02:46:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpElt-ZdAZc9 for ; Sun, 13 Nov 2011 02:46:35 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id A375D21F8B75 for ; Sun, 13 Nov 2011 02:46:35 -0800 (PST) Received: from dhcp-172-30-214-228.tpe.corp.google.com (unknown [72.14.229.193]) by vimes.kumari.net (Postfix) with ESMTPSA id F0D3E1B40032; Sun, 13 Nov 2011 05:46:34 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: <070.b33acc5d8289801bd9fe723f43a43378@trac.tools.ietf.org> Date: Sun, 13 Nov 2011 18:46:33 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <194D2F2C-823B-46F2-9BFA-9214B0CC0075@kumari.net> References: <055.1026e2cada5be186d7270ba0ee6f1627@trac.tools.ietf.org> <070.b33acc5d8289801bd9fe723f43a43378@trac.tools.ietf.org> To: IETF DANE WG list X-Mailer: Apple Mail (2.1084) Subject: Re: [dane] #6: Downgrade attacks : What to do if DANE fails X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 13 Nov 2011 10:46:36 -0000 We would like to get the working groups feedback on if they feel that = this is unclear (and proposed text changes if so=85) On Nov 9, 2011, at 12:58 PM, dane issue tracker wrote: > #6: Downgrade attacks : What to do if DANE fails >=20 > Changes (by matt@=85): >=20 > * status: closed =3D> reopened > * resolution: worksforme =3D> >=20 >=20 > Comment: >=20 > I hate to reopen this again (and I apologize for missing the deadline = of > Friday), but the essential issue that I mentioned in comment:2 is not > addressed in Section 4.4 or Appendix B, and only obliquely if at all = in > Section 1.2. Do we state that a client MUST fail the TLS handshake if = it > cannot get a secure or verified insecure response to the TLSA query? = If > we do not make this requirement, clients could leave themselves open = to a > trivial TLSA stripping attack that defeats any restrictive semantics = DANE > might provide. DNSSEC provides protection against stripping of resource records (like = TLSA) - this is fundamental to the security of DNSSEC. The parent says that a subdomain is signed, and then all of the records = within that domain are signed (or you have explicit information that = something isn't signed / doesn't exist). W > I understand we may want to leave room for local policy, > but I'd argue that this requirement should have the same strength as = the > last MUST in section 4.4, because it is the conjunction of the two > requirements that provides secure restriction. >=20 > --=20 > --------------------------------+----------------------- > Reporter: mlepinsk@=85 | Owner: > Type: defect | Status: reopened > Priority: major | Milestone: > Component: protocol | Version: > Severity: Active WG Document | Resolution: > Keywords: | > --------------------------------+----------------------- >=20 > Ticket URL: = > dane >=20 From ietf@meetecho.com Sun Nov 13 05:34: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 5471121F8B66 for ; Sun, 13 Nov 2011 05:34:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHGIb5it4WJt for ; Sun, 13 Nov 2011 05:34:26 -0800 (PST) Received: from smtpw2.aruba.it (smtpipvs3.aruba.it [62.149.128.188]) by ietfa.amsl.com (Postfix) with SMTP id 29AC921F8B63 for ; Sun, 13 Nov 2011 05:34:25 -0800 (PST) Received: (qmail 6477 invoked by uid 89); 13 Nov 2011 13:34:24 -0000 Received: from unknown (HELO aruba.it) (62.149.158.90) by smtpw2.ad.aruba.it with SMTP; 13 Nov 2011 13:34:24 -0000 Date: Sun, 13 Nov 2011 14:34:24 +0100 Message-Id: MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: "Meetecho IETF support" To: dane@ietf.org X-XaM3-API-Version: V3(R2) X-SenderIP: 130.129.21.177 X-Spam-Rating: smtpw2.ad.aruba.it 1.6.2 0/1000/N Subject: [dane] Meetecho support for DANE WG meeting session X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 13 Nov 2011 13:34:27 -0000 Hi all,=0A=0Aa virtual room has been reserved on the Meetecho system for = tomorrow DANE WG meeting session.=0A=0AAccess to the on-line session (inc= luding audio and video streams) will be available from 9:00am at:=0Ahttp:= //www.meetecho.com/ietf82/dane=0A=0AThe Meetecho session automatically lo= gs you into the standard IETF jabber room. So, from there, you can have a= n integrated experience involving all media and allowing you to interact = with the room.=0A=0AA tutorial of interactivity features of the tool can = be found at:=0Ahttp://www.meetecho.com/ietf82/tutorials=0A=0AFor further = information you can contact us at ietf-support@meetecho.com.=0A=0ACheers,= =0Athe Meetecho team=0A=C2=A0=0A--=0AMeetecho s.r.l.=0AWeb Conferencing a= nd Collaboration Tools=0Awww.meetecho.com=0A=C2=A0 From trac+dane@trac.tools.ietf.org Sun Nov 13 07:47: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 8695D21F88B7 for ; Sun, 13 Nov 2011 07:47:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJSsB1OuHBB7 for ; Sun, 13 Nov 2011 07:47:45 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id A106E21F861E for ; Sun, 13 Nov 2011 07:47:23 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RPcHB-00025i-3e; Sun, 13 Nov 2011 10:47:21 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: matt@mattmccutchen.net, warren@kumari.net X-Trac-Project: dane Date: Sun, 13 Nov 2011 15:47:20 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/13#comment:4 Message-ID: <070.c1531214bc0de314d999f822033071c3@trac.tools.ietf.org> References: <055.95ec24e5e3679207360dec78550e2dcb@trac.tools.ietf.org> X-Trac-Ticket-ID: 13 In-Reply-To: <055.95ec24e5e3679207360dec78550e2dcb@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] #13: Hostnames in 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: Sun, 13 Nov 2011 15:47:45 -0000 #13: Hostnames in Certificates Changes (by warren@…): * status: reopened => closed * resolution: => worksforme Comment: See: http://www.ietf.org/mail-archive/web/dane/current/msg03739.html -- --------------------------------+------------------------- Reporter: mlepinsk@… | Owner: Type: defect | Status: closed Priority: minor | Milestone: Component: protocol | Version: Severity: Active WG Document | Resolution: worksforme Keywords: | --------------------------------+------------------------- Ticket URL: dane From ekr@rtfm.com Sun Nov 13 16:52: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 1BE7221F86A0 for ; Sun, 13 Nov 2011 16:52:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.935 X-Spam-Level: X-Spam-Status: No, score=-102.935 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FbRHUogEinqQ for ; Sun, 13 Nov 2011 16:52:26 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 946DA21F8483 for ; Sun, 13 Nov 2011 16:52:26 -0800 (PST) Received: by yenq4 with SMTP id q4so2759929yen.31 for ; Sun, 13 Nov 2011 16:52:25 -0800 (PST) Received: by 10.146.25.2 with SMTP id 2mr2525081yay.20.1321231945088; Sun, 13 Nov 2011 16:52:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.146.88.36 with HTTP; Sun, 13 Nov 2011 16:51:44 -0800 (PST) X-Originating-IP: [74.95.2.173] From: Eric Rescorla Date: Sun, 13 Nov 2011 16:51:44 -0800 Message-ID: To: dane@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [dane] Clarity in S 4 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 14 Nov 2011 00:52:27 -0000 I've just read draft-ietf-dane-protocol-09 and I'm not finding S 4.4 as clear as one might like. In particular, it's not clear to me whether the checks prescribed here replace the PKIX checks or are added to the PKIX checks. Based on S 4.2, it appears to be the case that it depends on the reference type? Here's what I *think* this document says (ignoring the issue of the SAN/CN check): - With certificate type 1, the certificate is accepted iff the terminal certificate matches the TLSA RR. Specifically, PKIX verification is not done. - With certificate type 2, there are two cases: + With reference type 0, the certificate is accepted iff the terminal cert chains to the the cert in the TLSA record. + With reference type != 0, the certificate is accepted if the terminal cert chains to the cert in the TLSA record *or* if it would otherwise chain to an existing trust anchor - With certificate type 3, the certificate is accepted iff the public key in the TLSA record appears in one of the certificates received from the server. [*] This is true regardless of whether the certificate chains to an existing trust anchor? Is this interpretation correct? -Ekr [*] Note that this is probably too loosely worded in that it does not appear to require any check of the chain proper, leaving open the possibility that the terminal cert does not acually chain to the matching cert, which is especially relevant as some TLS stacks will process certs received out of order. From Jeff.Hodges@KingsMountain.com Sun Nov 13 22:37: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 6C29C1F0C88 for ; Sun, 13 Nov 2011 22:37:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.495 X-Spam-Level: X-Spam-Status: No, score=-100.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7v6SkMBkTGVj for ; Sun, 13 Nov 2011 22:37:09 -0800 (PST) Received: from oproxy4-pub.bluehost.com (oproxy4.bluehost.com [IPv6:2605:dc00:100:2::a4]) by ietfa.amsl.com (Postfix) with SMTP id 233601F0C5F for ; Sun, 13 Nov 2011 22:37:09 -0800 (PST) Received: (qmail 29239 invoked by uid 0); 14 Nov 2011 06:37:08 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy1.bluehost.com with SMTP; 14 Nov 2011 06:37:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=WMWK9Vj184kkedRA1wfJiYYwQJnUoH9m+sbin87yE+s=; b=oZcb0ybkapj7CUGUT9t3DOGZrT0J9dXP4NTTCOm5WRISjhuFSmN7oTfbpoz/LTNcolX1Gs7iOWO7RD+W4VwqQ+QuIZPvGWtfcnAGGdeOklypnGqFO12RxSrocAPjFkkU; Received: from dhcp-67bb.meeting.ietf.org ([130.129.103.187]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1RPqAF-0006QX-GW for dane@ietf.org; Sun, 13 Nov 2011 23:37:08 -0700 Message-ID: <4EC0B710.4020509@KingsMountain.com> Date: Sun, 13 Nov 2011 22:37:04 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: IETF DANE WG list Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 130.129.103.187 authed with jeff.hodges+kingsmountain.com} Subject: [dane] unedited raw ietf-82 taipei DANE minutes X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 14 Nov 2011 06:37:10 -0000 exported from: https://tools.ietf.org/wg/dane/minutes at approx 22:35h PST Sunday, November 13 2011 [ not sure who the minute-taker was. these are distinct from jabber room log ] ### MONDAY, November 14, 2011 - 0900-1130 Morning Session I 101C DNS-based Authentication of Named Entities WG Administrivia (Presented by Chairs) http://www.ietf.org/proceedings/82/slides/dane-1.pdf ------------ Agenda Bashing : No comments on Agenda Plan for the Meeting (Presented by Warren Kumari) http://www.ietf.org/proceedings/82/slides/dane-0.pdf ------------ No comments on plan for today's meeting Working the Open Issues (Presented by Richard Barnes) http://www.ietf.org/proceedings/82/slides/dane-2.pdf ------------ See list for Recently Closed Issued. This presentation will only cover op= en=20 issues. All decisions made at this meeting will be double-checked on the = list. Issue #23 Idea: Use DANE to assert that no TLS services exist at specified host and= port Proposal: Defer to a separate document, don't address in the base specifi= cation *** No objections to the proposed resolution Andrew Sullivan: Is this committing the working group to write a second d= raft?=20 Do we have a volunteer to write a new draft? Or are we deciding to do not= hing=20 (for now) and is everyone okay with that? PHB: This is not something DANE should do. There are other groups working= on this. Tim Polk: We can table the issue for this draft without having a voluntee= r (or=20 a definite decision) for a future draft. *** CONCLUSION: Do nothing in the protocol document Issue #37 Idea: Add a usage to assert a self-signed server certificate directly Proposal: Make no change to the core specification. This use-case can be = covered via usage 2. *** Alex Mayrhofer : I think this would make things easier for some people us= ing=20 self-signed certs Richard Barnes: We could add an example to the document showing how to us= e=20 usage 2 to address this use-case EKR: Doesn't what Richard says require PKIX validation Richard: Yes, there does need to be PKIX validation for usage 2, you can'= t just=20 do byte-wise comparison EKR: This sounds a lot more complicated Alex M: I kind of agree with EKR. Let's go with direct certificate associ= ation=20 to make this as simple as possible. This is a usability issue. Steve Kent: There is code for PKIX validation that is currently available= =2E This=20 code can just be re-used to do usage 2 of DANE. PHB: This is all a lot more critical if there is no choice about the excl= usivity Richard B: There is a requirement in the use-cases that you should be abl= e to=20 do this with a minimum of key management. The current document text does = not=20 require two key pairs (it just requires two certificates). Jim Schaad: I am lost as to why this needs to be a separate certificate? Richard B: The question is whether existing software stacks can do this u= sage 2=20 with only one certificate. There was some lack of clarity on the list wit= h=20 regards to what can be done with existing software stacks. Bill Manning : I think this is a useful thing to have in the stack, regar= dless=20 of whether we actually decide to deploy this. Code points are not scarce.= Paul Wouters: There will be a case (eg bare public key cert_type) that wi= ll not=20 have anything of a PKIX TA. Make sure that's clear to implement Richard B: If we support bare public keys in the future, we will probably= need=20 a new usage. *** CONCLUSION: After hum, there is no clear results, we will open a big disc= ussion=20 of this on the list. Issue # 38 Idea: Enable support for DANE within EAP-FAST Proposal: Do nothing in the protocol specification. *** No objects to this proposal *** CONCLUSION: Do nothing in the protocol document Issue # 8 Idea: What about DNSSEC last mile? Proposal: Add a note to the security considerations. Note the problem and= =20 possible existing solutions. *** Stephen AD: Somewhere it needs to be explained how to do this. It can be = done=20 by reference, but there needs to be an explanation of how to do this. Paul H: Can we do a null pointer? We don't currently have anything to poi= nt to=20 and we are probably the wrong people to write this. Stephen AD: It needs to be clear how to solve the last mile problem. Paul H: Is this going to hold up the current document? Stephen AD: I believe that this is one of things that the working group t= ook on=20 as part of the problem that the working group agreed to solve. Andrew S: Are you suggesting that we give DNS operational advice as one o= f the=20 products of this working group? I'm not convinced that this working group= has=20 the expertise to provide operational advice for DNS. Olafur Gudmundsson: We have an RFC 3655 that is attempting to answer this= last=20 mile issue. Read that document. If it is not good enough for your purpose= s then=20 we should revisit that document, but we put a lot of effort into that doc= ument=20 and I think it is good. Russ Mundy: Are you including API issues in what this working group needs= to do? Stephen AD: No Bill Manning: Is there ever a reason to use DANE without "high assurance"= ? Richard B: The use of "High assurance" is just slide text, its not in the= =20 document. There is another issue later on with regards to use of DANE wit= hout=20 DNSSEC. *** CONCLUSION: We take to the list proposed text to add to Security Consider= ations Issue #10 Idea: DANE (usage 2) could conflict with PKIX information about intermedi= ate=20 CAs (especially with regards to revocation). Proposed action: This is a property of usage 2 of DANE. Add a paragraph t= o the=20 Security Considerations to note this. *** PHB: If a Cert has an OCSP declared then a client needs to check it DANE = or no=20 DANE. EKR: Revocation seems fine to ignore here. If DANE says the TA is okay, t= hen we=20 should be trusting DANE. Bill Manning: We have two conflicting options for certificate validation.= We=20 need clear text (in security considerations) explaining the conflict and = the=20 resolution of which security regime wins when there is a conflict (and wh= y). Richard B: The document will say that PKIX wins Alex M: Does DANE have the authority to over-ride existing PKIX validatio= n rules? Paul H: Yes, DANE over-rides existing PKIX validition in other cases, the= case=20 described in this issue is the only case where a lack of clarity exists. = We=20 propose to clarify (in security considerations). Tim Polk: This type of possibility already exists in PKIX when you have=20 multiple TAs. What is being proposed is not a radical departure from PKIX= =2E EKR: Why do we care if some irrelevant third-party doesn't like a certifi= cate. PHB: Do we really want to give the Iranian Revolutionary Guard a way to b= reak=20 revocation of the intermediate cert in a DigiNotar type situation? Bill Manning: Yes, we want control locally. Paul Hoffman: We, the document authros will cycle some proposed text on t= he=20 mailing list before putting it in a future version of the draft. *** CONCLUSION: We will add clarifying text to security considerations as pro= posed. Issue: #36 Idea: Remove the restriction that all TLSA records MUST have DNSSEC prote= ction Proposed action: Add to "client processing" text that specifies behaivor = in all=20 DNSSEC validation cases *** Peter Koch: Your diagram on the slide seems to be missing a branch. In=20 particular, you do not seem to handle authenticated denial of existence. PHB: I think that it is reasonable to state that anyone publishing DANE r= ecords=20 MUST sign them with DNSSEC or else be ignored. However the only requireme= nt on=20 the client should be that it authenticates the data by some means that ma= y=20 include DNSSEC but may use a mechanism such as a secure tunnel to a trust= ed=20 resolver. Paul Wouters: Unsigned dnssec tlsa record is the same as non-dnssec aware= =20 client. The state for both is "indeterminate" and not "insecure" Warren Kumari: It may be useful to think of different classes of attacker= =2E You=20 might conceivably have an attacker who can only monkey with bits to the s= erver=20 and not monkey with bits to DNS ... in which case insecure DNS records co= uld=20 actually be useful. Warren Kumari: Not every client can do DNSSEC and not every zone is capab= le of=20 doing DNSSEC that chains to the global root. This is most useful because = it can=20 start being done tomorrow. Peter Koch: There are different reasons why DNSSEC might not be available= to=20 the client. Operationally this seems bad. If I operate a DNSSEC signed zo= ne,=20 then I need to be able to understand the behaivor of the client is. Russ Mundy: It becomes incredibly hard to do any analysis with any degree= of=20 precision, once you move away from fully DNSSEC validated. Warren Kumari: This has only been proposed for the "Ristrictive" DANE usa= ge.=20 You would not do this for the "Permissive" DANE use-case. Richard Barnes: Actually, Warren, I think that is still an open question.= Paul Hoffman: Who are you trying to give assurance to? Are we telling a z= one=20 owner "If you publish this, you get this result". Or are we telling a cli= ent=20 "If you get this, here is what it means". If the answer comes back=20 "Indeterminate", who are we trying to protect. The second option on the s= lide=20 will confuse a lot of people, because we don't give assurance to anyone. = (Although as Richard pointed out to me over the weekend, doing anything e= xcept=20 the second option will have bad results in some cases). EKR: As I was saying earlier on jabber chat, my position is that if you h= ave=20 unsecured (i.e., not obviously bogus) information from DNS that suggests = that a=20 given TLS cert is invalid, you ought not to be accepting that cert. Olafur G: On the publishing side, DNSSEC is mandatory. On the client side= , if=20 you don't get DNSSEC you fall back to something (determined locally). Warren Kumari: Allowing clients to use non-DNSSEC secure DANE information= in=20 the "Restrictive" usage seems to open up no new Tim Polk: This seems like scope creep. This is the kind of issue that cau= ses=20 you to rat hole and not get a document done. DANE's job is to specify wha= t=20 happens in the case when information is delivered securely. Clients will = figure=20 out what they want to do in other cases. Eric Osterwiel: I think we are slipping down the slope of "What constitut= es a=20 secure DNS record". That's not the job of DANE. Articulating the second o= ption=20 of 'Insecure+/-' will cause us to lose the transparency that is one of th= e=20 great benefits of DANE. Peter Koch: I think we have a hard time mandating that on the publishing = side=20 that DNSSEC must be used. What does that even mean? If I sign my zone but= don't=20 register keying material with my parent zone, have a complied with the=20 specification? We do not want to create a situation where both parties ca= n=20 point at each other "e.g., I did not sign, but you should have been liber= al in=20 what you accepted". PHB: If you are telling people to trust this key ("Permissive" usage) the= n you=20 need DNSSEC. In the other usage you don't need DNSSEC. Bill Manning: Note that DNSSEC state is fluid. A client could get a "secu= re"=20 response one minute and an "indeterminate" or "insecure" response the nex= t=20 minute, and then "secure" again 15 minutes later. It is inappropriate to = dictate DNS operations from DANE. Listen to Tim Polk. Paul Hoffman: There exist people in the room who have changed their mind = in the=20 last 15 minutes. In the next weeks or month, people need to not be afraid= to=20 say on the list that you have changed your mind. Paul Hoffman: If you believe that this is not the right chart to be looki= ng at=20 =2E. then please send art to the list. Jeff Hodges: An actual diagram or state table would be very helpful. *** CONCLUSION: Authors will try to create some candidate text that describes= the=20 process shown on the diagram, leaving blank [or calling out] the parts wh= ere it=20 is not clear what the client should do. Future of Dane (Presented by Chairs) http://www.ietf.org/proceedings/82/slides/dane-3.pdf ------------ Question: Does the working group need an Operational Document? Or is the = operations-related text in the current protocol docuemnt sufficient? *** No one claims that the current text in the protocol document is insuffice= nt. *** Ondrej : If you think we need an operational document but you are afraid = that=20 you will be forced to volunteer to write it, then send a message to the l= ist=20 from a new email address. Proposal: Once the protocol is done we go into haitus, and see after like= half=20 a year whether there is sufficient interest/energy to take on additional = work. *** Paul Hoffman: I am happy to help work on IPsec and S/MIME, but I am happy= to=20 put off this work until later. However, I think it is inappropriate for u= s to=20 go to haitus until we have done work on Bare Keys (note that this might b= e=20 joint work with the TLS WG). I would be happy to co-author a bare keys do= cument=20 with Paul W. Andrew S: Vote for shutting down instead of haitus. DNS-related working g= roup=20 should not go into haitus, we do not want this to live forever. Sean Turner: Would like to see S/MIME done. Open Mic -------- Olafur G: The current protocol document says that they will submit the TL= SA=20 record type for expert review. Is the protocol stable enough to have that= review? Richard Barnes: I believe that it is stable enough for expert review. The= re has=20 been only one recent proposal for changing bits on the wire, and I think = that=20 is going to resolved soon on the list. Peter Koch: Formally, because this is standards track we should not forma= lly=20 require expert review (for standards track we trust the wisdom of the IES= G). EKR: Please clarify Section 4. (EKR sent comments to the list) EKR: I am also concerned about this bit where it requires that a specific= TLS=20 alert be sent. I sent extensive comments about that a while ago=85 Paul H: We picked a specific TLS error code out of thin air. EKR has opin= ions,=20 other people probably also have opinions ... please discuss this on the l= ist. Andrew S: The expert review process can take a while, please submit for e= xpert=20 review as soon as the wire format is settled. (You could possibly change = wire=20 format after expert review, but please do not) Warren [as Chair]: Please do not re-open previously closed issues on the = list.=20 If you do not agree with the consensus or believe the issue was not close= d=20 properly or that consensus was not actually reached, please contact the c= hairs=20 off-list. ### From bortzmeyer@nic.fr Mon Nov 14 03:04: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 BA3CC1F0C72 for ; Mon, 14 Nov 2011 03:04:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.249 X-Spam-Level: X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, 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 sNOGi3xz78d5 for ; Mon, 14 Nov 2011 03:04:02 -0800 (PST) Received: from mx2.nic.fr (mx2.nic.fr [IPv6:2001:660:3003:2::4:11]) by ietfa.amsl.com (Postfix) with ESMTP id DF7EC1F0C43 for ; Mon, 14 Nov 2011 03:04:00 -0800 (PST) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id CAE561C00F3; Mon, 14 Nov 2011 12:03:57 +0100 (CET) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx2.nic.fr (Postfix) with ESMTP id C63141C0016; Mon, 14 Nov 2011 12:03:57 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.6.69]) by relay1.nic.fr (Postfix) with ESMTP id BAA3A568125; Mon, 14 Nov 2011 12:03:57 +0100 (CET) Date: Mon, 14 Nov 2011 12:03:57 +0100 From: Stephane Bortzmeyer To: Eric Rescorla Message-ID: <20111114110357.GA23137@nic.fr> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux wheezy/sid X-Kernel: Linux 3.0.0-1-686-pae i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.21 (2010-09-15) Cc: dane@ietf.org Subject: Re: [dane] Clarity in S 4 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 14 Nov 2011 11:04:02 -0000 On Sun, Nov 13, 2011 at 04:51:44PM -0800, Eric Rescorla wrote a message of 44 lines which said: > I've just read draft-ietf-dane-protocol-09 The current version is -12 and the numbers of certificate types are not the same... The document is now so different it is probably better to restart from -12. From ekr@rtfm.com Mon Nov 14 03:07: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 36FF31F0C84 for ; Mon, 14 Nov 2011 03:07:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.938 X-Spam-Level: X-Spam-Status: No, score=-102.938 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0w-NXL7s6rM for ; Mon, 14 Nov 2011 03:07:05 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 927861F0C72 for ; Mon, 14 Nov 2011 03:07:05 -0800 (PST) Received: by ggnr5 with SMTP id r5so831956ggn.31 for ; Mon, 14 Nov 2011 03:07:05 -0800 (PST) Received: by 10.236.195.4 with SMTP id o4mr14238352yhn.6.1321268825203; Mon, 14 Nov 2011 03:07:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.146.88.36 with HTTP; Mon, 14 Nov 2011 03:06:23 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: <20111114110357.GA23137@nic.fr> References: <20111114110357.GA23137@nic.fr> From: Eric Rescorla Date: Mon, 14 Nov 2011 03:06:23 -0800 Message-ID: To: Stephane Bortzmeyer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dane@ietf.org Subject: Re: [dane] Clarity in S 4 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 14 Nov 2011 11:07:06 -0000 On Mon, Nov 14, 2011 at 3:03 AM, Stephane Bortzmeyer wr= ote: > On Sun, Nov 13, 2011 at 04:51:44PM -0800, > =A0Eric Rescorla wrote > =A0a message of 44 lines which said: > >> I've just read draft-ietf-dane-protocol-09 > > The current version is -12 and the numbers of certificate types are > not the same... > > The document is now so different it is probably better to restart from > -12. > Oops. Don't know how I screwed that up. Will reread. From ietf@meetecho.com Tue Nov 15 05:45: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 30E3B11E813F for ; Tue, 15 Nov 2011 05:45:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FTny21VgK3fn for ; Tue, 15 Nov 2011 05:45:29 -0800 (PST) Received: from smtpw1.aruba.it (smtpipvs3.aruba.it [62.149.128.188]) by ietfa.amsl.com (Postfix) with SMTP id 1DDB411E8113 for ; Tue, 15 Nov 2011 05:45:28 -0800 (PST) Received: (qmail 16965 invoked by uid 89); 15 Nov 2011 13:45:27 -0000 Received: from unknown (HELO aruba.it) (62.149.158.90) by smtpw1.ad.aruba.it with SMTP; 15 Nov 2011 13:45:27 -0000 Date: Tue, 15 Nov 2011 14:45:27 +0100 Message-Id: MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: "Meetecho IETF support" To: dane@ietf.org X-XaM3-API-Version: V3(R2) X-SenderIP: 130.129.21.177 X-Spam-Rating: smtpw1.ad.aruba.it 1.6.2 0/1000/N Subject: [dane] DANE session recording available X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 Nov 2011 13:45:30 -0000 Dear all,=0A=0Athe full recording (synchronized video, audio, slides and = jabber room)=0Aof yesterday's DANE session is available.=0A=0AYou can wat= ch it by either clicking the proper link on the remote participation page= (http://www.ietf.org/meeting/82/remote-participation.html#Meetecho), or = by directly accessing the following URL:=0Ahttp://www.meetecho.com/ietf82= /recordings=0A=0AFor the chair(s): please feel free to put the link to th= e recording in the minutes, if you think this might be useful.=0A=0AIn ca= se of problems with the playout, just drop an e-mail to=0Aietf-support@me= etecho.com.=0A=0APlease keep in mind that the video quality is far from o= ptimal for this recording, since yesterday the room was too dark. Further= more, there is a 5 minutes gap in the audio recording due to the temporar= y disconnection of the mixer laptop (which was not yet on the wired IETF = network).=0A=0ACheers,=0Athe Meetecho Team=0A =0A--=0AMeetecho s.r.l.=0AW= eb Conferencing and Collaboration Tools=0Awww.meetecho.com=0A=C2=A0 From ogud@ogud.com Tue Nov 15 14: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 B900121F8512 for ; Tue, 15 Nov 2011 14:34:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.572 X-Spam-Level: X-Spam-Status: No, score=-106.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 QeTwgss38TAy for ; Tue, 15 Nov 2011 14:34:04 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8F921F8511 for ; Tue, 15 Nov 2011 14:34:01 -0800 (PST) Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id pAFMXwGR048033 for ; Tue, 15 Nov 2011 17:34:00 -0500 (EST) (envelope-from ogud@ogud.com) Message-ID: <4EC2E8CA.1060009@ogud.com> Date: Wed, 16 Nov 2011 06:33:46 +0800 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: dane@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Subject: [dane] Scope of the protocol document or plea for progress X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 Nov 2011 22:34:08 -0000 Dear colleagues, I'm getting worried that the WG is falling off the tracks, it is getting distracted by trying to address every possible corner case. I want to propose that the Current protocol document explicitly only cover the following case: Target zone is DNSSEC signed [1] and Consumer performs DNSSEC validation [2] and Target zone can be validated by the consumer. In this case there are two positive outcomes: - Validated TLSA RRset - Proof that the TLSA RRset does not exist and one Negative outcome: - TLSA RRset fails validation The document should say what the Consumer application does in each one of these cases for each type TLSA of record i.e. if there is need to check revocation lists, etc. For the other cases we just say "The consumer application falls back to the processing it is currently doing". This is the 98% solution and the faster we can start deploying it the better off we are!!!! A subsequent document can address the transition cases i.e. when DNSSEC validation can not succeed due to: Breaks in trust chain Algorithm mismatch Unsigned publisher zone No Validating resolver available DNSSEC records not getting through timeouts Incomplete Trust Chain etc. I would call this document "Value of TLSA records when DNSSEC validation is not available". I feel that using words like "DNS optional" does nothing but confuse both potential publishers and consumers of TLSA records as well as the implementors. I want to thank Richard Barnes for forcing me to think though the implications of his incomplete flow chart on the document. [3] My subsequent flowchart takes multiple pages and is not yet complete, thus I think any document that tries to address those issues will take a long time to write. Conversely writing such a document will be much easier if the positive cases are taken out of it. Comments Olafur [1] Target zone is the zone the name of the service resides in, i.e. the name _443._tcp.gmail.com is in gmail.com or _tcp.gmail.com. [2] Consumer has a DNSSEC capable validator that she/he trusts the answer from. [3] http://tools.ietf.org/agenda/82/slides/dane-2.pdf slide 9. From paul@xelerance.com Tue Nov 15 17:52: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 3FF0911E8166 for ; Tue, 15 Nov 2011 17:52:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.563 X-Spam-Level: X-Spam-Status: No, score=-6.563 tagged_above=-999 required=5 tests=[AWL=0.036, 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 MpN5U8orv4ei for ; Tue, 15 Nov 2011 17:52:10 -0800 (PST) Received: from mx.xelerance.com (mx.xelerance.com [193.110.157.188]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0C211E8169 for ; Tue, 15 Nov 2011 17:52:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx.xelerance.com (Postfix) with ESMTP id 972097F8; Tue, 15 Nov 2011 20:52:07 -0500 (EST) 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=1321408326; x= 1322013126; bh=ISKFwz9CTVxYrOxZaDpwxONElhmlmtSCHB4MAvk8mqA=; b=V 25pK9StVD8JYq0d8cFD4SzIH4QHGf+wq+8fIkKbarQmY3VwScLPmWQwmE9blceLa 1i1GPBotOBgfYiQHU11DV1ffDeXbru9shpOq4FthF3YyzJePrx6F+UsTK2MSs4ie 7RxlPcJGjXITO2pVi009Guwn8uQ1k91huJNi6vGPRE= 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 r1BW-hfYg9CG; Tue, 15 Nov 2011 20:52:06 -0500 (EST) 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 AA6C965; Tue, 15 Nov 2011 20:52:06 -0500 (EST) Received: by mail.xelerance.com (Postfix, from userid 1001) id 495C5554; Tue, 15 Nov 2011 20:52:06 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.xelerance.com (Postfix) with ESMTP id 4138A553; Tue, 15 Nov 2011 20:52:06 -0500 (EST) Date: Tue, 15 Nov 2011 20:52:06 -0500 (EST) From: Paul Wouters To: Olafur Gudmundsson In-Reply-To: <4EC2E8CA.1060009@ogud.com> Message-ID: References: <4EC2E8CA.1060009@ogud.com> 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] Scope of the protocol document or plea for progress X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Nov 2011 01:52:26 -0000 On Wed, 16 Nov 2011, Olafur Gudmundsson wrote: > I'm getting worried that the WG is falling off the tracks, it is > getting distracted by trying to address every possible corner case. > > I want to propose that the Current protocol document explicitly only cover > the following case: > Target zone is DNSSEC signed [1] > and Consumer performs DNSSEC validation [2] > and Target zone can be validated by the consumer. > > In this case there are two positive outcomes: > - Validated TLSA RRset > - Proof that the TLSA RRset does not exist > > and one Negative outcome: > - TLSA RRset fails validation > > The document should say what the Consumer application does in each one of > these cases for each type TLSA of record i.e. if there is need to check > revocation lists, etc. > > For the other cases we just say "The consumer application falls back to the > processing it is currently doing". Fully agree! Paul From Antoin.Verschuren@sidn.nl Tue Nov 15 18:19: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 71B1621F8E44 for ; Tue, 15 Nov 2011 18:19:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.76 X-Spam-Level: X-Spam-Status: No, score=-3.76 tagged_above=-999 required=5 tests=[AWL=0.744, 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 8QWK2knTiuA6 for ; Tue, 15 Nov 2011 18:19:32 -0800 (PST) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [94.198.152.69]) by ietfa.amsl.com (Postfix) with ESMTP id B5ECC11E8073 for ; Tue, 15 Nov 2011 18:19:31 -0800 (PST) Received: from kahubcas1.SIDN.local ([192.168.2.41]) by ede1-kamx.sidn.nl with ESMTP id pAG2JUlM031458 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Wed, 16 Nov 2011 03:19:30 +0100 Received: from KAMBX2.SIDN.local ([fe80::b1fd:88d9:e136:9655]) by kahubcas1.SIDN.local ([fe80::dff:8232:1563:3a16%14]) with mapi id 14.01.0323.003; Wed, 16 Nov 2011 03:19:30 +0100 From: Antoin Verschuren To: "dane@ietf.org" Thread-Topic: [dane] Scope of the protocol document or plea for progress Thread-Index: AQHMpAJnQSsLA3GytkSyYPzvhcfVEpWuxE4A Date: Wed, 16 Nov 2011 02:19:29 +0000 Message-ID: In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [192.168.192.231] Content-Type: text/plain; charset="us-ascii" Content-ID: <565000EB60E1E541815B9779A3C6D24E@sidn.nl> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dane] Scope of the protocol document or plea for progress X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Nov 2011 02:19:37 -0000 +1 --=20 Antoin Verschuren Technical Policy Advisor SIDN Meander 501, 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/ On 16-11-11 02:52, "Paul Wouters" wrote: >On Wed, 16 Nov 2011, Olafur Gudmundsson wrote: > >> I'm getting worried that the WG is falling off the tracks, it is >> getting distracted by trying to address every possible corner case. >> >> I want to propose that the Current protocol document explicitly only >>cover=20 >> the following case: >> Target zone is DNSSEC signed [1] >> and Consumer performs DNSSEC validation [2] >> and Target zone can be validated by the consumer. >> >> In this case there are two positive outcomes: >> - Validated TLSA RRset >> - Proof that the TLSA RRset does not exist >> >> and one Negative outcome: >> - TLSA RRset fails validation >> >> The document should say what the Consumer application does in each one >>of=20 >> these cases for each type TLSA of record i.e. if there is need to >>check=20 >> revocation lists, etc. >> >> For the other cases we just say "The consumer application falls back to >>the=20 >> processing it is currently doing". > >Fully agree! > >Paul >_______________________________________________ >dane mailing list >dane@ietf.org >https://www.ietf.org/mailman/listinfo/dane From ynir@checkpoint.com Tue Nov 15 18:37: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 045CA1F0C7B for ; Tue, 15 Nov 2011 18:37:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.418 X-Spam-Level: X-Spam-Status: No, score=-10.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Px5gkrKGFnRQ for ; Tue, 15 Nov 2011 18:37:22 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 15F501F0C60 for ; Tue, 15 Nov 2011 18:37:21 -0800 (PST) X-CheckPoint: {4EC32193-0-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id pAG2bK9v020591; Wed, 16 Nov 2011 04:37:20 +0200 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 16 Nov 2011 04:37:19 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Wed, 16 Nov 2011 04:37:19 +0200 From: Yoav Nir To: Paul Wouters Date: Wed, 16 Nov 2011 04:37:17 +0200 Thread-Topic: [dane] Scope of the protocol document or plea for progress Thread-Index: AcykCKjcRpk7oYcpSOeOrQHMwfXIhQ== Message-ID: <7AD7021C-0CCB-4E7B-8F11-D8DBF6664E20@checkpoint.com> References: <4EC2E8CA.1060009@ogud.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: "dane@ietf.org" Subject: Re: [dane] Scope of the protocol document or plea for progress X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Nov 2011 02:37:23 -0000 On Nov 16, 2011, at 9:52 AM, Paul Wouters wrote: > On Wed, 16 Nov 2011, Olafur Gudmundsson wrote: >=20 >> I'm getting worried that the WG is falling off the tracks, it is >> getting distracted by trying to address every possible corner case. >>=20 >> I want to propose that the Current protocol document explicitly only cov= er=20 >> the following case: >> Target zone is DNSSEC signed [1] >> and Consumer performs DNSSEC validation [2] >> and Target zone can be validated by the consumer. >>=20 >> In this case there are two positive outcomes: >> - Validated TLSA RRset >> - Proof that the TLSA RRset does not exist >>=20 >> and one Negative outcome: >> - TLSA RRset fails validation >>=20 >> The document should say what the Consumer application does in each one o= f=20 >> these cases for each type TLSA of record i.e. if there is need to check= =20 >> revocation lists, etc. >>=20 >> For the other cases we just say "The consumer application falls back to = the=20 >> processing it is currently doing". >=20 > Fully agree! +1 Yoav= From trevorf@exchange.microsoft.com Tue Nov 15 04:08: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 5FB4721F8EDE for ; Tue, 15 Nov 2011 04:08:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.67 X-Spam-Level: X-Spam-Status: No, score=-110.67 tagged_above=-999 required=5 tests=[AWL=-0.072, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 CYIVtqANiqn1 for ; Tue, 15 Nov 2011 04:08:27 -0800 (PST) Received: from mail.exchange.microsoft.com (mail7.exchange.microsoft.com [131.107.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 0BAA621F8EDC for ; Tue, 15 Nov 2011 04:08:27 -0800 (PST) Received: from df-h14-01.exchange.corp.microsoft.com (157.54.78.139) by DF-G14-02.exchange.corp.microsoft.com (157.54.87.56) with Microsoft SMTP Server (TLS) id 14.2.247.2; Tue, 15 Nov 2011 04:08:26 -0800 Received: from PIO-MLT-05.exchange.corp.microsoft.com (157.54.94.22) by DF-H14-01.exchange.corp.microsoft.com (157.54.78.139) with Microsoft SMTP Server (TLS) id 14.2.247.5; Tue, 15 Nov 2011 04:08:26 -0800 Received: from DF-M14-12.exchange.corp.microsoft.com ([fe80::7c94:4036:120:c95f]) by PIO-MLT-05.exchange.corp.microsoft.com ([fe80::d940:e316:1daa:5e6a%10]) with mapi id 14.02.0247.002; Tue, 15 Nov 2011 04:08:26 -0800 From: Trevor Freeman To: "dane@ietf.org" Thread-Topic: Fragility of binding to a CA certificate by certificate or ski Thread-Index: Acyjj0Rkb3L8aRwjTg+EWqkGLKap+g== Date: Tue, 15 Nov 2011 12:08:24 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: multipart/alternative; boundary="_000_E545B914D50B2A4B994F198378B1525D42789E26DFM1412exchange_" MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 15 Nov 2011 19:02:02 -0800 Subject: [dane] Fragility of binding to a CA certificate by certificate or ski X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 Nov 2011 12:08:28 -0000 --_000_E545B914D50B2A4B994F198378B1525D42789E26DFM1412exchange_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable For usage type =3D0, I am concerned about the fragility of matching a CA ce= rtificate is only by full certificate or SKI. Certificates and keys have an= inherently limited lifetime. CAs need to renew both as a matter of routine= maintenance, which is an operation outside of the visibility of the domain= and updating the domain DNS record is outside the control of the CA. This = is a recipe for things to go wrong. All a CA can do is notify the domain of= the update and hope they make the change to the DNS record. A more stable CA identifier would be a CA's subject name. This will remain = constant as certificates and keys are renewed. You can easily put a hexadec= imal encoded subject names in the DNS record and define a new match type. I= t would also be simple for the CA to publish instructions for creating the = DNS record and include the binary encoded subject name on the web page so t= he domain administrator can simple cut and paste the value when creating th= e DNS record for their domain and the instructions will not need updating e= very time they renew their CA certificate. Dr Trevor Freeman Senior Security Strategist End to End Trust Team Microsoft Trustworthy Computing --_000_E545B914D50B2A4B994F198378B1525D42789E26DFM1412exchange_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

For = usage type =3D0, I am concerned about the fragility of matching a CA certif= icate is only by full certificate or SKI. Certificates and keys have an inh= erently limited lifetime. CAs need to renew both as a matter of routine maintenance, which is an operation outsi= de of the visibility of the domain and updating the domain DNS record is ou= tside the control of the CA. This is a recipe for things to go wrong. All a= CA can do is notify the domain of the update and hope they make the change to the DNS record. =

 

A mo= re stable CA identifier would be a CA’s subject name. This will remai= n constant as certificates and keys are renewed. You can easily put a hexad= ecimal encoded subject names in the DNS record and define a new match type. It would also be simple for the CA to publish= instructions for creating the DNS record and include the binary encoded su= bject name on the web page so the domain administrator can simple cut and p= aste the value when creating the DNS record for their domain and the instructions will not need updating ev= ery time they renew their CA certificate.

 

Dr Trevor Freeman  Senior Security Strategist

End to End Trust Team

= Microsoft Trustworthy Computing  

 

--_000_E545B914D50B2A4B994F198378B1525D42789E26DFM1412exchange_-- From alangley@gmail.com Tue Nov 15 19:38: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 BA3D21F0CC0 for ; Tue, 15 Nov 2011 19:38:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85tYXCHcmKDX for ; Tue, 15 Nov 2011 19:38:05 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id D872B1F0C42 for ; Tue, 15 Nov 2011 19:37:50 -0800 (PST) Received: by iaeo4 with SMTP id o4so12449iae.31 for ; Tue, 15 Nov 2011 19:37:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=qpHbF3CXGxkS8miTFmRp68syfN2Q3Zmb8mnGPJOmLQg=; b=YfsPWHjf3upz9lOV0yZcaERwER6qTVsdPOuFPtANA5TOhHE9YCe8nrdSpb901J8v6h hGZVCk7z3Oko+BJo+LJfLOme5VmFXVqonERnQUNB5ZcuxYGb+6jI68apq0lX4ZBTsGtT pIjxwPBi2TeC5+ICMJFLVdR8MVXLC8id0Q6jM= MIME-Version: 1.0 Received: by 10.42.117.193 with SMTP id u1mr30694299icq.24.1321414670518; Tue, 15 Nov 2011 19:37:50 -0800 (PST) Sender: alangley@gmail.com Received: by 10.42.241.200 with HTTP; Tue, 15 Nov 2011 19:37:49 -0800 (PST) In-Reply-To: References: Date: Tue, 15 Nov 2011 22:37:49 -0500 X-Google-Sender-Auth: RW9qmJ2kdYSoEvbFBlFg8u02tWE Message-ID: From: Adam Langley To: Trevor Freeman Content-Type: text/plain; charset=UTF-8 Cc: "dane@ietf.org" Subject: Re: [dane] Fragility of binding to a CA certificate by certificate or ski X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Nov 2011 03:38:09 -0000 On Tue, Nov 15, 2011 at 7:08 AM, Trevor Freeman wrote: > For usage type =0, I am concerned about the fragility of matching a CA > certificate is only by full certificate or SKI. Certificates and keys have > an inherently limited lifetime. You are correct that matching by a certificate is a mistake because CAs often reissue their CA certificates and clients build chains from the bottom up. However, matching a SubjectPublicKeyInfo is rather robust. Certainly the leaf certificate cannot change without a site reconfiguring their servers. That implies that the next certificate's (call it I1) SPKI is fixed by the leaf (because it has to match the signature on the leaf). Above that, one could imagine the combination of: * The site fails to include any intermediate certificates * The leaf doesn't include an Authority Key Identifier, but incudes an AIA URL for I1 * I1 is replaced with a certificate with the same SPKI, but a different issuer. That way the CA could redirect the chain without the site knowing. However, it requires a misconfiguration of the site (that will cause intermittent issues and some clients to fail completely) and a grossly stupid CA. On the other hand, specifying via CA Subject name is very weak: any CA can issue certificates with any Subject name. Cheers AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From eosterweil@verisign.com Tue Nov 15 21:04: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 8BFD31F0CDF for ; Tue, 15 Nov 2011 21:04:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.577 X-Spam-Level: X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 zLayPoDVUstS for ; Tue, 15 Nov 2011 21:04:44 -0800 (PST) Received: from exprod6og109.obsmtp.com (exprod6og109.obsmtp.com [64.18.1.23]) by ietfa.amsl.com (Postfix) with ESMTP id 303721F0CE9 for ; Tue, 15 Nov 2011 21:04:29 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob109.postini.com ([64.18.5.12]) with SMTP ID DSNKTsNESRHSsRNymIkfNEuQJPNUxJTrBICv@postini.com; Tue, 15 Nov 2011 21:04:43 PST Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id pAG547B9013709; Wed, 16 Nov 2011 00:04:07 -0500 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.100.0.69]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Nov 2011 00:04:06 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: <7AD7021C-0CCB-4E7B-8F11-D8DBF6664E20@checkpoint.com> Date: Wed, 16 Nov 2011 13:03:56 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <32E8A6CB-5118-4E02-92F4-734411C2A825@verisign.com> References: <4EC2E8CA.1060009@ogud.com> <7AD7021C-0CCB-4E7B-8F11-D8DBF6664E20@checkpoint.com> To: Yoav Nir X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 16 Nov 2011 05:04:07.0247 (UTC) FILETIME=[2B2FEDF0:01CCA41D] Cc: "dane@ietf.org" Subject: Re: [dane] Scope of the protocol document or plea for progress X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Nov 2011 05:04:44 -0000 On Nov 16, 2011, at 10:37 AM, Yoav Nir wrote: >=20 > On Nov 16, 2011, at 9:52 AM, Paul Wouters wrote: >=20 >> On Wed, 16 Nov 2011, Olafur Gudmundsson wrote: >>=20 >>> I'm getting worried that the WG is falling off the tracks, it is >>> getting distracted by trying to address every possible corner case. >>>=20 >>> I want to propose that the Current protocol document explicitly only = cover=20 >>> the following case: >>> Target zone is DNSSEC signed [1] >>> and Consumer performs DNSSEC validation [2] >>> and Target zone can be validated by the consumer. >>>=20 >>> In this case there are two positive outcomes: >>> - Validated TLSA RRset >>> - Proof that the TLSA RRset does not exist >>>=20 >>> and one Negative outcome: >>> - TLSA RRset fails validation >>>=20 >>> The document should say what the Consumer application does in each = one of=20 >>> these cases for each type TLSA of record i.e. if there is need to = check=20 >>> revocation lists, etc. >>>=20 >>> For the other cases we just say "The consumer application falls back = to the=20 >>> processing it is currently doing". >>=20 >> Fully agree! >=20 > +1 +1 Eric= From nweaver@icsi.berkeley.edu Tue Nov 15 21:05: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 6C84C1F0CF5 for ; Tue, 15 Nov 2011 21:05:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2N6R0AmsyVi for ; Tue, 15 Nov 2011 21:05:16 -0800 (PST) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id EAD641F0CE0 for ; Tue, 15 Nov 2011 21:05:16 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id C15992C400F; Tue, 15 Nov 2011 21:05:16 -0800 (PST) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id F3ksqMJsbi7E; Tue, 15 Nov 2011 21:05:16 -0800 (PST) Received: from [10.0.1.11] (c-76-103-162-14.hsd1.ca.comcast.net [76.103.162.14]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 37C952C400A; Tue, 15 Nov 2011 21:05:16 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: <32E8A6CB-5118-4E02-92F4-734411C2A825@verisign.com> Date: Tue, 15 Nov 2011 21:05:14 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <4EC2E8CA.1060009@ogud.com> <7AD7021C-0CCB-4E7B-8F11-D8DBF6664E20@checkpoint.com> <32E8A6CB-5118-4E02-92F4-734411C2A825@verisign.com> To: Eric Osterweil X-Mailer: Apple Mail (2.1251.1) Cc: "dane@ietf.org" Subject: Re: [dane] Scope of the protocol document or plea for progress X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Nov 2011 05:05:17 -0000 On Nov 15, 2011, at 9:03 PM, Eric Osterweil wrote: > On Nov 16, 2011, at 10:37 AM, Yoav Nir wrote: >> On Nov 16, 2011, at 9:52 AM, Paul Wouters wrote: >> >>> On Wed, 16 Nov 2011, Olafur Gudmundsson wrote: >>> >>>> I'm getting worried that the WG is falling off the tracks, it is >>>> getting distracted by trying to address every possible corner case. Yet Another +1 From ondrej.sury@nic.cz Tue Nov 15 21:22: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 DA86E1F0CA3 for ; Tue, 15 Nov 2011 21:22:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KbafRHBOnARw for ; Tue, 15 Nov 2011 21:21:57 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 199991F0C61 for ; Tue, 15 Nov 2011 21:21:56 -0800 (PST) Received: from dhcp-63b8.meeting.ietf.org (dhcp-63b8.meeting.ietf.org [130.129.99.184]) by mail.nic.cz (Postfix) with ESMTPSA id 01CCB2A2D1E; Wed, 16 Nov 2011 06:21:53 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1321420915; bh=iMBaqZLepYZOu4glDQOefaLu0v2q1Q6+yc9bqyc6HSw=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=AheWfJf0fINSTT8V9z1zZURlzClJgSTGToxt70QJlOYdqg7sdropP9bcal3B8ZRYM tKTWsvZDLwCK9+6sO3AcCufQtO8+xjXmPQLhGC/iSEKXIWqywlxEbyBg5UD+OS2ipz iyTy6NZjfIVjousODzLcPhXgtC3K1Kj5I+cZocT0= Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <4EC2E8CA.1060009@ogud.com> Date: Wed, 16 Nov 2011 13:21:49 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <55221C61-0F07-41F7-9FEE-B98C790E7F3B@nic.cz> References: <4EC2E8CA.1060009@ogud.com> To: Olafur Gudmundsson X-Mailer: Apple Mail (2.1251.1) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane@ietf.org Subject: Re: [dane] Scope of the protocol document or plea for progress X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Nov 2011 05:22:20 -0000 I very much like the idea of having KISS solution in the DANE protocol = document and if there's interest (and a volunteer) we can have another I-D = covering the corner cases. Thanks to Olafur for pointing that we could have this in two step = process. With my chair hat on - could we get an consensus on: > I want to propose that the Current protocol document explicitly only = cover the following case: > Target zone is DNSSEC signed [1] > and Consumer performs DNSSEC validation [2] > and Target zone can be validated by the consumer. I already saw several +1's on the list and I would like to see more especially from the people who participated in the Taipei WG discussion on this topic. And here's +1 from me. O. On 16. 11. 2011, at 6:33, Olafur Gudmundsson wrote: >=20 > Dear colleagues, >=20 > I'm getting worried that the WG is falling off the tracks, it is > getting distracted by trying to address every possible corner case. >=20 > I want to propose that the Current protocol document explicitly only = cover the following case: > Target zone is DNSSEC signed [1] > and Consumer performs DNSSEC validation [2] > and Target zone can be validated by the consumer. >=20 > In this case there are two positive outcomes: > - Validated TLSA RRset > - Proof that the TLSA RRset does not exist >=20 > and one Negative outcome: > - TLSA RRset fails validation >=20 > The document should say what the Consumer application does in each one = of these cases for each type TLSA of record i.e. if there is need to = check revocation lists, etc. >=20 > For the other cases we just say "The consumer application falls back = to the processing it is currently doing". >=20 > This is the 98% solution and the faster we can start deploying it the = better off we are!!!! >=20 > A subsequent document can address the transition cases i.e. when > DNSSEC validation can not succeed due to: > Breaks in trust chain > Algorithm mismatch > Unsigned publisher zone > No Validating resolver available > DNSSEC records not getting through > timeouts > Incomplete Trust Chain > etc. >=20 > I would call this document > "Value of TLSA records when DNSSEC validation is not available". >=20 > I feel that using words like "DNS optional" does nothing but confuse = both potential publishers and consumers of TLSA records as well as the = implementors. >=20 > I want to thank Richard Barnes for forcing me to think though the = implications of his incomplete flow chart on the document. [3] > My subsequent flowchart takes multiple pages and is not yet complete, = thus I think any document that tries to address those issues will take a = long time to write. Conversely writing such a document will be > much easier if the positive cases are taken out of it. >=20 > Comments > Olafur >=20 > [1] Target zone is the zone the name of the service resides in, i.e. > the name _443._tcp.gmail.com is in gmail.com or _tcp.gmail.com. >=20 > [2] Consumer has a DNSSEC capable validator that she/he trusts the = answer from. >=20 > [3] http://tools.ietf.org/agenda/82/slides/dane-2.pdf slide 9. > _______________________________________________ > 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 miekg@atoom.net Tue Nov 15 22:32: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 1C41B11E8123 for ; Tue, 15 Nov 2011 22:32:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.856 X-Spam-Level: X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[AWL=0.745, 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 mRZK7OfyJPEw for ; Tue, 15 Nov 2011 22:32:28 -0800 (PST) Received: from elektron.atoom.net (cl-201.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:c8::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7E68711E8113 for ; Tue, 15 Nov 2011 22:32:28 -0800 (PST) Received: by elektron.atoom.net (Postfix, from userid 1000) id AE0E13FFE2; Wed, 16 Nov 2011 07:32:26 +0100 (CET) Date: Wed, 16 Nov 2011 07:32:26 +0100 From: Miek Gieben To: dane@ietf.org Message-ID: <20111116063226.GA26365@miek.nl> Mail-Followup-To: dane@ietf.org References: <4EC2E8CA.1060009@ogud.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PEIAKu/WMn1b1Hv9" Content-Disposition: inline In-Reply-To: <4EC2E8CA.1060009@ogud.com> User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Subject: Re: [dane] Scope of the protocol document or plea for progress X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Nov 2011 06:32:29 -0000 --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline [ Quoting at 06:33 on Nov 16 in "[dane] Scope of the ..." ] > I'm getting worried that the WG is falling off the tracks, it is > getting distracted by trying to address every possible corner case. +1 grtz Miek --PEIAKu/WMn1b1Hv9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk7DWPoACgkQJYuFzziA0PbhRwCfTOSTfTyv4ZQXrJ2IIL9xWo8q PwcAoOnPljKY8nkRNhatIl1+au3zqxws =VOYp -----END PGP SIGNATURE----- --PEIAKu/WMn1b1Hv9-- From fneves@registro.br Tue Nov 15 22:49: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 B1DC421F934A for ; Tue, 15 Nov 2011 22:49:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1E3WC9VBp99B for ; Tue, 15 Nov 2011 22:49:40 -0800 (PST) Received: from clone.registro.br (clone.registro.br [IPv6:2001:12ff:0:2::4]) by ietfa.amsl.com (Postfix) with ESMTP id 3668821F9349 for ; Tue, 15 Nov 2011 22:49:40 -0800 (PST) Received: by clone.registro.br (Postfix, from userid 1000) id D9A75E043C; Wed, 16 Nov 2011 04:49:34 -0200 (BRST) Date: Wed, 16 Nov 2011 04:49:34 -0200 From: Frederico A C Neves To: dane@ietf.org Message-ID: <20111116064934.GB13886@registro.br> References: <4EC2E8CA.1060009@ogud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EC2E8CA.1060009@ogud.com> Subject: Re: [dane] Scope of the protocol document or plea for progress X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Nov 2011 06:49:40 -0000 On Wed, Nov 16, 2011 at 06:33:46AM +0800, Olafur Gudmundsson wrote: > > Dear colleagues, > > I'm getting worried that the WG is falling off the tracks, it is > getting distracted by trying to address every possible corner case. > > I want to propose that the Current protocol document explicitly only > cover the following case: > Target zone is DNSSEC signed [1] > and Consumer performs DNSSEC validation [2] > and Target zone can be validated by the consumer. Fully agree, Fred From jakob@kirei.se Tue Nov 15 23:53: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 0D89211E816D for ; Tue, 15 Nov 2011 23:53:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uuiw5Snc6cQ1 for ; Tue, 15 Nov 2011 23:53:30 -0800 (PST) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id 9547211E80F9 for ; Tue, 15 Nov 2011 23:53:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=k3ui8/r/sZJtsbYuCByxVsWsCy6ozHP/pF3YqHvCCck=; b=kmQP5O1/WQqS7uja1pJeWuzib+2szERrXaI66gQf15BX1SYmQ6BctFqML2NpuMLAuOQPrBHsUJ5y+ KSbzOgupZnmSOHqtZCa+a5j50XOX8kRnXe+bSsD+grp2roLCaHrmQw4vSjkBLXLpR3q6OFMhlaP3h5 gPKJd68e00TpSZP4= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Wed, 16 Nov 2011 08:53:27 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: <4EC2E8CA.1060009@ogud.com> Date: Wed, 16 Nov 2011 08:53:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <944D9413-A209-438F-9B6D-17C82A205C75@kirei.se> References: <4EC2E8CA.1060009@ogud.com> To: Olafur Gudmundsson X-Mailer: Apple Mail (2.1251.1) Cc: dane@ietf.org Subject: Re: [dane] Scope of the protocol document or plea for progress X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Nov 2011 07:53:35 -0000 Thank you Olafur, I agree fully - (and it would make my life as = document (co)author a lot easier. jakob From zack.weinberg@gmail.com Wed Nov 16 08:16: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 2F27F21F954E for ; Wed, 16 Nov 2011 08:16:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.827 X-Spam-Level: X-Spam-Status: No, score=-2.827 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 qSP4XfvcGT1Q for ; Wed, 16 Nov 2011 08:16:20 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id F308421F953F for ; Wed, 16 Nov 2011 08:16:16 -0800 (PST) Received: by eyg24 with SMTP id 24so742268eyg.31 for ; Wed, 16 Nov 2011 08:16:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=5G3LD6t8mppOj188UM84GQ0scWjDAoBt1c6GrXPwDbA=; b=Zf3lD6d76a0NSZ2jLG0/AE1lELzz9OYySab/7dItzZEVmr+P4Drg5GTNh9kAKWugv8 73MRVf/rCxFns04nHIid33xdELzmqHHLrfMz05DRZc4xg/BVUWcH22PWoGbCOcK8aR6x x1GKlRN4zz07LnkPlNroR8gvD+NCYBIAjzbX8= MIME-Version: 1.0 Received: by 10.182.169.34 with SMTP id ab2mr7309680obc.27.1321460175528; Wed, 16 Nov 2011 08:16:15 -0800 (PST) Sender: zack.weinberg@gmail.com Received: by 10.182.88.103 with HTTP; Wed, 16 Nov 2011 08:16:15 -0800 (PST) In-Reply-To: <944D9413-A209-438F-9B6D-17C82A205C75@kirei.se> References: <4EC2E8CA.1060009@ogud.com> <944D9413-A209-438F-9B6D-17C82A205C75@kirei.se> Date: Wed, 16 Nov 2011 08:16:15 -0800 X-Google-Sender-Auth: nWgI6Ks0yunigAR9plj3KQX7Q3A Message-ID: From: Zack Weinberg To: Jakob Schlyter Content-Type: text/plain; charset=UTF-8 Cc: dane@ietf.org Subject: Re: [dane] Scope of the protocol document or plea for progress X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Nov 2011 16:16:21 -0000 I agree in principle with limiting scope creep - but I don't see that there is scope creep here. > A subsequent document can address the transition cases i.e. when > DNSSEC validation can not succeed due to: > Breaks in trust chain > Algorithm mismatch > Unsigned publisher zone > No Validating resolver available > DNSSEC records not getting through > timeouts > Incomplete Trust Chain > etc. If DNSSEC validation state is "bogus", fail association. If DNSSEC validation state is "insecure" or "indeterminate", ignore all TLSA records. That should be all that is needed. zw From mrex@sap.com Wed Nov 16 12:48: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 E587811E808F for ; Wed, 16 Nov 2011 12:48:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.136 X-Spam-Level: X-Spam-Status: No, score=-10.136 tagged_above=-999 required=5 tests=[AWL=0.113, 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 xCK6Ww+duF7i for ; Wed, 16 Nov 2011 12:48:02 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 44F3111E8085 for ; Wed, 16 Nov 2011 12:48:00 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id pAGKlxgP029814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 Nov 2011 21:47:59 +0100 (MET) From: Martin Rex Message-Id: <201111162047.pAGKlwm6006918@fs4113.wdf.sap.corp> To: paul@xelerance.com (Paul Wouters) Date: Wed, 16 Nov 2011 21:47:58 +0100 (MET) In-Reply-To: from "Paul Wouters" at Nov 15, 11 08:52:06 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] Scope of the protocol document or plea for progress 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, 16 Nov 2011 20:48:03 -0000 Paul Wouters wrote: > > Olafur Gudmundsson wrote: > > > > I'm getting worried that the WG is falling off the tracks, it is > > getting distracted by trying to address every possible corner case. > > > > I want to propose that the Current protocol document explicitly only cover > > the following case: > > Target zone is DNSSEC signed [1] > > and Consumer performs DNSSEC validation [2] > > and Target zone can be validated by the consumer. > > > > In this case there are two positive outcomes: > > - Validated TLSA RRset > > - Proof that the TLSA RRset does not exist > > > > and one Negative outcome: > > - TLSA RRset fails validation > > > > The document should say what the Consumer application does in each one of > > these cases for each type TLSA of record i.e. if there is need to check > > revocation lists, etc. > > > > For the other cases we just say "The consumer application falls back to the > > processing it is currently doing". > > Fully agree! +1 -Martin From mrex@sap.com Wed Nov 16 13:10: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 3AE4C11E8085 for ; Wed, 16 Nov 2011 13:10:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.138 X-Spam-Level: X-Spam-Status: No, score=-10.138 tagged_above=-999 required=5 tests=[AWL=0.111, 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 ayGZksR6IuGr for ; Wed, 16 Nov 2011 13:10:43 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1E321F9116 for ; Wed, 16 Nov 2011 13:10:43 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id pAGLAb7Z011050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 Nov 2011 22:10:37 +0100 (MET) From: Martin Rex Message-Id: <201111162110.pAGLAbRs008326@fs4113.wdf.sap.corp> To: trevorf@exchange.microsoft.com (Trevor Freeman) Date: Wed, 16 Nov 2011 22:10:37 +0100 (MET) In-Reply-To: from "Trevor Freeman" at Nov 15, 11 12:08:24 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] Fragility of binding to a CA certificate by certificate or 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, 16 Nov 2011 21:10:44 -0000 Trevor Freeman wrote: > > For usage type =0, I am concerned about the fragility of matching a CA > certificate is only by full certificate or SKI. Certificates and keys > have an inherently limited lifetime. That is only a problem for "cert pinning", but not for DANE. > > CAs need to renew both as a matter of routine maintenance, which is > an operation outside of the visibility of the domain and updating the > domain DNS record is outside the control of the CA. This is a recipe > for things to go wrong. All a CA can do is notify the domain of the > update and hope they make the change to the DNS record. Renewal of server certificates is an administrative task of the server admin, and certificate issuance is irrelevant, the only thing that matters is the actual administrative update of the servers certificate on the server itself. The CA certificate necessary to verify the server certificate is locked down with the signature on the server certificate and MUST be (per TLS protocol spec) sent by the TLS server in the servers certificate handshake message. When the CA issues the server certificate unter a different CA cert on server certificate renewal, then the server admin will have to update the DNS TLSA record before installing the new server certificate, of course. While a CA may "price" this the same as a renewal, it technically is not a renewal, but a different certificate, requiring the TLS server to also send a different forward certification path in the TLS server certificate handshake message, so such a CA better WARNS it customer with a big red sign when doing this instead of a renewal. > > A more stable CA identifier would be a CA's subject name. > This will remain constant as certificates and keys are renewed. Very bad idea. Every CA in the TLS X.509 PKI can create a subordinate CA with any arbitrary Name in it This idea would only work in a strictly hierarchical PKI with a singular root authority (which does not need to have a root cert, but must have the authority to define and enforce the policy by which all CAs in the PKI must be operated). -Martin From paul.hoffman@vpnc.org Wed Nov 16 15:01: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 0676211E808E for ; Wed, 16 Nov 2011 15:01:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFGwU7DEORkT for ; Wed, 16 Nov 2011 15:01:57 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0EF11E808B for ; Wed, 16 Nov 2011 15:01:57 -0800 (PST) Received: from [192.168.100.241] (61-220-70-183.HINET-IP.hinet.net [61.220.70.183]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id pAGN1kRe085019 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 16 Nov 2011 16:01:48 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Thu, 17 Nov 2011 07:01:47 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <162A261A-0872-4ADE-BE87-9F906E93CBED@vpnc.org> References: <4EC2E8CA.1060009@ogud.com> <944D9413-A209-438F-9B6D-17C82A205C75@kirei.se> To: Zack Weinberg X-Mailer: Apple Mail (2.1251.1) Cc: IETF DANE WG list Subject: Re: [dane] Scope of the protocol document or plea for progress X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Nov 2011 23:01:58 -0000 On Nov 17, 2011, at 12:16 AM, Zack Weinberg wrote: > If DNSSEC validation state is "bogus", fail association. > If DNSSEC validation state is "insecure" or "indeterminate", ignore > all TLSA records. >=20 > That should be all that is needed. I spoke with Olafur last night, and what you state here is not exactly = what he intended. I'll let him say precisely what he intended so that = people who already +1'd can decide if they still feel that way. --Paul Hoffman From brian.peter.dickson@gmail.com Wed Nov 16 15:12: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 4FD1421F8CF7 for ; Wed, 16 Nov 2011 15:12:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.489 X-Spam-Level: X-Spam-Status: No, score=-3.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 71+5gNBl71fM for ; Wed, 16 Nov 2011 15:12:05 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1B721F8CF6 for ; Wed, 16 Nov 2011 15:12:05 -0800 (PST) Received: by bkbzv15 with SMTP id zv15so1427768bkb.31 for ; Wed, 16 Nov 2011 15:12:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=wveLh1aJE+2PkX7xUcF5MDY54/1akCW+EEsBq4M3Z9M=; b=rGX8t1uzSkUG2R72QMx9U6rS2f8JS4u7QjL/XTXb1qGh/HpfgHBbIK5gY1W22HM9L8 Qo71zsufvskVoQBrNUkFQf5Kt56xOCku1NAKGHMrlL94SYU5FW4fqZt+rbaM19fTob5B LU9v0JCVC+MmhbmaanqFsVsBMQU16rAWWlfCE= MIME-Version: 1.0 Received: by 10.205.119.207 with SMTP id fv15mr31057843bkc.100.1321485124515; Wed, 16 Nov 2011 15:12:04 -0800 (PST) Received: by 10.223.54.15 with HTTP; Wed, 16 Nov 2011 15:12:04 -0800 (PST) In-Reply-To: References: Date: Wed, 16 Nov 2011 18:12:04 -0500 Message-ID: From: Brian Dickson To: Antoin Verschuren Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dane@ietf.org" Subject: Re: [dane] Scope of the protocol document or plea for progress X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Nov 2011 23:12:06 -0000 +1 (+1,000,000 actually). Brian On Tue, Nov 15, 2011 at 9:19 PM, Antoin Verschuren wrote: > +1 > > -- > Antoin Verschuren > > Technical Policy Advisor SIDN > Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands > > P: +31 26 3525500 =A0F: +31 26 3525505 =A0M: +31 6 23368970 > mailto:antoin.verschuren@sidn.nl =A0xmpp:antoin@jabber.sidn.nl > http://www.sidn.nl/ > > > > > On 16-11-11 02:52, "Paul Wouters" wrote: > >>On Wed, 16 Nov 2011, Olafur Gudmundsson wrote: >> >>> I'm getting worried that the WG is falling off the tracks, it is >>> getting distracted by trying to address every possible corner case. >>> >>> I want to propose that the Current protocol document explicitly only >>>cover >>> the following case: >>> =A0 =A0Target zone is DNSSEC signed [1] >>> and =A0 =A0Consumer performs DNSSEC validation [2] >>> and =A0 =A0 Target zone can be validated by the consumer. >>> >>> In this case there are two positive outcomes: >>> =A0 =A0- Validated TLSA RRset >>> =A0 =A0- Proof that the TLSA RRset does not exist >>> >>> and one Negative outcome: >>> =A0 =A0- TLSA RRset fails validation >>> >>> The document should say what the Consumer application does in each one >>>of >>> these cases for each type TLSA of record =A0i.e. if there is need to >>>check >>> revocation lists, etc. >>> >>> For the other cases we just say "The consumer application falls back to >>>the >>> processing it is currently doing". >> >>Fully agree! >> >>Paul >>_______________________________________________ >>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 ogud@ogud.com Wed Nov 16 17:05: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 3F38211E8098 for ; Wed, 16 Nov 2011 17:05:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.574 X-Spam-Level: X-Spam-Status: No, score=-106.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 48tDzvoNl-ed for ; Wed, 16 Nov 2011 17:04:59 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 7A89511E8086 for ; Wed, 16 Nov 2011 17:04:59 -0800 (PST) Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id pAH14tKE059733; Wed, 16 Nov 2011 20:04:57 -0500 (EST) (envelope-from ogud@ogud.com) Message-ID: <4EC45DAB.9050607@ogud.com> Date: Thu, 17 Nov 2011 09:04:43 +0800 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Paul Hoffman References: <4EC2E8CA.1060009@ogud.com> <944D9413-A209-438F-9B6D-17C82A205C75@kirei.se> <162A261A-0872-4ADE-BE87-9F906E93CBED@vpnc.org> In-Reply-To: <162A261A-0872-4ADE-BE87-9F906E93CBED@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: IETF DANE WG list Subject: Re: [dane] Scope of the protocol document or plea for progress X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 17 Nov 2011 01:05:00 -0000 On 17/11/2011 07:01, Paul Hoffman wrote: > On Nov 17, 2011, at 12:16 AM, Zack Weinberg wrote: > >> If DNSSEC validation state is "bogus", fail association. >> If DNSSEC validation state is "insecure" or "indeterminate", ignore >> all TLSA records. >> >> That should be all that is needed. > > > I spoke with Olafur last night, and what you state here is not exactly what he intended. I'll let him say precisely what he intended so that people who already +1'd can decide if they still feel that way. > > --Paul Hoffman > > Yesterday Paul and I talked about this at length, the DNSSEC-only document might/should give guidance on use policy in the cases DNSSEC validation can not succeed. There are two possible actions: Discard TLSA Specify use policy by TLSA sub-type My intention was that the application make that choice but explicitly state for each TLSA sub-type what the default policy for that sub-type is: For sub-types 0 and 1 reuse is possible. For sub-type 2 "MUST ignore" is the only sane policy For future sub-types the defining document MUST specify reuse policy. (For bare keys the MUST ignore is also the only sane policy) Thus I amend yesterdays proposal to explicitly put in scope of the document to specify the usage policy for each sub-type when DNSSEC does not succeed. Having said this I realize TLSA is potentially headed for the sub-typing hell that TXT and NAPTR records suffer from. The WG should have a short discussion about the design choice of "if single RR type or multiple RR types" is a better way forward and the document should have the justification for the choice made. Olafur From mrex@sap.com Wed Nov 16 17:24: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 6B5221F0C51 for ; Wed, 16 Nov 2011 17:24:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.143 X-Spam-Level: X-Spam-Status: No, score=-10.143 tagged_above=-999 required=5 tests=[AWL=0.106, 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 Qyo80q9eU5dI for ; Wed, 16 Nov 2011 17:24:04 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id A7E411F0C4A for ; Wed, 16 Nov 2011 17:24:03 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id pAH1NuvU003208 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 17 Nov 2011 02:24:01 +0100 (MET) From: Martin Rex Message-Id: <201111170123.pAH1Nu8P023794@fs4113.wdf.sap.corp> To: ogud@ogud.com (Olafur Gudmundsson) Date: Thu, 17 Nov 2011 02:23:55 +0100 (MET) In-Reply-To: <4EC45DAB.9050607@ogud.com> from "Olafur Gudmundsson" at Nov 17, 11 09:04:43 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] Scope of the protocol document or plea for progress 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, 17 Nov 2011 01:24:04 -0000 Olafur Gudmundsson wrote: > > Yesterday Paul and I talked about this at length, > the DNSSEC-only document might/should give guidance on use policy in > the cases DNSSEC validation can not succeed. > > There are two possible actions: > Discard TLSA > Specify use policy by TLSA sub-type > > My intention was that the application make that choice but > explicitly state for each TLSA sub-type what the default policy for > that sub-type is: > For sub-types 0 and 1 reuse is possible. > For sub-type 2 "MUST ignore" is the only sane policy I strongly dislike *ANY* reuse. As described in earlier discussions, for attackers that are sufficiently close to the victim client to see his DNS requests outgoing, it is trivial to reliably DNS spoof the client. MITMing the clients TLS connections to the server is MUCH harder (unless you happen to be the router on the path or coerce the client to believe that you're the router, an IPv6 feature). By inserting fake DNS TLSA records, you can make the TLS client that believe in TLSA absent of DNSSEC protection, reliably fail connection to the real server that the attacker fails to MITM, and showing only the connections that the attacker succeeds to MITM as "trustworthy". This is the "firesheep" scenario. I strongly dislike the idea to have the client make flawed assumptions that can backfire so badly. Instead, I would really prefer to leave the pressure on to create a TLS extension and convey the necessary DNSSEC records inband with the TLS handshake. -Martin From trevorf@exchange.microsoft.com Wed Nov 16 17:32: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 085DA11E80B5 for ; Wed, 16 Nov 2011 17:32:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.661 X-Spam-Level: X-Spam-Status: No, score=-110.661 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 JFdwGEcOK2js for ; Wed, 16 Nov 2011 17:31:59 -0800 (PST) Received: from mail.exchange.microsoft.com (mail1.exchange.microsoft.com [131.107.1.17]) by ietfa.amsl.com (Postfix) with ESMTP id 230DF11E80B4 for ; Wed, 16 Nov 2011 17:31:59 -0800 (PST) Received: from df-h14-01.exchange.corp.microsoft.com (157.54.78.139) by DF-G14-01.exchange.corp.microsoft.com (157.54.87.87) with Microsoft SMTP Server (TLS) id 14.2.247.2; Wed, 16 Nov 2011 17:31:57 -0800 Received: from PIO-MLT-05.exchange.corp.microsoft.com (157.54.94.22) by DF-H14-01.exchange.corp.microsoft.com (157.54.78.139) with Microsoft SMTP Server (TLS) id 14.2.247.5; Wed, 16 Nov 2011 17:31:57 -0800 Received: from DF-M14-12.exchange.corp.microsoft.com ([fe80::7c94:4036:120:c95f]) by PIO-MLT-05.exchange.corp.microsoft.com ([fe80::d940:e316:1daa:5e6a%10]) with mapi id 14.02.0247.002; Wed, 16 Nov 2011 17:31:56 -0800 From: Trevor Freeman To: Adam Langley Thread-Topic: [dane] Fragility of binding to a CA certificate by certificate or ski Thread-Index: Acyjj0Rkb3L8aRwjTg+EWqkGLKap+gAxOZ2AABoJAtA= Date: Thu, 17 Nov 2011 01:31:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "dane@ietf.org" Subject: Re: [dane] Fragility of binding to a CA certificate by certificate or ski X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 17 Nov 2011 01:32:00 -0000 SGkgQW5kLA0KDQpQa2l4IGhhcyBtYW55IGNvbnRyb2xzIHRvIGNvbnRyb2wgdHJ1c3QgaW4gQ0Fz LiBUaGVyZSBhcmUgbW9yZSBjb250cm9scyBmb3IgdHJ1c3QgaW4gQ0FzIGNlcnRpZmljYXRlcyB0 aGFuIHRob3NlIG92ZXIgZW5kIGVudGl0aWVzLiBXZSBhcmUgdGFsa2luZyBhYm91dCB1c2FnZSB0 eXBlID0wIHNvIHRoZSByZWx5aW5nIHBhcnR5IGhhcyBmdWxsIGNvbnRyb2wgb3ZlciB0aGVpciBv d24gcGtpeCBwb2xpY3kuDQoNCkkgYWdyZWUgdGhhdCBtYXRjaGluZyBTS0kgaXMgYSBzdHJvbmdl ciBiaW5kaW5nIGJ1dCBpdCBpcyBub3QgbmVjZXNzYXJ5IG1vcmUgcm9idXN0IGlmIGl0IHJlc3Vs dHMgaW4gbG9zcyBvZiBzZXJ2aWNlLiBJdOKAmXMgYSBtdWNoIGEgYnVzaW5lc3MgcmljayBkZXRl cm1pbmF0aW9uIGlmIHRoZSBzaXRlIHdhbnQgdG8gdHJhZGUgaGlnaGVyIGF2YWlsYWJpbGl0eSBm b3IgYSBzdHJvbmdlciBiaW5kaW5nLiBUaGV5IGFyZSBiZXN0IHBsYWNlZCB0byBkZXRlcm1pbmUg c2NhbGUgb2YgaW1wYWN0IGZyb20gbG9zcyBvZiBzZXJ2aWNlIHZzLiBhbiBhY3RpdmUgYXR0YWNr Lg0KDQpHaXZlbiB3ZSBhcmUgYW50aWNpcGF0aW5nIGEgd29yayB3aXRoIEROU1NFQywgdGhlIGF0 dGFja2VyIG5vdyBoYXMgdG8gb2J0YWluIGEgc2l0ZSBjZXJ0aWZpY2F0ZSBhbmQgY29tcHJvbWlz ZSBzb21lIHBhcnQgb2YgdGhlIHJvdXRpbmcgaW5mcmFzdHJ1Y3R1cmUgZm9yIHRoZSBtYXJrIHNv IHRoZXkgY2FuIHBlcmZvcm0gYWRkcmVzcyBtYXBwaW5nIHRvIHJlZGlyZWN0IHRoZSBpcCB0cmFm ZmljIHRvIHRoZSBib2d1cyBzaXRlLiBUaGF0IGlzIG5vdCBhbiBhdHRhY2sgdGhhdCBzY2FsZXMg d2VsbCBidXQgaWYgdGhlIENBIGNoYW5nZXMgaXRzIGtleSBhbmQgdGhlIHNpdGUgZGlkIG5vdCB1 cGRhdGUgaXRzIEROUyByZWNvcmQsIHRoZSBzaXRlIGlzIGRvd24uDQoNCkFkYW0sIHlvdSBuZWVk IHRvIGNoZWNrIDUyODAgc2VjdGlvbiA2LiBQa2l4IGNoYWluaW5nIGlzIG5hbWUgYmFzZWQgbm90 IGtleSBiYXNlZC4gIFllcyBpdCBjaGVja3MgdGhlIHNpZ25hdHVyZXMgYnV0IFNLSVxBS0kgbWF0 Y2hpbmcgaXMgbm90IHVzZWQgaW4gYW55IHdheS4NCg0KTWF0Y2hpbmcgYnkgc3ViamVjdCBuYW1l IHByZXNlbnRzIGEgc3Ryb25nIENBIGJpbmRpbmcgbWVjaGFuaXNtIHdoaWNoIGlzIG1vcmUgcm9i dXN0IGFnYWluc3QgY29uZmlndXJhdGlvbiBtaXNtYXRjaCAtIGhlbmNlIGRlbHZlcidzIGhpZ2hl ciBhdmFpbGFiaWxpdHkuIA0KDQpUcmV2b3INCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IGFsYW5nbGV5QGdtYWlsLmNvbSBbbWFpbHRvOmFsYW5nbGV5QGdtYWlsLmNvbV0gT24g QmVoYWxmIE9mIEFkYW0gTGFuZ2xleQ0KU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAxNiwgMjAx MSAxMTozOCBBTQ0KVG86IFRyZXZvciBGcmVlbWFuDQpDYzogZGFuZUBpZXRmLm9yZw0KU3ViamVj dDogUmU6IFtkYW5lXSBGcmFnaWxpdHkgb2YgYmluZGluZyB0byBhIENBIGNlcnRpZmljYXRlIGJ5 IGNlcnRpZmljYXRlIG9yIHNraQ0KDQpPbiBUdWUsIE5vdiAxNSwgMjAxMSBhdCA3OjA4IEFNLCBU cmV2b3IgRnJlZW1hbiA8dHJldm9yZkBleGNoYW5nZS5taWNyb3NvZnQuY29tPiB3cm90ZToNCj4g Rm9yIHVzYWdlIHR5cGUgPTAsIEkgYW0gY29uY2VybmVkIGFib3V0IHRoZSBmcmFnaWxpdHkgb2Yg bWF0Y2hpbmcgYSBDQSANCj4gY2VydGlmaWNhdGUgaXMgb25seSBieSBmdWxsIGNlcnRpZmljYXRl IG9yIFNLSS4gQ2VydGlmaWNhdGVzIGFuZCBrZXlzIA0KPiBoYXZlIGFuIGluaGVyZW50bHkgbGlt aXRlZCBsaWZldGltZS4NCg0KWW91IGFyZSBjb3JyZWN0IHRoYXQgbWF0Y2hpbmcgYnkgYSBjZXJ0 aWZpY2F0ZSBpcyBhIG1pc3Rha2UgYmVjYXVzZSBDQXMgb2Z0ZW4gcmVpc3N1ZSB0aGVpciBDQSBj ZXJ0aWZpY2F0ZXMgYW5kIGNsaWVudHMgYnVpbGQgY2hhaW5zIGZyb20gdGhlIGJvdHRvbSB1cC4N Cg0KSG93ZXZlciwgbWF0Y2hpbmcgYSBTdWJqZWN0UHVibGljS2V5SW5mbyBpcyByYXRoZXIgcm9i dXN0LiBDZXJ0YWlubHkgdGhlIGxlYWYgY2VydGlmaWNhdGUgY2Fubm90IGNoYW5nZSB3aXRob3V0 IGEgc2l0ZSByZWNvbmZpZ3VyaW5nIHRoZWlyIHNlcnZlcnMuIFRoYXQgaW1wbGllcyB0aGF0IHRo ZSBuZXh0IGNlcnRpZmljYXRlJ3MgKGNhbGwgaXQgSTEpIFNQS0kgaXMgZml4ZWQgYnkgdGhlIGxl YWYgKGJlY2F1c2UgaXQgaGFzIHRvIG1hdGNoIHRoZSBzaWduYXR1cmUgb24gdGhlIGxlYWYpLg0K DQpBYm92ZSB0aGF0LCBvbmUgY291bGQgaW1hZ2luZSB0aGUgY29tYmluYXRpb24gb2Y6DQoqIFRo ZSBzaXRlIGZhaWxzIHRvIGluY2x1ZGUgYW55IGludGVybWVkaWF0ZSBjZXJ0aWZpY2F0ZXMNCiog VGhlIGxlYWYgZG9lc24ndCBpbmNsdWRlIGFuIEF1dGhvcml0eSBLZXkgSWRlbnRpZmllciwgYnV0 IGluY3VkZXMgYW4gQUlBIFVSTCBmb3IgSTENCiogSTEgaXMgcmVwbGFjZWQgd2l0aCBhIGNlcnRp ZmljYXRlIHdpdGggdGhlIHNhbWUgU1BLSSwgYnV0IGEgZGlmZmVyZW50IGlzc3Vlci4NCg0KVGhh dCB3YXkgdGhlIENBIGNvdWxkIHJlZGlyZWN0IHRoZSBjaGFpbiB3aXRob3V0IHRoZSBzaXRlIGtu b3dpbmcuDQpIb3dldmVyLCBpdCByZXF1aXJlcyBhIG1pc2NvbmZpZ3VyYXRpb24gb2YgdGhlIHNp dGUgKHRoYXQgd2lsbCBjYXVzZSBpbnRlcm1pdHRlbnQgaXNzdWVzIGFuZCBzb21lIGNsaWVudHMg dG8gZmFpbCBjb21wbGV0ZWx5KSBhbmQgYSBncm9zc2x5IHN0dXBpZCBDQS4NCg0KT24gdGhlIG90 aGVyIGhhbmQsIHNwZWNpZnlpbmcgdmlhIENBIFN1YmplY3QgbmFtZSBpcyB2ZXJ5IHdlYWs6IGFu eSBDQSBjYW4gaXNzdWUgY2VydGlmaWNhdGVzIHdpdGggYW55IFN1YmplY3QgbmFtZS4NCg0KDQpD aGVlcnMNCg0KQUdMDQoNCi0tDQpBZGFtIExhbmdsZXkgYWdsQGltcGVyaWFsdmlvbGV0Lm9yZyBo dHRwOi8vd3d3LmltcGVyaWFsdmlvbGV0Lm9yZw0K From zack.weinberg@gmail.com Wed Nov 16 17:34: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 A089411E8081 for ; Wed, 16 Nov 2011 17:34:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qoovR9FfBbNR for ; Wed, 16 Nov 2011 17:34:52 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0BC11E8082 for ; Wed, 16 Nov 2011 17:34:52 -0800 (PST) Received: by iaeo4 with SMTP id o4so1737267iae.31 for ; Wed, 16 Nov 2011 17:34:52 -0800 (PST) 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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=biOuUaZivgVqTjLjqgMMrhuRlSyWE0fMMVp3AXHLEhk=; b=BVI4ixzX4No6b5DEr107tfVrqpkv1lZCD1GniKj7W/Hd1Dr6KzXPNBIOCn7KtVQs8p byx0KzQfPD30JDNRXiwwiIAzGSIPYKFiMkp0slJRxFY8ybU4svAJfc7OWV8ZXlgAjDwS XhOonpPUK1GhYjyhn+EofyDlzVlQIoEWdNP8E= Received: by 10.42.176.130 with SMTP id be2mr12662216icb.11.1321493685398; Wed, 16 Nov 2011 17:34:45 -0800 (PST) Received: from ardsley.local (99-113-32-219.lightspeed.sntcca.sbcglobal.net. [99.113.32.219]) by mx.google.com with ESMTPS id e2sm51216695ibe.0.2011.11.16.17.34.44 (version=SSLv3 cipher=OTHER); Wed, 16 Nov 2011 17:34:44 -0800 (PST) Sender: Zack Weinberg Message-ID: <4EC464B3.7070908@sv.cmu.edu> Date: Wed, 16 Nov 2011 17:34:43 -0800 From: Zack Weinberg User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Olafur Gudmundsson References: <4EC2E8CA.1060009@ogud.com> <944D9413-A209-438F-9B6D-17C82A205C75@kirei.se> <162A261A-0872-4ADE-BE87-9F906E93CBED@vpnc.org> <4EC45DAB.9050607@ogud.com> In-Reply-To: <4EC45DAB.9050607@ogud.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] Scope of the protocol document or plea for progress X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 17 Nov 2011 01:34:53 -0000 On 2011-11-16 5:04 PM, Olafur Gudmundsson wrote: > On 17/11/2011 07:01, Paul Hoffman wrote: >> On Nov 17, 2011, at 12:16 AM, Zack Weinberg wrote: >>> If DNSSEC validation state is "bogus", fail association. >>> If DNSSEC validation state is "insecure" or "indeterminate", ignore >>> all TLSA records. > > Yesterday Paul and I talked about this at length, > the DNSSEC-only document might/should give guidance on use policy in > the cases DNSSEC validation can not succeed. Please avoid the term "can not succeed", as it might mean any of the three DNSSEC validation states "bogus", "insecure", or "indeterminate", and they have _very different_ security implications. > There are two possible actions: > Discard TLSA > Specify use policy by TLSA sub-type Also "fail association" = "do not proceed with TLS handshake". > My intention was that the application make that choice I think this would be a mistake. > but > explicitly state for each TLSA sub-type what the default policy for > that sub-type is: I also think it would be a mistake to have the behavior vary based on subtype. > Having said this I realize TLSA is potentially headed for the sub-typing > hell that TXT and NAPTR records suffer from. Quite so. zw From rbarnes@bbn.com Wed Nov 16 17:46: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 DABB211E80B7 for ; Wed, 16 Nov 2011 17:46:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5YvbaymGmKf for ; Wed, 16 Nov 2011 17:46:50 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 490CA11E8081 for ; Wed, 16 Nov 2011 17:46:50 -0800 (PST) Received: from [128.89.255.47] (port=57296) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RQr3v-000NNk-FR; Wed, 16 Nov 2011 20:46:47 -0500 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Richard Barnes In-Reply-To: <4EC45DAB.9050607@ogud.com> Date: Thu, 17 Nov 2011 09:45:46 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <79D495A1-D4CA-41AE-9E3E-B42603346439@bbn.com> References: <4EC2E8CA.1060009@ogud.com> <944D9413-A209-438F-9B6D-17C82A205C75@kirei.se> <162A261A-0872-4ADE-BE87-9F906E93CBED@vpnc.org> <4EC45DAB.9050607@ogud.com> To: Olafur Gudmundsson X-Mailer: Apple Mail (2.1251.1) Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] Scope of the protocol document or plea for progress X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 17 Nov 2011 01:46:51 -0000 Hey Olafur, I think you're re-creating the rathole you were trying to avoid. I = would be satisfied for this document to define a process that terminates = in the same "NO-INFO" state whether there are no records or insecure = records. Re-use recommendations can be addressed in a separate = document. --Richard On Nov 17, 2011, at 9:04 AM, Olafur Gudmundsson wrote: > On 17/11/2011 07:01, Paul Hoffman wrote: >> On Nov 17, 2011, at 12:16 AM, Zack Weinberg wrote: >>=20 >>> If DNSSEC validation state is "bogus", fail association. >>> If DNSSEC validation state is "insecure" or "indeterminate", ignore >>> all TLSA records. >>>=20 >>> That should be all that is needed. >>=20 >>=20 >> I spoke with Olafur last night, and what you state here is not = exactly what he intended. I'll let him say precisely what he intended so = that people who already +1'd can decide if they still feel that way. >>=20 >> --Paul Hoffman >>=20 >>=20 > Yesterday Paul and I talked about this at length, > the DNSSEC-only document might/should give guidance on use policy in > the cases DNSSEC validation can not succeed. >=20 > There are two possible actions: > Discard TLSA > Specify use policy by TLSA sub-type >=20 > My intention was that the application make that choice but > explicitly state for each TLSA sub-type what the default policy for > that sub-type is: > For sub-types 0 and 1 reuse is possible. > For sub-type 2 "MUST ignore" is the only sane policy >=20 > For future sub-types the defining document MUST specify reuse policy. > (For bare keys the MUST ignore is also the only sane policy) >=20 > Thus I amend yesterdays proposal to explicitly put in scope of the = document to specify the usage policy for each sub-type when DNSSEC does = not succeed. > =09 > Having said this I realize TLSA is potentially headed for the = sub-typing hell that TXT and NAPTR records suffer from. > The WG should have a short discussion about the design choice of > "if single RR type or multiple RR types" > is a better way forward and the document should have the > justification for the choice made. >=20 > Olafur >=20 >=20 >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From rbarnes@bbn.com Wed Nov 16 17:47: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 CF8BE1F0C56 for ; Wed, 16 Nov 2011 17:47:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.149 X-Spam-Level: X-Spam-Status: No, score=-106.149 tagged_above=-999 required=5 tests=[AWL=-0.450, 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 6H2WRUSaHD-8 for ; Wed, 16 Nov 2011 17:47:50 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id D14FD1F0C51 for ; Wed, 16 Nov 2011 17:47:49 -0800 (PST) Received: from [128.89.255.47] (port=57296) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RQr4r-000NNk-0q; Wed, 16 Nov 2011 20:47:45 -0500 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: Richard Barnes In-Reply-To: <55221C61-0F07-41F7-9FEE-B98C790E7F3B@nic.cz> Date: Thu, 17 Nov 2011 09:47:43 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <9B4BDD4C-7CF4-4A32-A5CE-95CDB75E0ED9@bbn.com> References: <4EC2E8CA.1060009@ogud.com> <55221C61-0F07-41F7-9FEE-B98C790E7F3B@nic.cz> To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= X-Mailer: Apple Mail (2.1251.1) Cc: dane@ietf.org Subject: Re: [dane] Scope of the protocol document or plea for progress X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 17 Nov 2011 01:47:50 -0000 +1 I've sketched out a client decision process in state table and ASCII art = form below. The process takes a name and a certificate chain, and has = three outcomes:=20 GOOD - DANE indicates that you should accept this certificate chain for = this name BAD - DANE indicates that you should not accept=20 NO-INFO - DANE provides no information about whether you should accept That is, the NO-INFO case is as if there were no DANE records at all = (with secure nonexistence, natch). --Richard -----BEGIN ASCII ART----- +-------------+=20 | name, chain | +-------------+=20 | v /---------------------------\ | IN TLSA _port._proto.name | | with DNSSEC validation | \------------+--------------/ | v +---------+ ********** | bogus? |---Y--->* BAD *<------------+ +----+----+ ********** | | | N N | | v | +---------+ +---------+ +--------+ | secure? |---Y--->| exists? |---Y--->| match? |=20 +---------+ +---------+ +--------+ | | | N N Y | | | v | | *********** | ********** * NO-INFO *<------------+ * GOOD * *********** ********** -----END ASCII ART----- -----BEGIN STATE TABLE----- DNSSEC Exists Matches Outcome =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D bogus * * BAD secure yes no BAD secure yes yes GOOD secure no * NO-INFO other * * NO-INFO -----END STATE TABLE----- On Nov 16, 2011, at 1:21 PM, Ond=C5=99ej Sur=C3=BD wrote: > I very much like the idea of having KISS solution in the DANE protocol = document > and if there's interest (and a volunteer) we can have another I-D = covering > the corner cases. >=20 > Thanks to Olafur for pointing that we could have this in two step = process. >=20 > With my chair hat on - could we get an consensus on: >=20 >> I want to propose that the Current protocol document explicitly only = cover the following case: >> Target zone is DNSSEC signed [1] >> and Consumer performs DNSSEC validation [2] >> and Target zone can be validated by the consumer. >=20 >=20 > I already saw several +1's on the list and I would like to see more > especially from the people who participated in the Taipei WG = discussion > on this topic. >=20 > And here's +1 from me. >=20 > O. >=20 > On 16. 11. 2011, at 6:33, Olafur Gudmundsson wrote: >=20 >>=20 >> Dear colleagues, >>=20 >> I'm getting worried that the WG is falling off the tracks, it is >> getting distracted by trying to address every possible corner case. >>=20 >> I want to propose that the Current protocol document explicitly only = cover the following case: >> Target zone is DNSSEC signed [1] >> and Consumer performs DNSSEC validation [2] >> and Target zone can be validated by the consumer. >>=20 >> In this case there are two positive outcomes: >> - Validated TLSA RRset >> - Proof that the TLSA RRset does not exist >>=20 >> and one Negative outcome: >> - TLSA RRset fails validation >>=20 >> The document should say what the Consumer application does in each = one of these cases for each type TLSA of record i.e. if there is need = to check revocation lists, etc. >>=20 >> For the other cases we just say "The consumer application falls back = to the processing it is currently doing". >>=20 >> This is the 98% solution and the faster we can start deploying it the = better off we are!!!! >>=20 >> A subsequent document can address the transition cases i.e. when >> DNSSEC validation can not succeed due to: >> Breaks in trust chain >> Algorithm mismatch >> Unsigned publisher zone >> No Validating resolver available >> DNSSEC records not getting through >> timeouts >> Incomplete Trust Chain >> etc. >>=20 >> I would call this document >> "Value of TLSA records when DNSSEC validation is not available". >>=20 >> I feel that using words like "DNS optional" does nothing but confuse = both potential publishers and consumers of TLSA records as well as the = implementors. >>=20 >> I want to thank Richard Barnes for forcing me to think though the = implications of his incomplete flow chart on the document. [3] >> My subsequent flowchart takes multiple pages and is not yet complete, = thus I think any document that tries to address those issues will take a = long time to write. Conversely writing such a document will be >> much easier if the positive cases are taken out of it. >>=20 >> Comments >> Olafur >>=20 >> [1] Target zone is the zone the name of the service resides in, i.e. >> the name _443._tcp.gmail.com is in gmail.com or _tcp.gmail.com. >>=20 >> [2] Consumer has a DNSSEC capable validator that she/he trusts the = answer from. >>=20 >> [3] http://tools.ietf.org/agenda/82/slides/dane-2.pdf slide 9. >> _______________________________________________ >> 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 trevorf@exchange.microsoft.com Wed Nov 16 17:48: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 527EA1F0C60 for ; Wed, 16 Nov 2011 17:48:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.658 X-Spam-Level: X-Spam-Status: No, score=-110.658 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 dtFYeC4eg6rs for ; Wed, 16 Nov 2011 17:48:47 -0800 (PST) Received: from mail.exchange.microsoft.com (mail1.exchange.microsoft.com [131.107.1.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9DCC91F0C56 for ; Wed, 16 Nov 2011 17:48:47 -0800 (PST) Received: from df-h14-02.exchange.corp.microsoft.com (157.54.78.140) by DF-G14-01.exchange.corp.microsoft.com (157.54.87.87) with Microsoft SMTP Server (TLS) id 14.2.247.2; Wed, 16 Nov 2011 17:48:47 -0800 Received: from PIO-MLT-05.exchange.corp.microsoft.com (157.54.94.22) by DF-H14-02.exchange.corp.microsoft.com (157.54.78.140) with Microsoft SMTP Server (TLS) id 14.2.247.5; Wed, 16 Nov 2011 17:48:46 -0800 Received: from DF-M14-12.exchange.corp.microsoft.com ([fe80::7c94:4036:120:c95f]) by PIO-MLT-05.exchange.corp.microsoft.com ([fe80::d940:e316:1daa:5e6a%10]) with mapi id 14.02.0247.002; Wed, 16 Nov 2011 17:48:46 -0800 From: Trevor Freeman To: "mrex@sap.com" Thread-Topic: [dane] Fragility of binding to a CA certificate by certificate or Thread-Index: AQHMpKQzT5Qrq39rwU+1rUuUuB6O9pWwSNsg Date: Thu, 17 Nov 2011 01:48:45 +0000 Message-ID: References: from "Trevor Freeman" at Nov 15, 11 12:08:24 pm <201111162110.pAGLAbRs008326@fs4113.wdf.sap.corp> In-Reply-To: <201111162110.pAGLAbRs008326@fs4113.wdf.sap.corp> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dane@ietf.org" Subject: Re: [dane] Fragility of binding to a CA certificate by certificate or X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 17 Nov 2011 01:48:48 -0000 -----Original Message----- From: Martin Rex [mailto:mrex@sap.com]=20 Sent: Thursday, November 17, 2011 5:11 AM To: Trevor Freeman Cc: dane@ietf.org Subject: Re: [dane] Fragility of binding to a CA certificate by certificate= or Trevor Freeman wrote: >=20 > For usage type =3D0, I am concerned about the fragility of matching a CA= =20 > certificate is only by full certificate or SKI. Certificates and keys=20 > have an inherently limited lifetime. That is only a problem for "cert pinning", but not for DANE. [TF] DANE use type =3D0 depends on pkix validation which mends this is an i= ssue for DANE to consider since you are depending on pkix. > > CAs need to renew both as a matter of routine maintenance, which is an=20 > operation outside of the visibility of the domain and updating the=20 > domain DNS record is outside the control of the CA. This is a recipe=20 > for things to go wrong. All a CA can do is notify the domain of the=20 > update and hope they make the change to the DNS record. Renewal of server certificates is an administrative task of the server admi= n, and certificate issuance is irrelevant, the only thing that matters is t= he actual administrative update of the servers certificate on the server it= self. [TF] The critical thing with server certificate renewal is that the site op= erator is fully aware of the new cert so can initiate the update of the DAN= E record of they are using the leaf cert for the DANE record. The CA certificate necessary to verify the server certificate is locked dow= n with the signature on the server certificate and MUST be (per TLS protoco= l spec) sent by the TLS server in the servers certificate handshake message= . [TF] Not true, any CA certificate with the same subject name and key can be= used. The server sends a set of certificates but the client is not obliga= ted to use them. After that, the choice of possible paths is constrained on= ly by what is valid under the relying parties trust policy. DANE does not m= andate that the publish CA certificate be the leaf issuing CA, merely a CA = that the pkix path must intersect.=20 When the CA issues the server certificate unter a different CA cert on serv= er certificate renewal, then the server admin will have to update the DNS T= LSA record before installing the new server certificate, of course. While a CA may "price" this the same as a renewal, it technically is not a renewal, but a different certificate, re= quiring the TLS server to also send a different forward certification path = in the TLS server certificate handshake message, so such a CA better WARNS = it customer with a big red sign when doing this instead of a renewal. [TF] We seem to be in violent agreement. For server certificate renewal th= e site admin has to be in the loop for request\installing the new certifica= te. That is not the case for a CA certificate.=20 >=20 > A more stable CA identifier would be a CA's subject name. > This will remain constant as certificates and keys are renewed. Very bad idea. Every CA in the TLS X.509 PKI can create a subordinate CA w= ith any arbitrary Name in it [TF] As already observed, the pkix validation has many ways to control trus= t in CAs by the relying party.=20 This idea would only work in a strictly hierarchical PKI with a singular ro= ot authority (which does not need to have a root cert, but must have the au= thority to define and enforce the policy by which all CAs in the PKI must b= e operated). [TF] I don't understand the comment. Every pki path is hierarchical and thi= s has no dependency on the number of root authorities. PKI merely defines how to validate a path.=20 [TF] Trevor -Martin From ynir@checkpoint.com Wed Nov 16 17:49: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 740831F0C65 for ; Wed, 16 Nov 2011 17:49:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.452 X-Spam-Level: X-Spam-Status: No, score=-10.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z222Wh-0saFx for ; Wed, 16 Nov 2011 17:49:13 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA451F0C64 for ; Wed, 16 Nov 2011 17:49:12 -0800 (PST) X-CheckPoint: {4EC467BF-4-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id pAH1nAN5006421; Thu, 17 Nov 2011 03:49:10 +0200 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 17 Nov 2011 03:49:10 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Thu, 17 Nov 2011 03:49:10 +0200 From: Yoav Nir To: Olafur Gudmundsson Date: Thu, 17 Nov 2011 03:49:08 +0200 Thread-Topic: [dane] Scope of the protocol document or plea for progress Thread-Index: Acykyxl89r5y2TWBRf6oWIXs0oJCGA== Message-ID: References: <4EC2E8CA.1060009@ogud.com> <944D9413-A209-438F-9B6D-17C82A205C75@kirei.se> <162A261A-0872-4ADE-BE87-9F906E93CBED@vpnc.org> <4EC45DAB.9050607@ogud.com> In-Reply-To: <4EC45DAB.9050607@ogud.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] Scope of the protocol document or plea for progress X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 17 Nov 2011 01:49:13 -0000 On Nov 17, 2011, at 9:04 AM, Olafur Gudmundsson wrote: > On 17/11/2011 07:01, Paul Hoffman wrote: >> On Nov 17, 2011, at 12:16 AM, Zack Weinberg wrote: >>=20 >>> If DNSSEC validation state is "bogus", fail association. >>> If DNSSEC validation state is "insecure" or "indeterminate", ignore >>> all TLSA records. >>>=20 >>> That should be all that is needed. >>=20 >>=20 >> I spoke with Olafur last night, and what you state here is not exactly w= hat he intended. I'll let him say precisely what he intended so that people= who already +1'd can decide if they still feel that way. >>=20 >> --Paul Hoffman >>=20 >>=20 > Yesterday Paul and I talked about this at length, > the DNSSEC-only document might/should give guidance on use policy in > the cases DNSSEC validation can not succeed. >=20 > There are two possible actions: > Discard TLSA > Specify use policy by TLSA sub-type >=20 > My intention was that the application make that choice but > explicitly state for each TLSA sub-type what the default policy for > that sub-type is: > For sub-types 0 and 1 reuse is possible. > For sub-type 2 "MUST ignore" is the only sane policy >=20 I agree with Martin and Zack. A signature that doesn't validate (whether "i= nsecure" or "indeterminate") is like no signature at all, and should be tre= ated the same. Just require DNSSEC. Yoav From rbarnes@bbn.com Wed Nov 16 17:54: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 E98BA1F0C65 for ; Wed, 16 Nov 2011 17:54:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.582 X-Spam-Level: X-Spam-Status: No, score=-106.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 VzCO+xwGioVb for ; Wed, 16 Nov 2011 17:54:14 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1205A1F0C57 for ; Wed, 16 Nov 2011 17:53:46 -0800 (PST) Received: from [128.89.255.47] (port=57333) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RQrAe-0005NA-Bd; Wed, 16 Nov 2011 20:53:44 -0500 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Richard Barnes In-Reply-To: Date: Thu, 17 Nov 2011 09:53:38 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Trevor Freeman X-Mailer: Apple Mail (2.1251.1) Cc: Adam Langley , "dane@ietf.org" Subject: Re: [dane] Fragility of binding to a CA certificate by certificate or ski X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 17 Nov 2011 01:54:15 -0000 So are you not concerned about the following attack? 1. example.com provisions a DANE record saying that any cert that comes = under the CA "CN=3Dsuper-trusted-ca.com" is OK for that domain 2. Nefarious attacker generates a cert with his own key pair and = "CN=3Dsuper-trusted-ca.com" 3. Nefarious attacker MitMs a TLS session to example.com and presents = his cert 4. Client looks at the cert, sees the right name, and blissfully = proceeds with the hijacked session In light of this, any discussion of binding only to names is ridiculous. = I think this is what Adam was trying to say, a bit more politely. --RIchard On Nov 17, 2011, at 9:31 AM, Trevor Freeman wrote: > Hi And, >=20 > Pkix has many controls to control trust in CAs. There are more = controls for trust in CAs certificates than those over end entities. We = are talking about usage type =3D0 so the relying party has full control = over their own pkix policy. >=20 > I agree that matching SKI is a stronger binding but it is not = necessary more robust if it results in loss of service. It=92s a much a = business rick determination if the site want to trade higher = availability for a stronger binding. They are best placed to determine = scale of impact from loss of service vs. an active attack. >=20 > Given we are anticipating a work with DNSSEC, the attacker now has to = obtain a site certificate and compromise some part of the routing = infrastructure for the mark so they can perform address mapping to = redirect the ip traffic to the bogus site. That is not an attack that = scales well but if the CA changes its key and the site did not update = its DNS record, the site is down. >=20 > Adam, you need to check 5280 section 6. Pkix chaining is name based = not key based. Yes it checks the signatures but SKI\AKI matching is not = used in any way. >=20 > Matching by subject name presents a strong CA binding mechanism which = is more robust against configuration mismatch - hence delver's higher = availability.=20 >=20 > Trevor >=20 > -----Original Message----- > From: alangley@gmail.com [mailto:alangley@gmail.com] On Behalf Of Adam = Langley > Sent: Wednesday, November 16, 2011 11:38 AM > To: Trevor Freeman > Cc: dane@ietf.org > Subject: Re: [dane] Fragility of binding to a CA certificate by = certificate or ski >=20 > On Tue, Nov 15, 2011 at 7:08 AM, Trevor Freeman = wrote: >> For usage type =3D0, I am concerned about the fragility of matching a = CA=20 >> certificate is only by full certificate or SKI. Certificates and keys=20= >> have an inherently limited lifetime. >=20 > You are correct that matching by a certificate is a mistake because = CAs often reissue their CA certificates and clients build chains from = the bottom up. >=20 > However, matching a SubjectPublicKeyInfo is rather robust. Certainly = the leaf certificate cannot change without a site reconfiguring their = servers. That implies that the next certificate's (call it I1) SPKI is = fixed by the leaf (because it has to match the signature on the leaf). >=20 > Above that, one could imagine the combination of: > * The site fails to include any intermediate certificates > * The leaf doesn't include an Authority Key Identifier, but incudes an = AIA URL for I1 > * I1 is replaced with a certificate with the same SPKI, but a = different issuer. >=20 > That way the CA could redirect the chain without the site knowing. > However, it requires a misconfiguration of the site (that will cause = intermittent issues and some clients to fail completely) and a grossly = stupid CA. >=20 > On the other hand, specifying via CA Subject name is very weak: any CA = can issue certificates with any Subject name. >=20 >=20 > Cheers >=20 > AGL >=20 > -- > Adam Langley agl@imperialviolet.org http://www.imperialviolet.org > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From i.grok@comcast.net Wed Nov 16 17:57: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 EF3A51F0C7E for ; Wed, 16 Nov 2011 17:57:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kxCYtA7tP2uU for ; Wed, 16 Nov 2011 17:57:46 -0800 (PST) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [76.96.27.228]) by ietfa.amsl.com (Postfix) with ESMTP id 77A8C1F0C7C for ; Wed, 16 Nov 2011 17:57:46 -0800 (PST) Received: from omta23.emeryville.ca.mail.comcast.net ([76.96.30.90]) by qmta15.emeryville.ca.mail.comcast.net with comcast id y0l51h0051wfjNsAF1xeB3; Thu, 17 Nov 2011 01:57:38 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta23.emeryville.ca.mail.comcast.net with comcast id y1tt1h00J00PQ6U8j1tttr; Thu, 17 Nov 2011 01:53:54 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.4/8.14.3) with ESMTP id pAH1vgvp017736 for ; Wed, 16 Nov 2011 20:57:42 -0500 Received: (from draco@localhost) by odin.ulthar.us (8.14.4/8.14.4/Submit) id pAH1vg5T017735 for dane@ietf.org; Wed, 16 Nov 2011 20:57:42 -0500 Date: Wed, 16 Nov 2011 20:57:42 -0500 From: Scott Schmit To: dane@ietf.org Message-ID: <20111117015742.GA3911@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <4EC2E8CA.1060009@ogud.com> <944D9413-A209-438F-9B6D-17C82A205C75@kirei.se> <162A261A-0872-4ADE-BE87-9F906E93CBED@vpnc.org> <4EC45DAB.9050607@ogud.com> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="HlL+5n6rz5pIUxbD" Content-Disposition: inline In-Reply-To: <4EC45DAB.9050607@ogud.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Scope of the protocol document or plea for progress X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 17 Nov 2011 01:57:47 -0000 --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 17, 2011 at 09:04:43AM +0800, Olafur Gudmundsson wrote: > Yesterday Paul and I talked about this at length, > the DNSSEC-only document might/should give guidance on use policy in > the cases DNSSEC validation can not succeed. >=20 > There are two possible actions: > Discard TLSA > Specify use policy by TLSA sub-type >=20 > My intention was that the application make that choice but > explicitly state for each TLSA sub-type what the default policy for > that sub-type is: > For sub-types 0 and 1 reuse is possible. > For sub-type 2 "MUST ignore" is the only sane policy >=20 > For future sub-types the defining document MUST specify reuse policy. > (For bare keys the MUST ignore is also the only sane policy) I'm sorry, it's been a long day, so maybe I'm missing the obvious, but what do you mean by "reuse policy"? Reuse of what? --=20 Scott Schmit --HlL+5n6rz5pIUxbD Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQJgYJKoZIhvcNAQcCoIIQFzCCEBMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DVcwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBxswggYDoAMCAQICAwK+HTANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTExMDcxNzA1 MDQwNFoXDTEyMDcxNzExNDI1OVowYjEgMB4GA1UEDRMXNDY1MjU2LTBnRmI2Sk5ZWW44QnFW bUwxGzAZBgNVBAMMEmkuZ3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9r QGNvbWNhc3QubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2AjLOMsBGaqN hv2FcRbfom/QCeKMXu5tUd1JY5oIDZe5y29stnd+se/zUlEkiVeMam4Jgo1c8yGNnwLVYc5/ 9xVi7Qg1Is5b9AB6aJWElJDw/jIdihymNZ2kwkSLT0wl/lzd0mXlwFJPRgQiRkmE6V0ZmjsQ jaVtllVleGBbMvmWPm92e+4Bju9P81kKz7Xr02ijETmaPdVsl+jmOaKPS8Y+2Lat2xus4Ked oJ/7aIWIpz1gRSKjAHSZ1Wmwi2TYUjYhZryChu9e1RWtqk1CycNoeusJ8xdEVN3WSnJ299w/ 3ltK/x/9rpj2j9ShQZVB4NnX6cjQs7pz1lVxvIkjcQIDAQABo4IDrTCCA6kwCQYDVR0TBAIw ADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBQ29j2I0O8sRYi0So9NwwmT1caakDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhR gjAdBgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwggIhBgNVHSAEggIYMIICFDCCAhAG CysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJt ZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUF BwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJp bGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFu ZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0 cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQAZ5U0nL/2PQwsVfHgN7MVPbZEGzDzuj4Oy pTgz4XQFwPcCuy6U9sp1Dwmo3DyKX5nKN4xA7pslN+2Pl/kElGamX7zMCAH0xED0RTOLyk+v nDML4s+OUtWaYVnq1bZEp0F8Luq3zIslAYSebleyiz8M0EypZczsL5rOk86R2F9EYw1CBuFJ 5a4x0CmNu5o30fGNDFt+iXRlbJPp/KY25iUgVnBzJ4COT5kQjxn5lgr4t1I+BDCL5HQQ3h/8 2CzwrWVRBNb9Vqh9LL1ZtzYRt8JezoB6HkVvcKVNGlCZ+/MnvfMzPLwfbTDZC8o4d+4RH6aE LeGF2XmAOaenc/YRqm9oMYIClzCCApMCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQIDAr4dMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTExMTE3MDE1NzQyWjAjBgkqhkiG9w0BCQQxFgQUsBncLagi vxb0wLgiupWVjz3S8IoweQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAb24aeXce PmFC7QC33olwErEfYbDkBdODQq/1JMKZv0rXncVBK2ruiIXOBs3dqF1kTGsE+vNwXzywJUu/ aNDYxRsoKdow5YJ1+/QkXosul9TpJ+aYMTgid3FuuhXx/Es+loBgjqnAWQw+wxO4ISCbL8w9 imVa9PURx/yKg3vJp3EE53LQ5ucOZGqIsyLVrRGascfQvC2kwUzzDEvePGHvIFlsViYQ5z3F 96O0LAYOCJ5tQfouZyMDXZVMvxx48JXN2QH4CrIzAeVby7vyvQzJ5Ve16re3BHmIMCMW3wO1 JHw48PgAzI8qjyEvDq5Hd6hJKJxTGv7SI5Q5V++SVZmx7A== --HlL+5n6rz5pIUxbD-- From zack.weinberg@gmail.com Wed Nov 16 17:59: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 274821F0C64 for ; Wed, 16 Nov 2011 17:59:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.857 X-Spam-Level: X-Spam-Status: No, score=-2.857 tagged_above=-999 required=5 tests=[AWL=0.120, 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 7cywv1mxUX46 for ; Wed, 16 Nov 2011 17:59:05 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4121F0C4A for ; Wed, 16 Nov 2011 17:59:05 -0800 (PST) Received: by faap16 with SMTP id p16so2993968faa.31 for ; Wed, 16 Nov 2011 17:59:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=/0m/53ZRjn8lHhY92PJowJh3H0xm7xg/2eufmA5+PwI=; b=PYQkl9bFohrY/tslgY/FnkL+xr94LuTABzyIau/xSyyV1tftM0L+KQ5sJym7DqRiQt cbQBB4JLfiIIcRPt8v1hQgElktV0zV9St7ZhD0QoNr0ycRkFDXwwwtPKFTwQrJzv1RWz HPVf37JDmMEguHhmiA7pk4N6hwKsmCPm4rIeU= MIME-Version: 1.0 Received: by 10.182.169.34 with SMTP id ab2mr9543808obc.27.1321495144263; Wed, 16 Nov 2011 17:59:04 -0800 (PST) Sender: zack.weinberg@gmail.com Received: by 10.182.88.103 with HTTP; Wed, 16 Nov 2011 17:59:04 -0800 (PST) In-Reply-To: <9B4BDD4C-7CF4-4A32-A5CE-95CDB75E0ED9@bbn.com> References: <4EC2E8CA.1060009@ogud.com> <55221C61-0F07-41F7-9FEE-B98C790E7F3B@nic.cz> <9B4BDD4C-7CF4-4A32-A5CE-95CDB75E0ED9@bbn.com> Date: Wed, 16 Nov 2011 17:59:04 -0800 X-Google-Sender-Auth: Bt9ql07XYocvJTwRXw-CEg6cN7o Message-ID: From: Zack Weinberg To: Richard Barnes , IETF DANE WG list Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [dane] Scope of the protocol document or plea for progress X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 17 Nov 2011 01:59:06 -0000 On Wed, Nov 16, 2011 at 5:47 PM, Richard Barnes wrote: > +1 > > I've sketched out a client decision process in state table and ASCII art = form below. =C2=A0The process takes a name and a certificate chain, and has= three outcomes: > > GOOD - DANE indicates that you should accept this certificate chain for t= his name > BAD - DANE indicates that you should not accept > NO-INFO - DANE provides no information about whether you should accept This I can support, and the flowchart looks right to me. I would add one additional thing: go to state BAD if the *address record* lookup comes back "bogus", and to NO-INFO if that came back non-"secure". (I can't immediately think of a scenario where forging A(AAA) but not TLSA leads to anything worse than denial of service, since if the attacker can produce a cert chain that matches the legitimate TLSA records you've already lost; but I'm not certain there isn't one and extra defensiveness can't hurt.) zw From paul.hoffman@vpnc.org Wed Nov 16 18:14: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 E9C631F0C81 for ; Wed, 16 Nov 2011 18:14:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1NRK7fV+PcE8 for ; Wed, 16 Nov 2011 18:14:28 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 77F4F1F0C3D for ; Wed, 16 Nov 2011 18:14:28 -0800 (PST) Received: from dhcp-2121.meeting.ietf.org (dhcp-2121.meeting.ietf.org [130.129.33.33]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id pAH2EObV090201 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 16 Nov 2011 19:14:25 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Paul Hoffman In-Reply-To: Date: Thu, 17 Nov 2011 10:14:25 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4FC32BEF-E1F5-45D5-9092-D3CE9EB739D0@vpnc.org> References: <4EC2E8CA.1060009@ogud.com> <944D9413-A209-438F-9B6D-17C82A205C75@kirei.se> <162A261A-0872-4ADE-BE87-9F906E93CBED@vpnc.org> <4EC45DAB.9050607@ogud.com> To: IETF DANE WG list X-Mailer: Apple Mail (2.1251.1) Subject: Re: [dane] Scope of the protocol document or plea for progress X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 17 Nov 2011 02:14:29 -0000 On Nov 17, 2011, at 9:49 AM, Yoav Nir wrote: > I agree with Martin and Zack. A signature that doesn't validate = (whether "insecure" or "indeterminate") is like no signature at all, and = should be treated the same. Define "the same": you can use the data you got if you want, or act as = if you didn't the data. Extra points for saying if it is true for all = three types. > Just require DNSSEC. OK, but what does that mean if DNSSEC is required and the data comes as = "indeterminate"? --Paul Hoffman From paul@xelerance.com Wed Nov 16 18:19: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 3382311E8090 for ; Wed, 16 Nov 2011 18:19:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.48 X-Spam-Level: X-Spam-Status: No, score=-6.48 tagged_above=-999 required=5 tests=[AWL=0.119, 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 E5AMKhDeDeHz for ; Wed, 16 Nov 2011 18:19:44 -0800 (PST) Received: from mx.xelerance.com (mx.xelerance.com [193.110.157.188]) by ietfa.amsl.com (Postfix) with ESMTP id 4664511E8081 for ; Wed, 16 Nov 2011 18:19:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx.xelerance.com (Postfix) with ESMTP id 97512F24; Wed, 16 Nov 2011 21:19:42 -0500 (EST) 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=1321496381; x= 1322101181; bh=vGDyU9MM9sSlmjvdxRfbqOLSQqKNBA0T7nQg38ZLNV4=; b=N evpYPBBZP53+/+pr0oI3j7zE8FrVyZ4nX6LYb1glF/fXrjmCDzg4EfB8LKK1cXEo gnSe8dnEaepVHpbZ340UpF9LicsTqdis6cGjM2SZGwliFkCGTZoBeQo8C8t9EECh i1yb444K5KOzbP4hh8EILGi6OtlhZt5G3APwVAbO54= 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 qP5Rsw7sOTsX; Wed, 16 Nov 2011 21:19:41 -0500 (EST) 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 C0E6F65; Wed, 16 Nov 2011 21:19:41 -0500 (EST) Received: by mail.xelerance.com (Postfix, from userid 1001) id 792D0555; Wed, 16 Nov 2011 21:19:41 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.xelerance.com (Postfix) with ESMTP id 7049426A; Wed, 16 Nov 2011 21:19:41 -0500 (EST) Date: Wed, 16 Nov 2011 21:19:41 -0500 (EST) From: Paul Wouters To: Olafur Gudmundsson In-Reply-To: <4EC45DAB.9050607@ogud.com> Message-ID: References: <4EC2E8CA.1060009@ogud.com> <944D9413-A209-438F-9B6D-17C82A205C75@kirei.se> <162A261A-0872-4ADE-BE87-9F906E93CBED@vpnc.org> <4EC45DAB.9050607@ogud.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] Scope of the protocol document or plea for progress X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 17 Nov 2011 02:19:45 -0000 On Thu, 17 Nov 2011, Olafur Gudmundsson wrote: > Thus I amend yesterdays proposal to explicitly put in scope of the document > to specify the usage policy for each sub-type when DNSSEC does not succeed. I think the WG name and charter says it all: DNS-based Authentication of Named Entities Specify mechanisms and techniques that allow Internet applications to establish cryptographically secured communications by using information distributed through DNSSEC for discovering and authenticating public keys which are associated with a service located at a domain name. It was no accident that it did not talk about non-DNSSEC and/or non-authenticated DNS records. > Having said this I realize TLSA is potentially headed for the sub-typing hell > that TXT and NAPTR records suffer from. > The WG should have a short discussion about the design choice of > "if single RR type or multiple RR types" > is a better way forward and the document should have the > justification for the choice made. That's because some people want to stuff the whole OID PKIX tree in there. I think sub types for CA, EE and pubkey are reasonable. I have no idea what other identifiers one could want that do not fall within one of these three types. Paul From ynir@checkpoint.com Wed Nov 16 18:23: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 5D8DB1F0C5E for ; Wed, 16 Nov 2011 18:23:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.422 X-Spam-Level: X-Spam-Status: No, score=-10.422 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZiTc6JfxQqtz for ; Wed, 16 Nov 2011 18:23:34 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 265D31F0C54 for ; Wed, 16 Nov 2011 18:23:32 -0800 (PST) X-CheckPoint: {4EC46FCB-0-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id pAH2NUrm011253; Thu, 17 Nov 2011 04:23:30 +0200 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 17 Nov 2011 04:23:30 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Thu, 17 Nov 2011 04:23:30 +0200 From: Yoav Nir To: Paul Hoffman Date: Thu, 17 Nov 2011 04:23:28 +0200 Thread-Topic: [dane] Scope of the protocol document or plea for progress Thread-Index: Acykz+S8SXYJtA4bRuWsOxRZVG9SUA== Message-ID: References: <4EC2E8CA.1060009@ogud.com> <944D9413-A209-438F-9B6D-17C82A205C75@kirei.se> <162A261A-0872-4ADE-BE87-9F906E93CBED@vpnc.org> <4EC45DAB.9050607@ogud.com> <4FC32BEF-E1F5-45D5-9092-D3CE9EB739D0@vpnc.org> In-Reply-To: <4FC32BEF-E1F5-45D5-9092-D3CE9EB739D0@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: IETF DANE WG list Subject: Re: [dane] Scope of the protocol document or plea for progress X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 17 Nov 2011 02:23:39 -0000 On Nov 17, 2011, at 10:14 AM, Paul Hoffman wrote: > On Nov 17, 2011, at 9:49 AM, Yoav Nir wrote: >=20 >> I agree with Martin and Zack. A signature that doesn't validate (whether= "insecure" or "indeterminate") is like no signature at all, and should be = treated the same. >=20 > Define "the same": you can use the data you got if you want, or act as if= you didn't the data. Extra points for saying if it is true for all three t= ypes. Revert to the behavior the client would have if there had been no TLSA reco= rd at all. Yes, do it for all types. >=20 >> Just require DNSSEC. >=20 >=20 > OK, but what does that mean if DNSSEC is required and the data comes as "= indeterminate"? Ignore the TLSA record. Client falls back to the same behavior it would hav= e if no TLSA record had ever been received. And that probably means revert to PKIX. And yes, in case #2 that means eith= er fail association, or the way browsers do it today - with a big red warni= ng screen. From paul@xelerance.com Wed Nov 16 18:26: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 AAEB511E80B0 for ; Wed, 16 Nov 2011 18:26:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.556 X-Spam-Level: X-Spam-Status: No, score=-4.556 tagged_above=-999 required=5 tests=[AWL=-1.815, BAYES_00=-2.599, FRT_PROFIT1=3.858, 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 vg-GyAMGnzeO for ; Wed, 16 Nov 2011 18:26:21 -0800 (PST) Received: from mx.xelerance.com (mx.xelerance.com [193.110.157.188]) by ietfa.amsl.com (Postfix) with ESMTP id 0292811E80AF for ; Wed, 16 Nov 2011 18:26:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx.xelerance.com (Postfix) with ESMTP id 79D717F1; Wed, 16 Nov 2011 21:26:19 -0500 (EST) 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=1321496778; x= 1322101578; bh=dntCN6QfqjWUSe/T6/3C7N1OG+08jtX0txHU55t+ADs=; b=R VvylyCWpEXaUD6H5F3o2IjbAKrZSBvSwetRJjLqQqaEKc6RYfNBvOCW1iR9Rie0q 3Td554EVfhy9i0k56F8tAc06rwtc9139Jk/o0KXSyWf4wjHWh+Iy0rR7fVWl2k8K Yzy6W+Pq9X+nRUaT5GhXkiFgDaqfh7x+cyJAh0oDKo= 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 K9rBRLkkwb3T; Wed, 16 Nov 2011 21:26:18 -0500 (EST) 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 565FA65; Wed, 16 Nov 2011 21:26:18 -0500 (EST) Received: by mail.xelerance.com (Postfix, from userid 1001) id 2568E36B; Wed, 16 Nov 2011 21:26:18 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.xelerance.com (Postfix) with ESMTP id 1FF0526A; Wed, 16 Nov 2011 21:26:18 -0500 (EST) Date: Wed, 16 Nov 2011 21:26:18 -0500 (EST) From: Paul Wouters To: Paul Hoffman In-Reply-To: <4FC32BEF-E1F5-45D5-9092-D3CE9EB739D0@vpnc.org> Message-ID: References: <4EC2E8CA.1060009@ogud.com> <944D9413-A209-438F-9B6D-17C82A205C75@kirei.se> <162A261A-0872-4ADE-BE87-9F906E93CBED@vpnc.org> <4EC45DAB.9050607@ogud.com> <4FC32BEF-E1F5-45D5-9092-D3CE9EB739D0@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] Scope of the protocol document or plea for progress X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 17 Nov 2011 02:26:21 -0000 On Thu, 17 Nov 2011, Paul Hoffman wrote: > OK, but what does that mean if DNSSEC is required and the data comes as "indeterminate"? I'm not sure I understand the "indeterminate" state. You either got the TLSA record with proper DNSSEC validation, or you got the proof it does not exist, or you got a bogus answer, or you got a TLSA record which provably has no protection. In the first case you proceed only if the TLSA matches the TLS Server cert. In the second case you proceed without the use of TLSA. In the third case you reject the TLSA record and either abort or continue without TLSA depending on local policy. In the fourth case you ignore the TLSA record as if it did not exist (as you don't want someone spoofing it causing you to abort connecting and attempt other auth schemes like PKIX) Am I missing something? Paul From paul.hoffman@vpnc.org Wed Nov 16 18:34: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 B74DE1F0C69 for ; Wed, 16 Nov 2011 18:34:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.67 X-Spam-Level: X-Spam-Status: No, score=-100.67 tagged_above=-999 required=5 tests=[AWL=-1.929, BAYES_00=-2.599, FRT_PROFIT1=3.858, 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 o6ZlF-83dzN1 for ; Wed, 16 Nov 2011 18:34:58 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 48C161F0C38 for ; Wed, 16 Nov 2011 18:34:58 -0800 (PST) Received: from dhcp-2121.meeting.ietf.org (dhcp-2121.meeting.ietf.org [130.129.33.33]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id pAH2YtTW090811 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 16 Nov 2011 19:34:57 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Thu, 17 Nov 2011 10:34:56 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4D865969-8E8A-4252-A797-710BB66F9FF3@vpnc.org> References: <4EC2E8CA.1060009@ogud.com> <944D9413-A209-438F-9B6D-17C82A205C75@kirei.se> <162A261A-0872-4ADE-BE87-9F906E93CBED@vpnc.org> <4EC45DAB.9050607@ogud.com> <4FC32BEF-E1F5-45D5-9092-D3CE9EB739D0@vpnc.org> To: Paul Wouters X-Mailer: Apple Mail (2.1251.1) Cc: IETF DANE WG list Subject: Re: [dane] Scope of the protocol document or plea for progress X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 17 Nov 2011 02:34:58 -0000 On Nov 17, 2011, at 10:26 AM, Paul Wouters wrote: > I'm not sure I understand the "indeterminate" state. RFC 4033: Indeterminate: There is no trust anchor that would indicate that a specific portion of the tree is secure. This is the default operation mode. > You either got the TLSA record with > proper DNSSEC validation, or you got the proof it does not exist, or = you got a bogus answer, > or you got a TLSA record which provably has no protection. According to the standard we are talking about, it is the latter. > In the first case you proceed only if the TLSA matches the TLS Server = cert. > In the second case you proceed without the use of TLSA. > In the third case you reject the TLSA record and either abort or = continue without TLSA > depending on local policy. > In the fourth case you ignore the TLSA record as if it did not exist = (as you don't want > someone spoofing it causing you to abort connecting and attempt other = auth schemes like PKIX) That is a reasonable choice, and not the only one. > Am I missing something? Maybe that there might be people with different opinions? --Paul Hoffman From mrex@sap.com Wed Nov 16 20:02: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 E438011E80B3 for ; Wed, 16 Nov 2011 20:02:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.145 X-Spam-Level: X-Spam-Status: No, score=-10.145 tagged_above=-999 required=5 tests=[AWL=0.104, 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 oREoeL3ukpS4 for ; Wed, 16 Nov 2011 20:02:40 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id E976B11E80B0 for ; Wed, 16 Nov 2011 20:02:39 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id pAH42Xj2016611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 17 Nov 2011 05:02:33 +0100 (MET) From: Martin Rex Message-Id: <201111170402.pAH42WY8002548@fs4113.wdf.sap.corp> To: trevorf@exchange.microsoft.com (Trevor Freeman) Date: Thu, 17 Nov 2011 05:02:32 +0100 (MET) In-Reply-To: from "Trevor Freeman" at Nov 17, 11 01:48:45 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] Fragility of binding to a CA certificate by 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, 17 Nov 2011 04:02:41 -0000 (Your MUA's quoting style/settings seems completely hosed.) Trevor Freeman wrote: > > Martin Rex wrote: > > > > The CA certificate necessary to verify the server certificate is > > locked down with the signature on the server certificate and MUST > > be (per TLS protocol spec) sent by the TLS server in the servers > > certificate handshake message. > > [TF] Not true, any CA certificate with the same subject name and key > can be used. There are a number of broken TLS peers out there that perform discovery instead of straight path validation, but that doesn't meant that it is a good idea. > > The server sends a set of certificates but the client is not obligated > to use them. But should unconditionally abort when the path conveyed by the server(!) does not validate, i.e. when the server included an expired cert. Btw. no sane CA should issue a cert with a validity beyond the CAs own certificate. That would be stupid and calling for trouble. But I see that a common, and obviously very error prone custom, such as conveying a server credential as a pitiful single certificate instead of a sensibly bagged complete certification path, could lead to the situation where a newly received server certificate might outlive and old (intermediate) CA cert that is locally available and get used erroneouly when the local PKI software does not perform a certificate path validation against both, current time and a second before the end-entities validto date and report the error upfront, but blindly believes that inspite of arbitrarily mixing and matching certificates into a certification path and hoping for the best is "good enough". That happens more likely for developers who either do not provide support for what they ship or are walled off from the support load their solutions create. I do remember that when I was first exposed to SSL & X.509 in 2001 as a developer, I experimented with the test area of "Thawte", and in their test area you could select whether to receive the CA response as pitiful singular cert of PKCS#7 bag of a cert chain. They had a notice on their page indicating that they expected PKCS#7 responses to become the standard and pitiful singular cert response to become deprecated soon. Unfortunately that migration never happened, and there is a significant amount of PKI software with only brittle and vague idea of "PKI credential management" providing plenty of administrative pitfalls that would be trivially and completely avoidable. As it turns out, the extreme laissez-faire approach of OpenSSL & Apache to credential management is a major cause of misconfigured TLS servers (by having the certification path spread out over entirely independent files and complete absence of a "credential management" concept that will ensure the server's forward certification path is validated at least once during installation of a new server certificate.) An implementors approach to make a random pick about the value for a protocol option, in combination with that pick not blowing up on a very limited (read statistically insignificant) black-box test with all default settings, is what caused Win7 to get shipped with invalid RSA pre-master secret check on renegotiaton handshakes and causes interop-problems when activating TLSv1.2 because of the unconditional use of { 0x03,0x03 } for the record layer protocol_version instead of only for the ClientHello.client_version on the initial ClientHello. > > After that, the choice of possible paths is constrained only by what > is valid under the relying parties trust policy. DANE does not mandate > that the publish CA certificate be the leaf issuing CA, merely a CA > that the pkix path must intersect. It OUGHT to be a certificate from the forward path that the server sends within the server certificate handshake message. If we do not have that in the DANE protocol I-D, then we ought to put it in. And clients ought to ensure that they *ALL* use the CA cert from the server's Certificate handshake message when they perform the DANE validation, because only for that cert an synchronous update of the cert itself and the DNS DANE record can be ensured by the server admin. Distribution of renewed intermediate CA certs to clients will be completely random and diverse -- if at all. > > > (about unique CA subject names) > > > > This idea would only work in a strictly hierarchical PKI with a singular > > root authority (which does not need to have a root cert, but must have > > the authority to define and enforce the policy by which all CAs in the > > PKI must be operated). > > [TF] I don't understand the comment. Every pki path is hierarchical > and this has no dependency on the number of root authorities. PKI > merely defines how to validate a path. Unique CA subject names and Name constraints extension can only work in a strictly hierarchical PKI with ONE SINGLE root authority. The TLS X.509 PKI has plenty of completely independent, omnipotent root authorities. The windows trust anchor store maintained by Microsoft for Windows XP contains about 300 individual rootCA certificates today. And with big companies, such as Microsoft and Google, and government agencies such as DHS operating their own, fully trusted, omnipotent CA, you really ought to link your trust to specific keys rather than to names that can be spoofed by probably several hundred independent organizations around the globe (or anyone that manages to create a valid CA cert und any one of those, either by break-in or by collision precomputation or an MD2 or MD5 preimage attack on one of the tainted old rootCA certs. -Martin From trevorf@exchange.microsoft.com Wed Nov 16 21:56: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 29CFD11E8112 for ; Wed, 16 Nov 2011 21:56:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.652 X-Spam-Level: X-Spam-Status: No, score=-110.652 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 IXlXtCiHRuZA for ; Wed, 16 Nov 2011 21:56:30 -0800 (PST) Received: from mail.exchange.microsoft.com (mail7.exchange.microsoft.com [131.107.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id ECF9C11E8106 for ; Wed, 16 Nov 2011 21:56:29 -0800 (PST) Received: from df-h14-02.exchange.corp.microsoft.com (157.54.78.140) by DF-G14-02.exchange.corp.microsoft.com (157.54.87.56) with Microsoft SMTP Server (TLS) id 14.2.247.2; Wed, 16 Nov 2011 21:56:29 -0800 Received: from PIO-MLT-06.exchange.corp.microsoft.com (157.54.94.24) by DF-H14-02.exchange.corp.microsoft.com (157.54.78.140) with Microsoft SMTP Server (TLS) id 14.2.247.5; Wed, 16 Nov 2011 21:56:29 -0800 Received: from DF-M14-12.exchange.corp.microsoft.com ([fe80::7c94:4036:120:c95f]) by PIO-MLT-06.exchange.corp.microsoft.com ([fe80::d57f:521a:3ae6:c130%10]) with mapi id 14.02.0247.002; Wed, 16 Nov 2011 21:56:28 -0800 From: Trevor Freeman To: Richard Barnes Thread-Topic: [dane] Fragility of binding to a CA certificate by certificate or ski Thread-Index: Acyk7Zq4S+gnZYKDSF2buXtuovJkWQ== Date: Thu, 17 Nov 2011 05:56:28 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Adam Langley , "dane@ietf.org" Subject: Re: [dane] Fragility of binding to a CA certificate by certificate or ski X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 17 Nov 2011 05:56:31 -0000 Hi Richard, You description does not match what use type =3D0 It would have been helpful if document somewhere the threats you want to m= itigate, vs. the threats you are not mitigating as it helps such discussion= s.=20 We need clarity around what threats DNSSEC addresses and what value DANE ad= ds over just DNSSEC. The threats highlighted in 6394 is a DNS name resolver= attack which is intrinsically blocked by DNSSEC. Today, DNS based attacks = are fairly cheap and easy to use.=20 Getting a bogus EE certificate is a district threat from a CA certificate. = I can stop trust in a CA certificate issued from an instance of a CA by co= nstraining the path length of the CA certificate which is what is happening= today. This mitigates the threat of an attacker getting a CA certificate f= rom that CA. Equally since the relying party is using full pkix validation they can impo= se restrictions on the set of certificate policies - which again make it im= possible for any CA to issue a certificate with the right name and the righ= t policy since the policy is constrained from the root CA down.=20 There are these many reasons why when the client tries to validate the cert= ificate issued by the bogus CA with the same name as published by DANE, why= pkix will reject the certificate path based on the relying party trust pol= icy.=20 You may want to clarity what threats you are anticipating for how the attac= ker mounts the mitm attack with DNSSEC since you now have the right ip addr= esses. =20 Trevor =20 -----Original Message----- From: Richard Barnes [mailto:rbarnes@bbn.com]=20 Sent: Thursday, November 17, 2011 9:54 AM To: Trevor Freeman Cc: Adam Langley; dane@ietf.org Subject: Re: [dane] Fragility of binding to a CA certificate by certificate= or ski So are you not concerned about the following attack? 1. example.com provisions a DANE record saying that any cert that comes und= er the CA "CN=3Dsuper-trusted-ca.com" is OK for that domain 2. Nefarious attacker generates a cert with his own key pair and "CN=3Dsupe= r-trusted-ca.com" 3. Nefarious attacker MitMs a TLS session to example.com and presents his c= ert 4. Client looks at the cert, sees the right name, and blissfully proceeds w= ith the hijacked session In light of this, any discussion of binding only to names is ridiculous. I= think this is what Adam was trying to say, a bit more politely. --RIchard On Nov 17, 2011, at 9:31 AM, Trevor Freeman wrote: > Hi And, >=20 > Pkix has many controls to control trust in CAs. There are more controls f= or trust in CAs certificates than those over end entities. We are talking a= bout usage type =3D0 so the relying party has full control over their own p= kix policy. >=20 > I agree that matching SKI is a stronger binding but it is not necessary m= ore robust if it results in loss of service. It's a much a business rick de= termination if the site want to trade higher availability for a stronger bi= nding. They are best placed to determine scale of impact from loss of servi= ce vs. an active attack. >=20 > Given we are anticipating a work with DNSSEC, the attacker now has to obt= ain a site certificate and compromise some part of the routing infrastructu= re for the mark so they can perform address mapping to redirect the ip traf= fic to the bogus site. That is not an attack that scales well but if the CA= changes its key and the site did not update its DNS record, the site is do= wn. >=20 > Adam, you need to check 5280 section 6. Pkix chaining is name based not k= ey based. Yes it checks the signatures but SKI\AKI matching is not used in= any way. >=20 > Matching by subject name presents a strong CA binding mechanism which is = more robust against configuration mismatch - hence delver's higher availabi= lity.=20 >=20 > Trevor >=20 > -----Original Message----- > From: alangley@gmail.com [mailto:alangley@gmail.com] On Behalf Of Adam=20 > Langley > Sent: Wednesday, November 16, 2011 11:38 AM > To: Trevor Freeman > Cc: dane@ietf.org > Subject: Re: [dane] Fragility of binding to a CA certificate by=20 > certificate or ski >=20 > On Tue, Nov 15, 2011 at 7:08 AM, Trevor Freeman wrote: >> For usage type =3D0, I am concerned about the fragility of matching a=20 >> CA certificate is only by full certificate or SKI. Certificates and=20 >> keys have an inherently limited lifetime. >=20 > You are correct that matching by a certificate is a mistake because CAs o= ften reissue their CA certificates and clients build chains from the bottom= up. >=20 > However, matching a SubjectPublicKeyInfo is rather robust. Certainly the = leaf certificate cannot change without a site reconfiguring their servers. = That implies that the next certificate's (call it I1) SPKI is fixed by the = leaf (because it has to match the signature on the leaf). >=20 > Above that, one could imagine the combination of: > * The site fails to include any intermediate certificates > * The leaf doesn't include an Authority Key Identifier, but incudes an=20 > AIA URL for I1 > * I1 is replaced with a certificate with the same SPKI, but a different i= ssuer. >=20 > That way the CA could redirect the chain without the site knowing. > However, it requires a misconfiguration of the site (that will cause inte= rmittent issues and some clients to fail completely) and a grossly stupid C= A. >=20 > On the other hand, specifying via CA Subject name is very weak: any CA ca= n issue certificates with any Subject name. >=20 >=20 > Cheers >=20 > AGL >=20 > -- > Adam Langley agl@imperialviolet.org http://www.imperialviolet.org=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From Antoin.Verschuren@sidn.nl Wed Nov 16 22:08: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 422B811E80FD for ; Wed, 16 Nov 2011 22:08:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.131 X-Spam-Level: X-Spam-Status: No, score=-4.131 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zj9LAPc+8aKP for ; Wed, 16 Nov 2011 22:08:09 -0800 (PST) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [94.198.152.69]) by ietfa.amsl.com (Postfix) with ESMTP id 62A5C11E8083 for ; Wed, 16 Nov 2011 22:08:08 -0800 (PST) Received: from kahubcas1.SIDN.local ([192.168.2.41]) by ede1-kamx.sidn.nl with ESMTP id pAH687WW031414 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Thu, 17 Nov 2011 07:08:07 +0100 Received: from KAMBX2.SIDN.local ([fe80::b1fd:88d9:e136:9655]) by kahubcas1.SIDN.local ([fe80::dff:8232:1563:3a16%14]) with mapi id 14.01.0323.003; Thu, 17 Nov 2011 07:08:07 +0100 From: Antoin Verschuren To: IETF DANE WG list Thread-Topic: [dane] Scope of the protocol document or plea for progress Thread-Index: AQHMpHsQQSsLA3GytkSyYPzvhcfVEpWwDbWAgAAiWYCAAFTAgA== Date: Thu, 17 Nov 2011 06:08:06 +0000 Message-ID: References: <4EC2E8CA.1060009@ogud.com> <944D9413-A209-438F-9B6D-17C82A205C75@kirei.se> <162A261A-0872-4ADE-BE87-9F906E93CBED@vpnc.org> <4EC45DAB.9050607@ogud.com> In-Reply-To: <4EC45DAB.9050607@ogud.com> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.4.137] Content-Type: multipart/alternative; boundary="_000_BC941EB7C47B44D48B355052A12E2B4Esidnnl_" MIME-Version: 1.0 Subject: Re: [dane] Scope of the protocol document or plea for progress X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 17 Nov 2011 06:08:10 -0000 --_000_BC941EB7C47B44D48B355052A12E2B4Esidnnl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Op 17 nov. 2011, om 02:04 heeft Olafur Gudmundsson het volgende geschreven: Yesterday Paul and I talked about this at length, the DNSSEC-only document might/should give guidance on use policy in the cases DNSSEC validation can not succeed. There are two possible actions: Discard TLSA This is the only sane thing for the DANE protocol to define. If you do DANE, the TLSA record needs to be validated. If it cannot be vali= dated, do NOT use the record. Specify use policy by TLSA sub-type This is not for DANE to decide. Do it in another working group. If the record is not validated, you're not doing DANE. If you want to use the cert or any other content of the rrdata for any othe= r process to try to get a secure connection, fine, but you're not doing DAN= E. I would suggest to put the content of the cert in a CERT RR and try to d= o your verification trick over there depending on sub-type. How to do that = might be in a different document, possibly owned by the PKIX WG, or as an = individual submission, but it certainly is NOT DANE. I don't think DANE needs to inherit all flaws in other protocols, not the f= laws in DNSSEC nor the flaws in PKIX, they are up to a different WG definin= g that protocol. DANE is not here to fix the whole world, or we will never = finnish DANE. Antoin. --_000_BC941EB7C47B44D48B355052A12E2B4Esidnnl_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Op 17 nov. 2011, om 02:04 heeft Olafur Gudmundsson het volgende geschr= even:

Yesterday Paul and I talked about this at length,
the DNSSEC-only document might/should give guidance on use policy in
the cases DNSSEC validation can not succeed.

There are two possible actions:
Discard TLS= A

This is the only sane thing for the DANE protocol to define.
If you do DANE, the TLSA record needs to be validated. If it cannot be= validated, do NOT use the record.

Specif= y use policy by TLSA sub-type

This is not for DANE to decide. Do it in another working group.
If the record is not validated, you're not doing DANE.

If you want to use the cert or any other content of the rrdata for any= other process to try to get a secure connection, fine, but you're not doin= g DANE. I would suggest to put the content of the cert in a CERT RR and try= to do your verification trick over there depending on sub-type. How to do that might be in a different docume= nt, possibly owned  by the PKIX WG, or as an individual submission, bu= t it certainly is NOT DANE.

I don't think DANE needs to inherit all flaws in other protocols, not = the flaws in DNSSEC nor the flaws in PKIX, they are up to a different WG de= fining that protocol. DANE is not here to fix the whole world, or we will n= ever finnish DANE.

Antoin.

--_000_BC941EB7C47B44D48B355052A12E2B4Esidnnl_-- From peter@denic.de Wed Nov 16 22:17: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 6316A11E810C for ; Wed, 16 Nov 2011 22:17:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTsy3et1PvXF for ; Wed, 16 Nov 2011 22:17:30 -0800 (PST) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::4]) by ietfa.amsl.com (Postfix) with ESMTP id C3B1711E810A for ; Wed, 16 Nov 2011 22:17:30 -0800 (PST) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1RQvHt-0003ca-DY; Thu, 17 Nov 2011 07:17:29 +0100 Received: from localhost by x27.adm.denic.de with local id 1RQvHt-0004uP-7t; Thu, 17 Nov 2011 07:17:29 +0100 Date: Thu, 17 Nov 2011 07:17:29 +0100 From: Peter Koch To: Olafur Gudmundsson Message-ID: <20111117061729.GD13798@x27.adm.denic.de> Mail-Followup-To: Olafur Gudmundsson , IETF DANE WG list References: <4EC2E8CA.1060009@ogud.com> <944D9413-A209-438F-9B6D-17C82A205C75@kirei.se> <162A261A-0872-4ADE-BE87-9F906E93CBED@vpnc.org> <4EC45DAB.9050607@ogud.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EC45DAB.9050607@ogud.com> User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Cc: IETF DANE WG list Subject: [dane] Subtyping/Certificate Usage Registry [Re: Scope of the protocol document or plea for progress] X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 17 Nov 2011 06:17:31 -0000 On Thu, Nov 17, 2011 at 09:04:43AM +0800, Olafur Gudmundsson wrote: > Having said this I realize TLSA is potentially headed for the sub-typing > hell that TXT and NAPTR records suffer from. > The WG should have a short discussion about the design choice of > "if single RR type or multiple RR types" > is a better way forward and the document should have the > justification for the choice made. this concern can and probably should be addressed by a stricter policy for the "Certificate Usages for TLSA Resource Records" registry. However, in contrast to NAPTR, the use cases are not predetermined by the client (as in DDDS/NAPTR), but definitely part of the response. -Peter From trevorf@exchange.microsoft.com Wed Nov 16 22:26: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 358B011E813E for ; Wed, 16 Nov 2011 22:26:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.649 X-Spam-Level: X-Spam-Status: No, score=-110.649 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 CdpCCJ1wcSag for ; Wed, 16 Nov 2011 22:26:54 -0800 (PST) Received: from mail.exchange.microsoft.com (mail1.exchange.microsoft.com [131.107.1.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE9311E8131 for ; Wed, 16 Nov 2011 22:26:53 -0800 (PST) Received: from df-h14-01.exchange.corp.microsoft.com (157.54.78.139) by DF-G14-01.exchange.corp.microsoft.com (157.54.87.87) with Microsoft SMTP Server (TLS) id 14.2.247.2; Wed, 16 Nov 2011 22:26:53 -0800 Received: from PIO-MLT-05.exchange.corp.microsoft.com (157.54.94.22) by DF-H14-01.exchange.corp.microsoft.com (157.54.78.139) with Microsoft SMTP Server (TLS) id 14.2.247.5; Wed, 16 Nov 2011 22:26:53 -0800 Received: from DF-M14-12.exchange.corp.microsoft.com ([fe80::7c94:4036:120:c95f]) by PIO-MLT-05.exchange.corp.microsoft.com ([fe80::d940:e316:1daa:5e6a%10]) with mapi id 14.02.0247.002; Wed, 16 Nov 2011 22:26:53 -0800 From: Trevor Freeman To: "mrex@sap.com" Thread-Topic: [dane] Fragility of binding to a CA certificate by certificate Thread-Index: AQHMpN2/phad0pojIkKe+MJwZOCyaJWwkgcQ Date: Thu, 17 Nov 2011 06:26:52 +0000 Message-ID: References: from "Trevor Freeman" at Nov 17, 11 01:48:45 am <201111170402.pAH42WY8002548@fs4113.wdf.sap.corp> In-Reply-To: <201111170402.pAH42WY8002548@fs4113.wdf.sap.corp> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dane@ietf.org" Subject: Re: [dane] Fragility of binding to a CA certificate by 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, 17 Nov 2011 06:26:55 -0000 See inline below -----Original Message----- From: Martin Rex [mailto:mrex@sap.com]=20 Sent: Thursday, November 17, 2011 12:03 PM To: Trevor Freeman Cc: mrex@sap.com; dane@ietf.org Subject: Re: [dane] Fragility of binding to a CA certificate by certificate (Your MUA's quoting style/settings seems completely hosed.) Trevor Freeman wrote: >=20 > Martin Rex wrote: > >=20 > > The CA certificate necessary to verify the server certificate is=20 > > locked down with the signature on the server certificate and MUST be=20 > > (per TLS protocol spec) sent by the TLS server in the servers=20 > > certificate handshake message. > > [TF] Not true, any CA certificate with the same subject name and key=20 > can be used. There are a number of broken TLS peers out there that perform discovery ins= tead of straight path validation, but that doesn't meant that it is a good = idea. [TF] Broken implementation are just that. DANE is mandating here pkix valid= ation so anybody not doing pkix validation is non-compliant.=20 > > The server sends a set of certificates but the client is not obligated=20 > to use them. But should unconditionally abort when the path conveyed by the server(!) do= es not validate, i.e. when the server included an expired cert.=20 [TF] The relying part MUST find a valid pkix path. The server may include e= xpired certs but as long as the RP builds a valid path somehow, that is all= that matters.=20 Btw. no sane CA should issue a cert with a validity beyond the CAs own cert= ificate. That would be stupid and calling for trouble. [TF] SHOULD not MUST. As long as the CA operator fixed the problem in time = by creating a new CA certificate, life is good. The main case where this ki= nd of behavior is useful is decommissioning a CA so you are sure all issued= certificates are expired when you turn off the CA. But I see that a common, and obviously very error prone custom, such as con= veying a server credential as a pitiful single certificate instead of a sen= sibly bagged complete certification path, could lead to the situation where= a newly received server certificate might outlive and old (intermediate) C= A cert that is locally available and get used erroneouly when the local PKI= software does not perform a certificate path validation against both, curr= ent time and a second before the end-entities validto date and report the e= rror upfront, but blindly believes that inspite of arbitrarily mixing and m= atching certificates into a certification path and hoping for the best is "= good enough". That happens more likely for developers who either do not pr= ovide support for what they ship or are walled off from the support load th= eir solutions create. [TF] In scenarios like organization using bridge CA, the bag of certificate= s offered by the server is never complete - by design. The client still has= to find a valid path by finding the missing certificates for itself. Expir= ed or revoked CA certificates are the same problem.=20 I do remember that when I was first exposed to SSL & X.509 in 2001 as a dev= eloper, I experimented with the test area of "Thawte", and in their test ar= ea you could select whether to receive the CA response as pitiful singular = cert of PKCS#7 bag of a cert chain. They had a notice on their page indicating that they expected PKCS#7 respon= ses to become the standard and pitiful singular cert response to become dep= recated soon. Unfortunately that migration never happened, and there is a significant amo= unt of PKI software with only brittle and vague idea of "PKI credential man= agement" providing plenty of administrative pitfalls that would be triviall= y and completely avoidable. [TF] TLS and DANE use types one and two are both fully dependent on pki so = we have to accept the dependency on those aspects.=20 As it turns out, the extreme laissez-faire approach of OpenSSL & Apache to = credential management is a major cause of misconfigured TLS servers (by hav= ing the certification path spread out over entirely independent files and = complete absence of a "credential management" concept that will ensure the= server's forward certification path is validated at least once during ins= tallation of a new server certificate.) [TF] DANE has a dependency on TLS which in turn has a dependency on credent= ial management.=20 An implementors approach to make a random pick about the value for a protoc= ol option, in combination with that pick not blowing up on a very limited (= read statistically insignificant) black-box test with all default settings,= is what caused Win7 to get shipped with invalid RSA pre-master secret chec= k on renegotiaton handshakes and causes interop-problems when activating TL= Sv1.2 because of the unconditional use of { 0x03,0x03 } for the record laye= r protocol_version instead of only for the ClientHello.client_version on th= e initial ClientHello. > > After that, the choice of possible paths is constrained only by what=20 > is valid under the relying parties trust policy. DANE does not mandate=20 > that the publish CA certificate be the leaf issuing CA, merely a CA=20 > that the pkix path must intersect. It OUGHT to be a certificate from the forward path that the server sends wi= thin the server certificate handshake message. If we do not have that in t= he DANE protocol I-D, then we ought to put it in. [TF] You need something in the security considerations about the selection.= =20 And clients ought to ensure that they *ALL* use the CA cert from the server= 's Certificate handshake message when they perform the DANE validation, bec= ause only for that cert an synchronous update of the cert itself and the DN= S DANE record can be ensured by the server admin. Distribution of renewed = intermediate CA certs to clients will be completely random and diverse -- i= f at all. [TF] No - the current wording is correct - build a valid pkix path. The sen= t set of certificates are useful but as a RP it's down to me to build the p= ath.=20 >=20 > > (about unique CA subject names) > > > > This idea would only work in a strictly hierarchical PKI with a=20 > > singular root authority (which does not need to have a root cert,=20 > > but must have the authority to define and enforce the policy by=20 > > which all CAs in the PKI must be operated). > > [TF] I don't understand the comment. Every pki path is hierarchical=20 > and this has no dependency on the number of root authorities. PKI=20 > merely defines how to validate a path. Unique CA subject names and Name constraints extension can only work in a s= trictly hierarchical PKI with ONE SINGLE root authority. [TF] There are shipping pkix clients today that don't have that restriction= and work just fine with pkix. The TLS X.509 PKI has plenty of completely independent, omnipotent root aut= horities. The windows trust anchor store maintained by Microsoft for Windo= ws XP contains about 300 individual rootCA certificates today. And with bi= g companies, such as Microsoft and Google, and government agencies such as = DHS operating their own, fully trusted, omnipotent CA, you really ought to = link your trust to specific keys rather than to names that can be spoofed b= y probably several hundred independent organizations around the globe (or a= nyone that manages to create a valid CA cert und any one of those, either b= y break-in or by collision precomputation or an MD2 or MD5 preimage attack = on one of the tainted old rootCA certs. [TF] This reiterates the need for a concise list of threats DANE want to mi= tigate. Many of the threats you mentioned are already mitigated. I am all i= n favor blocking unmitigated threat but let's not reinvent wheels. Use type= s 0 and 1 both are dependent real CAs and pkix validation; use type 3 is wh= ere the server domain is rolling its own.=20 -Martin From rbarnes@bbn.com Wed Nov 16 22:27: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 CB30011E814D for ; Wed, 16 Nov 2011 22:27:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.283 X-Spam-Level: X-Spam-Status: No, score=-106.283 tagged_above=-999 required=5 tests=[AWL=-0.284, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JQU8bEeTsbD5 for ; Wed, 16 Nov 2011 22:27:22 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 7ABD211E8142 for ; Wed, 16 Nov 2011 22:27:22 -0800 (PST) Received: from [128.89.255.47] (port=59290) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RQvRM-000OyK-SO; Thu, 17 Nov 2011 01:27:17 -0500 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Richard Barnes In-Reply-To: Date: Thu, 17 Nov 2011 14:27:11 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <431D9158-63A6-4546-8E74-BFE0DF2FBA72@bbn.com> References: To: Trevor Freeman X-Mailer: Apple Mail (2.1251.1) Cc: Adam Langley , "dane@ietf.org" Subject: Re: [dane] Fragility of binding to a CA certificate by certificate or ski X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 17 Nov 2011 06:27:23 -0000 > You description does not match what use type =3D0 Sure it does. Let me clarify: 1. example.com provisions a DANE record saying that any cert must chain = through "CN=3Dsuper-trusted-ca.com" 2. Nefarious attacker generates a CA cert under a well-known TA with his = own key pair and "CN=3Dsuper-trusted-ca.com", and an EE cert under this = CA. In that case, the cert matches the type=3D0 constraint, but it's clearly = still bogus. And the client still gets MitM'ed. > It would have been helpful if document somewhere the threats you want = to mitigate, vs. the threats you are not mitigating as it helps such = discussions.=20 >=20 > We need clarity around what threats DNSSEC addresses and what value = DANE adds over just DNSSEC. The threats highlighted in 6394 is a DNS = name resolver attack which is intrinsically blocked by DNSSEC. Today, = DNS based attacks are fairly cheap and easy to use.=20 >=20 > Getting a bogus EE certificate is a district threat from a CA = certificate. I can stop trust in a CA certificate issued from an = instance of a CA by constraining the path length of the CA certificate = which is what is happening today. This mitigates the threat of an = attacker getting a CA certificate from that CA. >=20 > Equally since the relying party is using full pkix validation they can = impose restrictions on the set of certificate policies - which again = make it impossible for any CA to issue a certificate with the right name = and the right policy since the policy is constrained from the root CA = down.=20 >=20 > There are these many reasons why when the client tries to validate the = certificate issued by the bogus CA with the same name as published by = DANE, why pkix will reject the certificate path based on the relying = party trust policy.=20 So the above attack is not viable if the RP/client imposes path length = constraints on the TAs in its trust store. Are you aware of clients = that actually do this in practice? How do they decide what constraints = to apply, given that they don't know how the CAs they're trusting are = structuring their operations? > You may want to clarity what threats you are anticipating for how the = attacker mounts the mitm attack with DNSSEC since you now have the right = ip addresses. =20 For example:=20 --Richard >=20 > Trevor >=20 >=20 > -----Original Message----- > From: Richard Barnes [mailto:rbarnes@bbn.com]=20 > Sent: Thursday, November 17, 2011 9:54 AM > To: Trevor Freeman > Cc: Adam Langley; dane@ietf.org > Subject: Re: [dane] Fragility of binding to a CA certificate by = certificate or ski >=20 > So are you not concerned about the following attack? >=20 > 1. example.com provisions a DANE record saying that any cert that = comes under the CA "CN=3Dsuper-trusted-ca.com" is OK for that domain >=20 > 2. Nefarious attacker generates a cert with his own key pair and = "CN=3Dsuper-trusted-ca.com" >=20 > 3. Nefarious attacker MitMs a TLS session to example.com and presents = his cert >=20 > 4. Client looks at the cert, sees the right name, and blissfully = proceeds with the hijacked session >=20 > In light of this, any discussion of binding only to names is = ridiculous. I think this is what Adam was trying to say, a bit more = politely. >=20 > --RIchard >=20 >=20 >=20 >=20 > On Nov 17, 2011, at 9:31 AM, Trevor Freeman wrote: >=20 >> Hi And, >>=20 >> Pkix has many controls to control trust in CAs. There are more = controls for trust in CAs certificates than those over end entities. We = are talking about usage type =3D0 so the relying party has full control = over their own pkix policy. >>=20 >> I agree that matching SKI is a stronger binding but it is not = necessary more robust if it results in loss of service. It's a much a = business rick determination if the site want to trade higher = availability for a stronger binding. They are best placed to determine = scale of impact from loss of service vs. an active attack. >>=20 >> Given we are anticipating a work with DNSSEC, the attacker now has to = obtain a site certificate and compromise some part of the routing = infrastructure for the mark so they can perform address mapping to = redirect the ip traffic to the bogus site. That is not an attack that = scales well but if the CA changes its key and the site did not update = its DNS record, the site is down. >>=20 >> Adam, you need to check 5280 section 6. Pkix chaining is name based = not key based. Yes it checks the signatures but SKI\AKI matching is not = used in any way. >>=20 >> Matching by subject name presents a strong CA binding mechanism which = is more robust against configuration mismatch - hence delver's higher = availability.=20 >>=20 >> Trevor >>=20 >> -----Original Message----- >> From: alangley@gmail.com [mailto:alangley@gmail.com] On Behalf Of = Adam=20 >> Langley >> Sent: Wednesday, November 16, 2011 11:38 AM >> To: Trevor Freeman >> Cc: dane@ietf.org >> Subject: Re: [dane] Fragility of binding to a CA certificate by=20 >> certificate or ski >>=20 >> On Tue, Nov 15, 2011 at 7:08 AM, Trevor Freeman = wrote: >>> For usage type =3D0, I am concerned about the fragility of matching = a=20 >>> CA certificate is only by full certificate or SKI. Certificates and=20= >>> keys have an inherently limited lifetime. >>=20 >> You are correct that matching by a certificate is a mistake because = CAs often reissue their CA certificates and clients build chains from = the bottom up. >>=20 >> However, matching a SubjectPublicKeyInfo is rather robust. Certainly = the leaf certificate cannot change without a site reconfiguring their = servers. That implies that the next certificate's (call it I1) SPKI is = fixed by the leaf (because it has to match the signature on the leaf). >>=20 >> Above that, one could imagine the combination of: >> * The site fails to include any intermediate certificates >> * The leaf doesn't include an Authority Key Identifier, but incudes = an=20 >> AIA URL for I1 >> * I1 is replaced with a certificate with the same SPKI, but a = different issuer. >>=20 >> That way the CA could redirect the chain without the site knowing. >> However, it requires a misconfiguration of the site (that will cause = intermittent issues and some clients to fail completely) and a grossly = stupid CA. >>=20 >> On the other hand, specifying via CA Subject name is very weak: any = CA can issue certificates with any Subject name. >>=20 >>=20 >> Cheers >>=20 >> AGL >>=20 >> -- >> Adam Langley agl@imperialviolet.org http://www.imperialviolet.org=20 >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >=20 From rbarnes@bbn.com Wed Nov 16 22:28: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 57F3311E80C7 for ; Wed, 16 Nov 2011 22:28:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.574 X-Spam-Level: X-Spam-Status: No, score=-106.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 uDakpdZd9Wl9 for ; Wed, 16 Nov 2011 22:28:08 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id CE02011E80A4 for ; Wed, 16 Nov 2011 22:28:08 -0800 (PST) Received: from [128.89.255.47] (port=59290) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RQvSA-000OyK-JK; Thu, 17 Nov 2011 01:28:08 -0500 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Richard Barnes In-Reply-To: Date: Thu, 17 Nov 2011 14:28:04 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Trevor Freeman X-Mailer: Apple Mail (2.1251.1) Cc: "dane@ietf.org" Subject: Re: [dane] Fragility of binding to a CA certificate by certificate or ski X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 17 Nov 2011 06:28:09 -0000 Just to clarify: Are you asking for some change to the spec, or just = noting an operational risk? Thanks, --Richard On Nov 15, 2011, at 8:08 PM, Trevor Freeman wrote: > For usage type =3D0, I am concerned about the fragility of matching a = CA certificate is only by full certificate or SKI. Certificates and keys = have an inherently limited lifetime. CAs need to renew both as a matter = of routine maintenance, which is an operation outside of the visibility = of the domain and updating the domain DNS record is outside the control = of the CA. This is a recipe for things to go wrong. All a CA can do is = notify the domain of the update and hope they make the change to the DNS = record. > =20 > A more stable CA identifier would be a CA=92s subject name. This will = remain constant as certificates and keys are renewed. You can easily put = a hexadecimal encoded subject names in the DNS record and define a new = match type. It would also be simple for the CA to publish instructions = for creating the DNS record and include the binary encoded subject name = on the web page so the domain administrator can simple cut and paste the = value when creating the DNS record for their domain and the instructions = will not need updating every time they renew their CA certificate. > =20 > Dr Trevor Freeman Senior Security Strategist > End to End Trust Team > Microsoft Trustworthy Computing =20 > =20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From peter@denic.de Wed Nov 16 22:35: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 79F5A21F9716 for ; Wed, 16 Nov 2011 22:35:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XGfLeivkW4IO for ; Wed, 16 Nov 2011 22:35:38 -0800 (PST) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::4]) by ietfa.amsl.com (Postfix) with ESMTP id E7FD421F96FC for ; Wed, 16 Nov 2011 22:35:37 -0800 (PST) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1RQvZQ-0003hV-Kc; Thu, 17 Nov 2011 07:35:36 +0100 Received: from localhost by x27.adm.denic.de with local id 1RQvZQ-0005Bg-Gu; Thu, 17 Nov 2011 07:35:36 +0100 Date: Thu, 17 Nov 2011 07:35:36 +0100 From: Peter Koch To: IETF DANE WG Message-ID: <20111117063536.GE13798@x27.adm.denic.de> Mail-Followup-To: IETF DANE WG References: <4EC2E8CA.1060009@ogud.com> <55221C61-0F07-41F7-9FEE-B98C790E7F3B@nic.cz> <9B4BDD4C-7CF4-4A32-A5CE-95CDB75E0ED9@bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9B4BDD4C-7CF4-4A32-A5CE-95CDB75E0ED9@bbn.com> User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: Re: [dane] Scope of the protocol document or plea for progress X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 17 Nov 2011 06:35:38 -0000 On Thu, Nov 17, 2011 at 09:47:43AM +0800, Richard Barnes wrote: > -----BEGIN STATE TABLE----- > DNSSEC Exists Matches Outcome > ======================================= > bogus * * BAD > secure yes no BAD > secure yes yes GOOD > secure no * NO-INFO > other * * NO-INFO > -----END STATE TABLE----- under the assumption that 'Exists' is to distinguish between positive and negative (NXDOMAIN, NOERROR/NODATA {even though unlikely}) DNS responses, the table mixes DNSSEC status and content to make a decision which i'd consider a bit premature. To stress a famous quote: DNSSEC is expensive error detection. What to do in the absence of the AD bit is basically a local decision. In the case of DANE this decision probably has different risks depending on the use case. -Peter From ondrej.sury@nic.cz Thu Nov 17 00:00: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 1425F1F0C82 for ; Thu, 17 Nov 2011 00:00:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W92ciAJILGm0 for ; Thu, 17 Nov 2011 00:00:32 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 54D171F0C47 for ; Thu, 17 Nov 2011 00:00:32 -0800 (PST) Received: from dhcp-63b8.meeting.ietf.org (dhcp-63b8.meeting.ietf.org [130.129.99.184]) by mail.nic.cz (Postfix) with ESMTPSA id 5150A2A2D67; Thu, 17 Nov 2011 09:00:30 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1321516831; bh=qwsifMhwfW66Z0rFBY8i8gVfmEfnf34ZFLWfrKf5zLM=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=wD6vM5XeEVi7+mvTkmoGTxL1a7XzAAVYoUfgPRZVTZUyMFSwh5taWcyYHUXbX97fv AscDjLb6CVlJ8w1xfyGCgDCzOV11/InI5jrmB0btB01uj4VF24ZcGaUF4VGWNpqY2N fSlyWF9mTPPkH1g7L98kKMALw2nf2RVi1quar59w= Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <20111117063536.GE13798@x27.adm.denic.de> Date: Thu, 17 Nov 2011 16:00:25 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2D7F4BE3-5B9D-462A-B150-F1FB64E6D7B6@nic.cz> References: <4EC2E8CA.1060009@ogud.com> <55221C61-0F07-41F7-9FEE-B98C790E7F3B@nic.cz> <9B4BDD4C-7CF4-4A32-A5CE-95CDB75E0ED9@bbn.com> <20111117063536.GE13798@x27.adm.denic.de> To: Peter Koch X-Mailer: Apple Mail (2.1251.1) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: IETF DANE WG Subject: Re: [dane] Scope of the protocol document or plea for progress X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 17 Nov 2011 08:00:33 -0000 On 17. 11. 2011, at 14:35, Peter Koch wrote: > On Thu, Nov 17, 2011 at 09:47:43AM +0800, Richard Barnes wrote: >=20 >> -----BEGIN STATE TABLE----- >> DNSSEC Exists Matches Outcome >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> bogus * * BAD >> secure yes no BAD >> secure yes yes GOOD >> secure no * NO-INFO >> other * * NO-INFO >> -----END STATE TABLE----- >=20 > under the assumption that 'Exists' is to distinguish between > positive and negative (NXDOMAIN, NOERROR/NODATA {even though > unlikely}) DNS responses, the table mixes DNSSEC status > and content to make a decision which i'd consider a bit premature. I don't see this mix as something bad - you have DNSSEC statuses in rows and DNS response + DANE match in columns. > To stress a famous quote: DNSSEC is expensive error detection. > What to do in the absence of the AD bit is basically a local > decision. In the case of DANE this decision probably has > different risks depending on the use case. And I think we are trying to avoid the "depending on the use case" part for DANE protocol document, because: a) it's getting complicated and we seem to be going in the circles b) we can address that in separate document updating DANE protocol 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 Nov 17 00:31: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 AA1C221F989E for ; Thu, 17 Nov 2011 00:31:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6mIIFUE0kDj for ; Thu, 17 Nov 2011 00:31:22 -0800 (PST) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id 27FB921F9936 for ; Thu, 17 Nov 2011 00:31:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=/tjLlpFKFOKhFJItrYC37CyRoLJldRqBNhfdw1u9GwU=; b=UBsAv6lKhMK+AkmGX+tSvF/ekDK+lBDzqn3JR/qSwLbScGAmXaftN+v+1wS+O79k0dhR7E9BxFS6c fnZZNpir9woriPAhRT/vxLanndxFuNbuKQeTFFHkVhEGFVOvKLwAVeAx6XkHLFq2XtFaEknkvk+gxj w+/8Xo/oP/nXzjfw= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Thu, 17 Nov 2011 09:31:14 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: <201111170123.pAH1Nu8P023794@fs4113.wdf.sap.corp> Date: Thu, 17 Nov 2011 09:31:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2D558EC4-C315-4994-AE60-B86EBD6F4DFF@kirei.se> References: <201111170123.pAH1Nu8P023794@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1251.1) Cc: paul.hoffman@vpnc.org, dane@ietf.org Subject: Re: [dane] Scope of the protocol document or plea for progress X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 17 Nov 2011 08:31:23 -0000 On 17 nov 2011, at 02:23, Martin Rex wrote: > By inserting fake DNS TLSA records, you can make the TLS client > that believe in TLSA absent of DNSSEC protection, reliably fail > connection to the real server that the attacker fails to MITM, > and showing only the connections that the attacker succeeds > to MITM as "trustworthy". This is the "firesheep" scenario. A client received an insecure non-matching TLSA record knows for sure = that something is fishy - either someone is doing bad things with their = DNS, or someone is doing an MITM attack on TLS. I fail to see any = disadvantage aborting such a TLS connection (or alert the user), as it = may protect you from a subset of attacks (e.g., fraudulently issues = certificates from a CA that the TLS server do not want to be associated = with). N.B.: this is the insecure non-matching case ONLY in combination with = certificate usage type 0 and 1 ONLY. jakob From paul@xelerance.com Thu Nov 17 08:20: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 E9C5711E8181; Thu, 17 Nov 2011 08:20:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.96 X-Spam-Level: X-Spam-Status: No, score=-5.96 tagged_above=-999 required=5 tests=[AWL=-0.261, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, 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 RqxSayw1pRdw; Thu, 17 Nov 2011 08:20:26 -0800 (PST) Received: from mx.xelerance.com (mx.xelerance.com [193.110.157.188]) by ietfa.amsl.com (Postfix) with ESMTP id A660211E817B; Thu, 17 Nov 2011 08:20:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx.xelerance.com (Postfix) with ESMTP id 0C61251F; Thu, 17 Nov 2011 11:20:22 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xelerance.com; h= content-transfer-encoding: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=1321546818; x=1322151618; bh=7wL9Ksf/8laorqFNRY4ETOtW62Q J7DxgYv3Fwk2/Xbg=; b=L3sInfzTEns5emQLjk1A+3JXHW1iIOh6eFQnxSoexvN koqn2PIhYydfoY5tS6GUxbGb9B7YcXI7KgTeNdthjRJ7azVrRKsb/CubQ3h2kOq1 NllKa7UO9EzB27HfGuyKr0fCDOeiPgQE0d1T4pOYx6kU/WKTNgElYjGQ603Z7Y0E = 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 oUj++oJkTCbz; Thu, 17 Nov 2011 11:20:18 -0500 (EST) 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 A420D84; Thu, 17 Nov 2011 11:20:18 -0500 (EST) Received: by mail.xelerance.com (Postfix, from userid 1001) id 55A28445; Thu, 17 Nov 2011 11:20:18 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.xelerance.com (Postfix) with ESMTP id 4F2B01F2; Thu, 17 Nov 2011 11:20:18 -0500 (EST) Date: Thu, 17 Nov 2011 11:20:18 -0500 (EST) From: Paul Wouters To: =?ISO-8859-2?Q?Ond=F8ej_Sur=FD?= In-Reply-To: <8766068B-882E-41F9-B908-49088E451F03@nic.cz> Message-ID: References: <8766068B-882E-41F9-B908-49088E451F03@nic.cz> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Cc: tls@ietf.org, dane@ietf.org Subject: Re: [dane] [TLS] New Version Notification for draft-wouters-tls-oob-pubkey-01.txt (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 17 Nov 2011 16:20:27 -0000 On Thu, 17 Nov 2011, Ondřej Surý wrote: The -02 draft went out before I could respond to this.... > could you please drop this sentence from your draft? > > For example, if public keys were obtained using [DANE] it > is appropriate to use DNSSEC to authenticate the public keys. > > I know that it's just an example, but I can see that this could > lead to chaos and mayhem if the DANE protocol makes different > assertion in the future. So unless DANE protocol blooms into the > RFC before your draft, please don't make any assumptions, thanks. Though I see your point, I cannot really see any case where a TLS implementation would obtain a public key from DNS without any PKIX information and without any DNSSEC protection. In this case there is not even the PKIX fallback information to go on, so regardless of what DANE decides to do for "validatable PKIX", a TLS client MUST NOT use a TLSA record containing just a public key if it did not authenticate that data with DNSSEC. Perhaps it can be reworded? But I think it is a valid security concern to point out people should not just pluck spoofable TLSA records from DNS and build a TLS trust relationship based on that. Even if DANE decided to always mandata DNSSEC, I think it is a good reminder to make that explicit in the Security Considerations here? > And one minor nit, change > > Some small embedded devices use the UDP based [CoAP], a specialized > constrained networks and nodes for machine-to-machine applications. > > to > > Some small embedded devices use the UDP based Constrained Application > Protocol [CoAP], a specialized web transfer protocol for use with > constrained networks and nodes for machine-to-machine applications. > > or simpler > > Some small embedded devices use the UDP based Constrained Application > Protocol [CoAP] for use with constrained networks and nodes for > machine-to-machine applications. > > for better readability. Thanks. I've made the changes and the will be in the next draft. Paul > On 1. 11. 2011, at 7:21, Paul Wouters wrote: > >> >> This is the new version of the draft incorporating the feedback from Quebec City >> and the TLS list since then. It changes the draft from a new TLS extension to a >> new Certificate Type for raw keys. >> >> It also merges in the unpublished draft material from Hannes Tschofenig >> and Tero Kivinen whom had also been working on raw RSA >> TLS keys for use with CoAP (eg devices with no real time clock where >> PKIX validation cannot work) >> >> I did not yet change the draft ofrom individual submission to working group item, >> as I was waiting for confirmation on the TLW WG list of the last Quebec City >> meeting. >> >> http://tools.ietf.org/html/draft-wouters-tls-oob-pubkey-01 >> >> Paul >> >> ---------- Forwarded message ---------- >> Date: Mon, 31 Oct 2011 17:44:35 >> From: internet-drafts@ietf.org >> Cc: weiler@tislabs.com, hannes.tschofenig@gmx.net, gnu@toad.com, >> paul@xelerance.com, kivinen@iki.fi >> To: paul@xelerance.com >> Subject: New Version Notification for draft-wouters-tls-oob-pubkey-01.txt >> X-Spam-Flag: NO >> >> A new version of I-D, draft-wouters-tls-oob-pubkey-01.txt has been successfully submitted by Paul Wouters and posted to the IETF repository. >> >> Filename: draft-wouters-tls-oob-pubkey >> Revision: 01 >> Title: TLS out-of-band public key validation >> Creation date: 2011-10-31 >> WG ID: Individual Submission >> Number of pages: 11 >> >> Abstract: >> This document specifies a new TLS certificate type for exchanging raw >> public keys or their fingerprints in Transport Layer Security (TLS) >> and Datagram Transport Layer Security (DTLS) for use with out-of-band >> authentication. Currently, TLS authentication can only occur via >> PKIX or OpenPGP certificates. By specifying a minimum resource for >> raw public key exchange, implementations can use alternative >> authentication methods. >> >> One such method is using DANE Resource Records secured by DNSSEC, >> Another use case is to provide authentication functionality when used >> with devices in a constrained environment that use whitelists and >> blacklists, as is the case with sensors and other embedded devices >> that are constrained by memory, computational, and communication >> limitations where the usage of PKIX is not feasible. >> >> The new certificate type specified can also be used to reduce the >> latency of a TLS client that is already in possession of a validated >> public key of the TLS server before it starts a (non-resumed) TLS >> handshake. >> >> >> >> >> The IETF Secretariat >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > -- > Ondřej Surý > vedoucí výzkumu/Head of R&D department > ------------------------------------------- > CZ.NIC, z.s.p.o. -- Laboratoře 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 Nov 17 09:07: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 1F93B21F9A06; Thu, 17 Nov 2011 09:07:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RotQlMHMpD83; Thu, 17 Nov 2011 09:06:59 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id D540721F9A01; Thu, 17 Nov 2011 09:06:58 -0800 (PST) Received: from [192.168.100.100] (61-220-70-183.HINET-IP.hinet.net [61.220.70.183]) by mail.nic.cz (Postfix) with ESMTPSA id BF2442A2B86; Thu, 17 Nov 2011 18:06:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1321549617; bh=F9MqqeIRy7vogaW/a9XrXqD5vuigSSEAVvnJAYptl3o=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=pBYYJIlt4LGR7sE+HJjO8/hD96e+jaCh7MN4tBL1WLciIG4d3PWwUrIc4NO6RuU0I I7vxZZoi+gPaNi0I3GvOX6Luc9gODk9hk0rBwSX4NsmxTNy4d8oSK4CyFPRaG8eyLb Fuwkz70FOHg6zCYDo0Xlk+ofSv6dCzdqgo85GSCo= Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: Date: Fri, 18 Nov 2011 01:06:52 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8766068B-882E-41F9-B908-49088E451F03@nic.cz> To: Paul Wouters X-Mailer: Apple Mail (2.1251.1) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: tls@ietf.org, dane@ietf.org Subject: Re: [dane] [TLS] New Version Notification for draft-wouters-tls-oob-pubkey-01.txt (fwd) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 17 Nov 2011 17:07:11 -0000 On 18. 11. 2011, at 0:20, Paul Wouters wrote: > On Thu, 17 Nov 2011, Ond=C5=99ej Sur=C3=BD wrote: >=20 > The -02 draft went out before I could respond to this.... >=20 >> could you please drop this sentence from your draft? >>=20 >> For example, if public keys were obtained using [DANE] it >> is appropriate to use DNSSEC to authenticate the public keys. >>=20 >> I know that it's just an example, but I can see that this could >> lead to chaos and mayhem if the DANE protocol makes different >> assertion in the future. So unless DANE protocol blooms into the >> RFC before your draft, please don't make any assumptions, thanks. >=20 > Though I see your point, I cannot really see any case where a TLS > implementation would obtain a public key from DNS without any PKIX > information and without any DNSSEC protection. In this case there is > not even the PKIX fallback information to go on, so regardless of what > DANE decides to do for "validatable PKIX", a TLS client MUST NOT use > a TLSA record containing just a public key if it did not authenticate > that data with DNSSEC. I think it's perfectly fine to say, what you are saying in the first part of the paragraph: Depending on exactly how the public keys were obtained, it may be appropriate to use authentication mechanisms tied to the public key transport. but I object to saying what that means in the other (DANE) protocols. Or speak about the protocols which have the security properties already defined (LDAPS?). > Perhaps it can be reworded? But I think it is a valid security concern > to point out people should not just pluck spoofable TLSA records from > DNS and build a TLS trust relationship based on that. I agree with you, but this is not the place to say that. > Even if DANE > decided to always mandata DNSSEC, I think it is a good reminder to > make that explicit in the Security Considerations here? You can reword it to make it more general - less DANE-centric. >> And one minor nit, change >>=20 >> Some small embedded devices use the UDP based [CoAP], a specialized >> constrained networks and nodes for machine-to-machine applications. >>=20 >> to >>=20 >> Some small embedded devices use the UDP based Constrained = Application >> Protocol [CoAP], a specialized web transfer protocol for use with >> constrained networks and nodes for machine-to-machine applications. >>=20 >> or simpler >>=20 >> Some small embedded devices use the UDP based Constrained = Application >> Protocol [CoAP] for use with constrained networks and nodes for >> machine-to-machine applications. >>=20 >> for better readability. >=20 > Thanks. I've made the changes and the will be in the next draft. >=20 > Paul >=20 >> On 1. 11. 2011, at 7:21, Paul Wouters wrote: >>=20 >>>=20 >>> This is the new version of the draft incorporating the feedback from = Quebec City >>> and the TLS list since then. It changes the draft from a new TLS = extension to a >>> new Certificate Type for raw keys. >>>=20 >>> It also merges in the unpublished draft material from Hannes = Tschofenig >>> and Tero Kivinen whom had also been working on raw = RSA >>> TLS keys for use with CoAP (eg devices with no real time clock where >>> PKIX validation cannot work) >>>=20 >>> I did not yet change the draft ofrom individual submission to = working group item, >>> as I was waiting for confirmation on the TLW WG list of the last = Quebec City >>> meeting. >>>=20 >>> http://tools.ietf.org/html/draft-wouters-tls-oob-pubkey-01 >>>=20 >>> Paul >>>=20 >>> ---------- Forwarded message ---------- >>> Date: Mon, 31 Oct 2011 17:44:35 >>> From: internet-drafts@ietf.org >>> Cc: weiler@tislabs.com, hannes.tschofenig@gmx.net, gnu@toad.com, >>> paul@xelerance.com, kivinen@iki.fi >>> To: paul@xelerance.com >>> Subject: New Version Notification for = draft-wouters-tls-oob-pubkey-01.txt >>> X-Spam-Flag: NO >>>=20 >>> A new version of I-D, draft-wouters-tls-oob-pubkey-01.txt has been = successfully submitted by Paul Wouters and posted to the IETF = repository. >>>=20 >>> Filename: draft-wouters-tls-oob-pubkey >>> Revision: 01 >>> Title: TLS out-of-band public key validation >>> Creation date: 2011-10-31 >>> WG ID: Individual Submission >>> Number of pages: 11 >>>=20 >>> Abstract: >>> This document specifies a new TLS certificate type for exchanging = raw >>> public keys or their fingerprints in Transport Layer Security (TLS) >>> and Datagram Transport Layer Security (DTLS) for use with = out-of-band >>> authentication. Currently, TLS authentication can only occur via >>> PKIX or OpenPGP certificates. By specifying a minimum resource for >>> raw public key exchange, implementations can use alternative >>> authentication methods. >>>=20 >>> One such method is using DANE Resource Records secured by DNSSEC, >>> Another use case is to provide authentication functionality when = used >>> with devices in a constrained environment that use whitelists and >>> blacklists, as is the case with sensors and other embedded devices >>> that are constrained by memory, computational, and communication >>> limitations where the usage of PKIX is not feasible. >>>=20 >>> The new certificate type specified can also be used to reduce the >>> latency of a TLS client that is already in possession of a = validated >>> public key of the TLS server before it starts a (non-resumed) TLS >>> handshake. >>>=20 >>>=20 >>>=20 >>>=20 >>> The IETF Secretariat >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>=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 -- 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 mrex@sap.com Thu Nov 17 12:52: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 4CE071F0C5D for ; Thu, 17 Nov 2011 12:52:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.146 X-Spam-Level: X-Spam-Status: No, score=-10.146 tagged_above=-999 required=5 tests=[AWL=0.103, 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 2vG2-gVD4y9Z for ; Thu, 17 Nov 2011 12:52:32 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 819CE1F0C54 for ; Thu, 17 Nov 2011 12:52:32 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id pAHKqUav001922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 17 Nov 2011 21:52:30 +0100 (MET) From: Martin Rex Message-Id: <201111172052.pAHKqTJ1000780@fs4113.wdf.sap.corp> To: jakob@kirei.se (Jakob Schlyter) Date: Thu, 17 Nov 2011 21:52:29 +0100 (MET) In-Reply-To: <2D558EC4-C315-4994-AE60-B86EBD6F4DFF@kirei.se> from "Jakob Schlyter" at Nov 17, 11 09:31:07 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] Scope of the protocol document or plea for progress 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, 17 Nov 2011 20:52:33 -0000 Jakob Schlyter wrote: > > Martin Rex wrote: > > > > By inserting fake DNS TLSA records, you can make the TLS client > > that believe in TLSA absent of DNSSEC protection, reliably fail > > connection to the real server that the attacker fails to MITM, > > and showing only the connections that the attacker succeeds > > to MITM as "trustworthy". This is the "firesheep" scenario. > > N.B.: this is the insecure non-matching case ONLY in combination > with certificate usage type 0 and 1 ONLY. Yes, of course. AFAIK, noone suggested to believe in usage type 2 TLSA records where DNSSEC validation fails. But think about what cert usage type 0 and 1 really means: It means that someone managed to obtain a cert for which the PKIX validation performed by the client will pass! There is no point in DANE trying to protect from attacker who can not do this, because the PKIX validation would reliably fail. The purpose of using DANE with usage types 0 and 1 at all is giving the Domain Owner(!!) the ability to repudiate a certificate that will pass the client's PKIX validation and server endpoint identification. Believing in non-DNSSEC TLSA records of types 0 and 1 will result in exactly the opposite to be achievable for an attacker: a) make a correct PKIX-validating and Domain-Owner approved TLS server cert look fishy by a simple DNS spoof and have clients abort. and simultaneously b) make a fraudulent but PKIX-validating and *NOT* Domain-Owner approved TLS server cert look acceptable by a simple DNS spoof and give clients a false sense of security. -Martin From fanf2@hermes.cam.ac.uk Thu Nov 17 13:07: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 A47E421F9518 for ; Thu, 17 Nov 2011 13:07:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOsvXDLBheVS for ; Thu, 17 Nov 2011 13:07:50 -0800 (PST) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by ietfa.amsl.com (Postfix) with ESMTP id 7403C21F8481 for ; Thu, 17 Nov 2011 13:07:50 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:48881) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1RR9BT-00029o-Qh (Exim 4.72) (return-path ); Thu, 17 Nov 2011 21:07:47 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1RR9BT-00033k-78 (Exim 4.67) (return-path ); Thu, 17 Nov 2011 21:07:47 +0000 Date: Thu, 17 Nov 2011 21:07:47 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Zack Weinberg In-Reply-To: Message-ID: References: <4EC2E8CA.1060009@ogud.com> <55221C61-0F07-41F7-9FEE-B98C790E7F3B@nic.cz> <9B4BDD4C-7CF4-4A32-A5CE-95CDB75E0ED9@bbn.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: IETF DANE WG list Subject: Re: [dane] Scope of the protocol document or plea for progress X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 17 Nov 2011 21:07:52 -0000 Zack Weinberg wrote: > > I would add one additional thing: go to state BAD if the *address > record* lookup comes back "bogus", and to NO-INFO if that came back > non-"secure". I don't think there is any harm in having a secure TLSA record but insecure address records, since TLS certificate validation will check that you ended up connecting to the right place. Tony. -- f.anthony.n.finch http://dotat.at/ Rockall: South or southeast 4 or 5, increasing 6 at times. Moderate or rough, becoming very rough later in southwest. Rain or showers. Good, occasionally poor. From mrex@sap.com Thu Nov 17 13:26: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 AAB7A21F9863 for ; Thu, 17 Nov 2011 13:26:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.148 X-Spam-Level: X-Spam-Status: No, score=-10.148 tagged_above=-999 required=5 tests=[AWL=0.101, 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 1R173ScKj1e6 for ; Thu, 17 Nov 2011 13:26:30 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id C79DA21F9862 for ; Thu, 17 Nov 2011 13:26:29 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id pAHLQRSn019433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 17 Nov 2011 22:26:27 +0100 (MET) From: Martin Rex Message-Id: <201111172126.pAHLQQga002616@fs4113.wdf.sap.corp> To: mrex@sap.com Date: Thu, 17 Nov 2011 22:26:26 +0100 (MET) In-Reply-To: <201111172052.pAHKqTJ1000780@fs4113.wdf.sap.corp> from "Martin Rex" at Nov 17, 11 09:52:29 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] Scope of the protocol document or plea for progress 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, 17 Nov 2011 21:26:30 -0000 Martin Rex wrote: > > Jakob Schlyter wrote: > > > > Martin Rex wrote: > > > > > > By inserting fake DNS TLSA records, you can make the TLS client > > > that believe in TLSA absent of DNSSEC protection, reliably fail > > > connection to the real server that the attacker fails to MITM, > > > and showing only the connections that the attacker succeeds > > > to MITM as "trustworthy". This is the "firesheep" scenario. > > > > N.B.: this is the insecure non-matching case ONLY in combination > > with certificate usage type 0 and 1 ONLY. > > Yes, of course. AFAIK, noone suggested to believe in usage type 2 > TLSA records where DNSSEC validation fails. > > But think about what cert usage type 0 and 1 really means: > > It means that someone managed to obtain a cert for which the > PKIX validation performed by the client will pass! > > There is no point in DANE trying to protect from attacker who > can not do this, because the PKIX validation would reliably fail. > > The purpose of using DANE with usage types 0 and 1 at all is > giving the Domain Owner(!!) the ability to repudiate a certificate > that will pass the client's PKIX validation and server endpoint > identification. > > Believing in non-DNSSEC TLSA records of types 0 and 1 will result > in exactly the opposite to be achievable for an attacker: > > a) make a correct PKIX-validating and Domain-Owner approved TLS server cert > look fishy by a simple DNS spoof and have clients abort. > > and simultaneously > > b) make a fraudulent but PKIX-validating and *NOT* Domain-Owner approved > TLS server cert look acceptable by a simple DNS spoof and give clients a > false sense of security. But more importantly, believing in TLSA infos for which no DNSSEC validation can be performed might significantly impair interoperability. The IETF is about *improving* interop, not about reducing robustness and making things brittle. There might be simple, non-malicious, technical reasons (middle-boxes, firewalls, filtering) why a TLS client might not obtain all of the TLSA records that the DNS domain owner actually published and which would be visible to someone with unimpaired internet connectivity. Only when the DNSSEC signature verification succeeds we can be sure to have *ALL* of the data that the DNS domain owner published and unaltered. And only then we should take that information into consideration. Everything else amount to reading coffee grounds and may seriously impair the robustness of the infrastructure. If the client gets to see only some of that data, but not the necessary information, and a brittle DANE client aborts with "DANE validation failed", then the user at the client will call up the server admin to report incorrect DANE configuration -- which is obviously completely wrong and misleading in this situation, and the server admin can not repro the problems (caused by the middlebox near the client), and would not be able to fix them anyway. If the TLS client instead reported "can not perform DANE validation, incomplete data received", it would be accurate and significantly less confusing to any support folks that a user of that TLS client might contact. -Martin From jakob@kirei.se Fri Nov 18 03:40: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 559B121F89B8 for ; Fri, 18 Nov 2011 03:40:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JDRdp2OiMcno for ; Fri, 18 Nov 2011 03:40:15 -0800 (PST) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id A111021F88B6 for ; Fri, 18 Nov 2011 03:40:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=4inYoWVA8Wc1bJbubgYJQS80i8B1hPrsl6ZjNrb6JXc=; b=lAlfj5zXeYj3iimWDVErwPJJ2mfff5uTVd/hFvYa0aRJLF4IT5/Uc5DsdLXdKDODXI0oZZygM9O63 EHOvQRWJm+BAEcMR0upgcnvH5yr4tAo/gELs3MBbMJTJph3LBCPy1QRQV+/HecaXpU6EfrtIOGgrXL v/81vmyClWp9z/u0= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Fri, 18 Nov 2011 12:39:40 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Jakob Schlyter In-Reply-To: <201111172052.pAHKqTJ1000780@fs4113.wdf.sap.corp> Date: Fri, 18 Nov 2011 12:39:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <321A8A20-66F9-4064-B7A9-FD77795ABD5D@kirei.se> References: <201111172052.pAHKqTJ1000780@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1251.1) Cc: paul.hoffman@vpnc.org, dane@ietf.org Subject: Re: [dane] Scope of the protocol document or plea for progress X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 11:40:19 -0000 On 17 nov 2011, at 21:52, Martin Rex wrote: > Believing in non-DNSSEC TLSA records of types 0 and 1 will result > in exactly the opposite to be achievable for an attacker: >=20 > a) make a correct PKIX-validating and Domain-Owner approved TLS server = cert > look fishy by a simple DNS spoof and have clients abort. This is possible without DANE by spoofing the address record of the TLS = server. > and simultaneously >=20 > b) make a fraudulent but PKIX-validating and *NOT* Domain-Owner = approved > TLS server cert look acceptable by a simple DNS spoof and give = clients a > false sense of security. Please note that my proposal was not about positive matching, only about = negative matching where TLSA exists, but does not match the TLS server = certificate. This is NOT about trusting type 0/1 usages more than today, = it is about distrusting them in case a mis-match is found. jakob From jakob@kirei.se Fri Nov 18 03:41: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 9BFF421F8B05 for ; Fri, 18 Nov 2011 03:41:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELdxMMxZiK6d for ; Fri, 18 Nov 2011 03:41:33 -0800 (PST) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id B620821F88B6 for ; Fri, 18 Nov 2011 03:41:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=n/7j5DKiZAR2Soi/EA3vCvGE6+M7ExSjEgBfw/kLGcU=; b=dJBSqnrsmjVJ21U09Axys8isJaHxk5OReOcyo/MN3z+rcXKJtBECH6wrR5fkjR5gRScUpKbSaVg94 ma3nOk9HQCqDl5pT+9tEHFIjyFZMMQHDl2qniYgOoXKaqLG9Rjry1pQfVsRSWMpnTm1fuZiUZYw5V0 ki5Q1ebXqDr5c2Bc= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Fri, 18 Nov 2011 12:41:00 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Jakob Schlyter In-Reply-To: <201111172126.pAHLQQga002616@fs4113.wdf.sap.corp> Date: Fri, 18 Nov 2011 12:40:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <792679BB-D285-441C-B6D1-2DC73B8E30F1@kirei.se> References: <201111172126.pAHLQQga002616@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1251.1) Cc: paul.hoffman@vpnc.org, dane@ietf.org Subject: Re: [dane] Scope of the protocol document or plea for progress X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 11:41:33 -0000 On 17 nov 2011, at 22:26, Martin Rex wrote: > If the TLS client instead reported "can not perform DANE validation, > incomplete data received", it would be accurate and significantly less > confusing to any support folks that a user of that TLS client might = contact. I'm fine with such feedback to the user for the non-matching case. = Actually almost any feedback/warning on non-match would be useful. jakob From mrex@sap.com Fri Nov 18 09:02: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 AB7A31F0C47 for ; Fri, 18 Nov 2011 09:02:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.128 X-Spam-Level: X-Spam-Status: No, score=-10.128 tagged_above=-999 required=5 tests=[AWL=0.121, 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 7cQmvpypYiYJ for ; Fri, 18 Nov 2011 09:02:45 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id E59261F0C46 for ; Fri, 18 Nov 2011 09:02:44 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id pAIH2fbZ019050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 18 Nov 2011 18:02:42 +0100 (MET) From: Martin Rex Message-Id: <201111181702.pAIH2eIR011730@fs4113.wdf.sap.corp> To: jakob@kirei.se (Jakob Schlyter) Date: Fri, 18 Nov 2011 18:02:40 +0100 (MET) In-Reply-To: <321A8A20-66F9-4064-B7A9-FD77795ABD5D@kirei.se> from "Jakob Schlyter" at Nov 18, 11 12:39:32 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] Scope of the protocol document or plea for progress 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, 18 Nov 2011 17:02:45 -0000 Jakob Schlyter wrote: > > Martin Rex wrote: > > > > Believing in non-DNSSEC TLSA records of types 0 and 1 will result > > in exactly the opposite to be achievable for an attacker: > > > > a) make a correct PKIX-validating and Domain-Owner approved TLS server cert > > look fishy by a simple DNS spoof and have clients abort. > > This is possible without DANE by spoofing the address record of the TLS server. That is something _entirely_ different, because then you are, in fact, talking to the wrong server, and aborting is perfectly correct. > > > and simultaneously > > > > b) make a fraudulent but PKIX-validating and *NOT* Domain-Owner approved > > TLS server cert look acceptable by a simple DNS spoof and give clients a > > false sense of security. > > Please note that my proposal was not about positive matching, only > about negative matching where TLSA exists, but does not match the > TLS server certificate. This is NOT about trusting type 0/1 usages > more than today, it is about distrusting them in case a mis-match is found. I strongly believe the spec should not claim that such a pig could fly. I consider it likely that a non-negligible amount of implementors would get someting quite different airborne from what you intend. Personally, I think that the original design of TLS version negotiation is far from rocket science, but anyhow the entire installed base of Windows 7 and Windows 2008R2 has it wrong (that is several hundred million installations according to MS marketing and statcounters). What data do we have to make the bold claim that *all* TLS clients behind firewalls and middleboxes will see exactly *ALL* or *NONE* of the TLSA records and *nothing* in between? Pestering a non-negligible amounts of users with false alarms seems like a very bad idea and will only further desensitize users. -Martin From mrex@sap.com Fri Nov 18 09:36: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 13F3B11E8083 for ; Fri, 18 Nov 2011 09:36:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.13 X-Spam-Level: X-Spam-Status: No, score=-10.13 tagged_above=-999 required=5 tests=[AWL=0.119, 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 sj2ThY1jJegl for ; Fri, 18 Nov 2011 09:36:30 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id E612B11E8090 for ; Fri, 18 Nov 2011 09:36:29 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id pAIHaRdg022620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 18 Nov 2011 18:36:27 +0100 (MET) From: Martin Rex Message-Id: <201111181736.pAIHaQIQ013832@fs4113.wdf.sap.corp> To: mrex@sap.com Date: Fri, 18 Nov 2011 18:36:26 +0100 (MET) In-Reply-To: <201111181702.pAIH2eIR011730@fs4113.wdf.sap.corp> from "Martin Rex" at Nov 18, 11 06:02:40 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] Scope of the protocol document or plea for progress 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, 18 Nov 2011 17:36:31 -0000 Martin Rex wrote: > > Jakob Schlyter wrote: > > > > Please note that my proposal was not about positive matching, only > > about negative matching where TLSA exists, but does not match the > > TLS server certificate. This is NOT about trusting type 0/1 usages > > more than today, it is about distrusting them in case a mis-match is found. > > I strongly believe the spec should not claim that such a pig could > fly. I consider it likely that a non-negligible amount of implementors > would get someting quite different airborne from what you intend. I'm seriously concerned about the proposed functionality. A "failed" DANE validation of a usage type 0 or 1 cert is effectively a repudiation of a PKIX-validating(!!) cert with a different means. I don't know how "careless" CAs are acting when publishing certs on revocation lists. I would _not_ be surprised if they spend more effort on verifying the authenticity of revocations that they spend on verifying DV certs, and I fail to remember the part of PKIX and X.509 that says that one should entirely ignore when process X.509v2 CRLs for revocations and that the signature was only relevant for the "removeFromCRL" entries on the CRL. Btw. based on discussion on the PKIX list, I realized that there is likely a serious problem with usage type 0 TLSA records because of how a number of PKIX-fanatic TLS clients have implemented the processing of the Certificate handshake message in combination with how awkwardly a lot of CAs and some PKI software manages PKI credentials. Identifying PKIX "intermediate CA" certs by certificate or certificate hash (instead of subject public key info) is going to interfere badly with certificate renewal (and cross-certification). The only CAs cert where certificate/certificate-hash can be ensured by the server admin to be in sync with the information published in DNS are either permanent trust anchors that are not renewed or cross-certified, or those CA certs that the server sends within the forward certification path of the server Certificate handshake message. A number of TLS implementation appears to have the bad habit to perform pretty unpredictable certificate path discovery that includes a local pool of cached CA certs previously obtained from other sources and some might extremely unreasonable things such as AIA chasing, and those certs might get used _instead_ of those sent by the server for the PKIX certificate path validation, with the result that the DANE record for a CA cert/cert-hash may not match the CA cert that the client ended up with after PKIX path discovery voodoo. Distribution of renewed intermediate CA certs and subsitution with cross-CA certs will effectively be random/chaotic throughout the installed base. The only thing that can only change synchronous with the update of the server's certificate, is the public key that was used for signing the server's certificate. -Martin From trevorf@exchange.microsoft.com Fri Nov 18 13:43: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 422571F0C81 for ; Fri, 18 Nov 2011 13:43:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.644 X-Spam-Level: X-Spam-Status: No, score=-110.644 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 lYQnM10lWKSb for ; Fri, 18 Nov 2011 13:43:33 -0800 (PST) Received: from mail.exchange.microsoft.com (mail7.exchange.microsoft.com [131.107.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id BE03A1F0C7D for ; Fri, 18 Nov 2011 13:43:33 -0800 (PST) Received: from df-h14-01.exchange.corp.microsoft.com (157.54.78.139) by DF-G14-02.exchange.corp.microsoft.com (157.54.87.56) with Microsoft SMTP Server (TLS) id 14.2.247.2; Fri, 18 Nov 2011 13:43:33 -0800 Received: from PIO-MLT-06.exchange.corp.microsoft.com (157.54.94.24) by DF-H14-01.exchange.corp.microsoft.com (157.54.78.139) with Microsoft SMTP Server (TLS) id 14.2.247.5; Fri, 18 Nov 2011 13:43:33 -0800 Received: from DF-M14-12.exchange.corp.microsoft.com ([fe80::7c94:4036:120:c95f]) by PIO-MLT-06.exchange.corp.microsoft.com ([fe80::d57f:521a:3ae6:c130%10]) with mapi id 14.02.0267.001; Fri, 18 Nov 2011 13:43:32 -0800 From: Trevor Freeman To: Richard Barnes Thread-Topic: [dane] Fragility of binding to a CA certificate by certificate or ski Thread-Index: Acyjj0Rkb3L8aRwjTg+EWqkGLKap+gBpdl8AAEFv7LA= Date: Fri, 18 Nov 2011 21:43:32 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dane@ietf.org" Subject: Re: [dane] Fragility of binding to a CA certificate by certificate or ski X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 21:43:34 -0000 I was asking to add subject name as a selector field -----Original Message----- From: Richard Barnes [mailto:rbarnes@bbn.com]=20 Sent: Wednesday, November 16, 2011 10:28 PM To: Trevor Freeman Cc: dane@ietf.org Subject: Re: [dane] Fragility of binding to a CA certificate by certificate= or ski Just to clarify: Are you asking for some change to the spec, or just noting= an operational risk? Thanks, --Richard On Nov 15, 2011, at 8:08 PM, Trevor Freeman wrote: > For usage type =3D0, I am concerned about the fragility of matching a CA = certificate is only by full certificate or SKI. Certificates and keys have = an inherently limited lifetime. CAs need to renew both as a matter of routi= ne maintenance, which is an operation outside of the visibility of the doma= in and updating the domain DNS record is outside the control of the CA. Thi= s is a recipe for things to go wrong. All a CA can do is notify the domain = of the update and hope they make the change to the DNS record. > =20 > A more stable CA identifier would be a CA's subject name. This will remai= n constant as certificates and keys are renewed. You can easily put a hexad= ecimal encoded subject names in the DNS record and define a new match type.= It would also be simple for the CA to publish instructions for creating th= e DNS record and include the binary encoded subject name on the web page so= the domain administrator can simple cut and paste the value when creating = the DNS record for their domain and the instructions will not need updating= every time they renew their CA certificate. > =20 > Dr Trevor Freeman Senior Security Strategist End to End Trust Team=20 > Microsoft Trustworthy Computing > =20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From trevorf@exchange.microsoft.com Fri Nov 18 14:16: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 41E4211E8091 for ; Fri, 18 Nov 2011 14:16:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.342 X-Spam-Level: X-Spam-Status: No, score=-110.342 tagged_above=-999 required=5 tests=[AWL=-0.344, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_HI=-8, 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 rgClcwSiwPhB for ; Fri, 18 Nov 2011 14:15:55 -0800 (PST) Received: from mail.exchange.microsoft.com (mail7.exchange.microsoft.com [131.107.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id D3F8221F886A for ; Fri, 18 Nov 2011 14:15:54 -0800 (PST) Received: from df-h14-01.exchange.corp.microsoft.com (157.54.78.139) by DF-G14-02.exchange.corp.microsoft.com (157.54.87.56) with Microsoft SMTP Server (TLS) id 14.2.247.2; Fri, 18 Nov 2011 14:15:54 -0800 Received: from PIO-MLT-06.exchange.corp.microsoft.com (157.54.94.24) by DF-H14-01.exchange.corp.microsoft.com (157.54.78.139) with Microsoft SMTP Server (TLS) id 14.2.247.5; Fri, 18 Nov 2011 14:15:54 -0800 Received: from DF-M14-12.exchange.corp.microsoft.com ([fe80::7c94:4036:120:c95f]) by PIO-MLT-06.exchange.corp.microsoft.com ([fe80::d57f:521a:3ae6:c130%10]) with mapi id 14.02.0267.001; Fri, 18 Nov 2011 14:15:53 -0800 From: Trevor Freeman To: Richard Barnes Thread-Topic: [dane] Fragility of binding to a CA certificate by certificate or ski Thread-Index: Acyk7Zq4S+gnZYKDSF2buXtuovJkWQAR2OSAAEGKQTA= Date: Fri, 18 Nov 2011 22:15:53 +0000 Message-ID: References: <431D9158-63A6-4546-8E74-BFE0DF2FBA72@bbn.com> In-Reply-To: <431D9158-63A6-4546-8E74-BFE0DF2FBA72@bbn.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: multipart/alternative; boundary="_000_E545B914D50B2A4B994F198378B1525D427EE69FDFM1412exchange_" MIME-Version: 1.0 Cc: Adam Langley , "dane@ietf.org" Subject: Re: [dane] Fragility of binding to a CA certificate by certificate or ski X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 22:16:00 -0000 --_000_E545B914D50B2A4B994F198378B1525D427EE69FDFM1412exchange_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Richard, Lets get back to the threats because not all certificates are as easy to ge= nerate and be trusted Threat 1. Attacker socially engineers CA to provide a false identity verifi= cation 2. Attacker gets attack code into CAs environment and generates end u= ser certificate of their choice 3. Attacker gets attack code into CA environment and generates a CA c= ertificate of their choice 4. Attacker bribes a CA employee to get certificate of their choice. We have seen examples of #1 and #2 with end entity certificates and they ar= e only partially mitigated by better security and policy enforcement. #1 has not so far succeeded with a CA certificate because the checks are mu= ch more extensive. We are typically talking about certificates which cost t= ens of thousands of dollars or more each. It's not a simple, paste your req= uest and give us your credit card transaction like it is for SSL certificat= es. #3 has been mitigated by the public CA using path length constraints for o= nline CAs. This is typical by putting the path length =3D 0 into the online= CAs certificates but sometimes its higher up if the chin is longer. Pkix v= alidation means no CA certificate issued by a CA with path length =3D 0 wou= ld be trusted. #4 is still possible but that open up bribes to DNS registrars as well. So given getting an attacker cannot get a CA certificate by #3, we are left= with #1 and #4. Both #1 and #4 are at least one to two orders of magnitud= e harder than #2 and both are viable against DNNSEC as well Many organizations would accept such a trade for a more robust deployment. = I would not advocate subject name matching for end entity certificate becau= se of the feasibility of #2, but it is a reasonable option for a CA certifi= cate. Trevor -----Original Message----- From: Richard Barnes [mailto:rbarnes@bbn.com] Sent: Wednesday, November 16, 2011 10:27 PM To: Trevor Freeman Cc: Adam Langley; dane@ietf.org Subject: Re: [dane] Fragility of binding to a CA certificate by certificate= or ski > You description does not match what use type =3D0 Sure it does. Let me clarify: 1. example.com provisions a DANE record saying that any cert must chain thr= ough "CN=3Dsuper-trusted-ca.com" 2. Nefarious attacker generates a CA cert under a well-known TA with his ow= n key pair and "CN=3Dsuper-trusted-ca.com", and an EE cert under this CA. In that case, the cert matches the type=3D0 constraint, but it's clearly st= ill bogus. And the client still gets MitM'ed. > It would have been helpful if document somewhere the threats you want to = mitigate, vs. the threats you are not mitigating as it helps such discussi= ons. > > We need clarity around what threats DNSSEC addresses and what value DANE = adds over just DNSSEC. The threats highlighted in 6394 is a DNS name resolv= er attack which is intrinsically blocked by DNSSEC. Today, DNS based attack= s are fairly cheap and easy to use. > > Getting a bogus EE certificate is a district threat from a CA certificate= . I can stop trust in a CA certificate issued from an instance of a CA by = constraining the path length of the CA certificate which is what is happeni= ng today. This mitigates the threat of an attacker getting a CA certificate= from that CA. > > Equally since the relying party is using full pkix validation they can im= pose restrictions on the set of certificate policies - which again make it = impossible for any CA to issue a certificate with the right name and the ri= ght policy since the policy is constrained from the root CA down. > > There are these many reasons why when the client tries to validate the ce= rtificate issued by the bogus CA with the same name as published by DANE, w= hy pkix will reject the certificate path based on the relying party trust p= olicy. So the above attack is not viable if the RP/client imposes path length cons= traints on the TAs in its trust store. Are you aware of clients that actua= lly do this in practice? How do they decide what constraints to apply, giv= en that they don't know how the CAs they're trusting are structuring their = operations? > You may want to clarity what threats you are anticipating for how the att= acker mounts the mitm attack with DNSSEC since you now have the right ip ad= dresses. For example: --Richard > > Trevor > > > -----Original Message----- > From: Richard Barnes [mailto:rbarnes@bbn.com] > Sent: Thursday, November 17, 2011 9:54 AM > To: Trevor Freeman > Cc: Adam Langley; dane@ietf.org > Subject: Re: [dane] Fragility of binding to a CA certificate by > certificate or ski > > So are you not concerned about the following attack? > > 1. example.com provisions a DANE record saying that any cert that > comes under the CA "CN=3Dsuper-trusted-ca.com" is OK for that domain > > 2. Nefarious attacker generates a cert with his own key pair and "CN=3Dsu= per-trusted-ca.com" > > 3. Nefarious attacker MitMs a TLS session to example.com and presents > his cert > > 4. Client looks at the cert, sees the right name, and blissfully > proceeds with the hijacked session > > In light of this, any discussion of binding only to names is ridiculous. = I think this is what Adam was trying to say, a bit more politely. > > --RIchard > > > > > On Nov 17, 2011, at 9:31 AM, Trevor Freeman wrote: > >> Hi And, >> >> Pkix has many controls to control trust in CAs. There are more controls = for trust in CAs certificates than those over end entities. We are talking = about usage type =3D0 so the relying party has full control over their own = pkix policy. >> >> I agree that matching SKI is a stronger binding but it is not necessary = more robust if it results in loss of service. It's a much a business rick d= etermination if the site want to trade higher availability for a stronger b= inding. They are best placed to determine scale of impact from loss of serv= ice vs. an active attack. >> >> Given we are anticipating a work with DNSSEC, the attacker now has to ob= tain a site certificate and compromise some part of the routing infrastruct= ure for the mark so they can perform address mapping to redirect the ip tra= ffic to the bogus site. That is not an attack that scales well but if the C= A changes its key and the site did not update its DNS record, the site is d= own. >> >> Adam, you need to check 5280 section 6. Pkix chaining is name based not = key based. Yes it checks the signatures but SKI\AKI matching is not used i= n any way. >> >> Matching by subject name presents a strong CA binding mechanism which is= more robust against configuration mismatch - hence delver's higher availab= ility. >> >> Trevor >> >> -----Original Message----- >> From: alangley@gmail.com [mailto:alangley@gma= il.com] On Behalf Of >> Adam Langley >> Sent: Wednesday, November 16, 2011 11:38 AM >> To: Trevor Freeman >> Cc: dane@ietf.org >> Subject: Re: [dane] Fragility of binding to a CA certificate by >> certificate or ski >> >> On Tue, Nov 15, 2011 at 7:08 AM, Trevor Freeman > wrote: >>> For usage type =3D0, I am concerned about the fragility of matching a >>> CA certificate is only by full certificate or SKI. Certificates and >>> keys have an inherently limited lifetime. >> >> You are correct that matching by a certificate is a mistake because CAs = often reissue their CA certificates and clients build chains from the botto= m up. >> >> However, matching a SubjectPublicKeyInfo is rather robust. Certainly the= leaf certificate cannot change without a site reconfiguring their servers.= That implies that the next certificate's (call it I1) SPKI is fixed by the= leaf (because it has to match the signature on the leaf). >> >> Above that, one could imagine the combination of: >> * The site fails to include any intermediate certificates >> * The leaf doesn't include an Authority Key Identifier, but incudes >> an AIA URL for I1 >> * I1 is replaced with a certificate with the same SPKI, but a different = issuer. >> >> That way the CA could redirect the chain without the site knowing. >> However, it requires a misconfiguration of the site (that will cause int= ermittent issues and some clients to fail completely) and a grossly stupid = CA. >> >> On the other hand, specifying via CA Subject name is very weak: any CA c= an issue certificates with any Subject name. >> >> >> Cheers >> >> AGL >> >> -- >> Adam Langley agl@imperialviolet.org http:= //www.imperialviolet.org >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane > --_000_E545B914D50B2A4B994F198378B1525D427EE69FDFM1412exchange_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Richard,

 

Lets get back to the= threats because not all certificates are as easy to generate and be truste= d

 

Threat

1.       Attacker socially engineers CA to provide a = false  identity verification

2.       Attacker gets attack code into CAs environme= nt and generates end user certificate of their choice

3.       Attacker gets attack code into CA environmen= t and generates a CA certificate of their choice

4.       Attacker bribes a CA employee to get certifi= cate of their choice.

 

We have seen examples of #1 and #2 with end entit= y certificates and they are only partially mitigated by better security and= policy enforcement.

#1 has not so far succeeded with a CA certificate= because the checks are much more extensive. We are typically talking about= certificates which cost tens of thousands of dollars or more each. It̵= 7;s not a simple, paste your request and give us your credit card transaction like it is for SSL certificates.

 #3 = has been mitigated by the public CA using path length constraints for onlin= e CAs. This is typical by putting the path length =3D 0 into the online CAs= certificates but sometimes its higher up if the chin is longer. Pkix validation means no CA certificate issued by a CA= with path length =3D 0 would be trusted.

#4 is still possible but that open up bribes to D= NS registrars as well.

 

So given getting an attacker cannot get a CA cert= ificate by #3, we are left with #1 and #4. Both #1 and #4  are at least one to tw= o orders of magnitude harder than #2 and both are viable against DNNSEC as = well

 

Many organizations would accept such a trade for = a more robust deployment. I would not advocate subject name matching for en= d entity certificate because of the feasibility of #2, but it is a reasonab= le option for a CA certificate.

 

Trevor

 

-----Original Message-----
From: Richard Barnes [mailto:rbarnes@bbn.com]
Sent: Wednesday, November 16, 2011 10:27 PM
To: Trevor Freeman
Cc: Adam Langley; dane@ietf.org
Subject: Re: [dane] Fragility of binding to a CA certificate by certificate= or ski

 

> You description does not match what use type= =3D0

 

Sure it does.&nb= sp; Let me clarify:

 

1. example.com provisions a DANE record saying th= at any cert must chain through "CN=3Dsuper-trusted-ca.com"

 

2. Nefarious attacker generates a CA cert under a= well-known TA with his own key pair and "CN=3Dsuper-trusted-ca.com&qu= ot;, and an EE cert under this CA.

 

In that case, the cert matches the type=3D0 const= raint, but it's clearly still bogus.  And the client still gets MitM'ed.

 

 

> It would have been helpful if document somew= here the threats you want to  mitigate, vs. the threats you are not mitigating as it helps such di= scussions.

>

> We need clarity around what threats DNSSEC a= ddresses and what value DANE adds over just DNSSEC. The threats highlighted= in 6394 is a DNS name resolver attack which is intrinsically blocked by DN= SSEC. Today, DNS based attacks are fairly cheap and easy to use.

>

> Getting a bogus EE certificate is a district= threat from a CA certificate.  I can stop trust in a CA certificate issued from an instance of a CA= by constraining the path length of the CA certificate which is what is hap= pening today. This mitigates the threat of an attacker getting a CA certifi= cate from that CA.

>

> Equally since the relying party is using ful= l pkix validation they can impose restrictions on the set of certificate po= licies - which again make it impossible for any CA to issue a certificate w= ith the right name and the right policy since the policy is constrained from the root CA down.

>

> There are these many reasons why when the cl= ient tries to validate the certificate issued by the bogus CA with the same= name as published by DANE, why pkix will reject the certificate path based= on the relying party trust policy.

 

So the above attack is not viable if the RP/clien= t imposes path length constraints on the TAs in its trust store.  Are you aware of clients that actually do this in practice?  How do they decide what constraints to apply, given that they don't = know how the CAs they're trusting are structuring their operations?

 

 

> You may want to clarity what threats you are= anticipating for how the attacker mounts the mitm attack with DNSSEC since= you now have the right ip addresses. = ;

 

For example:

<http://en.wikipedia.org/wiki/ARP_spoofing>=

<http://en.wikipedia.org/wiki/IP_hijacking>=

 

--Richard

 

 

 

 

>

> Trevor

>

>

> -----Original Message-----

> From: Richard Barnes [= mailto:rbarnes@bbn.com]

> Sent: Thursday, November 17, 2011 9:54 AM

> To: Trevor Freeman

> Cc: Adam Langley; dane@ietf.org

> Subject: Re: [dane] Fragility of binding to = a CA certificate by

> certificate or ski

>

> So are you not concerned about the following= attack?

>

> 1. example.com provisions a DANE record sayi= ng that any cert that

> comes under the CA "CN=3Dsuper-trusted-= ca.com" is OK for that domain

>

> 2. Nefarious attacker generates a cert with = his own key pair and "CN=3Dsuper-trusted-ca.com"

>

> 3. Nefarious attacker MitMs a TLS session to= example.com and presents

> his cert

>

> 4. Client looks at the cert, sees the right = name, and blissfully

> proceeds with the hijacked session

>

> In light of this, any discussion of binding = only to names is ridiculous.  I think this is what Adam was trying to say, a bit more politely.

>

> --RIchard

>

>

>

>

> On Nov 17, 2011, at 9:31 AM, Trevor Freeman = wrote:

>

>> Hi And,

>>

>> Pkix has many controls to control trust = in CAs. There are more controls for trust in CAs certificates than those ov= er end entities. We are talking about usage type =3D0 so the relying party = has full control over their own pkix policy.

>>

>> I agree that matching SKI is a stronger = binding but it is not necessary more robust if it results in loss of servic= e. It's a much a business rick determination if the site want to trade high= er availability for a stronger binding. They are best placed to determine scale of impact from loss of service vs.= an active attack.

>>

>> Given we are anticipating a work with DN= SSEC, the attacker now has to obtain a site certificate and compromise some= part of the routing infrastructure for the mark so they can perform addres= s mapping to redirect the ip traffic to the bogus site. That is not an attack that scales well but if the CA chang= es its key and the site did not update its DNS record, the site is down.

>>

>> Adam, you need to check 5280 section 6. = Pkix chaining is name based not key based.=   Yes it checks the signatures but SKI\AKI matching is not used in any= way.

>>

>> Matching by subject name presents a stro= ng CA binding mechanism which is more robust against configuration mismatch= - hence delver's higher availability.

>>

>> Trevor

>>

>> -----Original Message-----

>> From: alangley@gmail.com [mailto:alangley@gmail.com] On Behalf Of

>> Adam Langley

>> Sent: Wednesday, November 16, 2011 11:38= AM

>> To: Trevor Freeman

>> Cc: dane= @ietf.org

>> Subject: Re: [dane] Fragility of binding= to a CA certificate by

>> certificate or ski

>>

>> On Tue, Nov 15, 2011 at 7:08 AM, Trevor = Freeman <trevorf@exch= ange.microsoft.com> wrote:

>>> For usage type =3D0, I am concerned = about the fragility of matching a

>>> CA certificate is only by full certi= ficate or SKI. Certificates and

>>> keys have an inherently limited life= time.

>>

>> You are correct that matching by a certi= ficate is a mistake because CAs often reissue their CA certificates and cli= ents build chains from the bottom up.

>>

>> However, matching a SubjectPublicKeyInfo= is rather robust. Certainly the leaf certificate cannot change without a s= ite reconfiguring their servers. That implies that the next certificate's (= call it I1) SPKI is fixed by the leaf (because it has to match the signature on the leaf).

>>

>> Above that, one could imagine the combin= ation of:

>> * The site fails to include any intermed= iate certificates

>> * The leaf doesn't include an Authority = Key Identifier, but incudes

>> an AIA URL for I1

>> * I1 is replaced with a certificate with= the same SPKI, but a different issuer.

>>

>> That way the CA could redirect the chain= without the site knowing.

>> However, it requires a misconfiguration = of the site (that will cause intermittent issues and some clients to fail c= ompletely) and a grossly stupid CA.

>>

>> On the other hand, specifying via CA Sub= ject name is very weak: any CA can issue certificates with any Subject name= .

>>

>>

>> Cheers

>>

>> AGL

>>

>> --

>> Adam Langley agl@imperialviolet.org http://www.imperialviolet.org

>> ________________________________________= _______

>> dane mailing list

>> dane@iet= f.org

>> https://www.ietf.org/mailman/listinfo/dane

>

 

--_000_E545B914D50B2A4B994F198378B1525D427EE69FDFM1412exchange_-- From mrex@sap.com Fri Nov 18 14:57: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 4F8D31F0C45 for ; Fri, 18 Nov 2011 14:57:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.133 X-Spam-Level: X-Spam-Status: No, score=-10.133 tagged_above=-999 required=5 tests=[AWL=0.116, 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 2CWIiKUFbkJc for ; Fri, 18 Nov 2011 14:57:33 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9F81F0C40 for ; Fri, 18 Nov 2011 14:57:33 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id pAIMvMOQ029309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 18 Nov 2011 23:57:22 +0100 (MET) From: Martin Rex Message-Id: <201111182257.pAIMvL53002529@fs4113.wdf.sap.corp> To: trevorf@exchange.microsoft.com (Trevor Freeman) Date: Fri, 18 Nov 2011 23:57:21 +0100 (MET) In-Reply-To: from "Trevor Freeman" at Nov 18, 11 10:15:53 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: agl@imperialviolet.org, dane@ietf.org Subject: Re: [dane] Fragility of PKIX path discovery 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, 18 Nov 2011 22:57:34 -0000 Trevor Freeman wrote: > > Lets get back to the threats because not all certificates are as > easy to generate and be trusted > > 3. Attacker gets attack code into CA environment and generates > a CA certificate of their choice > > #3 has been mitigated by the public CA using path length constraints > for online CAs. This is typical by putting the path length = 0 into > the online CAs certificates but sometimes its higher up if the chin > is longer. Pkix validation means no CA certificate issued by a CA > with path length = 0 would be trusted. Some 9 years ago it was discovered that MSIE would not check for "BasicConstraint cA=TRUE" in a certificate before accepting it as a CA cert in a certification path, therefore all End-Entity certs were treated equivalent to real CA certs: http://www.thoughtcrime.org/ie-ssl-chain.txt In 2011 it was reported that none of the existing versions of Apple iOS was having the exact same defect and would accept End-Entity certs as valid CA certs in certification paths. http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-0228 Your claim about PathLenConstraint=0 saving the day, reminds me of a quote from a movie: Did you see the body? Assumption is the mother of all F*** UPS! -Martin From paul.hoffman@vpnc.org Fri Nov 18 16:10: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 979EF21F8480 for ; Fri, 18 Nov 2011 16:10:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 9aiajdQ6eb0L for ; Fri, 18 Nov 2011 16:10:28 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3370121F846A for ; Fri, 18 Nov 2011 16:10:28 -0800 (PST) Received: from [192.168.100.102] (61-220-70-183.HINET-IP.hinet.net [61.220.70.183]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id pAJ0A64V006661 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 18 Nov 2011 17:10:08 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 19 Nov 2011 08:10:08 +0800 Message-Id: <45EA694E-096C-41A1-B60E-BF7B3832FE2A@vpnc.org> To: IETF DANE WG list Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: [dane] Aiming towards some specific wording X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 19 Nov 2011 00:10:29 -0000 Greetings again. The recent threads are useful, but some people change = the topic mid-thread so determining what actual words people want in the = draft is difficult. As document co-author, I want to nail down the = words. To do that, the WG needs some choices, and that is the purpose of = this message. I have tried to cast each of the choices expressed in the = past few days in actual text that would appear in the document. THIS IS NOT A CALL FOR SUPPORT FOR ANY WORDING!!! This is a call to be = sure that all opinions are given for a LATER CALL. Sorry to use the ALL = CAPS there, but people here tend to vote quickly and then ask for = modifications later. I propose the following preamble wording to the "interesting" parts of = the wording: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D PREAMBLE A START =3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Determining whether a TLS certificate association can be used depends on the DNSSEC valiation state (as defined in [RFC4033]). o A TLS certificate association whose DNSSEC validation state is secure can be used for TLS. o A TLS certificate association whose DNSSEC validation state is bogus cannot be used for TLS and must be marked as unusable. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D PREAMBLE A END =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= One of the following, or some other choice, needs to be added to the = preamble. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONTINUATION 1 START =3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D o A TLS certificate association whose DNSSEC validation state is indeterminate cannot be used for TLS and must be marked as unusable. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONTINUATION 1 END =3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D ############# OR #################### =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONTINUATION 2 START =3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D o A TLS certificate association whose DNSSEC validation state is indeterminate and whose usage is 0 or 1 MAY be used for TLS if application marks it as usable. o A TLS certificate association whose DNSSEC validation state is indeterminate and whose usage is 2 MUST NOT be used for TLS and must be marked as unusable. o Future definitions of new certificate usages MUST include specification of whether or not DNSSEC validation is required for that usage. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONTINUATION 2 END =3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Again, PLEASE DO NOT SAY YET WHICH OF THESE YOU SUPPORT. Instead, if you = think the wording in Preamble A, Continuation 1, or Continuation 2 do = not exactly match what you would want in the spec, please propose a = different preamble or continuation text (not just "ideas"). That way, = when we later ask for what wording people want, all proposals will = already be on the table and we will not (again) have wording changes = appear mid-vote. Thanks in advance for your cooperation. --Paul Hoffman From zack.weinberg@gmail.com Fri Nov 18 17:08: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 605831F0C40 for ; Fri, 18 Nov 2011 17:08:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J+uXH9D9I-sA for ; Fri, 18 Nov 2011 17:08:06 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id A25171F0C3C for ; Fri, 18 Nov 2011 17:08:06 -0800 (PST) Received: by yenm7 with SMTP id m7so568299yen.31 for ; Fri, 18 Nov 2011 17:08:06 -0800 (PST) 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=RvM8c4yW/bEAvxaG76fE1vpKRGG7z4H6lpF4Pv+Hrgo=; b=wBlU+DU0HTZIVgCDHEmJt1lxRaKTbAXFHzp2SGflPyMLS19DpdFFqWQFXNZMDjREcg G7IkZgWkzz13RsqRxi59KmPTCB3Taof4pSlZT9WEnREW9n31+/Oe+NdyKQ+DOHxs4XMj CWiuFIICD6Xi3ds8VEYJgTxdHKt8tlmZxhObE= Received: by 10.236.154.42 with SMTP id g30mr9172548yhk.3.1321664886161; Fri, 18 Nov 2011 17:08:06 -0800 (PST) Received: from dhcp-141.danastreet.live555.com (dhcp-141.danastreet.live555.com. [64.6.174.141]) by mx.google.com with ESMTPS id k20sm6934512ann.15.2011.11.18.17.08.05 (version=SSLv3 cipher=OTHER); Fri, 18 Nov 2011 17:08:05 -0800 (PST) Sender: Zack Weinberg Message-ID: <4EC70173.9090106@sv.cmu.edu> Date: Fri, 18 Nov 2011 17:08:03 -0800 From: Zack Weinberg User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: dane@ietf.org References: <45EA694E-096C-41A1-B60E-BF7B3832FE2A@vpnc.org> In-Reply-To: <45EA694E-096C-41A1-B60E-BF7B3832FE2A@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dane] Aiming towards some specific wording X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 19 Nov 2011 01:08:07 -0000 On 2011-11-18 4:10 PM, Paul Hoffman wrote: > Greetings again. The recent threads are useful, but some people change the topic mid-thread so determining what actual words people want in the draft is difficult. As document co-author, I want to nail down the words. To do that, the WG needs some choices, and that is the purpose of this message. I have tried to cast each of the choices expressed in the past few days in actual text that would appear in the document. > > THIS IS NOT A CALL FOR SUPPORT FOR ANY WORDING!!! This is a call to be sure that all opinions are given for a LATER CALL. Sorry to use the ALL CAPS there, but people here tend to vote quickly and then ask for modifications later. > > I propose the following preamble wording to the "interesting" parts of the wording: I think the terminology that is currently being used for this stuff ("association", "mark as (un)usable", "can(not) use for TLS" is confusing and needs to be replaced wholesale. However, that is an editorial issue that can be addressed separately from this wording change. Now, my understanding of the debate is that everyone agrees that the "bogus" DNSSEC state needs to cause a TLS connection abort, but the "indeterminate" and "insecure" DNSSEC states _at worst_ need to cause TLSA records to be ignored. The argument, as I understand it, is just over whether _all_ TLSA records need to be ignored when DNSSEC comes back "indeterminate" or "insecure". Therefore, > Determining whether a TLS certificate association can be used depends > on the DNSSEC valiation state (as defined in [RFC4033]). > > o A TLS certificate association whose DNSSEC validation state is > secure can be used for TLS. this is fine (except for the terminology caveat above), but > o A TLS certificate association whose DNSSEC validation state is > bogus cannot be used for TLS and must be marked as unusable. > o A TLS certificate association whose DNSSEC validation state is > indeterminate cannot be used for TLS and must be marked as > unusable. at least one of these sentences is wrong; as written, either both validation states cause a connection abort, or neither do. If it is the second sentence that is wrong, both Continuation 1 and 2 need to change. Also, the new text needs to explicitly cover DNSSEC validation state "insecure", which is presently not mentioned. I don't know any reason to treat it differently from "indeterminate"; it just needs to be mentioned as a possibility. Other than that, the proposed alternatives cover all of the sides of the debate as far as I can tell. zw From hallam@gmail.com Fri Nov 18 19:48: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 5559011E80A4 for ; Fri, 18 Nov 2011 19:48:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.485 X-Spam-Level: X-Spam-Status: No, score=-3.485 tagged_above=-999 required=5 tests=[AWL=0.113, 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 rlbdj7+PPv-p for ; Fri, 18 Nov 2011 19:48:56 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3EF11E8087 for ; Fri, 18 Nov 2011 19:48:56 -0800 (PST) Received: by ggeq3 with SMTP id q3so1948916gge.31 for ; Fri, 18 Nov 2011 19:48:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7f4BMPHcgYA2ALiZ9PTWEJlPaU0EPBG6atLxGgoCQ98=; b=jYALL0IPvQflb/omBn1LGfzgi11B2mvqUV1k9Ut4iCpKDl8qCIq8gwm0OxA9BNX7pv y3j9QeXJLa73hysqtnq2gldQa4NbE+jYDoJxoVQPXROEGaZxMDZhbDQd0MT30dNBmy+J pD+EXfRbm5pngRcTqDDr7S/gbMqFrm5i2dFww= MIME-Version: 1.0 Received: by 10.182.227.7 with SMTP id rw7mr1306600obc.70.1321674535105; Fri, 18 Nov 2011 19:48:55 -0800 (PST) Received: by 10.182.42.99 with HTTP; Fri, 18 Nov 2011 19:48:54 -0800 (PST) In-Reply-To: <201111182257.pAIMvL53002529@fs4113.wdf.sap.corp> References: <201111182257.pAIMvL53002529@fs4113.wdf.sap.corp> Date: Fri, 18 Nov 2011 22:48:54 -0500 Message-ID: From: Phillip Hallam-Baker To: mrex@sap.com Content-Type: multipart/alternative; boundary=f46d044472bb2c73d804b20e553f Cc: agl@imperialviolet.org, dane@ietf.org Subject: Re: [dane] Fragility of PKIX path discovery X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 19 Nov 2011 03:48:57 -0000 --f46d044472bb2c73d804b20e553f Content-Type: text/plain; charset=ISO-8859-1 Really, this one way 'lets beat up on PKIX but nobody can ever question DNSSEC' is getting tiresome. What you want is to have free hits on PKIX then run hide behind mommy when your scheme is considered. People screw up the implementation of all crypto code. Some people will screw up the implementation of DANE as well, if you are lucky enough for people to implement it. On Fri, Nov 18, 2011 at 5:57 PM, Martin Rex wrote: > Trevor Freeman wrote: > > > > Lets get back to the threats because not all certificates are as > > easy to generate and be trusted > > > > 3. Attacker gets attack code into CA environment and generates > > a CA certificate of their choice > > > > #3 has been mitigated by the public CA using path length constraints > > for online CAs. This is typical by putting the path length = 0 into > > the online CAs certificates but sometimes its higher up if the chin > > is longer. Pkix validation means no CA certificate issued by a CA > > with path length = 0 would be trusted. > > Some 9 years ago it was discovered that MSIE would not check for > "BasicConstraint cA=TRUE" in a certificate before accepting it as > a CA cert in a certification path, therefore all End-Entity certs > were treated equivalent to real CA certs: > > http://www.thoughtcrime.org/ie-ssl-chain.txt > > In 2011 it was reported that none of the existing versions of > Apple iOS was having the exact same defect and would accept > End-Entity certs as valid CA certs in certification paths. > > http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-0228 > > > Your claim about PathLenConstraint=0 saving the day, > reminds me of a quote from a movie: > > Did you see the body? Assumption is the mother of all F*** UPS! > > > -Martin > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > -- Website: http://hallambaker.com/ --f46d044472bb2c73d804b20e553f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Really, this one way 'lets beat up on PKIX but nobody can ever question= DNSSEC' is getting tiresome. What you want is to have free hits on PKI= X then run hide behind mommy when your scheme is considered.

People screw up the implementation of all crypto code. Some people wil= l screw up the implementation of DANE as well, if you are lucky enough for = people to implement it.


On Fri= , Nov 18, 2011 at 5:57 PM, Martin Rex <mrex@sap.com> wrote:
Trevor Freeman wrote:
>
> Lets get back to the threats because not all certificates are as
> easy to generate and be trusted
>
> 3. =A0Attacker gets attack code into CA environment and generates
> =A0 =A0 a CA certificate of their choice
>
> #3 has been mitigated by the public CA using path length constraints > for online CAs. This is typical by putting the path length =3D 0 into<= br> > the online CAs certificates but sometimes its higher up if the chin > is longer. =A0Pkix validation means no CA certificate issued by a CA > with path length =3D 0 would be trusted.

Some 9 years ago it was discovered that MSIE would not check for
"BasicConstraint cA=3DTRUE" in a certificate before accepting it = as
a CA cert in a certification path, therefore all End-Entity certs
were treated equivalent to real CA certs:

=A0http://www.thoughtcrime.org/ie-ssl-chain.txt

In 2011 it was reported that none of the existing versions of
Apple iOS was having the exact same defect and would accept
End-Entity certs as valid CA certs in certification paths.

=A0http://web.nvd.nist.gov/view/vuln/detail?vulnId=3DCV= E-2011-0228


Your claim about PathLenConstraint=3D0 saving the day,
reminds me of a quote from a movie:

=A0Did you see the body? Assumption is the mother of all F*** UPS!


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



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

--f46d044472bb2c73d804b20e553f-- From paul.hoffman@vpnc.org Sat Nov 19 02:46: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 1D28621F84B8 for ; Sat, 19 Nov 2011 02:46:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.933 X-Spam-Level: X-Spam-Status: No, score=-100.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_RECV_SPAM_DOMN0b=1.666, 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 PGElY+KQkx5j for ; Sat, 19 Nov 2011 02:46:23 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 95E9F21F84B4 for ; Sat, 19 Nov 2011 02:46:23 -0800 (PST) Received: from 220-137-252-28.dynamic.hinet.net (220-137-252-28.dynamic.hinet.net [220.137.252.28]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id pAJAkJ5o025154 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 19 Nov 2011 03:46:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Paul Hoffman In-Reply-To: <4EC70173.9090106@sv.cmu.edu> Date: Sat, 19 Nov 2011 18:46:22 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <247CAE36-68FB-4048-B07C-9B4C0903434D@vpnc.org> References: <45EA694E-096C-41A1-B60E-BF7B3832FE2A@vpnc.org> <4EC70173.9090106@sv.cmu.edu> To: IETF DANE WG list X-Mailer: Apple Mail (2.1251.1) Subject: Re: [dane] Aiming towards some specific wording X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 19 Nov 2011 10:46:24 -0000 On Nov 19, 2011, at 9:08 AM, Zack Weinberg wrote: > Now, my understanding of the debate is that everyone agrees that the = "bogus" DNSSEC state needs to cause a TLS connection abort, That was not my understanding from the earlier thread, but you could be = right. Why would a DNS lookup for the TLSA record cause a TLS connection = abort? First, it is unrelated to TLS it self if the data from TLSA is = not used. Second, there may be other valid records returned, so aborting = instead of just throwing away the bad data will lead to lack of secure = connections when secure connections were possible. Third, that rule seem = nonsensical in light of the fact that there is no parallel rule for a = bogus response on the A record lookup. Can someone who supports "bogus response on TLSA lookup" explain why it = should be more than "throw away the data from that record", particularly = in light of the last point? > but the "indeterminate" and "insecure" DNSSEC states _at worst_ need = to cause TLSA records to be ignored. The argument, as I understand it, = is just over whether _all_ TLSA records need to be ignored when DNSSEC = comes back "indeterminate" or "insecure". That was my impression. > Therefore, >=20 >> Determining whether a TLS certificate association can be used depends >> on the DNSSEC valiation state (as defined in [RFC4033]). >>=20 >> o A TLS certificate association whose DNSSEC validation state is >> secure can be used for TLS. >=20 > this is fine (except for the terminology caveat above), but >=20 >> o A TLS certificate association whose DNSSEC validation state is >> bogus cannot be used for TLS and must be marked as unusable. >=20 > > o A TLS certificate association whose DNSSEC validation state is > > indeterminate cannot be used for TLS and must be marked as > > unusable. >=20 > at least one of these sentences is wrong; as written, either both = validation states cause a connection abort, or neither do. If it is the = second sentence that is wrong, both Continuation 1 and 2 need to change. There is nothing about "abort" in either of those two sentences, so = "neither do" is correct. There is no assumption that a connection has = been started. There is an assumption that there might be additional TLSA = records that can be used even if the bogus record is unusable. > Also, the new text needs to explicitly cover DNSSEC validation state = "insecure", which is presently not mentioned. I don't know any reason = to treat it differently from "indeterminate"; it just needs to be = mentioned as a possibility. I purposely elft out insecure because the DNS root is now signed, but = since this morning, I have thought of cases where one might get = "insecure" due to local policy. I will change "indeterminate" to = "indeterminate or insecure" everywhere. --Paul Hoffman From ynir@checkpoint.com Sat Nov 19 02:58: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 2FEBF21F8511 for ; Sat, 19 Nov 2011 02:58:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.423 X-Spam-Level: X-Spam-Status: No, score=-10.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1LrC-6wjXdKY for ; Sat, 19 Nov 2011 02:58:11 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 4481E21F8510 for ; Sat, 19 Nov 2011 02:58:11 -0800 (PST) X-CheckPoint: {4EC78B53-0-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id pAJAw9qq006098; Sat, 19 Nov 2011 12:58:09 +0200 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sat, 19 Nov 2011 12:58:09 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Sat, 19 Nov 2011 12:58:09 +0200 From: Yoav Nir To: Paul Hoffman Date: Sat, 19 Nov 2011 12:58:08 +0200 Thread-Topic: [dane] Aiming towards some specific wording Thread-Index: Acymqh85PzIk7tbPTrW1trE7G9hBpw== Message-ID: <92AA2445-000C-44CF-8CA5-9796528EA946@checkpoint.com> References: <45EA694E-096C-41A1-B60E-BF7B3832FE2A@vpnc.org> <4EC70173.9090106@sv.cmu.edu> <247CAE36-68FB-4048-B07C-9B4C0903434D@vpnc.org> In-Reply-To: <247CAE36-68FB-4048-B07C-9B4C0903434D@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: IETF DANE WG list Subject: Re: [dane] Aiming towards some specific wording X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 19 Nov 2011 10:58:12 -0000 On Nov 19, 2011, at 11:46 AM, Paul Hoffman wrote: > On Nov 19, 2011, at 9:08 AM, Zack Weinberg wrote: >=20 >> Now, my understanding of the debate is that everyone agrees that the "bo= gus" DNSSEC state needs to cause a TLS connection abort, >=20 > That was not my understanding from the earlier thread, but you could be r= ight. Why would a DNS lookup for the TLSA record cause a TLS connection abo= rt? First, it is unrelated to TLS it self if the data from TLSA is not used= . Second, there may be other valid records returned, so aborting instead of= just throwing away the bad data will lead to lack of secure connections wh= en secure connections were possible. Third, that rule seem nonsensical in l= ight of the fact that there is no parallel rule for a bogus response on the= A record lookup. >=20 > Can someone who supports "bogus response on TLSA lookup" explain why it s= hould be more than "throw away the data from that record", particularly in = light of the last point? I am not in that camp, but since we are requiring TLSA to be secure, but no= t requiring this (for now) for A records, it makes no sense for an attacker= to forge a signature on the A record: you will accept it unsigned anyway. = A successfully forged TLSA record is the difference between getting a warni= ng screen for your invalid certificate, and not getting such a warning scre= en. If there is not difference in behavior between a missing TLSA record and a = bogus TLSA record, there is no deterrent for the attacker to try to send it= . OTOH, if the attacker cannot modify A records but can inject TLSA record= s, this would be a convenient way to DoS the server - just inject a bogus r= ecord, and that is why I am *not* in that camp. Yoav= From ondrej.mikle@nic.cz Sat Nov 19 08:38: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 E305821F84DA for ; Sat, 19 Nov 2011 08:38:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u0UBvqQVCW1o for ; Sat, 19 Nov 2011 08:38:30 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id B98C221F84B4 for ; Sat, 19 Nov 2011 08:38:29 -0800 (PST) Received: from [172.30.151.65] (ip-84-42-137-177.net.upcbroadband.cz [84.42.137.177]) by mail.nic.cz (Postfix) with ESMTPSA id DDAF12A27BE for ; Sat, 19 Nov 2011 17:38:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1321720706; bh=kfbVtyobKGGx7WVAApmu8yPdUOTps0xineWmSMgjHoE=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=adUP/y00qvY8N1NRy9IeFEYHHoaXV+65Jafi4okrKwX/F970V3B7GI7B/IE+GqoDj vFWEiXt8DvJ6gmoI6RlXkkESmnDJOpOW6zt4OTzDddpqXvSL1fQuoXPFqHzVnkeJZE ymh3a2ayUSmFVtAx0zI5EyAff+XwKH+3TOYjC8hs= Message-ID: <4EC7DB81.1080502@nic.cz> Date: Sat, 19 Nov 2011 17:38:25 +0100 From: Ondrej Mikle User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110409 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: dane@ietf.org References: <201111181736.pAIHaQIQ013832@fs4113.wdf.sap.corp> In-Reply-To: <201111181736.pAIHaQIQ013832@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: Re: [dane] Scope of the protocol document or plea for progress X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 19 Nov 2011 16:38:31 -0000 On 11/18/11 18:36, Martin Rex wrote: > Identifying PKIX "intermediate CA" certs by certificate or certificate > hash (instead of subject public key info) is going to interfere badly > with certificate renewal (and cross-certification). > > The only CAs cert where certificate/certificate-hash can be ensured > by the server admin to be in sync with the information published in DNS > are either permanent trust anchors that are not renewed or cross-certified, > or those CA certs that the server sends within the forward certification > path of the server Certificate handshake message. > > A number of TLS implementation appears to have the bad habit to > perform pretty unpredictable certificate path discovery that > includes a local pool of cached CA certs previously obtained > from other sources and some might extremely unreasonable things such > as AIA chasing, and those certs might get used _instead_ of those > sent by the server for the PKIX certificate path validation, > with the result that the DANE record for a CA cert/cert-hash > may not match the CA cert that the client ended up with after > PKIX path discovery voodoo. Distribution of renewed intermediate > CA certs and subsitution with cross-CA certs will effectively > be random/chaotic throughout the installed base. The only thing > that can only change synchronous with the update of the > server's certificate, is the public key that was used for signing > the server's certificate. Thanks for bringing this up again. Due to TLS client caching there's around 97000 "transvalid" certs that validate because of cached cert. Do you have a (partial) list of TLS implementions/clients that do the caching? (browsers or their TLS libraries mostly do this) This "transvalidity feature/bug" happens mostly due to fact that the site operators have no idea about the caching behavior - they see it works in their browsers, but don't check a clean browser profile installation (I wonder what good the caching should exactly do, except for making badly-configured servers work). AIA chasing? Out of curiosity, which TLS implementation does that? Cross-certs and resigned certs: the amount of sites experiencing the swapping by browser is quite vast. Most common are probably md2WithRsaEncryption Verisign certs sent in server chain (which every modern browser swaps for the sha1WithRsaEncryption version). There's at least tens of thousands such sites. I'm guessing this will leave many people confused when setting up TLSA for their sites and use one of those. Is there some figure giving the amount of known multi-path certs or hosts? (haven't seen one). I'll compute one from recently data in a bit. I guess giving both pub_key_info and the hash would be ok (though that means many records because of many hashes). Wouldn't just bare public key info suffice (sorry I'm tired so there's probably something I'm missing). Ondrej Mikle From warren@kumari.net Sat Nov 19 09:50: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 569F221F8569 for ; Sat, 19 Nov 2011 09:50:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.838 X-Spam-Level: X-Spam-Status: No, score=-105.838 tagged_above=-999 required=5 tests=[AWL=0.761, 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 lzRberQj9H2x for ; Sat, 19 Nov 2011 09:50:30 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id C496921F8564 for ; Sat, 19 Nov 2011 09:50:30 -0800 (PST) Received: from [10.242.59.201] (me20f36d0.tmodns.net [208.54.15.226]) by vimes.kumari.net (Postfix) with ESMTPSA id BFA371B402B3 for ; Sat, 19 Nov 2011 12:50:29 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1084) From: Warren Kumari In-Reply-To: Date: Sat, 19 Nov 2011 23:59:44 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EC2E8CA.1060009@ogud.com> <944D9413-A209-438F-9B6D-17C82A205C75@kirei.se> <162A261A-0872-4ADE-BE87-9F906E93CBED@vpnc.org> <4EC45DAB.9050607@ogud.com> <4FC32BEF-E1F5-45D5-9092-D3CE9EB739D0@vpnc.org> To: IETF DANE WG list X-Mailer: Apple Mail (2.1084) Subject: Re: [dane] Scope of the protocol document or plea for progress X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 19 Nov 2011 17:50:31 -0000 [ I'm writing this on the flight from NRT-> SFO and so am not fully = caught up on the thread (and also sleep deprived), so apologies if = things have already progressed / been settled=85 ] Our AD mentioned that he had some discussions with IESG folk and they = (strongly) expressed the view that if we don't have DNSSEC as a MUST, we = are outside our charter (which seems to be fairly clearly true, unless = one is willing to perform very create interpretation of the charter = text=85) So far I am seeing strong consensus for: If the outcome of the DNSSEC validation is "insecure" or = "indeterminate", proceed as if the TLSA record doesn't exist. There were some discussions on having DNSSEC as a MUST and then = specifying behavior other than "revert to the same behavior as is there = was no TLSA record" on "insecure" or "indeterminate". So far I haven't = seen much consensus for this, and to me it also feels like we are = violating the spirit of requiring DNSSEC.=20 While I personally think that there is lots of utility in allowing for = the restrictive use without DNSSEC, it is A: outside out charter and B: = the WG has been clear that this doesn't belong in the protocol doc / = doesn't want to discuss it now[0] So, unless I hear lots of strong objections (or there has been = substantive discussions while I've been in the air), it looks like we = have consensus and can move on... W [0]: After we are done with protocol, if the WG is interested and want = to, we can discuss rechartering and including this=85 or not=85 On Nov 17, 2011, at 10:23 AM, Yoav Nir wrote: >=20 > On Nov 17, 2011, at 10:14 AM, Paul Hoffman wrote: >=20 >> On Nov 17, 2011, at 9:49 AM, Yoav Nir wrote: >>=20 >>> I agree with Martin and Zack. A signature that doesn't validate = (whether "insecure" or "indeterminate") is like no signature at all, and = should be treated the same. >>=20 >> Define "the same": you can use the data you got if you want, or act = as if you didn't the data. Extra points for saying if it is true for all = three types. >=20 > Revert to the behavior the client would have if there had been no TLSA = record at all. Yes, do it for all types. >=20 >>=20 >>> Just require DNSSEC. >>=20 >>=20 >> OK, but what does that mean if DNSSEC is required and the data comes = as "indeterminate"? >=20 > Ignore the TLSA record. Client falls back to the same behavior it = would have if no TLSA record had ever been received. >=20 > And that probably means revert to PKIX. And yes, in case #2 that means = either fail association, or the way browsers do it today - with a big = red warning screen. >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 From ynir@checkpoint.com Sat Nov 19 09:54: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 5788921F86DD for ; Sat, 19 Nov 2011 09:54:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.429 X-Spam-Level: X-Spam-Status: No, score=-10.429 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8EayZ3c3EGZA for ; Sat, 19 Nov 2011 09:54:06 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 436CB21F86A6 for ; Sat, 19 Nov 2011 09:54:06 -0800 (PST) X-CheckPoint: {4EC7ECCB-0-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id pAJHs4TA016469; Sat, 19 Nov 2011 19:54:04 +0200 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sat, 19 Nov 2011 19:54:04 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Sat, 19 Nov 2011 19:54:03 +0200 From: Yoav Nir To: Ondrej Mikle Date: Sat, 19 Nov 2011 19:54:02 +0200 Thread-Topic: [dane] Scope of the protocol document or plea for progress Thread-Index: Acym5Dmz6AaVMwBwRSyNYvwXzlpDHg== Message-ID: <68230D53-8051-4490-ABEF-C417537E1EF6@checkpoint.com> References: <201111181736.pAIHaQIQ013832@fs4113.wdf.sap.corp> <4EC7DB81.1080502@nic.cz> In-Reply-To: <4EC7DB81.1080502@nic.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: "dane@ietf.org" Subject: Re: [dane] Scope of the protocol document or plea for progress X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 19 Nov 2011 17:54:07 -0000 On Nov 19, 2011, at 5:38 PM, Ondrej Mikle wrote: > On 11/18/11 18:36, Martin Rex wrote: >> Identifying PKIX "intermediate CA" certs by certificate or certificate >> hash (instead of subject public key info) is going to interfere badly >> with certificate renewal (and cross-certification). >>=20 >> The only CAs cert where certificate/certificate-hash can be ensured >> by the server admin to be in sync with the information published in DNS= =20 >> are either permanent trust anchors that are not renewed or cross-certifi= ed, >> or those CA certs that the server sends within the forward certification >> path of the server Certificate handshake message. >>=20 >> A number of TLS implementation appears to have the bad habit to >> perform pretty unpredictable certificate path discovery that >> includes a local pool of cached CA certs previously obtained >> from other sources and some might extremely unreasonable things such >> as AIA chasing, and those certs might get used _instead_ of those >> sent by the server for the PKIX certificate path validation, >> with the result that the DANE record for a CA cert/cert-hash >> may not match the CA cert that the client ended up with after >> PKIX path discovery voodoo. Distribution of renewed intermediate >> CA certs and subsitution with cross-CA certs will effectively >> be random/chaotic throughout the installed base. The only thing >> that can only change synchronous with the update of the >> server's certificate, is the public key that was used for signing >> the server's certificate. >=20 > Thanks for bringing this up again. Due to TLS client caching there's arou= nd > 97000 "transvalid" certs that validate because of cached cert. Do you hav= e a > (partial) list of TLS implementions/clients that do the caching? (browser= s or > their TLS libraries mostly do this) TLS proxies also do this, because they need to perform a lot of handshakes = with the same servers. Amazing how much of SSL traffic goes to gmail, and t= o a few popular banking sites. > This "transvalidity feature/bug" happens mostly due to fact that the site > operators have no idea about the caching behavior - they see it works in = their > browsers, but don't check a clean browser profile installation (I wonder = what > good the caching should exactly do, except for making badly-configured se= rvers > work). >=20 > AIA chasing? Out of curiosity, which TLS implementation does that? Lots of browsers and TLS proxies, because there is a non-trivial group of s= ites (if I was at work I could find a list) that send only the EE certifica= te, browsers and proxies need to check. > Cross-certs and resigned certs: the amount of sites experiencing the swap= ping by > browser is quite vast. Most common are probably md2WithRsaEncryption Veri= sign > certs sent in server chain (which every modern browser swaps for the > sha1WithRsaEncryption version). There's at least tens of thousands such s= ites. > I'm guessing this will leave many people confused when setting up TLSA fo= r their > sites and use one of those. >=20 > Is there some figure giving the amount of known multi-path certs or hosts= ? > (haven't seen one). I'll compute one from recently data in a bit. >=20 > I guess giving both pub_key_info and the hash would be ok (though that me= ans > many records because of many hashes). Wouldn't just bare public key info = suffice > (sorry I'm tired so there's probably something I'm missing). From warren@kumari.net Sat Nov 19 09:58: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 9AF7C21F8541 for ; Sat, 19 Nov 2011 09:58:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.838 X-Spam-Level: X-Spam-Status: No, score=-105.838 tagged_above=-999 required=5 tests=[AWL=0.761, 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 Z6IolvCTEcyk for ; Sat, 19 Nov 2011 09:58:19 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 66C4421F84CE for ; Sat, 19 Nov 2011 09:58:19 -0800 (PST) Received: from [10.242.59.201] (me20f36d0.tmodns.net [208.54.15.226]) by vimes.kumari.net (Postfix) with ESMTPSA id 073781B402B3 for ; Sat, 19 Nov 2011 12:58:07 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1084) From: Warren Kumari In-Reply-To: Date: Sat, 19 Nov 2011 23:59:44 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EC2E8CA.1060009@ogud.com> <944D9413-A209-438F-9B6D-17C82A205C75@kirei.se> <162A261A-0872-4ADE-BE87-9F906E93CBED@vpnc.org> <4EC45DAB.9050607@ogud.com> <4FC32BEF-E1F5-45D5-9092-D3CE9EB739D0@vpnc.org> To: IETF DANE WG list X-Mailer: Apple Mail (2.1084) Subject: Re: [dane] Scope of the protocol document or plea for progress X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 19 Nov 2011 17:58:19 -0000 [ I'm writing this on the flight from NRT-> SFO and so am not fully = caught up on the thread (and also sleep deprived), so apologies if = things have already progressed / been settled=85 ] Our AD mentioned that he had some discussions with IESG folk and they = (strongly) expressed the view that if we don't have DNSSEC as a MUST, we = are outside our charter (which seems to be fairly clearly true, unless = one is willing to perform very create interpretation of the charter = text=85) So far I am seeing strong consensus for: If the outcome of the DNSSEC validation is "insecure" or = "indeterminate", proceed as if the TLSA record doesn't exist. There were some discussions on having DNSSEC as a MUST and then = specifying behavior other than "revert to the same behavior as is there = was no TLSA record" on "insecure" or "indeterminate". So far I haven't = seen much consensus for this, and to me it also feels like we are = violating the spirit of requiring DNSSEC.=20 While I personally think that there is lots of utility in allowing for = the restrictive use without DNSSEC, it is A: outside out charter and B: = the WG has been clear that this doesn't belong in the protocol doc / = doesn't want to discuss it now[0] So, unless I hear lots of strong objections (or there has been = substantive discussions while I've been in the air), it looks like we = have consensus and can move on... W [0]: After we are done with protocol, if the WG is interested and want = to, we can discuss rechartering and including this=85 or not=85 On Nov 17, 2011, at 10:23 AM, Yoav Nir wrote: >=20 > On Nov 17, 2011, at 10:14 AM, Paul Hoffman wrote: >=20 >> On Nov 17, 2011, at 9:49 AM, Yoav Nir wrote: >>=20 >>> I agree with Martin and Zack. A signature that doesn't validate = (whether "insecure" or "indeterminate") is like no signature at all, and = should be treated the same. >>=20 >> Define "the same": you can use the data you got if you want, or act = as if you didn't the data. Extra points for saying if it is true for all = three types. >=20 > Revert to the behavior the client would have if there had been no TLSA = record at all. Yes, do it for all types. >=20 >>=20 >>> Just require DNSSEC. >>=20 >>=20 >> OK, but what does that mean if DNSSEC is required and the data comes = as "indeterminate"? >=20 > Ignore the TLSA record. Client falls back to the same behavior it = would have if no TLSA record had ever been received. >=20 > And that probably means revert to PKIX. And yes, in case #2 that means = either fail association, or the way browsers do it today - with a big = red warning screen. >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 From jakob@kirei.se Sat Nov 19 10:11:03 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE5D21F847B for ; Sat, 19 Nov 2011 10:11:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WF9OKmQqDaU for ; Sat, 19 Nov 2011 10:10:55 -0800 (PST) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id 1573F21F8770 for ; Sat, 19 Nov 2011 10:10:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=p9PxMcA7lwC3nzn1hx4RZmW5Y19GuqRpwjc9UJnrmBQ=; b=Er8Tqua6HlAq/XyKxIJLPbquDHwmGz4sZGeck04C6+06DKyDNrz2KoN+Yui5vAS8a6UsX5t8W0kKo 4XtDhZ0Ysh5TMdGG35ZAknidCThxXarKLUz9QGrCowR5g+avexiu8xFT26JJqnbmC3pl+JZDdql2kG Ube0eg5xLtvueAMI= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Sat, 19 Nov 2011 19:10:51 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: <92AA2445-000C-44CF-8CA5-9796528EA946@checkpoint.com> Date: Sat, 19 Nov 2011 19:10:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0536F82C-346C-4ABE-81E6-3B008219DBD9@kirei.se> References: <45EA694E-096C-41A1-B60E-BF7B3832FE2A@vpnc.org> <4EC70173.9090106@sv.cmu.edu> <247CAE36-68FB-4048-B07C-9B4C0903434D@vpnc.org> <92AA2445-000C-44CF-8CA5-9796528EA946@checkpoint.com> To: Yoav Nir X-Mailer: Apple Mail (2.1251.1) Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] Aiming towards some specific wording X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 19 Nov 2011 18:11:03 -0000 On 19 nov 2011, at 11:58, Yoav Nir wrote: > I am not in that camp, but since we are requiring TLSA to be secure, = but not requiring this (for now) for A records, it makes no sense for an = attacker to forge a signature on the A record: you will accept it = unsigned anyway. One should remember that most (if not, all) DNSSEC resolver will never = return bogus answers. If one tries to forge or strip a signature from a = record that is supposed to be signed, resolving will fail and nothing is = returned. jakob From ynir@checkpoint.com Sat Nov 19 10:27: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 A88AD21F88B7 for ; Sat, 19 Nov 2011 10:27:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.431 X-Spam-Level: X-Spam-Status: No, score=-10.431 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BeYVnxvCwJ7w for ; Sat, 19 Nov 2011 10:27:25 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id B5B8C21F86AA for ; Sat, 19 Nov 2011 10:27:24 -0800 (PST) X-CheckPoint: {4EC7F499-0-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id pAJIRMRN020170; Sat, 19 Nov 2011 20:27:22 +0200 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sat, 19 Nov 2011 20:27:22 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Sat, 19 Nov 2011 20:27:22 +0200 From: Yoav Nir To: Jakob Schlyter Date: Sat, 19 Nov 2011 20:27:21 +0200 Thread-Topic: [dane] Aiming towards some specific wording Thread-Index: Acym6OC3NBKqcUyGT+yOuew82BcUUw== Message-ID: References: <45EA694E-096C-41A1-B60E-BF7B3832FE2A@vpnc.org> <4EC70173.9090106@sv.cmu.edu> <247CAE36-68FB-4048-B07C-9B4C0903434D@vpnc.org> <92AA2445-000C-44CF-8CA5-9796528EA946@checkpoint.com> <0536F82C-346C-4ABE-81E6-3B008219DBD9@kirei.se> In-Reply-To: <0536F82C-346C-4ABE-81E6-3B008219DBD9@kirei.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] Aiming towards some specific wording X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 19 Nov 2011 18:27:25 -0000 On Nov 19, 2011, at 7:10 PM, Jakob Schlyter wrote: > On 19 nov 2011, at 11:58, Yoav Nir wrote: >=20 >> I am not in that camp, but since we are requiring TLSA to be secure, but= not requiring this (for now) for A records, it makes no sense for an attac= ker to forge a signature on the A record: you will accept it unsigned anywa= y. >=20 > One should remember that most (if not, all) DNSSEC resolver will never re= turn bogus answers. If one tries to forge or strip a signature from a recor= d that is supposed to be signed, resolving will fail and nothing is returne= d. All the more reason to +1 what Warren said. Validated DNSSEC or if didn't happen.= From zack.weinberg@gmail.com Sat Nov 19 10:38: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 7015921F851A for ; Sat, 19 Nov 2011 10:38:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wnvXKEw-1Q0A for ; Sat, 19 Nov 2011 10:38:59 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id DC29D21F8515 for ; Sat, 19 Nov 2011 10:38:58 -0800 (PST) Received: by iaeo4 with SMTP id o4so6338388iae.31 for ; Sat, 19 Nov 2011 10:38:58 -0800 (PST) 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=5teLgXQooc9x6KswplRc7/4FYPcGqYHLpUiaQ8xRId4=; b=Z38TuxOS9NMlo7Blia/727rCQ62VJtVT1E/6Tim+l5ThSnRLJq7mX3j2Nu/wtsPb1n 3MLlFoH288usoAUeI6HbUAFMx9dajJLuU7/Z1aFdYMPrtfrPGQj7atPOTdSaaWniOOW7 oyDO5Wpzj8FiOnAmKiuIINxn0FjH66oXoNUbM= Received: by 10.50.188.225 with SMTP id gd1mr7882931igc.50.1321727938398; Sat, 19 Nov 2011 10:38:58 -0800 (PST) Received: from ardsley.local (99-113-32-219.lightspeed.sntcca.sbcglobal.net. [99.113.32.219]) by mx.google.com with ESMTPS id el2sm20146684ibb.10.2011.11.19.10.38.57 (version=SSLv3 cipher=OTHER); Sat, 19 Nov 2011 10:38:57 -0800 (PST) Sender: Zack Weinberg Message-ID: <4EC7F7C0.1080107@sv.cmu.edu> Date: Sat, 19 Nov 2011 10:38:56 -0800 From: Zack Weinberg User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: dane@ietf.org References: <45EA694E-096C-41A1-B60E-BF7B3832FE2A@vpnc.org> <4EC70173.9090106@sv.cmu.edu> <247CAE36-68FB-4048-B07C-9B4C0903434D@vpnc.org> <92AA2445-000C-44CF-8CA5-9796528EA946@checkpoint.com> <0536F82C-346C-4ABE-81E6-3B008219DBD9@kirei.se> In-Reply-To: <0536F82C-346C-4ABE-81E6-3B008219DBD9@kirei.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dane] Aiming towards some specific wording X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 19 Nov 2011 18:38:59 -0000 On 2011-11-19 10:10 AM, Jakob Schlyter wrote: > One should remember that most (if not, all) DNSSEC resolver will > never return bogus answers. If one tries to forge or strip a > signature from a record that is supposed to be signed, resolving will > fail and nothing is returned. Because of the attack I described in my message to Paul just now, I think it is not possible to securely process TLSA information if you cannot distinguish validation state "bogus" from state "indeterminate" or from a server failure. In other words, such resolvers are inadequate to the needs of a DANE client. (I have long thought that it would be necessary for a DANE client to do its own DNSSEC processing; this does not seem like a major problem to me.) zw From marka@isc.org Sat Nov 19 16:04: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 37D7421F84DB for ; Sat, 19 Nov 2011 16:04:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, 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 AlA7bK0Xew24 for ; Sat, 19 Nov 2011 16:04:36 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id B145721F84DA for ; Sat, 19 Nov 2011 16:04:36 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 74511C9450; Sun, 20 Nov 2011 00:04:21 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 35D21216C6A; Sun, 20 Nov 2011 00:04:21 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 2E08717C97DA; Sun, 20 Nov 2011 11:04:19 +1100 (EST) To: Jakob Schlyter From: Mark Andrews References: <45EA694E-096C-41A1-B60E-BF7B3832FE2A@vpnc.org> <4EC70173.9090106@sv.cmu.edu> <247CAE36-68FB-4048-B07C-9B4C0903434D@vpnc.org> <92AA2445-000C-44CF-8CA5-9796528EA946@checkpoint.com> <0536F82C-346C-4ABE-81E6-3B008219DBD9@kirei.se> In-reply-to: Your message of "Sat, 19 Nov 2011 19:10:50 BST." <0536F82C-346C-4ABE-81E6-3B008219DBD9@kirei.se> Date: Sun, 20 Nov 2011 11:04:19 +1100 Message-Id: <20111120000419.2E08717C97DA@drugs.dv.isc.org> Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] Aiming towards some specific wording X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 20 Nov 2011 00:04:37 -0000 In message <0536F82C-346C-4ABE-81E6-3B008219DBD9@kirei.se>, Jakob Schlyter writ es: > On 19 nov 2011, at 11:58, Yoav Nir wrote: > > > I am not in that camp, but since we are requiring TLSA to be secure, but no > t requiring this (for now) for A records, it makes no sense for an attacker t > o forge a signature on the A record: you will accept it unsigned anyway. > > One should remember that most (if not, all) DNSSEC resolver will never return > bogus answers. If one tries to forge or strip a signature from a record that > is supposed to be signed, resolving will fail and nothing is returned. > > jakob But once the application starts doing DNSSEC for itself it will be asking with CD=1 at some point. > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From matt@mattmccutchen.net Sat Nov 19 21:49: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 E227C21F84A4 for ; Sat, 19 Nov 2011 21:49:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTMA3BstKPZX for ; Sat, 19 Nov 2011 21:49:10 -0800 (PST) Received: from homiemail-a7.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD9721F84A2 for ; Sat, 19 Nov 2011 21:49:10 -0800 (PST) Received: from homiemail-a7.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a7.g.dreamhost.com (Postfix) with ESMTP id DD48725C063; Sat, 19 Nov 2011 21:49:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=message-id :subject:from:to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:mime-version; q=dns; s= mattmccutchen.net; b=YJneBrb50EBmBpkq2O8eBqqUce2TAaT8crLQbDb6TEc fJJxDjMkMPW6tMO02dwVNQa5qJ4v3QQ8286SRVe3tOfWAOZr5J/QZGEPqksJzA7q Bo1r6N1h6Hh4GuVCXk4YcR0poPWSsL22aCERJB3bTRQUzkAqIZDK2GpZGvbLUxBA = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= message-id:subject:from:to:cc:date:in-reply-to:references :content-type:content-transfer-encoding:mime-version; s= mattmccutchen.net; bh=UaBfgFxtuy9CFb1kpjQIp+S3rWE=; b=paEEIpCmOP 7WOy+Zsw0+qS0yVZLmnYf/o/Tdzr6uxnjCSVY5MasgQMnrSYCfTBOQvC6q+/lSAV pAarUtyMW7VFajHip+WCNErHsH4lcC9d2cToBHeiWxb3g9c3rkzq74QDSJLtk7Lc OJGihLdR0A8FM85L00ijfdNupPPpZpAq8= 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 A99E825C062; Sat, 19 Nov 2011 21:49:08 -0800 (PST) Message-ID: <1321768148.8318.12.camel@mattlaptop2.local> From: Matt McCutchen To: Paul Hoffman Date: Sat, 19 Nov 2011 21:49:08 -0800 In-Reply-To: <247CAE36-68FB-4048-B07C-9B4C0903434D@vpnc.org> References: <45EA694E-096C-41A1-B60E-BF7B3832FE2A@vpnc.org> <4EC70173.9090106@sv.cmu.edu> <247CAE36-68FB-4048-B07C-9B4C0903434D@vpnc.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Cc: IETF DANE WG list Subject: Re: [dane] Aiming towards some specific wording X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 20 Nov 2011 05:49:11 -0000 On Sat, 2011-11-19 at 18:46 +0800, Paul Hoffman wrote: > On Nov 19, 2011, at 9:08 AM, Zack Weinberg wrote: > > > Now, my understanding of the debate is that everyone agrees that the > "bogus" DNSSEC state needs to cause a TLS connection abort, > > That was not my understanding from the earlier thread, but you could > be right. Why would [a bogus state on] a DNS lookup for the TLSA > record cause a TLS connection abort? Because that's the only way for restrictive TLSA data to be effective. If the client proceeds without using DANE in this case, then an MITM attacker who has fraudulently obtained a PKIX-acceptable certificate for the target server name can trivially deceive the client by replacing the TLSA response with a bogus response. -- Matt From jakob@kirei.se Sun Nov 20 00:40: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 0925E21F850E for ; Sun, 20 Nov 2011 00:40:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, MIME_QP_LONG_LINE=1.396, 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 KHUSUp1mE8bI for ; Sun, 20 Nov 2011 00:40:35 -0800 (PST) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id CB2C221F8509 for ; Sun, 20 Nov 2011 00:40:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:references:in-reply-to:mime-version:content-transfer-encoding: content-type:message-id:cc:x-mailer:from:subject:date:to; bh=jmTEgGKcAkkavgGW5ODwNAUotned/u7pzKqmged5XXA=; b=O4W0oZy6qFJgJmiQ+pdYkapJp4Hu7VKsANkqAN27/V+wfFT9DhtDjmKOXclyOULSFp/b/qpMpfCE8 VFSslCzHpzHfOVmfj1H2ijueZxySiawHqMzwU121vNV+21Uw9UPZYVn31Moqimtcvo39CmvqNnYTxd kwsqdlmkzDHGjnmk= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Sun, 20 Nov 2011 09:40:31 +0100 (CET) References: <45EA694E-096C-41A1-B60E-BF7B3832FE2A@vpnc.org> <4EC70173.9090106@sv.cmu.edu> <247CAE36-68FB-4048-B07C-9B4C0903434D@vpnc.org> <1321768148.8318.12.camel@mattlaptop2.local> In-Reply-To: <1321768148.8318.12.camel@mattlaptop2.local> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <16877EE7-A775-49C7-BB4F-BB84FCF0F430@kirei.se> X-Mailer: iPad Mail (9A405) From: Jakob Schlyter Date: Sun, 20 Nov 2011 09:40:20 +0100 To: Matt McCutchen Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] Aiming towards some specific wording X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 20 Nov 2011 08:40:36 -0000 20 nov 2011 kl. 06:49 skrev Matt McCutchen : > Because that's the only way for restrictive TLSA data to be effective. > If the client proceeds without using DANE in this case, then an MITM > attacker who has fraudulently obtained a PKIX-acceptable certificate for > the target server name can trivially deceive the client by replacing the > TLSA response with a bogus response. Spot on - bogus must result in connection termination, while insecure and in= determinate may safely be ignored.=20 Jakob From warren@kumari.net Sun Nov 20 06:17: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 8069A21F8A6F for ; Sun, 20 Nov 2011 06:17:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6e-nEGmPZ0c for ; Sun, 20 Nov 2011 06:17:12 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 05DC521F8A4B for ; Sun, 20 Nov 2011 06:17:11 -0800 (PST) Received: from [172.26.41.144] (unknown [72.14.228.1]) by vimes.kumari.net (Postfix) with ESMTPSA id 33CF91B404CC; Sun, 20 Nov 2011 09:17:11 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <16877EE7-A775-49C7-BB4F-BB84FCF0F430@kirei.se> Date: Sun, 20 Nov 2011 09:17:10 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <45EA694E-096C-41A1-B60E-BF7B3832FE2A@vpnc.org> <4EC70173.9090106@sv.cmu.edu> <247CAE36-68FB-4048-B07C-9B4C0903434D@vpnc.org> <1321768148.8318.12.camel@mattlaptop2.local> <16877EE7-A775-49C7-BB4F-BB84FCF0F430@kirei.se> To: Jakob Schlyter X-Mailer: Apple Mail (2.1084) Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] Aiming towards some specific wording X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 20 Nov 2011 14:17:12 -0000 On Nov 20, 2011, at 3:40 AM, Jakob Schlyter wrote: > 20 nov 2011 kl. 06:49 skrev Matt McCutchen : >=20 >> Because that's the only way for restrictive TLSA data to be = effective. >> If the client proceeds without using DANE in this case, then an MITM >> attacker who has fraudulently obtained a PKIX-acceptable certificate = for >> the target server name can trivially deceive the client by replacing = the >> TLSA response with a bogus response. >=20 > Spot on - bogus must result in connection termination, while insecure = and indeterminate may safely be ignored.=20 +1 >=20 > Jakob >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 From zack.weinberg@gmail.com Sun Nov 20 08: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 ED48421F8A7E for ; Sun, 20 Nov 2011 08:22:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.877 X-Spam-Level: X-Spam-Status: No, score=-2.877 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 NlbRtQvi8qyM for ; Sun, 20 Nov 2011 08:22:14 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4C46D21F8A67 for ; Sun, 20 Nov 2011 08:22:14 -0800 (PST) Received: by yenm7 with SMTP id m7so1596692yen.31 for ; Sun, 20 Nov 2011 08:22:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=J4g5iPdZlnof6x2aMJZSLYgID60KU1ugu0DeSYj7n/E=; b=xdv8hpyt6+eoLf/k4aKbVNIIb8zwUXDHrHhzFoN1qyeNC06lNOmsfw8tldH7ZiU9qt IBZKVSrUqInOCh8MGPsftyXcwxnEcfUkSTff8+2+S/JPQy20JXPPaRY+PM6v+G8r0z4W kEjhVr78OAH1bAMM/KqR+8rP3m/v64WJnaaXY= MIME-Version: 1.0 Received: by 10.182.50.65 with SMTP id a1mr2319081obo.17.1321806131705; Sun, 20 Nov 2011 08:22:11 -0800 (PST) Sender: zack.weinberg@gmail.com Received: by 10.182.88.103 with HTTP; Sun, 20 Nov 2011 08:22:11 -0800 (PST) In-Reply-To: <4EC7F701.4080006@panix.com> References: <45EA694E-096C-41A1-B60E-BF7B3832FE2A@vpnc.org> <4EC70173.9090106@sv.cmu.edu> <247CAE36-68FB-4048-B07C-9B4C0903434D@vpnc.org> <4EC7F701.4080006@panix.com> Date: Sun, 20 Nov 2011 08:22:11 -0800 X-Google-Sender-Auth: q0tupZtkMKy3bgFjA20jJUt9KAE 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: Aiming towards some specific wording X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 20 Nov 2011 16:22:15 -0000 (I sent this from the wrong address so it may not have gotten through. Sorry if you get two copies.) On 2011-11-19 2:46 AM, Paul Hoffman wrote: > > On Nov 19, 2011, at 9:08 AM, Zack Weinberg wrote: > >> Now, my understanding of the debate is that everyone agrees that >> the "bogus" DNSSEC state needs to cause a TLS connection abort, > > That was not my understanding from the earlier thread, but you could > be right. Why would a DNS lookup for the TLSA record cause a TLS > connection abort? If you get a "bogus" DNSSEC validation you *know* you are under attack. =C2=A0It seems absurd to me to proceed with a connection when you know that= . Here is an attack that can only be thwarted by this rule: Suppose the standard man-in-the-middle attacker on TLS, in possession of an illegitimate certificate for the site being MITMed, that would nonetheless be accepted by the client in the absence of DANE information. =C2=A0Suppose further that this attacker is able to block enti= re DNS queries but not tamper with their contents. =C2=A0They allow the A reco= rd query to go through and come back unmolested (they don't need to change the apparent address of the server to intercept traffic) but they block the TLSA query. =C2=A0This absence of response is DNSSEC-"bogus", because y= ou didn't get an NSEC(3) to prove that there is no such record. =C2=A0If you abort the connection, the attacker loses. =C2=A0If you fall back to non-DAN= E behavior, the attacker wins. (If the attacker can rewrite DNS responses, they can downgrade you to an absence of DNSSEC all the way to the root, which may or may not be distinguishable from an innocuous availability failure -- I'd *like* to be able to say fail connections in that case, now that the root is signed, but it seems unlikely to fly..) > First, it is unrelated to TLS it self if the data from TLSA is not > used. I do not understand this sentence. > Second, there may be other valid records returned, so aborting > instead of just throwing away the bad data will lead to lack of > secure connections when secure connections were possible. I cannot think of any scenario where this would be both true and distinguishable from the attack scenario above. =C2=A0Can you? > Third, that rule seem nonsensical in light of the fact that there is > no parallel rule for a bogus response on the A record lookup. Actually, I think there *should* be a parallel rule for a bogus response on the A(AAA) record lookup. =C2=A0It may not belong in DANE, but it seems like it belongs in a "how to make use of DNSSEC in a network client" best-practices document, at least. > There is no assumption that a connection > has been started. If you're processing TLSA records and it's *not* because you need to decide whether a TLS connection is properly authenticated, that seems out of scope for the document we're trying to write right now. > There is an assumption that there might be > additional TLSA records that can be used even if the bogus record is > unusable. Hm, I had not thought of this possibility. =C2=A0It seems like a silly thing for an attacker to do (any attacker who can inject a TLSA record can also remove all the legitimate ones, and why wouldn't they?) and I would argue that *any* bogosity coming back from DNSSEC is evidence that there is an attacker doing *something* and it is not safe to proceed. > I purposely elft out insecure because the DNS root is now signed, > but since this morning, I have thought of cases where one might get > "insecure" due to local policy. I will change "indeterminate" to > "indeterminate or insecure" everywhere. Ok. =C2=A0It is probably worth describing those scenarios in the security considerations section, and mentioning that localities whose policies do *not* interfere may want to treat "insecure" the same as "bogus". zw From peter@denic.de Sun Nov 20 08:36: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 0FFDB21F86EC for ; Sun, 20 Nov 2011 08:36:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eYf57+ek4aU1 for ; Sun, 20 Nov 2011 08:36:01 -0800 (PST) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::4]) by ietfa.amsl.com (Postfix) with ESMTP id 85B3721F854D for ; Sun, 20 Nov 2011 08:36:01 -0800 (PST) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1RSAN3-0000Pj-Vh; Sun, 20 Nov 2011 17:35:58 +0100 Received: from localhost by x27.adm.denic.de with local id 1RSAN3-00005H-Ru; Sun, 20 Nov 2011 17:35:57 +0100 Date: Sun, 20 Nov 2011 17:35:57 +0100 From: Peter Koch To: IETF DANE WG list Message-ID: <20111120163557.GX13798@x27.adm.denic.de> Mail-Followup-To: IETF DANE WG list References: <45EA694E-096C-41A1-B60E-BF7B3832FE2A@vpnc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45EA694E-096C-41A1-B60E-BF7B3832FE2A@vpnc.org> User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: Re: [dane] Aiming towards some specific wording X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 20 Nov 2011 16:36:02 -0000 On Sat, Nov 19, 2011 at 08:10:08AM +0800, Paul Hoffman wrote: > ========== PREAMBLE A START ========== > > Determining whether a TLS certificate association can be used depends > on the DNSSEC valiation state (as defined in [RFC4033]). > > o A TLS certificate association whose DNSSEC validation state is > secure can be used for TLS. I believe that s/TLS certificate association/TLSA RRSet/ would be more to the point and more precise protocol specification language. "can be used" remains ambiguous, though. -Peter From paul.hoffman@vpnc.org Sun Nov 20 12:27: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 EF59221F84B3 for ; Sun, 20 Nov 2011 12:27:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.878 X-Spam-Level: X-Spam-Status: No, score=-101.878 tagged_above=-999 required=5 tests=[AWL=-0.675, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 FMpp-6QbBj3t for ; Sun, 20 Nov 2011 12:27:53 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 701C521F844E for ; Sun, 20 Nov 2011 12:27:53 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id pAKKRo3p079386 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 20 Nov 2011 13:27:51 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 20 Nov 2011 12:27:50 -0800 Message-Id: <4AB082C8-24EE-4105-A50D-0990F42B097D@vpnc.org> To: IETF DANE WG list Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: [dane] Aiming towards some specific wording X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 20 Nov 2011 20:27:54 -0000 [[ New version, incorporating comments from this thread so far. Please = let me know if the specific wording of the proposals is OK, but not = whether you support them. ]] Greetings again. The recent threads are useful, but some people change = the topic mid-thread so determining what actual words people want in the = draft is difficult. As document co-author, I want to nail down the = words. To do that, the WG needs some choices, and that is the purpose of = this message. I have tried to cast each of the choices expressed in the = past few days in actual text that would appear in the document. THIS IS NOT A CALL FOR SUPPORT FOR ANY WORDING!!! This is a call to be = sure that all opinions are given for a LATER CALL. Sorry to use the ALL = CAPS there, but people here tend to vote quickly and then ask for = modifications later. I propose the following preamble wording to the "interesting" parts of = the wording: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D PREAMBLE A START =3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Determining whether a TLS certificate association can be used depends on the DNSSEC valiation state (as defined in [RFC4033]). o A TLS certificate association whose DNSSEC validation state is secure can be used for TLS. o A TLS certificate association whose DNSSEC validation state is bogus MUST cause TLS not to be started or, if the TLS negotiation is already in progress, to cause the connection to be aborted. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D PREAMBLE A END =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= One of the following, or some other choice, needs to be added to the = preamble. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONTINUATION 1 START =3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D o A TLS certificate association whose DNSSEC validation state is indeterminate or insecure cannot be used for TLS and must be marked as unusable. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONTINUATION 1 END =3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D ############# OR #################### =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONTINUATION 2 START =3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D o A TLS certificate association whose DNSSEC validation state is indeterminate or insecure and whose usage is 0 or 1 MAY be used for TLS if application marks it as usable. o A TLS certificate association whose DNSSEC validation state is indeterminate or insecure and whose usage is 2 MUST NOT be used for TLS and must be marked as unusable. o Future definitions of new certificate usages MUST include specification of whether or not DNSSEC validation is required for that usage. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONTINUATION 2 END =3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Again, PLEASE DO NOT SAY YET WHICH OF THESE YOU SUPPORT. Instead, if you = think the wording in Preamble A, Continuation 1, or Continuation 2 do = not exactly match what you would want in the spec, please propose a = different preamble or continuation text (not just "ideas"). That way, = when we later ask for what wording people want, all proposals will = already be on the table and we will not (again) have wording changes = appear mid-vote. Thanks in advance for your cooperation. --Paul Hoffman From paul.hoffman@vpnc.org Sun Nov 20 12:30: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 27A7C21F84B6 for ; Sun, 20 Nov 2011 12:30:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id InA57TWgVspr for ; Sun, 20 Nov 2011 12:30:00 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 65A7521F849B for ; Sun, 20 Nov 2011 12:30:00 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id pAKKTx8D079419 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 20 Nov 2011 13:29:59 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20111120163557.GX13798@x27.adm.denic.de> Date: Sun, 20 Nov 2011 12:29:59 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <0FF0603A-11CF-4A3B-BAAD-060FD24231C7@vpnc.org> References: <45EA694E-096C-41A1-B60E-BF7B3832FE2A@vpnc.org> <20111120163557.GX13798@x27.adm.denic.de> To: Peter Koch X-Mailer: Apple Mail (2.1251.1) Cc: IETF DANE WG list Subject: Re: [dane] Aiming towards some specific wording X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 20 Nov 2011 20:30:01 -0000 On Nov 20, 2011, at 8:35 AM, Peter Koch wrote: > On Sat, Nov 19, 2011 at 08:10:08AM +0800, Paul Hoffman wrote: >=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D PREAMBLE A START =3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D >>=20 >> Determining whether a TLS certificate association can be used depends >> on the DNSSEC valiation state (as defined in [RFC4033]). >>=20 >> o A TLS certificate association whose DNSSEC validation state is >> secure can be used for TLS. >=20 > I believe that s/TLS certificate association/TLSA RRSet/ would be > more to the point and more precise protocol specification language. The term "certificate association" is defined and used in this document. > "can be used" remains ambiguous, though. An implementation is not forced to use good DANE information even if it = comes validated. For example, there might be a local policy that says = "even if you get DANE information about somebigbank.com, ignore it and = use this hard-coded information instead". --Paul Hoffman From paul.hoffman@vpnc.org Sun Nov 20 12:31: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 478BA1F0C34 for ; Sun, 20 Nov 2011 12:31:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 iiFRwxyw91vG for ; Sun, 20 Nov 2011 12:31:58 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id C27A021F8ADC for ; Sun, 20 Nov 2011 12:31:58 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id pAKKVvRo079461 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 20 Nov 2011 13:31:58 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Paul Hoffman In-Reply-To: <20111120000419.2E08717C97DA@drugs.dv.isc.org> Date: Sun, 20 Nov 2011 12:31:57 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6B6BCDE8-365B-4040-9082-6F702E60573B@vpnc.org> References: <45EA694E-096C-41A1-B60E-BF7B3832FE2A@vpnc.org> <4EC70173.9090106@sv.cmu.edu> <247CAE36-68FB-4048-B07C-9B4C0903434D@vpnc.org> <92AA2445-000C-44CF-8CA5-9796528EA946@checkpoint.com> <0536F82C-346C-4ABE-81E6-3B008219DBD9@kirei.se> <20111120000419.2E08717C97DA@drugs.dv.isc.org> To: IETF DANE WG list X-Mailer: Apple Mail (2.1251.1) Subject: Re: [dane] Aiming towards some specific wording X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 20 Nov 2011 20:31:59 -0000 On Nov 19, 2011, at 4:04 PM, Mark Andrews wrote: > But once the application starts doing DNSSEC for itself it will be = asking > with CD=3D1 at some point. The DANE spec does not assume that the application does DNSSEC itself, = so we should cover both that case and the case of the application asking = a trusted validator for information. --Paul Hoffman From danny@tcb.net Sun Nov 20 14:21: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 ED62421F8726 for ; Sun, 20 Nov 2011 14:21:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.462 X-Spam-Level: X-Spam-Status: No, score=-102.462 tagged_above=-999 required=5 tests=[AWL=0.137, 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 aacvWhM4Lc+a for ; Sun, 20 Nov 2011 14:21:34 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7F721F86FF for ; Sun, 20 Nov 2011 14:21:34 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id 62E7F268063; Sun, 20 Nov 2011 15:21:33 -0700 (MST) Received: from dul1dmcphers-m1.home (pool-98-118-240-226.clppva.fios.verizon.net [98.118.240.226]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for dane@ietf.org; Sun, 20 Nov 2011 15:21:33 -0700 (MST) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=98.118.240.226; client-port=57446; syn-fingerprint=65535:48:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Danny McPherson In-Reply-To: Date: Sun, 20 Nov 2011 17:21:10 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0286EA84-7538-4676-96D4-3F3C1D12C795@tcb.net> References: <45EA694E-096C-41A1-B60E-BF7B3832FE2A@vpnc.org> <4EC70173.9090106@sv.cmu.edu> <247CAE36-68FB-4048-B07C-9B4C0903434D@vpnc.org> <1321768148.8318.12.camel@mattlaptop2.local> <16877EE7-A775-49C7-BB4F-BB84FCF0F430@kirei.se> To: IETF DANE WG list X-Mailer: Apple Mail (2.1084) Subject: Re: [dane] Aiming towards some specific wording X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 20 Nov 2011 22:21:35 -0000 On Nov 20, 2011, at 9:17 AM, Warren Kumari wrote: >>=20 >> Spot on - bogus must result in connection termination, while insecure = and indeterminate may safely be ignored.=20 I have some concerns about this.. =20 We'e seen instances with _already deployed DNSSEC root and TLD=20 zones where signatures could not be updated because nodes were=20 partitioned from the systems which update them -- this can happen = because of intentional or benign reasons. If there were RPs that were = performing=20 validation expired data would result in validation state "bogus". =20 IMO, this begs the question -- if we're even remotely considering = supporting DANE-esque functions for any state other than valid (Secure), to include = =20 non-DNSSEC support, then why not address this issue as well, rather than=20= letting practical realities potentially result in non-determinsitic = behaviors? -danny= From paul.hoffman@vpnc.org Sun Nov 20 14:36: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 7B74C21F8A71 for ; Sun, 20 Nov 2011 14:36:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[AWL=-0.266, BAYES_00=-2.599, J_CHICKENPOX_21=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 4oP24PjL6Eqb for ; Sun, 20 Nov 2011 14:36:30 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5AE21F85F1 for ; Sun, 20 Nov 2011 14:36:29 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id pAKMaTaT082164 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 20 Nov 2011 15:36:29 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <0286EA84-7538-4676-96D4-3F3C1D12C795@tcb.net> Date: Sun, 20 Nov 2011 14:36:28 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <45EA694E-096C-41A1-B60E-BF7B3832FE2A@vpnc.org> <4EC70173.9090106@sv.cmu.edu> <247CAE36-68FB-4048-B07C-9B4C0903434D@vpnc.org> <1321768148.8318.12.camel@mattlaptop2.local> <16877EE7-A775-49C7-BB4F-BB84FCF0F430@kirei.se> <0286EA84-7538-4676-96D4-3F3C1D12C795@tcb.net> To: Danny McPherson X-Mailer: Apple Mail (2.1251.1) Cc: IETF DANE WG list Subject: Re: [dane] Aiming towards some specific wording X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 20 Nov 2011 22:36:30 -0000 On Nov 20, 2011, at 2:21 PM, Danny McPherson wrote: > On Nov 20, 2011, at 9:17 AM, Warren Kumari wrote: >=20 >>>=20 >>> Spot on - bogus must result in connection termination, while = insecure and indeterminate may safely be ignored.=20 >=20 > I have some concerns about this.. =20 >=20 > We'e seen instances with _already deployed DNSSEC root and TLD=20 > zones where signatures could not be updated because nodes were=20 > partitioned from the systems which update them -- this can happen = because > of intentional or benign reasons. If there were RPs that were = performing=20 > validation expired data would result in validation state "bogus". =20 In that case ("bogus means poorly maintained zone"), the A/AAAA record = would come back bogus. An application that is rejecting bogus responses = would already stop on that error because it would have no place to go. > IMO, this begs the question -- if we're even remotely considering = supporting > DANE-esque functions for any state other than valid (Secure), to = include =20 > non-DNSSEC support, then why not address this issue as well, rather = than=20 > letting practical realities potentially result in non-determinsitic = behaviors? If you actually believe that an application that requests both A/AAAA = and TLSA records from a poorly maintained zone might get the first = marked valid but the second marked bogus, I will add two options for the = wording of the preamble, and the WG can decide between the two of them. = However, if you don't think this is at all likely, I think the new = wording ("bogus leads to no connection attempt or abort") is sufficient. --Paul Hoffman From matt@mattmccutchen.net Sun Nov 20 14:37: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 2027921F8A7A for ; Sun, 20 Nov 2011 14:37:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLPANEdu6Ztm for ; Sun, 20 Nov 2011 14:37:15 -0800 (PST) Received: from homiemail-a5.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 2605621F8A71 for ; Sun, 20 Nov 2011 14:37:15 -0800 (PST) Received: from homiemail-a5.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a5.g.dreamhost.com (Postfix) with ESMTP id BFFB1704074; Sun, 20 Nov 2011 14:37:14 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=message-id :subject:from:to:cc:in-reply-to:references:content-type:date :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=TIgRDNTpf7f68pfPkP6fEme4o+FXZaqp6tW0woX5oem 2c3VVqaUGuY1A6Hwy+cU1ueXieCVIgMD+JNefNMi1JYuRTnBD7Hc6ErXl3PZ+vQQ YOv9H4MAPfr9QkiohcFI41gwfMJN5081NvmFj78WDTxhXRrp2g9PKZLQ35tQH88k = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= message-id:subject:from:to:cc:in-reply-to:references :content-type:date:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=i4pZBF53uowAne4meWtVPXBRkwM=; b=Z1DpPiq9yM qyrVEdpLarrqjEPkBLeDPIN239DcLQthipsjjyRF4R8/MEDliOQPeI5IlHKUMb4q sOh8KIOV7oRt+7aTj/yTekFm0ZR62xKznXkx/Ga1ugFh8+FgyRBJIgS4nEnfH7Xz C6YnDsb8QMJ0NV9Jn1rpKQgW84akWs1TM= 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 9F847704071; Sun, 20 Nov 2011 14:37:14 -0800 (PST) Message-ID: <1321828627.8318.19.camel@mattlaptop2.local> From: Matt McCutchen To: Paul Hoffman In-Reply-To: <4AB082C8-24EE-4105-A50D-0990F42B097D@vpnc.org> References: <4AB082C8-24EE-4105-A50D-0990F42B097D@vpnc.org> Content-Type: text/plain; charset="UTF-8" Date: Sun, 20 Nov 2011 14:37:07 -0800 Mime-Version: 1.0 X-Mailer: Evolution 3.2.3 Content-Transfer-Encoding: 7bit Cc: IETF DANE WG list Subject: Re: [dane] Aiming towards some specific wording X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 20 Nov 2011 22:37:16 -0000 On Sun, 2011-11-20 at 12:27 -0800, Paul Hoffman wrote: > o A TLS certificate association whose DNSSEC validation state is > bogus MUST cause TLS not to be started or, if the TLS negotiation > is already in progress, to cause the connection to be aborted. Regardless of editorial preferences elsewhere, it is essential that this point refer to a "TLSA RRset", not a "TLS certificate association". The wording above, taken literally, would not cover the case in which an attacker replaces a TLSA RRset containing a restrictive certificate association with a bogus TLSA RRset that is empty. -- Matt From paul.hoffman@vpnc.org Sun Nov 20 15:05: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 277B321F886A for ; Sun, 20 Nov 2011 15:05:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 fpNJ+QUfTN3d for ; Sun, 20 Nov 2011 15:05:01 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 876DF21F87FC for ; Sun, 20 Nov 2011 15:05:01 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id pAKMojJD082511 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 20 Nov 2011 15:50:45 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Paul Hoffman In-Reply-To: <1321828627.8318.19.camel@mattlaptop2.local> Date: Sun, 20 Nov 2011 14:50:45 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4AB082C8-24EE-4105-A50D-0990F42B097D@vpnc.org> <1321828627.8318.19.camel@mattlaptop2.local> To: IETF DANE WG list X-Mailer: Apple Mail (2.1251.1) Subject: Re: [dane] Aiming towards some specific wording X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 20 Nov 2011 23:05:02 -0000 On Nov 20, 2011, at 2:37 PM, Matt McCutchen wrote: > On Sun, 2011-11-20 at 12:27 -0800, Paul Hoffman wrote: >> o A TLS certificate association whose DNSSEC validation state is >> bogus MUST cause TLS not to be started or, if the TLS negotiation >> is already in progress, to cause the connection to be aborted. >=20 > Regardless of editorial preferences elsewhere, it is essential that = this > point refer to a "TLSA RRset", not a "TLS certificate association". = The > wording above, taken literally, would not cover the case in which an > attacker replaces a TLSA RRset containing a restrictive certificate > association with a bogus TLSA RRset that is empty. Arrrgh: very good point. Will be updated in the next rev of the wording = choices to be sent to the group. And, combined with Peter Koch's earlier = request, I'll move the use of "certificate association" to later in the = text so that all these bullets use "RRset" consistently. After the call for wording choices and the next draft, I suspect there = will be more word juggling... --Paul Hoffman From matt@mattmccutchen.net Sun Nov 20 18:58: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 532B921F85B1 for ; Sun, 20 Nov 2011 18:58:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTfgXRyupFS8 for ; Sun, 20 Nov 2011 18:58:51 -0800 (PST) Received: from homiemail-a6.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3F921F85A7 for ; Sun, 20 Nov 2011 18:58:51 -0800 (PST) Received: from homiemail-a6.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTP id 100E4598077; Sun, 20 Nov 2011 18:58:51 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=message-id :subject:from:to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:mime-version; q=dns; s= mattmccutchen.net; b=CXVFoT9YYdgVhsKQPtLxYOw5HxvW1IbArSKh39fXrp7 kec3YpGZGi1oYlWm7XZ4FeObPIA8tU7Tnku8HUgO8bZTZNMoAvJe+uEg9SmHOcRo D2kxpQyxPDbnZrAClkODuRbRaAYvgaTIKFyyAszznuukG5IOO2Md3a+YcADTXpWI = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= message-id:subject:from:to:cc:date:in-reply-to:references :content-type:content-transfer-encoding:mime-version; s= mattmccutchen.net; bh=U1GukcGgDVtiCpkab8x6JTThv04=; b=ZBlSXOGjWH 6GJ5CnNTPlTwHOUSYnDCM7AR3C3EpqH0bzd8WjihecT1Y42dTWyi/grV58bXbRzH eWR217GWmIe0JM8uOSvAxmHGWwQoRGKGL7Obr3C/6pKXckkpR3aBne60zIYTNHt+ Flw4jPAqZA1OMdiBHsbyzMvwvoqgUJhQU= 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 DF362598070; Sun, 20 Nov 2011 18:58:50 -0800 (PST) Message-ID: <1321844329.22404.10.camel@mattlaptop2.local> From: Matt McCutchen To: Paul Hoffman Date: Sun, 20 Nov 2011 18:58:49 -0800 In-Reply-To: <4AB082C8-24EE-4105-A50D-0990F42B097D@vpnc.org> References: <4AB082C8-24EE-4105-A50D-0990F42B097D@vpnc.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Cc: IETF DANE WG list Subject: Re: [dane] Aiming towards some specific wording X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 21 Nov 2011 02:58:52 -0000 On Sun, 2011-11-20 at 12:27 -0800, Paul Hoffman wrote: > ========== CONTINUATION 2 START ========== > > o A TLS certificate association whose DNSSEC validation state is > indeterminate or insecure and whose usage is 0 or 1 MAY be used for > TLS if application marks it as usable. > > o A TLS certificate association whose DNSSEC validation state is > indeterminate or insecure and whose usage is 2 MUST NOT be used for > TLS and must be marked as unusable. We need to be more careful here. Since restriction is enforced whenever there is at least one usable association, allowing the client to mark some associations usable and others unusable will result in connection failures when the server uses a certificate corresponding to one of the associations marked unusable. I propose the following replacement text for Continuation 2: o If the TLSA RRset has DNSSEC validation state "insecure" or "indeterminate", the client MUST do one of the following: (1) Proceed as if each association of usage 2 instead had usage 0. (2) Proceed as if the TLSA RRset were empty. o Future definitions of new certificate usages MUST amend (1) above to specify the changes, if any, to be made to associations of that usage. -- Matt From paul.hoffman@vpnc.org Sun Nov 20 19:34: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 97AEC21F853B for ; Sun, 20 Nov 2011 19:34:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 AbCsNixmnGpb for ; Sun, 20 Nov 2011 19:34:49 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7111821F853A for ; Sun, 20 Nov 2011 19:34:42 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id pAL3Yf1s089261 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 20 Nov 2011 20:34:42 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <1321844329.22404.10.camel@mattlaptop2.local> Date: Sun, 20 Nov 2011 19:34:41 -0800 Content-Transfer-Encoding: 7bit Message-Id: <60ACA6E0-2986-4B45-BB36-568C7FA0B6BB@vpnc.org> References: <4AB082C8-24EE-4105-A50D-0990F42B097D@vpnc.org> <1321844329.22404.10.camel@mattlaptop2.local> To: Matt McCutchen X-Mailer: Apple Mail (2.1251.1) Cc: IETF DANE WG list Subject: Re: [dane] Aiming towards some specific wording X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 21 Nov 2011 03:34:49 -0000 On Nov 20, 2011, at 6:58 PM, Matt McCutchen wrote: > I propose the following replacement text > for Continuation 2: > > o If the TLSA RRset has DNSSEC validation state "insecure" or > "indeterminate", the client MUST do one of the following: > > (1) Proceed as if each association of usage 2 instead had usage 0. > > (2) Proceed as if the TLSA RRset were empty. > > o Future definitions of new certificate usages MUST amend (1) above to > specify the changes, if any, to be made to associations of that usage. I will add that as another option. --Paul Hoffman From matt@mattmccutchen.net Sun Nov 20 20:19: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 7BE8611E8096 for ; Sun, 20 Nov 2011 20:19:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 3KVeXNgHjkd5 for ; Sun, 20 Nov 2011 20:19:19 -0800 (PST) Received: from homiemail-a3.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id DBA3F11E808D for ; Sun, 20 Nov 2011 20:19:19 -0800 (PST) Received: from homiemail-a3.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a3.g.dreamhost.com (Postfix) with ESMTP id 7FF9828406E; Sun, 20 Nov 2011 20:19:19 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=message-id :subject:from:to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:mime-version; q=dns; s= mattmccutchen.net; b=gjW5OUNz5zMKiyd7FzGGVEv6vVyodrM1JX7uq24AUNM HrBBiJXYMKhPiTAO6yyBUfVobd/+TrNGz89VWLGHxx2gyHNM3cNtFpcueWjQl7G8 HKdHwdamfLy1na0j3d18Jfv0xk27ky5BqSaaGhxtG+IpQSx7BhyffdEwNr5QV4uQ = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= message-id:subject:from:to:cc:date:in-reply-to:references :content-type:content-transfer-encoding:mime-version; s= mattmccutchen.net; bh=lRo9NwDxFuiLJAR63k81JE8VXzg=; b=PmNLTHZBv1 Dqg/vNfzNNQ9kUqLICg4A7ZBgLZPKc7yDLHWk3sw6JUELbcRptppnSixXDZ3i729 qhS+qmvMeonINViRUB22h/vcGQGRDM6t7hUlCp4Wf0lJL1Zjhow3Zbba3XQvTmMg P070GycZxc/uUhSnUb0NRQz2RdXnIcInk= 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 5779C28406A; Sun, 20 Nov 2011 20:19:19 -0800 (PST) Message-ID: <1321849158.1657.3.camel@mattlaptop2.local> From: Matt McCutchen To: Paul Hoffman Date: Sun, 20 Nov 2011 20:19:18 -0800 In-Reply-To: <60ACA6E0-2986-4B45-BB36-568C7FA0B6BB@vpnc.org> References: <4AB082C8-24EE-4105-A50D-0990F42B097D@vpnc.org> <1321844329.22404.10.camel@mattlaptop2.local> <60ACA6E0-2986-4B45-BB36-568C7FA0B6BB@vpnc.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Cc: IETF DANE WG list Subject: Re: [dane] Aiming towards some specific wording X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 21 Nov 2011 04:19:20 -0000 On Sun, 2011-11-20 at 19:34 -0800, Paul Hoffman wrote: > On Nov 20, 2011, at 6:58 PM, Matt McCutchen wrote: > > I propose the following replacement text > > for Continuation 2: > > > > o If the TLSA RRset has DNSSEC validation state "insecure" or > > "indeterminate", the client MUST do one of the following: > > > > (1) Proceed as if each association of usage 2 instead had usage 0. > > > > (2) Proceed as if the TLSA RRset were empty. > > > > o Future definitions of new certificate usages MUST amend (1) above to > > specify the changes, if any, to be made to associations of that usage. > > > I will add that as another option. Is that really necessary? It seems clear to me that the original formulation of Continuation 2 is simply broken (no offense to you) and cannot possibly be what the proponents of DNSSEC-less restriction would have intended. But if it is too difficult to establish that at this point, we can just vote on the three options. -- Matt From paul.hoffman@vpnc.org Sun Nov 20 22:32: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 24EB221F8ABD for ; Sun, 20 Nov 2011 22:32:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 ym+iwtNFTSSA for ; Sun, 20 Nov 2011 22:32:27 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id A966F21F84FC for ; Sun, 20 Nov 2011 22:32:27 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id pAL6WQYj093517 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 20 Nov 2011 23:32:27 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Paul Hoffman In-Reply-To: <1321849158.1657.3.camel@mattlaptop2.local> Date: Sun, 20 Nov 2011 22:32:26 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4AB082C8-24EE-4105-A50D-0990F42B097D@vpnc.org> <1321844329.22404.10.camel@mattlaptop2.local> <60ACA6E0-2986-4B45-BB36-568C7FA0B6BB@vpnc.org> <1321849158.1657.3.camel@mattlaptop2.local> To: IETF DANE WG list X-Mailer: Apple Mail (2.1251.1) Subject: Re: [dane] Aiming towards some specific wording X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 21 Nov 2011 06:32:28 -0000 On Nov 20, 2011, at 8:19 PM, Matt McCutchen wrote: > On Sun, 2011-11-20 at 19:34 -0800, Paul Hoffman wrote: >> I will add that as another option. >=20 > Is that really necessary? =20 Yes. > It seems clear to me that the original > formulation of Continuation 2 is simply broken (no offense to you) and > cannot possibly be what the proponents of DNSSEC-less restriction = would > have intended. =20 Fine. If absolutely everyone agrees with you, and doesn't want the = Continuation 1, then we've only wasted a few electrons. If someone = disagrees with what is clear to you, then there is value to keeping all = three. > But if it is too difficult to establish that at this > point, we can just vote on the three options. Glad we agree here. --Paul Hoffman From mrex@sap.com Mon Nov 21 06:42: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 228A511E80C4 for ; Mon, 21 Nov 2011 06:42:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.205 X-Spam-Level: X-Spam-Status: No, score=-9.205 tagged_above=-999 required=5 tests=[AWL=-0.815, BAYES_20=-0.74, 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 q7u3DOEiUaHc for ; Mon, 21 Nov 2011 06:42:42 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id EB27111E80C2 for ; Mon, 21 Nov 2011 06:42:41 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id pALEgUUR009616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 21 Nov 2011 15:42:30 +0100 (MET) From: Martin Rex Message-Id: <201111211442.pALEgSnJ016837@fs4113.wdf.sap.corp> To: hallam@gmail.com (Phillip Hallam-Baker) Date: Mon, 21 Nov 2011 15:42:28 +0100 (MET) In-Reply-To: from "Phillip Hallam-Baker" at Nov 18, 11 10:48:54 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: agl@imperialviolet.org, dane@ietf.org Subject: Re: [dane] Fragility of PKIX path discovery X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 14:42:47 -0000 Phil, You're entirely missing the point. The PathLenConstraints is a pure business-model control in PKIX, it is *not* a security control. As Steve Kent keeps pointing out, X.509v3&PKIX design boldly assumes that properly managed CAs simply can not be subverted. The possibility to issue yourself CRL and OCSP signer certs *and* control the locations that will be checked for revocations of such certs only through the OCSP-AIA and CRL-DP elements of the (fraudulent) end-entity cert itself will reliably subvert revocation. But if CAs want to employ a original business model control such as PathLenConstraint=0 as a security control, they should probably first get some idea whether that feature is actually implemented in the installed base. BasicConstraint "cA=TRUE" is a security control, but anyhow at least two commercial CAs managed to issue themselves CA-certs without it, one of them (Entrust) even got it accepted and distributed by Browser vendors (OUCH!), and two vendors managed to ship without support for it (Microsoft in 1998 -- fixed 2002, Apple in 2007 -- fixed 2011). If a CA actually cared about security, it would have been a trivial no-brainer for them to configure a TLS server with various "demo-fraudulent" TLS credentials on non-standard ports signed under one of their official CA certs so that novice customers could check their fancy devices against it just by clicking an URL the CA's web page. It is even possible to use Flashcrowd/crowdsourcing to determine within hours whether the installed base supports your assumptions about security control. Example for a flashcrowd: http://www.theregister.co.uk/2009/12/07/darpa_balloon_hunt_result/ Apple shipped 4 generations of iPhones and 2 generations of iPads over 4 years (some 50 million gadgets) without (functioning) X.509v3 BasicConstraints security controls, and it required a curious security researcher to find out that the security controls, that commercial CAs blindly rely on, were not working on that Apple gear. Had any of the commercial CAs any such test-pages with "demo-fraudulent" certs then some curious folks (potentially even Apple-fans working for CAs) had stumbled upon this problem during the first year of its shipment. -Martin Phillip Hallam-Baker wrote: > > Really, this one way 'lets beat up on PKIX but nobody can ever question > DNSSEC' is getting tiresome. What you want is to have free hits on PKIX > then run hide behind mommy when your scheme is considered. > > People screw up the implementation of all crypto code. Some people will > screw up the implementation of DANE as well, if you are lucky enough for > people to implement it. > > On Fri, Nov 18, 2011 at 5:57 PM, Martin Rex wrote: > > > Trevor Freeman wrote: > > > > > > Lets get back to the threats because not all certificates are as > > > easy to generate and be trusted > > > > > > 3. Attacker gets attack code into CA environment and generates > > > a CA certificate of their choice > > > > > > #3 has been mitigated by the public CA using path length constraints > > > for online CAs. This is typical by putting the path length = 0 into > > > the online CAs certificates but sometimes its higher up if the chin > > > is longer. Pkix validation means no CA certificate issued by a CA > > > with path length = 0 would be trusted. > > > > Some 9 years ago it was discovered that MSIE would not check for > > "BasicConstraint cA=TRUE" in a certificate before accepting it as > > a CA cert in a certification path, therefore all End-Entity certs > > were treated equivalent to real CA certs: > > > > http://www.thoughtcrime.org/ie-ssl-chain.txt > > > > In 2011 it was reported that none of the existing versions of > > Apple iOS was having the exact same defect and would accept > > End-Entity certs as valid CA certs in certification paths. > > > > http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-0228 > > > > > > Your claim about PathLenConstraint=0 saving the day, > > reminds me of a quote from a movie: > > > > Did you see the body? Assumption is the mother of all F*** UPS! > > > > > > -Martin > > _______________________________________________ > > dane mailing list > > dane@ietf.org > > https://www.ietf.org/mailman/listinfo/dane > > > > > > -- > Website: http://hallambaker.com/ > > --f46d044472bb2c73d804b20e553f > Content-Type: text/html; charset="ISO-8859-1" > Content-Transfer-Encoding: quoted-printable > > Really, this one way 'lets beat up on PKIX but nobody can ever question= > DNSSEC' is getting tiresome. What you want is to have free hits on PKI= > X then run hide behind mommy when your scheme is considered.

>
People screw up the implementation of all crypto code. Some people wil= > l screw up the implementation of DANE as well, if you are lucky enough for = > people to implement it.


On Fri= > , Nov 18, 2011 at 5:57 PM, Martin Rex < to:mrex@sap.com">mrex@sap.com> wrote:
>
x #ccc solid;padding-left:1ex;">Trevor Freeman wrote:
> >
> > Lets get back to the threats because not all certificates are as
> > easy to generate and be trusted
> >
> > 3. =A0Attacker gets attack code into CA environment and generates
> > =A0 =A0 a CA certificate of their choice
> >
> > #3 has been mitigated by the public CA using path length constraints r> > > for online CAs. This is typical by putting the path length =3D 0 into<= > br> > > the online CAs certificates but sometimes its higher up if the chin > > > is longer. =A0Pkix validation means no CA certificate issued by a CA r> > > with path length =3D 0 would be trusted.
>
> Some 9 years ago it was discovered that MSIE would not check for
> "BasicConstraint cA=3DTRUE" in a certificate before accepting it = > as
> a CA cert in a certification path, therefore all End-Entity certs
> were treated equivalent to real CA certs:
>
> =A0 nk">http://www.thoughtcrime.org/ie-ssl-chain.txt
>
> In 2011 it was reported that none of the existing versions of
> Apple iOS was having the exact same defect and would accept
> End-Entity certs as valid CA certs in certification paths.
>
> =A0 228" target=3D"_blank">http://web.nvd.nist.gov/view/vuln/detail?vulnId=3DCV= > E-2011-0228
>
>
> Your claim about PathLenConstraint=3D0 saving the day,
> reminds me of a quote from a movie:
>
> =A0Did you see the body? Assumption is the mother of all F*** UPS!
>
>
> -Martin
> _______________________________________________
> dane mailing list
> dane@ietf.org
> ht= > tps://www.ietf.org/mailman/listinfo/dane
>



--
Website: href=3D"http://hallambaker.com/">http://hallambaker.com/

>
> > --f46d044472bb2c73d804b20e553f-- > From rbarnes@bbn.com Mon Nov 21 06:56: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 DBDB211E80C9 for ; Mon, 21 Nov 2011 06:56:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.901 X-Spam-Level: X-Spam-Status: No, score=-105.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 ESfPfVM-7e5H for ; Mon, 21 Nov 2011 06:56:30 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 669F211E80BD for ; Mon, 21 Nov 2011 06:56:30 -0800 (PST) Received: from ros-dhcp192-1-51-60.bbn.com ([192.1.51.60]:52800) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RSVII-0005Gc-SR; Mon, 21 Nov 2011 09:56:27 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <1321844329.22404.10.camel@mattlaptop2.local> Date: Mon, 21 Nov 2011 09:56:26 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4AB082C8-24EE-4105-A50D-0990F42B097D@vpnc.org> <1321844329.22404.10.camel@mattlaptop2.local> To: Matt McCutchen X-Mailer: Apple Mail (2.1084) Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] Aiming towards some specific wording X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 21 Nov 2011 14:56:31 -0000 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONTINUATION 2 START =3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>=20 >> o A TLS certificate association whose DNSSEC validation state is >> indeterminate or insecure and whose usage is 0 or 1 MAY be used for >> TLS if application marks it as usable. >>=20 >> o A TLS certificate association whose DNSSEC validation state is >> indeterminate or insecure and whose usage is 2 MUST NOT be used for >> TLS and must be marked as unusable. >=20 > We need to be more careful here. Since restriction is enforced = whenever > there is at least one usable association, allowing the client to mark > some associations usable and others unusable will result in connection > failures when the server uses a certificate corresponding to one of = the > associations marked unusable. I propose the following replacement = text > for Continuation 2: >=20 > o If the TLSA RRset has DNSSEC validation state "insecure" or > "indeterminate", the client MUST do one of the following: >=20 > (1) Proceed as if each association of usage 2 instead had usage 0. >=20 > (2) Proceed as if the TLSA RRset were empty. >=20 > o Future definitions of new certificate usages MUST amend (1) above to > specify the changes, if any, to be made to associations of that usage. I would propose that (2) is the only useful option here. If validation = state !=3D secure || bogus, then behave as if the RRset were empty. In = text form: o If the TLSA RRset has DNSSEC validation state "insecure" or "indeterminate", then the client MUST proceed as if the TLSA RRset were empty. --Richard From ondrej.sury@nic.cz Mon Nov 21 07:02: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 6739E1F0C4F for ; Mon, 21 Nov 2011 07:02:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[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 zOpPconH-iF5 for ; Mon, 21 Nov 2011 07:02:21 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 60FBF1F0C36 for ; Mon, 21 Nov 2011 07:02:21 -0800 (PST) Received: from kimac.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 704022A296E; Mon, 21 Nov 2011 16:02:20 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1321887740; bh=CFnR4UX9a3WsJdzZ4/xPG830NkZwAO8CXtMjUBhpoW0=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=d30GoBhuCpHvPuixb/4rykrGmf39O39C/Y63ytnzMAAYGASXO2o7E+4Y7MGRH6FV1 s7wmNcz8528qccDpOv1q7K5TA83TjqR7mmpQqaj/BVQscc4RVP90kCgDD/FqK0EiKL l492m6sJM5DxfN5lKPeHSjwgSdr8XbZvs8jCrxRs= Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <0536F82C-346C-4ABE-81E6-3B008219DBD9@kirei.se> Date: Mon, 21 Nov 2011 16:02:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <773BAA00-22B9-43A6-BB36-8E3CB6166E38@nic.cz> References: <45EA694E-096C-41A1-B60E-BF7B3832FE2A@vpnc.org> <4EC70173.9090106@sv.cmu.edu> <247CAE36-68FB-4048-B07C-9B4C0903434D@vpnc.org> <92AA2445-000C-44CF-8CA5-9796528EA946@checkpoint.com> <0536F82C-346C-4ABE-81E6-3B008219DBD9@kirei.se> To: Jakob Schlyter X-Mailer: Apple Mail (2.1251.1) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] Aiming towards some specific wording X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 21 Nov 2011 15:02:26 -0000 On 19. 11. 2011, at 19:10, Jakob Schlyter wrote: > On 19 nov 2011, at 11:58, Yoav Nir wrote: >=20 >> I am not in that camp, but since we are requiring TLSA to be secure, = but not requiring this (for now) for A records, it makes no sense for an = attacker to forge a signature on the A record: you will accept it = unsigned anyway. >=20 > One should remember that most (if not, all) DNSSEC resolver will never = return bogus answers. If one tries to forge or strip a signature from a = record that is supposed to be signed, resolving will fail and nothing is = returned. Jakob, you can look at the RCODE in the DNS response and if you see SERVFAIL = you can abort the TLS connection. And my view is that the DANE aware client should look at the RCODE and = "throw away" only if the RCODE is NOERROR or NXDOMAIN. 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 Nov 21 07:50: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 47BA111E80CB for ; Mon, 21 Nov 2011 07:50:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.001 X-Spam-Level: X-Spam-Status: No, score=-1.001 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIW+Gv2eNv-M for ; Mon, 21 Nov 2011 07:50:16 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 2581311E80C4 for ; Mon, 21 Nov 2011 07:50:16 -0800 (PST) Received: from kimac.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 601F72A2DAF; Mon, 21 Nov 2011 16:50:15 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1321890615; bh=gwgkCDDvk/QxE8OTx7AdQw842qFWfJLSkMLEWq3C268=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=t1QY6/fKQc06MiNGvgOEqMH5XIgQnL/vimJE7C7Quxq/tEqtdPVXDWlmk/G7XiLrC ywCe3K69kfLxe7rqZBeLQwsZUtcm8c4ihltkNI+ZmR9VPEzGEgjD5tzztw6qKQ+Mou Ui2+qcHs/cW1WKaSLZDKu5PWlR3T5ooxxAi1lTSI= Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <4AB082C8-24EE-4105-A50D-0990F42B097D@vpnc.org> Date: Mon, 21 Nov 2011 16:50:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4AB082C8-24EE-4105-A50D-0990F42B097D@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1251.1) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: IETF DANE WG list Subject: Re: [dane] Aiming towards some specific wording X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 21 Nov 2011 15:50:21 -0000 On 20. 11. 2011, at 21:27, Paul Hoffman wrote: > [[ New version, incorporating comments from this thread so far. Please = let me know if the specific wording of the proposals is OK, but not = whether you support them. ]] >=20 > Greetings again. The recent threads are useful, but some people change = the topic mid-thread so determining what actual words people want in the = draft is difficult. As document co-author, I want to nail down the = words. To do that, the WG needs some choices, and that is the purpose of = this message. I have tried to cast each of the choices expressed in the = past few days in actual text that would appear in the document. >=20 > THIS IS NOT A CALL FOR SUPPORT FOR ANY WORDING!!! This is a call to be = sure that all opinions are given for a LATER CALL. Sorry to use the ALL = CAPS there, but people here tend to vote quickly and then ask for = modifications later. >=20 > I propose the following preamble wording to the "interesting" parts of = the wording: >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D PREAMBLE A START =3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D >=20 > Determining whether a TLS certificate association can be used depends > on the DNSSEC validation state (as defined in [RFC4033]). >=20 > o A TLS certificate association whose DNSSEC validation state is > secure can be used for TLS. >=20 > o A TLS certificate association whose DNSSEC validation state is > bogus MUST cause TLS not to be started or, if the TLS negotiation > is already in progress, to cause the connection to be aborted. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D PREAMBLE A END =3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D >=20 > One of the following, or some other choice, needs to be added to the = preamble. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONTINUATION 1 START =3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > o A TLS certificate association whose DNSSEC validation state is > indeterminate or insecure cannot be used for TLS and must be marked > as unusable. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONTINUATION 1 END =3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Since we are not requiring the DANE-aware application to include validating resolver, you cannot really use RFC4033 states here. Any application using trusted validating resolver will only see DNS flags (+AD), RCODE and DNS RRSets and it will have to ask with +DNSSEC OK flag. So we will have to define our own state table, I propose to base the work on Richard's updated flowchart/state table. Our states (from trusted validating resolver): SECURE - +ADFlag && (RCODE=3DNOERROR || RCODE=3DNXDOMAIN) BOGUS =3D !(RCODE=3DNOERROR || RCODE=3DNXDOMAIN) INSECURE =3D -ADFlag Then the wording would be: o A DNS response for TLSA RRset query whose state is SECURE can be used for further DANE processing. If the TLSA RRset is non-empty it can be used for TLS. o A DNS response for TLSA RRset query whose state is BOGUS cause TLS not to be started or, if the TLS negotiation is already in progress, to cause the connection to be aborted. o A DNS response for TLSA RRset query whose state is INSECURE cannot be used for TLS and must be marked as unusable. O. > ############# OR #################### >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONTINUATION 2 START =3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > o A TLS certificate association whose DNSSEC validation state is > indeterminate or insecure and whose usage is 0 or 1 MAY be used for > TLS if application marks it as usable. >=20 > o A TLS certificate association whose DNSSEC validation state is > indeterminate or insecure and whose usage is 2 MUST NOT be used for > TLS and must be marked as unusable. >=20 > o Future definitions of new certificate usages MUST include > specification of whether or not DNSSEC validation is required > for that usage. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONTINUATION 2 END =3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D As Warren pointed out the CONTINUATION 2 is out of the charter. > Again, PLEASE DO NOT SAY YET WHICH OF THESE YOU SUPPORT. Instead, if = you think the wording in Preamble A, Continuation 1, or Continuation 2 = do not exactly match what you would want in the spec, please propose a = different preamble or continuation text (not just "ideas"). That way, = when we later ask for what wording people want, all proposals will = already be on the table and we will not (again) have wording changes = appear mid-vote. Thanks in advance for your cooperation. >=20 > --Paul Hoffman >=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 ogud@ogud.com Mon Nov 21 07:51: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 6092511E80CE for ; Mon, 21 Nov 2011 07:51:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.579 X-Spam-Level: X-Spam-Status: No, score=-106.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 Rc4jI6i5NLwl for ; Mon, 21 Nov 2011 07:51:49 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 037E911E80CB for ; Mon, 21 Nov 2011 07:51:48 -0800 (PST) Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id pALFplfL099898 for ; Mon, 21 Nov 2011 10:51:47 -0500 (EST) (envelope-from ogud@ogud.com) Message-ID: <4ECA7393.9060101@ogud.com> Date: Mon, 21 Nov 2011 10:51:47 -0500 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: dane@ietf.org References: <45EA694E-096C-41A1-B60E-BF7B3832FE2A@vpnc.org> In-Reply-To: <45EA694E-096C-41A1-B60E-BF7B3832FE2A@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Subject: Re: [dane] Aiming towards some specific wording X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 21 Nov 2011 15:51:53 -0000 On 18/11/2011 19:10, Paul Hoffman wrote: > Greetings again. The recent threads are useful, but some people change the topic mid-thread so determining what actual words people want in the draft is difficult. As document co-author, I want to nail down the words. To do that, the WG needs some choices, and that is the purpose of this message. I have tried to cast each of the choices expressed in the past few days in actual text that would appear in the document. > > THIS IS NOT A CALL FOR SUPPORT FOR ANY WORDING!!! This is a call to be sure that all opinions are given for a LATER CALL. Sorry to use the ALL CAPS there, but people here tend to vote quickly and then ask for modifications later. > > I propose the following preamble wording to the "interesting" parts of the wording: > > ========== PREAMBLE A START ========== > > Determining whether a TLS certificate association can be used depends > on the DNSSEC valiation state (as defined in [RFC4033]). > > o A TLS certificate association whose DNSSEC validation state is > secure can be used for TLS. > > o A TLS certificate association whose DNSSEC validation state is > bogus cannot be used for TLS and must be marked as unusable. > > ========== PREAMBLE A END ========== I think better wording is: (based on Warrens message from his flight, and my reading of the feelings on the mailing list and conversations with participants). ------ A TLS certificate association can only be used if DNSSEC validation state is secure. ------ or ----- Only when DNSSEC validation returns a validated answer[RFC4033] can a TLSA RRset be used by a DANE client. ----- What that means is that bogus, proof-ably insecure, undetermined etc. are all outside the scope of this document. If "DNSSEC validated only" is the scope of the document then none of the proposed texts below below are needed. Olafur > > One of the following, or some other choice, needs to be added to the preamble. > > ========== CONTINUATION 1 START ========== > > o A TLS certificate association whose DNSSEC validation state is > indeterminate cannot be used for TLS and must be marked as > unusable. > > ========== CONTINUATION 1 END ========== > > ############# OR #################### > > ========== CONTINUATION 2 START ========== > > o A TLS certificate association whose DNSSEC validation state is > indeterminate and whose usage is 0 or 1 MAY be used for TLS if > application marks it as usable. > > o A TLS certificate association whose DNSSEC validation state is > indeterminate and whose usage is 2 MUST NOT be used for TLS and > must be marked as unusable. > > o Future definitions of new certificate usages MUST include > specification of whether or not DNSSEC validation is required > for that usage. > > ========== CONTINUATION 2 END ========== > > Again, PLEASE DO NOT SAY YET WHICH OF THESE YOU SUPPORT. Instead, if you think the wording in Preamble A, Continuation 1, or Continuation 2 do not exactly match what you would want in the spec, please propose a different preamble or continuation text (not just "ideas"). That way, when we later ask for what wording people want, all proposals will already be on the table and we will not (again) have wording changes appear mid-vote. Thanks in advance for your cooperation. > > --Paul Hoffman > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > > > From peter@denic.de Mon Nov 21 07:35: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 0C96111E80BE for ; Mon, 21 Nov 2011 07:35:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, 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 mINUcHc+Fsbq for ; Mon, 21 Nov 2011 07:35:29 -0800 (PST) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::4]) by ietfa.amsl.com (Postfix) with ESMTP id B6C8A11E8096 for ; Mon, 21 Nov 2011 07:35:29 -0800 (PST) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1RSVu4-0002dk-Pb; Mon, 21 Nov 2011 16:35:28 +0100 Received: from localhost by x27.adm.denic.de with local id 1RSVu4-0002Vf-Ll; Mon, 21 Nov 2011 16:35:28 +0100 Date: Mon, 21 Nov 2011 16:35:28 +0100 From: Peter Koch To: IETF DANE WG list Message-ID: <20111121153528.GK13798@x27.adm.denic.de> Mail-Followup-To: IETF DANE WG list References: <45EA694E-096C-41A1-B60E-BF7B3832FE2A@vpnc.org> <20111120163557.GX13798@x27.adm.denic.de> <0FF0603A-11CF-4A3B-BAAD-060FD24231C7@vpnc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0FF0603A-11CF-4A3B-BAAD-060FD24231C7@vpnc.org> User-Agent: Mutt/1.4.2.3i Sender: Peter Koch X-Mailman-Approved-At: Mon, 21 Nov 2011 07:52:15 -0800 Subject: Re: [dane] Aiming towards some specific wording X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 21 Nov 2011 15:35:35 -0000 On Sun, Nov 20, 2011 at 12:29:59PM -0800, Paul Hoffman wrote: > > I believe that s/TLS certificate association/TLSA RRSet/ would be > > more to the point and more precise protocol specification language. > > The term "certificate association" is defined and used in this document. my suggestion was made in full recognition of section 1.1 of the document. > > "can be used" remains ambiguous, though. > An implementation is not forced to use good DANE information even if it comes validated. For example, there might be a local policy that says "even if you get DANE information about somebigbank.com, ignore it and use this hard-coded information instead". Local policy almost always trumps the protocol spec. So, "can" is unclear as it could be simply descriptive or half way into a "MAY" or even "SHOULD". What's the intent here? Same for "use": is that "usage" as per section 2.1.1? -Peter From peter@denic.de Mon Nov 21 07:53: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 8B01921F8AE6 for ; Mon, 21 Nov 2011 07:53:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 R0GVR4XBip4g for ; Mon, 21 Nov 2011 07:53:10 -0800 (PST) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::4]) by ietfa.amsl.com (Postfix) with ESMTP id 0E09221F8541 for ; Mon, 21 Nov 2011 07:53:10 -0800 (PST) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1RSWBA-0002kn-1v; Mon, 21 Nov 2011 16:53:08 +0100 Received: from localhost by x27.adm.denic.de with local id 1RSWB9-0002ly-Ui; Mon, 21 Nov 2011 16:53:07 +0100 Date: Mon, 21 Nov 2011 16:53:07 +0100 From: Peter Koch To: "Richard L. Barnes" Message-ID: <20111121155307.GL13798@x27.adm.denic.de> Mail-Followup-To: "Richard L. Barnes" , IETF DANE WG list References: <4AB082C8-24EE-4105-A50D-0990F42B097D@vpnc.org> <1321844329.22404.10.camel@mattlaptop2.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Cc: IETF DANE WG list Subject: Re: [dane] Aiming towards some specific wording X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 21 Nov 2011 15:53:10 -0000 On Mon, Nov 21, 2011 at 09:56:26AM -0500, Richard L. Barnes wrote: > o If the TLSA RRset has DNSSEC validation state "insecure" or > "indeterminate", then the client MUST proceed as if the TLSA > RRset were empty. while mathematically comprehensible, I'd recommend against this particular language just because in the DNS we do not talk about "empty RRSets". So s/RRset were empty/RRSet would not exist/ would do it. -Peter From rbarnes@bbn.com Mon Nov 21 08:22: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 9F97921F8B17 for ; Mon, 21 Nov 2011 08:22:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.549 X-Spam-Level: X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNvajWiJfq4N for ; Mon, 21 Nov 2011 08:22:01 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 26EB121F8B3B for ; Mon, 21 Nov 2011 08:22:01 -0800 (PST) Received: from ros-dhcp192-1-51-60.bbn.com ([192.1.51.60]:53789) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RSWd2-000LrK-II; Mon, 21 Nov 2011 11:21:56 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <20111121155307.GL13798@x27.adm.denic.de> Date: Mon, 21 Nov 2011 11:21:55 -0500 Content-Transfer-Encoding: 7bit Message-Id: <3ED27F6C-6A37-42DD-BE07-2790060341D9@bbn.com> References: <4AB082C8-24EE-4105-A50D-0990F42B097D@vpnc.org> <1321844329.22404.10.camel@mattlaptop2.local> <20111121155307.GL13798@x27.adm.denic.de> To: Peter Koch X-Mailer: Apple Mail (2.1084) Cc: IETF DANE WG list Subject: Re: [dane] Aiming towards some specific wording X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 21 Nov 2011 16:22:01 -0000 Fine with me. On Nov 21, 2011, at 10:53 AM, Peter Koch wrote: > On Mon, Nov 21, 2011 at 09:56:26AM -0500, Richard L. Barnes wrote: > >> o If the TLSA RRset has DNSSEC validation state "insecure" or >> "indeterminate", then the client MUST proceed as if the TLSA >> RRset were empty. > > while mathematically comprehensible, I'd recommend against this particular > language just because in the DNS we do not talk about "empty RRSets". > So s/RRset were empty/RRSet would not exist/ would do it. > > -Peter From zack.weinberg@gmail.com Mon Nov 21 08:57: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 AEA2921F8C73 for ; Mon, 21 Nov 2011 08:57:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.891 X-Spam-Level: X-Spam-Status: No, score=-2.891 tagged_above=-999 required=5 tests=[AWL=0.086, 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 GK9gwMQokAIf for ; Mon, 21 Nov 2011 08:57:41 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 274B021F8C70 for ; Mon, 21 Nov 2011 08:57:41 -0800 (PST) Received: by qadb40 with SMTP id b40so324169qad.10 for ; Mon, 21 Nov 2011 08:57:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=xOCWoZDLw21lgjX0q7pvFLTNVwUccMDBu2JQfdrcNMw=; b=emMSrgEeeQVd0pvHUCF+Awek7pn2GtTqnjr7drDQgu1QpzHghFx4RfjmW/kk59Y5ya erHmUh9eSOkZqTkFbjC30Y6fGtUkpjQcCtu7CfNV6NUj7LWp1iW8atz88lEmF+hmhQbZ 3s6d05A0xUq9Q02QdO7qB6BMB9PEegq/rNCYE= MIME-Version: 1.0 Received: by 10.182.222.99 with SMTP id ql3mr3157778obc.67.1321894660419; Mon, 21 Nov 2011 08:57:40 -0800 (PST) Sender: zack.weinberg@gmail.com Received: by 10.182.88.103 with HTTP; Mon, 21 Nov 2011 08:57:40 -0800 (PST) In-Reply-To: <4ECA7393.9060101@ogud.com> References: <45EA694E-096C-41A1-B60E-BF7B3832FE2A@vpnc.org> <4ECA7393.9060101@ogud.com> Date: Mon, 21 Nov 2011 08:57:40 -0800 X-Google-Sender-Auth: 7w9qA6hky1bkY1dOH-TGZbi9biE Message-ID: From: Zack Weinberg To: Olafur Gudmundsson Content-Type: text/plain; charset=UTF-8 Cc: dane@ietf.org Subject: Re: [dane] Aiming towards some specific wording X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 21 Nov 2011 16:57:41 -0000 On Mon, Nov 21, 2011 at 7:51 AM, Olafur Gudmundsson wrote: > What that means is that bogus, proof-ably insecure, undetermined etc. are > all outside the scope of this document. This is not acceptable to me. Most importantly, the behavior for "bogus" _must_ be specified in the initial protocol document, or we will be leaving security holes in a security mechanism. And I do not think there is any good reason to avoid specifying behavior for all four DNSSEC validation states. The appropriate thing to put out of scope is the case where the client is _incapable_ of accessing DNSSEC validation states - not because of its network conditions, but because it hasn't got the code. zw From zack.weinberg@gmail.com Mon Nov 21 09:04: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 D542F11E80BD for ; Mon, 21 Nov 2011 09:04:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.752 X-Spam-Level: X-Spam-Status: No, score=-2.752 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqxQcQ-FZBz0 for ; Mon, 21 Nov 2011 09:04:34 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1570211E80AA for ; Mon, 21 Nov 2011 09:04:34 -0800 (PST) Received: by vbbfc26 with SMTP id fc26so3217004vbb.31 for ; Mon, 21 Nov 2011 09:04:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=cNMVpwHivvNBiYDXMFq9NWf/rX6NBRr17yIPX88I4mI=; b=SaqF88eTFdiJKlPcfQcT3iSr64fjy6tB0b7e1V3BptBsQar7Wdsp30LdTsbsip/Lf5 CoXLiSDQpeln3rG7jorij3v4InccSEHQFYPA83kej/VUX+x9dBk/FdaORPJi4bknhyMQ K2GWRrCNhqECxX4cnaz61mgwbCIKrgnPSJXxE= MIME-Version: 1.0 Received: by 10.182.50.65 with SMTP id a1mr3193806obo.17.1321895072415; Mon, 21 Nov 2011 09:04:32 -0800 (PST) Sender: zack.weinberg@gmail.com Received: by 10.182.88.103 with HTTP; Mon, 21 Nov 2011 09:04:32 -0800 (PST) In-Reply-To: <773BAA00-22B9-43A6-BB36-8E3CB6166E38@nic.cz> References: <45EA694E-096C-41A1-B60E-BF7B3832FE2A@vpnc.org> <4EC70173.9090106@sv.cmu.edu> <247CAE36-68FB-4048-B07C-9B4C0903434D@vpnc.org> <92AA2445-000C-44CF-8CA5-9796528EA946@checkpoint.com> <0536F82C-346C-4ABE-81E6-3B008219DBD9@kirei.se> <773BAA00-22B9-43A6-BB36-8E3CB6166E38@nic.cz> Date: Mon, 21 Nov 2011 09:04:32 -0800 X-Google-Sender-Auth: o2mj5IHXU2E5rrlJJkt1ef_p_Pg Message-ID: From: Zack Weinberg To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IETF DANE WG list Subject: Re: [dane] Aiming towards some specific wording X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 21 Nov 2011 17:04:34 -0000 On Mon, Nov 21, 2011 at 7:02 AM, Ond=C5=99ej Sur=C3=BD = wrote: > > you can look at the RCODE in the DNS response and if you see SERVFAIL you= can abort the TLS connection. > > And my view is that the DANE aware client should look at the RCODE and "t= hrow away" only if the RCODE is NOERROR or NXDOMAIN. I think it would be better to specify client consumption of DNSSEC in terms of RFC 4033 validation states than RCODEs. The validation states have precise meanings and it is easy to reason about their security consequences. The RCODEs have broad and fuzzily specified meanings, and are partially tied to specific implementation behavior. It is not obvious to me, for instance, that a connection abort is appropriate for _all_ possible circumstances that lead to SERVFAIL, whereas IMO it _is_ for RFC4033 "bogus" state. IMO we should say that the client MUST be able to determine the DNSSEC validation state for each RRset, but leave _how_ it does that unspecified. If a client can reliably infer validation state from the RCODEs produced by its local trusted resolver, that's fine. zw From zack.weinberg@gmail.com Mon Nov 21 09:05: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 899E111E80C6 for ; Mon, 21 Nov 2011 09:05:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.894 X-Spam-Level: X-Spam-Status: No, score=-2.894 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 wkCODnnzZJJU for ; Mon, 21 Nov 2011 09:05:41 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id F1B0611E80AA for ; Mon, 21 Nov 2011 09:05:40 -0800 (PST) Received: by vcbfy13 with SMTP id fy13so3276066vcb.31 for ; Mon, 21 Nov 2011 09:05:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=U54X/M/yJlP1gvqyTVC6Hou5Ehk9uH1K6YiklQ3SxUs=; b=rN1FxQuwjwNei3LxuZdSywIPvgNvnoHeyNW2jsu9TzhC8aXLaGGu9a+VbAbSI4VpA5 sy25FB2s1iOYVcYvDgySems1Kjqr+2tn/DNEDK/zLxGw73D2k4obkmYZKpwOQqPmtK/V P/4P+rDLMk7cr9WevQTr2lLzAk2pOMOz/Pm5Y= MIME-Version: 1.0 Received: by 10.182.216.105 with SMTP id op9mr3165891obc.57.1321895140384; Mon, 21 Nov 2011 09:05:40 -0800 (PST) Sender: zack.weinberg@gmail.com Received: by 10.182.88.103 with HTTP; Mon, 21 Nov 2011 09:05:40 -0800 (PST) In-Reply-To: <20111121153528.GK13798@x27.adm.denic.de> References: <45EA694E-096C-41A1-B60E-BF7B3832FE2A@vpnc.org> <20111120163557.GX13798@x27.adm.denic.de> <0FF0603A-11CF-4A3B-BAAD-060FD24231C7@vpnc.org> <20111121153528.GK13798@x27.adm.denic.de> Date: Mon, 21 Nov 2011 09:05:40 -0800 X-Google-Sender-Auth: QUGe5PnM_i94XI2-N-OYMB9UNVI 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] Aiming towards some specific wording X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 21 Nov 2011 17:05:41 -0000 On Mon, Nov 21, 2011 at 7:35 AM, Peter Koch wrote: > > Local policy almost always trumps the protocol spec. So, "can" is unclear > as it could be simply descriptive or half way into a "MAY" or even "SHOUL= D". > What's the intent here? =C2=A0Same for "use": is that "usage" as per sect= ion 2.1.1? I'm going to stick in another plea here that we address the confusing "can be used" / "mark as usable" / "association" terminology _throughout the document_ and in a separate conversation. This conversation is already messy enough. zw From zack.weinberg@gmail.com Mon Nov 21 09:09: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 5925D21F8ACA for ; Mon, 21 Nov 2011 09:09:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.752 X-Spam-Level: X-Spam-Status: No, score=-2.752 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSeVys8y2SiN for ; Mon, 21 Nov 2011 09:09:31 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE9F21F8AB8 for ; Mon, 21 Nov 2011 09:09:31 -0800 (PST) Received: by vbbfc26 with SMTP id fc26so3223208vbb.31 for ; Mon, 21 Nov 2011 09:09:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Rjfq++p/0wAv1sahRyv6J6h6+1EBXql4b3eruv2tSN0=; b=BWHzYCp0v0oZOojS5Xag+d4rBxt7UoCfarVl+kWJg+pFzBwjZlvsQfLf4eCLdH0ISV f0YLvEmcorpLEwk6hg2FDPQgx3gjRse1nzyMycqP5aZG4xFsJ7NKI5tkia0WvNX50JFE 6rHcBUIdp6wJ/c5EhdIG/Q24mZSF+T/E7kkLw= MIME-Version: 1.0 Received: by 10.182.216.105 with SMTP id op9mr3169200obc.57.1321895371075; Mon, 21 Nov 2011 09:09:31 -0800 (PST) Sender: zack.weinberg@gmail.com Received: by 10.182.88.103 with HTTP; Mon, 21 Nov 2011 09:09:31 -0800 (PST) In-Reply-To: References: <4AB082C8-24EE-4105-A50D-0990F42B097D@vpnc.org> Date: Mon, 21 Nov 2011 09:09:31 -0800 X-Google-Sender-Auth: B8ykak4VFjb_Nft0BYss2zJLue8 Message-ID: From: Zack Weinberg To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] Aiming towards some specific wording X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 21 Nov 2011 17:09:32 -0000 On Mon, Nov 21, 2011 at 7:50 AM, Ond=C5=99ej Sur=C3=BD = wrote: > Since we are not requiring the DANE-aware application to include > validating resolver, you cannot really use RFC4033 states here. Yes we can; we just leave how it gets at them unspecified. I do not think we should mention RCODEs or the DNSSEC enable bits _at all_. Please see my other message. zw From warren@kumari.net Mon Nov 21 09:16: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 F392C11E80D2 for ; Mon, 21 Nov 2011 09:16:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.2 X-Spam-Level: X-Spam-Status: No, score=-106.2 tagged_above=-999 required=5 tests=[AWL=-0.201, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvDXeLUow1wV for ; Mon, 21 Nov 2011 09:16:16 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 2274A11E80CC for ; Mon, 21 Nov 2011 09:16:15 -0800 (PST) Received: from dhcp-172-19-119-228.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 5A82A1B40ABC; Mon, 21 Nov 2011 12:16:14 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: Date: Mon, 21 Nov 2011 12:16:12 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <431D9158-63A6-4546-8E74-BFE0DF2FBA72@bbn.com> To: Trevor Freeman X-Mailer: Apple Mail (2.1084) Cc: Adam Langley , "dane@ietf.org" Subject: Re: [dane] Fragility of binding to a CA certificate by certificate or ski X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 21 Nov 2011 17:16:22 -0000 This seems to be the last message in the thread before the CA bashing = started, so forking here.... I am having somewhat of a hard time following this thread -- it seems to = be slightly unclear what *exactly* is being proposed, so I am asking = that, if folk are still interested in this topic, they provided proposed = text[0]. If not, we are dropping it. W [0]: Proposed text suitable for a draft, not inflammatory text couched = in RFCese... On Nov 18, 2011, at 5:15 PM, Trevor Freeman wrote: > Richard, > =20 > Lets get back to the threats because not all certificates are as easy = to generate and be trusted > =20 > Threat > 1. Attacker socially engineers CA to provide a false identity = verification > 2. Attacker gets attack code into CAs environment and generates = end user certificate of their choice > 3. Attacker gets attack code into CA environment and generates a = CA certificate of their choice > 4. Attacker bribes a CA employee to get certificate of their = choice. > =20 > We have seen examples of #1 and #2 with end entity certificates and = they are only partially mitigated by better security and policy = enforcement. > #1 has not so far succeeded with a CA certificate because the checks = are much more extensive. We are typically talking about certificates = which cost tens of thousands of dollars or more each. It=92s not a = simple, paste your request and give us your credit card transaction like = it is for SSL certificates. > #3 has been mitigated by the public CA using path length constraints = for online CAs. This is typical by putting the path length =3D 0 into = the online CAs certificates but sometimes its higher up if the chin is = longer. Pkix validation means no CA certificate issued by a CA with path = length =3D 0 would be trusted. > #4 is still possible but that open up bribes to DNS registrars as = well. > =20 > So given getting an attacker cannot get a CA certificate by #3, we are = left with #1 and #4. Both #1 and #4 are at least one to two orders of = magnitude harder than #2 and both are viable against DNNSEC as well > =20 > Many organizations would accept such a trade for a more robust = deployment. I would not advocate subject name matching for end entity = certificate because of the feasibility of #2, but it is a reasonable = option for a CA certificate. > =20 > Trevor > =20 > -----Original Message----- > From: Richard Barnes [mailto:rbarnes@bbn.com]=20 > Sent: Wednesday, November 16, 2011 10:27 PM > To: Trevor Freeman > Cc: Adam Langley; dane@ietf.org > Subject: Re: [dane] Fragility of binding to a CA certificate by = certificate or ski > =20 > > You description does not match what use type =3D0 > =20 > Sure it does. Let me clarify: > =20 > 1. example.com provisions a DANE record saying that any cert must = chain through "CN=3Dsuper-trusted-ca.com" > =20 > 2. Nefarious attacker generates a CA cert under a well-known TA with = his own key pair and "CN=3Dsuper-trusted-ca.com", and an EE cert under = this CA. > =20 > In that case, the cert matches the type=3D0 constraint, but it's = clearly still bogus. And the client still gets MitM'ed. > =20 > =20 > > It would have been helpful if document somewhere the threats you = want to mitigate, vs. the threats you are not mitigating as it helps = such discussions. > > > > We need clarity around what threats DNSSEC addresses and what value = DANE adds over just DNSSEC. The threats highlighted in 6394 is a DNS = name resolver attack which is intrinsically blocked by DNSSEC. Today, = DNS based attacks are fairly cheap and easy to use. > > > > Getting a bogus EE certificate is a district threat from a CA = certificate. I can stop trust in a CA certificate issued from an = instance of a CA by constraining the path length of the CA certificate = which is what is happening today. This mitigates the threat of an = attacker getting a CA certificate from that CA. > > > > Equally since the relying party is using full pkix validation they = can impose restrictions on the set of certificate policies - which again = make it impossible for any CA to issue a certificate with the right name = and the right policy since the policy is constrained from the root CA = down. > > > > There are these many reasons why when the client tries to validate = the certificate issued by the bogus CA with the same name as published = by DANE, why pkix will reject the certificate path based on the relying = party trust policy. > =20 > So the above attack is not viable if the RP/client imposes path length = constraints on the TAs in its trust store. Are you aware of clients = that actually do this in practice? How do they decide what constraints = to apply, given that they don't know how the CAs they're trusting are = structuring their operations? > =20 > =20 > > You may want to clarity what threats you are anticipating for how = the attacker mounts the mitm attack with DNSSEC since you now have the = right ip addresses.=20 > =20 > For example: > > > =20 > --Richard > =20 > =20 > =20 > =20 > > > > Trevor > > > > > > -----Original Message----- > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > Sent: Thursday, November 17, 2011 9:54 AM > > To: Trevor Freeman > > Cc: Adam Langley; dane@ietf.org > > Subject: Re: [dane] Fragility of binding to a CA certificate by > > certificate or ski > > > > So are you not concerned about the following attack? > > > > 1. example.com provisions a DANE record saying that any cert that > > comes under the CA "CN=3Dsuper-trusted-ca.com" is OK for that domain > > > > 2. Nefarious attacker generates a cert with his own key pair and = "CN=3Dsuper-trusted-ca.com" > > > > 3. Nefarious attacker MitMs a TLS session to example.com and = presents > > his cert > > > > 4. Client looks at the cert, sees the right name, and blissfully > > proceeds with the hijacked session > > > > In light of this, any discussion of binding only to names is = ridiculous. I think this is what Adam was trying to say, a bit more = politely. > > > > --RIchard > > > > > > > > > > On Nov 17, 2011, at 9:31 AM, Trevor Freeman wrote: > > > >> Hi And, > >> > >> Pkix has many controls to control trust in CAs. There are more = controls for trust in CAs certificates than those over end entities. We = are talking about usage type =3D0 so the relying party has full control = over their own pkix policy. > >> > >> I agree that matching SKI is a stronger binding but it is not = necessary more robust if it results in loss of service. It's a much a = business rick determination if the site want to trade higher = availability for a stronger binding. They are best placed to determine = scale of impact from loss of service vs. an active attack. > >> > >> Given we are anticipating a work with DNSSEC, the attacker now has = to obtain a site certificate and compromise some part of the routing = infrastructure for the mark so they can perform address mapping to = redirect the ip traffic to the bogus site. That is not an attack that = scales well but if the CA changes its key and the site did not update = its DNS record, the site is down. > >> > >> Adam, you need to check 5280 section 6. Pkix chaining is name based = not key based. Yes it checks the signatures but SKI\AKI matching is not = used in any way. > >> > >> Matching by subject name presents a strong CA binding mechanism = which is more robust against configuration mismatch - hence delver's = higher availability. > >> > >> Trevor > >> > >> -----Original Message----- > >> From: alangley@gmail.com [mailto:alangley@gmail.com] On Behalf Of > >> Adam Langley > >> Sent: Wednesday, November 16, 2011 11:38 AM > >> To: Trevor Freeman > >> Cc: dane@ietf.org > >> Subject: Re: [dane] Fragility of binding to a CA certificate by > >> certificate or ski > >> > >> On Tue, Nov 15, 2011 at 7:08 AM, Trevor Freeman = wrote: > >>> For usage type =3D0, I am concerned about the fragility of = matching a > >>> CA certificate is only by full certificate or SKI. Certificates = and > >>> keys have an inherently limited lifetime. > >> > >> You are correct that matching by a certificate is a mistake because = CAs often reissue their CA certificates and clients build chains from = the bottom up. > >> > >> However, matching a SubjectPublicKeyInfo is rather robust. = Certainly the leaf certificate cannot change without a site = reconfiguring their servers. That implies that the next certificate's = (call it I1) SPKI is fixed by the leaf (because it has to match the = signature on the leaf). > >> > >> Above that, one could imagine the combination of: > >> * The site fails to include any intermediate certificates > >> * The leaf doesn't include an Authority Key Identifier, but incudes > >> an AIA URL for I1 > >> * I1 is replaced with a certificate with the same SPKI, but a = different issuer. > >> > >> That way the CA could redirect the chain without the site knowing. > >> However, it requires a misconfiguration of the site (that will = cause intermittent issues and some clients to fail completely) and a = grossly stupid CA. > >> > >> On the other hand, specifying via CA Subject name is very weak: any = CA can issue certificates with any Subject name. > >> > >> > >> Cheers > >> > >> AGL > >> > >> -- > >> Adam Langley agl@imperialviolet.org http://www.imperialviolet.org > >> _______________________________________________ > >> 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 paul.hoffman@vpnc.org Mon Nov 21 09:50: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 5166811E80CD for ; Mon, 21 Nov 2011 09:50:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLcXdpqaMrw3 for ; Mon, 21 Nov 2011 09:50:04 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id BA73621F8B1B for ; Mon, 21 Nov 2011 09:50:04 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id pALHeGtx021468 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 21 Nov 2011 10:40:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Apple Message framework v1251.1) From: Paul Hoffman In-Reply-To: <773BAA00-22B9-43A6-BB36-8E3CB6166E38@nic.cz> Date: Mon, 21 Nov 2011 09:40:16 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4B541E04-4A37-4402-AD01-EA95F69C8FB1@vpnc.org> References: <45EA694E-096C-41A1-B60E-BF7B3832FE2A@vpnc.org> <4EC70173.9090106@sv.cmu.edu> <247CAE36-68FB-4048-B07C-9B4C0903434D@vpnc.org> <92AA2445-000C-44CF-8CA5-9796528EA946@checkpoint.com> <0536F82C-346C-4ABE-81E6-3B008219DBD9@kirei.se> <773BAA00-22B9-43A6-BB36-8E3CB6166E38@nic.cz> To: IETF DANE WG list X-Mailer: Apple Mail (2.1251.1) Subject: Re: [dane] Aiming towards some specific wording X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 21 Nov 2011 17:50:05 -0000 On Nov 21, 2011, at 7:02 AM, Ond=C5=99ej Sur=C3=BD wrote: > you can look at the RCODE in the DNS response and if you see SERVFAIL = you can abort the TLS connection. > And my view is that the DANE aware client should look at the RCODE and = "throw away" only if the RCODE is NOERROR or NXDOMAIN. This requires an API that returns an RCODE. Different APIs so far have = returned different things. On Nov 21, 2011, at 7:50 AM, Ond=C5=99ej Sur=C3=BD wrote: > Since we are not requiring the DANE-aware application to include > validating resolver, you cannot really use RFC4033 states here. An API to a validating DNSSEC resolver *can* return the RFC 4033 state; = some of them already do, so saying that "you cannot really use" them is = wrong. You may have a preference for giving the logic based on RCODEs, = but others seem to prefer that we use RFC 4033 language. > Any application using trusted validating resolver will only see > DNS flags (+AD), RCODE and DNS RRSets and it will have to ask > with +DNSSEC OK flag. That's not true: it can also see RFC 4033 state. It is up to this WG to = say what we require from the DNSSEC API. > So we will have to define our own state table, I propose to base > the work on Richard's updated flowchart/state table. >=20 > Our states (from trusted validating resolver): > SECURE - +ADFlag && (RCODE=3DNOERROR || RCODE=3DNXDOMAIN) > BOGUS =3D !(RCODE=3DNOERROR || RCODE=3DNXDOMAIN) > INSECURE =3D -ADFlag To be blunt, I don't see anywhere in our charter that says that this WG = is supposed to do the RCODE-to-4033-state mapping and thus update RFC = 4033 and 4035. One would expect that such a mapping would have come from = the DNSEXT WG, yes? > Then the wording would be: >=20 > o A DNS response for TLSA RRset query whose state is SECURE > can be used for further DANE processing. If the TLSA RRset > is non-empty it can be used for TLS. >=20 > o A DNS response for TLSA RRset query whose state is BOGUS > cause TLS not to be started or, if the TLS negotiation is > already in progress, to cause the connection to be aborted. >=20 > o A DNS response for TLSA RRset query whose state is INSECURE > cannot be used for TLS and must be marked as unusable. That proposed wording is a valid alternative, but only if we know what = the mappings are. I suggest that we do not, and that we are going down a = rat hole by assuming that this WG is supposed to update RFCs 4033 and = 4035. --Paul Hoffman From ondrej.sury@nic.cz Mon Nov 21 10:23: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 3372B11E80DE for ; Mon, 21 Nov 2011 10:23:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.304 X-Spam-Level: X-Spam-Status: No, score=-0.304 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, 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 rX6nU+n27jaj for ; Mon, 21 Nov 2011 10:23:06 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 1A89921F852E for ; Mon, 21 Nov 2011 10:23:00 -0800 (PST) Received: from [IPv6:2001:718:1e03:aed1:bce5:4dd2:3e4:3f28] (unknown [IPv6:2001:718:1e03:aed1:bce5:4dd2:3e4:3f28]) by mail.nic.cz (Postfix) with ESMTPSA id C37E22A0AAD; Mon, 21 Nov 2011 19:22:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1321899778; bh=ta6lISeZ8zCRdbUcMyLkVIYkYvL2y4f7vGQ2WXoRM4E=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=t+RXVhfX7FW6O/chKqt2nP7J2XI99m/BFrvHoYQjrTfimN6f52OyXXTHJqcn16L5f jrkoCZYO6ymv/bZ8+YIrL1QUPvgQT8rEOK0sR+Nk+K7Meuo/Dm9d5uv2Vq9EBd2abj 3bRtcx8SaqEM4YZ1QWGoVsySGC5WhRv38p/02qBI= Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: Date: Mon, 21 Nov 2011 19:22:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4AB082C8-24EE-4105-A50D-0990F42B097D@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1251.1) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: IETF DANE WG list Subject: Re: [dane] Aiming towards some specific wording X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 21 Nov 2011 18:23:11 -0000 I have re-read the RFC403[345] again and I take back my email. The validating resolver has a way how to communicate the secure and = bogus states: This specification only defines how security-aware name servers can signal non-validating stub resolvers that data was found to be bogus (using RCODE=3D2, "Server Failure"; see [RFC4035]). There is a mechanism for security-aware name servers to signal security-aware stub resolvers that data was found to be secure (using the AD bit; see [RFC4035]). (Note: And this can be updated by further RFCs, so we should not really divert from this.) So what about this wording: -- cut here -- Determining whether a TLS certificate association can be used depends on the DNSSEC validation state (as defined in [RFC4033] Section 5). DANE-aware application MUST implement at least security-aware stub resolver (as defined in [RFC4033] Section 2). o A DNS response for TLSA RRset query whose state is Secure can be used for further DANE processing. If the TLSA RRset exists it can be used for TLS. o A DNS response for TLSA RRset query whose state is Bogus cause TLS not to be started or, if the TLS negotiation is already in progress, to cause the connection to be aborted. o A DNS response for TLSA RRset query whose state is not Secure or Bogus cannot be used for TLS and must be marked as unusable. -- cut here -- (Note: I am avoiding the Insecure or Indeterminate to create catch-all rule which will match also all other RCODEs which can be returned by the (validating) resolver.) O. On 21. 11. 2011, at 16:50, Ond=C5=99ej Sur=C3=BD wrote: >=20 > On 20. 11. 2011, at 21:27, Paul Hoffman wrote: >=20 >> [[ New version, incorporating comments from this thread so far. = Please let me know if the specific wording of the proposals is OK, but = not whether you support them. ]] >>=20 >> Greetings again. The recent threads are useful, but some people = change the topic mid-thread so determining what actual words people want = in the draft is difficult. As document co-author, I want to nail down = the words. To do that, the WG needs some choices, and that is the = purpose of this message. I have tried to cast each of the choices = expressed in the past few days in actual text that would appear in the = document. >>=20 >> THIS IS NOT A CALL FOR SUPPORT FOR ANY WORDING!!! This is a call to = be sure that all opinions are given for a LATER CALL. Sorry to use the = ALL CAPS there, but people here tend to vote quickly and then ask for = modifications later. >>=20 >> I propose the following preamble wording to the "interesting" parts = of the wording: >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D PREAMBLE A START =3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D >>=20 >> Determining whether a TLS certificate association can be used depends >> on the DNSSEC validation state (as defined in [RFC4033]). >>=20 >> o A TLS certificate association whose DNSSEC validation state is >> secure can be used for TLS. >>=20 >> o A TLS certificate association whose DNSSEC validation state is >> bogus MUST cause TLS not to be started or, if the TLS negotiation >> is already in progress, to cause the connection to be aborted. >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D PREAMBLE A END =3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D >>=20 >> One of the following, or some other choice, needs to be added to the = preamble. >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONTINUATION 1 START =3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>=20 >> o A TLS certificate association whose DNSSEC validation state is >> indeterminate or insecure cannot be used for TLS and must be marked >> as unusable. >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONTINUATION 1 END =3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Since we are not requiring the DANE-aware application to include > validating resolver, you cannot really use RFC4033 states here. >=20 > Any application using trusted validating resolver will only see > DNS flags (+AD), RCODE and DNS RRSets and it will have to ask > with +DNSSEC OK flag. >=20 > So we will have to define our own state table, I propose to base > the work on Richard's updated flowchart/state table. >=20 > Our states (from trusted validating resolver): > SECURE - +ADFlag && (RCODE=3DNOERROR || RCODE=3DNXDOMAIN) > BOGUS =3D !(RCODE=3DNOERROR || RCODE=3DNXDOMAIN) > INSECURE =3D -ADFlag >=20 > Then the wording would be: >=20 > o A DNS response for TLSA RRset query whose state is SECURE > can be used for further DANE processing. If the TLSA RRset > is non-empty it can be used for TLS. >=20 > o A DNS response for TLSA RRset query whose state is BOGUS > cause TLS not to be started or, if the TLS negotiation is > already in progress, to cause the connection to be aborted. >=20 > o A DNS response for TLSA RRset query whose state is INSECURE > cannot be used for TLS and must be marked as unusable. >=20 > O. >=20 >> ############# OR #################### >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONTINUATION 2 START =3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>=20 >> o A TLS certificate association whose DNSSEC validation state is >> indeterminate or insecure and whose usage is 0 or 1 MAY be used for >> TLS if application marks it as usable. >>=20 >> o A TLS certificate association whose DNSSEC validation state is >> indeterminate or insecure and whose usage is 2 MUST NOT be used for >> TLS and must be marked as unusable. >>=20 >> o Future definitions of new certificate usages MUST include >> specification of whether or not DNSSEC validation is required >> for that usage. >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONTINUATION 2 END =3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > As Warren pointed out the CONTINUATION 2 is out of the charter. >=20 >> Again, PLEASE DO NOT SAY YET WHICH OF THESE YOU SUPPORT. Instead, if = you think the wording in Preamble A, Continuation 1, or Continuation 2 = do not exactly match what you would want in the spec, please propose a = different preamble or continuation text (not just "ideas"). That way, = when we later ask for what wording people want, all proposals will = already be on the table and we will not (again) have wording changes = appear mid-vote. Thanks in advance for your cooperation. >>=20 >> --Paul Hoffman >>=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 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From ondrej.sury@nic.cz Mon Nov 21 10:32: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 756FA1F0C6D for ; Mon, 21 Nov 2011 10:32:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.002 X-Spam-Level: X-Spam-Status: No, score=-1.002 tagged_above=-999 required=5 tests=[AWL=0.698, 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 L-SmYY5QbE-S for ; Mon, 21 Nov 2011 10:32:28 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id BA63B1F0C67 for ; Mon, 21 Nov 2011 10:32:27 -0800 (PST) Received: from [IPv6:2001:718:1e03:aed1:bce5:4dd2:3e4:3f28] (unknown [IPv6:2001:718:1e03:aed1:bce5:4dd2:3e4:3f28]) by mail.nic.cz (Postfix) with ESMTPSA id 037B82A2EE8; Mon, 21 Nov 2011 19:32:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1321900347; bh=so6x1e4unmMFfxWwsmi+NP/B1F+W9jAVY9uROXY+3ZQ=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=CxQVdVzj/RE+kCvcSqWncSkAPXpocwfAsxo97LEMUnf8b3OwfyBjh5EITzlf8424G iY6buQ7x3lsGTXgU9dCfcs0NF9hqQ11JxH4tONTFWaW1Ah0XWeDEQhJxKLzQGeFWZV XTrAYxCI0e3HCeVMI7j2SaIot/5CfiNam5YA0+ro= Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <4B541E04-4A37-4402-AD01-EA95F69C8FB1@vpnc.org> Date: Mon, 21 Nov 2011 19:32:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6CA2C172-4BE7-479C-B305-E454B15EA9FA@nic.cz> References: <45EA694E-096C-41A1-B60E-BF7B3832FE2A@vpnc.org> <4EC70173.9090106@sv.cmu.edu> <247CAE36-68FB-4048-B07C-9B4C0903434D@vpnc.org> <92AA2445-000C-44CF-8CA5-9796528EA946@checkpoint.com> <0536F82C-346C-4ABE-81E6-3B008219DBD9@kirei.se> <773BAA00-22B9-43A6-BB36-8E3CB6166E38@nic.cz> <4B541E04-4A37-4402-AD01-EA95F69C8FB1@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1251.1) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: IETF DANE WG list Subject: Re: [dane] Aiming towards some specific wording X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 21 Nov 2011 18:32:38 -0000 On 21. 11. 2011, at 18:40, Paul Hoffman wrote: > On Nov 21, 2011, at 7:02 AM, Ond=C5=99ej Sur=C3=BD wrote: >=20 >> you can look at the RCODE in the DNS response and if you see SERVFAIL = you can abort the TLS connection. >=20 >> And my view is that the DANE aware client should look at the RCODE = and "throw away" only if the RCODE is NOERROR or NXDOMAIN. >=20 > This requires an API that returns an RCODE. Different APIs so far have = returned different things. We will need such API anyway if you are going to implement = security-aware (stub) resolver. > On Nov 21, 2011, at 7:50 AM, Ond=C5=99ej Sur=C3=BD wrote: >=20 >> Since we are not requiring the DANE-aware application to include >> validating resolver, you cannot really use RFC4033 states here. >=20 > An API to a validating DNSSEC resolver *can* return the RFC 4033 = state; some of them already do, so saying that "you cannot really use" = them is wrong. Right, I was wrong. > You may have a preference for giving the logic based on RCODEs, but = others seem to prefer that we use RFC 4033 language. The "validating resolver" =3D> "security-aware stub resolver" API uses = RCODE=3D2 (Bogus) and +AD flag (Secure). >> Any application using trusted validating resolver will only see >> DNS flags (+AD), RCODE and DNS RRSets and it will have to ask >> with +DNSSEC OK flag. >=20 > That's not true: it can also see RFC 4033 state. It is up to this WG = to say what we require from the DNSSEC API. We need at least security-aware stub resolver. We can ask for: 1. non-validating security-aware stub resolver (+DO) 2. validating security-aware stub resolver (+DO +CD) >> So we will have to define our own state table, I propose to base >> the work on Richard's updated flowchart/state table. >>=20 >> Our states (from trusted validating resolver): >> SECURE - +ADFlag && (RCODE=3DNOERROR || RCODE=3DNXDOMAIN) >> BOGUS =3D !(RCODE=3DNOERROR || RCODE=3DNXDOMAIN) >> INSECURE =3D -ADFlag >=20 > To be blunt, I don't see anywhere in our charter that says that this = WG is supposed to do the RCODE-to-4033-state mapping and thus update RFC = 4033 and 4035. One would expect that such a mapping would have come from = the DNSEXT WG, yes? True, disregard what I wrote there. 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 marka@isc.org Mon Nov 21 13: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 B7DAE21F8ADC; Mon, 21 Nov 2011 13:13:45 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc" X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, 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 U1o6Z8TpOiqR; Mon, 21 Nov 2011 13:13:45 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 344E221F8AD9; Mon, 21 Nov 2011 13:13:45 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 296015F98B6; Mon, 21 Nov 2011 21:13:18 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 8F479216C6B; Mon, 21 Nov 2011 21:13:16 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 6692917DB0E8; Tue, 22 Nov 2011 08:13:12 +1100 (EST) To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= From: Mark Andrews References: <45EA694E-096C-41A1-B60E-BF7B3832FE2A@vpnc.org> <4EC70173.9090106@sv.cmu.edu> <247CAE36-68FB-4048-B07C-9B4C0903434D@vpnc.org> <92AA2445-000C-44CF-8CA5-9796528EA946@checkpoint.com> <0536F82C-346C-4ABE-81E6-3B008219DBD9@kirei.se> <773BAA00-22B9-43A6-BB36-8E3CB6166E38@nic.cz> <4B541E04-4A37-4402-AD01-EA95F69C8FB1@vpnc.org> <6CA2C172-4BE7-479C-B305-E454B15EA9FA@nic.cz> In-reply-to: Your message of "Mon, 21 Nov 2011 19:32:26 BST." <6CA2C172-4BE7-479C-B305-E454B15EA9FA@nic.cz> Date: Tue, 22 Nov 2011 08:13:12 +1100 Message-Id: <20111121211312.6692917DB0E8@drugs.dv.isc.org> Cc: dnsext@ietf.org, Paul Hoffman , IETF DANE WG list Subject: Re: [dane] Aiming towards some specific wording X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dnsext@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 21:13:45 -0000 The only difference between "insecure" and "indeterminate" is that there was a TA configured somewhere above the name and there is a insecure delegation between that TA and data. We don't actually prove that something is insecure. We prove that there is not a secure path to the data. If you don't have a TA you do not have a secure path to the data. If you have a TA but a insecure delegation you do not have a secure path to the data. In both case the data could be signed or unsigned. "insecure" and "indeterminate" zones are logically the same. Dane should just treat them as !secure. Dnsext should fix the DNSSEC RFC's to get rid of one or other of them as having two terms for the same thing is pointless. Reply-to set to dnsext@ietf.org Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From paul.hoffman@vpnc.org Mon Nov 21 13:28: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 D661511E80FD for ; Mon, 21 Nov 2011 13:28:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttwRCvK9Ay3m for ; Mon, 21 Nov 2011 13:28:58 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE2411E80FC for ; Mon, 21 Nov 2011 13:28:58 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id pALLSvEU029526 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 21 Nov 2011 14:28:58 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Paul Hoffman In-Reply-To: <20111121211312.6692917DB0E8@drugs.dv.isc.org> Date: Mon, 21 Nov 2011 13:28:57 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <38DA1A4E-3BD6-4F82-910F-BD86E0C5B740@vpnc.org> References: <45EA694E-096C-41A1-B60E-BF7B3832FE2A@vpnc.org> <4EC70173.9090106@sv.cmu.edu> <247CAE36-68FB-4048-B07C-9B4C0903434D@vpnc.org> <92AA2445-000C-44CF-8CA5-9796528EA946@checkpoint.com> <0536F82C-346C-4ABE-81E6-3B008219DBD9@kirei.se> <773BAA00-22B9-43A6-BB36-8E3CB6166E38@nic.cz> <4B541E04-4A37-4402-AD01-EA95F69C8FB1@vpnc.org> <6CA2C172-4BE7-479C-B305-E454B15EA9FA@nic.cz> <20111121211312.6692917DB0E8@drugs.dv.isc.org> To: IETF DANE WG list X-Mailer: Apple Mail (2.1251.1) Subject: Re: [dane] Aiming towards some specific wording X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 21 Nov 2011 21:28:58 -0000 On Nov 21, 2011, at 1:13 PM, Mark Andrews wrote: > "insecure" and "indeterminate" zones are logically the same. Dane > should just treat them as !secure. I can't tell if you are just commenting or are about to suggest = different wording for the proposal. I believe the current wording treats = them the same, and the current wording treats them as not secure. --Paul Hoffman From matt@mattmccutchen.net Mon Nov 21 20:11: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 7A8DF21F886A; Mon, 21 Nov 2011 20:11:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8a3-zA-9yM2k; Mon, 21 Nov 2011 20:10:55 -0800 (PST) Received: from homiemail-a3.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 4845A21F86D0; Mon, 21 Nov 2011 20:10:55 -0800 (PST) Received: from homiemail-a3.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a3.g.dreamhost.com (Postfix) with ESMTP id 31A0A28408C; Mon, 21 Nov 2011 20:10:46 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=message-id :subject:from:to:cc:in-reply-to:references:content-type:date :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=Mux7HzYkwPCXbebarPq4KixxBiP/W/fFpdmGCS5wVp0 ZeO3O+NvGYxFXxpUqm04S3XY1Yutc1pP4vUt64+i5wGZ0DvoeY/EVwnR8ccLQd9i 8B/7fhRVY0CNLpUT+pdrgZ7AziLOmbQiCltjjR3XZGCX/9pB2a4Jfx8OT77t7wYU = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= message-id:subject:from:to:cc:in-reply-to:references :content-type:date:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=dhFD+q1cfo7K4aL3T1SiNzPFrzM=; b=LAiyhUf73s siziapGe3baYrTcnpOS0+aKIwBt2MWKDWsl0lzal8Z91yymFIAauGRYzLDeKbrjO govRrn8SBKbda9EXnchCEMxpNhGSN6VTzpjTEMxgy7AR1NSRIabd6WCTvgtKl4mg UTIhdm9yYv2O5kBHsZ5cuhvBfLZB2jSE0= 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-a3.g.dreamhost.com (Postfix) with ESMTPSA id F111C284081; Mon, 21 Nov 2011 20:10:45 -0800 (PST) Message-ID: <1321935016.1657.19.camel@mattlaptop2.local> From: Matt McCutchen To: dane@ietf.org, dnsext@ietf.org In-Reply-To: References: <45EA694E-096C-41A1-B60E-BF7B3832FE2A@vpnc.org> <4EC70173.9090106@sv.cmu.edu> <247CAE36-68FB-4048-B07C-9B4C0903434D@vpnc.org> <92AA2445-000C-44CF-8CA5-9796528EA946@checkpoint.com> <0536F82C-346C-4ABE-81E6-3B008219DBD9@kirei.se> <773BAA00-22B9-43A6-BB36-8E3CB6166E38@nic.cz> <4B541E04-4A37-4402-AD01-EA95F69C8FB1@vpnc.org> <6CA2C172-4BE7-479C-B305-E454B15EA9FA@nic.cz> <20111121211312.6692917DB0E8@drugs.dv.isc.org> Content-Type: text/plain; charset="UTF-8" Date: Mon, 21 Nov 2011 20:10:16 -0800 Mime-Version: 1.0 X-Mailer: Evolution 3.2.3 Content-Transfer-Encoding: 7bit Cc: Edward Lewis , Paul Hoffman Subject: Re: [dane] [dnsext] Aiming towards some specific wording X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 22 Nov 2011 04:11:00 -0000 On Mon, 2011-11-21 at 16:28 -0500, Edward Lewis wrote: > Answering only to DNSEXT... > > > At 8:13 +1100 11/22/11, Mark Andrews wrote: > >"insecure" and "indeterminate" zones are logically the same. Dane > >should just treat them as !secure. > > No, they are not the same. > > Insecure means I get records indicating there's no possible trust > chain that can be constructed from the data to anything I have. > > Indeterminate means when I try to get records for part of the chain I > "time-out". ("No servers could be reached.") > > There's a significant semantic difference between the two. Apart from > the fact that you won't succeed in constructing a chain, "insecure" > means it is definitively impossible and "indeterminate" means "not > with the data at hand, at this time." The former would be data that > is not protected, the latter could be declared a service failure. > > Here's the definition in RFC 4035 I'm pointing to: > > 4.3. Determining Security Status of Data > ... > Indeterminate: An RRset for which the resolver is not able to > determine whether the RRset should be signed, as the resolver is > not able to obtain the necessary DNSSEC RRs. This can occur > when > the security-aware resolver is not able to contact > security-aware > name servers for the relevant zones. That's great, RFC 4035 has a totally different definition of "indeterminate" than RFC 4033. RFC 4033 "indeterminate" is equivalent to "insecure" for DANE's purpose and likely other purposes as well. RFC 4035 "indeterminate" is not a separate group of cases; those cases are better described as "SERVFAIL", or possibly "bogus" if the resolver successfully retrieves the target RRset (but not the DNSSEC RRs). Ultimately, DANE needs three cases: 1. Secure: Process the RRset. 2. Insecure or RFC 4033 indeterminate: Fall back to pre-DANE behavior, or (maybe -- under discussion) process the restrictive part of the assertion without the additive part. 3. Bogus or query failed (RCODE other than NOERROR or NXDOMAIN, no response from DNS servers, etc.): Fail closed. -- Matt From ajs@anvilwalrusden.com Tue Nov 22 06:46: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 CD93321F8E2C for ; Tue, 22 Nov 2011 06:46:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.049, 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 QQXHtEU8NdKE for ; Tue, 22 Nov 2011 06:46:52 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 52E1921F8E29 for ; Tue, 22 Nov 2011 06:46:52 -0800 (PST) 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 605A51ECB41D for ; Tue, 22 Nov 2011 14:46:37 +0000 (UTC) Date: Tue, 22 Nov 2011 09:46:46 -0500 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20111122144646.GA7661@shinkuro.com> References: <45EA694E-096C-41A1-B60E-BF7B3832FE2A@vpnc.org> <4ECA7393.9060101@ogud.com> 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] Aiming towards some specific wording X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 22 Nov 2011 14:46:52 -0000 On Mon, Nov 21, 2011 at 08:57:40AM -0800, Zack Weinberg wrote: > On Mon, Nov 21, 2011 at 7:51 AM, Olafur Gudmundsson wrote: > > What that means is that bogus, proof-ably insecure, undetermined etc. are > > all outside the scope of this document. > > This is not acceptable to me. Most importantly, the behavior for > "bogus" _must_ be specified in the initial protocol document, or we > will be leaving security holes in a security mechanism. And I do not What is the hole in what Olafur proposed? "MUST be DNSSEC validatable" entails "MUST NOT use the record when it cannot be validated". There are only two relevant states under that formulation: validatable and everything else. "Bogus" is in the "everything else" category. Under this suggestion, it's exactly as unusable as TLSA that is not secured. I don't see where the hole. A -- Andrew Sullivan ajs@anvilwalrusden.com From rbarnes@bbn.com Tue Nov 22 07:14: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 C86F121F8E67 for ; Tue, 22 Nov 2011 07:14:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.552 X-Spam-Level: X-Spam-Status: No, score=-106.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wne+paZni1q5 for ; Tue, 22 Nov 2011 07:14:50 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 210FC21F8E65 for ; Tue, 22 Nov 2011 07:14:50 -0800 (PST) Received: from [192.1.255.200] (port=58908 helo=col-dhcp-192-1-255-200.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RSs3c-000MHc-Sn; Tue, 22 Nov 2011 10:14:48 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <20111122144646.GA7661@shinkuro.com> Date: Tue, 22 Nov 2011 10:14:47 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <45EA694E-096C-41A1-B60E-BF7B3832FE2A@vpnc.org> <4ECA7393.9060101@ogud.com> <20111122144646.GA7661@shinkuro.com> To: Andrew Sullivan X-Mailer: Apple Mail (2.1084) Cc: dane@ietf.org Subject: Re: [dane] Aiming towards some specific wording X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 22 Nov 2011 15:14:50 -0000 On Nov 22, 2011, at 9:46 AM, Andrew Sullivan wrote: > On Mon, Nov 21, 2011 at 08:57:40AM -0800, Zack Weinberg wrote: >> On Mon, Nov 21, 2011 at 7:51 AM, Olafur Gudmundsson = wrote: >>> What that means is that bogus, proof-ably insecure, undetermined = etc. are >>> all outside the scope of this document. >>=20 >> This is not acceptable to me. Most importantly, the behavior for >> "bogus" _must_ be specified in the initial protocol document, or we >> will be leaving security holes in a security mechanism. And I do not >=20 > What is the hole in what Olafur proposed? "MUST be DNSSEC > validatable" entails "MUST NOT use the record when it cannot be > validated". There are only two relevant states under that > formulation: validatable and everything else. "Bogus" is in the > "everything else" category. Under this suggestion, it's exactly as > unusable as TLSA that is not secured. I don't see where the hole. I think people want to use both positive and negative DNSSEC state = (secure and bogus). If secure, then you get additional assurance. If = bogus, then something's gone wrong and you need to fail. =20 Your/Olafur's suggestion covers the secure case, but lumps bogus in with = insecure/indeterminate. Do you think that there's a reason to ignore = the negative/bogus case? --Ricahrd From paul.hoffman@vpnc.org Tue Nov 22 08:20: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 4FAAE1F0CB5 for ; Tue, 22 Nov 2011 08:20:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 8A0fRdMBHVYb for ; Tue, 22 Nov 2011 08:20:09 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 65CAA1F0CB0 for ; Tue, 22 Nov 2011 08:20:09 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id pAMGA4PK069718 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 22 Nov 2011 09:10:05 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Tue, 22 Nov 2011 08:10:05 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <45EA694E-096C-41A1-B60E-BF7B3832FE2A@vpnc.org> <4ECA7393.9060101@ogud.com> <20111122144646.GA7661@shinkuro.com> To: "Richard L. Barnes" X-Mailer: Apple Mail (2.1251.1) Cc: dane@ietf.org Subject: Re: [dane] Aiming towards some specific wording X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 22 Nov 2011 16:20:10 -0000 On Nov 22, 2011, at 7:14 AM, Richard L. Barnes wrote: > Your/Olafur's suggestion covers the secure case, but lumps bogus in = with insecure/indeterminate. Do you think that there's a reason to = ignore the negative/bogus case? Which part of the "please don't voice an opinion yet" are you = forgetting? :-) I am hearing a desire that we split out the processing of "bogus". Some = folks want it to cause TLS termination, others want it just to not count = as anything. I have added this to the list of choices. --Paul Hoffman From mrex@sap.com Tue Nov 22 12:29: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 9C4291F0C4A for ; Tue, 22 Nov 2011 12:29:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.124 X-Spam-Level: X-Spam-Status: No, score=-10.124 tagged_above=-999 required=5 tests=[AWL=0.125, 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 z6iO6mg+QGHt for ; Tue, 22 Nov 2011 12:29:48 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id DF6EB1F0C35 for ; Tue, 22 Nov 2011 12:29:47 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id pAMKTeH1010111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 22 Nov 2011 21:29:40 +0100 (MET) From: Martin Rex Message-Id: <201111222029.pAMKTdoi028355@fs4113.wdf.sap.corp> To: hallam@gmail.com (Phillip Hallam-Baker) Date: Tue, 22 Nov 2011 21:29:39 +0100 (MET) In-Reply-To: from "Phillip Hallam-Baker" at Nov 18, 11 10:48:54 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: agl@imperialviolet.org, dane@ietf.org Subject: Re: [dane] Fragility of PKIX path discovery 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, 22 Nov 2011 20:29:48 -0000 Trevor Freeman wrote: > > Pkix validation means no CA certificate issued by a CA > with path length = 0 would be trusted. http://tools.ietf.org/html/rfc5280#section-4.2.1.9 A pathLenConstraint of zero indicates that no non-self-issued intermediate CA certificates may follow in a valid certification path. A self-issued CA cert would be just fine for an attacker. Hallam-Baker wrote: > > People screw up the implementation of all crypto code. Some people will > screw up the implementation of DANE as well, if you are lucky enough for > people to implement it. Trevor assumptions rely on a very specific form of PKIX NON-compliance. That is not to be recommended. -Martin From ajs@anvilwalrusden.com Tue Nov 22 12:35: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 8211411E80CC for ; Tue, 22 Nov 2011 12:35:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, 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 EN3rJ6ZopYWZ for ; Tue, 22 Nov 2011 12:35:23 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 0CAFB11E80C8 for ; Tue, 22 Nov 2011 12:35:22 -0800 (PST) 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 0A94F1ECB41D for ; Tue, 22 Nov 2011 20:35:07 +0000 (UTC) Date: Tue, 22 Nov 2011 15:35:21 -0500 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20111122203521.GP7661@shinkuro.com> References: <45EA694E-096C-41A1-B60E-BF7B3832FE2A@vpnc.org> <4ECA7393.9060101@ogud.com> <20111122144646.GA7661@shinkuro.com> 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] Aiming towards some specific wording X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 22 Nov 2011 20:35:23 -0000 On Tue, Nov 22, 2011 at 10:14:47AM -0500, Richard L. Barnes wrote: > > > I think people want to use both positive and negative DNSSEC state (secure and bogus). If secure, then you get additional assurance. If bogus, then something's gone wrong and you need to fail. > And then what do you do if indeterminate &c? I don't understand how that isn't "still fail", which is I think what Olafur was saying. > Your/Olafur's suggestion covers the secure case, but lumps bogus in with insecure/indeterminate. Do you think that there's a reason to ignore the negative/bogus case? > I don't know. I don't know what _else_ you're going to do except not proceed when you can't validate the answer. (Note that this is different from the general DNS case: we're explicitly trying to use this to bootstrap TLS, so if you're not able to validate that the TLSA RR you got is legit, it seems to me to be a bad idea to keep going.) A -- Andrew Sullivan ajs@anvilwalrusden.com From mrex@sap.com Tue Nov 22 13:04: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 B31DE11E80B4 for ; Tue, 22 Nov 2011 13:04:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.125 X-Spam-Level: X-Spam-Status: No, score=-10.125 tagged_above=-999 required=5 tests=[AWL=0.124, 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 7e5Q207hfnwm for ; Tue, 22 Nov 2011 13:04:40 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id E1D0211E80A4 for ; Tue, 22 Nov 2011 13:04:39 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id pAML4YAN013637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 22 Nov 2011 22:04:34 +0100 (MET) From: Martin Rex Message-Id: <201111222104.pAML4Xxh000274@fs4113.wdf.sap.corp> To: warren@kumari.net (Warren Kumari) Date: Tue, 22 Nov 2011 22:04:33 +0100 (MET) In-Reply-To: from "Warren Kumari" at Nov 21, 11 12:16:12 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: agl@imperialviolet.org, dane@ietf.org Subject: Re: [dane] Fragility of binding to a CA certificate by 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: Tue, 22 Nov 2011 21:04:40 -0000 Warren Kumari wrote: > > This seems to be the last message in the thread before > the CA bashing started, so forking here.... > > I am having somewhat of a hard time following this thread -- it seems > to be slightly unclear what *exactly* is being proposed, so I am asking > that, if folk are still interested in this topic, they provided > proposed text[0]. If not, we are dropping it. Trevor said that PKIX CA certs can not be reliably identified with a certificate hash for TLSA usage type 0. I agree with this observation. There are a *some* TLS peers that do perform certificate path discovery when processing the peers Certificate handshake message. While this is clearly not something that the TLS spec suggests, it is something that a number of PKIX folks *want* to happen. AFAIK, Microsoft's SChannel does it and Opera does it. So DANE inevitably will have to account for it. PKIX cert path discovery may cause *any* and all except the end-entity cert conveyed by Certificate handshake message to be replaced by CA certs with a different lifetime or arbitrary cross-CA certs before entering the PKIX certificate path validation algorithm. If TLSA usage type 0 tries to match the certificate hash of a CA cert that has passed PKIX certificate path validation, it may no longer find that CA cert in that path, even though it was conveyed in the forward path of the Certificate handshake message. Matching of the end-entity cert (TLSA usage type 1) does not have that problem, and TLSA usage type 0 when limited to the spki (subject public key info) of the CA that directly signed the TLS servers certificate would also not have such a problem -- and both are reliably predictable by the TLS server admin. Trying to cling to a specific CA cert seems to interfere with PKIX design and CA operations. Intermediate CA certs of commercial CAs usually have a shorter lifetime. In case they're renewed (same keypair, same Subject, new lifetime) rather than moving to a different CA cert (new keypair, new Subject, new lifetime), the distribution of the renewed intermediate CA cert to RPs and its use during PKIX certificate path validation will be non-predictable to the server admin. Use of cross-certification rather than acceptance of seperate trust anchor by a fraction of the TLS clients can also lead to the use of CA (cross-)certs in a path that the TLS server admin can hardly predict. -Martin From rbarnes@bbn.com Tue Nov 22 16:55: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 B73221F0C4D for ; Tue, 22 Nov 2011 16:55:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.577 X-Spam-Level: X-Spam-Status: No, score=-106.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 3d6twe6y9ELM for ; Tue, 22 Nov 2011 16:55:47 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 4410C1F0C4F for ; Tue, 22 Nov 2011 16:55:47 -0800 (PST) Received: from [128.89.255.85] (port=60340 helo=[192.168.1.4]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RT17p-000GeH-Gv; Tue, 22 Nov 2011 19:55:45 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <20111122203521.GP7661@shinkuro.com> Date: Tue, 22 Nov 2011 19:55:44 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <9D06941A-D84D-47D9-A4F8-6C40B9D2BEE5@bbn.com> References: <45EA694E-096C-41A1-B60E-BF7B3832FE2A@vpnc.org> <4ECA7393.9060101@ogud.com> <20111122144646.GA7661@shinkuro.com> <20111122203521.GP7661@shinkuro.com> To: Andrew Sullivan X-Mailer: Apple Mail (2.1084) Cc: dane@ietf.org Subject: Re: [dane] Aiming towards some specific wording X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 00:55:47 -0000 >> I think people want to use both positive and negative DNSSEC state = (secure and bogus). If secure, then you get additional assurance. If = bogus, then something's gone wrong and you need to fail. =20 >>=20 >=20 > And then what do you do if indeterminate &c? I don't understand how > that isn't "still fail", which is I think what Olafur was saying. Going back to Olafur's original email: "The consumer application falls back to the processing it is currently = doing" So the three behaviors would be: 1. Certificate passes validation (secure && match)=20 =3D> Proceed with connection, any other certificate checks 2. Certificate fails validation (bogus || (secure && !match)) =3D> Fail connection 3. Validation provides no information =3D> Decide based on other processing (as you would if DANE didn't = exist) >> Your/Olafur's suggestion covers the secure case, but lumps bogus in = with insecure/indeterminate. Do you think that there's a reason to = ignore the negative/bogus case? >>=20 >=20 > I don't know. I don't know what _else_ you're going to do except not > proceed when you can't validate the answer. (Note that this is = different from the general DNS case: we're explicitly trying to use this = to bootstrap TLS, so if you're not able to validate that the TLSA RR you = got is legit, it seems to me to be a bad idea to keep going.) I think that that's probably too strong, and would cause problems with = incremental deployment. But I may still be under the influence of jet = lag from TPE. --Richard= From ajs@anvilwalrusden.com Tue Nov 22 19:02: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 F307F1F0C59 for ; Tue, 22 Nov 2011 19:02:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 rsw0g6+snB1x for ; Tue, 22 Nov 2011 19:02:37 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 137361F0C4F for ; Tue, 22 Nov 2011 19:02:36 -0800 (PST) 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 E85DF1ECB41D for ; Wed, 23 Nov 2011 03:02:20 +0000 (UTC) Date: Tue, 22 Nov 2011 22:02:27 -0500 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20111123030227.GA11820@shinkuro.com> References: <45EA694E-096C-41A1-B60E-BF7B3832FE2A@vpnc.org> <4ECA7393.9060101@ogud.com> <20111122144646.GA7661@shinkuro.com> <20111122203521.GP7661@shinkuro.com> <9D06941A-D84D-47D9-A4F8-6C40B9D2BEE5@bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9D06941A-D84D-47D9-A4F8-6C40B9D2BEE5@bbn.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Aiming towards some specific wording X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 03:02:38 -0000 On Tue, Nov 22, 2011 at 07:55:44PM -0500, Richard L. Barnes wrote: > > So the three behaviors would be: > 1. Certificate passes validation (secure && match) > => Proceed with connection, any other certificate checks > 2. Certificate fails validation (bogus || (secure && !match)) > => Fail connection > 3. Validation provides no information > => Decide based on other processing (as you would if DANE didn't exist) I think I get it. The idea is that the bigus state (or the validated non-matching state) is positive evidence _not_ to proceed, but "no information" doesn't do that. I think I can construct an argument why that isn't wrong, although the slightly dodgy part is going to be explaining why (2) doesn't also lead to "fallback" (I believe I can construct such an argument, it just seems the weakest part to me). So I can see why this option is still on the table. Thanks! A -- Andrew Sullivan ajs@anvilwalrusden.com From zack.weinberg@gmail.com Tue Nov 22 19:36: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 1686311E80D6 for ; Tue, 22 Nov 2011 19:36:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.895 X-Spam-Level: X-Spam-Status: No, score=-2.895 tagged_above=-999 required=5 tests=[AWL=0.082, 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 DjwxXEzdRRgQ for ; Tue, 22 Nov 2011 19:36:44 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 737CE11E8088 for ; Tue, 22 Nov 2011 19:36:44 -0800 (PST) Received: by ggnp4 with SMTP id p4so1105481ggn.31 for ; Tue, 22 Nov 2011 19:36:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=D4vuaJgFhjc4gq6jWi6oheqFGahm5F3tec3O/1efvFQ=; b=KGZH3tGV0ml4Q3mWUqrDKrIKYtYgCuWmwvZ+27wV1xbGirrfmxLRyiY9RONqpZpqxY GiClPDHNHMp5ET8+0MKbXD2ch6W8n8+oj7SZMrdjA5xvCTk6bN57ykRsHzWENfMSJ8cj S+M8ZaG/TdVuKLdHnRcgZyBK2XvBlcCVMINuA= MIME-Version: 1.0 Received: by 10.182.59.49 with SMTP id w17mr8041011obq.37.1322019404070; Tue, 22 Nov 2011 19:36:44 -0800 (PST) Sender: zack.weinberg@gmail.com Received: by 10.182.88.103 with HTTP; Tue, 22 Nov 2011 19:36:43 -0800 (PST) In-Reply-To: <20111123030227.GA11820@shinkuro.com> References: <45EA694E-096C-41A1-B60E-BF7B3832FE2A@vpnc.org> <4ECA7393.9060101@ogud.com> <20111122144646.GA7661@shinkuro.com> <20111122203521.GP7661@shinkuro.com> <9D06941A-D84D-47D9-A4F8-6C40B9D2BEE5@bbn.com> <20111123030227.GA11820@shinkuro.com> Date: Tue, 22 Nov 2011 19:36:43 -0800 X-Google-Sender-Auth: zd_txL7LBAK47U7V5lyLIvFuGdM Message-ID: From: Zack Weinberg To: Andrew Sullivan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: dane@ietf.org Subject: Re: [dane] Aiming towards some specific wording X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 03:36:45 -0000 On Tue, Nov 22, 2011 at 7:02 PM, Andrew Sullivan w= rote: > I think I get it. =C2=A0The idea is that the bigus state (or the validate= d > non-matching state) is positive evidence _not_ to proceed, but "no > information" doesn't do that. > > I think I can construct an argument why that isn't wrong, although the > slightly dodgy part is going to be explaining why (2) doesn't also > lead to "fallback" (I believe I can construct such an argument, it > just seems the weakest part to me). =C2=A0So I can see why this option is > still on the table. There are concrete attacks that would be possible if (2) led to fallback rather than a connection abort. For instance, quoting my earlier message to Paul H: Suppose the standard man-in-the-middle attacker on TLS, in possession of an illegitimate certificate for the site being MITMed, that would nonetheless be accepted by the client in the absence of DANE information. Suppose further that this attacker is able to block entire DNS queries but not tamper with their contents. They allow the A record query to go through and come back unmolested (they don't need to change the apparent address of the server to intercept traffic) but they block the TLSA query. This absence of response is DNSSEC-"bogus", because you didn't get an NSEC(3) to prove that there are no TLSA records. If you abort the connection, the attacker loses. If you fall back to non-DANE behavior, the attacker wins. zw From ajs@anvilwalrusden.com Tue Nov 22 20:07: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 216841F0C4F for ; Tue, 22 Nov 2011 20:07:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 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 cDizDcs4I-Yf for ; Tue, 22 Nov 2011 20:07:56 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 911A71F0C71 for ; Tue, 22 Nov 2011 20:07:56 -0800 (PST) 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 86F4C1ECB41D for ; Wed, 23 Nov 2011 04:07:41 +0000 (UTC) Date: Tue, 22 Nov 2011 23:07:53 -0500 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20111123040753.GE11820@shinkuro.com> References: <45EA694E-096C-41A1-B60E-BF7B3832FE2A@vpnc.org> <4EC70173.9090106@sv.cmu.edu> <247CAE36-68FB-4048-B07C-9B4C0903434D@vpnc.org> <4EC7F701.4080006@panix.com> 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] Fwd: Aiming towards some specific wording X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 04:07:57 -0000 On Sun, Nov 20, 2011 at 08:22:11AM -0800, Zack Weinberg wrote: > (If the attacker can rewrite DNS responses, they can downgrade you to an > absence of DNSSEC all the way to the root No, they can't. You will fail the . validation at the last step, and everything is bogus. A -- Andrew Sullivan ajs@anvilwalrusden.com From zack.weinberg@gmail.com Tue Nov 22 20:18: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 973A51F0C52 for ; Tue, 22 Nov 2011 20:18:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.902 X-Spam-Level: X-Spam-Status: No, score=-2.902 tagged_above=-999 required=5 tests=[AWL=0.075, 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 r3vIi5DHutNd for ; Tue, 22 Nov 2011 20:18:40 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0841F0C4F for ; Tue, 22 Nov 2011 20:18:40 -0800 (PST) Received: by ywt34 with SMTP id 34so1095302ywt.31 for ; Tue, 22 Nov 2011 20:18:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=M+TUD1JrahoQ55ZaPpYgsHVZETZqXRztF+IFXp85gLE=; b=BomgEQWHNBNZJQdt0RgvIhrhgb0IiLqEh0N/d1AuxIDoNuGrV8znDcFQ+ZUIaJLdCW PTeQqg3Slzt/q8uyyw1WXX6XkCEiXielPZ7xpFaz5Lfe63RRzZNrSfsp9zVvX8cIQg3T kwZcV14eVd30hXlcmlbsSxw9QaC3kTgbgA5pI= MIME-Version: 1.0 Received: by 10.182.59.49 with SMTP id w17mr8064929obq.37.1322021919683; Tue, 22 Nov 2011 20:18:39 -0800 (PST) Sender: zack.weinberg@gmail.com Received: by 10.182.88.103 with HTTP; Tue, 22 Nov 2011 20:18:39 -0800 (PST) In-Reply-To: <20111123040753.GE11820@shinkuro.com> References: <45EA694E-096C-41A1-B60E-BF7B3832FE2A@vpnc.org> <4EC70173.9090106@sv.cmu.edu> <247CAE36-68FB-4048-B07C-9B4C0903434D@vpnc.org> <4EC7F701.4080006@panix.com> <20111123040753.GE11820@shinkuro.com> Date: Tue, 22 Nov 2011 20:18:39 -0800 X-Google-Sender-Auth: YbQthn7ubHWuoLvr7ufrZXdtrr0 Message-ID: From: Zack Weinberg To: Andrew Sullivan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: dane@ietf.org Subject: Re: [dane] Fwd: Aiming towards some specific wording X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 04:18:40 -0000 On Tue, Nov 22, 2011 at 8:07 PM, Andrew Sullivan w= rote: > On Sun, Nov 20, 2011 at 08:22:11AM -0800, Zack Weinberg wrote: > >> (If the attacker can rewrite DNS responses, they can downgrade you to an >> absence of DNSSEC all the way to the root > > No, they can't. =C2=A0You will fail the . validation at the last step, an= d > everything is bogus. I guess I'm assuming that a DNSSEC-validating client that sees a complete absence of DNSSEC records in the responses it gets with +AD is going to assume a "harmless" failure of some middlebox to pass the records, and fall back to non-validating behavior, rather than treat everything as bogus. Behaving like that does open a large avenue for exploits that I hope can be closed as soon as possible, but I suspect "as soon as possible" is not for at least a few years... zw From mrex@sap.com Tue Nov 22 20:34: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 0D42A11E80D4 for ; Tue, 22 Nov 2011 20:34:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.669 X-Spam-Level: X-Spam-Status: No, score=-9.669 tagged_above=-999 required=5 tests=[AWL=-0.335, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qm4yHuCrCMjd for ; Tue, 22 Nov 2011 20:34:24 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id D6BD611E80BC for ; Tue, 22 Nov 2011 20:34:23 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id pAN4YEW9016488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Nov 2011 05:34:19 +0100 (MET) From: Martin Rex Message-Id: <201111230434.pAN4YDrd026150@fs4113.wdf.sap.corp> To: zack.weinberg@sv.cmu.edu (Zack Weinberg) Date: Wed, 23 Nov 2011 05:34:13 +0100 (MET) In-Reply-To: from "Zack Weinberg" at Nov 22, 11 07:36:43 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] Aiming towards some specific wording 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, 23 Nov 2011 04:34:25 -0000 Zack Weinberg wrote: > > On Tue, Nov 22, 2011 at 7:02 PM, Andrew Sullivan wrote: > > I think I get it.  The idea is that the bigus state (or the validated > > non-matching state) is positive evidence _not_ to proceed, but "no > > information" doesn't do that. > > > > I think I can construct an argument why that isn't wrong, although the > > slightly dodgy part is going to be explaining why (2) doesn't also > > lead to "fallback" (I believe I can construct such an argument, it > > just seems the weakest part to me).  So I can see why this option is > > still on the table. > > There are concrete attacks that would be possible if (2) led to > fallback rather than a connection abort. > > For instance, quoting my earlier message to Paul H: Suppose the > standard man-in-the-middle attacker on TLS, in possession of an > illegitimate certificate for the site being MITMed, that would > nonetheless be accepted by the client in the absence of DANE > information. Suppose further that this attacker is able to block > entire DNS queries but not tamper with their contents. They allow the > A record query to go through and come back unmolested (they don't need > to change the apparent address of the server to intercept traffic) but > they block the TLSA query. This absence of response is > DNSSEC-"bogus", because you didn't get an NSEC(3) to prove that there > are no TLSA records. If you abort the connection, the attacker loses. > If you fall back to non-DANE behavior, the attacker wins. I think we're running in circles again. I believe it is wrong to focus on some specific attack scenarios. We are adding a new optional feature to an installed base, and there will be trade-offs where the additional security can not be reliably provided. That does not mean that there is a new vulnerability, just that there is _no_new_protection_. In the ultimate final scenario, the server will be conveying fresh stapled OCSP responses and the entire set of DNS(SEC) records inline in the TLS handshake through a TLS extension, the client *knows* that it will receive such data from the real server and will abort if it does not get it. For the time of the migration, much can be gained by cert pinning -- a concept that has been proven as successful through millions of years of revolution: keeping memories of previous encounters to better recognize imposters on future encounters. I don't think it is useful to define DANE validation in a fashion that it could be easily abused for "casting doubt". That could enable an attacker to spoof one single TLSA record into an ISPs recursive DNS resolver for a zone that does not use DNSSEC and make the access to that business fail for *ALL* customers of that ISP for several hours. Personally, I believe one should restrict the ability to make a PKIX-validating certificate look "fishy" to the server&DNS admin. If they put wrong info into DNS, the resulting "loss of business" is their responsibility, they should be able to see and repro the problem and be able to fix it. Connectivity problems newly created by unforgiving DANE clients that are caused by non-malicious middle boxes (or ocassionally attackers) is hard to impossible to see and repro for the server&DNS admin, and usually quite impossible to fix for them. -Martin From ogud@ogud.com Wed Nov 23 08:24: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 E618521F8B1A for ; Wed, 23 Nov 2011 08:24:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.58 X-Spam-Level: X-Spam-Status: No, score=-106.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 mxWKAEbQD4Cp for ; Wed, 23 Nov 2011 08:24:22 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 1192921F8B17 for ; Wed, 23 Nov 2011 08:24:21 -0800 (PST) Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id pANGOKrX018913 for ; Wed, 23 Nov 2011 11:24:20 -0500 (EST) (envelope-from ogud@ogud.com) Message-ID: <4ECD1E35.9030302@ogud.com> Date: Wed, 23 Nov 2011 11:24:21 -0500 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: dane@ietf.org References: <45EA694E-096C-41A1-B60E-BF7B3832FE2A@vpnc.org> <4EC70173.9090106@sv.cmu.edu> <247CAE36-68FB-4048-B07C-9B4C0903434D@vpnc.org> <4EC7F701.4080006@panix.com> <20111123040753.GE11820@shinkuro.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Subject: Re: [dane] Fwd: Aiming towards some specific wording X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 16:24:23 -0000 On 22/11/2011 23:18, Zack Weinberg wrote: > On Tue, Nov 22, 2011 at 8:07 PM, Andrew Sullivan wrote: >> On Sun, Nov 20, 2011 at 08:22:11AM -0800, Zack Weinberg wrote: >> >>> (If the attacker can rewrite DNS responses, they can downgrade you to an >>> absence of DNSSEC all the way to the root >> >> No, they can't. You will fail the . validation at the last step, and >> everything is bogus. > > I guess I'm assuming that a DNSSEC-validating client that sees a > complete absence of DNSSEC records in the responses it gets with +AD > is going to assume a "harmless" failure of some middlebox to pass the > records, and fall back to non-validating behavior, rather than treat > everything as bogus. Zack Sorry this is hard to parse. Middle box not letting DNSSEC records though is not a "harmless" failure in my book, it is a total failure to use DANE. What do you mean by "DNSSEC-validating client"? an application that is doing its own validation or an application that trusts a certain validator or an application that blindly trust any resolver. In the first case it will ignore the AD bit and fail due to lack of DNSSEC RRSIG records In the second case it would not use the DNSSEC RRSIG's thus their absence is immaterial. The third case is not a recommended practice see RFC3655, in particular section 4. On my laptop I use local validating resolver that does uses local resolvers when it can, but still validates all answers. [1] > Behaving like that does open a large avenue for exploits that I hope > can be closed as soon as possible, but I suspect "as soon as possible" > is not for at least a few years... > > zw > See above, what possible exploits remain in case 2 above with secure channel to the validating resolver? DNS is vulnerable to DoS attacks see RFC3833, DNSSEC protects you from accepting bogus information DNSSEC does not guarantee that you get the good information. hope this helps Olafur PS: Sorry to be pedantic but if we are not talking the same language we will talk past each other. [1] DNSSEC Trigger http://www.nlnetlabs.nl/projects/dnssec-trigger/ will also try to work around broken middle boxes by using alternate ways to talk to remote "trusted resolvers". From eosterweil@verisign.com Mon Nov 28 09:15: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 61C7421F8CF1 for ; Mon, 28 Nov 2011 09:15:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.195 X-Spam-Level: X-Spam-Status: No, score=-4.195 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLUvYlBnOWxJ for ; Mon, 28 Nov 2011 09:15:34 -0800 (PST) Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) by ietfa.amsl.com (Postfix) with ESMTP id CF77E21F8CB7 for ; Mon, 28 Nov 2011 09:15:27 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP ID DSNKTtPBpgdwEpfc5Tz9CRcHTenxYFUGytH7@postini.com; Mon, 28 Nov 2011 09:15:32 PST Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id pASHFH5F010664; Mon, 28 Nov 2011 12:15:17 -0500 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.131.29.104]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Nov 2011 12:14:52 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: <201111230434.pAN4YDrd026150@fs4113.wdf.sap.corp> Date: Mon, 28 Nov 2011 12:14:28 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201111230434.pAN4YDrd026150@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 28 Nov 2011 17:14:52.0904 (UTC) FILETIME=[3E313E80:01CCADF1] Cc: dane@ietf.org Subject: Re: [dane] Aiming towards some specific wording X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 17:15:35 -0000 On Nov 22, 2011, at 11:34 PM, Martin Rex wrote: > Zack Weinberg wrote: >>=20 >=20 > I think we're running in circles again. >=20 > I believe it is wrong to focus on some specific attack scenarios. Disagree, see below: >=20 > We are adding a new optional feature to an installed base, and > there will be trade-offs where the additional security can not > be reliably provided. That does not mean that there is a new > vulnerability, just that there is _no_new_protection_. Adding a new security approach should require us to describe the attack = surface one has when using it, no? Using specific attack scenarios to = illustrate a weakness is actually important because it evolves a concern = from speculation to a demonstrable weakness. >=20 > In the ultimate final scenario, the server will be conveying > fresh stapled OCSP responses and the entire set of DNS(SEC) records > inline in the TLS handshake through a TLS extension, the client > *knows* that it will receive such data from the real server and > will abort if it does not get it. Whoa... I strongly disagree with this. I wonder who exactly considers = this the "ultimate final scenario?" I think this approach is very = dangerous from an architectural perspective (as I mentioned on the list = before and during ietf 81). Among other things, it opens a new attack = vector based on _operational_ inevitabilities. >=20 > For the time of the migration, much can be gained by > cert pinning -- a concept that has been proven as successful > through millions of years of revolution: keeping memories of > previous encounters to better recognize imposters on future > encounters. Sooo... When a creature vets something that it thinks is pedestrian, but = turns out to be a camouflaged predator, how did those memories help? I = think this is a very strained analogy.=20 >=20 > I don't think it is useful to define DANE validation in a fashion > that it could be easily abused for "casting doubt". That could > enable an attacker to spoof one single TLSA record into an ISPs > recursive DNS resolver for a zone that does not use DNSSEC > and make the access to that business fail for *ALL* customers > of that ISP for several hours. Here I agree. I think we need to be more careful if we go down this = path. >=20 > Personally, I believe one should restrict the ability to > make a PKIX-validating certificate look "fishy" to the server&DNS = admin. > If they put wrong info into DNS, the resulting "loss of business" > is their responsibility, they should be able to see and repro the > problem and be able to fix it. I would mostly agree with this. My thought would be that if we are = going to start codifying an evidence-based security approach here, we = should try to capture a more quantifiable notion of how RPs make = judgements. A simple spoofed DNS packet that causes an RP to fail = sounds a little dangerous, but perhaps there's more that I'm missing, or = more that could be done? Eric= From ondrej.sury@nic.cz Wed Nov 30 08:59: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 2C13421F8BB8 for ; Wed, 30 Nov 2011 08:59:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.21 X-Spam-Level: X-Spam-Status: No, score=-0.21 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 Mh2rYcEqpVzx for ; Wed, 30 Nov 2011 08:59:45 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 6295321F8BAD for ; Wed, 30 Nov 2011 08:59:45 -0800 (PST) Received: from kimac.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 9AF472A2EF7 for ; Wed, 30 Nov 2011 17:59:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1322672383; bh=Hc7lkkw2zf5jLijtWO31RhbgJ2WOSae/P6olVodAk7Y=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Date: Message-Id:To:Mime-Version; b=sOw083BhxxuPs+ezcYFVNvC140Y+axws1InfcdWtsYeyLE+8pYyqtYY5QWHoFXY4L RCI/qKh7CaHITjJ91UrqsDO5FTTe72GspKbKIKWpN5kBl2vFUza4DoGlpgV0w1DVuE tdMqw/1KUvgvG1EVYw1Px+r5SzwsV/hHhr1JtDM0= From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Nov 2011 17:59:43 +0100 Message-Id: To: IETF DANE WG list Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: [dane] Call for consensus on level of DNSSEC support (Security-aware Stub Resolver in DANE-aware application) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 16:59:46 -0000 Hi all, I would like to set the working group into the motion again. I will use the RFC4033 language (Section 2 and Section 5), so please read that before you comment. Let's assume that the DANE-aware application is using trusted Validating Security-Aware Recursive Name Server. How is that achieved is out-of-the-scope for this email (and for the DANE protocol draft). It seems to me that from the 'Aiming towards...' thread, we still have a misunderstanding what should DANE-aware application do or not do. In particular, the call for consensus is that DANE-aware application has to implement (at least) Non-validating Security-aware Stub Resolver. As we (Warren) said earlier there were some concerns in the IESG and we have the DNSSEC in the charter, so we have to use only Secure TLSA possitive answers. Also we cannot ignore the Bogus state, because then the restrictive option (Usage type 0/1) would be vulnerable to stripping in-path attack. Implications: - DANE-aware client distinguishes three DNSSEC states of the data on the = input: + TLSA Resource Record Exists and is Secure (RFC4033 Section 5) (AD bit set) + DNS Response is Bogus (RCODE=3DSERVFAIL) + Everything else (catch-all rule) - When processing it becomes: + TLSA Resource Record Exists + TLSA Resource Record Matches =3D> OK + TLSA Resource Record Doesn't Match =3D> FAIL + DNS Response is Bogus =3D> FAIL + Everything else (catch-all rule) =3D> NO-INFO (Fallback to PKIX) - It's harder to implement, because there is not common API for that = yet. I think we already had a quite intensive discussion on this topic, so please only express your opinion (+1 vs. -1) 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 zack.weinberg@gmail.com Wed Nov 30 09:04: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 6094C21F8BB8 for ; Wed, 30 Nov 2011 09:04:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.188 X-Spam-Level: X-Spam-Status: No, score=-1.188 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYaPQoPT6MWl for ; Wed, 30 Nov 2011 09:04:04 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 512DC21F8B26 for ; Wed, 30 Nov 2011 09:04:04 -0800 (PST) Received: by vbbez10 with SMTP id ez10so661872vbb.31 for ; Wed, 30 Nov 2011 09:04:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Gr0LW8yqjfTLnXbn7N3tvzmltvB7aueoq8Y8bbAQj+8=; b=fNcfsnoToteoOuTXSRUXQFXOUVwZQAqJSkHTFDagWEvh5Lx9dqXwzIIz/pM6DMr1wB awB3vZVqzYojdrwWDQ1bLP0sIz0V2Z/hE62T+3wgyd5NLM+DG8rTdltAcztfjBGFFIOn OIGRQ9XbP1M3lOJjCi0RVQj8LKrGYa6bVP4nQ= MIME-Version: 1.0 Received: by 10.182.225.3 with SMTP id rg3mr574908obc.77.1322672643624; Wed, 30 Nov 2011 09:04:03 -0800 (PST) Sender: zack.weinberg@gmail.com Received: by 10.182.88.103 with HTTP; Wed, 30 Nov 2011 09:04:03 -0800 (PST) In-Reply-To: References: Date: Wed, 30 Nov 2011 09:04:03 -0800 X-Google-Sender-Auth: P1Tg9yCdeyLtMpRNFG6-swEbSA4 Message-ID: From: Zack Weinberg To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IETF DANE WG list Subject: Re: [dane] Call for consensus on level of DNSSEC support (Security-aware Stub Resolver in DANE-aware application) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 17:04:05 -0000 On Wed, Nov 30, 2011 at 8:59 AM, Ond=C5=99ej Sur=C3=BD = wrote: > Implications: > - DANE-aware client distinguishes three DNSSEC states of the data on the = input: > =C2=A0+ TLSA Resource Record Exists and is Secure (RFC4033 Section 5) > =C2=A0 (AD bit set) > =C2=A0+ DNS Response is Bogus > =C2=A0 (RCODE=3DSERVFAIL) -1 on mentioning AD or RCODE, +1 on everything else. Just delete the parentheticals. > =C2=A0+ Everything else (catch-all rule) > - When processing it becomes: > =C2=A0+ TLSA Resource Record Exists > =C2=A0+ TLSA Resource Record Matches =C2=A0 =C2=A0 =C2=A0 =3D> OK > =C2=A0+ TLSA Resource Record Doesn't Match =3D> FAIL > =C2=A0+ DNS Response is Bogus =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =3D> FAIL > =C2=A0+ Everything else (catch-all rule) =C2=A0 =C2=A0=3D> NO-INFO (Fallb= ack to PKIX) +1 zw From paul.hoffman@vpnc.org Wed Nov 30 09:07: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 1314521F8BB7 for ; Wed, 30 Nov 2011 09:07:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.263 X-Spam-Level: X-Spam-Status: No, score=-102.263 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CwJiZ8nFvxJV for ; Wed, 30 Nov 2011 09:07:26 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 971A121F8BA8 for ; Wed, 30 Nov 2011 09:07:26 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id pAUH7M5u080091 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 30 Nov 2011 10:07:23 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Wed, 30 Nov 2011 09:07:22 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= X-Mailer: Apple Mail (2.1251.1) Cc: IETF DANE WG list Subject: Re: [dane] Call for consensus on level of DNSSEC support (Security-aware Stub Resolver in DANE-aware application) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 17:07:27 -0000 With all due respect, your choices below do not reflect all the choices = that people asked to be able to choose between. Worse, you do not = propose specific wording that will help your humble document authors. Instead of the current poll you started, would you instead accept one = that is based on the choices that people asked for on the earlier = thread? --Paul Hoffman From ondrej.sury@nic.cz Wed Nov 30 10:15: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 1E16F11E809A for ; Wed, 30 Nov 2011 10:15:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.955 X-Spam-Level: X-Spam-Status: No, score=-0.955 tagged_above=-999 required=5 tests=[AWL=0.744, 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 5JuLNufRqXuQ for ; Wed, 30 Nov 2011 10:15:38 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 5FBD511E8098 for ; Wed, 30 Nov 2011 10:15:38 -0800 (PST) Received: from kimac.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id B9A062A2700; Wed, 30 Nov 2011 19:15:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1322676936; bh=OFSAr1qecAcIPtGKd49DSWEeidkJwxLqIqjS41G6HZ4=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Pq74w4oYBEjAmpjKf7uM5PxsP723rhxag08uUZpNt723N8m2TufiwXZ2K8FXJKfLF dbd2PafkE4DZFkNuh6tSah4/6R9m815SPEIwLpcO+U1wZmRoxpMGeGthvmqK7Grv47 A4IQHTpSm36gGu4z+A+/6goypY3YY8lwmi5R9C7s= Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: Date: Wed, 30 Nov 2011 19:15:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Zack Weinberg X-Mailer: Apple Mail (2.1251.1) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: IETF DANE WG list Subject: Re: [dane] Call for consensus on level of DNSSEC support (Security-aware Stub Resolver in DANE-aware application) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 18:15:39 -0000 On 30. 11. 2011, at 18:04, Zack Weinberg wrote: > On Wed, Nov 30, 2011 at 8:59 AM, Ond=C5=99ej Sur=C3=BD = wrote: >> Implications: >> - DANE-aware client distinguishes three DNSSEC states of the data on = the input: >> + TLSA Resource Record Exists and is Secure (RFC4033 Section 5) >> (AD bit set) >> + DNS Response is Bogus >> (RCODE=3DSERVFAIL) >=20 > -1 on mentioning AD or RCODE This merely reflects RFC4033 - but note taken. It could be removed = without any harm. > , +1 on everything else. Just delete the > parentheticals. >=20 >> + Everything else (catch-all rule) >> - When processing it becomes: >> + TLSA Resource Record Exists >> + TLSA Resource Record Matches =3D> OK >> + TLSA Resource Record Doesn't Match =3D> FAIL >> + DNS Response is Bogus =3D> FAIL >> + Everything else (catch-all rule) =3D> NO-INFO (Fallback to = PKIX) >=20 > +1 >=20 > zw -- 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 Wed Nov 30 10:36: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 DA4EE21F846D for ; Wed, 30 Nov 2011 10:36:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wzbf1bjyHWaN for ; Wed, 30 Nov 2011 10:36:21 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 60B0521F846A for ; Wed, 30 Nov 2011 10:36:21 -0800 (PST) Received: from [192.1.255.200] (port=64123 helo=col-dhcp-192-1-255-200.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RVp10-000ESl-2l; Wed, 30 Nov 2011 13:36:18 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Wed, 30 Nov 2011 13:36:16 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5EC7CB77-34EA-4774-A958-B6FB550209F5@bbn.com> References: To: Paul Hoffman X-Mailer: Apple Mail (2.1084) Cc: IETF DANE WG list Subject: Re: [dane] Call for consensus on level of DNSSEC support (Security-aware Stub Resolver in DANE-aware application) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 18:36:22 -0000 So, that's a "-1"? On Nov 30, 2011, at 12:07 PM, Paul Hoffman wrote: > With all due respect, your choices below do not reflect all the = choices that people asked to be able to choose between. Worse, you do = not propose specific wording that will help your humble document = authors. >=20 > Instead of the current poll you started, would you instead accept one = that is based on the choices that people asked for on the earlier = thread? >=20 > --Paul Hoffman >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From rbarnes@bbn.com Wed Nov 30 10:36: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 CEB4F21F8BBE for ; Wed, 30 Nov 2011 10:36:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sa8nsD5HZOvK for ; Wed, 30 Nov 2011 10:36:52 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5ECEB21F8478 for ; Wed, 30 Nov 2011 10:36:52 -0800 (PST) Received: from [192.1.255.200] (port=64123 helo=col-dhcp-192-1-255-200.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RVp1W-000ESl-QX; Wed, 30 Nov 2011 13:36:51 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: "Richard L. Barnes" In-Reply-To: Date: Wed, 30 Nov 2011 13:36:50 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7D82D146-C97C-49FB-9A93-57468EB5D23A@bbn.com> References: To: Zack Weinberg X-Mailer: Apple Mail (2.1084) Cc: IETF DANE WG list Subject: Re: [dane] Call for consensus on level of DNSSEC support (Security-aware Stub Resolver in DANE-aware application) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 18:36:52 -0000 +1 to what Zack said. --Richard On Nov 30, 2011, at 12:04 PM, Zack Weinberg wrote: > On Wed, Nov 30, 2011 at 8:59 AM, Ond=C5=99ej Sur=C3=BD = wrote: >> Implications: >> - DANE-aware client distinguishes three DNSSEC states of the data on = the input: >> + TLSA Resource Record Exists and is Secure (RFC4033 Section 5) >> (AD bit set) >> + DNS Response is Bogus >> (RCODE=3DSERVFAIL) >=20 > -1 on mentioning AD or RCODE, +1 on everything else. Just delete the > parentheticals. >=20 >> + Everything else (catch-all rule) >> - When processing it becomes: >> + TLSA Resource Record Exists >> + TLSA Resource Record Matches =3D> OK >> + TLSA Resource Record Doesn't Match =3D> FAIL >> + DNS Response is Bogus =3D> FAIL >> + Everything else (catch-all rule) =3D> NO-INFO (Fallback to = PKIX) >=20 > +1 >=20 > zw > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From ondrej.sury@nic.cz Wed Nov 30 11:56: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 89D7411E8081 for ; Wed, 30 Nov 2011 11:56:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.327 X-Spam-Level: X-Spam-Status: No, score=-1.327 tagged_above=-999 required=5 tests=[AWL=0.372, 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 X9ykIsCE4hbB for ; Wed, 30 Nov 2011 11:56:15 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id B666521F84D6 for ; Wed, 30 Nov 2011 11:56:15 -0800 (PST) Received: from kimac.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 6439E2A2DED for ; Wed, 30 Nov 2011 20:56:14 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1322682974; bh=yjgBhzqnbOs4k3ykI1iMcsMmNKq2BwpbyF+SUfW5c00=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=DOx4LiYgVFPClBvb0NeccRjNwGDdCihadaoSdOGx0FKDmdbsPq7jSvU7kbd5ObMcR ouEz/uBOk6jzDLCuSC5v7X+uR39DIkgO3Ka10eIWTG7LLNLmsLNZ39trcV32/Do1R7 1Se5ge9A87TVc1n4ciZdxroUBcRtPSHzwUHdjZ50= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Apple Message framework v1251.1) From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: Date: Wed, 30 Nov 2011 20:56:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0D281BEC-C54D-4319-AA91-1BB9BE77161F@nic.cz> References: To: IETF DANE WG list X-Mailer: Apple Mail (2.1251.1) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: Re: [dane] Call for consensus on level of DNSSEC support (Security-aware Stub Resolver in DANE-aware application) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 19:56:16 -0000 To clarify our intention here... We reflect what was said in earlier threads and that there were more choices how to interpret DNSSEC states and how to react. We (the = chairs) have noted that there was also strong support to not complicate things and keep the issue codenamed as "DNSSEC-optional" out of the protocol document. We have also noted that there was some differences on how to handle the Bogus response, but we also feel that there was stronger support for handling it as hard failure. So if any of you feel that you don't like the one choice I have = presented and asked for support, please do vote "-1" and we can continue to vote = for more complicated scenarios or split up this one scenario into more = atomic choices. But I would really like to: a) keep things moving b) not start running in circles again c) go to a) We also talked with Paul off-list and we are working on finishing the = specific wording into the draft which will reflect my Call for Consensus. If you = would feel more comfortable by waiting for the exact wording, please wait = before you vote, I hope to have the exact wording finished before end of Friday. Ondrej On 30. 11. 2011, at 18:07, Paul Hoffman wrote: > With all due respect, your choices below do not reflect all the = choices that people asked to be able to choose between. Worse, you do = not propose specific wording that will help your humble document = authors. >=20 > Instead of the current poll you started, would you instead accept one = that is based on the choices that people asked for on the earlier = thread? >=20 > --Paul Hoffman >=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 ------------------------------------------- From ajs@anvilwalrusden.com Wed Nov 30 12:01: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 ACFE21F0C53 for ; Wed, 30 Nov 2011 12:01:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-WC1e9q4kI5 for ; Wed, 30 Nov 2011 12:01:58 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 9C9D31F0C45 for ; Wed, 30 Nov 2011 12:01:58 -0800 (PST) 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 1EDDC1ECB423 for ; Wed, 30 Nov 2011 20:01:42 +0000 (UTC) Date: Wed, 30 Nov 2011 15:01:55 -0500 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20111130200154.GF56700@shinkuro.com> References: 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.5.21 (2010-09-15) Subject: Re: [dane] Call for consensus on level of DNSSEC support (Security-aware Stub Resolver in DANE-aware application) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 20:01:59 -0000 On Wed, Nov 30, 2011 at 05:59:43PM +0100, OndÅ™ej Surý wrote: > + TLSA Resource Record Exists and is Secure (RFC4033 Section 5) > (AD bit set) > + DNS Response is Bogus > (RCODE=SERVFAIL) > + Everything else (catch-all rule) > - When processing it becomes: > + TLSA Resource Record Exists > + TLSA Resource Record Matches => OK > + TLSA Resource Record Doesn't Match => FAIL > + DNS Response is Bogus => FAIL > + Everything else (catch-all rule) => NO-INFO (Fallback to PKIX) I don't think I understand the question. Under the "When processing", does "Matches" means "has AD bit set?" (and conversely, doesn't match/SERVFAIL)? There are three possible answer-states to a stub: answer with AD=1, answer without AD=1 (i.e. AD is clear), and SERVFAIL. The first of these corresponds to the first "+" above, the last to the second "+", and I can't tell whether the "When processing" is processing the + Everything Else or a description of how to consume and process an answer generally. Thanks, A -- Andrew Sullivan ajs@anvilwalrusden.com From rbarnes@bbn.com Wed Nov 30 12:34: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 8CAAA21F8A35 for ; Wed, 30 Nov 2011 12:34:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WdhI02PBcgwA for ; Wed, 30 Nov 2011 12:34:58 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 15A3421F89B8 for ; Wed, 30 Nov 2011 12:34:58 -0800 (PST) Received: from [192.1.255.200] (port=64574 helo=col-dhcp-192-1-255-200.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RVqrp-000Gsq-3d; Wed, 30 Nov 2011 15:34:57 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <20111130200154.GF56700@shinkuro.com> Date: Wed, 30 Nov 2011 15:34:56 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <24C048A3-A2C7-44C7-8A5D-E9A9AABEB428@bbn.com> References: <20111130200154.GF56700@shinkuro.com> To: Andrew Sullivan X-Mailer: Apple Mail (2.1084) Cc: dane@ietf.org Subject: Re: [dane] Call for consensus on level of DNSSEC support (Security-aware Stub Resolver in DANE-aware application) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 20:34:58 -0000 >> + TLSA Resource Record Exists and is Secure (RFC4033 Section 5) >> (AD bit set) >> + DNS Response is Bogus >> (RCODE=3DSERVFAIL) >> + Everything else (catch-all rule) >> - When processing it becomes: >> + TLSA Resource Record Exists >> + TLSA Resource Record Matches =3D> OK >> + TLSA Resource Record Doesn't Match =3D> FAIL >> + DNS Response is Bogus =3D> FAIL >> + Everything else (catch-all rule) =3D> NO-INFO (Fallback to PKIX) >=20 > I don't think I understand the question. Under the "When processing", > does "Matches" means "has AD bit set?" (and conversely, doesn't > match/SERVFAIL)? No, "match" is a match between the TLSA record and the certificate. = E.g., does the certificate chain to a trust anchor in a type 2 = certificate? It's an orthogonal, second-level check. > There are three possible answer-states to a stub: answer with AD=3D1, > answer without AD=3D1 (i.e. AD is clear), and SERVFAIL. The first of > these corresponds to the first "+" above, the last to the second "+", > and I can't tell whether the "When processing" is processing the + > Everything Else or a description of how to consume and process an > answer generally. I think the map is as follows: AD=3D1 =3D> Record exists and is secure SERVFAIL =3D> DNS response is bogus AD=3D0 =3D> [Falls into everything else] As I understood it, Ondrej was expressing four rules: Record exists and is secure && TLSA match =3D> OK Record exists and is secure && not TLSA match =3D> FAIL DNS Response is Bogus =3D> FAIL Otherwise =3D> NO-INFO --Richard= From ajs@anvilwalrusden.com Wed Nov 30 12:51: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 7762A1F0C5D for ; Wed, 30 Nov 2011 12:51:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.363 X-Spam-Level: X-Spam-Status: No, score=-2.363 tagged_above=-999 required=5 tests=[AWL=0.236, 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 9HO5wReVp+Re for ; Wed, 30 Nov 2011 12:51:45 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id DCEED1F0C5A for ; Wed, 30 Nov 2011 12:51:44 -0800 (PST) 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 DEF391ECB423 for ; Wed, 30 Nov 2011 20:51:24 +0000 (UTC) Date: Wed, 30 Nov 2011 15:51:30 -0500 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20111130205127.GG56700@shinkuro.com> References: <20111130200154.GF56700@shinkuro.com> <24C048A3-A2C7-44C7-8A5D-E9A9AABEB428@bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24C048A3-A2C7-44C7-8A5D-E9A9AABEB428@bbn.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Call for consensus on level of DNSSEC support (Security-aware Stub Resolver in DANE-aware application) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 20:51:45 -0000 On Wed, Nov 30, 2011 at 03:34:56PM -0500, Richard L. Barnes wrote: > As I understood it, Ondrej was expressing four rules: > Record exists and is secure && TLSA match => OK > Record exists and is secure && not TLSA match => FAIL > DNS Response is Bogus => FAIL > Otherwise => NO-INFO This is infinitely clearer. With the proviso that "bogus" is not strictly speaking something a non-validating resolver can strictly know (that is, SERVFAIL tells you "validation failed or else something else went wrong"), but that it's close enough, I'm ok with the above. In other words, subject to confirmation that's what's meant (and BTW, it's not how I interpreted it, but I'm dim), +1. A -- Andrew Sullivan ajs@anvilwalrusden.com From eosterweil@verisign.com Wed Nov 30 12: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 F144F1F0C5F for ; Wed, 30 Nov 2011 12:52:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.247 X-Spam-Level: X-Spam-Status: No, score=-5.247 tagged_above=-999 required=5 tests=[AWL=1.052, 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 L1nq8wGR-YsD for ; Wed, 30 Nov 2011 12:52:04 -0800 (PST) Received: from exprod6og106.obsmtp.com (exprod6og106.obsmtp.com [64.18.1.191]) by ietfa.amsl.com (Postfix) with ESMTP id 25C901F0C3B for ; Wed, 30 Nov 2011 12:52:04 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob106.postini.com ([64.18.5.12]) with SMTP ID DSNKTtaXaXzDVCJPMBU5xEdtI1opce7ajSvP@postini.com; Wed, 30 Nov 2011 12:52:04 PST Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id pAUKpnR0025403; Wed, 30 Nov 2011 15:51:51 -0500 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.131.29.104]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 Nov 2011 15:51:28 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Eric Osterweil In-Reply-To: Date: Wed, 30 Nov 2011 15:51:16 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 30 Nov 2011 20:51:28.0889 (UTC) FILETIME=[D53AAE90:01CCAFA1] Cc: IETF DANE WG list Subject: Re: [dane] Call for consensus on level of DNSSEC support (Security-aware Stub Resolver in DANE-aware application) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 20:52:05 -0000 On Nov 30, 2011, at 11:59 AM, Ond=C5=99ej Sur=C3=BD wrote: > Implications: > - DANE-aware client distinguishes three DNSSEC states of the data on = the input: > + TLSA Resource Record Exists and is Secure (RFC4033 Section 5) > (AD bit set) > + DNS Response is Bogus > (RCODE=3DSERVFAIL) +1 to the above > + Everything else (catch-all rule) > - When processing it becomes: > + TLSA Resource Record Exists > + TLSA Resource Record Matches =3D> OK > + TLSA Resource Record Doesn't Match =3D> FAIL So, is this under the catch-all case where the response is _not_ DNSSEC = verified? If this is correct, then we are verifying a cert based on = non-verified DNS data, and my vote is: -1 THough, I share (at least some of) Andrew's confusion, so I admit I = might be responding based on a misinterpretation... > + DNS Response is Bogus =3D> FAIL > + Everything else (catch-all rule) =3D> NO-INFO (Fallback to PKIX) > - It's harder to implement, because there is not common API for that = yet. -1 because I believe (based on something someone said in the previous = thread) this can be used in a downgrade attack using a cert from a = compromised CA. Eric= From ondrej.sury@nic.cz Wed Nov 30 13:03: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 67D431F0C7F for ; Wed, 30 Nov 2011 13:03:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[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 FFU9uKVHdikB for ; Wed, 30 Nov 2011 13:03:31 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id AF8DA1F0C5B for ; Wed, 30 Nov 2011 13:03:31 -0800 (PST) Received: from [10.0.0.12] (173.5.broadband15.iol.cz [90.182.5.173]) by mail.nic.cz (Postfix) with ESMTPSA id 658AA2A276A; Wed, 30 Nov 2011 22:03:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1322687007; bh=c4pBT7KdZtIjV+2dIkwRypGb8x6EtEQGKuEDmWhlcGo=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=J7mE6qCdqmMDQedAP26In0H9n9caBhlKfkWgCgCFUGIoXyF50S+1Exuf1kFj9LM7p z9ai/UT3bKxQt9knmAyhhWfmNU5H7n5SYV603Wq+YJHNF6zoswL9f65SBIFdi8kG24 LJZc5yaOkcYXt9tAM1v3JTlLJxjD5hmKX4TmloPE= Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: Date: Wed, 30 Nov 2011 22:03:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Eric Osterweil X-Mailer: Apple Mail (2.1251.1) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: IETF DANE WG list Subject: Re: [dane] Call for consensus on level of DNSSEC support (Security-aware Stub Resolver in DANE-aware application) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 21:03:32 -0000 On 30. 11. 2011, at 21:51, Eric Osterweil wrote: >=20 > On Nov 30, 2011, at 11:59 AM, Ond=C5=99ej Sur=C3=BD wrote: >=20 >> Implications: >> - DANE-aware client distinguishes three DNSSEC states of the data on = the input: >> + TLSA Resource Record Exists and is Secure (RFC4033 Section 5) >> (AD bit set) >> + DNS Response is Bogus >> (RCODE=3DSERVFAIL) >=20 > +1 to the above >=20 >> + Everything else (catch-all rule) >> - When processing it becomes: >> + TLSA Resource Record Exists >> + TLSA Resource Record Matches =3D> OK >> + TLSA Resource Record Doesn't Match =3D> FAIL >=20 >=20 > So, is this under the catch-all case where the response is _not_ = DNSSEC verified? Nope. It has lost the formatting somewhere along the way... I'll send the I-D text in a second. > If this is correct, then we are verifying a cert based on = non-verified DNS data, and my vote is: > -1 >=20 > THough, I share (at least some of) Andrew's confusion, so I admit I = might be responding based on a misinterpretation... >=20 >> + DNS Response is Bogus =3D> FAIL >> + Everything else (catch-all rule) =3D> NO-INFO (Fallback to PKIX) >> - It's harder to implement, because there is not common API for that = yet. >=20 > -1 because I believe (based on something someone said in the previous = thread) this can be used in a downgrade attack using a cert from a = compromised CA. >=20 > Eric -- 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 Wed Nov 30 13:07: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 DF8E81F0C38 for ; Wed, 30 Nov 2011 13:07:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[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 3TAp+ARXDDTB for ; Wed, 30 Nov 2011 13:07:34 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id CFFC41F0C35 for ; Wed, 30 Nov 2011 13:07:33 -0800 (PST) Received: from [10.0.0.12] (173.5.broadband15.iol.cz [90.182.5.173]) by mail.nic.cz (Postfix) with ESMTPSA id 8227E2A2D83 for ; Wed, 30 Nov 2011 22:07:32 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1322687252; bh=5nuOJkMxwOJ6CEOKjyl775RzfWfd7iuD3sJN0bzzOqs=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=F22gBogXMqkEL6f8R3ywDYPj4dj588XlAkNYF7DmRkuB+K6ZBc5CDNubCA8vesROn DsS0eACE6mhd+jD0m0NYVyXkHJew9ZO+p8HGOg4bHFq5jeF0QJZuYBGMN+2pnNA1Nn FbV4fWZt/baeXSS+wKCMtRGaYLbEIya5pJgsm6bs= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Apple Message framework v1251.1) From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: Date: Wed, 30 Nov 2011 22:07:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <48C7E091-64A9-4F27-A52F-06C681AD23B2@nic.cz> References: To: IETF DANE WG list X-Mailer: Apple Mail (2.1251.1) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: Re: [dane] Call for consensus on level of DNSSEC support (Security-aware Stub Resolver in DANE-aware application) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 21:07:35 -0000 In a hope to clear at least some of the confusion, here's the text which replaces last paragraph in 4.4, which is NOW: --old text from -12-- An application that complies with this document first requests TLSA records in order to make certificate associations. If that application receives zero usable certificate associations, it processes TLS in the normal fashion; otherwise, that application attempts to match each certificate association with the TLS server's end entity certificate. If such a match is found, that application continues the TLS handshake and ignores any remaining certificate associations; otherwise, that application MUST abort the TLS handshake with an "access_denied" error. --old text from -12-- which becomes: --new text-- An application that complies with this document first requests TLSA records in order to make certificate associations. Determining whether a TLSA RRset can be used depends on the DNSSEC validation state (as defined in [RFC4033]). o A TLSA RRset whose DNSSEC validation state is secure MAY be used as a certificate association for TLS. o If the DNSSEC validation state on the response to the request for the TLSA RRset is bogus, this MUST cause TLS not to be started or, if the TLS negotiation is already in progress, to cause the connection to be aborted. o A TLSA RRset whose DNSSEC validation state is indeterminate or insecure cannot be used for TLS and MUST be marked as unusable. --new text-- Note: Please read whole text and not just bullets. E.g. in all other possible (undefined here) cases the TLSA RRset cannot be used. O. On 30. 11. 2011, at 17:59, Ond=C5=99ej Sur=C3=BD wrote: > Hi all, >=20 > I would like to set the working group into the motion again. > I will use the RFC4033 language (Section 2 and Section 5), > so please read that before you comment. >=20 > Let's assume that the DANE-aware application is using trusted > Validating Security-Aware Recursive Name Server. >=20 > How is that achieved is out-of-the-scope for this email (and > for the DANE protocol draft). >=20 > It seems to me that from the 'Aiming towards...' thread, > we still have a misunderstanding what should DANE-aware > application do or not do. >=20 > In particular, the call for consensus is that DANE-aware > application has to implement (at least) Non-validating > Security-aware Stub Resolver. As we (Warren) said earlier > there were some concerns in the IESG and we have the DNSSEC > in the charter, so we have to use only Secure TLSA possitive > answers. Also we cannot ignore the Bogus state, because > then the restrictive option (Usage type 0/1) would be vulnerable > to stripping in-path attack. >=20 > Implications: > - DANE-aware client distinguishes three DNSSEC states of the data on = the input: > + TLSA Resource Record Exists and is Secure (RFC4033 Section 5) > (AD bit set) > + DNS Response is Bogus > (RCODE=3DSERVFAIL) > + Everything else (catch-all rule) > - When processing it becomes: > + TLSA Resource Record Exists > + TLSA Resource Record Matches =3D> OK > + TLSA Resource Record Doesn't Match =3D> FAIL > + DNS Response is Bogus =3D> FAIL > + Everything else (catch-all rule) =3D> NO-INFO (Fallback to PKIX) > - It's harder to implement, because there is not common API for that = yet. >=20 > I think we already had a quite intensive discussion on this topic, > so please only express your opinion (+1 vs. -1) >=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 -- 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 mrex@sap.com Wed Nov 30 13:11: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 068891F0C38 for ; Wed, 30 Nov 2011 13:11:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.97 X-Spam-Level: X-Spam-Status: No, score=-9.97 tagged_above=-999 required=5 tests=[AWL=0.279, 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 9pg9fTImD1n5 for ; Wed, 30 Nov 2011 13:11:17 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 35DA321F84ED for ; Wed, 30 Nov 2011 13:11:16 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id pAULB7xR016200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Nov 2011 22:11:07 +0100 (MET) From: Martin Rex Message-Id: <201111302111.pAULB6Fq029234@fs4113.wdf.sap.corp> To: rbarnes@bbn.com (Richard L. Barnes) Date: Wed, 30 Nov 2011 22:11:06 +0100 (MET) In-Reply-To: <24C048A3-A2C7-44C7-8A5D-E9A9AABEB428@bbn.com> from "Richard L. Barnes" at Nov 30, 11 03:34:56 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] Call for consensus on level of DNSSEC support 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, 30 Nov 2011 21:11:18 -0000 Richard L. Barnes wrote: > As I understood it, Ondrej was expressing four rules: > > Record exists and is secure && TLSA match => OK > Record exists and is secure && not TLSA match => FAIL > DNS Response is Bogus => FAIL > Otherwise => NO-INFO I having a serious problem with the 3rd, the others are OK. For usage types 0/1 (PKIX-validating cert), it really ought to be DNS Response is Bogus => NO-INFO -Martin From rbarnes@bbn.com Wed Nov 30 13:17: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 3A3F911E80C0 for ; Wed, 30 Nov 2011 13:17:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5o11JtZ7f1A for ; Wed, 30 Nov 2011 13:17:35 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id BBDFD11E80AF for ; Wed, 30 Nov 2011 13:17:35 -0800 (PST) Received: from [192.1.255.200] (port=64650 helo=col-dhcp-192-1-255-200.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RVrWw-000Hlw-IH; Wed, 30 Nov 2011 16:17:26 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <201111302111.pAULB6Fq029234@fs4113.wdf.sap.corp> Date: Wed, 30 Nov 2011 16:17:26 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201111302111.pAULB6Fq029234@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1084) Cc: dane@ietf.org Subject: Re: [dane] Call for consensus on level of DNSSEC support X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 21:17:36 -0000 >> As I understood it, Ondrej was expressing four rules: >>=20 >> Record exists and is secure && TLSA match =3D> OK >> Record exists and is secure && not TLSA match =3D> FAIL >> DNS Response is Bogus =3D> FAIL >> Otherwise =3D> NO-INFO >=20 > I having a serious problem with the 3rd, the others are OK. >=20 > For usage types 0/1 (PKIX-validating cert), it really ought to be=20 >=20 > DNS Response is Bogus =3D> NO-INFO Can you say more about why you think this? =20 ISTM that treating different usages differently makes implementation and = extensibility difficult. Also, as Ondrej noted, making Bogus=3D>NO-INFO = implies that suppressing usage 0/1 controls is trivial. --Richard= From paul.hoffman@vpnc.org Wed Nov 30 13:21: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 E489011E80DA for ; Wed, 30 Nov 2011 13:21:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.268 X-Spam-Level: X-Spam-Status: No, score=-102.268 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Yfeliys3Tou for ; Wed, 30 Nov 2011 13:21:07 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5530211E80D7 for ; Wed, 30 Nov 2011 13:21:06 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id pAULL5JV089546 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 30 Nov 2011 14:21:05 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: Paul Hoffman In-Reply-To: <48C7E091-64A9-4F27-A52F-06C681AD23B2@nic.cz> Date: Wed, 30 Nov 2011 13:21:04 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <48C7E091-64A9-4F27-A52F-06C681AD23B2@nic.cz> To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= X-Mailer: Apple Mail (2.1251.1) Cc: IETF DANE WG list Subject: Re: [dane] Call for consensus on level of DNSSEC support (Security-aware Stub Resolver in DANE-aware application) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 21:21:08 -0000 On Nov 30, 2011, at 1:07 PM, Ond=C5=99ej Sur=C3=BD wrote: > In a hope to clear at least some of the confusion, here's the > text which replaces last paragraph in 4.4, which is NOW: >=20 > --old text from -12-- > An application that complies with this document first requests TLSA > records in order to make certificate associations. If that > application receives zero usable certificate associations, it > processes TLS in the normal fashion; otherwise, that application > attempts to match each certificate association with the TLS server's > end entity certificate. If such a match is found, that application > continues the TLS handshake and ignores any remaining certificate > associations; otherwise, that application MUST abort the TLS > handshake with an "access_denied" error. > --old text from -12-- >=20 > which becomes: >=20 > --new text-- > An application that complies with this document first requests TLSA > records in order to make certificate associations. >=20 > Determining whether a TLSA RRset can be used depends > on the DNSSEC validation state (as defined in [RFC4033]). >=20 > o A TLSA RRset whose DNSSEC validation state is secure MAY be used > as a certificate association for TLS. >=20 > o If the DNSSEC validation state on the response to the request > for the TLSA RRset is bogus, this MUST cause TLS not to be started > or, if the TLS negotiation is already in progress, to cause > the connection to be aborted. >=20 > o A TLSA RRset whose DNSSEC validation state is indeterminate or > insecure cannot be used for TLS and MUST be marked as unusable. > --new text-- >=20 > Note: Please read whole text and not just bullets. E.g. in all other > possible (undefined here) cases the TLSA RRset cannot be used. +1 to this proposed wording. --Paul Hoffman From ajs@anvilwalrusden.com Wed Nov 30 13:21: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 EBCF011E80D9 for ; Wed, 30 Nov 2011 13:21:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8JGYiXjaUOBq for ; Wed, 30 Nov 2011 13:21:20 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 78ED311E80D7 for ; Wed, 30 Nov 2011 13:21:20 -0800 (PST) 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 42CA61ECB423 for ; Wed, 30 Nov 2011 21:20:58 +0000 (UTC) Date: Wed, 30 Nov 2011 16:21:01 -0500 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20111130212056.GH56700@shinkuro.com> References: <48C7E091-64A9-4F27-A52F-06C681AD23B2@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <48C7E091-64A9-4F27-A52F-06C681AD23B2@nic.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Call for consensus on level of DNSSEC support (Security-aware Stub Resolver in DANE-aware application) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 21:21:21 -0000 On Wed, Nov 30, 2011 at 10:07:32PM +0100, OndÅ™ej Surý wrote: > --new text-- > An application that complies with this document first requests TLSA > records in order to make certificate associations. > > Determining whether a TLSA RRset can be used depends > on the DNSSEC validation state (as defined in [RFC4033]). > > o A TLSA RRset whose DNSSEC validation state is secure MAY be used > as a certificate association for TLS. > > o If the DNSSEC validation state on the response to the request > for the TLSA RRset is bogus, this MUST cause TLS not to be started > or, if the TLS negotiation is already in progress, to cause > the connection to be aborted. > > o A TLSA RRset whose DNSSEC validation state is indeterminate or > insecure cannot be used for TLS and MUST be marked as unusable. > --new text-- > > Note: Please read whole text and not just bullets. E.g. in all other > possible (undefined here) cases the TLSA RRset cannot be used. I read this text, I understand it, and it's fine with me. A -- Andrew Sullivan ajs@anvilwalrusden.com From mrex@sap.com Wed Nov 30 13:23: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 2D6B211E80C0 for ; Wed, 30 Nov 2011 13:23:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.026 X-Spam-Level: X-Spam-Status: No, score=-10.026 tagged_above=-999 required=5 tests=[AWL=0.223, 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 SFgT+ClsjmgE for ; Wed, 30 Nov 2011 13:23:49 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 35BD011E80AF for ; Wed, 30 Nov 2011 13:23:49 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id pAULNe6o019257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Nov 2011 22:23:40 +0100 (MET) From: Martin Rex Message-Id: <201111302123.pAULNd4E000020@fs4113.wdf.sap.corp> To: rbarnes@bbn.com (Richard L. Barnes) Date: Wed, 30 Nov 2011 22:23:39 +0100 (MET) In-Reply-To: from "Richard L. Barnes" at Nov 30, 11 04:17:26 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] Call for consensus on level of DNSSEC support 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, 30 Nov 2011 21:23:50 -0000 Richard L. Barnes wrote: > > >> As I understood it, Ondrej was expressing four rules: > >> > >> Record exists and is secure && TLSA match => OK > >> Record exists and is secure && not TLSA match => FAIL > >> DNS Response is Bogus => FAIL > >> Otherwise => NO-INFO > > > > I having a serious problem with the 3rd, the others are OK. > > > > For usage types 0/1 (PKIX-validating cert), it really ought to be > > > > DNS Response is Bogus => NO-INFO > > Can you say more about why you think this? I believe there is no reliable difference between Bogus and Indeterminate, the distinction has at best some minor relevance for admins while doing troubleshooting. http://tools.ietf.org/html/rfc4035#page-21 How would you check compliance of any particular implementation in reliably distinguishing bogus from inteterminate based on that definition? > > ISTM that treating different usages differently makes implementation > and extensibility difficult. Also, as Ondrej noted, making > Bogus=>NO-INFO implies that suppressing usage 0/1 controls is trivial. Yes, suppressing these controls is trivial. DNS does *not* provide a reliable transport between end entities. Means to work around lack of reliability in DNS is to do local caching of previously received and still valid (with respect to RSIG, not TTL) DNS records and conveying the relevant DNS records inline through a TLS extension. -Martin From rbarnes@bbn.com Wed Nov 30 13:36: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 89F821F0C88 for ; Wed, 30 Nov 2011 13:36:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jTlQvwGjiPkG for ; Wed, 30 Nov 2011 13:36:59 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1A54E1F0C84 for ; Wed, 30 Nov 2011 13:36:59 -0800 (PST) Received: from [192.1.255.200] (port=64694 helo=col-dhcp-192-1-255-200.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RVrpl-000I7A-LJ; Wed, 30 Nov 2011 16:36:53 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <20111130212056.GH56700@shinkuro.com> Date: Wed, 30 Nov 2011 16:36:53 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: <48C7E091-64A9-4F27-A52F-06C681AD23B2@nic.cz> <20111130212056.GH56700@shinkuro.com> To: Andrew Sullivan X-Mailer: Apple Mail (2.1084) Cc: dane@ietf.org Subject: Re: [dane] Call for consensus on level of DNSSEC support (Security-aware Stub Resolver in DANE-aware application) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 21:36:59 -0000 >> --new text-- >> An application that complies with this document first requests TLSA >> records in order to make certificate associations. >> >> Determining whether a TLSA RRset can be used depends >> on the DNSSEC validation state (as defined in [RFC4033]). >> >> o A TLSA RRset whose DNSSEC validation state is secure MAY be used >> as a certificate association for TLS. >> >> o If the DNSSEC validation state on the response to the request >> for the TLSA RRset is bogus, this MUST cause TLS not to be started >> or, if the TLS negotiation is already in progress, to cause >> the connection to be aborted. >> >> o A TLSA RRset whose DNSSEC validation state is indeterminate or >> insecure cannot be used for TLS and MUST be marked as unusable. >> --new text-- >> >> Note: Please read whole text and not just bullets. E.g. in all other >> possible (undefined here) cases the TLSA RRset cannot be used. > > I read this text, I understand it, and it's fine with me. > > A > +1 --Richard From Marco.Davids@sidn.nl Wed Nov 30 13: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 02DF621F8B29 for ; Wed, 30 Nov 2011 13:41:54 -0800 (PST) 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 Bbtx21s7S9HW for ; Wed, 30 Nov 2011 13:41:53 -0800 (PST) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [94.198.152.69]) by ietfa.amsl.com (Postfix) with ESMTP id 4894E21F8B24 for ; Wed, 30 Nov 2011 13:41:52 -0800 (PST) Received: from kahubcas1.SIDN.local ([192.168.2.41]) by ede1-kamx.sidn.nl with ESMTP id pAULflux024789 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Wed, 30 Nov 2011 22:41:47 +0100 Received: from iMac-woonkamer.local (192.168.4.161) by KAHUBCAS1.SIDN.local (192.168.2.41) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 30 Nov 2011 22:41:47 +0100 Message-ID: <4ED6A31A.8090102@sidn.nl> Date: Wed, 30 Nov 2011 22:41:46 +0100 From: "Marco Davids (SIDN)" Organization: SIDN User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: References: <20111130200154.GF56700@shinkuro.com> <24C048A3-A2C7-44C7-8A5D-E9A9AABEB428@bbn.com> In-Reply-To: <24C048A3-A2C7-44C7-8A5D-E9A9AABEB428@bbn.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [192.168.4.161] Subject: Re: [dane] Call for consensus on level of DNSSEC support (Security-aware Stub Resolver in DANE-aware application) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 21:41:54 -0000 Op 30-11-11 21:34, Richard L. Barnes schreef: > As I understood it, Ondrej was expressing four rules: > Record exists and is secure && TLSA match => OK > Record exists and is secure && not TLSA match => FAIL > DNS Response is Bogus => FAIL > Otherwise => NO-INFO In that case: +1 But I would be interested in the exact wording of the document. Especially for the 'is secure' part. I am by no means an expert in resolver-libraries, so apologies if I get it all wrong, but is the AD-bit at all visible to the application that issues an 'res_mkquery()' or something similar? And if it isn't, than how is a browser supposed to 'declare a record secure'? Does DANE imply that new resolvers libraries will have to be defined, that will pass on the AD-bit? Does it imply validation on the client-side perhaps? -- Marco From warren@kumari.net Wed Nov 30 13:46: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 E0C0611E808C for ; Wed, 30 Nov 2011 13:46:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rznKfn3dTlH7 for ; Wed, 30 Nov 2011 13:46:41 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 6330B11E8081 for ; Wed, 30 Nov 2011 13:46:41 -0800 (PST) Received: from dhcp-172-19-119-228.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 8C79C1B40861; Wed, 30 Nov 2011 16:46:40 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Warren Kumari In-Reply-To: Date: Wed, 30 Nov 2011 16:46:38 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <48C7E091-64A9-4F27-A52F-06C681AD23B2@nic.cz> To: Paul Hoffman X-Mailer: Apple Mail (2.1084) Cc: IETF DANE WG list Subject: Re: [dane] Call for consensus on level of DNSSEC support (Security-aware Stub Resolver in DANE-aware application) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 21:46:42 -0000 On Nov 30, 2011, at 4:21 PM, Paul Hoffman wrote: > On Nov 30, 2011, at 1:07 PM, Ond=C5=99ej Sur=C3=BD wrote: >=20 >> In a hope to clear at least some of the confusion, here's the >> text which replaces last paragraph in 4.4, which is NOW: >>=20 >> --old text from -12-- >> An application that complies with this document first requests TLSA >> records in order to make certificate associations. If that >> application receives zero usable certificate associations, it >> processes TLS in the normal fashion; otherwise, that application >> attempts to match each certificate association with the TLS server's >> end entity certificate. If such a match is found, that application >> continues the TLS handshake and ignores any remaining certificate >> associations; otherwise, that application MUST abort the TLS >> handshake with an "access_denied" error. >> --old text from -12-- >>=20 >> which becomes: >>=20 >> --new text-- >> An application that complies with this document first requests TLSA >> records in order to make certificate associations. >>=20 >> Determining whether a TLSA RRset can be used depends >> on the DNSSEC validation state (as defined in [RFC4033]). >>=20 >> o A TLSA RRset whose DNSSEC validation state is secure MAY be used >> as a certificate association for TLS. >>=20 >> o If the DNSSEC validation state on the response to the request >> for the TLSA RRset is bogus, this MUST cause TLS not to be started >> or, if the TLS negotiation is already in progress, to cause >> the connection to be aborted. >>=20 >> o A TLSA RRset whose DNSSEC validation state is indeterminate or >> insecure cannot be used for TLS and MUST be marked as unusable. >> --new text-- >>=20 >> Note: Please read whole text and not just bullets. E.g. in all other >> possible (undefined here) cases the TLSA RRset cannot be used. >=20 > +1 to this proposed wording. I am ok with the proposed wording. Nit: s/TLS negotiation is already in progress, to cause/TLS negotiation = is already in progress, cause/ # Superfluous 'to'? W >=20 > --Paul Hoffman >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From peter@denic.de Wed Nov 30 13:51: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 88EE911E809F for ; Wed, 30 Nov 2011 13:51:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0EmKvRLXoeo for ; Wed, 30 Nov 2011 13:51:20 -0800 (PST) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::4]) by ietfa.amsl.com (Postfix) with ESMTP id 24E7A11E8081 for ; Wed, 30 Nov 2011 13:51:19 -0800 (PST) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1RVs3h-0007Pm-PN; Wed, 30 Nov 2011 22:51:17 +0100 Received: from localhost by x27.adm.denic.de with local id 1RVs3h-0004zU-LY; Wed, 30 Nov 2011 22:51:17 +0100 Date: Wed, 30 Nov 2011 22:51:17 +0100 From: Peter Koch To: IETF DANE WG list Message-ID: <20111130215117.GA17317@x27.adm.denic.de> Mail-Followup-To: IETF DANE WG list References: <48C7E091-64A9-4F27-A52F-06C681AD23B2@nic.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <48C7E091-64A9-4F27-A52F-06C681AD23B2@nic.cz> User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: Re: [dane] Call for consensus on level of DNSSEC support (Security-aware Stub Resolver in DANE-aware application) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 21:51:33 -0000 On Wed, Nov 30, 2011 at 10:07:32PM +0100, Ond??ej Surý wrote: > --new text-- > An application that complies with this document first requests TLSA > records in order to make certificate associations. > > Determining whether a TLSA RRset can be used depends > on the DNSSEC validation state (as defined in [RFC4033]). > > o A TLSA RRset whose DNSSEC validation state is secure MAY be used > as a certificate association for TLS. > > o If the DNSSEC validation state on the response to the request > for the TLSA RRset is bogus, this MUST cause TLS not to be started > or, if the TLS negotiation is already in progress, to cause > the connection to be aborted. > > o A TLSA RRset whose DNSSEC validation state is indeterminate or > insecure cannot be used for TLS and MUST be marked as unusable. > --new text-- > > Note: Please read whole text and not just bullets. E.g. in all other > possible (undefined here) cases the TLSA RRset cannot be used. I have read the whole text and think it is well done! => "+1" For the final document, it should try even less to be aesthetic prose, so "cannot be used for TLS and MUST be marked as unusable" would become "MUST NOT be used for TLS". Also, an additional explanation for the second bullet's complicated wording would state that there might not be a TLSA RRSet available (RCODE=SERVFAIL). Finally, the Security Considerations section should advise that the 'restrictive' use case cannot be relied upon; that's only a slight drawback because it doesn't help with all the DANE-unaware implementations to start with. -Peter From warren@kumari.net Wed Nov 30 13:55: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 C254F11E809D for ; Wed, 30 Nov 2011 13:55:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdYwHvMm8RAx for ; Wed, 30 Nov 2011 13:55:06 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 5007E11E8081 for ; Wed, 30 Nov 2011 13:55:06 -0800 (PST) Received: from dhcp-172-19-119-228.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 87DA81B40861; Wed, 30 Nov 2011 16:55:05 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <4ED6A31A.8090102@sidn.nl> Date: Wed, 30 Nov 2011 16:55:03 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20111130200154.GF56700@shinkuro.com> <24C048A3-A2C7-44C7-8A5D-E9A9AABEB428@bbn.com> <4ED6A31A.8090102@sidn.nl> To: "Marco Davids (SIDN)" X-Mailer: Apple Mail (2.1084) Cc: dane@ietf.org Subject: Re: [dane] Call for consensus on level of DNSSEC support (Security-aware Stub Resolver in DANE-aware application) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 21:55:06 -0000 On Nov 30, 2011, at 4:41 PM, Marco Davids (SIDN) wrote: > Op 30-11-11 21:34, Richard L. Barnes schreef: >=20 >> As I understood it, Ondrej was expressing four rules: >> Record exists and is secure && TLSA match =3D> OK >> Record exists and is secure && not TLSA match =3D> FAIL >> DNS Response is Bogus =3D> FAIL >> Otherwise =3D> NO-INFO >=20 > In that case: +1 >=20 > But I would be interested in the exact wording of the document. > Especially for the 'is secure' part. >=20 > I am by no means an expert in resolver-libraries, so apologies if I = get > it all wrong, [No hats] Me neither, so apologies in advance if I get things horribly wrong! > but is the AD-bit at all visible to the application that > issues an 'res_mkquery()' or something similar? And if it isn't, than > how is a browser supposed to 'declare a record secure'? Does DANE = imply > that new resolvers libraries will have to be defined, that will pass = on > the AD-bit? > Does it imply validation on the client-side perhaps? Kinda. There are currently a number of products / resolver libraries that = expose this information (libunbound, SPARTA's libval as examples), but = there is currently no standard standard interface to get this = information. There is currently ongoing efforts to create a standard API = for getting this (and additional info) from the resolvers.=20 Apps can also simply* do the DNSSEC themselves...=20 W *: Notice the hand-waving there? Good, wasn't it?! >=20 > -- > Marco >=20 >=20 >=20 >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 From ietf@augustcellars.com Wed Nov 30 14:02: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 468A31F0C4E for ; Wed, 30 Nov 2011 14:02:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=-0.450, 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 bd9ZJPEE4LGf for ; Wed, 30 Nov 2011 14:02:23 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA2C1F0C35 for ; Wed, 30 Nov 2011 14:02:23 -0800 (PST) Received: from Tobias (173-8-216-38-Oregon.hfc.comcastbusiness.net [173.8.216.38]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 1B83B2CA17; Wed, 30 Nov 2011 14:02:23 -0800 (PST) From: "Jim Schaad" To: =?utf-8?Q?'Ondrej_Sur=C3=BD'?= , "'IETF DANE WG list'" References: <48C7E091-64A9-4F27-A52F-06C681AD23B2@nic.cz> In-Reply-To: <48C7E091-64A9-4F27-A52F-06C681AD23B2@nic.cz> Date: Wed, 30 Nov 2011 14:01:47 -0800 Message-ID: <000601ccafab$ac11ae10$04350a30$@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: AQGut/YJDNlSCGQivK9LrRHjlJIdAgMw0D5YlehgynA= Content-Language: en-us Subject: Re: [dane] Call for consensus on level of DNSSEC support (Security-aware Stub Resolver in DANE-aware application) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 22:02:24 -0000 > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf = Of > Ondrej Sur=C3=BD > Sent: Wednesday, November 30, 2011 1:08 PM > To: IETF DANE WG list > Subject: Re: [dane] Call for consensus on level of DNSSEC support = (Security- > aware Stub Resolver in DANE-aware application) >=20 > In a hope to clear at least some of the confusion, here's the text = which > replaces last paragraph in 4.4, which is NOW: >=20 > --old text from -12-- > An application that complies with this document first requests TLSA > records in order to make certificate associations. If that > application receives zero usable certificate associations, it > processes TLS in the normal fashion; otherwise, that application > attempts to match each certificate association with the TLS = server's > end entity certificate. If such a match is found, that application > continues the TLS handshake and ignores any remaining certificate > associations; otherwise, that application MUST abort the TLS > handshake with an "access_denied" error. > --old text from -12-- >=20 > which becomes: >=20 > --new text-- > An application that complies with this document first requests TLSA > records in order to make certificate associations. >=20 > Determining whether a TLSA RRset can be used depends > on the DNSSEC validation state (as defined in [RFC4033]). >=20 > o A TLSA RRset whose DNSSEC validation state is secure MAY be used > as a certificate association for TLS. Can you elaborate on why you put a MAY here? Jim >=20 > o If the DNSSEC validation state on the response to the request > for the TLSA RRset is bogus, this MUST cause TLS not to be = started > or, if the TLS negotiation is already in progress, to cause > the connection to be aborted. >=20 > o A TLSA RRset whose DNSSEC validation state is indeterminate or > insecure cannot be used for TLS and MUST be marked as unusable. > --new text-- >=20 > Note: Please read whole text and not just bullets. E.g. in all other = possible > (undefined here) cases the TLSA RRset cannot be used. >=20 > O. >=20 > On 30. 11. 2011, at 17:59, Ondrej Sur wrote: >=20 > > Hi all, > > > > I would like to set the working group into the motion again. > > I will use the RFC4033 language (Section 2 and Section 5), so please > > read that before you comment. > > > > Let's assume that the DANE-aware application is using trusted > > Validating Security-Aware Recursive Name Server. > > > > How is that achieved is out-of-the-scope for this email (and for the > > DANE protocol draft). > > > > It seems to me that from the 'Aiming towards...' thread, we still = have > > a misunderstanding what should DANE-aware application do or not do. > > > > In particular, the call for consensus is that DANE-aware application > > has to implement (at least) Non-validating Security-aware Stub > > Resolver. As we (Warren) said earlier there were some concerns in = the > > IESG and we have the DNSSEC in the charter, so we have to use only > > Secure TLSA possitive answers. Also we cannot ignore the Bogus = state, > > because then the restrictive option (Usage type 0/1) would be > > vulnerable to stripping in-path attack. > > > > Implications: > > - DANE-aware client distinguishes three DNSSEC states of the data on = the > input: > > + TLSA Resource Record Exists and is Secure (RFC4033 Section 5) > > (AD bit set) > > + DNS Response is Bogus > > (RCODE=3DSERVFAIL) > > + Everything else (catch-all rule) > > - When processing it becomes: > > + TLSA Resource Record Exists > > + TLSA Resource Record Matches =3D> OK > > + TLSA Resource Record Doesn't Match =3D> FAIL > > + DNS Response is Bogus =3D> FAIL > > + Everything else (catch-all rule) =3D> NO-INFO (Fallback to = PKIX) > > - It's harder to implement, because there is not common API for that = yet. > > > > I think we already had a quite intensive discussion on this topic, = so > > please only express your opinion (+1 vs. -1) > > > > Thank you, > > -- > > 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 >=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 ynir@checkpoint.com Wed Nov 30 14:07: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 4C6B51F0C5F for ; Wed, 30 Nov 2011 14:07:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttq+OktQS1Rh for ; Wed, 30 Nov 2011 14:07:51 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 57BC71F0C5A for ; Wed, 30 Nov 2011 14:07:51 -0800 (PST) X-CheckPoint: {4ED6A854-1-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id pAUM7nJV032386; Thu, 1 Dec 2011 00:07:49 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 1 Dec 2011 00:07:48 +0200 From: Yoav Nir To: =?utf-8?B?T25kxZllaiBTdXLDvQ==?= Date: Thu, 1 Dec 2011 00:07:45 +0200 Thread-Topic: [dane] Call for consensus on level of DNSSEC support (Security-aware Stub Resolver in DANE-aware application) Thread-Index: AcyvrH4vZKFuBkyDSkC4pi3sDtCT+w== Message-ID: References: <48C7E091-64A9-4F27-A52F-06C681AD23B2@nic.cz> In-Reply-To: <48C7E091-64A9-4F27-A52F-06C681AD23B2@nic.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: IETF DANE WG list Subject: Re: [dane] Call for consensus on level of DNSSEC support (Security-aware Stub Resolver in DANE-aware application) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 22:07:52 -0000 DQpPbiBOb3YgMzAsIDIwMTEsIGF0IDExOjA3IFBNLCBPbmTFmWVqIFN1csO9IHdyb3RlOg0KDQo+ IEluIGEgaG9wZSB0byBjbGVhciBhdCBsZWFzdCBzb21lIG9mIHRoZSBjb25mdXNpb24sIGhlcmUn cyB0aGUNCj4gdGV4dCB3aGljaCByZXBsYWNlcyBsYXN0IHBhcmFncmFwaCBpbiA0LjQsIHdoaWNo IGlzIE5PVzoNCj4gDQo+IC0tb2xkIHRleHQgZnJvbSAtMTItLQ0KPiAgIEFuIGFwcGxpY2F0aW9u IHRoYXQgY29tcGxpZXMgd2l0aCB0aGlzIGRvY3VtZW50IGZpcnN0IHJlcXVlc3RzIFRMU0ENCj4g ICByZWNvcmRzIGluIG9yZGVyIHRvIG1ha2UgY2VydGlmaWNhdGUgYXNzb2NpYXRpb25zLiAgSWYg dGhhdA0KPiAgIGFwcGxpY2F0aW9uIHJlY2VpdmVzIHplcm8gdXNhYmxlIGNlcnRpZmljYXRlIGFz c29jaWF0aW9ucywgaXQNCj4gICBwcm9jZXNzZXMgVExTIGluIHRoZSBub3JtYWwgZmFzaGlvbjsg b3RoZXJ3aXNlLCB0aGF0IGFwcGxpY2F0aW9uDQo+ICAgYXR0ZW1wdHMgdG8gbWF0Y2ggZWFjaCBj ZXJ0aWZpY2F0ZSBhc3NvY2lhdGlvbiB3aXRoIHRoZSBUTFMgc2VydmVyJ3MNCj4gICBlbmQgZW50 aXR5IGNlcnRpZmljYXRlLiAgSWYgc3VjaCBhIG1hdGNoIGlzIGZvdW5kLCB0aGF0IGFwcGxpY2F0 aW9uDQo+ICAgY29udGludWVzIHRoZSBUTFMgaGFuZHNoYWtlIGFuZCBpZ25vcmVzIGFueSByZW1h aW5pbmcgY2VydGlmaWNhdGUNCj4gICBhc3NvY2lhdGlvbnM7IG90aGVyd2lzZSwgdGhhdCBhcHBs aWNhdGlvbiBNVVNUIGFib3J0IHRoZSBUTFMNCj4gICBoYW5kc2hha2Ugd2l0aCBhbiAiYWNjZXNz X2RlbmllZCIgZXJyb3IuDQo+IC0tb2xkIHRleHQgZnJvbSAtMTItLQ0KPiANCj4gd2hpY2ggYmVj b21lczoNCj4gDQo+IC0tbmV3IHRleHQtLQ0KPiAgIEFuIGFwcGxpY2F0aW9uIHRoYXQgY29tcGxp ZXMgd2l0aCB0aGlzIGRvY3VtZW50IGZpcnN0IHJlcXVlc3RzIFRMU0ENCj4gICByZWNvcmRzIGlu IG9yZGVyIHRvIG1ha2UgY2VydGlmaWNhdGUgYXNzb2NpYXRpb25zLg0KPiANCj4gICBEZXRlcm1p bmluZyB3aGV0aGVyIGEgVExTQSBSUnNldCBjYW4gYmUgdXNlZCBkZXBlbmRzDQo+ICAgb24gdGhl IEROU1NFQyB2YWxpZGF0aW9uIHN0YXRlIChhcyBkZWZpbmVkIGluIFtSRkM0MDMzXSkuDQo+IA0K PiAgIG8gQSBUTFNBIFJSc2V0IHdob3NlIEROU1NFQyB2YWxpZGF0aW9uIHN0YXRlIGlzIHNlY3Vy ZSBNQVkgYmUgdXNlZA0KPiAgICAgYXMgYSBjZXJ0aWZpY2F0ZSBhc3NvY2lhdGlvbiBmb3IgVExT Lg0KPiANCj4gICBvIElmIHRoZSBETlNTRUMgdmFsaWRhdGlvbiBzdGF0ZSBvbiB0aGUgcmVzcG9u c2UgdG8gdGhlIHJlcXVlc3QNCj4gICAgIGZvciB0aGUgVExTQSBSUnNldCBpcyBib2d1cywgdGhp cyBNVVNUIGNhdXNlIFRMUyBub3QgdG8gYmUgc3RhcnRlZA0KPiAgICAgb3IsIGlmIHRoZSBUTFMg bmVnb3RpYXRpb24gaXMgYWxyZWFkeSBpbiBwcm9ncmVzcywgdG8gY2F1c2UNCj4gICAgIHRoZSBj b25uZWN0aW9uIHRvIGJlIGFib3J0ZWQuDQo+IA0KPiAgIG8gQSBUTFNBIFJSc2V0IHdob3NlIERO U1NFQyB2YWxpZGF0aW9uIHN0YXRlIGlzIGluZGV0ZXJtaW5hdGUgb3INCj4gICAgIGluc2VjdXJl IGNhbm5vdCBiZSB1c2VkIGZvciBUTFMgYW5kIE1VU1QgYmUgbWFya2VkIGFzIHVudXNhYmxlLg0K PiAtLW5ldyB0ZXh0LS0NCj4gDQo+IE5vdGU6IFBsZWFzZSByZWFkIHdob2xlIHRleHQgYW5kIG5v dCBqdXN0IGJ1bGxldHMuICBFLmcuIGluIGFsbCBvdGhlcg0KPiBwb3NzaWJsZSAodW5kZWZpbmVk IGhlcmUpIGNhc2VzIHRoZSBUTFNBIFJSc2V0IGNhbm5vdCBiZSB1c2VkLg0KDQorMQ0KDQpFeGNl cHQsIHdoeSBpcyB0aGF0IGEgTUFZIG9uIHRoZSBmaXJzdCBidWxsZXQ/ICBJZiB5b3UncmUgbm90 IGdvaW5nIHRvIGFjdCBvbiBhIEROU1NFQy12YWxpZGF0ZWQgVExTQSByZWNvcmQsIHdoYXQncyB0 aGUgcG9pbnQgb2YgaW1wbGVtZW50aW5nIHRoaXMgc3BlY2lmaWNhdGlvbj8NCg0K From ynir@checkpoint.com Wed Nov 30 14:08: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 E521221F8541 for ; Wed, 30 Nov 2011 14:08:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.524 X-Spam-Level: X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z96vhB6DTyoF for ; Wed, 30 Nov 2011 14:08:53 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id F0A2721F853E for ; Wed, 30 Nov 2011 14:08:52 -0800 (PST) X-CheckPoint: {4ED6A892-2-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id pAUM8LU7032464; Thu, 1 Dec 2011 00:08:21 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 1 Dec 2011 00:08:20 +0200 From: Yoav Nir To: Jim Schaad Date: Thu, 1 Dec 2011 00:08:19 +0200 Thread-Topic: [dane] Call for consensus on level of DNSSEC support (Security-aware Stub Resolver in DANE-aware application) Thread-Index: AcyvrJGrE4Wu62v0RBynppE1ODlPyA== Message-ID: <0E637D5C-BCD8-4504-9553-79A83EC150C2@checkpoint.com> References: <48C7E091-64A9-4F27-A52F-06C681AD23B2@nic.cz> <000601ccafab$ac11ae10$04350a30$@augustcellars.com> In-Reply-To: <000601ccafab$ac11ae10$04350a30$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF DANE WG list Subject: Re: [dane] Call for consensus on level of DNSSEC support (Security-aware Stub Resolver in DANE-aware application) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 22:08:54 -0000 On Dec 1, 2011, at 12:01 AM, Jim Schaad wrote: >=20 >=20 >> -----Original Message----- >> From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of >> Ondrej Sur=FD >> Sent: Wednesday, November 30, 2011 1:08 PM >> To: IETF DANE WG list >> Subject: Re: [dane] Call for consensus on level of DNSSEC support (Secur= ity- >> aware Stub Resolver in DANE-aware application) >>=20 >> In a hope to clear at least some of the confusion, here's the text which >> replaces last paragraph in 4.4, which is NOW: >>=20 >> --old text from -12-- >> An application that complies with this document first requests TLSA >> records in order to make certificate associations. If that >> application receives zero usable certificate associations, it >> processes TLS in the normal fashion; otherwise, that application >> attempts to match each certificate association with the TLS server's >> end entity certificate. If such a match is found, that application >> continues the TLS handshake and ignores any remaining certificate >> associations; otherwise, that application MUST abort the TLS >> handshake with an "access_denied" error. >> --old text from -12-- >>=20 >> which becomes: >>=20 >> --new text-- >> An application that complies with this document first requests TLSA >> records in order to make certificate associations. >>=20 >> Determining whether a TLSA RRset can be used depends >> on the DNSSEC validation state (as defined in [RFC4033]). >>=20 >> o A TLSA RRset whose DNSSEC validation state is secure MAY be used >> as a certificate association for TLS. >=20 > Can you elaborate on why you put a MAY here? >=20 > Jim Oops, beat me to it. From paul.hoffman@vpnc.org Wed Nov 30 14:19: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 E142421F8B8A for ; Wed, 30 Nov 2011 14:19:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.421 X-Spam-Level: X-Spam-Status: No, score=-102.421 tagged_above=-999 required=5 tests=[AWL=0.178, 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 VjIgl11uWsAS for ; Wed, 30 Nov 2011 14:19:47 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id D70E121F8B86 for ; Wed, 30 Nov 2011 14:19:46 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id pAUMJjM7091418 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 30 Nov 2011 15:19:46 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Paul Hoffman In-Reply-To: Date: Wed, 30 Nov 2011 14:19:45 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7BA32289-B2B1-4B07-A5EA-69F5F556FC8E@vpnc.org> References: <48C7E091-64A9-4F27-A52F-06C681AD23B2@nic.cz> To: IETF DANE WG list X-Mailer: Apple Mail (2.1251.1) Subject: Re: [dane] Call for consensus on level of DNSSEC support (Security-aware Stub Resolver in DANE-aware application) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 22:19:48 -0000 On Nov 30, 2011, at 2:07 PM, Yoav Nir wrote: > Except, why is that a MAY on the first bullet? If you're not going to = act on a DNSSEC-validated TLSA record, what's the point of implementing = this specification? There may be other policy that would cause you to not use the = certificate association. For example, assume that you *only* trust certs = from YourOwnCA when communicating with = any.domain.under.yourowncompany.com. You go to = misconfigured.yourowncompany.com and get a TLSA record type 0 that is = issued by SomeOtherCA. Your local policy should be able to trump the = TLSA record. --Paul Hoffman From ondrej.sury@nic.cz Wed Nov 30 14:27: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 099FB11E80B5 for ; Wed, 30 Nov 2011 14:27:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8Q6pQZCYi9j for ; Wed, 30 Nov 2011 14:27:03 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 948B311E809D for ; Wed, 30 Nov 2011 14:26:57 -0800 (PST) Received: from [10.0.0.12] (173.5.broadband15.iol.cz [90.182.5.173]) by mail.nic.cz (Postfix) with ESMTPSA id 935392A2B50; Wed, 30 Nov 2011 23:26:56 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1322692016; bh=6ptgsNTPJvFzQ7D9MyDwO88g0SzmlDwR9BhGFjgfZsA=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=cAaHkhShxYKAY2vwQ+oAb4LfTXDP8W+T7eNCCs0ODxGTxMsGp5MfhYWRDHBmk9Dqx 4RlhANNiCb316iLR0vkbU1ceYZHKW5HGzHFwTc6C2f837QPUVQDDkWi++XrCGIP+hN VRfamO0xEAMRdBTQKBdZCc877HJPYxGlKf+jXlXM= Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <4ED6A31A.8090102@sidn.nl> Date: Wed, 30 Nov 2011 23:26:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <40E1F3E1-A95D-4214-82F1-8CCA33C56550@nic.cz> References: <20111130200154.GF56700@shinkuro.com> <24C048A3-A2C7-44C7-8A5D-E9A9AABEB428@bbn.com> <4ED6A31A.8090102@sidn.nl> To: "Marco Davids (SIDN)" X-Mailer: Apple Mail (2.1251.1) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane@ietf.org Subject: Re: [dane] Call for consensus on level of DNSSEC support (Security-aware Stub Resolver in DANE-aware application) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 22:27:04 -0000 On 30. 11. 2011, at 22:41, Marco Davids (SIDN) wrote: > Op 30-11-11 21:34, Richard L. Barnes schreef: >=20 >> As I understood it, Ondrej was expressing four rules: >> Record exists and is secure && TLSA match =3D> OK >> Record exists and is secure && not TLSA match =3D> FAIL >> DNS Response is Bogus =3D> FAIL >> Otherwise =3D> NO-INFO >=20 > In that case: +1 >=20 > But I would be interested in the exact wording of the document. > Especially for the 'is secure' part. See my later email. > I am by no means an expert in resolver-libraries, so apologies if I = get > it all wrong, but is the AD-bit at all visible to the application that > issues an 'res_mkquery()' or something similar? And if it isn't, than > how is a browser supposed to 'declare a record secure'? Does DANE = imply > that new resolvers libraries will have to be defined, that will pass = on > the AD-bit? Does it imply validation on the client-side perhaps? See RFC 4033 Section 5: This specification only defines how security-aware name servers can signal non-validating stub resolvers that data was found to be bogus (using RCODE=3D2, "Server Failure"; see [RFC4035]). There is a mechanism for security-aware name servers to signal security-aware stub resolvers that data was found to be secure (using the AD bit; see [RFC4035]). That's why I have wrote that DANE-aware application must implement (at least) non-validating security-aware stub resolver. 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 Wed Nov 30 14:30: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 B46DD11E80C5 for ; Wed, 30 Nov 2011 14:30:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WAKzqC3ttAeg for ; Wed, 30 Nov 2011 14:30:44 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id F3EBF11E809D for ; Wed, 30 Nov 2011 14:30:43 -0800 (PST) Received: from [10.0.0.12] (173.5.broadband15.iol.cz [90.182.5.173]) by mail.nic.cz (Postfix) with ESMTPSA id 21E292A0A78; Wed, 30 Nov 2011 23:30:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1322692243; bh=s9450QHBXAkBhNBiXkak42n0g488XdY4MiA4UA5f59I=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=CjTBwgDXopggbtY1xlhbH8JHHRS1N0UhkL8/6w8xrnlF+GIJdZhQ4O/UFIddjxeKW ccn3ArAv/waeL2BEpmmQ4KouXZmhVcxpqcV6NuOXpqLYfdturgVg/cD8tfWgH8vrTY LYxNo2IZ5SibI4Sy3/ik2IkQQSPlIU/L20q/NXf0= Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <201111302123.pAULNd4E000020@fs4113.wdf.sap.corp> Date: Wed, 30 Nov 2011 23:30:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201111302123.pAULNd4E000020@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1251.1) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: IETF DANE WG list Subject: Re: [dane] Call for consensus on level of DNSSEC support X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 22:30:44 -0000 On 30. 11. 2011, at 22:23, Martin Rex wrote: > Richard L. Barnes wrote: >>=20 >>>> As I understood it, Ondrej was expressing four rules: >>>>=20 >>>> Record exists and is secure && TLSA match =3D> OK >>>> Record exists and is secure && not TLSA match =3D> FAIL >>>> DNS Response is Bogus =3D> FAIL >>>> Otherwise =3D> NO-INFO >>>=20 >>> I having a serious problem with the 3rd, the others are OK. >>>=20 >>> For usage types 0/1 (PKIX-validating cert), it really ought to be=20 >>>=20 >>> DNS Response is Bogus =3D> NO-INFO >>=20 >> Can you say more about why you think this? =20 >=20 > I believe there is no reliable difference between Bogus and = Indeterminate, > the distinction has at best some minor relevance for admins while = doing > troubleshooting.=20 >=20 > http://tools.ietf.org/html/rfc4035#page-21 That discrepancy must be fixed in DNSEXT. We are using RFC 4033 = definitions of DNSSEC validation states. And I think I have clearly stated that (exactly for this reason): > I will use the RFC4033 language (Section 2 and Section 5), > so please read that before you comment. [...] > + TLSA Resource Record Exists and is Secure (RFC4033 Section 5) [...] 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 Wed Nov 30 14:35: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 14BB911E80C5 for ; Wed, 30 Nov 2011 14:35:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZeP6U1mDtQc for ; Wed, 30 Nov 2011 14:35:41 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id CB62811E809D for ; Wed, 30 Nov 2011 14:35:38 -0800 (PST) Received: from [10.0.0.12] (173.5.broadband15.iol.cz [90.182.5.173]) by mail.nic.cz (Postfix) with ESMTPSA id 004E52A2B50; Wed, 30 Nov 2011 23:35:37 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1322692538; bh=rUR10W0UUy09vYisLG4RvAWusHFP9dsAGHuUEDCAO8U=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=vnjnWywNo8kTpJGNBmw3r3/J0FMLAMVbd+FgZ3Wt+IAtrbAOyKkO6ACh0HFYyje4m 9sumLKkoVqyE7bhODl5MO17Y43SXd5Rl/zAMBICXkD8C407kGPbF06gM1aaQ9vgDvY nGOrdXCnmZkJ09sDH4LAKG4y45FD9amJjTwNlyFQ= Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <000601ccafab$ac11ae10$04350a30$@augustcellars.com> Date: Wed, 30 Nov 2011 23:35:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <30124937-44D0-484A-B040-7F15E90727AE@nic.cz> References: <48C7E091-64A9-4F27-A52F-06C681AD23B2@nic.cz> <000601ccafab$ac11ae10$04350a30$@augustcellars.com> To: "Jim Schaad" X-Mailer: Apple Mail (2.1251.1) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: 'IETF DANE WG list' Subject: Re: [dane] Call for consensus on level of DNSSEC support (Security-aware Stub Resolver in DANE-aware application) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 22:35:42 -0000 On 30. 11. 2011, at 23:01, Jim Schaad wrote: >> --new text-- >> An application that complies with this document first requests TLSA >> records in order to make certificate associations. >>=20 >> Determining whether a TLSA RRset can be used depends >> on the DNSSEC validation state (as defined in [RFC4033]). >>=20 >> o A TLSA RRset whose DNSSEC validation state is secure MAY be used >> as a certificate association for TLS. >=20 > Can you elaborate on why you put a MAY here? I see that as an equivalent to: >> o A TLSA RRset whose DNSSEC validation state is secure can be used >> as a certificate association for TLS. 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 fanf2@hermes.cam.ac.uk Wed Nov 30 14:47: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 768D721F8B3E for ; Wed, 30 Nov 2011 14:47:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 UwvS0HkfSeZt for ; Wed, 30 Nov 2011 14:47:16 -0800 (PST) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id B6C5321F8B39 for ; Wed, 30 Nov 2011 14:47:16 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from 74.168.pn.adsl.brightview.com ([91.125.168.74]:61328 helo=[192.168.0.5]) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:587) with esmtpsa (PLAIN:fanf2) (TLSv1:AES128-SHA:128) id 1RVsvp-0001gT-Z3 (Exim 4.72) (return-path ); Wed, 30 Nov 2011 22:47:13 +0000 References: <201111302111.pAULB6Fq029234@fs4113.wdf.sap.corp> In-Reply-To: <201111302111.pAULB6Fq029234@fs4113.wdf.sap.corp> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <415C8E63-BE58-4219-8635-ED7F82220200@dotat.at> X-Mailer: iPhone Mail (9A405) From: Tony Finch Date: Wed, 30 Nov 2011 22:47:10 +0000 To: "mrex@sap.com" Sender: Tony Finch Cc: "dane@ietf.org" Subject: Re: [dane] Call for consensus on level of DNSSEC support X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 22:47:17 -0000 On 30 Nov 2011, at 21:11, Martin Rex wrote: >=20 > For usage types 0/1 (PKIX-validating cert), it really ought to be=20 >=20 > DNS Response is Bogus =3D> NO-INFO No, a bogus DNSSEC response implies you are under attack and that any TLS ce= rtificate is likely to have been issued by an untrustworthy CA. I think Ond=C5=99ej's proposed text is fine. Tony. -- f.anthony.n.finch http://dotat.at/= From mrex@sap.com Wed Nov 30 15:12: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 25B2621F8B77 for ; Wed, 30 Nov 2011 15:12:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.304 X-Spam-Level: X-Spam-Status: No, score=-9.304 tagged_above=-999 required=5 tests=[AWL=-0.574, BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2ghlcBU9NHD for ; Wed, 30 Nov 2011 15:12:13 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 4F36321F899D for ; Wed, 30 Nov 2011 15:12:13 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id pAUNC6f8008311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Dec 2011 00:12:06 +0100 (MET) From: Martin Rex Message-Id: <201111302312.pAUNC5d1006389@fs4113.wdf.sap.corp> To: ondrej.sury@nic.cz (=?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?=) Date: Thu, 1 Dec 2011 00:12:05 +2500 (MET) In-Reply-To: from "=?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?=" at Nov 30, 11 11:30:42 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] Call for consensus on level of DNSSEC support 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, 30 Nov 2011 23:12:14 -0000 =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= wrote: > > On 30. 11. 2011, at 22:23, Martin Rex wrote: >>>> DNS Response is Bogus => NO-INFO >>> >>> Can you say more about why you think this? >> >> I believe there is no reliable difference between Bogus and Indeterminate, >> the distinction has at best some minor relevance for admins while doing >> troubleshooting. >> >> http://tools.ietf.org/html/rfc4035#page-21 Bogus: An RRset for which the resolver believes that it ought to be able to establish a chain of trust but for which it is unable to do so, either due to signatures that for some reason fail to validate or due to missing data that the relevant DNSSEC RRs indicate should be present. This case may indicate an attack but may also indicate a configuration error or some form of data corruption. Indeterminate: An RRset for which the resolver is not able to determine whether the RRset should be signed, as the resolver is not able to obtain the necessary DNSSEC RRs. This can occur when the security-aware resolver is not able to contact security-aware name servers for the relevant zones. > > That discrepancy must be fixed in DNSEXT. We are using RFC 4033 definitions > of DNSSEC validation states. I fail to notice a difference. http://tools.ietf.org/html/rfc4033#page-10 Bogus: The validating resolver has a trust anchor and a secure delegation indicating that subsidiary data is signed, but the response fails to validate for some reason: missing signatures, expired signatures, signatures with unsupported algorithms, data missing that the relevant NSEC RR says should be present, and so forth. Indeterminate: There is no trust anchor that would indicate that a specific portion of the tree is secure. This is the default operation mode. If you have a roaming device with a secure resolver (i.e. the root zone key locally configured) and you are either a static host and behind a middle box that impairs DNS lookups but lets DS records pass, or a mobile host that is caching DNS records (including DS records for a zone) and you roam to an area where a middlebox prevents you from further receiving some of the zones records for whatever reason so that you can not perform a signature verification, then both 4033 and 4035 say that all lookups for that zone are to be flagged as "bogus". I believe DANE should avoid creating new interop problems. -Martin From cloos@jhcloos.com Wed Nov 30 17:17: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 4C15C21F8B2F for ; Wed, 30 Nov 2011 17:17:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 e1ZyPs-K6hjd for ; Wed, 30 Nov 2011 17:17:40 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by ietfa.amsl.com (Postfix) with ESMTP id A154F21F8510 for ; Wed, 30 Nov 2011 17:17:40 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 673534011C; Thu, 1 Dec 2011 01:17:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1322702258; bh=VDXuWwNqw0G1q98BohdpF/jG2yradN6OH4AQZzDyUdQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=zo5NyIDtvixe+SLYwYhxsXgPcJXAX9LjHmaO9VKpLI6iQNbO1DgQQsH34KxfLfumT rnFxKSU9tgfP1WtYZM6Ml20xnNF+DgLHt18C1L/kRHVXDAdB9ewU31xdnn5gEA7obE OHjgbxnE4gIliSMrdbUqpsNvHxg7CxwFYio9evOQ= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 52D0B36004E; Thu, 1 Dec 2011 01:10:56 +0000 (UTC) From: James Cloos To: =?utf-8?B?T25kxZllaiBTdXLDvQ==?= In-Reply-To: (=?utf-8?Q?=22O?= =?utf-8?Q?nd=C5=99ej_Sur=C3=BD=22's?= message of "Wed, 30 Nov 2011 17:59:43 +0100") References: User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.91 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2011 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Wed, 30 Nov 2011 20:10:55 -0500 Message-ID: Lines: 8 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:111201:ondrej.sury@nic.cz::wwuWdN2hBUJDkNb+:000000000000000000000000000000000000000000ToW/E X-Hashcash: 1:30:111201:dane@ietf.org::4xfafQhCTRudjhfV:000yrAAO Cc: IETF DANE WG list Subject: Re: [dane] Call for consensus on level of DNSSEC support (Security-aware Stub Resolver in DANE-aware application) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Dec 2011 01:17:41 -0000 OS> I think we already had a quite intensive discussion on this topic, OS> so please only express your opinion (+1 vs. -1) +1 -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From paul@xelerance.com Wed Nov 30 17:49: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 74D6821F8AB0 for ; Wed, 30 Nov 2011 17:49:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2LQH-Wclg33v for ; Wed, 30 Nov 2011 17:49:30 -0800 (PST) Received: from mx.xelerance.com (mx.xelerance.com [193.110.157.188]) by ietfa.amsl.com (Postfix) with ESMTP id B7DF221F85C7 for ; Wed, 30 Nov 2011 17:49:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx.xelerance.com (Postfix) with ESMTP id 0616110BD; Wed, 30 Nov 2011 20:49:28 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xelerance.com; h= content-transfer-encoding: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=1322704167; x=1323308967; bh=CScKbw6WFCf+HDzxxpWPJwC9nLb IRCVP1LnoBenIfu8=; b=aylZONds6kY2NPkyzU+5VQJGVkUVmBOLI5DQeOoJnWK aE5K8L5hT43ixqj1qJhwscEipDXM3Mw66L/cSsZQxRQxGXTHQOCVas9qJWs6UlHH eA/b7y5MoC+xdgN+quHcKDh43kwmuGtfqGrgoMcSkPrmxjH8IjRqMXBJ7WtI+rn0 = 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 bOchyBRCZIPh; Wed, 30 Nov 2011 20:49:27 -0500 (EST) 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 09462110; Wed, 30 Nov 2011 20:49:26 -0500 (EST) Received: by mail.xelerance.com (Postfix, from userid 1001) id A25A37FC; Wed, 30 Nov 2011 20:49:26 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.xelerance.com (Postfix) with ESMTP id A12F6553; Wed, 30 Nov 2011 20:49:26 -0500 (EST) Date: Wed, 30 Nov 2011 20:49:26 -0500 (EST) From: Paul Wouters To: =?ISO-8859-2?Q?Ond=F8ej_Sur=FD?= In-Reply-To: <30124937-44D0-484A-B040-7F15E90727AE@nic.cz> Message-ID: References: <48C7E091-64A9-4F27-A52F-06C681AD23B2@nic.cz> <000601ccafab$ac11ae10$04350a30$@augustcellars.com> <30124937-44D0-484A-B040-7F15E90727AE@nic.cz> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=ISO-8859-2 Content-Transfer-Encoding: 8BIT Cc: 'IETF DANE WG list' Subject: Re: [dane] Call for consensus on level of DNSSEC support (Security-aware Stub Resolver in DANE-aware application) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Dec 2011 01:49:31 -0000 On Wed, 30 Nov 2011, Ondøej Surý wrote: >>> o A TLSA RRset whose DNSSEC validation state is secure MAY be used >>> as a certificate association for TLS. >> >> Can you elaborate on why you put a MAY here? > > > I see that as an equivalent to: > >>> o A TLSA RRset whose DNSSEC validation state is secure can be used >>> as a certificate association for TLS. Not entirely. If I get a DNSSEC validated TLSA RRset, and I don't find a matching hash, the "MAY" suggests I'm fine not using it and trusting just other local policies like PKIX, thereby removing the TLSA protection. Perhaps these items need to contain both "whose DNSSE validation state is secure" and "contains a valid TLSA record matching the received TLS information"? Or perhaps it should be "MUST" whereupon missing a matching TLSA in a validating set leads to aborting? Paul (in general +1 for what is meant, but will monitor exact text) From i.grok@comcast.net Wed Nov 30 19:30: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 1C02E1F0C51 for ; Wed, 30 Nov 2011 19:30:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KtdW1g6PRdXN for ; Wed, 30 Nov 2011 19:30:46 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfa.amsl.com (Postfix) with ESMTP id 7768A1F0C36 for ; Wed, 30 Nov 2011 19:30:46 -0800 (PST) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta03.westchester.pa.mail.comcast.net with comcast id 3XaM1i0091uE5Es53fWnqH; Thu, 01 Dec 2011 03:30:47 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta16.westchester.pa.mail.comcast.net with comcast id 3fWm1i00X00PQ6U3cfWmgk; Thu, 01 Dec 2011 03:30:47 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.4/8.14.3) with ESMTP id pB13Ugk6013422 for ; Wed, 30 Nov 2011 22:30:42 -0500 Received: (from draco@localhost) by odin.ulthar.us (8.14.4/8.14.4/Submit) id pB13UfBW013420 for dane@ietf.org; Wed, 30 Nov 2011 22:30:41 -0500 Date: Wed, 30 Nov 2011 22:30:41 -0500 From: Scott Schmit To: dane@ietf.org Message-ID: <20111201033041.GA13361@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <48C7E091-64A9-4F27-A52F-06C681AD23B2@nic.cz> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="zhXaljGHf11kAtnf" Content-Disposition: inline In-Reply-To: <48C7E091-64A9-4F27-A52F-06C681AD23B2@nic.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Call for consensus on level of DNSSEC support (Security-aware Stub Resolver in DANE-aware application) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Dec 2011 03:30:47 -0000 --zhXaljGHf11kAtnf Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 30, 2011 at 10:07:32PM +0100, Ond=C5=99ej Sur=C3=BD wrote: > --new text-- > An application that complies with this document first requests TLSA > records in order to make certificate associations. >=20 > Determining whether a TLSA RRset can be used depends > on the DNSSEC validation state (as defined in [RFC4033]). >=20 > o A TLSA RRset whose DNSSEC validation state is secure MAY be used > as a certificate association for TLS. >=20 > o If the DNSSEC validation state on the response to the request > for the TLSA RRset is bogus, this MUST cause TLS not to be started > or, if the TLS negotiation is already in progress, to cause > the connection to be aborted. >=20 > o A TLSA RRset whose DNSSEC validation state is indeterminate or > insecure cannot be used for TLS and MUST be marked as unusable. > --new text-- +1 --=20 Scott Schmit --zhXaljGHf11kAtnf Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQJgYJKoZIhvcNAQcCoIIQFzCCEBMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DVcwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBxswggYDoAMCAQICAwK+HTANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTExMDcxNzA1 MDQwNFoXDTEyMDcxNzExNDI1OVowYjEgMB4GA1UEDRMXNDY1MjU2LTBnRmI2Sk5ZWW44QnFW bUwxGzAZBgNVBAMMEmkuZ3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9r QGNvbWNhc3QubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2AjLOMsBGaqN hv2FcRbfom/QCeKMXu5tUd1JY5oIDZe5y29stnd+se/zUlEkiVeMam4Jgo1c8yGNnwLVYc5/ 9xVi7Qg1Is5b9AB6aJWElJDw/jIdihymNZ2kwkSLT0wl/lzd0mXlwFJPRgQiRkmE6V0ZmjsQ jaVtllVleGBbMvmWPm92e+4Bju9P81kKz7Xr02ijETmaPdVsl+jmOaKPS8Y+2Lat2xus4Ked oJ/7aIWIpz1gRSKjAHSZ1Wmwi2TYUjYhZryChu9e1RWtqk1CycNoeusJ8xdEVN3WSnJ299w/ 3ltK/x/9rpj2j9ShQZVB4NnX6cjQs7pz1lVxvIkjcQIDAQABo4IDrTCCA6kwCQYDVR0TBAIw ADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBQ29j2I0O8sRYi0So9NwwmT1caakDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhR gjAdBgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwggIhBgNVHSAEggIYMIICFDCCAhAG CysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJt ZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUF BwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJp bGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFu ZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0 cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQAZ5U0nL/2PQwsVfHgN7MVPbZEGzDzuj4Oy pTgz4XQFwPcCuy6U9sp1Dwmo3DyKX5nKN4xA7pslN+2Pl/kElGamX7zMCAH0xED0RTOLyk+v nDML4s+OUtWaYVnq1bZEp0F8Luq3zIslAYSebleyiz8M0EypZczsL5rOk86R2F9EYw1CBuFJ 5a4x0CmNu5o30fGNDFt+iXRlbJPp/KY25iUgVnBzJ4COT5kQjxn5lgr4t1I+BDCL5HQQ3h/8 2CzwrWVRBNb9Vqh9LL1ZtzYRt8JezoB6HkVvcKVNGlCZ+/MnvfMzPLwfbTDZC8o4d+4RH6aE LeGF2XmAOaenc/YRqm9oMYIClzCCApMCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQIDAr4dMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTExMjAxMDMzMDQxWjAjBgkqhkiG9w0BCQQxFgQU8rSSZODN 9XK13hTlPCQdwCThOR8weQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAopLwXC30 tyxq8ViHJv/Hmv0jLxCI0urtQuUiKN7Bc1xlii3jKUMU32kjWW+Mi/3yaZ4Hq3R+p+G6mLjq yAMDXIiB8WMrrKkfVWfMYeii9T7zQIRThS+SwGsvLgaZjb8iEpAx9ideYRXx9nIMbV0gdswY NdFugssaR1Pv0pftacjgObpf41NMy0gouPzv+4AjHnz24vhII0a9ee7OEHD3pX+KecJX2o0E OoT2O4OcihR7gAQKlBKN0TRKHkr12+tunJ4gHmNnwIPP6LvpJVYABI1oBe5FJr6WWNBK8SFG PNic9yI2n2Ze5/ZjYSOlIAWydwRg7SBStuVkp3r+s/66tw== --zhXaljGHf11kAtnf-- From rbarnes@bbn.com Wed Nov 30 19:47:03 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2703221F84D2 for ; Wed, 30 Nov 2011 19:47:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqLK2jOjdMGP for ; Wed, 30 Nov 2011 19:47:02 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id A539C21F84FD for ; Wed, 30 Nov 2011 19:47:02 -0800 (PST) Received: from [128.89.255.215] (port=49458 helo=[192.168.1.4]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RVxbs-000LXK-6a; Wed, 30 Nov 2011 22:46:57 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Wed, 30 Nov 2011 22:46:56 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4020ACAD-CCA3-4A47-8E63-42C44194F47A@bbn.com> References: <48C7E091-64A9-4F27-A52F-06C681AD23B2@nic.cz> <000601ccafab$ac11ae10$04350a30$@augustcellars.com> <30124937-44D0-484A-B040-7F15E90727AE@nic.cz> To: Paul Wouters X-Mailer: Apple Mail (2.1084) Cc: 'IETF DANE WG list' Subject: Re: [dane] Call for consensus on level of DNSSEC support (Security-aware Stub Resolver in DANE-aware application) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Dec 2011 03:47:03 -0000 >>>> o A TLSA RRset whose DNSSEC validation state is secure MAY be used >>>> as a certificate association for TLS. >>>=20 >>> Can you elaborate on why you put a MAY here? >>=20 >>=20 >> I see that as an equivalent to: >>=20 >>>> o A TLSA RRset whose DNSSEC validation state is secure can be used >>>> as a certificate association for TLS. >=20 > Not entirely. If I get a DNSSEC validated TLSA RRset, and I don't = find a > matching hash, the "MAY" suggests I'm fine not using it and trusting = just > other local policies like PKIX, thereby removing the TLSA protection. >=20 > Perhaps these items need to contain both "whose DNSSE validation state = is secure" > and "contains a valid TLSA record matching the received TLS = information"? >=20 > Or perhaps it should be "MUST" whereupon missing a matching TLSA in a = validating > set leads to aborting? >=20 > Paul > (in general +1 for what is meant, but will monitor exact text) This logic seems kind of sensible. If you're doing this specification, = you MUST interpret whatever TLSA records you find. If you're going to = ignore secure records, you're just not doing DANE. =20 Consider the reverse: What if someone does follows the bogus and "other" = cases (the MUSTs), but *not* the secure case (the MAY)? In that case, = all they're getting is FAIL or NO-INFO; basically they're testing to see = if DNSSEC works on TLSA records. This doesn't seem tremendously = valuable, so I'm comfortable ruling it out. --Richard From zack.weinberg@gmail.com Wed Nov 30 19:55: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 7EE1221F87D9 for ; Wed, 30 Nov 2011 19:55:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.083 X-Spam-Level: X-Spam-Status: No, score=-2.083 tagged_above=-999 required=5 tests=[AWL=0.894, 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 ZmJATmP1ys4r for ; Wed, 30 Nov 2011 19:55:24 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 076C621F8753 for ; Wed, 30 Nov 2011 19:55:23 -0800 (PST) Received: by ggnp4 with SMTP id p4so1712264ggn.31 for ; Wed, 30 Nov 2011 19:55:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Ch4+EV/XDyz2ztn8wnLP7XEbs5TDE+eklwaXSE4NcKs=; b=D8eIUJczuAnn3gBhCtHe6FDgh+ore3UbNE6BjK7+u+tJK3a/Qdc4ZDyuFYLVHOnhzq B2n2vAVlWZMXSQ3mTQzXdQED+ad1/IR9G2WEfePo+HLQ4fV71YYwAAdQavTYmOUwrnjR q+5hU08liG9lkoDRIq10CBVq8eyUaoKRMydAA= MIME-Version: 1.0 Received: by 10.182.59.49 with SMTP id w17mr1075359obq.37.1322711722898; Wed, 30 Nov 2011 19:55:22 -0800 (PST) Sender: zack.weinberg@gmail.com Received: by 10.182.88.103 with HTTP; Wed, 30 Nov 2011 19:55:22 -0800 (PST) In-Reply-To: <4020ACAD-CCA3-4A47-8E63-42C44194F47A@bbn.com> References: <48C7E091-64A9-4F27-A52F-06C681AD23B2@nic.cz> <000601ccafab$ac11ae10$04350a30$@augustcellars.com> <30124937-44D0-484A-B040-7F15E90727AE@nic.cz> <4020ACAD-CCA3-4A47-8E63-42C44194F47A@bbn.com> Date: Wed, 30 Nov 2011 19:55:22 -0800 X-Google-Sender-Auth: V8AdJIPHIVPgtAc1nTDHr4LwyAA Message-ID: From: Zack Weinberg To: "Richard L. Barnes" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IETF DANE WG list Subject: Re: [dane] Call for consensus on level of DNSSEC support (Security-aware Stub Resolver in DANE-aware application) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Dec 2011 03:55:24 -0000 On Wed, Nov 30, 2011 at 7:46 PM, Richard L. Barnes wrote: >> >> Not entirely. If I get a DNSSEC =C2=A0validated TLSA RRset, and I don't = find a >> matching hash, the "MAY" suggests I'm fine not using it and trusting jus= t >> other local policies like PKIX, thereby removing the TLSA protection. >> >> Perhaps these items need to contain both "whose DNSSE validation state i= s secure" >> and "contains a valid TLSA record matching the received TLS information"= ? >> >> Or perhaps it should be "MUST" whereupon missing a matching TLSA in a va= lidating >> set leads to aborting? > > This logic seems kind of sensible. =C2=A0If you're doing this specificati= on, you MUST > interpret whatever TLSA records you find. =C2=A0If you're going to ignore= secure records, > you're just not doing DANE. I don't think DANE should override a local determination that some certificate is never to be trusted (explicit blacklist, that is, not just default-untrusted). Can we make sure we allow local policy to do that? zw From rbarnes@bbn.com Wed Nov 30 20:03: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 4889911E8097 for ; Wed, 30 Nov 2011 20:03:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVwOotuCe6np for ; Wed, 30 Nov 2011 20:03:54 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id CDF3411E8090 for ; Wed, 30 Nov 2011 20:03:54 -0800 (PST) Received: from [128.89.255.215] (port=49482 helo=[192.168.1.4]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RVxsH-000Ld7-DV; Wed, 30 Nov 2011 23:03:53 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Wed, 30 Nov 2011 23:03:53 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <357B474A-A161-45CC-888C-F867869FD72B@bbn.com> References: <48C7E091-64A9-4F27-A52F-06C681AD23B2@nic.cz> <000601ccafab$ac11ae10$04350a30$@augustcellars.com> <30124937-44D0-484A-B040-7F15E90727AE@nic.cz> <4020ACAD-CCA3-4A47-8E63-42C44194F47A@bbn.com> To: Zack Weinberg X-Mailer: Apple Mail (2.1084) Cc: IETF DANE WG list Subject: Re: [dane] Call for consensus on level of DNSSEC support (Security-aware Stub Resolver in DANE-aware application) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Dec 2011 04:03:55 -0000 >>> Not entirely. If I get a DNSSEC validated TLSA RRset, and I don't = find a >>> matching hash, the "MAY" suggests I'm fine not using it and trusting = just >>> other local policies like PKIX, thereby removing the TLSA = protection. >>>=20 >>> Perhaps these items need to contain both "whose DNSSE validation = state is secure" >>> and "contains a valid TLSA record matching the received TLS = information"? >>>=20 >>> Or perhaps it should be "MUST" whereupon missing a matching TLSA in = a validating >>> set leads to aborting? >>=20 >> This logic seems kind of sensible. If you're doing this = specification, you MUST >> interpret whatever TLSA records you find. If you're going to ignore = secure records, >> you're just not doing DANE. >=20 > I don't think DANE should override a local determination that some > certificate is never to be trusted (explicit blacklist, that is, not > just default-untrusted). Can we make sure we allow local policy to do > that? Do we really need to say anything about this? ISTM that local policy = can always override. Keep in mind that DANE validation is a part of the = overall certificate acceptance process. There are already other checks = (e.g., name checks) that get applied by the application layer; checking = blacklists could be part of that. =20 Besides, if you see the cert and it's on your black-list, why would you = go to the trouble of invoking DANE? =20 --Richard= From paul@xelerance.com Wed Nov 30 20:09: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 ED74111E8090 for ; Wed, 30 Nov 2011 20:09:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 5LCeqTgBNJee for ; Wed, 30 Nov 2011 20:09:05 -0800 (PST) Received: from mx.xelerance.com (mx.xelerance.com [193.110.157.188]) by ietfa.amsl.com (Postfix) with ESMTP id E940D11E80AA for ; Wed, 30 Nov 2011 20:09:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx.xelerance.com (Postfix) with ESMTP id A0D7210A9; Wed, 30 Nov 2011 23:08:58 -0500 (EST) 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=1322712537; x= 1323317337; bh=+91n3CKSvfIz4e+GQS1FFnQfqxMsXM+u40hpUtKSolo=; b=E KI/xuey7AwGizQCHwntnUbFQ+taeroGjnZSy0P6YuuI+r9lTo6FM6JvJCTV/DpFV iRm8L7SCwTADGoHgwgSPal8lNlGRfxfaGp1n+xokz80ngbyczXhZRmdJG6j1mLUm eMjaj4XuWDK0YOrDhyRjZqMTXd1l8CZ/y8iSBHshL4= 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 6hTJriwvEeMf; Wed, 30 Nov 2011 23:08:57 -0500 (EST) 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 C58D3201; Wed, 30 Nov 2011 23:08:56 -0500 (EST) Received: by mail.xelerance.com (Postfix, from userid 1001) id 981EC7FC; Wed, 30 Nov 2011 23:08:56 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.xelerance.com (Postfix) with ESMTP id 928E3553; Wed, 30 Nov 2011 23:08:56 -0500 (EST) Date: Wed, 30 Nov 2011 23:08:56 -0500 (EST) From: Paul Wouters To: "Richard L. Barnes" In-Reply-To: <357B474A-A161-45CC-888C-F867869FD72B@bbn.com> Message-ID: References: <48C7E091-64A9-4F27-A52F-06C681AD23B2@nic.cz> <000601ccafab$ac11ae10$04350a30$@augustcellars.com> <30124937-44D0-484A-B040-7F15E90727AE@nic.cz> <4020ACAD-CCA3-4A47-8E63-42C44194F47A@bbn.com> <357B474A-A161-45CC-888C-F867869FD72B@bbn.com> 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] Call for consensus on level of DNSSEC support (Security-aware Stub Resolver in DANE-aware application) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Dec 2011 04:09:06 -0000 On Wed, 30 Nov 2011, Richard L. Barnes wrote: >>>> Not entirely. If I get a DNSSEC validated TLSA RRset, and I don't find a >>>> matching hash, the "MAY" suggests I'm fine not using it and trusting just >>>> other local policies like PKIX, thereby removing the TLSA protection. >>>> >>>> Perhaps these items need to contain both "whose DNSSE validation state is secure" >>>> and "contains a valid TLSA record matching the received TLS information"? >>>> >>>> Or perhaps it should be "MUST" whereupon missing a matching TLSA in a validating >>>> set leads to aborting? >>> >>> This logic seems kind of sensible. If you're doing this specification, you MUST >>> interpret whatever TLSA records you find. If you're going to ignore secure records, >>> you're just not doing DANE. >> >> I don't think DANE should override a local determination that some >> certificate is never to be trusted (explicit blacklist, that is, not >> just default-untrusted). Can we make sure we allow local policy to do >> that? > > Do we really need to say anything about this? ISTM that local policy can always override. Keep in mind that DANE validation is a part of the overall certificate acceptance process. There are already other checks (e.g., name checks) that get applied by the application layer; checking blacklists could be part of that. > > Besides, if you see the cert and it's on your black-list, why would you go to the trouble of invoking DANE? I just wanted to make clear that IF an application implements DANE, and it gets a TLSA RRset that does validate to a trust anchor AND there is no matching TLSA record for the TLS connection that it MUST abort. I think the "MAY" in the proposed text could be misread to mean if no matching TLSA is found in the obtained validated RRset, go try something else to validate the key. Paul From jakob@kirei.se Wed Nov 30 20:12: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 8CF6411E80AD for ; Wed, 30 Nov 2011 20:12:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.398 X-Spam-Level: X-Spam-Status: No, score=-0.398 tagged_above=-999 required=5 tests=[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 q-sJI0rDijjX for ; Wed, 30 Nov 2011 20:12:07 -0800 (PST) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id 7A28811E8090 for ; Wed, 30 Nov 2011 20:12:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=86pjZyUAxMLC+7Rv7/j6yfgGdxwiasMi6W95lD+pg3g=; b=KkcnIiONmduOsmsnEwrF7QhoB+CD/m18CazxKrX6onkc/36nsK2Q2sLJlEkaY2SjNlWMOAcGsJKwr 7RI4n0B9MD0VfUJFHEOt3hpoDuPPKIc4qMRwl6Vw9VhTNp/qbP8PZyPHn34h9RIBBTu458XYTPtnyC dOnVHWy7TL2wnAlA= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Thu, 1 Dec 2011 05:12:03 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: Jakob Schlyter In-Reply-To: <48C7E091-64A9-4F27-A52F-06C681AD23B2@nic.cz> Date: Thu, 1 Dec 2011 05:11:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <16C4B1FB-2176-4E70-A362-70FED227744A@kirei.se> References: <48C7E091-64A9-4F27-A52F-06C681AD23B2@nic.cz> To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= X-Mailer: Apple Mail (2.1251.1) Cc: IETF DANE WG list Subject: Re: [dane] Call for consensus on level of DNSSEC support (Security-aware Stub Resolver in DANE-aware application) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Dec 2011 04:12:07 -0000 On 30 nov 2011, at 22:07, Ond=C5=99ej Sur=C3=BD wrote: > --new text-- > An application that complies with this document first requests TLSA > records in order to make certificate associations. >=20 > Determining whether a TLSA RRset can be used depends > on the DNSSEC validation state (as defined in [RFC4033]). >=20 > o A TLSA RRset whose DNSSEC validation state is secure MAY be used > as a certificate association for TLS. >=20 > o If the DNSSEC validation state on the response to the request > for the TLSA RRset is bogus, this MUST cause TLS not to be started > or, if the TLS negotiation is already in progress, to cause > the connection to be aborted. >=20 > o A TLSA RRset whose DNSSEC validation state is indeterminate or > insecure cannot be used for TLS and MUST be marked as unusable. > --new text-- +1 jakob From matt@mattmccutchen.net Wed Nov 30 20:56: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 7077B11E80B4 for ; Wed, 30 Nov 2011 20:56:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LyJs+xBBhFPX for ; Wed, 30 Nov 2011 20:56:42 -0800 (PST) Received: from homiemail-a7.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC3411E80B1 for ; Wed, 30 Nov 2011 20:56:42 -0800 (PST) Received: from homiemail-a7.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a7.g.dreamhost.com (Postfix) with ESMTP id 9EF3725C062; Wed, 30 Nov 2011 20:56:41 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=message-id :subject:from:to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:mime-version; q=dns; s= mattmccutchen.net; b=VVOZP63vXWerjW5zkWF45Od7FLLcBXDGuhANR7mkneG 5S+iDmW2oSKgSU2JBM3PFhxiRl5XhJcu/HpR+QEDRX2yqWd++7ilD4gjOxJw58c4 aXqR6TuKyLzGswycP+tNu1+SihorDFytUFLt5Vmuzj5vFehiQ2z2fX2wRFy0+O3s = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= message-id:subject:from:to:cc:date:in-reply-to:references :content-type:content-transfer-encoding:mime-version; s= mattmccutchen.net; bh=UK2DvTqhX9Oee3ElqPmnjgJoTe8=; b=ITIqjgghf1 ibC1Czte6mNlwgy+H9wgiRagJm4h3CUkIZ+JyGCSmKyBEXlMBaStd4+pYj/ZqsaX ttTKD1ZSRckWG1/2z0QQGJotJdaSVdxfUN8EDBbxovK2Kd4vXUspnMQgCk6Jgizv DgyBnZn1W58+9Cfw1ANl9sM0U+MLH2wSM= 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 7052925C061; Wed, 30 Nov 2011 20:56:41 -0800 (PST) Message-ID: <1322715400.32630.9.camel@localhost> From: Matt McCutchen To: Paul Hoffman Date: Wed, 30 Nov 2011 20:56:40 -0800 In-Reply-To: <7BA32289-B2B1-4B07-A5EA-69F5F556FC8E@vpnc.org> References: <48C7E091-64A9-4F27-A52F-06C681AD23B2@nic.cz> <7BA32289-B2B1-4B07-A5EA-69F5F556FC8E@vpnc.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Cc: IETF DANE WG list Subject: Re: [dane] Call for consensus on level of DNSSEC support (Security-aware Stub Resolver in DANE-aware application) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Dec 2011 04:56:46 -0000 On Wed, 2011-11-30 at 14:19 -0800, Paul Hoffman wrote: > On Nov 30, 2011, at 2:07 PM, Yoav Nir wrote: > > > Except, why is that a MAY on the first bullet? If you're not going > to act on a DNSSEC-validated TLSA record, what's the point of > implementing this specification? > > There may be other policy that would cause you to not use the > certificate association. For example, assume that you *only* trust > certs from YourOwnCA when communicating with > any.domain.under.yourowncompany.com. You go to > misconfigured.yourowncompany.com and get a TLSA record type 0 that is > issued by SomeOtherCA. Your local policy should be able to trump the > TLSA record. Does local policy override the restrictive part of TLSA or only the additive part? I.e., is a client that accepts a cert from YourOwnCA for misconfigured.yourowncompany.com regardless of the TLSA RRset conformant? From the "MAY", I am not sure. -- Matt From ynir@checkpoint.com Wed Nov 30 23:26: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 D92C121F84D7 for ; Wed, 30 Nov 2011 23:26:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.419 X-Spam-Level: X-Spam-Status: No, score=-10.419 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F9ZVVQjjntDq for ; Wed, 30 Nov 2011 23:26:17 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 0493021F84D5 for ; Wed, 30 Nov 2011 23:26:16 -0800 (PST) X-CheckPoint: {4ED72B32-2-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id pB17Q8o3026981; Thu, 1 Dec 2011 09:26:09 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 1 Dec 2011 09:26:08 +0200 From: Yoav Nir To: =?utf-8?B?T25kxZllaiBTdXLDvQ==?= Date: Thu, 1 Dec 2011 09:26:08 +0200 Thread-Topic: [dane] Call for consensus on level of DNSSEC support (Security-aware Stub Resolver in DANE-aware application) Thread-Index: Acyv+n4Gr4Lua9dnTTCCxYp40kINDA== Message-ID: <86A71405-68C1-4A37-B8E2-1291ED617771@checkpoint.com> References: <48C7E091-64A9-4F27-A52F-06C681AD23B2@nic.cz> <000601ccafab$ac11ae10$04350a30$@augustcellars.com> <30124937-44D0-484A-B040-7F15E90727AE@nic.cz> In-Reply-To: <30124937-44D0-484A-B040-7F15E90727AE@nic.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: IETF DANE WG list Subject: Re: [dane] Call for consensus on level of DNSSEC support (Security-aware Stub Resolver in DANE-aware application) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Dec 2011 07:26:18 -0000 DQpPbiBEZWMgMSwgMjAxMSwgYXQgMTI6MzUgQU0sIE9uZMWZZWogU3Vyw70gd3JvdGU6DQoNCj4g DQo+IE9uIDMwLiAxMS4gMjAxMSwgYXQgMjM6MDEsIEppbSBTY2hhYWQgd3JvdGU6DQo+Pj4gLS1u ZXcgdGV4dC0tDQo+Pj4gIEFuIGFwcGxpY2F0aW9uIHRoYXQgY29tcGxpZXMgd2l0aCB0aGlzIGRv Y3VtZW50IGZpcnN0IHJlcXVlc3RzIFRMU0ENCj4+PiAgcmVjb3JkcyBpbiBvcmRlciB0byBtYWtl IGNlcnRpZmljYXRlIGFzc29jaWF0aW9ucy4NCj4+PiANCj4+PiAgRGV0ZXJtaW5pbmcgd2hldGhl ciBhIFRMU0EgUlJzZXQgY2FuIGJlIHVzZWQgZGVwZW5kcw0KPj4+ICBvbiB0aGUgRE5TU0VDIHZh bGlkYXRpb24gc3RhdGUgKGFzIGRlZmluZWQgaW4gW1JGQzQwMzNdKS4NCj4+PiANCj4+PiAgbyBB IFRMU0EgUlJzZXQgd2hvc2UgRE5TU0VDIHZhbGlkYXRpb24gc3RhdGUgaXMgc2VjdXJlIE1BWSBi ZSB1c2VkDQo+Pj4gICAgYXMgYSBjZXJ0aWZpY2F0ZSBhc3NvY2lhdGlvbiBmb3IgVExTLg0KPj4g DQo+PiBDYW4geW91IGVsYWJvcmF0ZSBvbiB3aHkgeW91IHB1dCBhIE1BWSBoZXJlPw0KPiANCj4g DQo+IEkgc2VlIHRoYXQgYXMgYW4gZXF1aXZhbGVudCB0bzoNCj4gDQo+Pj4gIG8gQSBUTFNBIFJS c2V0IHdob3NlIEROU1NFQyB2YWxpZGF0aW9uIHN0YXRlIGlzIHNlY3VyZSBjYW4gYmUgdXNlZA0K Pj4+ICAgIGFzIGEgY2VydGlmaWNhdGUgYXNzb2NpYXRpb24gZm9yIFRMUy4NCg0KSSB0aGluayB0 aGUgc2Vjb25kIHZlcnNpb24gaXMgYmV0dGVyLiBBcyBQYXVsIFcgc2FpZCwgdGhlIG5vcm1hdGl2 ZSBsYW5ndWFnZSBpcyBjb25mdXNpbmcgaGVyZS4NCg0KQnV0ICsxIGVpdGhlciB3YXkuDQoNCg0K