From kivinen@iki.fi Sat Nov 3 18:02:44 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51EA121F992A for ; Sat, 3 Nov 2012 18:02:44 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pv9GsKaEYYt2 for ; Sat, 3 Nov 2012 18:02:43 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 791A621F98D7 for ; Sat, 3 Nov 2012 18:02:43 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id qA412adN008847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Nov 2012 03:02:36 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id qA412a2A006060; Sun, 4 Nov 2012 03:02:36 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20629.48812.92331.28195@fireball.kivinen.iki.fi> Date: Sun, 4 Nov 2012 03:02:36 +0200 From: Tero Kivinen To: dot@dotat.at, dane@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 15 min X-Total-Time: 16 min X-Mailman-Approved-At: Sun, 04 Nov 2012 00:55:40 -0700 Subject: [dane] Comments to the draft-fanf-dane-mua-00 draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 04 Nov 2012 01:02:44 -0000 In section "3. Mail server TLSA records", it would be nice to have example of these records, in the same way where the draft-fanf-dane-smtp-04 has. It is bit hard to follow what kind of records there should be just from the text. Also it would be better to expand the document name from the reference, i.e. not use references in format of: ---------------------------------------------------------------------- MUAs SHALL look up the TLSA record(s) for a mail server using its host name and port number, as described in section 3 of [I-D.ietf-dane-protocol]. ---------------------------------------------------------------------- Now it is still understandable, as the draft name tells what document it is, but when it changes to [RFC5432] (or whatever the dane protocol rfc is) the for casual reader it gets very hard to follow, as reader always needs to jump to the references to see which document this magic number was again... Changing that to: ---------------------------------------------------------------------- MUAs SHALL look up the TLSA record(s) for a mail server using its host name and port number, as described in section 3 of base DANE protocol [RFC6698]. ---------------------------------------------------------------------- Then casual reader can see which document you refer to without jumping to actual refences section. In quite few place you already have this ok, (SMTP, POP3, IMAP etc), but RFC6186 and this dane-protocol references are at least missing all descriptive text, they only have reference. I think the document should be understandable, even if you remove all references (i.e. text between []) or replace them with just running counter number. -- kivinen@iki.fi From kivinen@iki.fi Sat Nov 3 18:08:29 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF42921F86CB for ; Sat, 3 Nov 2012 18:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eIgGcuAXn+HZ for ; Sat, 3 Nov 2012 18:08:29 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3D81121F8542 for ; Sat, 3 Nov 2012 18:08:29 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id qA418PSG019981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Nov 2012 03:08:25 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id qA418NVW000193; Sun, 4 Nov 2012 03:08:23 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20629.49159.266147.544247@fireball.kivinen.iki.fi> Date: Sun, 4 Nov 2012 03:08:23 +0200 From: Tero Kivinen To: dot@dotat.at, dane@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 6 min X-Total-Time: 5 min X-Mailman-Approved-At: Sun, 04 Nov 2012 00:55:40 -0700 Subject: [dane] Comments to draft-fanf-dane-smtp-04.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 01:08:30 -0000 In section "5. The Transmitted: header field", it would be nice to have example of what the Transmitted header looks like. Or it could be in the appendix A.2 or similar along with other examples. Now reading only the (partial) ABNF makes understanding how the actual header looks like, quite hard. There is also typo at section 3.2: s/as descrbed below./as described below./ -- kivinen@iki.fi From ondrej.mikle@nic.cz Tue Nov 6 08:45:40 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5691821F8905 for ; Tue, 6 Nov 2012 08:45: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ir5t9iJ3Id71 for ; Tue, 6 Nov 2012 08:45:39 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 98DCA21F8A63 for ; Tue, 6 Nov 2012 08:45:39 -0800 (PST) Received: from [IPv6:2001:1488:ac14:1400:221:ccff:fe72:8878] (unknown [IPv6:2001:1488:ac14:1400:221:ccff:fe72:8878]) by mail.nic.cz (Postfix) with ESMTPSA id A805A13FA24 for ; Tue, 6 Nov 2012 17:45:38 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1352220338; bh=4YHT0ZnygrZIHTL3buKhsYRAHqLKX7cDTS+Z94rlw88=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type; b=IJKNvGX0BhynWLLoERJj6FbURM87F6CnSckl46YOhvxL6MBJE2becMPDpOr67sptw 4pyM9SZtIBLF4MiTujdpEtcTEpVKVEkWZeJ7bl1PIBugRL57U0dddzVFRNpRxrsIFJ LbI6ggXLr1XaWdG66PZypgvgpTCGV8waF7UZnzn4= Message-ID: <50993EAC.1050602@nic.cz> Date: Tue, 06 Nov 2012 17:45:32 +0100 From: Ondrej Mikle User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: dane@ietf.org X-Enigmail-Version: 1.4.5 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigBB45848DEA591095E0CC671E" X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: [dane] Dane Patrol Firefox addon, version 0.2.3 (with official project page and git repo now) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 16:45:40 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBB45848DEA591095E0CC671E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, I've updated Dane Patrol to version 0.2.3, project page is here (click En= glish on top if you don't get EN version, web takes language preferences from browser's headers): https://labs.nic.cz/page/1207/dane-patrol/ The git repository (also mentioned on the page) is available at: git://git.nic.cz/dane-patrol Short changelog against the 0.1.0 that was posted here: - the "untrusted certificate page" can be overriden if TLSA matches (cert= ificate usage 2/3; by default turned on, can be disabled in preferences) - build now works on Linux and Mac, i686/x86_64 (prebuilt XPI files avail= able for download) - bump to latest stable set of dependent libraries (ldns 1.6.15 was relea= sed in the meantime) - switch to CMake (and many internal toolchain changes) Ondrej Mikle --------------enigBB45848DEA591095E0CC671E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iQEcBAEBCAAGBQJQmT6yAAoJEAy6xNgMZCEgNIAH/1BLTUkFNkcnbhivQIKm95TQ UT43YLI+l+QA4d9+15ZmCZFmpet1gIWyHrDPYk/cI9m27HkdWyvarQyPm5xsdtGS CFnU8ZQ5Eiz8HoEb52nLdu4SkEbNyLE6lDnLu8HmKmql1KwB71IYFZgHkxCHLpVj i13jPyCO2N6t959W6j6lboWMmHEjIlLUzxRA+swJcQZIz1sLjXyGiKGLaiSE12Nl 1Ids1urm/5LnoXUTZF+YOSda9KCw9qezQ131Wyl0u2IEPSorKLxxukE4xZKv/4FH CYVDg6GRcavmD3XRHS9zGlTxGsOLvsFuX9HHqhLMvxZJnX/U7uNdDFkClc1i2ok= =wCf0 -----END PGP SIGNATURE----- --------------enigBB45848DEA591095E0CC671E-- From rafiee@hpi.uni-potsdam.de Thu Nov 8 06:35:50 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15B4421F8A78; Thu, 8 Nov 2012 06:35:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.19 X-Spam-Level: X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9DGO+lzZAVdt; Thu, 8 Nov 2012 06:35:45 -0800 (PST) Received: from mail3.hpi.uni-potsdam.de (mail3.hpi.uni-potsdam.de [IPv6:2001:638:807:204::8d59:e17b]) by ietfa.amsl.com (Postfix) with ESMTP id 5295821F85E2; Thu, 8 Nov 2012 06:35:44 -0800 (PST) Received: from owa2.hpi.uni-potsdam.de (owa2.hpi.uni-potsdam.de [141.89.225.162]) by mail3.hpi.uni-potsdam.de (Postfix) with ESMTP id 7AF44169E9A; Thu, 8 Nov 2012 15:35:43 +0100 (CET) Received: from 8MXMA1R.hpi.uni-potsdam.de ([fe80::88e9:3d98:b35f:83bf]) by OWA2.hpi.uni-potsdam.de ([2002:8d59:e1a2::8d59:e1a2]) with mapi; Thu, 8 Nov 2012 15:35:43 +0100 From: "Rafiee, Hosnieh" To: "dnsext@ietf.org" Date: Thu, 8 Nov 2012 15:35:38 +0100 Thread-Topic: (CGA-TSIG) answers to some of the comments Thread-Index: Ac29vlJpDwbxbx0jQ3OwHMTGE8GlsA== Message-ID: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_EA738325B0580041A50A364F5F76B68924D4465CF88MXMA1Rhpiuni_" MIME-Version: 1.0 Cc: "dane@ietf.org" Subject: Re: [dane] (CGA-TSIG) answers to some of the comments X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 14:35:50 -0000 --_000_EA738325B0580041A50A364F5F76B68924D4465CF88MXMA1Rhpiuni_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dave, 1) Having the DHCP server do dynamic update is not necessarily just for add= resses allocated by DHCP. See http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 which is= a DHC WG draft. Thanks a lot for your answer. Please check the consideration section of the= draft you referred to. The stated approach is prone to attacks as it is so= lely about an extra management efforts and not security approaches. To prev= ent the attacks it also stated using SEND. Now the question is, when you want to use SEND to secure your local network= , my approach is also applicable and better fits than TSIG itself as you do= not need to generate public private keys, CGA and you use the same value a= vailable there. DHCPv6 is only useful when you would like to have more management and admin= istration control on your network. But, if you only want to know who used w= hich address, you do not need to go to extra configuration , you need just = a passive monitoring system in the network to sniff all ICMPv6 unsolicited = Neighbor advertisement packets and delete them from the monitoring database= if receive no more NA messages from that node. (frequently nodes update th= eir cache and send NA) 2- Is not true. DNS information is not the only information obtained thro= ugh DHCP, it's a general purpose mechanism through which many things are, and can be, obtained. It is a bad idea to = try to pollute RAs with such information (for one, you're limited to the MTU in RAs). See RFC 5505 section 2.3 for = some more discussion. DNS information is just an information missing in NDP. For addressing not m= ore option is required for a node. I am not quite understand and convinced = that why every time you change the talk to DHCPv6. I am talking about the n= etworks where SEND is used and not DHCPv6. I do not have any discussion abo= ut whether or not the DNS options in RAs is the best. 3- RFC 6434 section 6 even states "Hosts will need to decide which mechanism (or whether both) should be implemented." The fact that we actually have two mechanisms is a bad thing. This is why based on the network requirements, administrator can choose whi= ch one to use. 3) The main feedback some of us provided is that the proposal would be far = more widely applicable and useful if it just passed a public key and used the le= ap of faith model like SSH, rather than narrowing the use case significantly and depend= ing on implementation of CGA, which isn't really implemented/deployed in practice = today. It is not true. Please check this website http://en.wikipedia.org/wiki/Secu= re_Neighbor_Discovery_Protocol . And about using SSH, It might be a good solution to this problem (but so ge= neral) that if you like we can work on that on a separate draft together. The CGA-TSIG focused on a solution to this problem in IPv6 network when usi= ng SEND in local security. I am not agree with you in this sentence " it is= far applicable ", because when for the local security you use SEND you can= easily use this approach without any configuration for your clients side. Thank you, Hosnieh P.S. I also included DANE WG. From: Dave Thaler [mailto:dthaler@microsoft.com] Sent: Wednesday, November 07, 2012 8:40 PM To: Rafiee, Hosnieh; Suresh Krishnan (suresh.krishnan@ericsson.com); julien.ietf@gmail.com Cc: Int-area@ietf.org; dnsext@ietf.org; martin@v.loewis.de Subject: RE: (CGA-TSIG) answers to some of the comments Quick response... 1) Having the DHCP server do dynamic update is not necessarily just for add= resses allocated by DHCP. See http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 which is= a DHC WG draft. 2) "RFC 6106, the router advertisement contains the DNS information also so= there is no need for DHCP server configuration" Is not true. DNS information is not the only information obtained through= DHCP, it's a general purpose mechanism through which many things are, and can be, obtained. It is a bad idea to = try to pollute RAs with such information (for one, you're limited to the MTU in RAs). See RFC 5505 section 2.3 for = some more discussion. RFC 6434 section 6 even states "Hosts will need to decide which mechanism (or whether both) should be implemented." The fact that we actually have two mechanisms is a bad thing. 3) The main feedback some of us provided is that the proposal would be far = more widely applicable and useful if it just passed a public key and used the le= ap of faith model like SSH, rather than narrowing the use case significantly and depend= ing on implementation of CGA, which isn't really implemented/deployed in practice = today. -Dave From: int-area-bounces@ietf.org [mailto:i= nt-area-bounces@ietf.org] On Behalf Of Rafiee, Hosnieh Sent: Wednesday, November 7, 2012 10:28 AM To: Suresh Krishnan (suresh.krishnan@ericsson.com); julien.ietf@gmail.com Cc: Int-area@ietf.org; dnsext@ietf.org; martin@v.loewis.de Subject: [Int-area] (CGA-TSIG) answers to some of the comments Thanks to Julian, Suresh and others for all their comments on my presentati= on. Following are the answers to the questions raised and, hopefully, this = will clarify the main purpose of this draft: - A comment was made that DHCP can update the clients' DNS records on behal= f of the clients so they see any no reason for this draft as DHCPv6 can upd= ate the DNS records for the clients on behalf of them. Here we are talking about another IPv6 addressing mechanism, i.e., Neighbor= Discovery Protocol (RFC 4861) and not DHCPv6. NDP is a new addressing mechanism included in the IPv6 suite that functions= like ARP, discovering other neighbor nodes, ICMP, and address configuratio= n automatically. By default, all operating systems support this functionali= ty and, for windows, it is the default method of addressing. - Why do some administrators prefer to use NDP instead of DHCPv6? With NDP no DHCP server configuration is required. - Usage of NDP protocol All kinds of networks like campus, companies whether they are public and pr= ivate - How can a client or a server in IPv6 networks set its IP address using ND= P When you connect your computer to an IPv6 network, your computer generates = its IP address automatically and then processes duplicate address detection= by using 5 types of ICMPv6 messages. Your computer also sets its global ad= dress by using the router advertisement. The administrator just needs to en= able NDP on his router and configure it to advertise his available prefixes= . It is a great way to manage the network. - The problem with NDP WAS (solved now) Before, it did not support the DNS option and it took the DNS information f= rom the DHCP server, BUT NOW, according to a new extension to NDP, in RFC 6= 106, the router advertisement contains the DNS information also so there is= no need for DHCP server configuration. What is the problem now in this local network - what gap CGA-TSIG fills Briefly: It provides local security in IPv6 networks without the need for extra conf= iguration as it uses the current security parameters and mechanism availabl= e on this network, i.e., SEND. When node addresses change over time in IPv= 6 networks for privacy reasons, CGA-TSIG provides the necessary security in= IPv6 networks for the DNS authentication process. This solution works very= well in local networks, but also is applicable in global networks. - Local security is an important issue: In IPv6 networks that use NDP, ther= e is no central server available to perform the updates to DNS records on b= ehalf of the client. As local security is important, as well as global secu= rity, CGA-TSIG provides a solution for the automation of this process and a= llows for client authentication with DNS servers as well as the ability to = update their own records. The question that might arise here is, why local security is important?: The answer here is the same as that provided for the use of SEcure Neighbor= Discovery in IPv6 networks. Many attacks are internal and not via the Inte= rnet. When, because of flaws or viruses or..., a host in a network is infec= ted that gives the attacker control of that host the role of local security= is highlighted. In this case the attacker is inside your network and using= the legitimate nodes inside your network for their malicious purposes. The= refore, if you just think about global security, you have just partly secur= ed your network! If we also consider the case where the host's generates their IP address an= d keep it as long as it is connected to the same network. When this legitim= ate node, for the first time, join to a network, if TSIG or other security = mechanisms are used, the administrator needs to generate this shared secret= so that it is only shared between this host and the DNS server. Thus CGA-T= SIG reduces this task, while at the same time, provides the security necess= ary for DNS servers and clients. - Privacy is the second or another important issue: In Europe, privacy is a= very important issue. An example of that is in Germany that the ISPs are f= orced to change their range of IP addresses frequently. In this case, for e= very change, the administrators of the sub-networks, using these ISPs, need= to reconfigure their clients and servers to again use the security mechani= sm for authentication purposes. CGA-TSIG is the solution. It can provide th= is authentication without the need for more configuration - Global security: the same approach is applicable for authentication purpo= ses among the DNS servers on the Internet if they are under the privacy rul= es that force them to change their ISP's prefix, as was explained in my fir= st point Finally : DNS serves or clients only need use the cached CGA data and do no= t need to regenerate CGA! This is an important point because only a few cha= nges need be made to the current implementation of DNS server. I will provide you with the list of more attacks later. Some of the attack= s that CGA-TSIG can prevent are found in Security consideration section at = the following link: http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig-00#section-4 I welcome all questions and comments that can help to clear up the purpose = of this draft. Thank you all for your help. It is greatly appreciated. Thank you again, Hosnieh --_000_EA738325B0580041A50A364F5F76B68924D4465CF88MXMA1Rhpiuni_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Dave,

1) Having the DHCP server do dynamic update is not ne= cessarily just for addresses allocated by DHCP.
See http://tools.ietf.or= g/html/draft-ietf-dhc-addr-registration-01 which is a DHC WG draft.

Thanks a lot for your answer. Please= check the consideration section of the draft you referred to. The stated a= pproach is prone to attacks as it is solely about an extra management effor= ts and not security approaches. To prevent the attacks it also stated using= SEND.

Now the question is, when= you want to use SEND to secure your local network, my approach is also app= licable and better fits than TSIG itself as you do not need to generate pub= lic private keys, CGA and you use the same value available there.

DHCPv6 is only useful when you would like to have= more management and administration control on your network. But, if you on= ly want to know who used which address, you do not need to go to extra conf= iguration , you need just a passive monitoring system in the network to sni= ff all ICMPv6 unsolicited Neighbor advertisement packets and delete them fr= om the monitoring database if receive no more NA messages from that node. (= frequently nodes update their cache and send NA)

2- Is not true.   DNS information = is not the only information obtained through DHCP, it’s a general pur= pose mechanism
through which many things are, and can be, obtained. = ;  It is a bad idea to try to pollute RAs with such information
(fo= r one, you’re limited to the MTU in RAs).  See RFC 5505 section = 2.3 for some more discussion.

DNS information is just an information missing in NDP. For addressing = not more option is required for a node. I am not quite understand and convi= nced that why every time you change the talk to DHCPv6. I am talking about = the networks where SEND is used and not DHCPv6. I do not have any discussio= n about whether or not the DNS options in RAs is the best.

3- RFC 6434 section 6 eve=
n states
“Hosts will need to decide which mechanism (or whether both) =
should be

implemented.”
The fact that we actually have tw= o mechanisms is a bad thing.

This is why based on the network requirements, administrator ca= n choose which one to use.

3) The main feedback some of us provided = is that the proposal would be far more
widely applicable and useful if i= t just passed a public key and used the leap of faith
model like SSH, ra= ther than narrowing the use case significantly and depending on
implemen= tation of CGA, which isn’t really implemented/deployed in practice to= day.

It is not = true. Please check this website http://en.wikipedia.org/wiki/Secure_Neighb= or_Discovery_Protocol .

And about using SSH, It might be a good solution to this prob= lem (but so general) that if you like we can work on that on a separate dra= ft together.

Th= e CGA-TSIG focused on a solution to this problem in IPv6 network when using= SEND in local security. I am not agree with you in this sentence “ i= t is far applicable “, because when for the local security you use SE= ND you can easily use this approach without any configuration for your clie= nts side.

Thank you,=

Hosnieh

=

P.S. I also included DANE WG.

 

 

 

=

 =

From: Dave Thaler [mailto:dthaler@microsoft.com]
Sent: Wednesda= y, November 07, 2012 8:40 PM
To: Rafiee, Hosnieh; Suresh Krishnan= (suresh.krishnan@ericsson.= com); julien.ietf@gmail.com
Cc: Int-area@ietf.org;= dnsext@ietf.org; martin@v.loewis.de
Subject: RE: (CGA-TSIG= ) answers to some of the comments

 

Quick response…

<= span style=3D'color:#1F497D'>1) Having the DHCP server do dynamic update is= not necessarily just for addresses allocated by DHCP.
See http:/= /tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 which is a DHC WG draft.

2) “RFC 6106, th= e router advertisement contains the DNS information also so there is no nee= d for DHCP server configuration”

Is not true.   DNS information is not the only info= rmation obtained through DHCP, it’s a general purpose mechanism
th= rough which many things are, and can be, obtained.   It is a bad = idea to try to pollute RAs with such information
(for one, you’re = limited to the MTU in RAs).  See RFC 5505 section 2.3 for some more di= scussion.

RFC 6434 sect=
ion 6 even states
“=
Hosts will need to decide which mechanism (or whether both) shoul=
d be

implemente= d.”
The fact that we actually have two mechanisms is a bad thing.<= o:p>

3) The main feedb= ack some of us provided is that the proposal would be far more
widely ap= plicable and useful if it just passed a public key and used the leap of fai= th
model like SSH, rather than narrowing the use case significantly and = depending on
implementation of CGA, which isn’t really implemented= /deployed in practice today.

-Dave

= From: int-area-bounces@= ietf.org [mailto:int-area-= bounces@ietf.org] On Behalf Of Rafiee, Hosnieh
Sent: W= ednesday, November 7, 2012 10:28 AM
To: Suresh Krishnan (suresh.krishnan@ericsson.com);= julien.ietf@gmail.com
C= c: Int-area@ietf.org; dnsext@ietf.org; martin@v.loewis.de
Subject: [Int-area] (CGA-TSIG)= answers to some of the comments

 

Thanks to Julian, Suresh and others for all their commen= ts on my presentation. Following are the answers to the questions raised an= d, hopefully, this will  clarify the main purpose of this draft:<= /o:p>

- A comment was made that DHCP can update the clients' DNS r= ecords on behalf of the clients so they see any no reason for this draft as= DHCPv6 can update the DNS records for the clients on behalf of them. =

Here we are talking about another IPv6 addressing mechani= sm, i.e., Neighbor Discovery Protocol (RFC 4861) and not DHCPv6.=

NDP is a new addressing mechanism included in the IPv6 suite that funct= ions like ARP, discovering other neighbor nodes, ICMP, and address configur= ation automatically. By default, all operating systems support this functio= nality and, for windows, it is the default method of addressing.=

- Why do some administrators prefer to use NDP instead of DHCPv6?=

With NDP no DHCP server configuration is required. <= o:p>

- Usage of NDP protocol

= All kinds= of networks like campus, companies whether they are public and private

- How can a client or a server in IPv6 networks set its IP= address using NDP

When you connect your computer to= an IPv6 network, your computer generates its IP address automatically and = then processes duplicate address detection by using 5 types of ICMPv6 messa= ges. Your computer also sets its global address by using the router adverti= sement. The administrator just needs to enable NDP on his router and config= ure it to advertise his available prefixes. It is a great way to manage the= network.

- The problem with NDP WAS (solved now)=

Before, it did not support the DNS option and it took the= DNS information from the DHCP server, BUT NOW, according to a new extensio= n to NDP, in RFC 6106, the router advertisement contains the DNS informatio= n also so there is no need for DHCP server configuration.=

= What is the problem now in this local network – what gap CGA-TSIG fil= ls

Briefly:

It provides local securi= ty in IPv6 networks without the need for extra configuration as it uses the= current security parameters and mechanism available on this network, i.e.,= SEND.  When node addresses change over time in IPv6 networks for priv= acy reasons, CGA-TSIG provides the necessary security in IPv6 networks for = the DNS authentication process. This solution works very well in local netw= orks, but also is applicable in global networks.

<= span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>- Local= security is an important issue: In IPv6 networks that use NDP, there i= s no central server available to perform the updates to DNS records on beha= lf of the client. As local security is important, as well as global securit= y, CGA-TSIG provides a solution for the automation of this process and allo= ws for client authentication with DNS servers as well as the ability to upd= ate their own records.

The question that might arise here is= , why local security is important?:

The answer here is the sa= me as that provided for the use of SEcure Neighbor Discovery in IPv6 networ= ks. Many attacks are internal and not via the Internet. When, because of fl= aws or viruses or…, a host in a network is infected that gives the at= tacker control of that host the role of local security is highlighted. In t= his case the attacker is inside your network and using the legitimate nodes= inside your network for their malicious purposes. Therefore, if you just t= hink about global security, you have just partly secured your network!

If we also consider the case where the host's generates their IP= address and keep it as long as it is connected to the same network. When t= his legitimate node, for the first time, join to a network, if TSIG or othe= r security mechanisms are used, the administrator needs to generate this sh= ared secret so that it is only shared between this host and the DNS server.= Thus CGA-TSIG reduces this task, while at the same time, provides the secu= rity necessary for DNS servers and clients.

- Privacy is= the second or another important issue: In Europe, privacy is a very im= portant issue. An example of that is in Germany that the ISPs are forced to= change their range of IP addresses frequently. In this case, for every cha= nge, the administrators of the sub-networks, using these ISPs, need to reco= nfigure their clients and servers to again use the security mechanism for a= uthentication purposes. CGA-TSIG is the solution. It can provide this authe= ntication without the need for more configuration

- Global= security: the same approach is applicable for authentication purposes = among the DNS servers on the Internet if they are under the privacy rules t= hat force them to change their ISP's prefix, as was explained in my first p= oint

Finally : DNS serves or clients only need use the c= ached CGA data and do not need to regenerate CGA! This is an important poin= t because only a few changes need be made  to the current implementati= on of DNS server.

I will provide you with the list of more at= tacks later.  Some of the attacks that CGA-TSIG can prevent are found = in Security consideration section at the following link:<= /p>

http://tools.ietf.org/html/draft-rafiee-intarea-cga-ts= ig-00#section-4

<= b>I welco= me all questions and comments that can help to clear up the purpose of this= draft. Thank you all for your help. It is greatly appreciated.<= span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>

Thank you again,

Hosnieh

 

 

= --_000_EA738325B0580041A50A364F5F76B68924D4465CF88MXMA1Rhpiuni_-- From rafiee@hpi.uni-potsdam.de Thu Nov 8 06:22:53 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC4A21F8AD7; Thu, 8 Nov 2012 06:22:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.187 X-Spam-Level: X-Spam-Status: No, score=-2.187 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Am8Ee3HfMj1i; Thu, 8 Nov 2012 06:22:42 -0800 (PST) Received: from mail3.hpi.uni-potsdam.de (mail3.hpi.uni-potsdam.de [IPv6:2001:638:807:204::8d59:e17b]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDC221F8B97; Thu, 8 Nov 2012 06:22:40 -0800 (PST) Received: from owa2.hpi.uni-potsdam.de (owa2.hpi.uni-potsdam.de [141.89.225.162]) by mail3.hpi.uni-potsdam.de (Postfix) with ESMTP id 9FFA4169E4D; Thu, 8 Nov 2012 15:22:39 +0100 (CET) Received: from 8MXMA1R.hpi.uni-potsdam.de ([fe80::88e9:3d98:b35f:83bf]) by OWA2.hpi.uni-potsdam.de ([2002:8d59:e1a2::8d59:e1a2]) with mapi; Thu, 8 Nov 2012 15:22:39 +0100 From: "Rafiee, Hosnieh" To: Dave Thaler Date: Thu, 8 Nov 2012 15:22:35 +0100 Thread-Topic: (CGA-TSIG) answers to some of the comments Thread-Index: Ac285dnqWsyLqCHNR5+px/yGKKx0JQAOEzPQACP1VOA= Message-ID: References: <9B57C850BB53634CACEC56EF4853FF653B90869E@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B90869E@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_EA738325B0580041A50A364F5F76B68924D4465CF08MXMA1Rhpiuni_" MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 08 Nov 2012 08:23:40 -0800 Cc: "Suresh Krishnan \(suresh.krishnan@ericsson.com\)" Subject: Re: [dane] (CGA-TSIG) answers to some of the comments X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 14:22:53 -0000 --_000_EA738325B0580041A50A364F5F76B68924D4465CF08MXMA1Rhpiuni_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dave, 1) Having the DHCP server do dynamic update is not necessarily just for add= resses allocated by DHCP. See http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 which is= a DHC WG draft. Thanks a lot for your answer. Please check the consideration section of the= draft you referred to. The stated approach is prone to attacks as it is so= lely about an extra management efforts and not security approaches. To prev= ent the attacks it also stated using SEND. Now the question is, when you want to use SEND to secure your local network= , my approach is also applicable and better fits than TSIG itself as you do= not need to generate public private keys, CGA and you use the same value a= vailable there. DHCPv6 is only useful when you would like to have more management and admin= istration control on your network. But, if you only want to know who used w= hich address, you do not need to go to extra configuration , you need just = a passive monitoring system in the network to sniff all ICMPv6 unsolicited = Neighbor advertisement packets and delete them from the monitoring database= if receive no more NA messages from that node. (frequently nodes update th= eir cache and send NA) 2- Is not true. DNS information is not the only information obtained thro= ugh DHCP, it's a general purpose mechanism through which many things are, and can be, obtained. It is a bad idea to = try to pollute RAs with such information (for one, you're limited to the MTU in RAs). See RFC 5505 section 2.3 for = some more discussion. DNS information is just an information missing in NDP. For addressing not m= ore option is required for a node. I am not quite understand and convinced = that why every time you change the talk to DHCPv6. I am talking about the n= etworks where SEND is used and not DHCPv6. I do not have any discussion abo= ut whether or not the DNS options in RAs is the best. 3- RFC 6434 section 6 even states "Hosts will need to decide which mechanism (or whether both) should be implemented." The fact that we actually have two mechanisms is a bad thing. This is why based on the network requirements, administrator can choose whi= ch one to use. 3) The main feedback some of us provided is that the proposal would be far = more widely applicable and useful if it just passed a public key and used the le= ap of faith model like SSH, rather than narrowing the use case significantly and depend= ing on implementation of CGA, which isn't really implemented/deployed in practice = today. It is not true. Please check this website http://en.wikipedia.org/wiki/Secu= re_Neighbor_Discovery_Protocol . And about using SSH, It might be a good solution to this problem (but so ge= neral) that if you like we can work on that on a separate draft together. The CGA-TSIG focused on a solution to this problem in IPv6 network when usi= ng SEND in local security. I am not agree with you in this sentence " it is= far applicable ", because when for the local security you use SEND you can= easily use this approach without any configuration for your clients side. Thank you, Hosnieh P.S. I also included DANE WG. From: Dave Thaler [mailto:dthaler@microsoft.com] Sent: Wednesday, November 07, 2012 8:40 PM To: Rafiee, Hosnieh; Suresh Krishnan (suresh.krishnan@ericsson.com); julien.ietf@gmail.com Cc: Int-area@ietf.org; dnsext@ietf.org; martin@v.loewis.de Subject: RE: (CGA-TSIG) answers to some of the comments Quick response... 1) Having the DHCP server do dynamic update is not necessarily just for add= resses allocated by DHCP. See http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 which is= a DHC WG draft. 2) "RFC 6106, the router advertisement contains the DNS information also so= there is no need for DHCP server configuration" Is not true. DNS information is not the only information obtained through= DHCP, it's a general purpose mechanism through which many things are, and can be, obtained. It is a bad idea to = try to pollute RAs with such information (for one, you're limited to the MTU in RAs). See RFC 5505 section 2.3 for = some more discussion. RFC 6434 section 6 even states "Hosts will need to decide which mechanism (or whether both) should be implemented." The fact that we actually have two mechanisms is a bad thing. 3) The main feedback some of us provided is that the proposal would be far = more widely applicable and useful if it just passed a public key and used the le= ap of faith model like SSH, rather than narrowing the use case significantly and depend= ing on implementation of CGA, which isn't really implemented/deployed in practice = today. -Dave From: int-area-bounces@ietf.org [mailto:i= nt-area-bounces@ietf.org] On Behalf Of Rafiee, Hosnieh Sent: Wednesday, November 7, 2012 10:28 AM To: Suresh Krishnan (suresh.krishnan@ericsson.com); julien.ietf@gmail.com Cc: Int-area@ietf.org; dnsext@ietf.org; martin@v.loewis.de Subject: [Int-area] (CGA-TSIG) answers to some of the comments Thanks to Julian, Suresh and others for all their comments on my presentati= on. Following are the answers to the questions raised and, hopefully, this = will clarify the main purpose of this draft: - A comment was made that DHCP can update the clients' DNS records on behal= f of the clients so they see any no reason for this draft as DHCPv6 can upd= ate the DNS records for the clients on behalf of them. Here we are talking about another IPv6 addressing mechanism, i.e., Neighbor= Discovery Protocol (RFC 4861) and not DHCPv6. NDP is a new addressing mechanism included in the IPv6 suite that functions= like ARP, discovering other neighbor nodes, ICMP, and address configuratio= n automatically. By default, all operating systems support this functionali= ty and, for windows, it is the default method of addressing. - Why do some administrators prefer to use NDP instead of DHCPv6? With NDP no DHCP server configuration is required. - Usage of NDP protocol All kinds of networks like campus, companies whether they are public and pr= ivate - How can a client or a server in IPv6 networks set its IP address using ND= P When you connect your computer to an IPv6 network, your computer generates = its IP address automatically and then processes duplicate address detection= by using 5 types of ICMPv6 messages. Your computer also sets its global ad= dress by using the router advertisement. The administrator just needs to en= able NDP on his router and configure it to advertise his available prefixes= . It is a great way to manage the network. - The problem with NDP WAS (solved now) Before, it did not support the DNS option and it took the DNS information f= rom the DHCP server, BUT NOW, according to a new extension to NDP, in RFC 6= 106, the router advertisement contains the DNS information also so there is= no need for DHCP server configuration. What is the problem now in this local network - what gap CGA-TSIG fills Briefly: It provides local security in IPv6 networks without the need for extra conf= iguration as it uses the current security parameters and mechanism availabl= e on this network, i.e., SEND. When node addresses change over time in IPv= 6 networks for privacy reasons, CGA-TSIG provides the necessary security in= IPv6 networks for the DNS authentication process. This solution works very= well in local networks, but also is applicable in global networks. - Local security is an important issue: In IPv6 networks that use NDP, ther= e is no central server available to perform the updates to DNS records on b= ehalf of the client. As local security is important, as well as global secu= rity, CGA-TSIG provides a solution for the automation of this process and a= llows for client authentication with DNS servers as well as the ability to = update their own records. The question that might arise here is, why local security is important?: The answer here is the same as that provided for the use of SEcure Neighbor= Discovery in IPv6 networks. Many attacks are internal and not via the Inte= rnet. When, because of flaws or viruses or..., a host in a network is infec= ted that gives the attacker control of that host the role of local security= is highlighted. In this case the attacker is inside your network and using= the legitimate nodes inside your network for their malicious purposes. The= refore, if you just think about global security, you have just partly secur= ed your network! If we also consider the case where the host's generates their IP address an= d keep it as long as it is connected to the same network. When this legitim= ate node, for the first time, join to a network, if TSIG or other security = mechanisms are used, the administrator needs to generate this shared secret= so that it is only shared between this host and the DNS server. Thus CGA-T= SIG reduces this task, while at the same time, provides the security necess= ary for DNS servers and clients. - Privacy is the second or another important issue: In Europe, privacy is a= very important issue. An example of that is in Germany that the ISPs are f= orced to change their range of IP addresses frequently. In this case, for e= very change, the administrators of the sub-networks, using these ISPs, need= to reconfigure their clients and servers to again use the security mechani= sm for authentication purposes. CGA-TSIG is the solution. It can provide th= is authentication without the need for more configuration - Global security: the same approach is applicable for authentication purpo= ses among the DNS servers on the Internet if they are under the privacy rul= es that force them to change their ISP's prefix, as was explained in my fir= st point Finally : DNS serves or clients only need use the cached CGA data and do no= t need to regenerate CGA! This is an important point because only a few cha= nges need be made to the current implementation of DNS server. I will provide you with the list of more attacks later. Some of the attack= s that CGA-TSIG can prevent are found in Security consideration section at = the following link: http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig-00#section-4 I welcome all questions and comments that can help to clear up the purpose = of this draft. Thank you all for your help. It is greatly appreciated. Thank you again, Hosnieh --_000_EA738325B0580041A50A364F5F76B68924D4465CF08MXMA1Rhpiuni_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dave,

1) Having the DHCP server do dynamic update is not neces= sarily just for addresses allocated by DHCP.
See http://tools.ietf.org/h= tml/draft-ietf-dhc-addr-registration-01 which is a DHC WG draft.

Thanks a lot for your answer. Please ch= eck the consideration section of the draft you referred to. The stated appr= oach is prone to attacks as it is solely about an extra management efforts = and not security approaches. To prevent the attacks it also stated using= SEND.

Now the question is, when yo= u want to use SEND to secure your local network, my approach is also applic= able and better fits than TSIG itself as you do not need to generate public= private keys, CGA and you use the same value available there.

DHCPv6 is only useful when you would like to have mo= re management and administration control on your network. But, if you only = want to know who used which address, you do not need to go to extra configu= ration , you need just a passive monitoring system in the network to sniff = all ICMPv6 unsolicited Neighbor advertisement packets and delete them from = the monitoring database if receive no more NA messages from that node. (fre= quently nodes update their cache and send NA)

2- Is not true.   DNS information is = not the only information obtained through DHCP, it’s a general purpos= e mechanism
through which many things are, and can be, obtained. &n= bsp; It is a bad idea to try to pollute RAs with such information
(for o= ne, you’re limited to the MTU in RAs).  See RFC 5505 section 2.3= for some more discussion.

DNS information is just an information missing in NDP. For addressing not= more option is required for a node. I am not quite understand and convince= d that why every time you change the talk to DHCPv6. I am talking about the= networks where SEND is used and not DHCPv6. I do not have any discussion a= bout whether or not the DNS options in RAs is the best.

3- RFC 6434 section 6 even s=
tates
“Hosts will need to decide which mechanism (or whether both) sho=
uld be

implemented.”
The fact that we actually have two m= echanisms is a bad thing.

This is why based on the network requirements, administrator can c= hoose which one to use.

3) The main feedback some of us provided is = that the proposal would be far more
widely applicable and useful if it j= ust passed a public key and used the leap of faith
model like SSH, rathe= r than narrowing the use case significantly and depending on
implementat= ion of CGA, which isn’t really implemented/deployed in practice today= .

It is not tru= e. Please check this website http://en.wikipedia.org/wiki/Secure_Neighbor_= Discovery_Protocol .

And about using SSH, It might be a good solution to this problem= (but so general) that if you like we can work on that on a separate draft = together.

The= CGA-TSIG focused on a solution to this problem in IPv6 network when using = SEND in local security. I am not agree with you in this sentence “ it= is far applicable “, because when for the local security you use SEN= D you can easily use this approach without any configuration for your clien= ts side.

Thank you,<= /o:p>

Hosnieh

<= p class=3DMsoNormal>P.S. I also included DANE WG.=

 

 

 

<= p class=3DMsoNormal> <= /p>

From: Dave Thaler [mailto:dthaler@microsoft.com]
Sent: Wednesday= , November 07, 2012 8:40 PM
To: Rafiee, Hosnieh; Suresh Krishnan = (suresh.krishnan@ericsson.c= om); julien.ietf@gmail.com=
Cc: Int-area@ietf.org; = dnsext@ietf.org; martin@v.loewis.de
Subject: RE: (CGA-TSIG)= answers to some of the comments

 

Quick response…

<= span style=3D'color:#1F497D'>1) Having the DHCP server do dynamic update is= not necessarily just for addresses allocated by DHCP.
See http:/= /tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 which is a DHC WG draft.

2) “RFC 6106, th= e router advertisement contains the DNS information also so there is no nee= d for DHCP server configuration”

Is not true.   DNS information is not the only info= rmation obtained through DHCP, it’s a general purpose mechanism
th= rough which many things are, and can be, obtained.   It is a bad = idea to try to pollute RAs with such information
(for one, you’re = limited to the MTU in RAs).  See RFC 5505 section 2.3 for some more di= scussion.

RFC 6434 sect=
ion 6 even states
“=
Hosts will need to decide which mechanism (or whether both) shoul=
d be

implemente= d.”
The fact that we actually have two mechanisms is a bad thing.<= o:p>

3) The main feedb= ack some of us provided is that the proposal would be far more
widely ap= plicable and useful if it just passed a public key and used the leap of fai= th
model like SSH, rather than narrowing the use case significantly and = depending on
implementation of CGA, which isn’t really implemented= /deployed in practice today.

-Dave

= From: int-area-bounces@= ietf.org [mailto:int-area-= bounces@ietf.org] On Behalf Of Rafiee, Hosnieh
Sent: W= ednesday, November 7, 2012 10:28 AM
To: Suresh Krishnan (suresh.krishnan@ericsson.com);= julien.ietf@gmail.com
C= c: Int-area@ietf.org; dnsext@ietf.org; martin@v.loewis.de
Subject: [Int-area] (CGA-TSIG)= answers to some of the comments

 

Thanks to Julian, Suresh and others for all their commen= ts on my presentation. Following are the answers to the questions raised an= d, hopefully, this will  clarify the main purpose of this draft:<= /o:p>

- A comment was made that DHCP can update the clients' DNS r= ecords on behalf of the clients so they see any no reason for this draft as= DHCPv6 can update the DNS records for the clients on behalf of them. =

Here we are talking about another IPv6 addressing mechani= sm, i.e., Neighbor Discovery Protocol (RFC 4861) and not DHCPv6.=

NDP is a new addressing mechanism included in the IPv6 suite that funct= ions like ARP, discovering other neighbor nodes, ICMP, and address configur= ation automatically. By default, all operating systems support this functio= nality and, for windows, it is the default method of addressing.=

- Why do some administrators prefer to use NDP instead of DHCPv6?=

With NDP no DHCP server configuration is required. <= o:p>

- Usage of NDP protocol

= All kinds= of networks like campus, companies whether they are public and private

- How can a client or a server in IPv6 networks set its IP= address using NDP

When you connect your computer to= an IPv6 network, your computer generates its IP address automatically and = then processes duplicate address detection by using 5 types of ICMPv6 messa= ges. Your computer also sets its global address by using the router adverti= sement. The administrator just needs to enable NDP on his router and config= ure it to advertise his available prefixes. It is a great way to manage the= network.

- The problem with NDP WAS (solved now)=

Before, it did not support the DNS option and it took the= DNS information from the DHCP server, BUT NOW, according to a new extensio= n to NDP, in RFC 6106, the router advertisement contains the DNS informatio= n also so there is no need for DHCP server configuration.=

= What is the problem now in this local network – what gap CGA-TSIG fil= ls

Briefly:

It provides local securi= ty in IPv6 networks without the need for extra configuration as it uses the= current security parameters and mechanism available on this network, i.e.,= SEND.  When node addresses change over time in IPv6 networks for priv= acy reasons, CGA-TSIG provides the necessary security in IPv6 networks for = the DNS authentication process. This solution works very well in local netw= orks, but also is applicable in global networks.

<= span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>- Local= security is an important issue: In IPv6 networks that use NDP, there i= s no central server available to perform the updates to DNS records on beha= lf of the client. As local security is important, as well as global securit= y, CGA-TSIG provides a solution for the automation of this process and allo= ws for client authentication with DNS servers as well as the ability to upd= ate their own records.

The question that might arise here is= , why local security is important?:

The answer here is the sa= me as that provided for the use of SEcure Neighbor Discovery in IPv6 networ= ks. Many attacks are internal and not via the Internet. When, because of fl= aws or viruses or…, a host in a network is infected that gives the at= tacker control of that host the role of local security is highlighted. In t= his case the attacker is inside your network and using the legitimate nodes= inside your network for their malicious purposes. Therefore, if you just t= hink about global security, you have just partly secured your network!

If we also consider the case where the host's generates their IP= address and keep it as long as it is connected to the same network. When t= his legitimate node, for the first time, join to a network, if TSIG or othe= r security mechanisms are used, the administrator needs to generate this sh= ared secret so that it is only shared between this host and the DNS server.= Thus CGA-TSIG reduces this task, while at the same time, provides the secu= rity necessary for DNS servers and clients.

- Privacy is= the second or another important issue: In Europe, privacy is a very im= portant issue. An example of that is in Germany that the ISPs are forced to= change their range of IP addresses frequently. In this case, for every cha= nge, the administrators of the sub-networks, using these ISPs, need to reco= nfigure their clients and servers to again use the security mechanism for a= uthentication purposes. CGA-TSIG is the solution. It can provide this authe= ntication without the need for more configuration

- Global= security: the same approach is applicable for authentication purposes = among the DNS servers on the Internet if they are under the privacy rules t= hat force them to change their ISP's prefix, as was explained in my first p= oint

Finally : DNS serves or clients only need use the c= ached CGA data and do not need to regenerate CGA! This is an important poin= t because only a few changes need be made  to the current implementati= on of DNS server.

I will provide you with the list of more at= tacks later.  Some of the attacks that CGA-TSIG can prevent are found = in Security consideration section at the following link:<= /p>

http://tools.ietf.org/html/draft-rafiee-intarea-cga-ts= ig-00#section-4

<= b>I welco= me all questions and comments that can help to clear up the purpose of this= draft. Thank you all for your help. It is greatly appreciated.<= span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>

Thank you again,

Hosnieh

 

 

= --_000_EA738325B0580041A50A364F5F76B68924D4465CF08MXMA1Rhpiuni_-- From christian.becker@tu-harburg.de Fri Nov 9 11:21:21 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F7921F86D2 for ; Fri, 9 Nov 2012 11:21:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YcgQZ3ks0lNn for ; Fri, 9 Nov 2012 11:21:21 -0800 (PST) Received: from smtp3.rz.tu-harburg.de (smtp3.rz.tu-harburg.de [134.28.202.138]) by ietfa.amsl.com (Postfix) with ESMTP id C827621F86D0 for ; Fri, 9 Nov 2012 11:21:19 -0800 (PST) Received: from mail.tu-harburg.de (mail.tu-harburg.de [134.28.202.179]) by smtp3.rz.tu-harburg.de (8.13.8/8.13.8) with ESMTP id qA9JLIk5027899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 9 Nov 2012 20:21:18 +0100 Received: from [0.0.0.0] (politkovskaja.torservers.net [77.247.181.165]) (user=secb0840 mech=PLAIN bits=0) by mail.tu-harburg.de (8.13.8/8.13.8) with ESMTP id qA9JKm8l031923 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 9 Nov 2012 20:21:10 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tu-harburg.de; s=x2012-45; t=1352488878; bh=aurCGKf1y5p2zRtT8CwFWNhEdF9VeMbvNUc+nkaoUbA=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=VOAGFd8v37fWjLxhLUv72Rg+g1KnS3Cw3bUQKRxDWz2tn54eY9Ws2cBEPyg30Mfl7 7NYKaVzQ6SbzFGodLV1eqMLvzlirICJbIuNmaDGmhErWlrjXqhOSimJ1zSqIzeAAI1 5/H5NWD81/X48x2yq7a6v15aDdNkY1g3y8gitq+Y= Message-ID: <509D5715.4000109@tu-harburg.de> Date: Fri, 09 Nov 2012 20:18:45 +0100 From: Christian Becker User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20121027 Icedove/3.0.11 MIME-Version: 1.0 To: dane@ietf.org X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Scanned-By: TUHH Rechenzentrum content checker on 134.28.202.138 X-Scanned-By: TUHH Rechenzentrum content checker on 134.28.202.179 Subject: [dane] no security benefit from insecure or indeterminate domains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 19:35:15 -0000 Hi, I am confused by the last paragraph of 4.1 in RFC6698. To my understanding in the case of a "domain is insecure or indeterminate" there is no security benefit compared to TLS processed in the normal fashion. Thus, also in this case the application "SHOULD NOT make any internal or external indication that TLSA was applied." Referred paragraph: "Thus, in order to achieve any security benefit from certificate usage 0 or 1, an application that sends a request for TLSA records needs to get either a valid signed response containing TLSA records or verification that the domain is insecure or indeterminate. If a request for a TLSA record does not meet one of those two criteria but the application continues with the TLS handshake anyway, the application has gotten no benefit from TLSA and SHOULD NOT make any internal or external indication that TLSA was applied." Christian From paul@cypherpunks.ca Fri Nov 9 16:12:00 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B47621F86B8 for ; Fri, 9 Nov 2012 16:12:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJObNb2n9WbP for ; Fri, 9 Nov 2012 16:11:59 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 8D61C21F865B for ; Fri, 9 Nov 2012 16:11:59 -0800 (PST) Received: by bofh.nohats.ca (Postfix, from userid 500) id 1A6F282B73; Fri, 9 Nov 2012 19:11:12 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id C8E7382B70; Fri, 9 Nov 2012 19:11:12 -0500 (EST) Date: Fri, 9 Nov 2012 19:11:12 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Christian Becker In-Reply-To: <509D5715.4000109@tu-harburg.de> Message-ID: References: <509D5715.4000109@tu-harburg.de> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dane WG list Subject: Re: [dane] no security benefit from insecure or indeterminate domains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 10 Nov 2012 00:12:00 -0000 On Fri, 9 Nov 2012, Christian Becker wrote: > Date: Fri, 9 Nov 2012 14:18:45 > From: Christian Becker > To: dane@ietf.org > Subject: [dane] no security benefit from insecure or indeterminate domains > > Hi, > > I am confused by the last paragraph of 4.1 in RFC6698. To my > understanding in the case of a "domain is insecure or indeterminate" > there is no security benefit compared to TLS processed in the normal > fashion. Thus, also in this case the application "SHOULD NOT make any > internal or external indication that TLSA was applied." Well, for "indeterminate", you know that the DNS was very broken, or possibly tampered with, and prevented receiving positive or negative prove from DNS/TLSA. To me, the actions to perform for "insecure" versus "indeterminate" are quite different. Paul From christian.becker@tu-harburg.de Sat Nov 10 00:06:56 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00A4D21F84DC for ; Sat, 10 Nov 2012 00:06:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CSEm1Vk1ult2 for ; Sat, 10 Nov 2012 00:06:55 -0800 (PST) Received: from smtp3.rz.tu-harburg.de (smtp3.rz.tu-harburg.de [134.28.202.138]) by ietfa.amsl.com (Postfix) with ESMTP id 9B52421F84D4 for ; Sat, 10 Nov 2012 00:06:53 -0800 (PST) Received: from mail.tu-harburg.de (mail.tu-harburg.de [134.28.202.179]) by smtp3.rz.tu-harburg.de (8.13.8/8.13.8) with ESMTP id qAA86mQV029064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 10 Nov 2012 09:06:48 +0100 Received: from [0.0.0.0] (tor-exit.efnet.at [158.255.212.179]) (user=secb0840 mech=PLAIN bits=0) by mail.tu-harburg.de (8.13.8/8.13.8) with ESMTP id qAA864Rl020203 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sat, 10 Nov 2012 09:06:45 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tu-harburg.de; s=x2012-45; t=1352534808; bh=LLiMZQtKrf9STuN2Jt0x5Lk+X+qyT8KIiq395ZaHigI=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=WlwR51umIbksYLpz8RreYdTj3BoZ/onvtrDAdhuY6KKL8DbnoyeG08604mzGl7lpO p+7THN4izRL5wAFk3gdrBx19S5aSFoouY16wpNXn68jIBQxu+19BYw/1pRhCR8pvjU +YYh3YiEFHKL93QT1w08X/vdIdRc/aOoo7TDLuEE= Message-ID: <509E0A73.60505@tu-harburg.de> Date: Sat, 10 Nov 2012 09:04:03 +0100 From: Christian Becker User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20121027 Icedove/3.0.11 MIME-Version: 1.0 To: Paul Wouters References: <509D5715.4000109@tu-harburg.de> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: TUHH Rechenzentrum content checker on 134.28.202.138 X-Scanned-By: TUHH Rechenzentrum content checker on 134.28.202.179 Cc: dane@ietf.org Subject: Re: [dane] no security benefit from insecure or indeterminate domains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 10 Nov 2012 08:06:56 -0000 Am 10.11.2012 01:11, schrieb Paul Wouters: > On Fri, 9 Nov 2012, Christian Becker wrote: >> I am confused by the last paragraph of 4.1 in RFC6698. To my >> understanding in the case of a "domain is insecure or indeterminate" >> there is no security benefit compared to TLS processed in the normal >> fashion. Thus, also in this case the application "SHOULD NOT make any >> internal or external indication that TLSA was applied." > > Well, for "indeterminate", you know that the DNS was very broken, or > possibly tampered with, and prevented receiving positive or negative > prove from DNS/TLSA. > > To me, the actions to perform for "insecure" versus "indeterminate" are > quite different. I agree, this should be a difference, but 1.) as stated above, the RFC6698 handles these two cases together probably for the reason that 2.) also RFC4033 says in paragraph 5 that "The current signaling mechanism does not distinguish between indeterminate and insecure states." That is why to my understanding it is one case "insecure or indeterminate" and should be handled as the worst case, namely the data could have been tampered and therefor the application "SHOULD NOT make any internal or external indication that TLSA was applied." Christian From paul@cypherpunks.ca Sat Nov 10 10:19:26 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9A3921F8581 for ; Sat, 10 Nov 2012 10:19:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OvYW28-8-bX4 for ; Sat, 10 Nov 2012 10:19:26 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 51F7021F857E for ; Sat, 10 Nov 2012 10:19:25 -0800 (PST) Received: by bofh.nohats.ca (Postfix, from userid 500) id F0F3982B69; Sat, 10 Nov 2012 13:18:39 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id BB759804AA; Sat, 10 Nov 2012 13:18:39 -0500 (EST) Date: Sat, 10 Nov 2012 13:18:39 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Christian Becker In-Reply-To: <509E0A73.60505@tu-harburg.de> Message-ID: References: <509D5715.4000109@tu-harburg.de> <509E0A73.60505@tu-harburg.de> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dane WG list Subject: Re: [dane] no security benefit from insecure or indeterminate domains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 10 Nov 2012 18:19:26 -0000 On Sat, 10 Nov 2012, Christian Becker wrote: > I agree, this should be a difference, but > > 1.) as stated above, the RFC6698 handles these two cases together > > probably for the reason that > > 2.) also RFC4033 says in paragraph 5 that "The current signaling > mechanism does not distinguish between indeterminate and insecure states." > > That is why to my understanding it is one case "insecure or > indeterminate" and should be handled as the worst case, namely the data > could have been tampered and therefor the application "SHOULD NOT make > any internal or external indication that TLSA was applied." If you are under attack (possible when in indeterminate) I would hope the user gets to see more then the lack of a security identifier. Paul From fanf2@hermes.cam.ac.uk Wed Nov 14 06:01:09 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B38C821F85C4 for ; Wed, 14 Nov 2012 06:01:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.693 X-Spam-Level: X-Spam-Status: No, score=-2.693 tagged_above=-999 required=5 tests=[AWL=-1.953, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HdoBh2h7BjZc for ; Wed, 14 Nov 2012 06:01:09 -0800 (PST) Received: from ppsw-43.csi.cam.ac.uk (ppsw-43.csi.cam.ac.uk [131.111.8.143]) by ietfa.amsl.com (Postfix) with ESMTP id D4F5621F858E for ; Wed, 14 Nov 2012 06:01:08 -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-1.csi.cam.ac.uk ([131.111.8.51]:37072) by ppsw-43.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1TYdWa-0008KC-pV (Exim 4.72) (return-path ); Wed, 14 Nov 2012 14:01:04 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1TYdWa-0006dZ-UP (Exim 4.72) (return-path ); Wed, 14 Nov 2012 14:01:04 +0000 Date: Wed, 14 Nov 2012 14:01:04 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Paul Wouters In-Reply-To: Message-ID: References: <509D5715.4000109@tu-harburg.de> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dane WG list Subject: Re: [dane] no security benefit from insecure or indeterminate domains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 14:01:09 -0000 Paul Wouters wrote: > > Well, for "indeterminate", you know that the DNS was very broken, or > possibly tampered with, and prevented receiving positive or negative > prove from DNS/TLSA. No, indeterminate just means you have no trust anchors. Broken/tampered is bogus. > To me, the actions to perform for "insecure" versus "indeterminate" are > quite different. To me they are equivalent from an app's point of view. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From benl@google.com Wed Nov 14 07:48:23 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2F1A21F8659 for ; Wed, 14 Nov 2012 07:48:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.805 X-Spam-Level: X-Spam-Status: No, score=-102.805 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4-r7Vfcgfqz for ; Wed, 14 Nov 2012 07:48:23 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3431421F8645 for ; Wed, 14 Nov 2012 07:48:23 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fl11so653477vcb.31 for ; Wed, 14 Nov 2012 07:48:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=LOfCzzh4wkPSUhMbYcpEb2lHWUZsdW/aCI7JLU0iMBs=; b=KJKwfTnsZMaPTvVEWCzrMDHpAgZw0l9CnZDqMgFpb7o0+AIkWwYDCYABfHQ7gvGtbE 90JcWjAGBi64W4tw4tvGGrtoCzs7iLXJxOYGgm1m+aMn/5Rjrj6JA4f/QBiwmluUrk0Z mKnXKOMROAWJh62MrO7pKWcolOTrKaaOuNF06XjoBJHleUjPG8RrV44kGPnleNi6Fibj auts2Nzn9UEApjG6BBdH0o3PINWaTmPxr9ZopyqjkfavDSSfhwKzlcq0B5REYGvE6uUM OnhxdONOFVc8mJODiexM+IZxG9XmYqTcP2c0iKQjFGOu2rbN7lalqNAVND35Ptw7GNbG L9Nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=LOfCzzh4wkPSUhMbYcpEb2lHWUZsdW/aCI7JLU0iMBs=; b=g0Dd0DCuVxpJQ2ZIY18QbPLKPxbT1FRgr9bU+LFzCQTmxbHq7933f1ZYGd7F0raaIa oz5TayEjSqUqf008ozcSjfm3Les8e8DEqRecoExCoEk7lp60G1SEffGQA1Nwm0P3Dfpb TCXx0AIyfwGi70SPqYSbhWX3qLJgH2BIfqb3OkoPq/Nr+CetobLnP3oukEbSqMsEful+ 5dWGBWWAiSgnL7eyMW2TVpZ1+O6gDWBDSDpHWXK8RcUb9+qWio6pvR6QjtNaxO2bkMuN NoxdYXb1HrGgCkHNby6ON1NY0Pji5232GwIF+Xqq85mcRhL//yfs1q0lLOx6yV2m+W3x 48KQ== MIME-Version: 1.0 Received: by 10.220.155.132 with SMTP id s4mr11456480vcw.15.1352908102445; Wed, 14 Nov 2012 07:48:22 -0800 (PST) Received: by 10.220.228.6 with HTTP; Wed, 14 Nov 2012 07:48:22 -0800 (PST) Date: Wed, 14 Nov 2012 15:48:22 +0000 Message-ID: From: Ben Laurie To: IETF DANE WG list , therightkey@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkKD2VQT+xouLUlhbo9EWeQL9e5i0YLFtNE/+5wIKRuHNmduHTgBsg9Cc1mH+ZkbCXS6p55kYy5H/O1JgqEOpFSZPCUNHD00eEEg6ktRJkYAD8pAkGGWXzapJaqcouAI07US9qKyV2pEEB0nWQqhi24/MKz0x0YNHwI/O5CBCh6qojkMiLOBQjsitf1hmYkQp+XP56d Subject: [dane] DANE and CT X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 15:48:23 -0000 At the CT BoF the question was raised: what about DANE? Which is a good question. So, I think Google is prepared to contemplate running a CT log for DANE, but this leaves some questions... a) What would we log? DNSSEC keys as well as certs? Only DNSSEC keys? Something else? b) How do we prevent the log getting spammed out of existence as soon as it becomes useful? c) When someone observes badness in the log, what do they do about it? I do not intend to drive the answers to these questions, but if someone supplies them I will certainly consider running a DANE log. From fanf2@hermes.cam.ac.uk Wed Nov 14 08:02:10 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB9AF21F862C; Wed, 14 Nov 2012 08:02:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.134 X-Spam-Level: X-Spam-Status: No, score=-5.134 tagged_above=-999 required=5 tests=[AWL=1.465, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-Y+sdpsnRIV; Wed, 14 Nov 2012 08:02:10 -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 4CF5121F8574; Wed, 14 Nov 2012 08:02:10 -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-1.csi.cam.ac.uk ([131.111.8.51]:36011) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1TYfPl-0007Jq-Wy (Exim 4.72) (return-path ); Wed, 14 Nov 2012 16:02:09 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1TYfPl-0006wk-6D (Exim 4.72) (return-path ); Wed, 14 Nov 2012 16:02:09 +0000 Date: Wed, 14 Nov 2012 16:02:09 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Ben Laurie In-Reply-To: Message-ID: References: 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: therightkey@ietf.org, IETF DANE WG list Subject: Re: [dane] DANE and CT X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 16:02:11 -0000 Ben Laurie wrote: > At the CT BoF the question was raised: what about DANE? > > Which is a good question. So, I think Google is prepared to > contemplate running a CT log for DANE, but this leaves some > questions... What problem would CT for DANE be aiming to fix? Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From benl@google.com Wed Nov 14 08:05:25 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D79E321F85A5 for ; Wed, 14 Nov 2012 08:05:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.843 X-Spam-Level: X-Spam-Status: No, score=-102.843 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mSHbb3ch6mdk for ; Wed, 14 Nov 2012 08:05:25 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1600521F859A for ; Wed, 14 Nov 2012 08:05:25 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so645272vbb.31 for ; Wed, 14 Nov 2012 08:05:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=16eQkrzCvoE2YFMNv9RYd7RL1zlUNQEEyYN/YZGDBYs=; b=poIbQVXcTwtzdiCSc6QNBE5BIJwqJit2VUnU7yAYVLZ+Q3NimUgABAFNJsaScqAqi+ r0QiCqYjTAob5aOf+YZfO7FvJEf/oRwcDP6Q9V4H0J1TqFac3xpz+QoyH8TMfmU5DXRo R0eo5iMwjosi6ANVP3uviwkxmmQpr+sTl9nH3GXacTUFvtCoOlkSXfjzIBU7cQkN8CRh 9glm7gkvPE+aAVD7ZkGxarIvUR/PNYowtZs195IG/aw0y02zpfjdhsLFjjrUqTHD8gad PztXTY9fKJ80fDfR8or+brhPcJnrbTyr572GzDthidfipmmwQXFuVaSMub4xI5xLyK5J nGmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=16eQkrzCvoE2YFMNv9RYd7RL1zlUNQEEyYN/YZGDBYs=; b=GDyzQLBN9sVQKVOz/qTTcFRuFdip1o2dnHnBj4oNGNrizWIH5c5hF8WtqOP9gy0e8c iLxe0e3GUucomjDgTleGbzkt6fwF9qrKP4rRXJ2PEs62a4s67N8ZucYBPNTVpqn7mDvj SZx99PgD3oJPbCRPhx/hYcCE6qW0hY+vrTVaVLyc3fzIwnRsMTibrtUAerWXOUSFvdeq iHkzBijBscJ5CsOiwkiDivFytXe+gNO3O8KOZLxGsctVXlxQ5bRpnBkG6RCg0kej7AnJ 9WGa+rAXgo3Ah/Uprk+SyAS3Mgz3xhHFw73FBdO8A54Bwn53/efyM0KSGCJ4/TNSuyE0 GlCg== MIME-Version: 1.0 Received: by 10.220.8.138 with SMTP id h10mr11461766vch.35.1352909124522; Wed, 14 Nov 2012 08:05:24 -0800 (PST) Received: by 10.220.228.6 with HTTP; Wed, 14 Nov 2012 08:05:24 -0800 (PST) In-Reply-To: References: Date: Wed, 14 Nov 2012 16:05:24 +0000 Message-ID: From: Ben Laurie To: Tony Finch Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmsJDc+G0klPys0f/9z3h7HMLinMbpoyy9SvjuroJvcxeKxvJKlJ7y+5163NyVyG1GLD+deK1U/9EiJKiNjzUi4ricKUgd1Bt1MMPyPeXnG08NJBc069WOhds8vkKHeKw4EzzPr4o61nFWjnKrs7oCLQBM8Gs5bbFWkJoDxWnB+vQkRFwqXk/CDiPnFmdTN3ipDWgp8 Cc: therightkey@ietf.org, IETF DANE WG list Subject: Re: [dane] DANE and CT X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 16:05:26 -0000 On 14 November 2012 16:02, Tony Finch wrote: > Ben Laurie wrote: > >> At the CT BoF the question was raised: what about DANE? >> >> Which is a good question. So, I think Google is prepared to >> contemplate running a CT log for DANE, but this leaves some >> questions... > > What problem would CT for DANE be aiming to fix? By all means add that to the list of questions :-) But I assume the same problem CT already fixes: misissuance of certs (which in the DNSSEC world I guess mostly boils down to bad delegation). > > Tony. > -- > f.anthony.n.finch http://dotat.at/ > Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. > Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, > occasionally poor at first. From paul@cypherpunks.ca Wed Nov 14 08:24:32 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD5EE21F85C0 for ; Wed, 14 Nov 2012 08:24:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOSppzRygg4q for ; Wed, 14 Nov 2012 08:24:32 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 5408E21F85CB for ; Wed, 14 Nov 2012 08:24:32 -0800 (PST) Received: by bofh.nohats.ca (Postfix, from userid 500) id 345BB82B69; Wed, 14 Nov 2012 11:23:46 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 2875B804AA; Wed, 14 Nov 2012 11:23:46 -0500 (EST) Date: Wed, 14 Nov 2012 11:23:46 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Tony Finch In-Reply-To: Message-ID: References: <509D5715.4000109@tu-harburg.de> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dane WG list Subject: Re: [dane] no security benefit from insecure or indeterminate domains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 16:24:33 -0000 On Wed, 14 Nov 2012, Tony Finch wrote: >> Well, for "indeterminate", you know that the DNS was very broken, or >> possibly tampered with, and prevented receiving positive or negative >> prove from DNS/TLSA. > > No, indeterminate just means you have no trust anchors. Broken/tampered is > bogus. If you ask with DO bit, and get no answer packet whatsoever, that is indeterminate, but not bogus. >> To me, the actions to perform for "insecure" versus "indeterminate" are >> quite different. > > To me they are equivalent from an app's point of view. proven insecure is a lot different from "could be under attack" Paul From warren@kumari.net Wed Nov 14 08:28:39 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 328F721F85EB; Wed, 14 Nov 2012 08:28:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ObEtRaAZcd+X; Wed, 14 Nov 2012 08:28:38 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3BB21F8620; Wed, 14 Nov 2012 08:28:38 -0800 (PST) Received: from [192.168.2.103] (unknown [209.133.29.2]) by vimes.kumari.net (Postfix) with ESMTPSA id AE7E41B404E9; Wed, 14 Nov 2012 11:28:37 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Warren Kumari In-Reply-To: Date: Wed, 14 Nov 2012 11:28:35 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <212E2C13-CE98-43BB-B665-14DD18236F03@kumari.net> References: To: Tony Finch X-Mailer: Apple Mail (2.1499) Cc: therightkey@ietf.org, IETF DANE WG list Subject: Re: [dane] DANE and CT X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 16:28:39 -0000 On Nov 14, 2012, at 11:02 AM, Tony Finch wrote: > Ben Laurie wrote: >=20 >> At the CT BoF the question was raised: what about DANE? >>=20 >> Which is a good question. So, I think Google is prepared to >> contemplate running a CT log for DANE, but this leaves some >> questions... >=20 > What problem would CT for DANE be aiming to fix? >=20 If I run example.com and someone managed to generate / publish a TLSA = record for that I'd sure like to know about it.=20 Yes, I should be able to simply check myself (and presumably a malicious = actor wouldn't submit it to the log :-)), but it seem like it couldn't = hurt[0] Also, as a relying party, if I'm checking / relying on CT this gives me = additional information - if the cert / TLSSA record do not match the = published stuff in the log I may have evidence that shenanigans are = afoot. Yes, there is a fair bit of detail still to be worked out (what do you = *do* if they don't match? what if a DANE user simply doesn't want to = publish and the world moves to enforced CT?), the "it seems like it = can't hurt" feels scary, and so needs more thought, but to me CT and = DANE seem complementary, not competing technologies=85 W [0]: Famous last words! > Tony. > --=20 > f.anthony.n.finch http://dotat.at/ > Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at = first. > Rough, becoming slight or moderate. Showers, rain at first. Moderate = or good, > occasionally poor at first. > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 -- Do not meddle in the affairs of dragons, for you are crunchy and taste = good with ketchup.=20 From paul@nohats.ca Wed Nov 14 08:31:15 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A94921F85EB; Wed, 14 Nov 2012 08:31:15 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wR8pmpskohVS; Wed, 14 Nov 2012 08:31:15 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 27ACA21F85A5; Wed, 14 Nov 2012 08:31:15 -0800 (PST) Received: by bofh.nohats.ca (Postfix, from userid 500) id A08DE82B69; Wed, 14 Nov 2012 11:30:31 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 970D4804AA; Wed, 14 Nov 2012 11:30:31 -0500 (EST) Date: Wed, 14 Nov 2012 11:30:31 -0500 (EST) From: Paul Wouters To: Ben Laurie In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: therightkey@ietf.org, IETF DANE WG list Subject: Re: [dane] [therightkey] DANE and CT X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 16:31:15 -0000 On Wed, 14 Nov 2012, Ben Laurie wrote: >>> At the CT BoF the question was raised: what about DANE? >>> >>> Which is a good question. So, I think Google is prepared to >>> contemplate running a CT log for DANE, but this leaves some >>> questions... >> >> What problem would CT for DANE be aiming to fix? > > By all means add that to the list of questions :-) > > But I assume the same problem CT already fixes: misissuance of certs > (which in the DNSSEC world I guess mostly boils down to bad > delegation). Does that make sense though? With RRSIG validity times and TTL's you can set your "damange period" as small as you want. There is no issue like with certificates where your credentials can be abused for up to 12 months. The only use I could see is as an alternative mechanism to transfer these records into the application that does not require a clean DNS transport. I think CT is a bandaid for PKIX that does not apply to DANE. I think the problem with DANE/DNSSEC right now is the additional latency and dns transport issues (hotspots, VPN, etc) but I don't think CT is very well suited to address those. Paul From benl@google.com Wed Nov 14 08:35:32 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFFD921F84D4 for ; Wed, 14 Nov 2012 08:35:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.867 X-Spam-Level: X-Spam-Status: No, score=-102.867 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ve5msemkABmO for ; Wed, 14 Nov 2012 08:35:32 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id F422B21F84B6 for ; Wed, 14 Nov 2012 08:35:31 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fl11so710262vcb.31 for ; Wed, 14 Nov 2012 08:35:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nOgr9Y0B/Lm9ouBvldPDv4hrw5yMlNz93n+LO8bRs+I=; b=SGxwFCbhtQzwf51Lh5UkTHTfvib6cW0VwiRnbsPMYsHE+BXhoyRbxffBgJsz5dMqO0 CFTXPAFmifC5ZgzLDqOFQtZIKCq+5JNY11OR9y/iu6l/3/AtVMA9GEMTMtAdqE/bMzWS ZfuvSL8OgJHaK1WGXn3p/DGXUVwhCe+UxuEJEHg+J1X3nuVqPWbZ94N/6Co/i38hLRGN 8pwShU578fET2cEN1Y+4M2UFDD+9AUUofi4Ww/kpST8jBrIDruVtih3PA/+85cqSSgGk ZXS6JA7rk67wkzs+E5GpK4NujsQ5FUc72MmEAq7rgvh8Lsrv4GpXMPQMLXxp1jHWj7jX adaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=nOgr9Y0B/Lm9ouBvldPDv4hrw5yMlNz93n+LO8bRs+I=; b=bIQMo1C97uRukZjS+EHZR3t5rKI+qvEW1104JBCWiQTkVEc+LBHi7+pCRfSeNiyLYE B1wnKHLLYqAnrutdv+1OW0Z1i102KVlQblWokbEKRyh7hQrGYEp5bxf2r9fTFyTXEMQD NdMZ6D3gY2oaNaeF9OYoSZPCrzXVZ6nTPGA7RmDGkvgHWzpcZhETHr/6C2KcjO0ZQis/ 9i9eD6gFnPRzYFXk33doeiScasz5ArsEoRXMxUEia/QcHvFQvbWiYH+hcPmWsn9hgxMZ txodqROVB51LmsIlYx6Z1BnVmekDUZgTveGzcFhye/dFQ7BrOMZz+5QdiItzYArkhKoT 7syQ== MIME-Version: 1.0 Received: by 10.52.175.167 with SMTP id cb7mr2624498vdc.58.1352910931286; Wed, 14 Nov 2012 08:35:31 -0800 (PST) Received: by 10.220.228.6 with HTTP; Wed, 14 Nov 2012 08:35:31 -0800 (PST) In-Reply-To: References: Date: Wed, 14 Nov 2012 16:35:31 +0000 Message-ID: From: Ben Laurie To: Paul Wouters Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQln2b6DsPehysHWCekVFaQ0w787MtJ2xfVglaScT5ucrcUaaj4pt+GEdVsRLGRefEcsdxoCJpxNL4knGKdFcRjWPE2VYoL36MCGm4wkWIW8GGuPbZVINejPFZnCUK5+USEMBJn8CzDcJFvRrso10HV1lKWqYFZqDCWxvMaP1sBizzRKIFc+dtH/vsT/c05LrAYnFvp4 Cc: therightkey@ietf.org, IETF DANE WG list Subject: Re: [dane] [therightkey] DANE and CT X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 16:35:33 -0000 On 14 November 2012 16:30, Paul Wouters wrote: > On Wed, 14 Nov 2012, Ben Laurie wrote: > >>>> At the CT BoF the question was raised: what about DANE? >>>> >>>> Which is a good question. So, I think Google is prepared to >>>> contemplate running a CT log for DANE, but this leaves some >>>> questions... >>> >>> >>> What problem would CT for DANE be aiming to fix? >> >> >> By all means add that to the list of questions :-) >> >> But I assume the same problem CT already fixes: misissuance of certs >> (which in the DNSSEC world I guess mostly boils down to bad >> delegation). > > > Does that make sense though? With RRSIG validity times and TTL's you > can set your "damange period" as small as you want. There is no issue > like with certificates where your credentials can be abused for up to > 12 months. > > The only use I could see is as an alternative mechanism to transfer these > records into the application that does not require a clean DNS transport. > > I think CT is a bandaid for PKIX that does not apply to DANE. > > I think the problem with DANE/DNSSEC right now is the additional latency > and dns transport issues (hotspots, VPN, etc) but I don't think CT is > very well suited to address those. a) Why would an attacker use your validity times? b) Weren't you amongst those asking for CT to support DANE during the BoF? I disagree that CT is a bandaid for anything, BTW - it is a useful mechanism in its own right. From tom@ritter.vg Wed Nov 14 08:37:39 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D48321F84D4 for ; Wed, 14 Nov 2012 08:37:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7vnfcC55lnU for ; Wed, 14 Nov 2012 08:37:38 -0800 (PST) Received: from mail-yh0-f44.google.com (mail-yh0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6B95521F84B6 for ; Wed, 14 Nov 2012 08:37:38 -0800 (PST) Received: by mail-yh0-f44.google.com with SMTP id 56so122987yhq.31 for ; Wed, 14 Nov 2012 08:37:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=pwbgCmqI5i/G/yrvqjWD8+UAEBxmRFvbiMO2k7lA71g=; b=Tf6fFpkEA4z1Hv/PiWddOF0DGXCLgHDWgCxdyOYMshhdIuo3WdNzCy6HsGRh91mzeU GuVmCBt1+xg5fBBsjA5GnD8LQXmHvgZgZe26ZZmIRPOdrfuKrBLvbJPgIp3UrqwpkdJR fopYGJ8p/dAcHNW9E1TCYCosfs2CkABp3LpHY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=pwbgCmqI5i/G/yrvqjWD8+UAEBxmRFvbiMO2k7lA71g=; b=chnNFk0veB1sbAWD5Jun9UA2Rp1b1UudGZodhgapa3IrOh0Dii1cE92oLmf+2N87cS Vja0l0EgRb2CgyKPJcn4WYq5WjPD+zhcLQqCAjCle2ZMyFlq6cHEUa8kqkWyS8u0IU+a AMDfNUNLXii2DsbKa37D6yWvTp7YJfi3kGW0NjTtWaS6CgIFWwH4lykaSBz753WsUSXF I2XxArUngNlbsPrN1n4q5zXRIVmeHiKmtFvTF0NAWGqrt4GRawaUBqL85YUjZVLklfea EjAfVKCHncVYK0VTi6rFdmq2ya9PfV4j71/T84PcN969temH+r27aqe2tJukuEy8qcPA zvCA== Received: by 10.58.221.228 with SMTP id qh4mr32457359vec.49.1352911057898; Wed, 14 Nov 2012 08:37:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.151.178 with HTTP; Wed, 14 Nov 2012 08:37:17 -0800 (PST) In-Reply-To: References: From: Tom Ritter Date: Wed, 14 Nov 2012 11:37:17 -0500 Message-ID: To: Paul Wouters Content-Type: multipart/alternative; boundary=047d7bdc7a9a04ced304ce772724 X-Gm-Message-State: ALoCoQkUA69kjhHoaoT1An/Qe3dMatRrJyrNf+3t9xhICRADQkXf2tD8FRUlad5ETv5h1XSii3Q7 Cc: therightkey@ietf.org, IETF DANE WG list Subject: Re: [dane] [therightkey] DANE and CT X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 16:37:39 -0000 --047d7bdc7a9a04ced304ce772724 Content-Type: text/plain; charset=ISO-8859-1 On 14 November 2012 11:30, Paul Wouters wrote: > I think CT is a bandaid for PKIX that does not apply to DANE. > Perhaps not DANE - but DNSSEC. PKIX allows N CAs to issue unlimited trusted certs for your domain. DNSSEC allows 1 TLD to issue unlimited trusted signing keys for your domain. Maybe it's the KSK that should go into a log? -tom --047d7bdc7a9a04ced304ce772724 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 14 November 2012 11:30, Paul Wouters <paul@nohats.ca> wrote:=
I think CT is a bandaid for PKIX that does not apply to D= ANE.

Perhaps not DANE - but DNSSEC. = =A0PKIX allows N CAs to issue unlimited trusted certs for your domain. =A0D= NSSEC allows 1 TLD to issue unlimited trusted signing keys for your domain.= =A0Maybe it's the KSK that should go into a log?

-tom
--047d7bdc7a9a04ced304ce772724-- From fanf2@hermes.cam.ac.uk Wed Nov 14 08:38:52 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77FD921F84D4 for ; Wed, 14 Nov 2012 08:38:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.427 X-Spam-Level: X-Spam-Status: No, score=-5.427 tagged_above=-999 required=5 tests=[AWL=1.172, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dWvdgnIJAEl for ; Wed, 14 Nov 2012 08:38:51 -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 C514221F84B6 for ; Wed, 14 Nov 2012 08:38:51 -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-1.csi.cam.ac.uk ([131.111.8.51]:60191) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1TYfzA-0006rq-Qh (Exim 4.72) (return-path ); Wed, 14 Nov 2012 16:38:44 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1TYfzA-0003ed-8K (Exim 4.72) (return-path ); Wed, 14 Nov 2012 16:38:44 +0000 Date: Wed, 14 Nov 2012 16:38:44 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Paul Wouters In-Reply-To: Message-ID: References: <509D5715.4000109@tu-harburg.de> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dane WG list Subject: Re: [dane] no security benefit from insecure or indeterminate domains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 16:38:52 -0000 Paul Wouters wrote: > On Wed, 14 Nov 2012, Tony Finch wrote: > > > > No, indeterminate just means you have no trust anchors. Broken/tampered is > > bogus. > > If you ask with DO bit, and get no answer packet whatsoever, that is > indeterminate, but not bogus. Oh this is the 4033 / 4035 inconsistency again. I think the "indeterminate" status is useless. It's operationally equivalent to either insecure or to bogus. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From fanf2@hermes.cam.ac.uk Wed Nov 14 09:02:47 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A2C421F8680; Wed, 14 Nov 2012 09:02:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.623 X-Spam-Level: X-Spam-Status: No, score=-5.623 tagged_above=-999 required=5 tests=[AWL=0.977, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4cq1a3DEgQe; Wed, 14 Nov 2012 09:02:46 -0800 (PST) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id EE37521F85FD; Wed, 14 Nov 2012 09:02:45 -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-1.csi.cam.ac.uk ([131.111.8.51]:56726) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1TYgMN-00007K-rr (Exim 4.72) (return-path ); Wed, 14 Nov 2012 17:02:43 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1TYgMN-00074g-Lf (Exim 4.72) (return-path ); Wed, 14 Nov 2012 17:02:43 +0000 Date: Wed, 14 Nov 2012 17:02:43 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Warren Kumari In-Reply-To: <212E2C13-CE98-43BB-B665-14DD18236F03@kumari.net> Message-ID: References: <212E2C13-CE98-43BB-B665-14DD18236F03@kumari.net> 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: therightkey@ietf.org, IETF DANE WG list Subject: Re: [dane] DANE and CT X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 17:02:47 -0000 Warren Kumari wrote: > > If I run example.com and someone managed to generate / publish a TLSA > record for that I'd sure like to know about it. Right. But in PKIX a mis-issued certificate has nothing to do with your own infrastructure, whereas with DANE it implies that your infrastructure (or the infrastructure of your DNS service providers) has been compromised. I'm a bit worried about the operational implications: PKIX CT is extra work for CAs, but DANE CT is extra work for everyone. So I'm skeptical that the cost/benefit tradeoff is positive. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From benl@google.com Wed Nov 14 09:07:59 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B802021F86FC for ; Wed, 14 Nov 2012 09:07:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.891 X-Spam-Level: X-Spam-Status: No, score=-102.891 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGE0PDgzc+x1 for ; Wed, 14 Nov 2012 09:07:59 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id E479021F8689 for ; Wed, 14 Nov 2012 09:07:58 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fl11so749902vcb.31 for ; Wed, 14 Nov 2012 09:07:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HwILyQRrXBtL6Byx0W+CAPICoPjQVvZIQ4MmEwITe6k=; b=Ag1A4mOqDtmhn0WPFlxf4a09ShDkXvmVfrytXweckYDXqBdBxhlGORjDKgrfknsuIm oXINLjKXAmlkYywZcyaudZFpSgyMbRETfvtKGIWIvxo1KeWai8IKjoNEEr9H4RF4i9ix O9wnY/9ZjBSJ9lOay/Trz1yWebAHacijkd/uX0c7bVtwus9M/xThJ47ubICR9/jPjqeq IiM3VL1wM1VnBJ84g+TmDqgeI4F8Fln2KwfZ75GD8HR/utOpgNjLXG8GcUMPltPiB3po cUE92Exo5HO+lwPS5fDr4mCZ7wTWrrHWFbIwAE5UiQFTW4MmMW8VfU0xcXbHk6+MtuZM 2ihA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=HwILyQRrXBtL6Byx0W+CAPICoPjQVvZIQ4MmEwITe6k=; b=l6aBoTyg4OPQxyEUCvI8sfjicMC3no1tJuyGobvtgA1Qq4/p2L5Ez5RwzDCvq8SR8A cKenOK60iGy4yr8SvN50aQDwMrBkVXAYG8CQ15SjiiH5F2742A+D/Lb2XnaHif5q/Eni 3zT06UfcNcaU76DVZHJkZZyy7lNUmBihpUz7ZA8xmujLVFXUzRuRRi459vA3w+5vO1T/ QenzYkZg91xZh7wmhrt+eQ4xtcMFCdQDw1n8H9U995VrdyWLFw7kFeN80kFCgZ1Lux+p +1NlFnX6GmMJVtopPkd+Ajn4y4m3rhCP9JgN3SE/UiM9OeB61XgwTmLfyEbWoPkPrDrP MIjw== MIME-Version: 1.0 Received: by 10.220.155.132 with SMTP id s4mr11792136vcw.15.1352912878344; Wed, 14 Nov 2012 09:07:58 -0800 (PST) Received: by 10.220.228.6 with HTTP; Wed, 14 Nov 2012 09:07:58 -0800 (PST) In-Reply-To: References: <212E2C13-CE98-43BB-B665-14DD18236F03@kumari.net> Date: Wed, 14 Nov 2012 17:07:58 +0000 Message-ID: From: Ben Laurie To: Tony Finch Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkoCUm81lLww8o7zc5XEA5F7s0gzJ8/nzMFRMOI3J43EZ34RU77he7FuAJINdy6xI6lNoIngB7v3xV7bw0lOOfJYkFG5zYyCjMbUZhKFnWVibCzJvdMP4vaWw0oPDXglAw7V/mdO5fzZ9cqwgkoLoYBV881oUeAQ8uGzLeB4I9Tu+0NWX7pRGvyUDYICEHjWk4uwYXb Cc: therightkey@ietf.org, IETF DANE WG list Subject: Re: [dane] DANE and CT X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 17:07:59 -0000 On 14 November 2012 17:02, Tony Finch wrote: > Warren Kumari wrote: >> >> If I run example.com and someone managed to generate / publish a TLSA >> record for that I'd sure like to know about it. > > Right. But in PKIX a mis-issued certificate has nothing to do with your > own infrastructure, whereas with DANE it implies that your infrastructure > (or the infrastructure of your DNS service providers) has been > compromised. Isn't the infrastructure of your DNS service providers nothing to do with your own infrastructure? Not to mention your TLD's infrastructure, and that of all of their registrars (and, presumably, DNS service providers)? > I'm a bit worried about the operational implications: PKIX CT is extra > work for CAs, but DANE CT is extra work for everyone. Only everyone who uses keys, and they've already signed up for quite a lot of work. > So I'm skeptical that the cost/benefit tradeoff is positive. I am unconvinced by your argument. > > Tony. > -- > f.anthony.n.finch http://dotat.at/ > Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. > Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, > occasionally poor at first. From shuque@upenn.edu Wed Nov 14 09:29:52 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC7821F86FF; Wed, 14 Nov 2012 09:29:52 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8aHPVXuoox0; Wed, 14 Nov 2012 09:29:51 -0800 (PST) Received: from mopeypopo.net.isc.upenn.edu (www.huque.com [IPv6:2607:f470:2:1::a:2]) by ietfa.amsl.com (Postfix) with ESMTP id B978A21F8754; Wed, 14 Nov 2012 09:29:51 -0800 (PST) Received: by mopeypopo.net.isc.upenn.edu (Postfix, from userid 500) id 9B56AA5002; Wed, 14 Nov 2012 12:29:50 -0500 (EST) Date: Wed, 14 Nov 2012 12:29:50 -0500 From: Shumon Huque To: Ben Laurie Message-ID: <20121114172950.GA13499@isc.upenn.edu> References: <212E2C13-CE98-43BB-B665-14DD18236F03@kumari.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: University of Pennsylvania User-Agent: Mutt/1.5.21 (2010-09-15) Cc: therightkey@ietf.org, IETF DANE WG list Subject: Re: [dane] DANE and CT X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 17:29:52 -0000 On Wed, Nov 14, 2012 at 05:07:58PM +0000, Ben Laurie wrote: > On 14 November 2012 17:02, Tony Finch wrote: > > Warren Kumari wrote: > >> > >> If I run example.com and someone managed to generate / publish a TLSA > >> record for that I'd sure like to know about it. > > > > Right. But in PKIX a mis-issued certificate has nothing to do with your > > own infrastructure, whereas with DANE it implies that your infrastructure > > (or the infrastructure of your DNS service providers) has been > > compromised. > > Isn't the infrastructure of your DNS service providers nothing to do > with your own infrastructure? Not to mention your TLD's > infrastructure, and that of all of their registrars (and, presumably, > DNS service providers)? One critical difference is that with DANE, I can query the DNSSEC delegation chain myself and detect whether my TLD has installed a bogus DS record and take action. I cannot today detect a bogus X.509 cert by myself. I think this makes a CT like scheme less necessary for DANE. -- Shumon Huque University of Pennsylvania. From tom@ritter.vg Wed Nov 14 09:51:29 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BCAE21F8615 for ; Wed, 14 Nov 2012 09:51:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3sTmN0Sm9FJy for ; Wed, 14 Nov 2012 09:51:26 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D51DC21F85F3 for ; Wed, 14 Nov 2012 09:51:25 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fl11so805596vcb.31 for ; Wed, 14 Nov 2012 09:51:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=p+6q9B26GioLatIMK2lqBbTg1B3K1eKUgCq3tA0FnMM=; b=uiBl5vWpvoz+L3SQiVeq/pmizJYMMnNWFfUkeQpkK8FVmVTnD3BiWmizzGaBwpRWBG j4H5H12x8d/9Mbf+fQQfuIZz/CsndmtUkqnO/Jpgu4qyqm+Oe8vT9hIvUS+WpYPbBKnn 7Yw3jLxm1ffRduHmVSYRc6bd8R7crnCnVe2iQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=p+6q9B26GioLatIMK2lqBbTg1B3K1eKUgCq3tA0FnMM=; b=JbIX6dJGKxVhe7g6/0jac08cNYUUwe5bkCr+ndbJfEvi8kwHp31/4N+9RuQZZYY4Fh xkwgqVtQAZatbUT0cUxw8Ac5wJlzxSqDuej/Ls8yIL74LI+0xAaxaE2OEBM819rsOy0D rToNh4klzFoTFtLbAMye+vDZHToHVQNzT8+XHNYKHRGveqFYFXVZOzRQNmn74Xpibcvc /BoqAXIT7jPrLKPCUVEFyzZSqRpElDnkjidcQ0+LXquTlYd+ytFPT+0hp6EI+n5aX12z JFT2Vm7fPvjOeeXNYs4eZrzh6lDSI0ja4HdelSpeOYTCdV5Z0OQ+JagRJowmr7iEQKNp gwzA== Received: by 10.220.227.199 with SMTP id jb7mr11865187vcb.26.1352915485056; Wed, 14 Nov 2012 09:51:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.151.178 with HTTP; Wed, 14 Nov 2012 09:51:04 -0800 (PST) In-Reply-To: <20121114172950.GA13499@isc.upenn.edu> References: <212E2C13-CE98-43BB-B665-14DD18236F03@kumari.net> <20121114172950.GA13499@isc.upenn.edu> From: Tom Ritter Date: Wed, 14 Nov 2012 12:51:04 -0500 Message-ID: To: Shumon Huque Content-Type: multipart/alternative; boundary=14dae9cdca9be5de6304ce782edd X-Gm-Message-State: ALoCoQkfOaY7WP2pWkFsy2ogUA1m6uOyTLgE+zdjozM5FN/tWA58PwX3/1E6Z/JSft/Hyyg08TRk Cc: therightkey , IETF DANE WG list Subject: Re: [dane] DANE and CT X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 17:51:29 -0000 --14dae9cdca9be5de6304ce782edd Content-Type: text/plain; charset=ISO-8859-1 On 14 November 2012 12:29, Shumon Huque wrote: > One critical difference is that with DANE, I can query the DNSSEC > delegation chain myself and detect whether my TLD has installed a > bogus DS record and take action. I cannot today detect a bogus > X.509 cert by myself. I think this makes a CT like scheme less necessary > for DANE. I can query my server on port 443 and see if there is a bogus certificate. The lack of a bogus certificate in a response to a single query does not mean there is not a valid attacker-controlled signature chain an attacker could send to attack a user - whether that signature chain is of PKIX signatures or DNSSEC signatures. -tom --14dae9cdca9be5de6304ce782edd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 14 November 2012 12:29, Shumon Huque <shuque@upenn.edu> wr= ote:
One critical difference is that with DANE, I can query th= e DNSSEC
delegation chain myself and detect whether my TLD has installed a
bogus DS record and take action. I cannot today detect a bogus
X.509 cert by myself. I think this makes a CT like scheme less necessary for DANE.

I can query my server on port 443= and see if there is a bogus certificate. =A0The lack of a bogus certificat= e in a response to a single query does not mean there is not a valid attack= er-controlled signature chain an attacker could send to attack a user - whe= ther that signature chain is of PKIX signatures or DNSSEC signatures.

-tom
--14dae9cdca9be5de6304ce782edd-- From benl@google.com Wed Nov 14 09:56:32 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5BD421F853A for ; Wed, 14 Nov 2012 09:56:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.902 X-Spam-Level: X-Spam-Status: No, score=-102.902 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C1vA6V7wnfxd for ; Wed, 14 Nov 2012 09:56:32 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8D84A21F8522 for ; Wed, 14 Nov 2012 09:56:25 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so783558vbb.31 for ; Wed, 14 Nov 2012 09:56:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/5IJtKVvHU5cnswul0O+m6SBCqI2HN4iAQtNWEMFqaY=; b=WM6o+CIIifNnNW+ZYpw9ZhtQQNL62mxnaKN1zmAbE3vX1zlZRy2/edFd156AinMkL0 JljxwPhH6eUn4Jy2pdq7yCpf+5Qd7dGtHQy3+XaHTGsERrWnfqtzfzy69PmrfjJYnWac 0pNDYky8+UB0GmkRau0oLryCdSOdQKpbXN99GmfjCuyw+TuCH96WS1aLT5+6vsxdAa9k fSmup7hbOuIxgJvM5MaxPHYR3tQhxDECUiZITzIzxAO6W2twSw4Oo0rfUGsR9eqyqGvQ JM1ds1ln59AorJmyIuZjvmo2lwezC4GekWnii2cOU0wTEQbC3TNM8Nmb1lTYSUzYMtpj 0iCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=/5IJtKVvHU5cnswul0O+m6SBCqI2HN4iAQtNWEMFqaY=; b=KJSZa48w9+odPdLPl8lPvQ2EK6bpofm6kHVdC6ivi5Nv2ByRi0aOqWT4hn6dpQGixB YqwLu86lhr0kIViPE7Yi5QGhAef89fzhc9wzbDzmSiQ2butCl4XY+FTNsINiWHmiCIPq Zntvs9RWNriDWe5x5NVIOVN8pKy9t3bc/y+/licfnItQX74vD1UnPPv52pdmH9Ua69Xo KEm2fSbPUbgRguPWMDgPNSo5SRctQnGQ7TX1KtGawRce9ZbIWol/8EK64d2tG6QmaDn5 j1BcnERXwOdcq5d9X24+Uxcq0xyxWw43bSpPmF+bGYh2p5QlreNBwZDJpA+HGuy6bQzV lR6Q== MIME-Version: 1.0 Received: by 10.220.155.132 with SMTP id s4mr11984047vcw.15.1352915784929; Wed, 14 Nov 2012 09:56:24 -0800 (PST) Received: by 10.220.228.6 with HTTP; Wed, 14 Nov 2012 09:56:24 -0800 (PST) In-Reply-To: <20121114172950.GA13499@isc.upenn.edu> References: <212E2C13-CE98-43BB-B665-14DD18236F03@kumari.net> <20121114172950.GA13499@isc.upenn.edu> Date: Wed, 14 Nov 2012 17:56:24 +0000 Message-ID: From: Ben Laurie To: Shumon Huque Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnvXfJoQ4PqG1XOZVvTsWwiqUAdSvpt1DPpNHjTEsKVHOxkAexTgnYXIGd9y9lfRjbwBBzu+9BftRNE/BkbV0s0qSGviPuzdjIMuRnAzJFmMxwNMWzcva9R3KPol9Qu3ojzHxoc6qWQbc9EUJVl2SbOhBl0eGcl7Sq7oVIVuXaGwBhwkflBm4LrnESYHu65arcsFK3a Cc: therightkey@ietf.org, IETF DANE WG list Subject: Re: [dane] DANE and CT X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 17:56:33 -0000 On 14 November 2012 17:29, Shumon Huque wrote: > On Wed, Nov 14, 2012 at 05:07:58PM +0000, Ben Laurie wrote: >> On 14 November 2012 17:02, Tony Finch wrote: >> > Warren Kumari wrote: >> >> >> >> If I run example.com and someone managed to generate / publish a TLSA >> >> record for that I'd sure like to know about it. >> > >> > Right. But in PKIX a mis-issued certificate has nothing to do with your >> > own infrastructure, whereas with DANE it implies that your infrastructure >> > (or the infrastructure of your DNS service providers) has been >> > compromised. >> >> Isn't the infrastructure of your DNS service providers nothing to do >> with your own infrastructure? Not to mention your TLD's >> infrastructure, and that of all of their registrars (and, presumably, >> DNS service providers)? > > One critical difference is that with DANE, I can query the DNSSEC > delegation chain myself and detect whether my TLD has installed a > bogus DS record and take action. I cannot today detect a bogus > X.509 cert by myself. I think this makes a CT like scheme less necessary > for DANE. You can't detect a bogus X.509 cert because you can't connect to the server serving it, presumably. What magic allows you to perform this trick for DNS but not HTTPS? > > -- > Shumon Huque > University of Pennsylvania. From carl@redhoundsoftware.com Wed Nov 14 09:57:19 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C067A21F853A for ; Wed, 14 Nov 2012 09:57:19 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6OxDcGVMkLmp for ; Wed, 14 Nov 2012 09:57:19 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4601F21F8626 for ; Wed, 14 Nov 2012 09:57:19 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so784537vbb.31 for ; Wed, 14 Nov 2012 09:57:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding :x-gm-message-state; bh=WjyuB3a70C1HKNfJGt1Nz5G1dE77aapWIRROn4WOwb4=; b=fXB2EHdV0sr9lVkVypJiQ9V5fuZpoClx0rUgbYSTjqe0EmdPxJv0u2ds0DVEc0Y6Zj 3AbLc0mjKZizwo0WxnuHzhw1kx5IgU5fOUDU/wAYeq/1oS/BQzwpOIcI7v0JIOMJcml2 c4+7z1dxl0MUpVRxJvEeYZMaqWL4N22O0MLNN/rR7VVrKDf8ZgtLe0k0k29Wb9UyCqbv H1sjeXYxE1WgwAI+yDRR4OD0/1Q0dlsl5jNubgDfoMbiGoqpVyET+g8PtlpXTZqOJ5lU hpzmqKRpeQsaKAzdHWIlP9xPURmFGLSpJC0lKB58IPSrvjcNpdLsl6W2mzVNTg/8ciZW W1MA== Received: by 10.52.68.7 with SMTP id r7mr2929334vdt.96.1352915838381; Wed, 14 Nov 2012 09:57:18 -0800 (PST) Received: from [192.168.2.3] (pool-173-79-132-206.washdc.fios.verizon.net. [173.79.132.206]) by mx.google.com with ESMTPS id d4sm11476492vew.7.2012.11.14.09.57.14 (version=SSLv3 cipher=OTHER); Wed, 14 Nov 2012 09:57:17 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Wed, 14 Nov 2012 12:57:06 -0500 From: Carl Wallace To: Paul Wouters , Ben Laurie Message-ID: Thread-Topic: [dane] [therightkey] DANE and CT In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Gm-Message-State: ALoCoQmSXIJy65o8QXwbpAEYwA0OD6uEqtxrb6Vmebgs9PtJh3en4ttRZ97at3AT6c735BsNEvzj Cc: therightkey@ietf.org, IETF DANE WG list Subject: Re: [dane] [therightkey] DANE and CT X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 17:57:19 -0000 On 11/14/12 11:30 AM, "Paul Wouters" wrote: >I think CT is a bandaid for PKIX that does not apply to DANE. I thought the point was that DANE would not be allowed to do "an end run" around CT so logging DANE stuff was necessary, not that DANE necessarily had the same needs as the web PKI. From shuque@upenn.edu Wed Nov 14 10:14:39 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5179F21F8758; Wed, 14 Nov 2012 10:14:39 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJazXCjdpGG0; Wed, 14 Nov 2012 10:14:38 -0800 (PST) Received: from mopeypopo.net.isc.upenn.edu (www.huque.com [IPv6:2607:f470:2:1::a:2]) by ietfa.amsl.com (Postfix) with ESMTP id B3A7721F86A8; Wed, 14 Nov 2012 10:14:38 -0800 (PST) Received: by mopeypopo.net.isc.upenn.edu (Postfix, from userid 500) id E70B3A5002; Wed, 14 Nov 2012 13:14:37 -0500 (EST) Date: Wed, 14 Nov 2012 13:14:37 -0500 From: Shumon Huque To: Ben Laurie Message-ID: <20121114181437.GA26508@isc.upenn.edu> References: <212E2C13-CE98-43BB-B665-14DD18236F03@kumari.net> <20121114172950.GA13499@isc.upenn.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: University of Pennsylvania User-Agent: Mutt/1.5.21 (2010-09-15) Cc: therightkey@ietf.org, IETF DANE WG list Subject: Re: [dane] [therightkey] DANE and CT X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 18:14:39 -0000 On Wed, Nov 14, 2012 at 05:56:24PM +0000, Ben Laurie wrote: > On 14 November 2012 17:29, Shumon Huque wrote: > > On Wed, Nov 14, 2012 at 05:07:58PM +0000, Ben Laurie wrote: > >> On 14 November 2012 17:02, Tony Finch wrote: > >> > Warren Kumari wrote: > >> >> > >> >> If I run example.com and someone managed to generate / publish a TLSA > >> >> record for that I'd sure like to know about it. > >> > > >> > Right. But in PKIX a mis-issued certificate has nothing to do with your > >> > own infrastructure, whereas with DANE it implies that your infrastructure > >> > (or the infrastructure of your DNS service providers) has been > >> > compromised. > >> > >> Isn't the infrastructure of your DNS service providers nothing to do > >> with your own infrastructure? Not to mention your TLD's > >> infrastructure, and that of all of their registrars (and, presumably, > >> DNS service providers)? > > > > One critical difference is that with DANE, I can query the DNSSEC > > delegation chain myself and detect whether my TLD has installed a > > bogus DS record and take action. I cannot today detect a bogus > > X.509 cert by myself. I think this makes a CT like scheme less necessary > > for DANE. > > You can't detect a bogus X.509 cert because you can't connect to the > server serving it, presumably. What magic allows you to perform this > trick for DNS but not HTTPS? For the DANE/DNSSEC case, I'm detecting an attack on the DNSSEC authentication chain, not the existence of a fraudulently issued certificate on some attacker's server. If the DNSSEC chain is intact, then presumably DANE aware clients will properly authenticate the TLSA record before accepting the server certificate. I admit that's a mighty presumption today, but we'll see ... -- Shumon Huque University of Pennsylvania. From fneves@registro.br Wed Nov 14 10:49:03 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45C4E21F8626; Wed, 14 Nov 2012 10:49:03 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ei4wsYCdJxfo; Wed, 14 Nov 2012 10:49:02 -0800 (PST) Received: from clone.registro.br (clone.registro.br [IPv6:2001:12ff:0:2::4]) by ietfa.amsl.com (Postfix) with ESMTP id 8780421F8622; Wed, 14 Nov 2012 10:49:02 -0800 (PST) Received: by clone.registro.br (Postfix, from userid 1000) id 27B25E0446; Wed, 14 Nov 2012 16:48:59 -0200 (BRST) Date: Wed, 14 Nov 2012 16:48:59 -0200 From: Frederico A C Neves To: Ben Laurie Message-ID: <20121114184859.GB18212@registro.br> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: therightkey@ietf.org, Paul Wouters , IETF DANE WG list Subject: Re: [dane] [therightkey] DANE and CT X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 18:49:03 -0000 On Wed, Nov 14, 2012 at 04:35:31PM +0000, Ben Laurie wrote: > On 14 November 2012 16:30, Paul Wouters wrote: > > On Wed, 14 Nov 2012, Ben Laurie wrote: ... > >>> What problem would CT for DANE be aiming to fix? > >> > >> > >> By all means add that to the list of questions :-) > >> > >> But I assume the same problem CT already fixes: misissuance of certs > >> (which in the DNSSEC world I guess mostly boils down to bad > >> delegation). > > > > > > Does that make sense though? With RRSIG validity times and TTL's you > > can set your "damange period" as small as you want. There is no issue > > like with certificates where your credentials can be abused for up to > > 12 months. > > > > The only use I could see is as an alternative mechanism to transfer these > > records into the application that does not require a clean DNS transport. > > > > I think CT is a bandaid for PKIX that does not apply to DANE. > > > > I think the problem with DANE/DNSSEC right now is the additional latency > > and dns transport issues (hotspots, VPN, etc) but I don't think CT is > > very well suited to address those. > > a) Why would an attacker use your validity times? What do you mean? What is your attack scenario? This thread quickly starts to move to a marshy soil. Fred From leifj@mnt.se Wed Nov 14 14:52:40 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A054721F8850 for ; Wed, 14 Nov 2012 14:52:40 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRreoD05v9Lb for ; Wed, 14 Nov 2012 14:52:29 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7E48821F8721 for ; Wed, 14 Nov 2012 14:52:25 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id w11so470660bku.31 for ; Wed, 14 Nov 2012 14:52:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=jOvtKyA48ePt1n5Cg4aD7qHNK7+Zl3RuMwB+PiomkdM=; b=Ugz/vKYYScEPj4FtDEOAM56auDK9LQkecAWTElIiX6jT9D2FTBlQCbSClNKbp/BPWh oKsoZ5KWC/yh5/+QGQ6pKheOCaW8DP87D38tPI0TsP3pOLP0HfZFm6+8HcJZ5jQ0ISnG oeTtTCsewKsb0JmcdKVfepoUEWYPEUZIkhRgg0mD1QeslSZhFTaJSX4v+SVEgDn+nsms Vg2FM0CihXKYSiypOofXskD/rESh+yVOUzMZ7YiKfAhq0uEVxM2dQc48Yj27hZgI0HBA PbZcV/oxk5AsQmvil4uk3TqE9lRD2ivtikDI96Sz9j76I7ZNg5LERY3W03lXbjpJTlRe wUnQ== Received: by 10.204.147.132 with SMTP id l4mr3758312bkv.20.1352933544431; Wed, 14 Nov 2012 14:52:24 -0800 (PST) Received: from [10.0.0.244] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by mx.google.com with ESMTPS id fm5sm9131632bkc.5.2012.11.14.14.52.22 (version=SSLv3 cipher=OTHER); Wed, 14 Nov 2012 14:52:23 -0800 (PST) Message-ID: <50A420A5.2090500@mnt.se> Date: Wed, 14 Nov 2012 23:52:21 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: dane@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnTQeoR4fCUzVf3fuVexu1GXe6xJr+rPvp+KUfsSuV8kG9VmWANv30IJRM2NqDdIKwPCziC Subject: Re: [dane] DANE and CT X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 22:52:40 -0000 On 11/14/2012 05:02 PM, Tony Finch wrote: > Ben Laurie wrote: > >> At the CT BoF the question was raised: what about DANE? >> >> Which is a good question. So, I think Google is prepared to >> contemplate running a CT log for DANE, but this leaves some >> questions... > What problem would CT for DANE be aiming to fix? > > Tony. You're sending a chain to the log server for CT. The chain must be rooted at something that is reasonably widely trusted (to avoid spamming). For DANE, that means extending the chain through DNSSEC up to the DNS root. my 5c From leifj@mnt.se Wed Nov 14 14:54:00 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9EC821F8721 for ; Wed, 14 Nov 2012 14:54:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JyyFPcUB7m90 for ; Wed, 14 Nov 2012 14:54:00 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 258DA21F8871 for ; Wed, 14 Nov 2012 14:53:59 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so915843lbk.31 for ; Wed, 14 Nov 2012 14:53:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=bmfJuq8F0jEhpjQoU3ZnxB+6Uh5N6lPboX6cF9Cf9w8=; b=O6oDpk5uXIyxkk/+q6mjijXV05ZaR5PN4PsfNx/vrPvt9VvfvnC/t2lgEYteZsPZnA Vfk6vkfNTJhF/K0Cjv5CYb8ZC8Kv0mT5nwX7MeFCnH/xUam6OBvG8AKQr2WGERaPufQh Xo0tc5DaL2ZkgNHkO5uokiNJw6HctMiD/rN4anXj/D3EDnX6Iv4LoHLhMN+DnEKnLxiu CQ0Rwtv76a09i23qIriH9hKa4n5x3qgLyPT9r0Nk6k4MxyqQD6rZLRkXsqbto/9tTGwR nrbrZwr07SsHGRKLYZ6ZTokClqawFEtfqox7VbiSIThLqxwwZwrz5Q+zTJhsIlKuMfxj bBCA== Received: by 10.112.28.98 with SMTP id a2mr11206697lbh.110.1352933639037; Wed, 14 Nov 2012 14:53:59 -0800 (PST) Received: from [10.0.0.244] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by mx.google.com with ESMTPS id fp7sm5542229lab.4.2012.11.14.14.53.57 (version=SSLv3 cipher=OTHER); Wed, 14 Nov 2012 14:53:57 -0800 (PST) Message-ID: <50A42104.4040509@mnt.se> Date: Wed, 14 Nov 2012 23:53:56 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: dane@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmIlK0nkdqC+dPLTQJQZSOdYRwfGnl2c909BW1FhYv9+0LSul4dtcH2RoBGWllnukwNgC81 Subject: Re: [dane] [therightkey] DANE and CT X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 22:54:01 -0000 > Does that make sense though? With RRSIG validity times and TTL's you > can set your "damange period" as small as you want. There is no issue > like with certificates where your credentials can be abused for up to > 12 months. You still need to detect the attack, right? DANE may help you mitigate the attack but it won't help you detect it. Cheers Leif From fneves@registro.br Wed Nov 14 15:28:41 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A9921F85B3 for ; Wed, 14 Nov 2012 15:28:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfG5tmWIRZE3 for ; Wed, 14 Nov 2012 15:28: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 79A0B21F854F for ; Wed, 14 Nov 2012 15:28:40 -0800 (PST) Received: by clone.registro.br (Postfix, from userid 1000) id E997BE046F; Wed, 14 Nov 2012 21:28:38 -0200 (BRST) Date: Wed, 14 Nov 2012 21:28:38 -0200 From: Frederico A C Neves To: Leif Johansson Message-ID: <20121114232838.GH50173@registro.br> References: <50A42104.4040509@mnt.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50A42104.4040509@mnt.se> Cc: dane@ietf.org Subject: Re: [dane] [therightkey] DANE and CT X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 23:28:41 -0000 On Wed, Nov 14, 2012 at 11:53:56PM +0100, Leif Johansson wrote: > > > Does that make sense though? With RRSIG validity times and TTL's you > > can set your "damange period" as small as you want. There is no issue > > like with certificates where your credentials can be abused for up to > > 12 months. > You still need to detect the attack, right? DANE may help you mitigate > the attack but it won't help you detect it. Respected the DNSSEC "grand scheme of things" a relying party will definitely detect it, perhaps not the owner of the zone. Is that what you meant? Fred From leifj@mnt.se Wed Nov 14 23:54:29 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3458421F86E4 for ; Wed, 14 Nov 2012 23:54:29 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-z8orsNC91Z for ; Wed, 14 Nov 2012 23:54:28 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB0321F86DD for ; Wed, 14 Nov 2012 23:54:28 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so1161549lbk.31 for ; Wed, 14 Nov 2012 23:54:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=HjsOMnTEucMYEyrG9SUtFcL58y/jkijfo+9ngOKFCRM=; b=lNB5heh3e3MaAqC/v8NkMS44BV4+hUKnIrM9pwdlcjVHyr7a+It9hR+xePtlYpvs9F fkoj1/8UMdOPb6M98nElkyw5EJ6XZkzJc8tYeVF66Lcw5+s8p6jzU5uylhnQ5qLfe+sw UkN+XKBI+WFBmFkLXgHbtK5KFSvGT4YyNhmA/pi+K891Gl/0bMy+UsFn0GEbrFK9XwJQ 22GxFOQZCX3H3F4+HjEpQgz9yk3ETMICNeFJ3QGE87NpkW5D4t1Mi6hCu2vi4XmUtFbv YifxbaSFoO63vs8ehwth+XM+y1kpfRBNK7INerDS2/ROcc6SqnnO9+DC3oDH/vFfNK9f NGJQ== Received: by 10.112.100.164 with SMTP id ez4mr236233lbb.106.1352966067109; Wed, 14 Nov 2012 23:54:27 -0800 (PST) Received: from [109.105.104.229] ([109.105.104.229]) by mx.google.com with ESMTPS id x5sm5880590lbf.9.2012.11.14.23.54.22 (version=SSLv3 cipher=OTHER); Wed, 14 Nov 2012 23:54:26 -0800 (PST) Message-ID: <50A49FAC.1060400@mnt.se> Date: Thu, 15 Nov 2012 08:54:20 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Frederico A C Neves References: <50A42104.4040509@mnt.se> <20121114232838.GH50173@registro.br> In-Reply-To: <20121114232838.GH50173@registro.br> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmRBZi+HGWvIQwYFNO3PCGCO3y/ZaPrzyFRr+T+ZdQoejDC4NOOK8GfEXOQol8CkKZ1J8Hy Cc: dane@ietf.org Subject: Re: [dane] [therightkey] DANE and CT X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 07:54:29 -0000 On 11/15/2012 12:28 AM, Frederico A C Neves wrote: > On Wed, Nov 14, 2012 at 11:53:56PM +0100, Leif Johansson wrote: >>> Does that make sense though? With RRSIG validity times and TTL's you >>> can set your "damange period" as small as you want. There is no issue >>> like with certificates where your credentials can be abused for up to >>> 12 months. >> You still need to detect the attack, right? DANE may help you mitigate >> the attack but it won't help you detect it. > Respected the DNSSEC "grand scheme of things" a relying party will > definitely detect it, perhaps not the owner of the zone. Is that what > you meant? > > Fred yep From hallam@gmail.com Thu Nov 15 05:02:07 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8B821F88E0; Thu, 15 Nov 2012 05:02:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.237 X-Spam-Level: X-Spam-Status: No, score=-4.237 tagged_above=-999 required=5 tests=[AWL=-0.639, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFtW-injI08v; Thu, 15 Nov 2012 05:02:06 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 33E7721F88D4; Thu, 15 Nov 2012 05:02:06 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so1676685oag.31 for ; Thu, 15 Nov 2012 05:02:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=f2HC2wPzdPE8COkfgKDDQS9YFTBNN8ou70CmYFGivFk=; b=q6HbvIdWM6owz6bUflnaK1uLDQ2amg+e+xPIH2awssG8rFQ0d/UppcoYTLKGFpDoHh +BCYpS73a/+wLL0NNv4QDrMvNP2YQf+uf+LWyJsYGVoYRXzs7DPTZWSkyPwxyLcjPsJt yjtjZm+5nue8BQS+4pX8eNha49WylTOqrrgmynQcVIUkfrtS6vR5GnZLpvsEWgmO6WAg 1dLZpwJOUS70l10hr9XNHkNKAuZ1MTscYqSc2OddEnQqACPtFVAYFkrgwSpjsvbcol67 +UtJOKaUiASTjwm0GPDcTbRWgTcESKa9vs1lEfyS+PSpoe1B9LbReeVLgth4Uo/Y8nLR MMaw== MIME-Version: 1.0 Received: by 10.60.26.38 with SMTP id i6mr769234oeg.23.1352984525441; Thu, 15 Nov 2012 05:02:05 -0800 (PST) Received: by 10.76.27.103 with HTTP; Thu, 15 Nov 2012 05:02:04 -0800 (PST) In-Reply-To: References: Date: Thu, 15 Nov 2012 08:02:04 -0500 Message-ID: From: Phillip Hallam-Baker To: Tony Finch Content-Type: multipart/alternative; boundary=e89a8fb2007c068a1004ce884299 Cc: therightkey@ietf.org, IETF DANE WG list Subject: Re: [dane] DANE and CT X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 13:02:07 -0000 --e89a8fb2007c068a1004ce884299 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 14, 2012 at 11:02 AM, Tony Finch wrote: > Ben Laurie wrote: > > > At the CT BoF the question was raised: what about DANE? > > > > Which is a good question. So, I think Google is prepared to > > contemplate running a CT log for DANE, but this leaves some > > questions... > > What problem would CT for DANE be aiming to fix? > I see a number of issues that need fixing: 1) Domain hijacking DANE certificates are only as secure as the DNS names they are attached to. DNS hijacking occurs at a rate well in excess of 10,000 names a year and is probably much much higher if we could get better numbers. At present the DNS name owner (and it is the owner, regardless of what idiot lawyers claim) has to rely on their registrar to be competent and on the processes at the registry and to a certain extent on the honesty of other registrars. This whole area is essentially opaque, there is no documentation for most of the processes on which businesses are forced to rely. 2) Root jacking Russia and China are just not going to be recognizing the ICANN roots dudes. They have been telling everyone who will listen that they are going to fork the root and they have a big enough fraction of the population of the planet to make it stick. So people can do the ostrich head in the sand thing or they can anticipate this attack and think about ways to neutralize it. 3) Demonstrate continuity In the case that a DNS name changes hands I do not necessarily want to be sending the new information the confidential data I would have sent the old one. Lacking the ability to establish an external validation of the source, this means I am much more interested in determining the lineage of credentials. Or it could just be that the DANE people have created an absolutely perfect system that is beyond any possible reproach and the fact that nobody seems to be implementing it beyond limited scale trials and plugins is due to the inability of everyone else to fully appreciate their awesomeness. -- Website: http://hallambaker.com/ --e89a8fb2007c068a1004ce884299 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Nov 14, 2012 at 11:02 AM, Tony F= inch <dot@dotat.at> wrote:
Ben Laurie <benl@go= ogle.com> wrote:

> At the CT BoF the question was raised: what about DANE?
>
> Which is a good question. So, I think Google is prepared to
> contemplate running a CT log for DANE, but this leaves some
> questions...

What problem would CT for DANE be aiming to fix?

I see a number of issues that need fixing:

1) Domain hijacking

DANE certificates are= only as secure as the DNS names they are attached to. DNS hijacking occurs= at a rate well in excess of 10,000 names a year and is probably much much = higher if we could get better numbers.

At present the DNS name owner (and it is the owner, reg= ardless of what idiot lawyers claim) has to rely on their registrar to be c= ompetent and on the processes at the registry and to a certain extent on th= e honesty of other registrars. This whole area is essentially opaque, there= is no documentation for most of the processes on which businesses are forc= ed to rely.


2) Root jacking

Russia and China are just not going to be recognizing the ICANN roots dude= s. They have been telling everyone who will listen that they are going to f= ork the root and they have a big enough fraction of the population of the p= lanet to make it stick.

So people can do the ostrich head in the sand thing or = they can anticipate this attack and think about ways to neutralize it.


3) Demonstrate continuity

In the case that a DNS name changes hands I do not necessari= ly want to be sending the new information the confidential data I would hav= e sent the old one. Lacking the ability to establish an external validation= of the source, this means I am much more interested in determining the lin= eage of credentials.


Or it could just be that the DANE people= have created an absolutely perfect system that is beyond any possible repr= oach and the fact that nobody seems to be implementing it beyond limited sc= ale trials and plugins is due to the inability of everyone else to fully ap= preciate their awesomeness.
=A0

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

--e89a8fb2007c068a1004ce884299-- From paul.hoffman@vpnc.org Thu Nov 15 07:46:44 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 842FA21F857C; Thu, 15 Nov 2012 07:46:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Op16P9xGt52T; Thu, 15 Nov 2012 07:46:44 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id E25E721F8573; Thu, 15 Nov 2012 07:46:43 -0800 (PST) Received: from [10.20.30.102] (50-0-66-243.dsl.dynamic.fusionbroadband.com [50.0.66.243]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id qAFFke8E064981 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 15 Nov 2012 08:46:41 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: <20121114181437.GA26508@isc.upenn.edu> Date: Thu, 15 Nov 2012 07:46:47 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <212E2C13-CE98-43BB-B665-14DD18236F03@kumari.net> <20121114172950.GA13499@isc.upenn.edu> <20121114181437.GA26508@isc.upenn.edu> To: Shumon Huque X-Mailer: Apple Mail (2.1499) Cc: therightkey@ietf.org, IETF DANE WG list Subject: Re: [dane] [therightkey] DANE and CT X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 15:46:44 -0000 On Nov 14, 2012, at 10:14 AM, Shumon Huque wrote: > For the DANE/DNSSEC case, I'm detecting an attack on the DNSSEC=20 > authentication chain, not the existence of a fraudulently issued=20 > certificate on some attacker's server. >=20 > If the DNSSEC chain is intact, then presumably DANE aware clients=20 > will properly authenticate the TLSA record before accepting the server=20= > certificate. I admit that's a mighty presumption today, but we'll see = ... This is an excellent summary of the scenario. However, that's not exactly what Ben is asking about. CT-for-PKIX is = about "did a trusted CA issue a certificate it should not have". = CT-for-DNSSEC is about "did a server in the hierarchy above the leaf = include a DS it should not have". In the latter case, those rogue DS = records might not be detectable to the party with the leaf record. For example, assume the domain name example.newtld. The owner of example = has put DS record A in the newtld zone. If the owner of newtld goes = rogue and shows DS record B to a limited number of requests (such as to = a particular geographic region or set of network addresses), the party = with the private key associated with B can spoof example, and the owner = of example would not know unless he could see B. --Paul Hoffman= From shuque@upenn.edu Thu Nov 15 10:43:25 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A743521F8552; Thu, 15 Nov 2012 10:43:25 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ma1zTvxpOHyY; Thu, 15 Nov 2012 10:43:25 -0800 (PST) Received: from mopeypopo.net.isc.upenn.edu (www.huque.com [IPv6:2607:f470:2:1::a:2]) by ietfa.amsl.com (Postfix) with ESMTP id 149F921F8563; Thu, 15 Nov 2012 10:43:25 -0800 (PST) Received: by mopeypopo.net.isc.upenn.edu (Postfix, from userid 500) id 3C2C7A5003; Thu, 15 Nov 2012 13:43:24 -0500 (EST) Date: Thu, 15 Nov 2012 13:43:24 -0500 From: Shumon Huque To: Paul Hoffman Message-ID: <20121115184324.GA21572@isc.upenn.edu> References: <212E2C13-CE98-43BB-B665-14DD18236F03@kumari.net> <20121114172950.GA13499@isc.upenn.edu> <20121114181437.GA26508@isc.upenn.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: University of Pennsylvania User-Agent: Mutt/1.5.21 (2010-09-15) Cc: therightkey@ietf.org, IETF DANE WG list Subject: Re: [dane] [therightkey] DANE and CT X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 18:43:25 -0000 On Thu, Nov 15, 2012 at 07:46:47AM -0800, Paul Hoffman wrote: > On Nov 14, 2012, at 10:14 AM, Shumon Huque wrote: > > > For the DANE/DNSSEC case, I'm detecting an attack on the DNSSEC > > authentication chain, not the existence of a fraudulently issued > > certificate on some attacker's server. > > > > If the DNSSEC chain is intact, then presumably DANE aware clients > > will properly authenticate the TLSA record before accepting the server > > certificate. I admit that's a mighty presumption today, but we'll see ... > > This is an excellent summary of the scenario. > > However, that's not exactly what Ben is asking about. CT-for-PKIX is about "did a trusted CA issue a certificate it should not have". CT-for-DNSSEC is about "did a server in the hierarchy above the leaf include a DS it should not have". In the latter case, those rogue DS records might not be detectable to the party with the leaf record. > > For example, assume the domain name example.newtld. The owner of example has put DS record A in the newtld zone. If the owner of newtld goes rogue and shows DS record B to a limited number of requests (such as to a particular geographic region or set of network addresses), the party with the private key associated with B can spoof example, and the owner of example would not know unless he could see B. > > --Paul Hoffman Good point. An auditable log of DS/SEP key chains would seem to be useful for this. -- Shumon Huque University of Pennsylvania. From paul@nohats.ca Thu Nov 15 12:11:41 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADE0821F850B; Thu, 15 Nov 2012 12:11:41 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k29YbIooC63y; Thu, 15 Nov 2012 12:11:41 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 3167721F8530; Thu, 15 Nov 2012 12:11:40 -0800 (PST) Received: by bofh.nohats.ca (Postfix, from userid 500) id E363A82B75; Thu, 15 Nov 2012 15:10:51 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id A6BC182B5B; Thu, 15 Nov 2012 15:10:51 -0500 (EST) Date: Thu, 15 Nov 2012 15:10:51 -0500 (EST) From: Paul Wouters To: Ben Laurie In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: therightkey@ietf.org, IETF DANE WG list Subject: Re: [dane] [therightkey] DANE and CT X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 20:11:41 -0000 On Wed, 14 Nov 2012, Ben Laurie wrote: >> I think CT is a bandaid for PKIX that does not apply to DANE. >> >> I think the problem with DANE/DNSSEC right now is the additional latency >> and dns transport issues (hotspots, VPN, etc) but I don't think CT is >> very well suited to address those. > > a) Why would an attacker use your validity times? Because there are DNSSEC keys to back the time slots used, and without it, the data can and should be rejected. > b) Weren't you amongst those asking for CT to support DANE during the BoF? I wanted CT to not exclude DANE, and thereby enforcing an artificial TLS certificate market where I have to pay $10-$150 a year to be "accepted" in browsers via CT. What I understood was that browser vendors that were looking at CT and DANE would specifically not be supoprted. The first thought was to have a DANE backed CT that could be configured, purely to get the DANE information (valid key + TTL/RRSIG info) into the browsers that don't support or want to support DNSSEC (chains). But the DANE/DNSSEC information does not need an publicly shared audit log. Its current up to date validity is available in the DNS at all times, cached and distributed. Paul From paul@nohats.ca Thu Nov 15 12:33:34 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F64421F892D; Thu, 15 Nov 2012 12:33:34 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCOHsaZzcdYe; Thu, 15 Nov 2012 12:33:34 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id DD5CA21F892B; Thu, 15 Nov 2012 12:33:33 -0800 (PST) Received: by bofh.nohats.ca (Postfix, from userid 500) id 85A3782B75; Thu, 15 Nov 2012 15:32:47 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6F22982B5B; Thu, 15 Nov 2012 15:32:47 -0500 (EST) Date: Thu, 15 Nov 2012 15:32:47 -0500 (EST) From: Paul Wouters To: Paul Hoffman In-Reply-To: Message-ID: References: <212E2C13-CE98-43BB-B665-14DD18236F03@kumari.net> <20121114172950.GA13499@isc.upenn.edu> <20121114181437.GA26508@isc.upenn.edu> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: therightkey@ietf.org, IETF DANE WG list Subject: Re: [dane] [therightkey] DANE and CT X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 20:33:34 -0000 On Thu, 15 Nov 2012, Paul Hoffman wrote: > On Nov 14, 2012, at 10:14 AM, Shumon Huque wrote: > >> For the DANE/DNSSEC case, I'm detecting an attack on the DNSSEC >> authentication chain, not the existence of a fraudulently issued >> certificate on some attacker's server. >> >> If the DNSSEC chain is intact, then presumably DANE aware clients >> will properly authenticate the TLSA record before accepting the server >> certificate. I admit that's a mighty presumption today, but we'll see ... > > This is an excellent summary of the scenario. > > However, that's not exactly what Ben is asking about. CT-for-PKIX is about "did a trusted CA issue a certificate it should not have". CT-for-DNSSEC is about "did a server in the hierarchy above the leaf include a DS it should not have". In the latter case, those rogue DS records might not be detectable to the party with the leaf record. > > For example, assume the domain name example.newtld. The owner of example has put DS record A in the newtld zone. If the owner of newtld goes rogue and shows DS record B to a limited number of requests (such as to a particular geographic region or set of network addresses), the party with the private key associated with B can spoof example, and the owner of example would not know unless he could see B. Interesting. I had not considered this because a big difference is that such rogue DNS records would not be contained/targetted. The forged DS created by the parent would quickly expose the parent, and I doubt the parents would want that reputation damage. Unless they are totalitarian governments, but unlike phb, I give up any kind of using the internet against advisaries that are physically in the path - it just ends up with you refusing to be lied to and not connecting, or going along with their lies and getting eavesdropped. But I'm not sure how CT would see the difference between me logging in to my registrar interface and updating the DS record, someone else using my credentials to do the same without my knowledge, or the registry going rogue. The way PKIX-CT does this is via some financial transaction pretending to convey trust and authority and a credit card audit trail. It fails for the common user precisely because it costs money, and today's criminals have more money to invest compared to the average internet user. I also don't see how TACK addresses this either, with their complicated pinning schemes that are just many different ways of shooting yourself in the foot, without adding anything to the DANE pinning method (apart from relying on verisign to not forfeit their root zone contract to sign custom data for anyone) So I think CT could be used as DNSSEC/DANE history audit log, but IMHO the main asset of something like CT based DANE is purely as a better transport layer for DNSSEC - not as a replacement for DANE/DNSSEC. DNSSEC points to the publisher, who is defined as always right (even if they are wrong because they are sloppy or have a gun pointed at their heads) Paul From danny@tcb.net Thu Nov 15 14:57:48 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA5921F8A05 for ; Thu, 15 Nov 2012 14:57:48 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aobU5-nZR360 for ; Thu, 15 Nov 2012 14:57:48 -0800 (PST) Received: from mail.friendswithtools.org (unknown [IPv6:2600:3000:150f:701:5054:ff:fed1:24a9]) by ietfa.amsl.com (Postfix) with ESMTP id DCA5F21F89FF for ; Thu, 15 Nov 2012 14:57:47 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 734212165 for ; Thu, 15 Nov 2012 22:57:47 +0000 (UTC) Received: from [10.196.208.46] (unknown [209.133.29.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id B34E51A30; Thu, 15 Nov 2012 15:57:46 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Danny McPherson In-Reply-To: Date: Thu, 15 Nov 2012 17:57:45 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3CF77CCB-5549-4888-8024-7842BB5FFE17@tcb.net> References: To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Innocent X-DSPAM-Processed: Thu Nov 15 15:57:47 2012 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 50a5736b199631947814425 X-DSPAM-Factors: 27, 15+#+#+8, 0.40000, the+DNS, 0.40000, they+#+#+to, 0.40000, this+Thanks, 0.40000, secure+#+#+#+names, 0.40000, they+#+attached, 0.40000, 000+names, 0.40000, excess+of, 0.40000, could+get, 0.40000, Baker+#+DANE, 0.40000, to+DNS, 0.40000, names+they, 0.40000, much+#+if, 0.40000, probably+#+#+#+if, 0.40000, and+#+probably, 0.40000, 8+#+#+Phillip, 0.40000, excess+#+10, 0.40000, have+#+#+qualifying, 0.40000, much+#+#+#+could, 0.40000, much+#+#+we, 0.40000, in+excess, 0.40000, certificates+#+only, 0.40000, Hallam+#+wrote, 0.40000, attached+to, 0.40000, as+secure, 0.40000, 000+#+a, 0.40000, To*Phillip+#+hallam, 0.40000 Cc: therightkey@ietf.org, IETF DANE WG list Subject: Re: [dane] DANE and CT X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 22:57:48 -0000 On Nov 15, 2012, at 8:02 AM, Phillip Hallam-Baker wrote: >=20 > DANE certificates are only as secure as the DNS names they are = attached to. DNS hijacking occurs at a rate well in excess of 10,000 = names a year and is probably much much higher if we could get better = numbers. PHB - do you have a citation qualifying this? Thanks,=20 -danny From hallam@gmail.com Thu Nov 15 16:14:22 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B44BC1F0C6E; Thu, 15 Nov 2012 16:14:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.215 X-Spam-Level: X-Spam-Status: No, score=-4.215 tagged_above=-999 required=5 tests=[AWL=-0.617, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHgVPyk8YYKS; Thu, 15 Nov 2012 16:14:22 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id CE4D71F0C44; Thu, 15 Nov 2012 16:14:21 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id ef5so2407659obb.31 for ; Thu, 15 Nov 2012 16:14:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mYoJVbnz/zJbjVxUvhDUtPO8cU18fottomDMknAjJRs=; b=KJg2AIgy/YK5Fy4D5W/g8XTyioAkNAT2/qUtdWakzhdELWqruaxAj/ryrn46tqCzDI MkmaMfMYiYOR5XrE8c6ACP9ZPjdjub6ZYq5pW/9+0v5nWPzgS5p99gjNcfmudc+IOc9w 7jLX2HL7kIY5YNhASYfiwxzwdS4Rf9I8/FGA1y7Wk1tey/LP5ox18ijb3RU/dLibhjes CMGSy6ucX8j7u5Hgbr1RmAQYooY2y3VAT0Cu3cwYHlAHSZS83MtFKDlpxUyrCuffEixw 2VuvoIVQIDUQsjZP4JZqWhJrhkxUEsj12ub9DbeJ+GvBfXoBYz4fTLOMq89DqTxC9Ovf Kcfw== MIME-Version: 1.0 Received: by 10.60.5.232 with SMTP id v8mr2437002oev.26.1353024861305; Thu, 15 Nov 2012 16:14:21 -0800 (PST) Received: by 10.76.27.103 with HTTP; Thu, 15 Nov 2012 16:14:21 -0800 (PST) In-Reply-To: <3CF77CCB-5549-4888-8024-7842BB5FFE17@tcb.net> References: <3CF77CCB-5549-4888-8024-7842BB5FFE17@tcb.net> Date: Thu, 15 Nov 2012 19:14:21 -0500 Message-ID: From: Phillip Hallam-Baker To: Danny McPherson Content-Type: multipart/alternative; boundary=e89a8ff253583af9ed04ce91a61f Cc: therightkey@ietf.org, IETF DANE WG list Subject: Re: [dane] DANE and CT X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 00:14:22 -0000 --e89a8ff253583af9ed04ce91a61f Content-Type: text/plain; charset=ISO-8859-1 On Thu, Nov 15, 2012 at 5:57 PM, Danny McPherson wrote: > > On Nov 15, 2012, at 8:02 AM, Phillip Hallam-Baker wrote: > > > > > DANE certificates are only as secure as the DNS names they are attached > to. DNS hijacking occurs at a rate well in excess of 10,000 names a year > and is probably much much higher if we could get better numbers. > > PHB - do you have a citation qualifying this? > Not one I can share. But it seemed at the lower bound to me given the number of sites I use that have been hijacked recently. You folk should have much more accurate figures. Care to share? -- Website: http://hallambaker.com/ --e89a8ff253583af9ed04ce91a61f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Nov 15, 2012 at 5:57 PM, Danny M= cPherson <danny@tcb.net> wrote:

On Nov 15, 2012, at 8:02 AM, Phillip Hallam-Baker wrote:

>
> DANE certificates are only as secure as the DNS names they are attache= d to. DNS hijacking occurs at a rate well in excess of 10,000 names a year = and is probably much much higher if we could get better numbers.

PHB - do you have a citation qualifying this?
Not one I can share. But it seemed at the lower bound to me gi= ven the number of sites I use that have been hijacked recently.

You folk should have much more accurate figures. Care to sha= re?=A0



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

--e89a8ff253583af9ed04ce91a61f-- From ogud@ogud.com Thu Nov 15 16:33:28 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEB8D1F0C44 for ; Thu, 15 Nov 2012 16:33:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.716 X-Spam-Level: X-Spam-Status: No, score=-103.716 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ho-rLNl4a8B6 for ; Thu, 15 Nov 2012 16:33:28 -0800 (PST) Received: from smtp134.iad.emailsrvr.com (smtp134.iad.emailsrvr.com [207.97.245.134]) by ietfa.amsl.com (Postfix) with ESMTP id 40E181F041A for ; Thu, 15 Nov 2012 16:33:28 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp53.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 97802583EA; Thu, 15 Nov 2012 19:33:27 -0500 (EST) X-Virus-Scanned: OK Received: by smtp53.relay.iad1a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 257AA58348; Thu, 15 Nov 2012 19:33:26 -0500 (EST) Message-ID: <50A589D1.4090604@ogud.com> Date: Thu, 15 Nov 2012 19:33:21 -0500 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: dane@ietf.org References: <3CF77CCB-5549-4888-8024-7842BB5FFE17@tcb.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dane] DANE and CT X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 00:33:28 -0000 On 15/11/2012 19:14, Phillip Hallam-Baker wrote: > > > On Thu, Nov 15, 2012 at 5:57 PM, Danny McPherson > wrote: > > > On Nov 15, 2012, at 8:02 AM, Phillip Hallam-Baker wrote: > > > > > DANE certificates are only as secure as the DNS names they are > attached to. DNS hijacking occurs at a rate well in excess of 10,000 > names a year and is probably much much higher if we could get better > numbers. > > PHB - do you have a citation qualifying this? > > > Not one I can share. But it seemed at the lower bound to me given the > number of sites I use that have been hijacked recently. > > You folk should have much more accurate figures. Care to share? > > Can you give us any indication if this is problem across major TLD's or limited to a few. thanks Olafur From danny@tcb.net Thu Nov 15 16:37:23 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 581621F0C67 for ; Thu, 15 Nov 2012 16:37:23 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65icvKusoErA for ; Thu, 15 Nov 2012 16:37:23 -0800 (PST) Received: from mail.friendswithtools.org (unknown [IPv6:2600:3000:150f:701:5054:ff:fed1:24a9]) by ietfa.amsl.com (Postfix) with ESMTP id D9A2A1F041A for ; Thu, 15 Nov 2012 16:37:22 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 21AD92146 for ; Fri, 16 Nov 2012 00:37:22 +0000 (UTC) Received: from [10.196.208.46] (unknown [209.133.29.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 89E792109; Thu, 15 Nov 2012 17:37:21 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Danny McPherson In-Reply-To: Date: Thu, 15 Nov 2012 19:37:20 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7C668D44-1041-43D2-9C97-F8611C966F4D@tcb.net> References: <3CF77CCB-5549-4888-8024-7842BB5FFE17@tcb.net> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Innocent X-DSPAM-Processed: Thu Nov 15 17:37:22 2012 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 50a58ac2199631836021311 X-DSPAM-Factors: 27, Nope+#+just, 0.40000, hence+#+query, 0.40000, Hallam+#+#+#+folk, 0.40000, registry+operator, 0.40000, most+of, 0.40000, of+#+issues, 0.40000, Subject*therightkey+#+#+and, 0.40000, figures+Care, 0.40000, at+#+14, 0.40000, have+#+#+accurate, 0.40000, Nope+we're, 0.40000, much+more, 0.40000, to+share, 0.40000, Hallam+#+wrote, 0.40000, To*Phillip+#+hallam, 0.40000, Mime-Version*Message+#+v1283, 0.40000, Cc*dane+ietf.org, 0.40000, with+#+registrars, 0.40000, Subject*therightkey+#+#+#+CT, 0.40000, Cc*therightkey+ietf.org, 0.40000, Cc*WG+#+dane, 0.40000, share+#+#+just, 0.40000, the+#+hence, 0.40000, 7+14, 0.40000, issues+#+#+#+the, 0.40000, the+#+#+most, 0.40000, Phillip+#+#+wrote, 0.40000 Cc: therightkey@ietf.org, IETF DANE WG list Subject: Re: [dane] [therightkey] DANE and CT X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 00:37:23 -0000 On Nov 15, 2012, at 7:14 PM, Phillip Hallam-Baker wrote: >=20 > You folk should have much more accurate figures. Care to share?=20 Nope, we're just the registry operator, most of these issues are = resolved with the registrars, hence my query. Thanks,=20 -danny From hallam@gmail.com Thu Nov 15 20:34:16 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6C6F21E804C for ; Thu, 15 Nov 2012 20:34:16 -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=[AWL=-0.597, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKU2nbPr2Hiq for ; Thu, 15 Nov 2012 20:34:16 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D4BAE1F0C67 for ; Thu, 15 Nov 2012 20:34:15 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id ef5so2561179obb.31 for ; Thu, 15 Nov 2012 20:34:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+wlSrznmsALTtZOmM/MeeTKFcmto6Oq+QAmCz6TvbWA=; b=a5EtQ+nIXR+XS7tZ/3ebSK99ZyXH8t45vnEVLbmGhcZ/+lOBTHGIb/u0FPfPJWolrf Rl/pG1CUy0/1fqxdE2ZqGfzDMyKENCKYTRUAr0H7dzRFLWRsxgrc+JIB3ZjavZZ/NeCv 0PXeNhagpgzk49NXYW17AHPNSgMQQzuih+S1kuGzqLw2CKiYE3y7XnVk7fl8VCYq2NDV q2MWqLUz0i8P9WVG6OUcN1ENJMhCbnoMYIatzhYOdNocUY5ZMTONlIPWZ7DWthi9Fn9o WohxYNSCfA0O0/2zBedjONNTluOFZVVmupo6IVPCLuyVU1u/WsVXkpMdlPDSJZ/Kugyn VEKw== MIME-Version: 1.0 Received: by 10.60.5.232 with SMTP id v8mr2826679oev.26.1353040455400; Thu, 15 Nov 2012 20:34:15 -0800 (PST) Received: by 10.76.27.103 with HTTP; Thu, 15 Nov 2012 20:34:15 -0800 (PST) In-Reply-To: <50A589D1.4090604@ogud.com> References: <3CF77CCB-5549-4888-8024-7842BB5FFE17@tcb.net> <50A589D1.4090604@ogud.com> Date: Thu, 15 Nov 2012 23:34:15 -0500 Message-ID: From: Phillip Hallam-Baker To: Olafur Gudmundsson Content-Type: multipart/alternative; boundary=e89a8ff25358b5fdcd04ce954760 Cc: dane@ietf.org Subject: Re: [dane] DANE and CT X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 04:34:16 -0000 --e89a8ff25358b5fdcd04ce954760 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Nov 15, 2012 at 7:33 PM, Olafur Gudmundsson wrote: > On 15/11/2012 19:14, Phillip Hallam-Baker wrote: > >> >> >> On Thu, Nov 15, 2012 at 5:57 PM, Danny McPherson > > wrote: >> >> >> On Nov 15, 2012, at 8:02 AM, Phillip Hallam-Baker wrote: >> >> > >> > DANE certificates are only as secure as the DNS names they are >> attached to. DNS hijacking occurs at a rate well in excess of 10,000 >> names a year and is probably much much higher if we could get better >> numbers. >> >> PHB - do you have a citation qualifying this? >> >> >> Not one I can share. But it seemed at the lower bound to me given the >> number of sites I use that have been hijacked recently. >> >> You folk should have much more accurate figures. Care to share? >> >> >> > Can you give us any indication if this is problem across major TLD's or > limited to a few. > > thanks > Olafur Given that all the cases I have seen have been hacks on the registrar, I can't see why it would be limited to one TLD. But very few of the sites I use are outside .com What I am referring to here is what happened to therpf.com recently when their domain name was hijacked by some squatter who then inserted a proxy to the real site but serving their own ads (plus malware no doubt). Wikipedia refers to it as Domain Hijacking rather than DNS, but that is what I meant. -- Website: http://hallambaker.com/ --e89a8ff25358b5fdcd04ce954760 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Nov 15, 2012 at 7:33 PM, Olafur Gudmundsson <<= a href=3D"mailto:ogud@ogud.com" target=3D"_blank">ogud@ogud.com> wrote:
On 15/11/2012 19:14, Phillip Hallam-Baker wrote:


On Thu, Nov 15, 2012 at 5:57 PM, Danny McPherson <danny@tcb.net
<mailto:danny@tcb.net= >> wrote:


=A0 =A0 On Nov 15, 2012, at 8:02 AM, Phillip Hallam-Baker wrote:

=A0 =A0 =A0>
=A0 =A0 =A0> DANE certificates are only as secure as the DNS names they = are
=A0 =A0 attached to. DNS hijacking occurs at a rate well in excess of 10,00= 0
=A0 =A0 names a year and is probably much much higher if we could get bette= r
=A0 =A0 numbers.

=A0 =A0 PHB - do you have a citation qualifying this?


Not one I can share. But it seemed at the lower bound to me given the
number of sites I use that have been hijacked recently.

You folk should have much more accurate figures. Care to share?



Can you give us any indication if this is problem across major TLD's or= limited to a few.
=A0 =A0 =A0 =A0
=A0 =A0 =A0 =A0 thanks
=A0 =A0 =A0 =A0 Olafur

Given that all t= he cases I have seen have been hacks on the registrar, I can't see why = it would be limited to one TLD. But very few of the sites I use are outside= .com


What I am referring to here is what happened t= o therpf.com recently when their domain n= ame was hijacked by some squatter who then inserted a proxy to the real sit= e but serving their own ads (plus malware no doubt). Wikipedia refers to it= as Domain Hijacking rather than DNS, but that is what I meant.
--e89a8ff25358b5fdcd04ce954760-- From benl@google.com Fri Nov 16 03:23:11 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA6A21F84D7 for ; Fri, 16 Nov 2012 03:23:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.91 X-Spam-Level: X-Spam-Status: No, score=-102.91 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogBg88Ew8GSn for ; Fri, 16 Nov 2012 03:23:10 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3684021F84D8 for ; Fri, 16 Nov 2012 03:23:10 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fw7so283727vcb.31 for ; Fri, 16 Nov 2012 03:23:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VyVjZGX1xf/YPBKCKB9aYoe6TiLuAuhNe3q4U+HVmfs=; b=AzeW2FladyRRDvs+VicQo0xXAP+YqLOwejlD4NFuBr8SfcZMrlbz74BuvHdmVMBnsp XgwjupbyJZUwJh52l4u68NK+1O3XqNOChkUAYlThrJzdUIhdqwx5xCShs3wQLgLNZ5PX Ljg7H+jzlaR5FP74b9D9TBBU6W6HRpWcHkH8A8PV2R38/yy3eswmv4cMx5+ZGjKSpL28 OaN5+OSlR8EJXzv5Bg0lCQM03r4+0v86UPkRLBD4TGitmQjLpleOHOUyZGvobFAN1VwR zYVh5EN66ZunB1dV+cp7dn27fRJf4chkjdcfHBkP56h+XImjYoH7uj9bxA7rtw00vlC+ HyiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=VyVjZGX1xf/YPBKCKB9aYoe6TiLuAuhNe3q4U+HVmfs=; b=T/1iLuNxNgz/bplFKDX15seZyHYOytqciAHlrJWBGx5bxrym6qKBcXAyDZF6WFNXuJ sVGa1mmvN/ycvy+cqirw8Xd58mB43gy8dngCCQnGXHevQCPQKq2DTp3Vzfg06ZW01ggm EUM0Pyhh2jCYpTcYvc9lrC2p2K3ng+2blklVVzWFwSNjHwI+W0PnAUh1bRy1ciZa/cw+ PL/aFgkXgx7sw3q2D5aV+S86RSbE1iK3t26433iy9BjDvP2zc6tDbyDqHuPQxnq6d0jx FYmtBgqrIPdkvShn3Nc5/MpT7eSJwSDg2Bt76kBtHIHf/yhUJ5iab08nytDc2qfV1u64 hrtQ== MIME-Version: 1.0 Received: by 10.52.100.5 with SMTP id eu5mr5152075vdb.34.1353064989438; Fri, 16 Nov 2012 03:23:09 -0800 (PST) Received: by 10.220.228.6 with HTTP; Fri, 16 Nov 2012 03:23:09 -0800 (PST) In-Reply-To: References: Date: Fri, 16 Nov 2012 11:23:09 +0000 Message-ID: From: Ben Laurie To: Paul Wouters Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkbgGqMPtYUHHGwM0epZLN8HfzkyNw+0IXPrZQyLsZhBL1aQPhUq8Ug++bBomvFpKlUtGBk/QFOHfnquVA8p9mdQpa4IHkHXmONkJTqoJu0sFIy25x9dsJJF9ulAYVqPrjMRYGhOgeUuMGHGQ4sXsp3FzoDohnvsA2sVViboJk5DDQcg6SWQfMUOp713Uq78wmU8h3g Cc: therightkey@ietf.org, IETF DANE WG list Subject: Re: [dane] [therightkey] DANE and CT X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 11:23:11 -0000 On 15 November 2012 20:10, Paul Wouters wrote: > On Wed, 14 Nov 2012, Ben Laurie wrote: > >>> I think CT is a bandaid for PKIX that does not apply to DANE. >>> >>> I think the problem with DANE/DNSSEC right now is the additional latency >>> and dns transport issues (hotspots, VPN, etc) but I don't think CT is >>> very well suited to address those. >> >> >> a) Why would an attacker use your validity times? > > > Because there are DNSSEC keys to back the time slots used, and > without it, the data can and should be rejected. This argument is circular: clearly if no-one ever gets control of keys for your domain, you don't have a problem. Validity times are irrelevant. If someone does get control, they control validity times, no? >> b) Weren't you amongst those asking for CT to support DANE during the BoF? > > I wanted CT to not exclude DANE, and thereby enforcing an artificial TLS > certificate market where I have to pay $10-$150 a year to be "accepted" > in browsers via CT. What I understood was that browser vendors that > were looking at CT and DANE would specifically not be supoprted. The > first thought was to have a DANE backed CT that could be configured, > purely to get the DANE information (valid key + TTL/RRSIG info) into > the browsers that don't support or want to support DNSSEC (chains). > > But the DANE/DNSSEC information does not need an publicly shared audit > log. Its current up to date validity is available in the DNS at all > times, cached and distributed. You have a lot of faith in a mechanism that is not designed to provide a globally consistent view. How does DNS prevent bad actors from showing local views of the DNS? (Hint: it doesn't). This is precisely what CT does, and is exactly the value it adds to this kind of system. As for CT vs DANE, it is precisely because DNS does not provide a robust infrastructure that DANE cannot be allowed to override CT. This can be fixed by making DANE use some kind of equivalently strong transparency. I agree with others that this is probably better applied to DS records than to TLSA records. > > Paul From benl@google.com Fri Nov 16 03:26:15 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC52C21F84D8 for ; Fri, 16 Nov 2012 03:26:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.913 X-Spam-Level: X-Spam-Status: No, score=-102.913 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QTLcZOiBScA3 for ; Fri, 16 Nov 2012 03:26:15 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id B4CE621F84C5 for ; Fri, 16 Nov 2012 03:26:14 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so2980675vbb.31 for ; Fri, 16 Nov 2012 03:26:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BK/vFT/22OGlLJISTBGsHLRFMB4mvzbhnbxQG8plVbQ=; b=Nvzu+Zng1+Teko5fVV1XyXJJ33MFtcQQLeAsmHNoZ4l6w00ews9Yt/qBSBrZlno6Ge cdoWORujyAVTDt+4vSnoOjDP7Nyddt7YipZCLxj2HgRMojYNFEA7Y9GbJc4Fo87iOeQc 4AAUVRCxoK1MGuFHoaDI++H/4XbLLPaBcAxxc4ujdiNQMkoHzW7JTyS75WRyCLhCpsYQ EQpvtzoJJU7mbsjrHDM2NRts9eKRrkKeTj5ZrIhCwN9P8myGWpGAQMu0QENUzm4+Dj83 MTVm77Kbqy3lSLsgO1FRll0vEQ6dhWbksahNzZGR7jUsMAnqRMwCkooZjiPnzFuThOLn sx/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=BK/vFT/22OGlLJISTBGsHLRFMB4mvzbhnbxQG8plVbQ=; b=PmC+6116ZPII0HH1g4TLC88MC/IPrUo2Q0VuYvdLOyMq2Q9iv9V+hUs6qOkVdloyjP tnfgNBMHDGnKbUERie50vVj3Ue2zoNWjXEd89Tba/TvL+mpgVExhQZFwXalb/GxW1YfV vUNCQF8+f9viYNbEN67QRftddSpPQ65NAdyP/pO9P794ZRB2++soCyTyA9RxUWVqiqaW T+IlTnAUrgHHBBGhgaiSOSygbfBc7AJLo3kez2Z6urAPItqdZoH9x3lh6jWUzDW581RW uci8D3NXFbXUPKOrKEkfxaIxDlaQuRBwugP48nlyy23F/nZXNz85aAmfyylqTaermfjR ksXQ== MIME-Version: 1.0 Received: by 10.52.34.168 with SMTP id a8mr3188417vdj.49.1353065174158; Fri, 16 Nov 2012 03:26:14 -0800 (PST) Received: by 10.220.228.6 with HTTP; Fri, 16 Nov 2012 03:26:14 -0800 (PST) In-Reply-To: References: <212E2C13-CE98-43BB-B665-14DD18236F03@kumari.net> <20121114172950.GA13499@isc.upenn.edu> <20121114181437.GA26508@isc.upenn.edu> Date: Fri, 16 Nov 2012 11:26:14 +0000 Message-ID: From: Ben Laurie To: Paul Wouters Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlJXfMuQ5y8hcCP6zfr+d29nOV8E6Kp3vTVlwIb12vIBi9/5wE/1CmlE/34Got7UHlpvH34uRCCuW78vX+BoXe/MI49kOJhWm1s1P7IlBS3y3eUbnO17GNTawBMJM+X8uTekV9v1Xcebyj3CM5TrL2fziWQmYysY9t119Y2SOqKD270GDdrJd13kfxoLXv2Q4oy+gDq Cc: therightkey@ietf.org, Paul Hoffman , IETF DANE WG list Subject: Re: [dane] [therightkey] DANE and CT X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 11:26:15 -0000 On 15 November 2012 20:32, Paul Wouters wrote: > On Thu, 15 Nov 2012, Paul Hoffman wrote: > >> On Nov 14, 2012, at 10:14 AM, Shumon Huque wrote: >> >>> For the DANE/DNSSEC case, I'm detecting an attack on the DNSSEC >>> authentication chain, not the existence of a fraudulently issued >>> certificate on some attacker's server. >>> >>> If the DNSSEC chain is intact, then presumably DANE aware clients >>> will properly authenticate the TLSA record before accepting the server >>> certificate. I admit that's a mighty presumption today, but we'll see ... >> >> >> This is an excellent summary of the scenario. >> >> However, that's not exactly what Ben is asking about. CT-for-PKIX is about >> "did a trusted CA issue a certificate it should not have". CT-for-DNSSEC is >> about "did a server in the hierarchy above the leaf include a DS it should >> not have". In the latter case, those rogue DS records might not be >> detectable to the party with the leaf record. >> >> For example, assume the domain name example.newtld. The owner of example >> has put DS record A in the newtld zone. If the owner of newtld goes rogue >> and shows DS record B to a limited number of requests (such as to a >> particular geographic region or set of network addresses), the party with >> the private key associated with B can spoof example, and the owner of >> example would not know unless he could see B. > > > Interesting. I had not considered this because a big difference is that > such rogue DNS records would not be contained/targetted. The forged DS > created by the parent would quickly expose the parent, and I doubt the > parents would want that reputation damage. Unless they are totalitarian > governments, but unlike phb, I give up any kind of using the internet > against advisaries that are physically in the path - it just ends up > with you refusing to be lied to and not connecting, or going along with > their lies and getting eavesdropped. > > But I'm not sure how CT would see the difference between me logging > in to my registrar interface and updating the DS record, someone else > using my credentials to do the same without my knowledge, or the registry > going rogue. The way PKIX-CT does this is via some financial transaction > pretending to convey trust and authority and a credit card audit trail. > It fails for the common user precisely because it costs money, and > today's criminals have more money to invest compared to the average > internet user. Incorrect: CT provides a globally verifiable audit trail - the exchange of money is irrelevant. CT does not see the difference between you logging in to your registrar interface and updating the DS record, someone else using your credentials to do the same without your knowledge, or the registry going rogue. What it does it make all of these visible to you. Then it is up to you (or anyone else) to spot the abuse and do something about it. > I also don't see how TACK addresses this either, with their complicated > pinning schemes that are just many different ways of shooting yourself > in the foot, without adding anything to the DANE pinning method (apart > from relying on verisign to not forfeit their root zone contract to sign > custom data for anyone) > > So I think CT could be used as DNSSEC/DANE history audit log, but IMHO > the main asset of something like CT based DANE is purely as a better > transport > layer for DNSSEC - not as a replacement for DANE/DNSSEC. CT does not replace DNSSEC (or PKIX), it does as you say: provides an audit log. > DNSSEC points to the publisher, who is defined as always right (even if > they are wrong because they are sloppy or have a gun pointed at their > heads) > > Paul > From paul@nohats.ca Fri Nov 16 10:50:19 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B74F21F84CC; Fri, 16 Nov 2012 10:50:19 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2m5PaHJRy1JG; Fri, 16 Nov 2012 10:50:18 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 2D08D21F84C6; Fri, 16 Nov 2012 10:50:18 -0800 (PST) Received: by bofh.nohats.ca (Postfix, from userid 500) id F360682B74; Fri, 16 Nov 2012 13:49:26 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D779982B5B; Fri, 16 Nov 2012 13:49:26 -0500 (EST) Date: Fri, 16 Nov 2012 13:49:26 -0500 (EST) From: Paul Wouters To: Ben Laurie In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: therightkey@ietf.org, IETF DANE WG list Subject: Re: [dane] [therightkey] DANE and CT X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 18:50:19 -0000 On Fri, 16 Nov 2012, Ben Laurie wrote: >> Because there are DNSSEC keys to back the time slots used, and >> without it, the data can and should be rejected. > > This argument is circular: clearly if no-one ever gets control of keys > for your domain, you don't have a problem. Validity times are > irrelevant. > > If someone does get control, they control validity times, no? If someone obtains your private keys, there is no need to forge anything or issue any new certificates, they just run a copy of your private key/cert on their MITM box. CT can't help you there either. If attackers get your private DNSSEC keys (which shouldn't even be online, and surely much harder to obtain compared to the TLS private key) you are lost. > You have a lot of faith in a mechanism that is not designed to provide > a globally consistent view. How does DNS prevent bad actors from > showing local views of the DNS? (Hint: it doesn't). The root key protects me against that. And the TLD key. Sure, if I'm using some untrusted national TLD which might be overwriting my parent NS/DS set, again you are in a no-win situation. Best you can do is monitor your own zone, and possible carry your own domain's trust anchors with you. And these same players would simply prevent you from accessing the CT services as well. > This is precisely what CT does, and is exactly the value it adds to > this kind of system. > > As for CT vs DANE, it is precisely because DNS does not provide a > robust infrastructure that DANE cannot be allowed to override CT. So Diginotar will submit a new cert for me to the CT, and we're back at square one? > This > can be fixed by making DANE use some kind of equivalently strong > transparency. I agree with others that this is probably better applied > to DS records than to TLSA records. While I agree that it won't hurt to log and audit DS records to see if verisign or the USG really is signing their own records with the root or .com keys, I still believe those two parts are the most secure players I know to delegate some trust to. The real weak points of DNSSEC will be the dns operators of the zones and the registrar webgui's for making zone changes. In fact, I would probably rather trust the root key, then most CT audit people - and it would come with less false positives due to the middle man delays. Paul From paul@nohats.ca Fri Nov 16 10:54:10 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C404421F8AF0; Fri, 16 Nov 2012 10:54: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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nAmq-JGUEaEC; Fri, 16 Nov 2012 10:54:10 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 38FDD21F8AED; Fri, 16 Nov 2012 10:54:10 -0800 (PST) Received: by bofh.nohats.ca (Postfix, from userid 500) id 03D1782B74; Fri, 16 Nov 2012 13:53:25 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D952982B5B; Fri, 16 Nov 2012 13:53:25 -0500 (EST) Date: Fri, 16 Nov 2012 13:53:25 -0500 (EST) From: Paul Wouters To: Ben Laurie In-Reply-To: Message-ID: References: <212E2C13-CE98-43BB-B665-14DD18236F03@kumari.net> <20121114172950.GA13499@isc.upenn.edu> <20121114181437.GA26508@isc.upenn.edu> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: therightkey@ietf.org, Paul Hoffman , IETF DANE WG list Subject: Re: [dane] [therightkey] DANE and CT X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 18:54:10 -0000 > Incorrect: CT provides a globally verifiable audit trail - the > exchange of money is irrelevant. It is if Google CT only accepts submissions of CAs, and Chrome ships with the Google CT. It forces me to use CAs. > CT does not see the difference between you logging in to your > registrar interface and updating the DS record, someone else using > your credentials to do the same without your knowledge, or the > registry going rogue. What it does it make all of these visible to > you. Then it is up to you (or anyone else) to spot the abuse and do > something about it. Which is the exact problem of outsourcing trust vs trusting no one. People keep insisting they can do both. Adding another "cert patrol" warning box in my browser isn't going to make users more secure. So what happens if I update my TLS key? I need to live with a few hours of users getting told my site is hacked and clicking OK, or do we ignore the first few hours of a site being compromised? Paul From paul.hoffman@vpnc.org Fri Nov 16 11:06:53 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8264821F8688; Fri, 16 Nov 2012 11:06:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6SXDOjtYWoR4; Fri, 16 Nov 2012 11:06: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 06BA121F850E; Fri, 16 Nov 2012 11:06:52 -0800 (PST) Received: from [10.20.30.102] (50-0-66-243.dsl.dynamic.fusionbroadband.com [50.0.66.243]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id qAGJ6ocu014277 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 16 Nov 2012 12:06:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: Date: Fri, 16 Nov 2012 11:06:50 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <70D44D23-477C-44AC-AE5F-7EAB7BFA0207@vpnc.org> References: To: Ben Laurie X-Mailer: Apple Mail (2.1499) Cc: therightkey@ietf.org, IETF DANE WG list Subject: Re: [dane] [therightkey] DANE and CT X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 19:06:53 -0000 On Nov 16, 2012, at 3:23 AM, Ben Laurie wrote: > As for CT vs DANE, it is precisely because DNS does not provide a > robust infrastructure that DANE cannot be allowed to override CT. This > can be fixed by making DANE use some kind of equivalently strong > transparency. I agree with others that this is probably better applied > to DS records than to TLSA records. Proposal: we take this off the DANE list and keep it on therightkey = list, focused on DS instead of DANE. That is, a rogue zone with = additional / substitute DS records might affect more than DANE in the = future. --Paul Hoffman= From hallam@gmail.com Fri Nov 16 14:40:10 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 147E721F845B; Fri, 16 Nov 2012 14:40:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.177 X-Spam-Level: X-Spam-Status: No, score=-4.177 tagged_above=-999 required=5 tests=[AWL=-0.579, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjLHDZkdftYy; Fri, 16 Nov 2012 14:40:09 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3725A21F844A; Fri, 16 Nov 2012 14:40:09 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so3500523oag.31 for ; Fri, 16 Nov 2012 14:40:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iA/az03uAzTI4QvMsdI5V7vVvGge6K2DVf99LDBkw2I=; b=Am7GTgMt9Z4MmtIFilcy7tc34wtMtiQutmHVKBeCgOS7yY/4//AXABThLMxgOUnzLl EEl/hjfD6LCMyGwP1ZEdiI8bjyANpoJn8t2kNJS90Jocz8RUOAI59k+ykHGP7bi4lnSx nPL2taYz7IklQo9A4+8k44/3bmjTUnmTAeSrSBNX4k7E8dfk56Dnk5+FZbliDnZeORaP aWh2YLCTShIZqiTkt90iN85iTjM7qiW4EpnYeE0kRsSDJhn/eObqVnX9g9VhroiIhLYF 0QsZIasQ60XoeGjL4UB7+P/cyuGtMKyI9Dj/CX3iOBNxB8c+2rpXqKNR//hBmnLhDUws JMRQ== MIME-Version: 1.0 Received: by 10.182.95.205 with SMTP id dm13mr5260418obb.9.1353105607522; Fri, 16 Nov 2012 14:40:07 -0800 (PST) Received: by 10.76.27.103 with HTTP; Fri, 16 Nov 2012 14:40:07 -0800 (PST) In-Reply-To: <70D44D23-477C-44AC-AE5F-7EAB7BFA0207@vpnc.org> References: <70D44D23-477C-44AC-AE5F-7EAB7BFA0207@vpnc.org> Date: Fri, 16 Nov 2012 17:40:07 -0500 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=14dae93b63201479e604cea47310 Cc: therightkey@ietf.org, IETF DANE WG list Subject: Re: [dane] [therightkey] DANE and CT X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 22:40:10 -0000 --14dae93b63201479e604cea47310 Content-Type: text/plain; charset=ISO-8859-1 +1 Paul is right here, the big value in CT is probably applying it as a reinforcement against people screwing with the DS records or to ensure that DLV type schemes are not being futzed with. On Fri, Nov 16, 2012 at 2:06 PM, Paul Hoffman wrote: > On Nov 16, 2012, at 3:23 AM, Ben Laurie wrote: > > > As for CT vs DANE, it is precisely because DNS does not provide a > > robust infrastructure that DANE cannot be allowed to override CT. This > > can be fixed by making DANE use some kind of equivalently strong > > transparency. I agree with others that this is probably better applied > > to DS records than to TLSA records. > > Proposal: we take this off the DANE list and keep it on therightkey list, > focused on DS instead of DANE. That is, a rogue zone with additional / > substitute DS records might affect more than DANE in the future. > > --Paul Hoffman > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey > -- Website: http://hallambaker.com/ --14dae93b63201479e604cea47310 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1

Paul is right here, the big value in CT is probably a= pplying it as a reinforcement against people screwing with the DS records o= r to ensure that DLV type schemes are not being futzed with.=A0

On Fri, Nov 16, 2012 at 2:06 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
On Nov 16, 2012, at 3:23 AM, Ben Laurie <benl@google.com> wrote:

> As for CT vs DANE, it is precisely because DNS does not provide a
> robust infrastructure that DANE cannot be allowed to override CT. This=
> can be fixed by making DANE use some kind of equivalently strong
> transparency. I agree with others that this is probably better applied=
> to DS records than to TLSA records.

Proposal: we take this off the DANE list and keep it on therightkey l= ist, focused on DS instead of DANE. That is, a rogue zone with additional /= substitute DS records might affect more than DANE in the future.

--Paul Hoffman
_____________________= __________________________
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey



--
= Website: http://hallambaker.com/
--14dae93b63201479e604cea47310-- From cloos@jhcloos.com Fri Nov 16 17:05:52 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE6421F8AE4; Fri, 16 Nov 2012 17:05:52 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QSGG1dzgyAEQ; Fri, 16 Nov 2012 17:05:52 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by ietfa.amsl.com (Postfix) with ESMTP id 7D35621F8A22; Fri, 16 Nov 2012 17:05:49 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id CD94840107; Sat, 17 Nov 2012 01:05:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1353114346; bh=O7YCXcXAEjGb8LMdpe2tJ4r+WSaDu5TWmTTib0Vu2Nw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=d4uEfrcwqkKwCu+nxxWqVmaoNqB74FwSXJ4APa80NPU13r23fmm0CslOYHCaSjMcf e25VaCpTT+2aK8wulqZSHVeDl/GZzNOZxqULBcCjBh11k9iKol4G64ZpWjoAyFCxsp VI+6EH1VFyI5tVs5qijwXwkJ/5zsn/dz5OqnaaJU= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 25E1460119; Sat, 17 Nov 2012 00:50:47 +0000 (UTC) From: James Cloos To: therightkey@ietf.org In-Reply-To: <70D44D23-477C-44AC-AE5F-7EAB7BFA0207@vpnc.org> (Paul Hoffman's message of "Fri, 16 Nov 2012 11:06:50 -0800") References: <70D44D23-477C-44AC-AE5F-7EAB7BFA0207@vpnc.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.3.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2012 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Fri, 16 Nov 2012 19:50:47 -0500 Message-ID: Lines: 12 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:121117:therightkey@ietf.org::HQJLgewKY+T8MqBS:0000000000000000000000000000000000000000fnUbO X-Hashcash: 1:30:121117:paul.hoffman@vpnc.org::GuplIm+EdG17hjeM:000000000000000000000000000000000000000BmTai X-Hashcash: 1:30:121117:benl@google.com::YXtCvA0g/8x4kdNo:0zKyBB X-Hashcash: 1:30:121117:dane@ietf.org::ifU0jUUHziyVNRv6:000Hnjo2 Cc: Paul Hoffman , dane@ietf.org Subject: Re: [dane] [therightkey] DANE and CT X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 01:05:52 -0000 >>>>> "PH" == Paul Hoffman writes: PH> Proposal: we take this off the DANE list and keep it on therightkey PH> list, focused on DS instead of DANE. +1 TLSA is only one relevant vector for dnssec attacks. Any such discussion should be more general. And tracking DS RRs feels like enough to provide tamper evidence, at least. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From benl@google.com Sat Nov 17 02:52:56 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A00D521F8790 for ; Sat, 17 Nov 2012 02:52:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvRAzzEQIruz for ; Sat, 17 Nov 2012 02:52:56 -0800 (PST) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4E221F86D4 for ; Sat, 17 Nov 2012 02:52:55 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id dr13so1357776wgb.13 for ; Sat, 17 Nov 2012 02:52:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2mzx1nMqYZ/lZoJyg7tSf1BZAqu7cS9y+b2Qqs8YoKk=; b=fhT9NJ5vg7Bnr5CS1Ct/JerDbDDXbP6ZlSIZl3yQQtmKbVRexn4+wnJDtFEhSCYYwO /9dLTgghtNv5XSrSLm47INeOaxc8BJJmgnTW8t1eQH0kE1cjZCPaMbtaqgB3slGgKfYk 7ZAj+wFAp4Hiqx65ziAOOusPlCfo09qgPxACxsbWqyQld4P34MBgQNkCViPgK5TH+9ez JgM4+fS3Wh515LdJVXoMszIGdW6O8Ik4VfM8YwaExkj5Zx8vYvfkUIbkayc80BWrIKG1 FYZlRZNS8XxloQw/tSqRs7+1IsPihDF8kTT2vgoTc5uRtT5ZoK8Qb+XmyysE78hyOjCl +uIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=2mzx1nMqYZ/lZoJyg7tSf1BZAqu7cS9y+b2Qqs8YoKk=; b=kZnDHxGndBCXENfBajaCAXEr2FIaAuRZnGYopzM/79blRFFuVa06ZEwwg/PWhiiaFn aDsTd5dTCoRmSb6u6vqes0/dwRZ+KYodq0g3hvrk/WAEk9kxJFYW1FcLtc7V6MHBmjRb XsvWyZJ7KVTMtI90+z9xI1aY3IPPh9t1wafwvmMxrOmgEMfcY1eFELCH9PpGbvFHegn5 uN4VJKbfujQaC7lajGad/S1mAaJVXv/nauwSEHMdUffZazESFgVnZYbzTtDNEt900SUl lmU9DdYvMANENppPScJSGjzhggPZP6Oj6HtzaRADQ2mD9Yk4ximWE2QOtP8Bfo6/8em7 f2dg== MIME-Version: 1.0 Received: by 10.180.19.71 with SMTP id c7mr1726104wie.2.1353149574612; Sat, 17 Nov 2012 02:52:54 -0800 (PST) Received: by 10.194.51.100 with HTTP; Sat, 17 Nov 2012 02:52:54 -0800 (PST) In-Reply-To: <70D44D23-477C-44AC-AE5F-7EAB7BFA0207@vpnc.org> References: <70D44D23-477C-44AC-AE5F-7EAB7BFA0207@vpnc.org> Date: Sat, 17 Nov 2012 10:52:54 +0000 Message-ID: From: Ben Laurie To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQk40WMFzRj4Im5dstGidVE807DptfvoB/vxYyq42j0R8ol6+MfDCgsjydUUCtGVHss/sAg124yaLcQTrKRG0COw+WsL2+O0vRid8JTWWmUWBKhF9DORzw6zmQgyeb4TgAuP53t3bWdZItqEwMYP6MlgjDb01/7lnMWhsK1XR5qWvzmogmyOt89+CW9bepMKhpBiX86Y Cc: therightkey@ietf.org, IETF DANE WG list Subject: Re: [dane] [therightkey] DANE and CT X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 10:52:56 -0000 On 16 November 2012 19:06, Paul Hoffman wrote: > On Nov 16, 2012, at 3:23 AM, Ben Laurie wrote: > >> As for CT vs DANE, it is precisely because DNS does not provide a >> robust infrastructure that DANE cannot be allowed to override CT. This >> can be fixed by making DANE use some kind of equivalently strong >> transparency. I agree with others that this is probably better applied >> to DS records than to TLSA records. > > Proposal: we take this off the DANE list and keep it on therightkey list, focused on DS instead of DANE. That is, a rogue zone with additional / substitute DS records might affect more than DANE in the future. +1 > > --Paul Hoffman From dan-ietf@danyork.org Mon Nov 19 11:13:16 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE1C21F86D0 for ; Mon, 19 Nov 2012 11:13:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.972 X-Spam-Level: X-Spam-Status: No, score=-2.972 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YSjQxBTZ9+1a for ; Mon, 19 Nov 2012 11:13:15 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8BDBA21F869F for ; Mon, 19 Nov 2012 11:13:13 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fw7so3279518vcb.31 for ; Mon, 19 Nov 2012 11:13:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:content-type:subject:date:message-id:to:mime-version:x-mailer :x-gm-message-state; bh=ORWqBnjXURORmGRr/vCx8V+LLBlGkNEa77unsX92zok=; b=SFh4tW3HQc9ruUadpP/VWdP9nmHQ5ydslbMXjQdDXEuyxoHYmDvCNvbuRsyfBxVGqg eWDjIyIel7Esk235mQYmVqdkCzoK3cGSmfItP4JLdwnUWdQ1oEw9heVeV4zjg9Tx+SNx obfKyVB24vrfhbJfQ5tcHj764svnxDQ13qAYzmg+HMZ8tq3biPq3qNY+nuABO1e/O6FM Kbzf3b8JcrYtc8U7MhmTdY1uIPmscterIWozi8BSkmSpwbMof0ApFdtNDLHnH8JDU15L 02I/J9hTTlbMlAZMQlKJAgVfSA/H/xsF59BsKRtMCzo2w5AixUfXoTg4ifapklA0lQV9 +sOQ== Received: by 10.220.149.142 with SMTP id t14mr20524423vcv.46.1353352392869; Mon, 19 Nov 2012 11:13:12 -0800 (PST) Received: from ?IPv6:2001:470:1f07:309:bcb0:ecb3:d3:1956? ([2001:470:1f07:309:bcb0:ecb3:d3:1956]) by mx.google.com with ESMTPS id r17sm366493vdj.21.2012.11.19.11.13.11 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 19 Nov 2012 11:13:12 -0800 (PST) From: Dan York Content-Type: multipart/alternative; boundary="Apple-Mail=_BF032FAB-CA8A-4E99-9981-C6B8D70673DA" Date: Mon, 19 Nov 2012 14:13:09 -0500 Message-Id: To: dane WG list Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQkyXLK3oygzZiyHkj5cu2LGAKKzlctMPi5gx6TuqfylnPocOPLhv0UmW7e5kTojsrpFfSCh Subject: [dane] DANE tool/project funding possibly available from NLnet Foundation - deadline Dec 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: Mon, 19 Nov 2012 19:13:16 -0000 --Apple-Mail=_BF032FAB-CA8A-4E99-9981-C6B8D70673DA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii FYI, the NLnet Foundation has a "DNS Security Fund" where they fund work = on open source projects related to securing DNS. They are currently = accepting applications for their next funding round until December 1 at = 12:00 Central European Time. Their site is at: http://www.nlnet.nl/dnssec/ and their "Open call for funding" is at: = http://www.nlnet.nl/news/2012/20121201-call-en.html I wrote about this today encouraging people to think about what kind of = DNSSEC-related or DANE-related tools/services could potentially be = funded: = http://www.internetsociety.org/deploy360/blog/2012/11/got-a-dnssec-project= -that-needs-funding-apply-to-nlnet-foundation-before-dec-1/ If you have an idea for a new DANE tool or for adding DANE support to an = existing tool, but don't have the funding to dedicate some time to it, = this might be a way to get some help. Dan --=20 Dan York dyork@lodestar2.com http://www.danyork.me/ skype:danyork Phone: +1-802-735-1624 Twitter - http://twitter.com/danyork --Apple-Mail=_BF032FAB-CA8A-4E99-9981-C6B8D70673DA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii FYI, = the NLnet Foundation has a "DNS Security Fund" where they fund work on = open source projects related to securing DNS.  They are currently = accepting applications for their next funding round until December 1 at = 12:00 Central European Time.  Their site is = at:

=

and their "Open call for funding" is at:  http://www.nl= net.nl/news/2012/20121201-call-en.html

I = wrote about this today encouraging people to think about what kind of = DNSSEC-related or DANE-related tools/services could potentially be = funded:


<= /div>
If you have an idea for a new DANE tool or for adding DANE = support to an existing tool, but don't have the funding to dedicate some = time to it, this might be a way to get some = help.

Dan

dyork@lodestar2.com
http://www.danyork.me/  &nb= sp;skype:danyork
Phone: = +1-802-735-1624
Twitter - http://twitter.com/danyork



= --Apple-Mail=_BF032FAB-CA8A-4E99-9981-C6B8D70673DA-- From leifj@mnt.se Mon Nov 19 11:56:24 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED7F311E8099 for ; Mon, 19 Nov 2012 11:56:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D80ePMiG7Dbz for ; Mon, 19 Nov 2012 11:56:23 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 302D121F8687 for ; Mon, 19 Nov 2012 11:56:22 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so4342153lbk.31 for ; Mon, 19 Nov 2012 11:56:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:x-gm-message-state; bh=HkV3g9F0SqsF0GxdfPZDa+CwnEpnqS6m8d4BiGWC0b0=; b=AHn6VLZAeFxnJHSHBTrwtZQQQYajC6sQTEGiAVrOZ4HhFqL41PyiIZuLMMGNS4QPut uQTzC9Q7xDJPte0pCHG9dUaYb6z267aSeeRepmxSZzQkZBmww3Zju3ozX3iCL9Nm4Nyd 03TQ98tac/kDdfS+4XtDf2luC9h+DtkFHk9vSKrYVi1FCe/GUKOshYsKmmcGuwZDDavb Zl7IuB5Ti54Pst5zdAY7JOh4eZ8JCHVwaXc8TRnnNL5e4fLDY8a0SToceoN3sxaNJJ2J uYysrN7EVuuGGF/8FWakCTSSpZeomR67jeRr4bzBmN0XKGNczGsPtwJBo/rwJZ5Styq0 M9Uw== Received: by 10.112.29.71 with SMTP id i7mr5460029lbh.85.1353354981705; Mon, 19 Nov 2012 11:56:21 -0800 (PST) Received: from [10.0.0.244] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by mx.google.com with ESMTPS id j10sm1560499lbh.17.2012.11.19.11.56.19 (version=SSLv3 cipher=OTHER); Mon, 19 Nov 2012 11:56:20 -0800 (PST) Message-ID: <50AA8EE2.9020903@mnt.se> Date: Mon, 19 Nov 2012 20:56:18 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: dane@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------040802010107090705060209" X-Gm-Message-State: ALoCoQkl9aJfqn10U/8ChOteOgAJQJ50TtBHd/NcRQlCiuctMkhZXJE/KPk12DDRoNB71aUPkA38 Subject: Re: [dane] DANE tool/project funding possibly available from NLnet Foundation - deadline Dec 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: Mon, 19 Nov 2012 19:56:25 -0000 This is a multi-part message in MIME format. --------------040802010107090705060209 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 11/19/2012 08:13 PM, Dan York wrote: > FYI, the NLnet Foundation has a "DNS Security Fund" where they fund > work on open source projects related to securing DNS. They are > currently accepting applications for their next funding round until > December 1 at 12:00 Central European Time. Their site is at: > > http://www.nlnet.nl/dnssec/ > > and their "Open call for funding" is at: > http://www.nlnet.nl/news/2012/20121201-call-en.html > > I wrote about this today encouraging people to think about what kind > of DNSSEC-related or DANE-related tools/services could potentially be > funded: > > http://www.internetsociety.org/deploy360/blog/2012/11/got-a-dnssec-project-that-needs-funding-apply-to-nlnet-foundation-before-dec-1/ > > If you have an idea for a new DANE tool or for adding DANE support to > an existing tool, but don't have the funding to dedicate some time to > it, this might be a way to get some help. > FYI there is an existing project to add DANE support to OpenSSL (funded by .SE) so pick another stack :-) Cheers Leif > Dan > > -- > Dan York dyork@lodestar2.com > http://www.danyork.me/ skype:danyork > Phone: +1-802-735-1624 > Twitter - http://twitter.com/danyork > > > > > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane --------------040802010107090705060209 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 11/19/2012 08:13 PM, Dan York wrote:
FYI, the NLnet Foundation has a "DNS Security Fund" where they fund work on open source projects related to securing DNS.  They are currently accepting applications for their next funding round until December 1 at 12:00 Central European Time.  Their site is at:


and their "Open call for funding" is at:  http://www.nlnet.nl/news/2012/20121201-call-en.html

I wrote about this today encouraging people to think about what kind of DNSSEC-related or DANE-related tools/services could potentially be funded:


If you have an idea for a new DANE tool or for adding DANE support to an existing tool, but don't have the funding to dedicate some time to it, this might be a way to get some help.

FYI there is an existing project to add DANE support to OpenSSL (funded by .SE)
so pick another stack :-)

            Cheers Leif

Dan

-- 
Dan York  dyork@lodestar2.com
http://www.danyork.me/   skype:danyork
Phone: +1-802-735-1624
Twitter - http://twitter.com/danyork





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

--------------040802010107090705060209--