From oej@edvina.net Wed Jul 3 00:51:40 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D62BA21F9A3E; Wed, 3 Jul 2013 00:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRjmlrMOY7TU; Wed, 3 Jul 2013 00:51:38 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 53D6121F9A14; Wed, 3 Jul 2013 00:51:36 -0700 (PDT) Received: from [192.168.40.15] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 80AD093C1AF; Wed, 3 Jul 2013 07:51:34 +0000 (UTC) From: "Olle E. Johansson" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Jul 2013 09:51:34 +0200 Message-Id: To: dane WG list Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Cc: "Cullen Jennings \(fluffy\)" , "dispatch@ietf.org list" Subject: [dane] Random thoughts about SIP and DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 07:51:40 -0000 Hi! I've tried to collect my thought about SIP and DANE on a slide set. It's = the way I brainstorm I guess :-) You can view it here: = http://www.slideshare.net/oej/danebased-tls-verification-in-the-sip-protoc= ol Feedback is always welcome!=20 If this is on the right path, I'll try to write a draft. We do have DNSsec support in Kamailio now, so hopefully I can get the = developer team to work with me to get some code for testing. /Olle= From ibc@aliax.net Wed Jul 3 05:17:30 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 502DC21F9DA8 for ; Wed, 3 Jul 2013 05:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.637 X-Spam-Level: X-Spam-Status: No, score=-2.637 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9yTZawAcEUD for ; Wed, 3 Jul 2013 05:17:26 -0700 (PDT) Received: from mail-qe0-f46.google.com (mail-qe0-f46.google.com [209.85.128.46]) by ietfa.amsl.com (Postfix) with ESMTP id D96ED21F9DA5 for ; Wed, 3 Jul 2013 05:17:25 -0700 (PDT) Received: by mail-qe0-f46.google.com with SMTP id nd7so26959qeb.19 for ; Wed, 03 Jul 2013 05:17:22 -0700 (PDT) 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:content-transfer-encoding:x-gm-message-state; bh=TY6ngKE5pES9RqALu5yQ9McCZbdHRBjzy4iJJ5+OPsg=; b=GdJYWNFmo/ufRnDO9pXl/MzLv9LN0N/h5e5maKtPI+trCf/Rb7vnijD8bD04lLeW9Z mEU160ZEYaaed1k025MeeVNuEPtkPSFxtPcNdEr5v6Orp1l4Kbce2fHf9EgSlhGPz580 0ymuIu9UwDMBGqci4eqUQozb/3VN7zpIBEZJFIDfoNEiL6N8/C4qC7aJKCXlQfsFQMic 6Yw+Se8QIwoIr8oEuXaH6G8hNvFIb8il/EKAsDFC9TYMcx+YN+1tdye/Yvf2B6nrlxgp I1dWRx1NQAxvmNIdjLHGU8f7leKRQjLqvMC//05rSaxCQh9UbiGWgNcJGJlAp2Q5L1YL FTfA== X-Received: by 10.224.90.1 with SMTP id g1mr3565466qam.0.1372853841210; Wed, 03 Jul 2013 05:17:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.72.132 with HTTP; Wed, 3 Jul 2013 05:17:01 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 3 Jul 2013 14:17:01 +0200 Message-ID: To: "Olle E. Johansson" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlZFfRRln8icZZuVGjODpWEdI8NMUugepuqXWquJ2GPXTBN0kPJe/ZTrR98vNIQXscOAZkq X-Mailman-Approved-At: Wed, 03 Jul 2013 05:56:02 -0700 Cc: "Cullen Jennings \(fluffy\)" , "dispatch@ietf.org list" , dane WG list Subject: Re: [dane] [dispatch] Random thoughts about SIP and DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 12:17:30 -0000 2013/7/3 Olle E. Johansson : > You can view it here: > http://www.slideshare.net/oej/danebased-tls-verification-in-the-sip-proto= col > > Feedback is always welcome! Just some comments: Slide 13 ------------ According to RFC 5922: - First check subjectAltName for SIP URIs with no username@. If so take them and exit. - Otherwise check subjectAltName for DNS domains. If so take them and exit. - Otherwise check the CN. Slide 14 ----------- SIPS? No please... it's better to write a new draft deprecating SIPS schema= ;) SIMPLE? good luck! :) -- I=C3=B1aki Baz Castillo From oej@edvina.net Wed Jul 3 22:57:27 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9E921F9EBC; Wed, 3 Jul 2013 22:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id upN+AteuVtyA; Wed, 3 Jul 2013 22:57:26 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 0B79921F9EE7; Wed, 3 Jul 2013 22:57:23 -0700 (PDT) Received: from [192.168.40.15] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 54FA893C1AF; Thu, 4 Jul 2013 05:57:20 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: "Olle E. Johansson" In-Reply-To: Date: Thu, 4 Jul 2013 07:57:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <175DFFE9-3BED-4ECD-B60D-749767B8313C@edvina.net> References: To: "Cullen Jennings (fluffy)" X-Mailer: Apple Mail (2.1508) Cc: "dispatch@ietf.org list" , dane WG list Subject: Re: [dane] Random thoughts about SIP and DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 05:57:27 -0000 4 jul 2013 kl. 00:39 skrev "Cullen Jennings (fluffy)" = : >=20 > I like it. Hope you write a draft.=20 Thanks. >=20 > In slide 9 with pub key, I don't understand how the challenge / = response works but this is probably just me not knowing enough=85 TLS verifies that the server actually has the private key in the cert it = sends using a challenge/response mechanism. If you ignore the cert = (since you actually have the public key and trust it), you still want to = verify that the server has the matching private key. >=20 > On slide 14,=20 >=20 > SIPS has turned out to be a mess but I don't think think you have to = consider it one way or the other. As much as it works (or does not = work), a connection secured via the DANE approach can be treated the = same as a connection secured via classic TLS approach=85 I suspect this = is about the same answer for connection reuse and SIMPLE. It seems like = they should both work fine with this.=20 Yes. There are some questions in regards to certificate matching in = SIMPLE but that applies regardless of DANE. >=20 > SIP Identity is a different kettle of fish but I think that as long as = the STIR bof deals with DANE, hopefully that will be resolve with = something better than current SIP Identity RFC.=20 Well, Jon wrote on the STIR mailing list that the HTTP uri could be = ignored if you had other means of verifying the cert, so if that's = correct the issue is already solved. Thanks for your feedback, Cullen! /O >=20 >=20 >=20 >=20 > On Jul 3, 2013, at 12:51 AM, Olle E. Johansson wrote: >=20 >> Hi! >>=20 >> I've tried to collect my thought about SIP and DANE on a slide set. = It's the way I brainstorm I guess :-) >>=20 >> You can view it here: >> = http://www.slideshare.net/oej/danebased-tls-verification-in-the-sip-protoc= ol >>=20 >> Feedback is always welcome!=20 >>=20 >> If this is on the right path, I'll try to write a draft. >>=20 >> We do have DNSsec support in Kamailio now, so hopefully I can get the = developer team to work with me to get some code for testing. >>=20 >> /Olle >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >=20 From viktor1dane@dukhovni.org Wed Jul 3 23:19:38 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5360B21F941D for ; Wed, 3 Jul 2013 23:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfTfmMLMDSJK for ; Wed, 3 Jul 2013 23:19:34 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 2C58121F934C for ; Wed, 3 Jul 2013 23:19:34 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 476CB2AAC8E; Thu, 4 Jul 2013 06:19:33 +0000 (UTC) Date: Thu, 4 Jul 2013 06:19:33 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130704061933.GQ29420@mournblade.imrryr.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Random thoughts about SIP and DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 06:19:38 -0000 On Wed, Jul 03, 2013 at 09:51:34AM +0200, Olle E. Johansson wrote: > I've tried to collect my thought about SIP and DANE on a slide > set. It's the way I brainstorm I guess :-) > > You can view it here: > http://www.slideshare.net/oej/danebased-tls-verification-in-the-sip-protocol I am confused about the 3rd bullet on slide 9: With TLSA public key, match to server by challenge/response (ignore server certificate contents). What is the intent here? Why is this different from TLSA certificate or TLSA digest? It is rather puzzling... Perhaps the whole validation slide is a bit mysterious... On slide 12, indeed DANE aware UAs will match the SRV hostname in the server certificate unless the certificate usage is 3, in which case name checks are redundant. So "3 1 1" can be more compatible in cases where legacy clients want a different certificate name than would be the case with DANE usages 0--2. Thus with no SNI, but TLSA "3 1 1" the certificates can remain unchanged (slide 13). -- Viktor. From fluffy@cisco.com Wed Jul 3 15:39:55 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2856821F9BD5; Wed, 3 Jul 2013 15:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azqy-nupDUsL; Wed, 3 Jul 2013 15:39:50 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 5E21A11E80E0; Wed, 3 Jul 2013 15:39:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1521; q=dns/txt; s=iport; t=1372891190; x=1374100790; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=7cSLhdAkOJdTUDSBVLRaCFNLTNAFXOOQ6m8V5oZ6MwI=; b=hfKLl0xk5/IC32tQmhXLyw+wfyFhS+68hg9nOvkIxYgA13werlTZXc0H AlYXFHEE34JGEXgNVjTqlQ7UF12N77P9BQro9YOSqf6Ez1q7YuRru+Lgo dRZ1Bo/01N2rWnrFonY/lSZaRgNkWfFJ2fHQA7b3nZ+QxYFSYhVIywPfZ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFAN6n1FGtJXHB/2dsb2JhbABRCYMJMknAOYEJFnSCIwEBAQMBAQEBawsFCwIBCCIkJwslAgQOBQiIAQYMuimOMIEIAjEHgwRpA6kOgxGCKA X-IronPort-AV: E=Sophos;i="4.87,991,1363132800"; d="scan'208";a="230776327" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-3.cisco.com with ESMTP; 03 Jul 2013 22:39:34 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r63MdYZV024354 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Jul 2013 22:39:34 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.116]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Wed, 3 Jul 2013 17:39:33 -0500 From: "Cullen Jennings (fluffy)" To: "Olle E. Johansson" Thread-Topic: [dane] Random thoughts about SIP and DANE Thread-Index: AQHOd8Imgvc/hKNE30u1xa1rKID//JlT4K2A Date: Wed, 3 Jul 2013 22:39:33 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.147.38] Content-Type: text/plain; charset="Windows-1252" Content-ID: <66466B2396467D44BE0805440C6C648B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 03 Jul 2013 23:20:32 -0700 Cc: "dispatch@ietf.org list" , dane WG list Subject: Re: [dane] Random thoughts about SIP and DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 22:39:55 -0000 I like it. Hope you write a draft.=20 In slide 9 with pub key, I don't understand how the challenge / response wo= rks but this is probably just me not knowing enough=85 On slide 14,=20 SIPS has turned out to be a mess but I don't think think you have to consid= er it one way or the other. As much as it works (or does not work), a conne= ction secured via the DANE approach can be treated the same as a connection= secured via classic TLS approach=85 I suspect this is about the same answe= r for connection reuse and SIMPLE. It seems like they should both work fine= with this.=20 SIP Identity is a different kettle of fish but I think that as long as the = STIR bof deals with DANE, hopefully that will be resolve with something bet= ter than current SIP Identity RFC.=20 On Jul 3, 2013, at 12:51 AM, Olle E. Johansson wrote: > Hi! >=20 > I've tried to collect my thought about SIP and DANE on a slide set. It's = the way I brainstorm I guess :-) >=20 > You can view it here: > http://www.slideshare.net/oej/danebased-tls-verification-in-the-sip-proto= col >=20 > Feedback is always welcome!=20 >=20 > If this is on the right path, I'll try to write a draft. >=20 > We do have DNSsec support in Kamailio now, so hopefully I can get the dev= eloper team to work with me to get some code for testing. >=20 > /Olle > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From oej@edvina.net Thu Jul 4 00:00:26 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53EBF21F9DE2 for ; Thu, 4 Jul 2013 00:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BvGw2ylVoodM for ; Thu, 4 Jul 2013 00:00:25 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id A1F9321F9CED for ; Thu, 4 Jul 2013 00:00:20 -0700 (PDT) Received: from [192.168.40.15] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 4BC9A93C1AF; Thu, 4 Jul 2013 07:00:19 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: "Olle E. Johansson" In-Reply-To: <20130704061933.GQ29420@mournblade.imrryr.org> Date: Thu, 4 Jul 2013 09:00:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130704061933.GQ29420@mournblade.imrryr.org> To: dane@ietf.org X-Mailer: Apple Mail (2.1508) Subject: Re: [dane] Random thoughts about SIP and DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 07:00:26 -0000 4 jul 2013 kl. 08:19 skrev Viktor Dukhovni : > On Wed, Jul 03, 2013 at 09:51:34AM +0200, Olle E. Johansson wrote: >=20 >> I've tried to collect my thought about SIP and DANE on a slide >> set. It's the way I brainstorm I guess :-) >>=20 >> You can view it here: >> = http://www.slideshare.net/oej/danebased-tls-verification-in-the-sip-protoc= ol >=20 > I am confused about the 3rd bullet on slide 9: >=20 > With TLSA public key, match to server by challenge/response > (ignore server certificate contents). >=20 > What is the intent here? Why is this different from TLSA certificate > or TLSA digest? It is rather puzzling... Perhaps the whole = validation > slide is a bit mysterious... Yes, it is. I need to work on that one. :-) >=20 > On slide 12, indeed DANE aware UAs will match the SRV hostname in > the server certificate unless the certificate usage is 3, in which > case name checks are redundant. So "3 1 1" can be more compatible > in cases where legacy clients want a different certificate name than > would be the case with DANE usages 0--2. >=20 > Thus with no SNI, but TLSA "3 1 1" the certificates can remain > unchanged (slide 13). Great. Thanks for the feedback, I'll take another stab at this and will notify when I update. /Olle= From viktor1dane@dukhovni.org Thu Jul 4 00:14:23 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2B4421F9377 for ; Thu, 4 Jul 2013 00:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1E43JgzxNlHt for ; Thu, 4 Jul 2013 00:14:18 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id A2D3A21F9AD3 for ; Thu, 4 Jul 2013 00:14:18 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id E75A02AAC8E; Thu, 4 Jul 2013 07:14:17 +0000 (UTC) Date: Thu, 4 Jul 2013 07:14:17 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130704071417.GR29420@mournblade.imrryr.org> References: <175DFFE9-3BED-4ECD-B60D-749767B8313C@edvina.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <175DFFE9-3BED-4ECD-B60D-749767B8313C@edvina.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Random thoughts about SIP and DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 07:14:24 -0000 On Thu, Jul 04, 2013 at 07:57:20AM +0200, Olle E. Johansson wrote: > TLS verifies that the server actually has the private key in the > cert it sends using a challenge/response mechanism. If you ignore > the cert (since you actually have the public key and trust it), > you still want to verify that the server has the matching private > key. This is a rather peculiar way of describing TLS, and the picture with DANE is more complex. - The EE certificate is never ignored, the SSL library will use its public key to encrypt or authenticate the key agreement. This is not usually described as challenge/response, it is encrypted or authenticated key exchange. So regardless of which PKI is used to verify the server certificate, it is the SSL library's job to ensure that the server certificate contains the public key whose private key either signed or decrypted the key exchange. - If the PKI is DANE, then: * If the public key in the TLSA RR is a trust anchor (usage 0 or 2), one needs to verify that the server certificate is signed by a valid chain whose top-most element is signed by the public key in question. * If the public key in the TLSA RR is an end-entity public key (usage 1 or 3), then it is simply compared with the public key from the server' certificate. If the usage is 3, that's the only check needed to ensure that the peer is authentic. - In principle matching a public key is not substantively different from matching a certificate. And matching via digests is conceptually the same as matching complete objects. The differences are: * The complete object (cert or key) may be too large for reliable delivery via DNS. * Matching via digests may require the full object to be sent in-band in the TLS handshake. * Support for bare TA public keys (2 1 0) may be difficult with existing libraries when the corresponding cert is not sent in-band. It sure seems like slide 9 is based on a misunderstanding of RFC 6698, though perhaps it is simply too concise, and just needs to be stated more clearly. -- Viktor. From oej@edvina.net Thu Jul 4 00:26:59 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C80521F9F58 for ; Thu, 4 Jul 2013 00:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RIQ1ujUiSlnU for ; Thu, 4 Jul 2013 00:26:58 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 54DE421F9ECB for ; Thu, 4 Jul 2013 00:26:57 -0700 (PDT) Received: from [192.168.40.16] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 815DE93C1AF; Thu, 4 Jul 2013 07:26:55 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: "Olle E. Johansson" In-Reply-To: <20130704071417.GR29420@mournblade.imrryr.org> Date: Thu, 4 Jul 2013 09:26:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <175DFFE9-3BED-4ECD-B60D-749767B8313C@edvina.net> <20130704071417.GR29420@mournblade.imrryr.org> To: dane@ietf.org X-Mailer: Apple Mail (2.1508) Subject: Re: [dane] Random thoughts about SIP and DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 07:26:59 -0000 4 jul 2013 kl. 09:14 skrev Viktor Dukhovni : > On Thu, Jul 04, 2013 at 07:57:20AM +0200, Olle E. Johansson wrote: >=20 >> TLS verifies that the server actually has the private key in the >> cert it sends using a challenge/response mechanism. If you ignore >> the cert (since you actually have the public key and trust it), >> you still want to verify that the server has the matching private >> key. >=20 > This is a rather peculiar way of describing TLS, and the picture with > DANE is more complex. >=20 > - The EE certificate is never ignored, the SSL library will use its > public key to encrypt or authenticate the key agreement. This is > not usually described as challenge/response, it is encrypted or > authenticated key exchange. >=20 > So regardless of which PKI is used to verify the server = certificate, > it is the SSL library's job to ensure that the server certificate > contains the public key whose private key either signed or = decrypted > the key exchange. >=20 > - If the PKI is DANE, then: >=20 > * If the public key in the TLSA RR is a trust anchor (usage > 0 or 2), one needs to verify that the server certificate > is signed by a valid chain whose top-most element is > signed by the public key in question. >=20 > * If the public key in the TLSA RR is an end-entity public key > (usage 1 or 3), then it is simply compared with the public > key from the server' certificate. If the usage is 3, that's > the only check needed to ensure that the peer is authentic. >=20 > - In principle matching a public key is not substantively > different from matching a certificate. And matching via > digests is conceptually the same as matching complete objects. >=20 > The differences are: >=20 > * The complete object (cert or key) may be too large for = reliable > delivery via DNS. >=20 > * Matching via digests may require the full object to be sent > in-band in the TLS handshake. >=20 > * Support for bare TA public keys (2 1 0) may be difficult with > existing libraries when the corresponding cert is not sent > in-band. >=20 > It sure seems like slide 9 is based on a misunderstanding of RFC 6698, > though perhaps it is simply too concise, and just needs to be stated > more clearly. I think it was sloppy work on the author's behalf. Thank you for your = clarification and - as always - very good feedback. /O= From oej@edvina.net Thu Jul 4 05:46:18 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2DBE21F9FF2; Thu, 4 Jul 2013 05:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9M+SDaaqmHjh; Thu, 4 Jul 2013 05:46:18 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id D905F21F9E48; Thu, 4 Jul 2013 05:46:15 -0700 (PDT) Received: from [192.168.40.16] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 502C793C1AF; Thu, 4 Jul 2013 12:46:13 +0000 (UTC) From: "Olle E. Johansson" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Jul 2013 14:46:12 +0200 Message-Id: <18932A7A-8989-4B32-BAE5-1BCFD07BC97F@edvina.net> To: "dane@ietf.org list" , "dispatch@ietf.org list" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [dane] Updated version of SIP DANE brainstorm X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jul 2013 12:46:18 -0000 Hi! I've updated my brainstorm of SIP & Dane. The new version can be found = here: http://www.slideshare.net/oej/sip-dane Changes: - Clarified TLSA records and validation (Cullen, Victor) - Added thoughts on SIP connection reuse SIP connection reuse is the art form of re-using a TLS connection = between two SIP servers for more than one destination - in the case of = SIP hosting with multiple domains. The current RFC is based on exchanging server and client certificates = with a list of domains in the SubjAltName field.=20 With DANE, there will be only the SRV host name. The server needs to = look up domains and if there's a secure delegation from a new domain to = a hostname where the server has a connection, add the domain to the domain table for that = connection and reuse it. Now the question is raised in my head - what about the client = certificate? We get a connection from an IP address and request a client certificate. = Is it really needed? In the current RFC it's a requirement. Server for example.com gets a connection from serverb.example.net. The = example.com domain relationship to the actual host srv02.example.com was verified using DANE and the cert validated correctly. Now if example.com has a SIP request addressed to example.net - it = checks DNS and gets DNSsec signed responses that points to = serverb.example.net. Is this enough to reuse the existing TLS connection for requests to = example.net? Or do we need a certificate on top of this somewhere? /O References: - RFC 5923 describes SIP connection reuse - RFC 5922 defines SIP domain certificates= From viktor1dane@dukhovni.org Thu Jul 4 09:35:11 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D06321F9E6D for ; Thu, 4 Jul 2013 09:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_BACKHAIR_14=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4GJ72J6F2f3b for ; Thu, 4 Jul 2013 09:35:07 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 2C85121F9DEF for ; Thu, 4 Jul 2013 09:35:07 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id BEDC22AAC85; Thu, 4 Jul 2013 16:35:02 +0000 (UTC) Date: Thu, 4 Jul 2013 16:35:02 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130704163502.GS29420@mournblade.imrryr.org> References: <18932A7A-8989-4B32-BAE5-1BCFD07BC97F@edvina.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18932A7A-8989-4B32-BAE5-1BCFD07BC97F@edvina.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Updated version of SIP DANE brainstorm X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 16:35:11 -0000 On Thu, Jul 04, 2013 at 02:46:12PM +0200, Olle E. Johansson wrote: > Hi! > > I've updated my brainstorm of SIP & Dane. The new version can be found here: > http://www.slideshare.net/oej/sip-dane > > Changes: > - Clarified TLSA records and validation (Cullen, Victor) On slide 11 you state that with DANE TLSA certificate usage 0/1 after matching the TLSA RR the certificate is verified "as before". It is true that the chain's validity is verified via PKIX as before, but name checks (which RFC 6698 does not detail, so this will be discussed in my "ops" draft) should look for the "base domain" of the TLSA RRset. Since DANE TLSA base names are fundamentally DNS entities, the corresponding certificate element must be a DNS subjectAltName. You seem to assume that clients will check both subjectAltNames and the CN, but existing RFCs specify that subjectAltName takes precedence, and if present the CN is ignored. Therefore, a certificate that matches both a legacy SIP domain and a new DANE SRV host name should have: Subject: /what=ever/CN=legacy.example subjectAltName: DNS:legacy.example, DNS:sip-srv.example.com That is the subjectAltName should always include any legacy CN intended for clients that don't understand subjectAltName. > SIP connection reuse is the art form of re-using a TLS connection > between two SIP servers for more than one destination - in the case > of SIP hosting with multiple domains. > The current RFC is based on exchanging server and client certificates > with a list of domains in the SubjAltName field. Is there any expectation that *outbound* SIP connections are only made by the hosts that receive incoming SIP connections? This is far from true for SMTP for example. If with SIP (as with SMTP), this cannot reasonably be assumed to be the set of inbound SRV hosts, you can't expect to find the client TLSA RRs at: __tcp.. You may need a new mechanism to publish the expected client certificate associations. -- Viktor. From oej@edvina.net Thu Jul 4 11:46:45 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B883211E8173 for ; Thu, 4 Jul 2013 11:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_BACKHAIR_14=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JdsPLd6PpccE for ; Thu, 4 Jul 2013 11:46:45 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id A606611E816B for ; Thu, 4 Jul 2013 11:46:41 -0700 (PDT) Received: from [192.168.40.15] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 4976893C1AF; Thu, 4 Jul 2013 18:46:39 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: "Olle E. Johansson" In-Reply-To: <20130704163502.GS29420@mournblade.imrryr.org> Date: Thu, 4 Jul 2013 20:46:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <823F08AB-3D0A-4A1C-9E0F-DCCECB7B204C@edvina.net> References: <18932A7A-8989-4B32-BAE5-1BCFD07BC97F@edvina.net> <20130704163502.GS29420@mournblade.imrryr.org> To: dane@ietf.org X-Mailer: Apple Mail (2.1508) Subject: Re: [dane] Updated version of SIP DANE brainstorm X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 04 Jul 2013 18:46:45 -0000 4 jul 2013 kl. 18:35 skrev Viktor Dukhovni : > On Thu, Jul 04, 2013 at 02:46:12PM +0200, Olle E. Johansson wrote: >> Hi! >>=20 >> I've updated my brainstorm of SIP & Dane. The new version can be = found here: >> http://www.slideshare.net/oej/sip-dane >>=20 >> Changes: >> - Clarified TLSA records and validation (Cullen, Victor) >=20 > On slide 11 you state that with DANE TLSA certificate usage 0/1 after > matching the TLSA RR the certificate is verified "as before". >=20 > It is true that the chain's validity is verified via PKIX as before, = but > name checks (which RFC 6698 does not detail, so this will be discussed > in my "ops" draft) should look for the "base domain" of the TLSA = RRset. >=20 > Since DANE TLSA base names are fundamentally DNS entities, the > corresponding certificate element must be a DNS subjectAltName. >=20 > You seem to assume that clients will check both subjectAltNames > and the CN, but existing RFCs specify that subjectAltName takes > precedence, and if present the CN is ignored. >=20 > Therefore, a certificate that matches both a legacy SIP domain and > a new DANE SRV host name should have: >=20 > Subject: /what=3Dever/CN=3Dlegacy.example >=20 > subjectAltName: DNS:legacy.example, DNS:sip-srv.example.com >=20 > That is the subjectAltName should always include any legacy CN = intended > for clients that don't understand subjectAltName. Ok, that was badly written. I need to specify more clearly what I want. I think we always should match the SRV host name with the certificate if DANE is used and TLSA records exists, never fall back to the old RFC.=20= If there's a TLSA record, let's skip the SIP domain certificates RFC and=20= follow the DANE SRV draft more closely. >=20 >> SIP connection reuse is the art form of re-using a TLS connection >> between two SIP servers for more than one destination - in the case >> of SIP hosting with multiple domains. >> The current RFC is based on exchanging server and client certificates >> with a list of domains in the SubjAltName field. >=20 > Is there any expectation that *outbound* SIP connections are only made > by the hosts that receive incoming SIP connections? This is far from > true for SMTP for example. The word "outbound" is in SIP reserved for a specific standard NAT traversal method for clients. The SIP connection reuse RFC is for = exchange of SIP messages between two SIP servers, not endpoints. It leaves some parts unlear in regards to a server knowing that another server is connecting to it and separating a server from a user agent=20 - because we have no separation of "server" vs "phone",=20 like in XMPP where two different ports are used. >=20 > If with SIP (as with SMTP), this cannot reasonably be assumed to > be the set of inbound SRV hosts, you can't expect to find the client > TLSA RRs at: >=20 > __tcp.. >=20 > You may need a new mechanism to publish the expected client > certificate associations. The question here is if the client sends messages from sip:something@example.net - can I find the SRV hosts for example.net, look them up and see if any IP matches the one I have a connection from? If all these DNS lookups was protected with DNSsec, can I assume that the client is authoritative for "example.net" and send messages=20 to that domain reusing the same connection? This way, no certificate is involved in that direction, from the = original server to the client in the connection. The connection is already using TLS, but we haven't used TLS certificates to check the client side. I hope you follow what I mean. /O From wes@hardakers.net Fri Jul 5 09:07:49 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D52311E8303 for ; Fri, 5 Jul 2013 09:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kx+IaTzNHnKV for ; Fri, 5 Jul 2013 09:07:49 -0700 (PDT) Received: from mail.hardakers.net (dawn.hardakers.net [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id F0B6B11E82F1 for ; Fri, 5 Jul 2013 09:07:48 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:470:1f00:187:2d18:a2d8:d1b1:37a6]) by mail.hardakers.net (Postfix) with ESMTPSA id 3725B2A31A; Fri, 5 Jul 2013 09:07:47 -0700 (PDT) From: Wes Hardaker To: Viktor Dukhovni References: <175DFFE9-3BED-4ECD-B60D-749767B8313C@edvina.net> <20130704071417.GR29420@mournblade.imrryr.org> Date: Fri, 05 Jul 2013 09:07:47 -0700 In-Reply-To: <20130704071417.GR29420@mournblade.imrryr.org> (Viktor Dukhovni's message of "Thu, 4 Jul 2013 07:14:17 +0000") Message-ID: <0lli5lj8h8.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: dane@ietf.org Subject: Re: [dane] Random thoughts about SIP and DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 16:07:49 -0000 Viktor Dukhovni writes: > * If the public key in the TLSA RR is a trust anchor (usage > 0 or 2), one needs to verify that the server certificate > is signed by a valid chain whose top-most element is > signed by the public key in question. That text could be interpreted as "must be the top-most root CA", which isn't true. It may point to an accepted subordinate CA and there may be a higher level available in a chain. IE, it doesn't have to be the upper most endpoint available (though may be the highest endpoint needed for verification). Actually, the way that 6698 is written, I think the below is legal usage of type 0. But it's not crystal clear: O -- Root CA in a PKIX chain and present in the child's | CA bundle / TA list. | O -- type 0/2 DANE record points here to a subordinate TA | | O -- EE cert I don't think the reverse is legal: O -- type 0/2 DANE record points here to a subordinate TA | | O -- Subordinate CA in a PKIX chain and present in the child's | CA bundle / TA list. | O -- EE cert Reading the type 0 specification, I *think* prohibits the second case because it says: "specify a CA certificate, or the public key of such a certificate, that MUST be found in any of the PKIX certification paths for the end entity certificate given by the server in TLS" And my reading is that because the type 0 pointer is not *inside* the PKIX path, then it's not acceptable. Above it doesn't count if the top level isn't in the CA store. Any one else want to point to me where I'm wrong, especially on the first diagram? -- Wes Hardaker My Pictures: http://capturedonearth.com/ My Thoughts: http://pontifications.hardakers.net/ From wjhns1@hardakers.net Fri Jul 5 09:08:09 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1F3A11E832B for ; Fri, 5 Jul 2013 09:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lt5xYWgrtIR for ; Fri, 5 Jul 2013 09:08:09 -0700 (PDT) Received: from mail.hardakers.net (unknown [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id A0A0C11E832A for ; Fri, 5 Jul 2013 09:08:08 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:470:1f00:187:2d18:a2d8:d1b1:37a6]) by mail.hardakers.net (Postfix) with ESMTPSA id 06D3D2A319; Fri, 5 Jul 2013 09:08:07 -0700 (PDT) From: Wes Hardaker To: Viktor Dukhovni In-Reply-To: <20130704071417.GR29420@mournblade.imrryr.org> (Viktor Dukhovni's message of "Thu, 4 Jul 2013 07:14:17 +0000") References: <175DFFE9-3BED-4ECD-B60D-749767B8313C@edvina.net> <20130704071417.GR29420@mournblade.imrryr.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2 (gnu/linux) Date: Fri, 05 Jul 2013 09:08:07 -0700 Message-ID: <0lk3l5j8go.fsf@wjh.hardakers.net> MIME-Version: 1.0 Content-Type: text/plain Cc: dane@ietf.org Subject: Re: [dane] Random thoughts about SIP and DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 16:08:09 -0000 Viktor Dukhovni writes: > * If the public key in the TLSA RR is a trust anchor (usage > 0 or 2), one needs to verify that the server certificate > is signed by a valid chain whose top-most element is > signed by the public key in question. That text could be interpreted as "must be the top-most root CA", which isn't true. It may point to an accepted subordinate CA and there may be a higher level available in a chain. IE, it doesn't have to be the upper most endpoint available (though may be the highest endpoint needed for verification). Actually, the way that 6698 is written, I think the below is legal usage of type 0. But it's not crystal clear: O -- Root CA in a PKIX chain and present in the child's | CA bundle / TA list. | O -- type 0/2 DANE record points here to a subordinate TA | | O -- EE cert I don't think the reverse is legal: O -- type 0/2 DANE record points here to a subordinate TA | | O -- Subordinate CA in a PKIX chain and present in the child's | CA bundle / TA list. | O -- EE cert Reading the type 0 specification, I *think* prohibits the second case because it says: "specify a CA certificate, or the public key of such a certificate, that MUST be found in any of the PKIX certification paths for the end entity certificate given by the server in TLS" And my reading is that because the type 0 pointer is not *inside* the PKIX path, then it's not acceptable. Above it doesn't count if the top level isn't in the CA store. Any one else want to point to me where I'm wrong, especially on the first diagram? -- Wes Hardaker My Pictures: http://capturedonearth.com/ My Thoughts: http://pontifications.hardakers.net/ From viktor1dane@dukhovni.org Fri Jul 5 11:16:23 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0263B21F9FF3 for ; Fri, 5 Jul 2013 11:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fq1PqbHpPhgI for ; Fri, 5 Jul 2013 11:16:18 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 56F9821F9FE2 for ; Fri, 5 Jul 2013 11:16:12 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 2BE2B2AAB42; Fri, 5 Jul 2013 18:16:05 +0000 (UTC) Date: Fri, 5 Jul 2013 18:16:05 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130705181605.GX29420@mournblade.imrryr.org> References: <175DFFE9-3BED-4ECD-B60D-749767B8313C@edvina.net> <20130704071417.GR29420@mournblade.imrryr.org> <0lli5lj8h8.fsf@wjh.hardakers.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0lli5lj8h8.fsf@wjh.hardakers.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Random thoughts about SIP and DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 18:16:23 -0000 On Fri, Jul 05, 2013 at 09:07:47AM -0700, Wes Hardaker wrote: > Viktor Dukhovni writes: > > > * If the public key in the TLSA RR is a trust anchor (usage > > 0 or 2), one needs to verify that the server certificate > > is signed by a valid chain whose top-most element is > > signed by the public key in question. > > That text could be interpreted as "must be the top-most root CA", which > isn't true. It may point to an accepted subordinate CA and there may be > a higher level available in a chain. IE, it doesn't have to be the > upper most endpoint available (though may be the highest endpoint needed > for verification). That's not the intent, the phrase "a valid chain", means some chain built from a subset of the certificates sent by the server, hence the TA may be in the middle, but then we throw away the rest. > Actually, the way that 6698 is written, I think the below is legal usage > of type 0. But it's not crystal clear: > > O -- Root CA in a PKIX chain and present in the child's > | CA bundle / TA list. > | > O -- type 0/2 DANE record points here to a subordinate TA > | > | > O -- EE cert Yes, this is just fine. > I don't think the reverse is legal: > > O -- type 0/2 DANE record points here to a subordinate TA > | > | > O -- Subordinate CA in a PKIX chain and present in the child's > | CA bundle / TA list. > | > O -- EE cert This is fine too, but of course the TA in the middle is not self-signed, or else it can't have an issuing parent. If the client's library has trusted intermediate PKIX CAs, this should be OK also. > Reading the type 0 specification, I *think* prohibits the second case > because it says: > > "specify a CA certificate, or the public key of such a > certificate, that MUST be found in any of the PKIX certification > paths for the end entity certificate given by the server in TLS" This reading of the language is I believe too strict. Otherwise a TA root CA will break on clients that trust intermediate certs, which would be rather surprising and broken. All that 6698 was trying to say was the the TA need not be at the top of the chain. If the client builds a truncated chain because it trusts non-root CAs that is not a reason to reject the TA in usage 0. OpenSSL typically avoids this problem, because by default it looks for issuers in the peer's chain first, and in the trust store only as a last resort (except that the root of the chain is possibly replaced by a trust-store variant with trust settings). We should probably clarify this in the ops draft, (it is more implementation issue than operational issue, but the ops draft already crosses that boundary in a major way). > And my reading is that because the type 0 pointer is not *inside* the > PKIX path, then it's not acceptable. Above it doesn't count if the top > level isn't in the CA store. This would be rather bad, so if 6698 can be read that way, it should be made more clear. Of course if the client only trusts the intermediate and not the root, the CA constraint is no longer a constraint, so the client implementation really needs to walk the chain to the topmost trusted CA and not stop in the middle. I don't use PKIX validation, so my implementation does not run into this, but otherwise client care is required. -- Viktor. From oej@edvina.net Sat Jul 6 06:44:36 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBC4B21F88EA for ; Sat, 6 Jul 2013 06:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQyBuOkqtsXc for ; Sat, 6 Jul 2013 06:44:36 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 3222321F88D8 for ; Sat, 6 Jul 2013 06:44:34 -0700 (PDT) Received: from 216.242.214.82.in-addr.arpa (unknown [82.214.242.216]) by smtp7.webway.se (Postfix) with ESMTPA id F2E0F93C1AF; Sat, 6 Jul 2013 13:44:07 +0000 (UTC) From: "Olle E. Johansson" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 6 Jul 2013 15:43:52 +0200 Message-Id: <5B0A4B86-1D09-4F33-B170-08D8E2A830F0@edvina.net> To: "dane@ietf.org list" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [dane] draft-ietf-dane-srv-02 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jul 2013 13:44:37 -0000 Hi! While working on the SIP-dane draft, I'm trying to follow = draft-ietf-dane-srv and add the missing parts for SIP. I note that in section 6 the draft requires support for TLS SNI (RFC = 6066).=20 Why is this a requirement? I don't see the need to require SNI here. = Supporting SNI makes life much easier for everyone, but as I haven't seen many SIP implementations using it = (mostly because the support=20 hasn't been in the installed versions of OpenSSL/GnuTLS and ...hummm... = TLS is not widely used). Adding a requirement on this (a must level) is in my view a bit too = harsh. One could rephrase it a bit, to say "if a server is addressed using = multiple names TLS SNI must be supported". Cheers, /O= From paul.hoffman@vpnc.org Sat Jul 6 07:56:36 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC1E21F9C11 for ; Sat, 6 Jul 2013 07:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9JrJA7kBugK for ; Sat, 6 Jul 2013 07:56:36 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 037E421F9C0E for ; Sat, 6 Jul 2013 07:56:35 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-228.dsl.dynamic.sonic.net [50.1.98.228]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r66EuRl5096617 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 6 Jul 2013 07:56:29 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <5B0A4B86-1D09-4F33-B170-08D8E2A830F0@edvina.net> Date: Sat, 6 Jul 2013 07:56:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5B0A4B86-1D09-4F33-B170-08D8E2A830F0@edvina.net> To: "Olle E. Johansson" X-Mailer: Apple Mail (2.1508) Cc: "dane@ietf.org list" Subject: Re: [dane] draft-ietf-dane-srv-02 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jul 2013 14:56:36 -0000 On Jul 6, 2013, at 6:43 AM, Olle E. Johansson wrote: > While working on the SIP-dane draft, I'm trying to follow = draft-ietf-dane-srv and add the missing parts for SIP. >=20 > I note that in section 6 the draft requires support for TLS SNI (RFC = 6066).=20 >=20 > Why is this a requirement? I don't see the need to require SNI here. = Supporting SNI makes life much easier > for everyone, but as I haven't seen many SIP implementations using it = (mostly because the support=20 > hasn't been in the installed versions of OpenSSL/GnuTLS and = ...hummm... TLS is not widely used). >=20 > Adding a requirement on this (a must level) is in my view a bit too = harsh. >=20 > One could rephrase it a bit, to say "if a server is addressed using = multiple names TLS SNI must > be supported". Support for SNI on the relying party side is needed because a relying = party can't know ahead of time whether or not a server will have = multiple names. Further, without this requirement, a server that has an = operational reason to use multiple names would be constrained not to = because of the lack of support for SNI in the systems it wants to = communicate with. --Paul Hoffman= From viktor1dane@dukhovni.org Sat Jul 6 12:57:59 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1345921F9CC1 for ; Sat, 6 Jul 2013 12:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1O9fGCt93pB for ; Sat, 6 Jul 2013 12:57:54 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id CD3FA21F9CBF for ; Sat, 6 Jul 2013 12:57:54 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 792DB2AAC91; Sat, 6 Jul 2013 19:57:50 +0000 (UTC) Date: Sat, 6 Jul 2013 19:57:50 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130706195750.GE29420@mournblade.imrryr.org> References: <5B0A4B86-1D09-4F33-B170-08D8E2A830F0@edvina.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] draft-ietf-dane-srv-02 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 19:57:59 -0000 On Jul 6, 2013, at 6:43 AM, Olle E. Johansson wrote: > I note that in section 6 the draft requires support for TLS SNI (RFC 6066). > > Why is this a requirement? I don't see the need to require SNI > here. Supporting SNI makes life much easier for everyone, but as I > haven't seen many SIP implementations using it (mostly because the > support hasn't been in the installed versions of OpenSSL/GnuTLS and > ...hummm... TLS is not widely used). Clients MUST support SNI. Servers need not. Take a look at the latest revision of Wes Hardaker's and mine SMTP draft: $ git clone https://github.com/vdukhovni/ietf $ cd ietf; make Then read the resulting: draft-dukhovni-dane-ops-01.html draft-dukhovni-smtp-opportunistic-tls-01.html with your favour browser, or just read the source XML if you prefer. This is gradually becoming a reasonably coherent description of how to use DANE TLSA with an actual applicaton protocol. It will I hope prove a useful jumping off point for other protocol specifications. Please read it, all constructive comments (including patches correcting any glaring mistakes) welcome. -- Viktor. From oej@edvina.net Sun Jul 7 01:46:21 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6106121F9EB5 for ; Sun, 7 Jul 2013 01:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ev+LCJO4VSGv for ; Sun, 7 Jul 2013 01:46:20 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 6FBE021F9EAF for ; Sun, 7 Jul 2013 01:46:18 -0700 (PDT) Received: from [192.168.1.43] (170.Red-88-2-166.staticIP.rima-tde.net [88.2.166.170]) by smtp7.webway.se (Postfix) with ESMTPA id 31A5093C2A1 for ; Sun, 7 Jul 2013 08:46:14 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: "Olle E. Johansson" In-Reply-To: <20130706195750.GE29420@mournblade.imrryr.org> Date: Sun, 7 Jul 2013 10:46:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5B0A4B86-1D09-4F33-B170-08D8E2A830F0@edvina.net> <20130706195750.GE29420@mournblade.imrryr.org> To: dane@ietf.org X-Mailer: Apple Mail (2.1508) Subject: Re: [dane] draft-ietf-dane-srv-02 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jul 2013 08:46:21 -0000 6 jul 2013 kl. 21:57 skrev Viktor Dukhovni : > On Jul 6, 2013, at 6:43 AM, Olle E. Johansson wrote: >=20 >> I note that in section 6 the draft requires support for TLS SNI (RFC = 6066).=20 >>=20 >> Why is this a requirement? I don't see the need to require SNI >> here. Supporting SNI makes life much easier for everyone, but as I >> haven't seen many SIP implementations using it (mostly because the >> support hasn't been in the installed versions of OpenSSL/GnuTLS and >> ...hummm... TLS is not widely used). >=20 > Clients MUST support SNI. Servers need not. Take a look at the > latest revision of Wes Hardaker's and mine SMTP draft: >=20 > $ git clone https://github.com/vdukhovni/ietf > $ cd ietf; make >=20 > Then read the resulting: >=20 > draft-dukhovni-dane-ops-01.html > draft-dukhovni-smtp-opportunistic-tls-01.html >=20 > with your favour browser, or just read the source XML if you prefer. >=20 > This is gradually becoming a reasonably coherent description of > how to use DANE TLSA with an actual applicaton protocol. It will > I hope prove a useful jumping off point for other protocol > specifications. Please read it, all constructive comments (including > patches correcting any glaring mistakes) welcome. I will read. Notice a statement that sni on server side was required in order to provide backwards compatibility. Since SIP use subjaltnames and we just can add another for the SRV host, I don't think we need to require SNI for SIP. /O= From bry8star@inventati.org Sun Jul 7 17:09:43 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB5CD21F8C4C for ; Sun, 7 Jul 2013 17:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.201 X-Spam-Level: * X-Spam-Status: No, score=1.201 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_65=0.6, J_CHICKENPOX_83=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Izj0LyEhT82i for ; Sun, 7 Jul 2013 17:09:40 -0700 (PDT) Received: from latitanza.investici.org (latitanza.investici.org [IPv6:2002:525e:f9ea::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E98D21F91B0 for ; Sun, 7 Jul 2013 17:09:35 -0700 (PDT) Received: from [82.94.249.234] (latitanza [82.94.249.234]) (Authenticated sender: bry8star@inventati.org) by localhost (Postfix) with ESMTPSA id 2DEB0981E8 for ; Mon, 8 Jul 2013 00:09:23 +0000 (UTC) X-DKIM: Sendmail DKIM Filter v2.8.2 latitanza.investici.org 2DEB0981E8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inventati.org; s=stigmate; t=1373242173; bh=7EkjbIPgifL/bNsQyImJcaED8yi/3Df+L4BTZudS6jY=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject:References: In-Reply-To:Content-Type; b=nJ0bL2wPxusUMAB7qU6h5PhUhZNxtCuf14QTm+q3XrUgh60d9Z69lIXYbJxKMQs7K pyhw57btIhTfDm9ReTbNodgdfj+YhDzKnTfNnpsVw0m32HEXZzbzZ/fNCGFWn7irbw AkQQN73aK9v2aHKOUVzL3596fU2xXVchn8BlSmCc= Message-ID: <51DA0317.4000808@inventati.org> Date: Sun, 07 Jul 2013 17:08:55 -0700 From: Bry8 Star User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: dane@ietf.org References: <51B9C72E.2040706@inventati.org> <20130613191536.GL29420@mournblade.imrryr.org> <51BAC647.1060302@inventati.org> <20130614143603.GO29420@mournblade.imrryr.org> <51BB5029.2080205@inventati.org> <98C0E5EE-BB9F-4E0B-AB9F-A5BED86B4125@kumari.net> <51BCBD79.1040807@gmail.com> <51BEA6C4.5090005@inventati.org> <20130617081609.GF29420@mournblade.imrryr.org> In-Reply-To: <20130617081609.GF29420@mournblade.imrryr.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2TNWOPCKTKPKCIGEASDKC" Subject: Re: [dane] Combined TLSA TA (2 S M) and TLSA EE (1 S M) Usage X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bry8star@inventati.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 00:09:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2TNWOPCKTKPKCIGEASDKC Content-Type: multipart/mixed; boundary="------------070007060609050104010202" This is a multi-part message in MIME format. --------------070007060609050104010202 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thank you very much again for very valuable and all help. "tlsagen" is fantastic bash script (it uses openssl and perl). (But, i could not utilize SPKI C_A_D gen functions in my side). D-O =3D Domain-Owner. ZO =3D Zone-Operator. Few/Other helpful instructions for D-O / ZO : Convert a .pem based SSL / TLS certificate (use public-portion only) file, into its equivalent binary DER based cert file: openssl x509 -in SSL-cert-file.pub.pem \ -outform DER \ -out SSL-cert-file.pub.der If you are sure your .pem file is actually & really in PEM format, then you can add this portion in above command: -inform PEM (From openssl.org site : "If no nameopt switch is present the default "oneline" format is used...". "oneline : ... It is equivalent to specifying the esc_2253, esc_ctrl, esc_msb, utf8, dump_nostr, dump_der, use_quote, sep_comma_plus_space, space_eq and sname options). (So using "-nameopt oneline" is not necessary). Always use only public-portion of a SSL/TLS certificate, when creating C_A_D codes for TLSA dns RRs. Do not keep or use private_key portion inside your .pem or .cer or .crt cert file, when you will use it for creating C_A_D. Many users forget to remove private_key portion from pem file, so be careful about that. C_A_D =3D Certificate Association Data. Used in TLSA dns record (RR), obtained/created from or based on, a SSL/TLS certificate. Command-lines in linux/unix can be joined using "&&" symbols (use without double-quotes). Shown "\" (backslash) symbol is just an indicator that next line is part of this line. So in your actual command-line, do not use those "\" symbols, instead join them, to form one single long command-line. In this email we use/used it, to place rest of the command-line in a next line, (as email and email-reply breaks full lines and words into smaller portions, and may result into wrong command). Few other alternative simple commands to convert a DER based full (public-side) certificate, into full C_A_D, to use in TLSA RRs: cat SSL-cert-file.pub.der | \ hexdump -v -e '"" 1/1 "%02X" ""' ; echo (You may see reference [1] in below for how this command was formed/formulated) To save the shown C_A_D hexadecimal codes in a file, (so that you can copy-paste into a zone-file), a ZO/D-O user can do such as this command-line: cat SSL-cert-file.pub.der | \ hexdump -v -e '"" 1/1 "%02X" ""' > \ SSL-cert-file.full-cad.tlsa Another alternative: openssl x509 -in SSL-cert-file.pub.pem \ -outform DER -nameopt oneline | \ hexdump -v -e '"" 1/1 "%02X" ""' > \ SSL-cert-file.full-cad.tlsa To append a NL (new-line) or LF (aka, line-feed, aka, "\n") character at end of long hexadecimal code in a file, such command can be used: echo >> SSL-cert-file.full-cad.tlsa Note: in above, you must use two ">" symbol, for "append" process to work, like this: >> All these commands can be joined & applied using one long command-line, in a bash shell, like this: openssl x509 -in SSL-cert-file.pub.crt \ -outform DER | hexdump -v -e \ '"" 1/1 "%02X" ""' > \ SSL-cert-file.full-cad.tlsa ; \ echo >> SSL-cert-file.full-cad.tlsa Another alternative of above command-line, will work in linux/unix bash shell/terminal like this: { openssl x509 -in SSL-cert-file.pub.crt \ -outform DER | \ hexdump -v -e '"" 1/1 "%02X" ""' \ ;echo; } > SSL-cert-file.full-cad.tlsa (You may see reference [3] in below for how this command was formed/formulated) To view "SSL-cert-file.full-cad.tlsa" file's content on screen, use this command: cat SSL-cert-file.full-cad.tlsa Another perl based command, to convert a DER based SSL/TLS cert file, into its equivalent Full C_A_D hexadecimal codes: perl -e ' $der2cad =3D ""; $ssl_der_file=3D""; $ssl_der_file =3D $ARGV[0]; die "SSL DER 2 TLSA CAD: Please specify a DER " =2E"based SSL filename in commandline.\n" unless $ssl_der_file; open my $fh, "<", $ssl_der_file or die "Could not open \"$ssl_der_file\": $!\n"; { local $/; $der2cad =3D <$fh>; } close $fh; $der2cad =3D~ s/(.)/sprintf("%02X", ord($1))/egs; printf "$der2cad\n"; ' "SSL-cert-file.pub.der" Optionally, you should join above 10 lines into one single long one command line, before executing. (You may see reference [2] in below for how this command was formed/formulated) In above perl codes, it takes each DER binary (bin) character (char) (from DER file) one by one, ("ord") converts one bin char into equivalent ASCII numeric, ("ord" can handle Unicode chars), and then ("%X" formatting flag in "sprintf") again converts that into equivalent Hexadecimal number, and then a formatting is done: if an ASCII numeric is converted into a hex number which have single hex-digit then one zero is added in front of it, (if hex conversion have no hex-digit then upto two zeros will be used as replacement, but this does not happen as perl "ord" sends at-least one zero), and, if converted hex have two hex-digits then it remains intact, and finally this (hex-converted & formatted) number is used to replace the input bin-char, and in this way one by one, all bin-char is converted into equivalent hexadecimals. Even another perl script to convert a DER based SSL cert into its equivalent Full C_A_D and HASH-256 and HASH-512 hexadecimal codes: perl -e ' use Digest::SHA qw(sha256_hex sha512_hex); $rFN =3D ""; $rFN =3D $ARGV[0]; $m =3D " v1.0.201307030000. Bright Star \(bry " =2E"8 st ar \@a.t\@ ya hoo d.o.t c om\)\n"; die "SSL DER 2 TLSA CAD\: Specify a DER based SSL " =2E"filename in commandline.\n$m" unless $rFN; printf "SSL DER 2 TLSA CAD:\n$m\nAttempting to load " =2E"\"$rFN\" file..."; open my $rFH, "<", $rFN or die " Failed To Load $rFN File For Reading: $!\n"; { local $/; $der =3D <$rFH>; } close $rFH || warn " Failed To Close $rFN File: $!\n"; printf " loading done.\n\n"; $full_cad =3D $der; $full_cad =3D~ s/(.)/sprintf("%02X", ord($1))/egs; $m =3D "\; a DNSSEC DANE/TLSA DNS record syntax\:\n" =2E"\; _port._proto.[host.]domain.TLD. [TTL] IN " =2E"TLSA u s m C_A_D\n\n\; Replace below \"u\" based " =2E"on SSL certificate \"usage\"\n\; type, mentioned " =2E"in\:\n\; " =2E"https\://tools.ietf.org/html/rfc6698\n\n\; " =2E"A Full C_A_D hexadecimal code of Full SSL " =2E"cert\:\n\n_443._tcp.www\.example\.com. 900 IN " =2E"TLSA u 0 0 $full_cad\n\n"; my $sha =3D Digest::SHA->new(256); $sha->addfile($rFN, "b"); $sha256 =3D uc $sha->hexdigest; $m .=3D "\; SHA-256 based C_A_D of Full SSL cert\:\n" =2E"\n_443._tcp.www\.example\.com. 900 IN TLSA u " =2E"0 1 $sha256\n\n"; $sha =3D Digest::SHA->reset(512); $sha->addfile($rFN, "b"); $sha512 =3D uc $sha->hexdigest; $m .=3D "\; SHA-512 based C_A_D of Full SSL cert\:\n" =2E"\n_443._tcp.www\.example\.com. 900 IN TLSA u " =2E"0 2 $sha512\n\n"; printf "$m"; $wFN =3D $rFN . ".cad.tlsa"; printf "Attempting to create or over-write \"$wFN\"..."; open my $wFH, ">", $wFN or die " Could Not Create or OverWrite $wFN File For " =2E"Writing: $!\n"; { print $wFH "$m"; } close($wFH) || warn " Failed To Close $wFN File: $!\n"; printf " file created.\n"; ' "SSL-cert-file.pub.der" Above codes are attached as "der2tlsa_pl" file. Rename der2tlsa_pl, into der2tlsa.pl before using. A perl command can be: =2E/der2cad.pl SSL-cert-file.pub.der (You may see reference [4] in below for how this command was formed/formulated) In later version i may add further features. Perl usually exist in most variants of Linux, Unix, MacOSX type of OSes. There are Strawberry perl, Active Perl, etc software for Windows OS. Install and place perl's "bin" folder in your (Windows) OS's PATH environment variable, and then, either restart computer, or, logout+login. Another option for Windows OS users is to get Cygwin's setup file, and install cygwin and related tools. It can enable you to use Linux/Unix "bash" or other shell/terminal/console interface, and cygwin will also enable you to use (various) other software and tools like : perl, python, gcc, gpg, bind, bind-utils, dig, openssl, ssh, certtool, danetool, dnssec-keygen, dnssec-dsfromkey, dnssec-signzone, dnssec-revoke, named-checkzone, gnutls-serv, gnutls-cli, various types of compilers, ... etc. For cygwin users only : Inside Cygwin setup do these : for "hexdump" to work, search for "util-linux" > "Utils" or "System" > select "util-linux". Also load these : search for "openssl" > Net > select "openssl", search for "perl" > Interpreters > select "perl", search for "python" > Interpreters > select "python", search for "bind" > Net > select "bind-utils" and "bind", search for "openssh" > Net > select "openssh", search for "gnupg" > Utils > select "gnupg" (GPG). And complete installation of those (and related components). Those who (wants to or do) use proxy : Cygwin will allow HTTP proxy. Though support of Socks5 proxy would have been better. Update base/cygwin/core (and security related) components via direct connection. Then smaller or other tools can be updated/loaded via proxy connection. If your HTTP-proxy is connected to a Socks5 proxy, then make sure to use and configure such HTTP-proxy software, which will not leak DNS via direct connection. In such case, all DNS suppose to go through Socks5 proxy tunnel. It would have been better if cygwin website was DNSSEC signed, (at the time of writing this, :( it is not signed), and, if their SSL/TLS certificate was declared in their TLSA/DANE dns record, and if there was an option to download the "setup.exe" file from a HTTPS based webpage (or if "setup.exe" was GPG signed and they were showing asc/sig, but, that is not the case :( at the time of writing this). ( And it would have been better if "setup.exe" was using (or obtaining) at-least GPG authenticated file-list & mirror-list, and was also using at-least gpg authenticated developer-list, where each developer's package signing keys were pre-declared, so that files downloaded over non-encrypted connections like HTTP or FTP or when obtained via proxy, can still be verified authentically in client side, with (almost) no chance of using a fake file, if a fake or altered file was delivered to the client side ) <-- Cygwin probably already doing such, i'm not sure though. Something similar like above, should be applied on CPAN, Ruby/gems, etc and similar type of other package management software/tools. Package management software/tools should be able to handle DNSSEC queries and responses, on its own. Specially any software developers or developer-groups who owns domains/zones, they must declare their package signing GPG KEYS (public side portion), in their CERT PGP, etc DNS records. They must declare their web-server's SSL cert's Full C_A_D (or SHA-512 hash based C_A_D) in their TLSA DNS records. These standards are already released for some time by now, they should have done it by now. A DNSSEC signed zone and which also declares SSL cert's TLSA dns record, indicates that it's owners/developers care about security and safety of files and user's/people's data/content, and also indicates that they care about their own security and safety. And ISC DLV can be used to publish/declare a domain's/zone's DNSSEC DS keys (public-side), when a domain-name owner or zone-operator do not yet have full DNSSEC support in their own zone's/domain-name's registry/registrar or dns/zone-operator company/entity. And in such case they can instruct users/visitors in their homepage, to also use ISC DLV dnssec key and enable it in user-side (or visitor/client -side) local DNS-Server or DNS-Resolver, for DNSSEC (and related) authentications. They(D-O/ZO) can also use/configure their own DLV server. Until, a full DNSSEC support is introduced/deployed by their domain-name's/zone's registry/registrar entities. And all users, visitors, or clients etc, need to make sure that they are always using the last & valid & default DNSSEC root-key file or codes, in their own DNS-Server or DNS-Resolver software. Default dnssec rootkey comes from Root servers, and these servers are governed by ICANN/IANA. I tested each command-lines, scripts posted in this email. Please do correct mistakes, Thanks in advance, -- Bright Star. References/Notes section: [1] User "grimeton"/"ruth" (in #openssl in Freenode) suggested to use "cat somecert.der | hexdump", which i had to modify a lot for it to work. User "damncool" in CommandLineFu.com site showed this "$hexdump -v -e '"\\""x" 1/1 "%02x" ""' " code, which was modified further (by me) to show suitable code for C_A_D. man hexdump [2] Base code was obtained from http://perldoc.perl.org/perlvar.html and And "sprintf("%02x", ord($var))" portion can be seen in this BinToHexView function http://php.net/manual/de/function.sprintf.php And Viktor Dukhovni used this in perl and attached a script file. [3] It is based on GreyCat's/Greg's Wiki: http://mywiki.wooledge.org/BashGuide http://bash.cumulonim.biz/ [4] PDPC supporter/user "tm604"/"tom" (in #perl at Freenode IRC) contributed perl codes related to calculating SHA-256, i added SHA-512 into it based on below site, and added other codes. https://metacpan.org/module/Digest::SHA Received from Viktor Dukhovni, on 2013-06-17 1:16 AM: > On Sun, Jun 16, 2013 at 11:03:48PM -0700, Bry8 Star wrote: >=20 >> how you can make direction easy for such vast groups of users. >=20 > A fair question. >=20 > I won't attempt to explain how to operate a DNSSEC signed zone > here, sadly this is still rather complex, since DNSSEC signed zones > need to be frequently and automatically resigned, and rotating the > KSK DS records in registries is harder still. If that's part of > your question, perhaps someone else is willing to tackle this rather > weighty topic, maybe on a DNSSEC list, if not here. >=20 > So let's assume that you've somehow crossed the hurdle of implementing > DNSSEC. >=20 > Let's also assume that you have some TLS-enabled service on TCP > port 12345 of host mumble.example.com and you want to publish DANE > TLSA records for this host. >=20 > The certificate association portion of a TLSA record contains binary > data that is usually presented in hexadecimal form for ease of > entry into zone files. The underlying binary data is either: >=20 > - A complete X.509 certificate in DER form (IN TLSA X 0 0 ...) > - A complete SPKI public-key in DER form (IN TLSA X 1 0 ...) > - A binary SHA-256 digest of one of the above (IN TLSA X Y 1 ...) > - A binary SHA-512 digest of one of the above (IN TLSA X Y 2 ...) >=20 > where "X" is the certificate usage. >=20 > When X is 0 or 2, the certificate association publishes a property > of a root or intermediate CA that (possibly through a chain of > intermediate CAs) ultimately issued the certificate of mumble.example.c= om. >=20 > When X is 1 or 3, the certificate association publishes a property > of the actual certificate whose public key is the public key of > mumble.example.com. >=20 > Whether you choose X =3D 0, 1, 2 or 3 is >=20 > - part operational considerations (who updates the DNS in your > organization, how often are server keys rotated, ...). Do > you optimize for robustness in the face of buggy client > implementations (simpler is better, and nothing is simpler > than X=3D3) or robustness in the face of lazy operators who > neglect to coordinate key rollover with DNS updates (X=3D0 or > 2 requires less work for the DNS operator). >=20 > - part application considerations, is the client pre-configured with > a suitable list of trusted CAs? Does the client have a secure way > to determine the service hostname (mumble.example.com), ... >=20 > - part security considerations? Which risks do you want to mitigate?= > DNSSEC zone signingkey compromises? Rogue public CAs? Server > key compromises? Do your clients consult CA revocation lists? > How often are these lists updated? How quickly can you publish > a revocation? ... >=20 > - part PKI politics. Does your organization fervently believe in eith= er > of the two PKI models (public CAs or DANE) and distance itself from= the > other? >=20 > Keep in mind that when keys change some clients will have older DNSSEC > records in their caches, so you may need to publish both the old and th= e > new association values when transitioning between and old and a new > certificate (be it a CA or a server certificate). DANE validation will= > work provided at least association matches. >=20 --------------070007060609050104010202 Content-Type: text/plain; charset=windows-1252; name="der2tlsa_pl" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="der2tlsa_pl" #!/usr/bin/perl # - - - - - - - - - - - - - - - - - - - - - - - - - - - - - # der2tlsa.pl # Author: Bright Star. (bry 8 st ar \@a.t\@ ya hoo d.o.t c om) # Author: tom/tm604. #=20 # SSL DER to TLSA CAD. # Change filename from "der2tlsa_pl" into "der2tlsa.pl" # before using. # To create a DER SSL/TLS cert file, # from a PEM or CRT file: # $ openssl x509 -in SSL-cert-file.pub.pem \ # -outform DER \ # -out SSL-cert-file.pub.der # Do not specify .crt, .pem file in commandline, # then it will show wrong codes. # To Convert DER content into equivalent=20 # TLSA Hexadecimal, and Create Hash of DER content: use Digest::SHA qw(sha256_hex sha512_hex); $rFN =3D ""; $rFN =3D $ARGV[0]; $m =3D " v1.0.201307030000. Bright Star \(bry " =2E"8 st ar \@a.t\@ ya hoo d.o.t c om\)\n"; die "SSL DER 2 TLSA CAD\: Specify a DER " =2E"based SSL filename in commandline.\n$m"=20 unless $rFN; printf "SSL DER 2 TLSA CAD:\n$m\nAttempting " =2E"to load \"$rFN\" file..."; open my $rFH, "<", $rFN or die=20 " Failed To Load $rFN File For Reading: $!\n";=20 { local $/; $der =3D <$rFH>; } close $rFH || warn=20 " Failed To Close $rFN File: $!\n"; printf " loading done.\n\n"; $full_cad =3D $der; $full_cad =3D~ s/(.)/sprintf("%02X", ord($1))/egs; $m =3D "\; a DNSSEC DANE/TLSA DNS record syntax\:\n" =2E"\; _port._proto.[host.]domain.TLD. [TTL] IN TLSA u s m C_A_D\n\n" =2E"\; Replace below \"u\", based on SSL/TLS certificate\'s \"usage\"\n" =2E"\; field, mentioned in\:\n" =2E"\; https\://tools\.ietf\.org/html/rfc6698\n" =2E"\; Brief/Summary: \"u\" can be replaced with any one of these numbers= \: 0, 1,\n" =2E"\; 2, 3. \"s\" can be 0 or 1, \"m\" can be 0, 1 or 2. A purchased SSL= cert \(EE\)\n" =2E"\; from a known \(Public\) CA company which has their RootCA SSL cert= already\n" =2E"\; pre-included in popular web-browsers, client-software, operating s= ystems,\n" =2E"\; etc then declare such EE cert via \"TLSA 1 s m\" type of TLSA DNS = record.\n" =2E"\; If domain-owner created own self-signed \(EE\) srvr SSL cert, then= either\n" =2E"\; declare via \"TLSA 1 s m\", or, via \"TLSA 3 s m\". When \"u\" is = 0, 1 or 2,\n" =2E"\; then DANE supported clients check Server SSL cert\'s entire \(PKIX= \) chain.\n" =2E"\; When \"u\" is 3, then clients skip checking chain. If you want to = declare\n" =2E"\; \(Public\) CA company\'s RootCA SSL cert, then use \"TLSA 0 s m\".= To declare\n" =2E"\; a Root-CA SSL cert which you yourself created, or when a Root-CA S= SL cert\n" =2E"\; is by-default not pre-included in web-browsers or client software = or OS,\n" =2E"\; then use \"TLSA 2 s m\". When s=3D0 then C_A_D is based on Full SS= L/TLS cert,\n" =2E"\; when s=3D1 then C_A_D is based ONLY on SPKI \(SubjectPublicKeyInfo= \) portion\n" =2E"\; of a SSL cert. When m=3D0, then C_A_D has Full data of what is men= tioned in\n" =2E"\; \"s\", when m=3D1 then C_A_D is based on SHA-256 hash code of \"s\= ", when m=3D2\n" =2E"\; then C_A_D is based on SHA-512. C_A_D =3D Certificate Association = Data. CAD\n" =2E"\; =3D C_A_D. TTL =3D Time To Live, in seconds. proto=3Dprotocol. TLD= =3D Top Level\n" =2E"\; Domain.\n\n" =2E"\; A Full C_A_D hexadecimal code of Full SSL cert\:\n\n" =2E"_443._tcp.www\.example\.com. 900 IN " =2E"TLSA u 0 0 $full_cad\n\n"; my $sha =3D Digest::SHA->new(256); $sha->addfile($rFN, "b"); $sha256 =3D uc $sha->hexdigest; $m .=3D "\; SHA-256 based C_A_D of Full SSL cert\:\n\n" =2E"_443._tcp.www\.example\.com. 900 IN " =2E"TLSA u 0 1 $sha256\n\n"; $sha =3D Digest::SHA->reset(512); $sha->addfile($rFN, "b"); $sha512 =3D uc $sha->hexdigest; $m .=3D "\; SHA-512 based C_A_D of Full SSL cert\:\n\n" =2E"_443._tcp.www\.example\.com. 900 IN " =2E"TLSA u 0 2 $sha512\n\n"; printf "$m"; $wFN =3D $rFN . ".cad.tlsa"; printf "Attempting to create \(or over-write\) " =2E"\"$wFN\"..."; open my $wFH, ">", $wFN or die=20 " Could Not Create \(or OverWrite\) $wFN File " =2E"For Writing: $!\n";=20 { print $wFH "$m"; } close($wFH) || warn=20 " Failed To Close $wFN File: $!\n";=20 printf " file created, info saved.\n"; # - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------070007060609050104010202-- ------enig2TNWOPCKTKPKCIGEASDKC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJR2gMfAAoJEID2ikYfWSP6EZ8P/ja4jwZznM1Sh0zDamxetH1C oXojv9oocQdLgEU2u1nie2bomQVEy4rBiyj/so1+vWFXAUeBAcU+ovCoZUNXGsLr gV7LDA25wk70V3F5505RxNgqRN+ihc8pG9ixPydhO78ph0B3I9r/iiubs31BUPCK kFVApDXB1u67KjqwHd7mpz2iKmz5AjFLavtZULKF+BFZrH/dnvpfSPMOG3cRmkyd FuJKFxtRn3Kdd4EcslBH1qlEhnT8OhxYPfHyr/f4YowN349QWEXBN33V8P4BZ686 Epv3g7YiLqwuynxA5S1AVBEfGReTzXxZP2PKJtZxQQ1rNfYisAcqVGybFirZ8Iog DVE80F01Xc/hziXJj+tGw2yVoyRbqI75aJ3+tJx6/vmH8hNJbCdoJPbRBaqSU+fb 3UpPtQL2eRAzuiSelhwYeqjjXZXXg7GyUFYf34QiEWqcvNZFj1lxzhXDceu2OTt8 ZNwASdYi/xrIolKKhG5VlRGTvmsMrd63QTNvnqek2ePVGTSoJhrXXrJzG27yAZa6 W9SH1Jm/AInf4wpmZd3z+a/d/vM/yTi1j+06k5yzTFPIITJ++7ieLKoTO8LOwkZL Z9nprZ9CKhPlWunEZQ0JNW6rQwPSDKgZqvEPMVP2X31Utfg+gq01m/NShwcNjqFn TxyOYH6t9RMfOPu5Ck1X =8Jbr -----END PGP SIGNATURE----- ------enig2TNWOPCKTKPKCIGEASDKC-- From paul@nohats.ca Mon Jul 8 08:12:09 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFB1321F9CC5 for ; Mon, 8 Jul 2013 08:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xjpJhIVy9UYn for ; Mon, 8 Jul 2013 08:12:03 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 0D52521F9B06 for ; Mon, 8 Jul 2013 08:12:03 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3bpqrX1j6hz27H; Mon, 8 Jul 2013 11:11:56 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id bZ-X6qWR5Llv; Mon, 8 Jul 2013 11:11:55 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Mon, 8 Jul 2013 11:11:55 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 840318179B; Mon, 8 Jul 2013 11:11:56 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 438808179A; Mon, 8 Jul 2013 11:11:56 -0400 (EDT) Date: Mon, 8 Jul 2013 11:11:56 -0400 (EDT) From: Paul Wouters To: Paul Hoffman In-Reply-To: Message-ID: References: User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dane WG list Subject: [dane] Minor issues with draft-hoffman-dane-smime X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 08 Jul 2013 15:12:09 -0000 I support this document, only have minor issues: Section 3 has an example that uses capital letters for the LHS of the new DNS record. As DNS is case insensitive, I don't like that usage. Section 4 talks about usage types and selector types, but no where is there text or a reference to what these are. I assume it means the usage and types from TLSA from RFC 6698. Section 5.1 states "TLSA RRtype" instead of "SMIMEA RRtype" Paul From internet-drafts@ietf.org Tue Jul 9 13:27:29 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27B6521F99B8; Tue, 9 Jul 2013 13:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UInKG5+YrPdI; Tue, 9 Jul 2013 13:27:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 57D5F21F9DEE; Tue, 9 Jul 2013 13:27:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130709202720.23770.17360.idtracker@ietfa.amsl.com> Date: Tue, 09 Jul 2013 13:27:20 -0700 Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-smime-02.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 20:27:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS-based Authentication of Named Entitie= s Working Group of the IETF. Title : Using Secure DNS to Associate Certificates with Domain N= ames For S/MIME Author(s) : Paul Hoffman Jakob Schlyter Filename : draft-ietf-dane-smime-02.txt Pages : 7 Date : 2013-07-09 Abstract: This document describes how to use secure DNS to associate an S/MIME user's certificate with the intended domain name, similar to the way that DANE (RFC 6698) does for TLS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-smime There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dane-smime-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dane-smime-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From paul.hoffman@vpnc.org Tue Jul 9 13:30:19 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E54E21F99A6 for ; Tue, 9 Jul 2013 13:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a14oX5jV-z8l for ; Tue, 9 Jul 2013 13:30:18 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id C795721F9993 for ; Tue, 9 Jul 2013 13:30:18 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-228.dsl.dynamic.sonic.net [50.1.98.228]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r69KUGdk001914 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 9 Jul 2013 13:30:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <20130709202720.23770.17360.idtracker@ietfa.amsl.com> Date: Tue, 9 Jul 2013 13:30:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130709202720.23770.17360.idtracker@ietfa.amsl.com> To: "dane@ietf.org list" X-Mailer: Apple Mail (2.1508) Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-02.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 20:30:19 -0000 As y'all can see from the diffs, this is just a small editorial bump to = keep the draft up-to-date. Jakob and I note that there was no = substantial discussion of Scott Rose's message about the earlier draft = (see ). = We would love to hear more about that, particularly now that people are = starting to pay more attention to DANE's use in email. --Paul Hoffman= From viktor1dane@dukhovni.org Wed Jul 10 08:17:57 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 568EF21F9C6E for ; Wed, 10 Jul 2013 08:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmzowNEUYYXL for ; Wed, 10 Jul 2013 08:17:53 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 0DCF021F9AD8 for ; Wed, 10 Jul 2013 08:17:48 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id C64D42AAB3C; Wed, 10 Jul 2013 15:17:44 +0000 (UTC) Date: Wed, 10 Jul 2013 15:17:44 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130710151744.GY29420@mournblade.imrryr.org> References: <20130709202720.23770.17360.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-02.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 15:17:57 -0000 On Tue, Jul 09, 2013 at 01:30:15PM -0700, Paul Hoffman wrote: > As y'all can see from the diffs, this is just a small editorial > bump to keep the draft up-to-date. Jakob and I note that there was > no substantial discussion of Scott Rose's message about the earlier > draft (see ). > We would love to hear more about that, particularly now that people > are starting to pay more attention to DANE's use in email. Grammar nit: "In order for the S/MIME receiver to authenticate that a message is from the sender whom is identified in the message," I am pretty sure the sender is in the nominative case in this sentence, and "whom" should be "who". http://grammar.quickanddirtytips.com/who-versus-whom.aspx As to the substance of the draft, there is no discussion of wildcard mechanisms. With email user certificates, I'd expect most domains to publish an associated TA certificate that is common to all users (either usage 0 or 2). I guess the draft implicitly supports this via: *._smimecert.example.com IN SMIMEA 2 1 1 ... This is perhaps worth some explicit discussion. And now that we see the dreaded "2 1 1", the same question arises as with TLSA RRs, do SMIME senders generally include the (root) TA certificate in the pkcs7 certificate chain pkcs7? Some guidance for sending MUAs may be appropriate (start including root TA certs in pkcs7 SMIME blobs, probably unconditionally). Unlike TLS sessions, SMIME messages are not transient. Thus an SMIME message sent last year and verified by last year's certificate, may need to be re-validated this year with the domain's TA or user's EE certificate updated. How is TA/EE certificate rollover to be handled? Because SMIME is not like TLS (data at rest vs. data in motion), it is not clear that a simple analogy to TLSA (mere refinement of the record type and query labels) is sufficient. -- Viktor. From paul.hoffman@vpnc.org Wed Jul 10 09:23:20 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7B7E21F9F1E for ; Wed, 10 Jul 2013 09:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ly+g7c7uFod5 for ; Wed, 10 Jul 2013 09:23:19 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 98D7721F9E95 for ; Wed, 10 Jul 2013 09:23:12 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-228.dsl.dynamic.sonic.net [50.1.98.228]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r6AGNBdo042048 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 10 Jul 2013 09:23:11 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <20130710151744.GY29420@mournblade.imrryr.org> Date: Wed, 10 Jul 2013 09:23:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <052057FB-18AC-4C1A-8386-D25B4E5EC7DD@vpnc.org> References: <20130709202720.23770.17360.idtracker@ietfa.amsl.com> <20130710151744.GY29420@mournblade.imrryr.org> To: dane@ietf.org X-Mailer: Apple Mail (2.1508) Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-02.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 16:23:20 -0000 On Jul 10, 2013, at 8:17 AM, Viktor Dukhovni = wrote: > Grammar nit: Fixed > As to the substance of the draft, there is no discussion of wildcard > mechanisms. With email user certificates, I'd expect most domains > to publish an associated TA certificate that is common to all users > (either usage 0 or 2). I guess the draft implicitly supports this = via: >=20 > *._smimecert.example.com IN SMIMEA 2 1 1 ... >=20 > This is perhaps worth some explicit discussion. Sounds fine. > And now that we see the dreaded "2 1 1", the same question arises > as with TLSA RRs, do SMIME senders generally include the (root) TA > certificate in the pkcs7 certificate chain pkcs7? "Generally" is a terrible word to use here. :-) We do not have any = useful usage data on S/MIME to make an assertion one way or the other. > Some guidance > for sending MUAs may be appropriate (start including root TA certs > in pkcs7 SMIME blobs, probably unconditionally). Disagree. Unless we know what they do currently without DANE, any = guidance we give could easily contradict that. > Unlike TLS sessions, SMIME messages are not transient. Thus an > SMIME message sent last year and verified by last year's certificate, > may need to be re-validated this year with the domain's TA or user's > EE certificate updated. How is TA/EE certificate rollover to be > handled? Indeterminately. At least we're sure of that, from discussions 15 years = ago. > Because SMIME is not like TLS (data at rest vs. data in motion), > it is not clear that a simple analogy to TLSA (mere refinement of > the record type and query labels) is sufficient. Having a specific list of differences would be useful for Jakob and I to = determine where we need to put in more words. --Paul Hoffman= From oej@edvina.net Wed Jul 10 11:20:53 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADD9721F9A35; Wed, 10 Jul 2013 11:20:53 -0700 (PDT) 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_SE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVSIS4aG1z8f; Wed, 10 Jul 2013 11:20:49 -0700 (PDT) Received: from aero.webway.se (aero.webway.se [212.3.14.206]) by ietfa.amsl.com (Postfix) with ESMTP id DC81321F9A7E; Wed, 10 Jul 2013 11:20:40 -0700 (PDT) Received: from aero.webway.se (localhost [127.0.0.1]) by aero.webway.se (Postfix) with ESMTP id 6E115AA1700; Wed, 10 Jul 2013 20:20:38 +0200 (CEST) Received: from 88.2.166.170 (SquirrelMail authenticated user p02) by aero.webway.se with HTTP; Wed, 10 Jul 2013 20:20:38 +0200 Message-ID: <9732162f6a7183a96ce9d46630a35c78.squirrel@aero.webway.se> Date: Wed, 10 Jul 2013 20:20:38 +0200 From: "Olle E. Johansson" To: dispatch@ietf.org, dane@ietf.org User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: [dane] [Fwd: New Version Notification for draft-johansson-dane-sip-00.txt] X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 18:20:53 -0000 Hi! I've submitted a first version of the draft describing a possible way to use DANE in SIP. I don't really know which working group - dispatch or DANE - that will handle this, so I cross-post at this time to get as much feedback as possible. I will add more examples, but wanted to get the first draft of the draft out now. Greetings from a sunny Malaga in Spain! /Olle -------------------------------------------------------------------------- A new version of I-D, draft-johansson-dane-sip-00.txt has been successfully submitted by Olle E. Johansson and posted to the IETF repository. Filename: draft-johansson-dane-sip Revision: 00 Title: TLS sessions in SIP using DNS-based Authentication of Named Entities (DANE) TLSA records Creation date: 2013-07-10 Group: Individual Submission Number of pages: 9 URL: http://www.ietf.org/internet-drafts/draft-johansson-dane-sip-00.txt Status: http://datatracker.ietf.org/doc/draft-johansson-dane-sip Htmlized: http://tools.ietf.org/html/draft-johansson-dane-sip-00 Abstract: Use of TLS in the SIP protocol is defined in multiple documents, starting with RFC 3261. The actual verification that happens when setting up a SIP TLS connection to a SIP server based on a SIP URI is described in detail in RFC 5922 - SIP Domain Certificates. In this document, an alternative method is defined, using DNS-Based Authentication of Named Entities (DANE). By looking up TLSA DNS records and using DNSsec protection of the required queries, including lookups for NAPTR and SRV records, a SIP Client can verify the identity of the TLS SIP server in a different way, matching on the SRV host name in the X.509 PKIX certificate instead of the SIP domain. This provides more scalability in hosting solutions and make it easier to use standard CA certificates (if needed at all). This document updates RFC 5922. The IETF Secretariat From viktor1dane@dukhovni.org Wed Jul 10 13:37:11 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B59F21F89C3 for ; Wed, 10 Jul 2013 13:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5duEQgv+oRs for ; Wed, 10 Jul 2013 13:37:06 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id E959221F9EE2 for ; Wed, 10 Jul 2013 13:37:05 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id DD61C2AAC60; Wed, 10 Jul 2013 20:36:59 +0000 (UTC) Date: Wed, 10 Jul 2013 20:36:59 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130710203659.GB29420@mournblade.imrryr.org> References: <20130709202720.23770.17360.idtracker@ietfa.amsl.com> <20130710151744.GY29420@mournblade.imrryr.org> <052057FB-18AC-4C1A-8386-D25B4E5EC7DD@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <052057FB-18AC-4C1A-8386-D25B4E5EC7DD@vpnc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-02.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 20:37:11 -0000 On Wed, Jul 10, 2013 at 09:23:10AM -0700, Paul Hoffman wrote: > > And now that we see the dreaded "2 1 1", the same question arises > > as with TLSA RRs, do SMIME senders generally include the (root) TA > > certificate in the pkcs7 certificate chain pkcs7? > > "Generally" is a terrible word to use here. :-) We do not have > any useful usage data on S/MIME to make an assertion one way or > the other. There is some support for S/MIME in various mainsteam MUAs, Microsoft's Outlook, Apple's Mail.app and Thunderbird come to mind. It may be reasonable to check how these decide which certificates to include in a signed message. There are also commercial gateway-to-gateway and gateway-to-user SMIME appliances, whose behaviour may be useful to know. Alternatively, the draft could simply encourage all signers to include complete chains in their signatures, and to not "optimize out" self-signed root issuers. > > Some guidance > > for sending MUAs may be appropriate (start including root TA certs > > in pkcs7 SMIME blobs, probably unconditionally). > > Disagree. Unless we know what they do currently without DANE, > any guidance we give could easily contradict that. Well, it is likely necessary to contradict any advice to omit root CAs, and otherwise we'd agree with the existing practice, so where's the harm? > > Unlike TLS sessions, SMIME messages are not transient. Thus an > > SMIME message sent last year and verified by last year's certificate, > > may need to be re-validated this year with the domain's TA or user's > > EE certificate updated. How is TA/EE certificate rollover to be > > handled? > > Indeterminately. At least we're sure of that, from discussions 15 years ago. That's much less of a problem with the public CA PKI, because root CA lifetimes are so long. With DANE TA or EE certificates, the problem is liable to become far more acute. If there is no mechanism to deal with retired, but valid at time of message receipt, certificates, validating old messages becomes a rather difficult problem. So SMIMEA would then provide a mechanism for retrieving the current public key for sending new encrypted messages to a recipient, and for verifying messages at time of receipt, but would not be suitable for later re-verification. If there is deliberately no mechanism to publish old keys, valid only for verifying old messages, there is an implicit burden on the MUA to either cache the verification status of certificates (and validity intervals) associated with received messages, or to cache per-message verification status. > > Because SMIME is not like TLS (data at rest vs. data in motion), > > it is not clear that a simple analogy to TLSA (mere refinement of > > the record type and query labels) is sufficient. > > Having a specific list of differences would be useful for Jakob > and I to determine where we need to put in more words. As with TLS, SMIME supports initiators (message senders) who need the peer's current public key. Unlike TLS SMIME also supports arbitrarily delayed in time acceptors (message readers) who need to be able to read an SMIME message and determine whether it was valid at the time it was received. Delayed sender signature verification is a rather different problem, and if it is explicitly out of scope for SMIMEA, then perhaps it is worth mentioning that mechanisms for this are to sought elsewhere, unless SMIME standards already adequately cover this problem. -- Viktor. From 35nlv6@nottheoilrig.com Sat Jul 13 11:14:33 2013 Return-Path: <35nlv6@nottheoilrig.com> X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F7921F9DA1 for ; Sat, 13 Jul 2013 11:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0JFKSSEHwRvm for ; Sat, 13 Jul 2013 11:14:29 -0700 (PDT) Received: from mail.nottheoilrig.com (mail.nottheoilrig.com [50.16.249.74]) by ietfa.amsl.com (Postfix) with ESMTP id 4C2E521F9C0B for ; Sat, 13 Jul 2013 11:14:29 -0700 (PDT) Received: from mail.nottheoilrig.com (localhost [127.0.0.1]) by mail.nottheoilrig.com (Postfix) with ESMTP id 1F05040BBB for ; Sat, 13 Jul 2013 18:14:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nottheoilrig.com; s=mail; t=1373739264; bh=GIFUj6zCSKukYIciUHFyB3Iq2zB3fkuU0I6xigFTjM4=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=I13Fgi3cIRNwKo7Vc3tSBT//OydZ91nsxSCkvLG217R5T1GwfcpvsVpxCqRigg9FT vF7yKCJJ5UIfBZurXNZR5zejLBYkV5trqIms2BAIKjdjPdqN6iv8cPRVa2pduq3A0y 4drSgmj5ENZv5QvPApkigK3cGEC71z0qKhh7vNdU= Received: from [192.168.0.11] (S0106c8fb26402908.ek.shawcable.net [24.66.136.12]) by mail.nottheoilrig.com (Postfix) with ESMTPSA for ; Sat, 13 Jul 2013 18:14:23 +0000 (UTC) Message-ID: <51E19900.9020306@nottheoilrig.com> Date: Sat, 13 Jul 2013 11:14:24 -0700 From: Jack Bates <35nlv6@nottheoilrig.com> User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: dane@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 13 Jul 2013 11:26:33 -0700 Subject: [dane] List of resources? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 13 Jul 2013 18:16:00 -0000 Hello, I've been searching for tools that implement DANE and instructions for generating TLSA records and I wonder if somethere there is a list of DANE resources? In particular, does there exist a website that will verify TLSA records, similar to: http://dnssec-debugger.verisignlabs.com/ Here is the list of resources that my searching turned up: Specs: o RFC 6698: http://tools.ietf.org/html/rfc6698 o Specs covering specific applications of DANE: http://tools.ietf.org/wg/dane/ Demo sites (sites that implement server side of DANE): o http://www.internetsociety.org/deploy360/resources/dane-test-sites/ Tools: o SWEDE: https://github.com/pieterlexis/swede o hash-slinger: http://people.redhat.com/pwouters/hash-slinger/ o tlsa_rdata: https://github.com/shuque/tlsa_rdata o DANE Patrol: https://labs.nic.cz/page/1207/dane-patrol/ o Extended DNSSEC Validator: https://os3sec.org/ o DNSSEC/TLSA Validator: http://people.redhat.com/pwouters/ Talks: o Linux Security Summit 2012: http://people.redhat.com/pwouters/LinuxCon2012-DNSSEC.pdf Resources: o Walking Through Setting Up A TLSA Record for DNSSEC/DANE: http://blog.huque.com/2012/10/dnssec-and-certificates.html o The DANE Protocol: http://www.internetsociety.org/deploy360/resources/dane/ o Posts tagged "DANE": http://www.internetsociety.org/deploy360/blog/tag/dane/ o IETF Journal October 2011: http://www.internetsociety.org/articles/dane-taking-tls-authentication-next-level-using-dnssec o Mozilla: https://wiki.mozilla.org/Security/DNSSEC-TLS-details o Postfix: http://www.postfix.org/TLS_README.html o Wikipedia: http://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities Notes: o RFC 6698 section 8 Security Considerations: When it says "A rogue DNS administrator ... That administrator could probably get a certificate issued by some CA anyway, so this is not an additional threat." it means that under DANE a person who controls the DNS controls the TLS security (because they can change the certificate) but in reality this is already the case because many CAs use control of MX record to establish ownership of a domain and issue a valid certificate. From paul.hoffman@vpnc.org Sun Jul 14 08:01:21 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00EF221F8FEB for ; Sun, 14 Jul 2013 08:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.292 X-Spam-Level: X-Spam-Status: No, score=-102.292 tagged_above=-999 required=5 tests=[AWL=-0.293, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rjHMxZgIq83G for ; Sun, 14 Jul 2013 08:01:20 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 716F121F8D73 for ; Sun, 14 Jul 2013 08:01:20 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-228.dsl.dynamic.sonic.net [50.1.98.228]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r6EF1H1o004876 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 14 Jul 2013 08:01:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-228.dsl.dynamic.sonic.net [50.1.98.228] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <20130710203659.GB29420@mournblade.imrryr.org> Date: Sun, 14 Jul 2013 08:01:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130709202720.23770.17360.idtracker@ietfa.amsl.com> <20130710151744.GY29420@mournblade.imrryr.org> <052057FB-18AC-4C1A-8386-D25B4E5EC7DD@vpnc.org> <20130710203659.GB29420@mournblade.imrryr.org> To: dane@ietf.org X-Mailer: Apple Mail (2.1508) Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-02.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, 14 Jul 2013 15:01:21 -0000 On Jul 10, 2013, at 1:36 PM, Viktor Dukhovni = wrote: > On Wed, Jul 10, 2013 at 09:23:10AM -0700, Paul Hoffman wrote: >=20 >>> And now that we see the dreaded "2 1 1", the same question arises >>> as with TLSA RRs, do SMIME senders generally include the (root) TA >>> certificate in the pkcs7 certificate chain pkcs7? >>=20 >> "Generally" is a terrible word to use here. :-) We do not have >> any useful usage data on S/MIME to make an assertion one way or >> the other. >=20 > There is some support for S/MIME in various mainsteam MUAs, > Microsoft's Outlook, Apple's Mail.app and Thunderbird come to mind. > It may be reasonable to check how these decide which certificates > to include in a signed message. There are also commercial > gateway-to-gateway and gateway-to-user SMIME appliances, whose > behaviour may be useful to know. All of that can be found out, but from earlier viewing of the data, the = results will be wildly different. > Alternatively, the draft could simply encourage all signers to > include complete chains in their signatures, and to not "optimize > out" self-signed root issuers. It is probably inappropriate for a draft from this WG to try to affect = the S/MIME protocol that has been deployed for over a decade. >>> Some guidance >>> for sending MUAs may be appropriate (start including root TA certs >>> in pkcs7 SMIME blobs, probably unconditionally). >>=20 >> Disagree. Unless we know what they do currently without DANE, >> any guidance we give could easily contradict that. >=20 > Well, it is likely necessary to contradict any advice to omit root > CAs, and otherwise we'd agree with the existing practice, so where's > the harm? The harm is in having two IETF standards on the same topic that = disagree, particularly because an S/MIME implementer might not care in = the least about DANE. > If there is no mechanism to deal with retired, but valid at time > of message receipt, certificates, validating old messages becomes > a rather difficult problem. Yes. > So SMIMEA would then provide a mechanism for retrieving the current > public key for sending new encrypted messages to a recipient, and > for verifying messages at time of receipt, but would not be suitable > for later re-verification. The same is true for many other parts of S/MIME. For example, a trust = anchor might have a long lifetime, but intermediate CAs might be short = for very good reasons. > If there is deliberately no mechanism to publish old keys, valid > only for verifying old messages, there is an implicit burden on > the MUA to either cache the verification status of certificates > (and validity intervals) associated with received messages, or > to cache per-message verification status. Yes. >>> Because SMIME is not like TLS (data at rest vs. data in motion), >>> it is not clear that a simple analogy to TLSA (mere refinement of >>> the record type and query labels) is sufficient. >>=20 >> Having a specific list of differences would be useful for Jakob >> and I to determine where we need to put in more words. >=20 > As with TLS, SMIME supports initiators (message senders) who need > the peer's current public key. Unlike TLS SMIME also supports > arbitrarily delayed in time acceptors (message readers) who need > to be able to read an SMIME message and determine whether it was > valid at the time it was received. >=20 > Delayed sender signature verification is a rather different problem, > and if it is explicitly out of scope for SMIMEA, then perhaps it is > worth mentioning that mechanisms for this are to sought elsewhere, > unless SMIME standards already adequately cover this problem. Just the opposite: the S/MIME standards do not. There was some work from = the LTANS WG in this area; see RFC 4810 and 4998. It has mostly been = ignored, I believe. --Paul Hoffman= From dan-ietf@danyork.org Mon Jul 15 00:44:08 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A11AA21F84AA for ; Mon, 15 Jul 2013 00:44:04 -0700 (PDT) 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=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yrmhTAjnt3s9 for ; Mon, 15 Jul 2013 00:43:57 -0700 (PDT) Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) by ietfa.amsl.com (Postfix) with ESMTP id 5EBF721F93D4 for ; Mon, 15 Jul 2013 00:42:16 -0700 (PDT) Received: by mail-vc0-f177.google.com with SMTP id hv10so9064016vcb.36 for ; Mon, 15 Jul 2013 00:42:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=w7rXjhIU0jbL4nYxGdMB5BZFsTXi4IBiAdGyhVAx67U=; b=P+zrVS/CpV1LXyXvcMxZ6CNNBDc7DTp+fm8BTit0XBkZ8fkerbL6pnptLBN3DsuMzF TaVctAdk4KNBCebEk6tGkI1ml1M8qlU9cdxU6xQgSetP6mJA/AGjenvxUMfEHDIoin6t lCmEGUk/JiqFTAiDhf5BEWuwvJdqSGQFRH1dp3pDz94lc+b4j136OMDeCR9TjMfxgmFI M37BNEedHWqMaicxPorxlIiwLPbKhT44OhWaiFLwiKQ7nqFhCKUryjARlTO+dF2xVkIQ Inz7fthZNJya4WFOM7LWwhAzurX1x8qWjoX7cpAA3eueyqMqgIm+mQs6ACGsAXzoV0Lu 8bJw== MIME-Version: 1.0 X-Received: by 10.52.119.179 with SMTP id kv19mr23555959vdb.76.1373874133943; Mon, 15 Jul 2013 00:42:13 -0700 (PDT) Received: by 10.58.217.101 with HTTP; Mon, 15 Jul 2013 00:42:13 -0700 (PDT) X-Originating-IP: [2620:f:8000:210:95b3:879e:5048:f847] In-Reply-To: <51E19900.9020306@nottheoilrig.com> References: <51E19900.9020306@nottheoilrig.com> Date: Mon, 15 Jul 2013 09:42:13 +0200 Message-ID: From: Dan York To: Jack Bates <35nlv6@nottheoilrig.com> Content-Type: multipart/alternative; boundary=047d7bf0d902b86f0c04e187ff5b X-Gm-Message-State: ALoCoQnMYX5en44PUPWHPY4707kSpz5IaanSa4suXaPN5q08Oq8FuCIItS3qXu6/cFXn8QZjO67o Cc: dane@ietf.org Subject: Re: [dane] List of resources? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 Jul 2013 07:44:09 -0000 --047d7bf0d902b86f0c04e187ff5b Content-Type: text/plain; charset=ISO-8859-1 Jack, On Sat, Jul 13, 2013 at 8:14 PM, Jack Bates <35nlv6@nottheoilrig.com> wrote: I've been searching for tools that implement DANE and instructions for > generating TLSA records and I wonder if somethere there is a list of DANE > resources? That is exactly what I have been aiming to do with a page that you mention later in your list of resources: http://www.internetsociety.**org/deploy360/resources/dane/ Having said that, I haven't updated the page in a bit and obviously need to do so in light of some of the additional tools you pointed out in your search results. I will do so shortly, as I am giving a brief DANE tutorial at ICANN 47 during the DNSSEC Workshop on this coming Wednesday, July 17. I would welcome any suggestions for more items to add to that page. My point of doing so is to help enable more people to get out there deploying DANE. > In particular, does there exist a website that will verify TLSA records, > similar to: > I am not away of any sites that verify TLSA records yet. Regards, Dan -- Dan York, dan-ietf@danyork.org http://danyork.me http://twitter.com/danyork --047d7bf0d902b86f0c04e187ff5b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jack,

On Sat, Jul 13, 2013 at 8:14 PM, Ja= ck Bates <35nlv6@nottheoilrig.com> wrote:

I've been searching for tools that i= mplement DANE and instructions for generating TLSA records and I wonder if = somethere there is a list of DANE resources?

That is exactly what I have been aiming to do with a pa= ge that you mention later in your list of resources:

http://www.internetsociety.org/deploy360/resources/da= ne/

Having said that, I haven't updated the page in a b= it and obviously need to do so in light of some of the additional tools you= pointed out in your search results. =A0I will do so shortly, as I am givin= g a brief DANE tutorial at ICANN 47 during the DNSSEC Workshop on this comi= ng Wednesday, July 17.

I would welcome any suggestions for more items to add t= o that page. =A0My point of doing so is to help enable more people to get o= ut there deploying DANE.
=A0
In particular, does there exist a website that will verify TLSA records, si= milar to:

I am not away of any sites th= at verify TLSA records yet.

Regards,
Dan
=A0
--
= http://danyork.me =A0 <= a href=3D"http://twitter.com/danyork" target=3D"_blank">http://twitter.com/= danyork
--047d7bf0d902b86f0c04e187ff5b-- From Marco.Davids@sidn.nl Mon Jul 15 01:12:04 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED8621F8AAF for ; Mon, 15 Jul 2013 01:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.715 X-Spam-Level: X-Spam-Status: No, score=-0.715 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_EQ_IP_ADDR=1.119] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DT4-WaXOgvUk for ; Mon, 15 Jul 2013 01:11:48 -0700 (PDT) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) by ietfa.amsl.com (Postfix) with ESMTP id 55C8421F8653 for ; Mon, 15 Jul 2013 01:10:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn_nl; c=relaxed/relaxed; h=message-id:date:from:organization:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:openpgp:content-type:x-originating-ip; bh=vxTjntiNbY1abfBbP4QQTgtXJp1fLxKeRh3r7+wvLqs=; b=mQgW9RCtb42AIrkIRZotvuT75AfSZalex1UmkPE/TbBHyIF9A7cytDsoGkk8ukuME3QleZACmbEtSu1vAtYHlkW7/jzjmvhys3Pi8ILXz6ONks8Fwd5BvuiqdKAaFsb8F7hPMYd7rOaYmPq865sVRXu9Bn5G+OwBgZ63WIK5v/U= Received: from kahubcasn02.SIDN.local ([192.168.2.74]) by ede1-kamx.sidn.nl with ESMTP id r6F89wwk015182-r6F89wwm015182 (version=TLSv1 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Mon, 15 Jul 2013 10:09:59 +0200 Received: from KAHUBCAS1.SIDN.local (192.168.2.41) by kahubcasn02.SIDN.local (192.168.2.74) with Microsoft SMTP Server (TLS) id 14.2.328.9; Mon, 15 Jul 2013 10:09:58 +0200 Received: from [94.198.152.216] (94.198.152.216) by KAHUBCAS1.SIDN.local (192.168.2.41) with Microsoft SMTP Server (TLS) id 14.2.328.9; Mon, 15 Jul 2013 10:09:58 +0200 Message-ID: <51E3AE56.5030102@sidn.nl> Date: Mon, 15 Jul 2013 10:09:58 +0200 From: "Marco Davids (SIDN)" Organization: SIDN User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: References: <51E19900.9020306@nottheoilrig.com> In-Reply-To: X-Enigmail-Version: 1.5.1 OpenPGP: id=9F781B52 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070401070602080309050709" X-Originating-IP: [94.198.152.216] Subject: Re: [dane] List of resources? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 Jul 2013 08:12:04 -0000 --------------ms070401070602080309050709 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, On 07/15/13 09:42, Dan York wrote: >> In particular, does there exist a website that will verify TLSA >> records, similar to: > I am not away of any sites that verify TLSA records yet. Are you familiar with: http://check.sidnlabs.nl/dane/ ? Also, the example-utilities of 'LDNS' contains a good tool to generate TLSA records. In fact, the web-page above is based on that tool (ldns-dan= e). http://www.nlnetlabs.nl/projects/ldns/ Regards, -- Marco --------------ms070401070602080309050709 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMZjCC BiowggUSoAMCAQICAwa6NTANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTEzMDUzMTExMDk0MloXDTE0MDYwMjAzMjc1NFowRDEdMBsGA1UE AwwUbWFyY28uZGF2aWRzQHNpZG4ubmwxIzAhBgkqhkiG9w0BCQEWFG1hcmNvLmRhdmlkc0Bz aWRuLm5sMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyajTCa3uBAPAiQrrqCDe mzW5wvxaovW3h1/dCzfEuR/OZRYlgQg0dRsrGPMs+Wg2wwqPvvjsF/YQ2AeXxpzAIQVHywI5 zgZwptg0+Lv4UvFZFwHw5xdB2STvVIXFG7fuTyk5D0MkhhsO/MHjOmSucDzkH6CW/TgiBxkJ bSXIc+YOKZlI1E1q9V10rR2NW4VD27/AO71Va6sfA33qbY2MGvjR9UPB9bBjwsczeCulpNhE rIU7K4tWhgcd1DTUgz8P6pHw5bqRMzxfIQW3yHg5SnXjugCxLIfKBxIN7uXrqVmf0+haU3K/ tc6Wjl9JYjzXsdhempN1eRI3clyl6jS8YQIDAQABo4IC2jCCAtYwCQYDVR0TBAIwADALBgNV HQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBRn3ugN 5hkGkJ5A8hb1D6n4GcsppTAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HREEGDAWgRRtYXJjby5kYXZpZHNAc2lkbi5ubDCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYB BAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xp Y3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0 aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0Eg cG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21w bGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCug KaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcB AQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNz MS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRz L3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS8wDQYJKoZIhvcNAQELBQADggEBALqkjS+NnMxn/trjz71UHJEeiNJ7rbgNxk1+ RdhMw2TKiGocYa2Ql7TfCjgknCaakk7m54Spmr7AdbSVKVffmxQFzUaq5Or5HAMtqRfWJLh1 A94gOMPaRErdoRF0PLGPrwJPbxMAH4lTOIwpRqSVnUepG4pJKEBYFMXRWBW6nSs4/RJSscAP 70qoyX/MOPWFZjuxRU9d/gqQt4rNjf3Ojq+j3omI3oS/LgVUAyCdEsg7M0SEC5eG/kxLTCH9 bzY7A98/g55OENAsVQlP43GNr+hojOva9VDyeYQTktt0AtYheb29Za/Grw7cP9UAFzOdlsDA 5uL4TzfzDsk2BIwt2ZEwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9u IEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQG EwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg Q2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5 IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zP f1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG /FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvur yGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSy rrSMTGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIB qTAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssB XHx+ljVO8tS4UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUH AQEEWjBYMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYB BQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCeg JaAjhiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9j cmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBm MC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsG AQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqG SIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95 CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A +hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcL N5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/ O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI27 0g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z 77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/Q vVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8 BYtv9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV 27ioRKbj/cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jGCA90wggPZAgEBMIGU MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwa6NTAJBgUrDgMCGgUAoIIC HTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA3MTUwODA5 NThaMCMGCSqGSIb3DQEJBDEWBBQwWcsUt/v4xfoLS1x0wtZNiA8HiTBsBgkqhkiG9w0BCQ8x XzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3 EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBro1MIGnBgsq hkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0 ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMG ujUwDQYJKoZIhvcNAQEBBQAEggEAxRkEbXcnhlnRLGdxF2T1b1catB+/9oQjL16pbhlc9i8P +KHOkASUynS2tI66ez2oDZb7MwNxDFIhlppcPGD3offeHciRTrtT8Q7ELss0XhdwphMUa3Tk r1ymLrHjJRngzrUm1TMm5Ym6tpekh+Co3rp4epwRGq1Av48SXioMxZrjq8AemewPAZP6lpMt hPzAoK1Encz4b6x9wvPZIhyrqMWRvh9W8/rxtBF+zxJFEDX5U8HwtA0j4QEvvGvdPnRD023S sfzPSLHWcTjj7mTE4Kxb905sjtlVsYZixLku8C6T4BPLdpIl/Eh77wmBR/WHS0zoOI1mV+Ck n04MC6JgPgAAAAAAAA== --------------ms070401070602080309050709-- From paul@cypherpunks.ca Mon Jul 15 11:48:16 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1952A21E80C6 for ; Mon, 15 Jul 2013 11:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNxLO7Jlyj0p for ; Mon, 15 Jul 2013 11:48:09 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id F248A11E8105 for ; Mon, 15 Jul 2013 11:48:08 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3bvDJM33mTz5Cj; Mon, 15 Jul 2013 14:47:47 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id YwKwgL7H6hHp; Mon, 15 Jul 2013 14:47:46 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Mon, 15 Jul 2013 14:47:46 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id C27CF817DB; Mon, 15 Jul 2013 14:47:46 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B6167817D7; Mon, 15 Jul 2013 14:47:46 -0400 (EDT) Date: Mon, 15 Jul 2013 14:47:46 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Dan York In-Reply-To: Message-ID: References: <51E19900.9020306@nottheoilrig.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=ISO-8859-15 Content-Transfer-Encoding: 8BIT Cc: Jack Bates <35nlv6@nottheoilrig.com>, dane WG list Subject: Re: [dane] List of resources? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 Jul 2013 18:48:16 -0000 On Mon, 15 Jul 2013, Dan York wrote: > I would welcome any suggestions for more items to add to that page.  My point of doing so is to help enable more people to get out > there deploying DANE. >   > In particular, does there exist a website that will verify TLSA records, similar to: > > I am not away of any sites that verify TLSA records yet. You can check https://nohats.ca/ versus https://rogue.nohats.ca/ The latter one has an invalid TLSA record: _443._tcp.rogue.nohats.ca. 3446 IN TLSA 3 1 0 00000000000000000000000000000000000000000000000000000000 00000000 I'll see if I can throw up a website that uses hash-slinger to check TLSA records of other sites (after today's 24:00 UTC cut-off :) Paul From paul@cypherpunks.ca Mon Jul 15 11:50:05 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B623C11E817C for ; Mon, 15 Jul 2013 11:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8Ny888HCLi7 for ; Mon, 15 Jul 2013 11:50:00 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9479011E81B4 for ; Mon, 15 Jul 2013 11:50:00 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3bvDLs03Rnz5Df; Mon, 15 Jul 2013 14:49:57 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 0hbvHPL-AtC5; Mon, 15 Jul 2013 14:49:56 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Mon, 15 Jul 2013 14:49:56 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 3DED2817DB; Mon, 15 Jul 2013 14:49:57 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 31BC9817D7; Mon, 15 Jul 2013 14:49:57 -0400 (EDT) Date: Mon, 15 Jul 2013 14:49:57 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: "Marco Davids (SIDN)" In-Reply-To: <51E3AE56.5030102@sidn.nl> Message-ID: References: <51E19900.9020306@nottheoilrig.com> <51E3AE56.5030102@sidn.nl> User-Agent: Alpine 2.10 (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] List of resources? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 Jul 2013 18:50:05 -0000 On Mon, 15 Jul 2013, Marco Davids (SIDN) wrote: > Are you familiar with: > > http://check.sidnlabs.nl/dane/ ? Oh, I was not :) Is there a way to deeplink, eg like: http://check.sidnlabs.nl/dane/?q=rogue.nohats.ca Paul From pwouters@redhat.com Mon Jul 15 13:38:26 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C70E21E8141 for ; Mon, 15 Jul 2013 13:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvtDIpZ+37m7 for ; Mon, 15 Jul 2013 13:38:22 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 79C8A21E8174 for ; Mon, 15 Jul 2013 13:37:53 -0700 (PDT) Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r6FKbqe3012675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 15 Jul 2013 16:37:52 -0400 Received: from bofh.nohats.ca (vpn-62-221.rdu2.redhat.com [10.10.62.221]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r6FKbpaO009350 for ; Mon, 15 Jul 2013 16:37:51 -0400 Message-ID: <51E45D9F.9020902@redhat.com> Date: Mon, 15 Jul 2013 16:37:51 -0400 From: Paul Wouters User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: dane@ietf.org References: <20130715202329.16503.79218.idtracker@ietfa.amsl.com> In-Reply-To: <20130715202329.16503.79218.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.1 X-Forwarded-Message-Id: <20130715202329.16503.79218.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 X-Mailman-Approved-At: Mon, 15 Jul 2013 13:41:32 -0700 Subject: [dane] Fwd: New Version Notification for draft-wouters-dane-otrfp-00.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 20:38:27 -0000 Hi, I've submitted a first version for using DANE to associate Instant Message OTR public keys with email addresses. Note that Peter Saint-Andre and I are also working on writing up the OTR specification itself. Paul A new version of I-D, draft-wouters-dane-otrfp-00.txt has been successfully submitted by Paul Wouters and posted to the IETF repository. Filename: draft-wouters-dane-otrfp Revision: 00 Title: Using DANE to Associate OTR public keys with email addresses Creation date: 2013-07-15 Group: Individual Submission Number of pages: 11 URL: http://www.ietf.org/internet-drafts/draft-wouters-dane-otrfp-00.txt Status: http://datatracker.ietf.org/doc/draft-wouters-dane-otrfp Htmlized: http://tools.ietf.org/html/draft-wouters-dane-otrfp-00 Abstract: The Off-the-Record (OTR) protocol exchanges public keys in-band. This document describes how to use DANE to securely associate an Instant Message user identified by their email address with an OTR public key. This association helps to authenticate users and protect against MITM attacks. The IETF Secretariat From pwouters@redhat.com Mon Jul 15 13:40:16 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4562021E811F for ; Mon, 15 Jul 2013 13:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQ3z+CrO63bv for ; Mon, 15 Jul 2013 13:40:12 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 2449C21E8161 for ; Mon, 15 Jul 2013 13:40:12 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r6FKeBMT001093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 15 Jul 2013 16:40:11 -0400 Received: from bofh.nohats.ca (vpn-62-221.rdu2.redhat.com [10.10.62.221]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r6FKeArl022855 for ; Mon, 15 Jul 2013 16:40:10 -0400 Message-ID: <51E45E2A.7000409@redhat.com> Date: Mon, 15 Jul 2013 16:40:10 -0400 From: Paul Wouters User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: dane@ietf.org References: <20130715202437.7290.67664.idtracker@ietfa.amsl.com> In-Reply-To: <20130715202437.7290.67664.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.1 X-Forwarded-Message-Id: <20130715202437.7290.67664.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Mailman-Approved-At: Mon, 15 Jul 2013 13:41:32 -0700 Subject: [dane] Fwd: New Version Notification for draft-wouters-dane-openpgp-00.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 20:40:16 -0000 Hi, I've submitted a draft to associate an PGP public key with an email address using DANE. As the openpgp WG closed down, I'm not sure if I should also send this announcement to another IETF mailing list. Paul A new version of I-D, draft-wouters-dane-openpgp-00.txt has been successfully submitted by Paul Wouters and posted to the IETF repository. Filename: draft-wouters-dane-openpgp Revision: 00 Title: Using DANE to Associate OpenPGP public keys with email addresses Creation date: 2013-07-15 Group: Individual Submission Number of pages: 11 URL: http://www.ietf.org/internet-drafts/draft-wouters-dane-openpgp-00.txt Status: http://datatracker.ietf.org/doc/draft-wouters-dane-openpgp Htmlized: http://tools.ietf.org/html/draft-wouters-dane-openpgp-00 Abstract: OpenPGP is a message format for email (and file) encryption, that lacks a standarized secure lookup mechanism to obtain OpenPGP public keys. This document specifies a standarized method for securely publishing and locating OpenPGP public keys in DNS using a new OPENPGPKEY DNS Resource Record. The IETF Secretariat From stpeter@stpeter.im Mon Jul 15 13:46:18 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9610021E8174 for ; Mon, 15 Jul 2013 13:46:18 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iakp+AnQyRu5 for ; Mon, 15 Jul 2013 13:46:14 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7908921E8141 for ; Mon, 15 Jul 2013 13:46:14 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.235]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E17A34144F; Mon, 15 Jul 2013 14:47:35 -0600 (MDT) Message-ID: <51E45F92.2030400@stpeter.im> Date: Mon, 15 Jul 2013 14:46:10 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: dane@ietf.org References: <20130715202437.7290.67664.idtracker@ietfa.amsl.com> <51E45E2A.7000409@redhat.com> In-Reply-To: <51E45E2A.7000409@redhat.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dane] Fwd: New Version Notification for draft-wouters-dane-openpgp-00.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 20:46:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/15/13 2:40 PM, Paul Wouters wrote: > > Hi, > > I've submitted a draft to associate an PGP public key with an > email address using DANE. I've reviewed this quickly and it looks good. I will spend more time for an in-depth review before IETF 87. > As the openpgp WG closed down, I'm not sure if I should also send > this announcement to another IETF mailing list. The OPENPGP WG closed down, but the list is still active: https://www.ietf.org/mailman/listinfo/openpgp Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJR5F+SAAoJEOoGpJErxa2p91EP/RIMVvqTQSxGO4o10PCobo5R wmrO9uUGr5Ym6NZ22n24YiHbBYzYYT7aEttt8tJuB+YcSG8nBGNpZerU+GJPf6as KUgR+esNbgH9vUQZ7YcDp3tZ7CsmXZsu3GluajF2x1tVkqJPrzdLdDyAL9zEKf4Z f9CntLX8enJ3w0aw0t1Bcf0UMDqSG8B0uBoJrzx9qGS1EpdWk8cAsMqrVsqJiDzS scRNQDhI9FkQaqxm4G4jVRGUs9Fw0krFNUWBA76/DLB9mQRAaoGc6lEnxkourZ0y w6ambblLTFE07plaLAAO/d9puQ/hrubnRrP/lcNiQT4FPWJDoRKmbguogqHF5T9y GSDf87ue8ZncC0oUBuM1YR5orThRVhVb6OlDY6N1L2D0xIEhorQ5ooRCGRbfD2Hk Ydf5YNt/gD4a9FhwGybxzvri12CM8bCPgtjKqIFAHyykJcl9QYlHPnjZi3AlnpS6 5UBwdqOF9BOH4CS8jKeO87Xf1viI5uy8SbhUJtYyY6O/KdcBBtK83ekwJdcMd/rT VT6FxdRAerGzRGDY3bXVjuNabzbvZTyaVEUcMyfailHvYl4YKznhpuiRsHLOreUJ c8w1TIEafnnl3xJO1g1Hc5wIFhV9xpevgU4L2phaDxLcmJd7pYFxdPLZ88YDxaWQ YlOPVsHGu2UbLGxI0LwH =gdwO -----END PGP SIGNATURE----- From dan-ietf@danyork.org Mon Jul 15 14:56:16 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB6AC21E8166 for ; Mon, 15 Jul 2013 14:56:16 -0700 (PDT) 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=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cqkRKUot3BnQ for ; Mon, 15 Jul 2013 14:56:12 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C4E7321E814F for ; Mon, 15 Jul 2013 14:56:03 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id e15so3560551vbg.3 for ; Mon, 15 Jul 2013 14:55:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=NPg+cLeang6ZkRId6Vt6n7udcNQNovYpGg2bE7ybRyg=; b=kLmuczoprbEdz08wTtKOCW6nXHVMpysAIz4hPYv8Bq9FmZEiJPjzHxpy0IkmodAiHk VCa72CoT1+HRd+EcH/mAHVTbB39Y+tiqsnVKMj2/y+gtNn3m2xENP1VBuCRSsvWMm/24 en40RAp6rWyq2BgGauWLvu3B96WkOYodk3FMJa2l7vczLRok2q0ozfX99goUzwFR66Iw uaAptktPZHGl6l8NCexLaCtWIWP7gNmBt5Fjm/JlJdZnNBdTOTEGjzEdPy0pumQqdY0E 5uKyXaBXYdJRHBFn4JToEHVZbPaop+KPwtP7tHpO32xfo/epocSxxH0/LazxNdHLkMmT eLvg== MIME-Version: 1.0 X-Received: by 10.52.72.15 with SMTP id z15mr24247644vdu.91.1373925348998; Mon, 15 Jul 2013 14:55:48 -0700 (PDT) Received: by 10.58.217.101 with HTTP; Mon, 15 Jul 2013 14:55:48 -0700 (PDT) X-Originating-IP: [196.38.31.134] In-Reply-To: <51E3AE56.5030102@sidn.nl> References: <51E19900.9020306@nottheoilrig.com> <51E3AE56.5030102@sidn.nl> Date: Mon, 15 Jul 2013 23:55:48 +0200 Message-ID: From: Dan York To: "Marco Davids (SIDN)" Content-Type: multipart/alternative; boundary=20cf307f30da600d8204e193ec30 X-Gm-Message-State: ALoCoQlYC3PAgCCaurW4zqwT8fixLLQjqhg2NEE7/Ljbv+/79O6auHz1ngd4N2jcMTBMQ9akXVLc Cc: IETF DANE WG list Subject: Re: [dane] List of resources? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 Jul 2013 21:56:17 -0000 --20cf307f30da600d8204e193ec30 Content-Type: text/plain; charset=ISO-8859-1 Marco, On Mon, Jul 15, 2013 at 10:09 AM, Marco Davids (SIDN) wrote: > > > I am not away of any sites that verify TLSA records yet. > > Are you familiar with: > > http://check.sidnlabs.nl/dane/ ? > Now that you mention it, I do seem to remember hearing about that... but I had forgotten in the interim. Thanks for sending along the link. I'll add it to the list of resources. Thanks, Dan -- Dan York, dan-ietf@danyork.org http://danyork.me http://twitter.com/danyork --20cf307f30da600d8204e193ec30 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Marco,

On Mon, Jul 15, 2013 at 10:09 AM, Marco Davids (SIDN) <marco.davi= ds@sidn.nl> wrote:

> I am not away of any sites that verify TLSA records yet.

Are you familiar with:

http://check.s= idnlabs.nl/dane/ ?
Now that you mention it, I do seem to remember hearing about that...= but I had forgotten in the interim. =A0Thanks for sending along the link. = I'll add it to the list of resources.

Thanks,
= Dan


--
--20cf307f30da600d8204e193ec30-- From wjhns1@hardakers.net Mon Jul 15 16:58:07 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F38921E811C for ; Mon, 15 Jul 2013 16:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7zAasEq8Z2K for ; Mon, 15 Jul 2013 16:58:07 -0700 (PDT) Received: from mail.hardakers.net (dawn.hardakers.net [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id 01FB021E81BD for ; Mon, 15 Jul 2013 16:58:02 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:470:1f00:187:9c81:3501:fc02:feb1]) by mail.hardakers.net (Postfix) with ESMTPSA id 53C6E25ECD for ; Mon, 15 Jul 2013 16:58:02 -0700 (PDT) From: Wes Hardaker To: dane@ietf.org Date: Mon, 15 Jul 2013 16:58:02 -0700 Message-ID: <0loba3z88l.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Subject: [dane] [internet-drafts@ietf.org] New Version Notification for draft-dukhovni-smtp-opportunistic-tls-01.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 23:58:07 -0000 --=-=-= Content-Type: text/plain FYI: --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on dawn.hardakers.net X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD, SPF_PASS autolearn=ham version=3.3.2 X-Spam-Level: X-Spam-Flag: NO X-Original-To: ietf@hardakers.net Delivered-To: ietf@hardakers.net Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:123a::1:1e]) by mail.hardakers.net (Postfix) with ESMTP id E9E142BDA6 for ; Mon, 15 Jul 2013 16:45:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28D0E11E8282; Mon, 15 Jul 2013 16:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pHMrjwbrKVTg; Mon, 15 Jul 2013 16:45:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB6211E827E; Mon, 15 Jul 2013 16:45:44 -0700 (PDT) From: internet-drafts@ietf.org To: Viktor Dukhovni , Wes Hardaker , Wesley Hardaker Subject: New Version Notification for draft-dukhovni-smtp-opportunistic-tls-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130715234544.18021.45303.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 16:45:44 -0700 MIME-Version: 1.0 Content-Type: text/plain A new version of I-D, draft-dukhovni-smtp-opportunistic-tls-01.txt has been successfully submitted by Viktor Dukhovni and posted to the IETF repository. Filename: draft-dukhovni-smtp-opportunistic-tls Revision: 01 Title: SMTP security via opportunistic DANE TLS Creation date: 2013-07-15 Group: Individual Submission Number of pages: 17 URL: http://www.ietf.org/internet-drafts/draft-dukhovni-smtp-opportunistic-tls-01.txt Status: http://datatracker.ietf.org/doc/draft-dukhovni-smtp-opportunistic-tls Htmlized: http://tools.ietf.org/html/draft-dukhovni-smtp-opportunistic-tls-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-dukhovni-smtp-opportunistic-tls-01 Abstract: This memo describes a protocol for opportunistic TLS security based on the DANE TLSA DNS record. The design goal is an incremental transition of the Internet email backbone (MTA to MTA SMTP traffic) from today's unauthenticated and unencrypted connections to TLS encrypted and authenticated delivery when the client is DANE TLSA aware and the server domain publishes DANE TLSA records for its MX hosts. The IETF Secretariat --=-=-= Content-Type: text/plain -- Wes Hardaker Parsons --=-=-=-- From wjhns1@hardakers.net Mon Jul 15 16:58:23 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2EE411E8282 for ; Mon, 15 Jul 2013 16:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ctkLuscnnsfB for ; Mon, 15 Jul 2013 16:58:16 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED6711E8246 for ; Mon, 15 Jul 2013 16:58:16 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:470:1f00:187:9c81:3501:fc02:feb1]) by mail.hardakers.net (Postfix) with ESMTPSA id 7366325ECD for ; Mon, 15 Jul 2013 16:58:15 -0700 (PDT) From: Wes Hardaker To: dane@ietf.org Date: Mon, 15 Jul 2013 16:58:15 -0700 Message-ID: <0lk3krz888.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Subject: [dane] [internet-drafts@ietf.org] New Version Notification for draft-dukhovni-dane-ops-01.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 23:58:23 -0000 --=-=-= Content-Type: text/plain FYI: --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on dawn.hardakers.net X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD, SPF_PASS autolearn=ham version=3.3.2 X-Spam-Level: X-Spam-Flag: NO X-Original-To: ietf@hardakers.net Delivered-To: ietf@hardakers.net Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:123a::1:1e]) by mail.hardakers.net (Postfix) with ESMTP id B90C22BDA6 for ; Mon, 15 Jul 2013 16:45:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15B5711E8276; Mon, 15 Jul 2013 16:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOKGrszdMUM4; Mon, 15 Jul 2013 16:45:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6195611E827A; Mon, 15 Jul 2013 16:45:48 -0700 (PDT) From: internet-drafts@ietf.org To: Viktor Dukhovni , Wes Hardaker , Wesley Hardaker Subject: New Version Notification for draft-dukhovni-dane-ops-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130715234548.8354.61679.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 16:45:48 -0700 MIME-Version: 1.0 Content-Type: text/plain A new version of I-D, draft-dukhovni-dane-ops-01.txt has been successfully submitted by Viktor Dukhovni and posted to the IETF repository. Filename: draft-dukhovni-dane-ops Revision: 01 Title: DANE TLSA implementation and operational guidance Creation date: 2013-07-15 Group: Individual Submission Number of pages: 18 URL: http://www.ietf.org/internet-drafts/draft-dukhovni-dane-ops-01.txt Status: http://datatracker.ietf.org/doc/draft-dukhovni-dane-ops Htmlized: http://tools.ietf.org/html/draft-dukhovni-dane-ops-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-dukhovni-dane-ops-01 Abstract: This memo provides operational guidance to server operators to help ensure that clients will be able to authenticate a server's certificate chain via published TLSA records. Guidance is also provided to clients for selecting reliable TLSA record parameters to use for server authentication. Finally, guidance is given to protocol designers who wish to make use of TLSA records to secure protocols using a TLS and TLSA combination. The IETF Secretariat --=-=-= Content-Type: text/plain -- Wes Hardaker Parsons --=-=-=-- From simon@arlott.org Tue Jul 16 04:49:47 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 802BD11E8195 for ; Tue, 16 Jul 2013 04:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwTC9M8AV8DD for ; Tue, 16 Jul 2013 04:49:47 -0700 (PDT) Received: from proxima.lp0.eu (proxima.lp0.eu [IPv6:2001:8b0:ffea:0:205:b4ff:fe12:530]) by ietfa.amsl.com (Postfix) with ESMTP id D001721E80A1 for ; Tue, 16 Jul 2013 04:49:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=arlott.org; s=exim; h=Content-Transfer-Encoding:Content-Type:MIME-Version:To:From:Subject:Date:References:In-Reply-To:Message-ID; bh=jYg4XbPVqoSo616sj9TkC4085JQuhkQmWLGpvI9uw5A=; b=W2fjrJ53ydaUZkuUnU4qajcnIsl3aN6gnu//wEt/sg1sEhUnaZ2V5EZHbyE5AtQmYg7ZDXMK8Gk89QTNLJXRpqodsLwpjUWBgt5biOE2Tfuju0BN2CGt6QKv67tRVAlCJEyTcp7i3t7fCV5hC2J+RON57OxH3/6Mdf89flgoMHut1bIeZy8BD2B63b4b/OUq/n2Pb5ZvpL6O3eKPsbrUfV1Z8TEXAgJDKvNy716pvLIpbhezbeQJ8S6iwt8Hv/+80Gy8z/pOV76UO+Rc05ydQKxPGVsX22bDcpgKatmZljdn/JHfnbgPnxyF2VUisZg9I88QB0HnAvsCCmBKee/HFA==; Received: from lp0_webmail by proxima.lp0.eu with local id 1Uz3dq-0005lB-FA for dane@ietf.org; Tue, 16 Jul 2013 12:42:03 +0100 Received: from simon by proxima.lp0.eu with https; Tue, 16 Jul 2013 12:42:02 +0100 Message-ID: <42fbfe08616637e1c0c314e146aedb1489637cd1@8b5064a13e22126c1b9329f0dc35b8915774b7c3.invalid> In-Reply-To: <51E45F92.2030400@stpeter.im> References: <20130715202437.7290.67664.idtracker@ietfa.amsl.com> <51E45E2A.7000409@redhat.com> <51E45F92.2030400@stpeter.im> Date: Tue, 16 Jul 2013 12:42:02 +0100 From: "Simon Arlott" To: dane@ietf.org User-Agent: SquirrelMail/1.4.19 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: [dane] Fwd: New Version Notification for draft-wouters-dane-openpgp-00.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 11:49:47 -0000 On Mon, July 15, 2013 21:46, Peter Saint-Andre wrote: > On 7/15/13 2:40 PM, Paul Wouters wrote: >> I've submitted a draft to associate an PGP public key with an >> email address using DANE. > > I've reviewed this quickly and it looks good. I will spend more time > for an in-depth review before IETF 87. Doesn't this completely duplicate RFC4398? What's wrong with stating that PGP CERT and IPGP CERT RRs should be trusted if they are verified by DNSSEC? -- Simon Arlott From benl@google.com Tue Jul 16 07:48:07 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0235011E80D7 for ; Tue, 16 Jul 2013 07:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhQTIo+w01NI for ; Tue, 16 Jul 2013 07:48:06 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 7E68A11E80D3 for ; Tue, 16 Jul 2013 07:48:06 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id 10so1870868ied.0 for ; Tue, 16 Jul 2013 07:48:06 -0700 (PDT) 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=3T+3c570kJAPhBWpTaIbsO2engIU6upfSTpQEenW2Dw=; b=EUulIAUSKhLzJE/xKIlzHHU5El8EmSK2rPYQhVgQMURa/1BnQjr+YXTaGJVn4pla+K McJYwEgA0BN8Fg53CFcKjnqaelS0Yj35TmMZN41nND7HmtSavGc8rgbJec5QQuTamYXW c6m2as9hWK7el4KqyJllxHAi3IEzT7PnfdxxKvoEPzadQldWGyPBnFSIWmWwZlPTMM1u +b7Gplv0hqH+3LgyYYHuzP35Q8aFQ7PlNd3+PiPole7peztAOcxSifd8FIygqbpvbXNb oeGTyfWBI+eeLH6wIWtVG731Q+aihazRkjvWm9jv8mpahrGjDDxSs6S23u9VFpPG5lYD DjsQ== 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=3T+3c570kJAPhBWpTaIbsO2engIU6upfSTpQEenW2Dw=; b=PPdkxUMnKHpP9hFUxmu8Ao6FukV1rRpwPfC6Jp+OfScgChjUFk3xTXdL80AffQIJmn B+mKhwQ8r8IGhXehgeTXbEHqOznpiuFCifijbNP3O3j8x3OxzraXbul2t/BewMIEgyXd JhWfdF/qNbtl090pDhCt7A5e5VVq/ntJTnqAv/k91lVYzCPFUFmpusySusKGgBBmXwgn uMuNJrf/U/kAKGZCrKfUnqHuKQwjunjsESwgFV6hMlLqio7rK1DL/R+5X3qAzTqG1GAC /HKNM1t9rCM/w5zH8ZC6qqzzJdWXRCJJvtjI/5hRoVP7067J609fNcU3ROyCUjo+xbgg /nZQ== MIME-Version: 1.0 X-Received: by 10.42.254.8 with SMTP id nc8mr662068icb.49.1373986085958; Tue, 16 Jul 2013 07:48:05 -0700 (PDT) Received: by 10.64.100.207 with HTTP; Tue, 16 Jul 2013 07:48:05 -0700 (PDT) In-Reply-To: <0lk3krz888.fsf@wjh.hardakers.net> References: <0lk3krz888.fsf@wjh.hardakers.net> Date: Tue, 16 Jul 2013 15:48:05 +0100 Message-ID: From: Ben Laurie To: Wes Hardaker Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmCqLzZQREnDyOEZ62nu6IhPvve0Q10prN/X6HTT9L6wxockhD2ZyrJOAUzEd3hMLFlld5cmuvMvZsF5SaF/aZUvsUWneZxtHonFBnTe+qqcj4vX1LJGqShJnBJJ2yN2L+gbmzFh4sqkdOtgBVavWwjVUVxleZFs9oT4M3/qiomrJ/DyEjP5/xkv4XM2cjp6qrFEEiV Cc: IETF DANE WG list Subject: Re: [dane] [internet-drafts@ietf.org] New Version Notification for draft-dukhovni-dane-ops-01.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 14:48:07 -0000 I have to push back on the text in 3.7. Interaction with Certificate Transparency: "If ... DANE TLSA RRs constrain the end-entity certificate to a fixed public key, there is no role for CT, and clients SHOULD NOT apply CT checks." This assumes that DNSSEC is impossible to subvert. If you realistically assume that DNSSEC may suffer from the same kinds of issues that CAs do, then CT has a role: the detection of incorrect issuance of certs in conjunction with incorrect DANE records. On 16 July 2013 00:58, Wes Hardaker wrote: > > FYI: > > > > ---------- Forwarded message ---------- > From: internet-drafts@ietf.org > To: Viktor Dukhovni , Wes Hardaker , Wesley Hardaker > Cc: > Date: Mon, 15 Jul 2013 16:45:48 -0700 > Subject: New Version Notification for draft-dukhovni-dane-ops-01.txt > > A new version of I-D, draft-dukhovni-dane-ops-01.txt > has been successfully submitted by Viktor Dukhovni and posted to the > IETF repository. > > Filename: draft-dukhovni-dane-ops > Revision: 01 > Title: DANE TLSA implementation and operational guidance > Creation date: 2013-07-15 > Group: Individual Submission > Number of pages: 18 > URL: http://www.ietf.org/internet-drafts/draft-dukhovni-dane-ops-01.txt > Status: http://datatracker.ietf.org/doc/draft-dukhovni-dane-ops > Htmlized: http://tools.ietf.org/html/draft-dukhovni-dane-ops-01 > Diff: http://www.ietf.org/rfcdiff?url2=draft-dukhovni-dane-ops-01 > > Abstract: > This memo provides operational guidance to server operators to help > ensure that clients will be able to authenticate a server's > certificate chain via published TLSA records. Guidance is also > provided to clients for selecting reliable TLSA record parameters to > use for server authentication. Finally, guidance is given to > protocol designers who wish to make use of TLSA records to secure > protocols using a TLS and TLSA combination. > > > > > The IETF Secretariat > > > > > -- > Wes Hardaker > Parsons > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > From schoen@eff.org Tue Jul 16 08:09:49 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33F0A21F9D4F for ; Tue, 16 Jul 2013 08:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lt5z4eBduBlc for ; Tue, 16 Jul 2013 08:09:44 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [64.147.188.12]) by ietfa.amsl.com (Postfix) with ESMTP id C06D021F9EEB for ; Tue, 16 Jul 2013 08:09:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=hPJ2Yb+lGSEyEVinhCe1R3n169HFPW6eGJ2VaW1/g/Q=; b=RevaZGVONXqCP1FZUtkRh0XqLQPeBQyZ36kCVMsrH6H8KuuQNEo9BzH9q9ZWlUTkbLOCZgCXblwUD5G8PfxlLYuuDsipeF5DFL75gbdAw4cLQRjAbbU9uyGjRncreO6q; Received: from localhost ([127.0.0.1]:49873 helo=sescenties) by mail2.eff.org with esmtp (Exim 4.80) (envelope-from ) id 1Uz6sp-0004ra-OY; Tue, 16 Jul 2013 08:09:43 -0700 Date: Tue, 16 Jul 2013 08:09:39 -0700 From: Seth David Schoen To: Ben Laurie Message-ID: <20130716150939.GR2345@sescenties.(null)> References: <0lk3krz888.fsf@wjh.hardakers.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IETF DANE WG list Subject: Re: [dane] [internet-drafts@ietf.org] New Version Notification for draft-dukhovni-dane-ops-01.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 15:09:49 -0000 Ben Laurie writes: > I have to push back on the text in 3.7. Interaction with Certificate > Transparency: > > "If ... DANE TLSA RRs constrain the end-entity certificate to a fixed > public key, there is no role for CT, and clients SHOULD NOT apply CT > checks." > > This assumes that DNSSEC is impossible to subvert. If you > realistically assume that DNSSEC may suffer from the same kinds of > issues that CAs do, then CT has a role: the detection of incorrect > issuance of certs in conjunction with incorrect DANE records. I'd suggest that when there are multiple mechanisms available to constrain the end-entity certificate, clients SHOULD be able to protect themselves by taking advantage of more than one of them. We might say that this is a matter of allowing the end-entity to use both belt and suspenders. -- Seth Schoen Senior Staff Technologist https://www.eff.org/ Electronic Frontier Foundation https://www.eff.org/join 815 Eddy Street, San Francisco, CA 94109 +1 415 436 9333 x107 From viktor1dane@dukhovni.org Tue Jul 16 08:11:41 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D81E21F9A2E for ; Tue, 16 Jul 2013 08:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwVFg5c6Z0Gi for ; Tue, 16 Jul 2013 08:11:36 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 947C421E80B4 for ; Tue, 16 Jul 2013 08:11:32 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 1CBCF2AACFB; Tue, 16 Jul 2013 15:11:32 +0000 (UTC) Date: Tue, 16 Jul 2013 15:11:32 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130716151132.GD29420@mournblade.imrryr.org> References: <0lk3krz888.fsf@wjh.hardakers.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] [internet-drafts@ietf.org] New Version Notification for draft-dukhovni-dane-ops-01.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 15:11:41 -0000 On Tue, Jul 16, 2013 at 03:48:05PM +0100, Ben Laurie wrote: > "If ... DANE TLSA RRs constrain the end-entity certificate to a fixed > public key, there is no role for CT, and clients SHOULD NOT apply CT > checks." > > This assumes that DNSSEC is impossible to subvert. If you > realistically assume that DNSSEC may suffer from the same kinds of > issues that CAs do, then CT has a role: the detection of incorrect > issuance of certs in conjunction with incorrect DANE records. In effect you're saying you don't trust DANE (period), because DNSSEC security is not absolute. An attacker who can modify the server's DNS RRs can make them all 3 1 1 certificate associations, with self-signed certificates of his choice that are not anchored at any known CA (I've posted examples of certificates with no names in them at all, no issuer, no subject no altnames, just the public key ma'am). How would CT help? An attacker who can't modify the server's TLSA RR's cannot MITM the connection between a client and the legitimate server since he lacks the server's private key. Other attacks that also compromise CT include root-kits on the client and compromise of the of the server's private key or break-in into the server. I am not suggesting any problems with CT just because it does not prevent these. With usage 3, there are no trusted CAs, so it would be inappropriate to attempt to impute any meaning to the validity of the certificate's issuance. The server operator has indicated which public key (3 1 1) provides the service, the certificate can be: - expired - name a completely unrelated entity - have a key usage that indicates something other than TLS server - ... The attacker could also publish "2 1 1" with some synthetic CA and a child server certificate issued by it. Similarly CT can't help here. If we take DANE types 2/3 seriously, then an EE certificate match means we're at the right place. If we don't take types 2/3 seriously, we're done with DANE, there's not much of anything useful left. -- Viktor. From viktor1dane@dukhovni.org Tue Jul 16 08:16:41 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9BF11E80C5 for ; Tue, 16 Jul 2013 08:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4h683pmkFhu for ; Tue, 16 Jul 2013 08:16:36 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id F04CA21F9BC3 for ; Tue, 16 Jul 2013 08:16:35 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id A50B42AACFB; Tue, 16 Jul 2013 15:16:35 +0000 (UTC) Date: Tue, 16 Jul 2013 15:16:35 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130716151635.GE29420@mournblade.imrryr.org> References: <0lk3krz888.fsf@wjh.hardakers.net> <20130716150939.GR2345@sescenties.(null)> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130716150939.GR2345@sescenties.(null)> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] [internet-drafts@ietf.org] New Version Notification for draft-dukhovni-dane-ops-01.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 15:16:41 -0000 On Tue, Jul 16, 2013 at 08:09:39AM -0700, Seth David Schoen wrote: > > I have to push back on the text in 3.7. Interaction with Certificate > > Transparency: > > > > "If ... DANE TLSA RRs constrain the end-entity certificate to a fixed > > public key, there is no role for CT, and clients SHOULD NOT apply CT > > checks." > > > > This assumes that DNSSEC is impossible to subvert. If you > > realistically assume that DNSSEC may suffer from the same kinds of > > issues that CAs do, then CT has a role: the detection of incorrect > > issuance of certs in conjunction with incorrect DANE records. > > I'd suggest that when there are multiple mechanisms available to > constrain the end-entity certificate, clients SHOULD be able to > protect themselves by taking advantage of more than one of them. > We might say that this is a matter of allowing the end-entity to > use both belt and suspenders. Except that the suspenders aren't attached to the trousers. The hypothetical DNSSEC attack subverts both DANE and CT. The CT suspenders for DANE just add weight, we're leaving CT in place for usage 0, because once you're doing PKIX checks you may as well do CT. -- Viktor. From benl@google.com Tue Jul 16 08:46:11 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6C721F9C9A for ; Tue, 16 Jul 2013 08:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEKANUopZhIs for ; Tue, 16 Jul 2013 08:46:10 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 8716711E80D5 for ; Tue, 16 Jul 2013 08:46:10 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id aq17so1925721iec.22 for ; Tue, 16 Jul 2013 08:46:10 -0700 (PDT) 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 :content-type; bh=nNxGRHw0V0w0WvmEE4FbGd0yCDJc0ZZZupd0OyPRxB8=; b=CZTBGC+xhra0z4RoFdiN0WkFzTIZ6BJxJSJ7YgTKzXjXixLt/PprAhat8L5cqzMwgv JLg78J9o+A+yf5sCzfvcJmmS8x7iZqjAFBegIaSBwOFRT2pgxhHY/0KydXH90UR+uGRN TK0yCub/fLRjKRs46POEqTwVynODuqjq4MuRiV6wl/EmZouQ0e4R6h+wkZtoxMRgw0Ei orxF/NYgvEo5yyvzsabElEN0DRKjN3dEj3ECDsBfo5DL7viHuYLZJYGNzzhK9+LEwhGl 4T53dYFHdzKsIJBSCG4CfkSXQ2ZfQw+Pw61UZTUIuNE0BUSFD4VWyQXfto7QC/2OTcnr r+tg== 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 :content-type:x-gm-message-state; bh=nNxGRHw0V0w0WvmEE4FbGd0yCDJc0ZZZupd0OyPRxB8=; b=RrN7bdFdaiQoJk0HRD2h2KCKUvE2QrogGh3o+KQGX474xJq1JPUChaTvHmJzTXAEun thvpymCmQPfnJ96pfooijhE+Cr/caRHQj74SowviN8dbVDol/Xup5lh2mgIWxw9LkvJt 0yXec+20nSq54+36hNypqGXezlz9mF7qD09/u0eiLHCChLunm4jPlQXYiXgSoTnyrKsy vdUkrAQl9c+LpJnBFikJb1yyAahc9DgUwifIBid4q3ixjVMfOM9dqlhjM12yTHzpi2iL lCKADy2UXqay1oFZC7Sz6FEdHc4uPyQNz8JA1YdZxyD2Llyk0vzZmITPvtKNFzO8eS/N UFuA== MIME-Version: 1.0 X-Received: by 10.43.78.16 with SMTP id zk16mr1380845icb.63.1373989570019; Tue, 16 Jul 2013 08:46:10 -0700 (PDT) Received: by 10.64.100.207 with HTTP; Tue, 16 Jul 2013 08:46:09 -0700 (PDT) In-Reply-To: <20130716151132.GD29420@mournblade.imrryr.org> References: <0lk3krz888.fsf@wjh.hardakers.net> <20130716151132.GD29420@mournblade.imrryr.org> Date: Tue, 16 Jul 2013 16:46:09 +0100 Message-ID: From: Ben Laurie To: IETF DANE WG list Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmU5VjAnY9QquYcMTiBenJQT13AIxDvotcxqzGevvhbhAFnqKNw0LwOptM5kkA2XnvDpl4MTk367H4YodsqHp4G1fq0ecCJMmMErCcDpFUKpZFnz2uyWLZ11AsMf+58fZyAunMNuCHBAhkbvkJCPao8nyWmvoN4rQL9rystisQZEC56mznK7K6inAWWR6x5WeE2T+ob Subject: Re: [dane] [internet-drafts@ietf.org] New Version Notification for draft-dukhovni-dane-ops-01.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 15:46:11 -0000 On 16 July 2013 16:11, Viktor Dukhovni wrote: > On Tue, Jul 16, 2013 at 03:48:05PM +0100, Ben Laurie wrote: > >> "If ... DANE TLSA RRs constrain the end-entity certificate to a fixed >> public key, there is no role for CT, and clients SHOULD NOT apply CT >> checks." >> >> This assumes that DNSSEC is impossible to subvert. If you >> realistically assume that DNSSEC may suffer from the same kinds of >> issues that CAs do, then CT has a role: the detection of incorrect >> issuance of certs in conjunction with incorrect DANE records. > > In effect you're saying you don't trust DANE (period), because > DNSSEC security is not absolute. I am saying I trust CT more. > An attacker who can modify the server's DNS RRs can make them all > 3 1 1 certificate associations, with self-signed certificates of > his choice that are not anchored at any known CA (I've posted > examples of certificates with no names in them at all, no issuer, > no subject no altnames, just the public key ma'am). How would CT > help? It would help because if I don't follow your SHOULD NOT, then I would decline that certificate. As we have said before, we cannot allow DANE to do an end-run around CT. There is no point in finding a way to fix the problem with one set of trusted third parties only to reintroduce it via another set of trusted third parties. Also, as I have said before, we could mitigate this problem in DNSSEC by also applying transparency to it. > > An attacker who can't modify the server's TLSA RR's cannot MITM > the connection between a client and the legitimate server since > he lacks the server's private key. > > Other attacks that also compromise CT include root-kits on the > client and compromise of the of the server's private key or break-in > into the server. I am not suggesting any problems with CT just > because it does not prevent these. > > With usage 3, there are no trusted CAs, so it would be inappropriate > to attempt to impute any meaning to the validity of the certificate's > issuance. The server operator has indicated which public key (3 > 1 1) provides the service, the certificate can be: > > - expired > > - name a completely unrelated entity > > - have a key usage that indicates something other than TLS server > > - ... > > The attacker could also publish "2 1 1" with some synthetic CA and > a child server certificate issued by it. Similarly CT can't help > here. > > If we take DANE types 2/3 seriously, then an EE certificate match > means we're at the right place. If we don't take types 2/3 seriously, > we're done with DANE, there's not much of anything useful left. See above. I am happy to help with applying transparency to DNSSEC. > > -- > Viktor. > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From viktor1dane@dukhovni.org Tue Jul 16 09:01:32 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 938B521F9C32 for ; Tue, 16 Jul 2013 09:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjAq-AyoB9cm for ; Tue, 16 Jul 2013 09:01:27 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 94E8121F9C7B for ; Tue, 16 Jul 2013 09:01:14 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3FA222AAD04; Tue, 16 Jul 2013 16:01:13 +0000 (UTC) Date: Tue, 16 Jul 2013 16:01:13 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130716160112.GG29420@mournblade.imrryr.org> References: <0lk3krz888.fsf@wjh.hardakers.net> <20130716151132.GD29420@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] [internet-drafts@ietf.org] New Version Notification for draft-dukhovni-dane-ops-01.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 16:01:32 -0000 On Tue, Jul 16, 2013 at 04:46:09PM +0100, Ben Laurie wrote: > > In effect you're saying you don't trust DANE (period), because > > DNSSEC security is not absolute. > > I am saying I trust CT more. This is not surprising. :-) And TLS clients don't need to implement DANE. DANE enables server operators to bind trust to self-signed certificates (essentially bare public keys) via DNSSEC. If the client and server agree on this security mechanism, CT is out of scope at the level of the server certificate, because it is self-signed and not issued by an CA to which one can apply CT. We're merely restating the obvious. > > An attacker who can modify the server's DNS RRs can make them all > > 3 1 1 certificate associations, with self-signed certificates of > > his choice that are not anchored at any known CA (I've posted > > examples of certificates with no names in them at all, no issuer, > > no subject no altnames, just the public key ma'am). How would CT > > help? > > It would help because if I don't follow your SHOULD NOT, then I would > decline that certificate. As we have said before, we cannot allow DANE > to do an end-run around CT. There is no point in finding a way to fix > the problem with one set of trusted third parties only to reintroduce > it via another set of trusted third parties. You would decline all DANE self-signed 3 1 1 certificates. None of them can be verified via CT. This removes one of the primary use cases for DANE. So I stand by the observation that you basically don't trust DANE (at least in its present form) regardless of CT. > Also, as I have said before, we could mitigate this problem in DNSSEC > by also applying transparency to it. The place to apply transparency here is not to the certificate in the TLSA RR published by the domain owner, but to the chain DNSSEC of key and signature records that lead to the TLSA RRset. Right? If so, this would be a new DNSSEC CT mechanism, not an X.509 PKI CT. It would prevent parent zones from lying about DS key signatures, and support for this would be in the DNSSEC libraries, not in the application TLS libraries. With CT for DNSSEC I'd have more confidence that the TLSA RRset is not fraudulent, and *then* still not apply CT at the TLS layer, because the X.509 certificate is basically vestigial with DANE, despite the 24 different flavours it is just a public key bound to the service. > > If we take DANE types 2/3 seriously, then an EE certificate match > > means we're at the right place. If we don't take types 2/3 seriously, > > we're done with DANE, there's not much of anything useful left. > > See above. I am happy to help with applying transparency to DNSSEC. I think that's a fine idea, but it is orthogonal to the interaction of DANE with CT for X.509 certificates. DANE is a parallel PKI, so transparency for the world of PKIX CAs plays no useful role here. -- Viktor. From kent@bbn.com Tue Jul 16 09:05:49 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F62221F9A7E for ; Tue, 16 Jul 2013 09:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09yAl3GbIGwc for ; Tue, 16 Jul 2013 09:05:43 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id D5A2821F9ADD for ; Tue, 16 Jul 2013 09:05:41 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:55627) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Uz7ky-000GiL-Ff; Tue, 16 Jul 2013 12:05:40 -0400 Message-ID: <51E56F55.4030707@bbn.com> Date: Tue, 16 Jul 2013 12:05:41 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Ben Laurie References: <0lk3krz888.fsf@wjh.hardakers.net> <20130716151132.GD29420@mournblade.imrryr.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF DANE WG list Subject: Re: [dane] [internet-drafts@ietf.org] New Version Notification for draft-dukhovni-dane-ops-01.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 16:05:49 -0000 Ben, ... >> In effect you're saying you don't trust DANE (period), because >> DNSSEC security is not absolute. > I am saying I trust CT more. not surprising, given the source of the CT idea :-). Steve From benl@google.com Tue Jul 16 09:25:39 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68ED521E8054 for ; Tue, 16 Jul 2013 09:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxXpHK8UOmsR for ; Tue, 16 Jul 2013 09:25:39 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id D84A421F9ED4 for ; Tue, 16 Jul 2013 09:25:38 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id c10so2096051ieb.10 for ; Tue, 16 Jul 2013 09:25:38 -0700 (PDT) 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=IEyCNrqKEu91Dm8xyKze6BOtXhH2ZrNLSEyHJ2UNd/A=; b=c8PKWu3ryE2X+biS6Q0NkBulbp5bWb93/uuOl5Fc8sW/+aFuM2NSmPRwD/ZYnhqa+N f25FcBfNfQcNgzRGXLb1moFaa3mxEy5tQkW3dzKOwH9Mt6wh6819uh1rBQOHNzvRDjy2 QTF8N5UvbIqpOHUwO3Z8ZD22XYIHp1giKjLbbxqPCfbjzF4OXQ1OwiOCr/zVzGKFbtGE LGAh4IvqKKJelpUSurfSi1x24iih2SOjlpW4Wk5kJCyabGBLO2pDYIvJrN8igiygQB6G aupLGrqGgPMudDJCGDTdmv7SHtwN85Haa2KFX5As5U3To43eG/MkIQlzpaygnt99kjmt 75Xg== 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=IEyCNrqKEu91Dm8xyKze6BOtXhH2ZrNLSEyHJ2UNd/A=; b=PVk+avLBjJ9qU9kQJrOOwadBtY40C+kuwBjw9ejcWiP7CP2xAAofHnn3u3IPv1JddH I3Q6Oi81aOjlWQepD1a541MYE25+a1RR/jbJPeIFiD09GRDd79yR/7o6qLN20KHQdXK/ 4drEjttkb3xblKv4PXuzNiAfS+FKMSlwUZbg8hlreVDyGrcfIhuz8E1y++F58fdDmWJK dfI85pNLr8OKqMntikUQ174AWoltpyH6P02niHShfQ121nEObez9THSMS8ExxYM7hkaX Iytn+ESAHuoXLg3sfp+iTMklIFKYxM93ccA1k5/Z/QouxKvSNUsLB69Dyql/dd+kdsqF r0dw== MIME-Version: 1.0 X-Received: by 10.43.113.1 with SMTP id eu1mr1559754icc.113.1373991938316; Tue, 16 Jul 2013 09:25:38 -0700 (PDT) Received: by 10.64.100.207 with HTTP; Tue, 16 Jul 2013 09:25:38 -0700 (PDT) In-Reply-To: <51E56F55.4030707@bbn.com> References: <0lk3krz888.fsf@wjh.hardakers.net> <20130716151132.GD29420@mournblade.imrryr.org> <51E56F55.4030707@bbn.com> Date: Tue, 16 Jul 2013 17:25:38 +0100 Message-ID: From: Ben Laurie To: Stephen Kent Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmtxCm1VtVZLrNuIZiPapuu4q4AovhrEmKaZF6ebaxU21Z+Yhciu6yPN3B/XFMTi50ZozKb5k2wnHX69gChscOZC+5JnuUdhrClV1f15Q6SZiH9Q92EL875ic2ml64kwcYYxliTpyRc72/MiMeeWqNvFtoX+xdcj4iCWfog4xCj2bAqPPb6YwEkW14o0r4F4QQ9/nD5 Cc: IETF DANE WG list Subject: Re: [dane] [internet-drafts@ietf.org] New Version Notification for draft-dukhovni-dane-ops-01.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 16:25:39 -0000 On 16 July 2013 17:05, Stephen Kent wrote: > Ben, > > ... > > >>> In effect you're saying you don't trust DANE (period), because >>> DNSSEC security is not absolute. >> >> I am saying I trust CT more. > > not surprising, given the source of the CT idea :-). I was also one of the early supporters of DANE, so you can't read all that much into that :-) I don't care where the ideas came from, I just care about making the 'net more secure. From benl@google.com Tue Jul 16 10:18:40 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A511821E809D for ; Tue, 16 Jul 2013 10:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ih785WKhqabj for ; Tue, 16 Jul 2013 10:18:40 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 2091921E8082 for ; Tue, 16 Jul 2013 10:18:36 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id x12so2176855ief.12 for ; Tue, 16 Jul 2013 10:18:35 -0700 (PDT) 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 :content-type; bh=eWXqpz0XjqFSDZRpwcmCmzCMpp5khPn/nqBX/S/DYL8=; b=kbKSRbOXpihfclT+75yGODGjE8yY1QBgI/ZAAThycH4CBiffvlr9J7p0HKXG6BtQKF 8A6qZ3pOgWCnbSWsCwxNUuaiv8CfV9hWt2kPgeUlPl+sLHygFe8gxO+qifvbD1nIoZTa kNhkv+YWr+HeYXGIWkhFIZbJ/tW8AvA2VeKB89iQJkREmbqB2djXiloxXGRXtTn4kE0z 1nZjlQ1PQxGKjN1/jPEJqGqqGXoj8JCS5sXy8Fp/ILRrX6V5l2a+d8HgIsqFFDGb0Rnu 0h6sPA6g0ptM8Ke18dK66vrmtTnv0W/pWOpHrk+MF2lJd+n5rY6EbQ43hTBcF6kdpkkB 8JOw== 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 :content-type:x-gm-message-state; bh=eWXqpz0XjqFSDZRpwcmCmzCMpp5khPn/nqBX/S/DYL8=; b=BOyuTCq3YWuU3hE2APtFwUm7atYAHzN5v9MqNK4SLVJEA6mRbV39DsmKdihh58ZU5s 4saKq5tN4VTJtckd4GhhwaFSJzf214PHsNqf/3Ey41cqe7dHorz0Vc5qJclcqio2Yjra aQQoYxn6vI5b1Vw7hoy79CUeq9Acgl80gRIBd3VZcmmM8arPYbawZMQOVSgxiscTbTE1 R/sGiSOoeiPKhbfiY3WAGSv8vAacLnhNGexTXSWd6KLIfiGSwF/kMAyZEWoVY0T6LgJH cb6j7jt95mQCPDFHwLa2UqikumiG3qhSqBq68/IjZ+DQIhym3y22Mwvip8dAbJ73yMRi j4ig== MIME-Version: 1.0 X-Received: by 10.43.113.1 with SMTP id eu1mr1844691icc.113.1373995114526; Tue, 16 Jul 2013 10:18:34 -0700 (PDT) Received: by 10.64.100.207 with HTTP; Tue, 16 Jul 2013 10:18:34 -0700 (PDT) In-Reply-To: <20130716160112.GG29420@mournblade.imrryr.org> References: <0lk3krz888.fsf@wjh.hardakers.net> <20130716151132.GD29420@mournblade.imrryr.org> <20130716160112.GG29420@mournblade.imrryr.org> Date: Tue, 16 Jul 2013 18:18:34 +0100 Message-ID: From: Ben Laurie To: IETF DANE WG list Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnqJogi3Gfg5VUIQWbOxWJhvRVvUprTWu/wFqHl0L7hfq/pbJTC0wJlgE6SNdZrLNzqdUU0aLN5mZVVpbIyZLFPrPSbX0LkgjlsDwLHcx4J+Ii11TrpaBwwE6UpBwP/GS9P3euDhG/Fjkq8JU103Hdeae704QUqsCI2n65yNlFpzy3o+kkbTYnbmTqWhYWm21Tup7pY Subject: Re: [dane] [internet-drafts@ietf.org] New Version Notification for draft-dukhovni-dane-ops-01.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 17:18:40 -0000 On 16 July 2013 17:01, Viktor Dukhovni wrote: >> Also, as I have said before, we could mitigate this problem in DNSSEC >> by also applying transparency to it. > > The place to apply transparency here is not to the certificate in > the TLSA RR published by the domain owner, but to the chain DNSSEC > of key and signature records that lead to the TLSA RRset. Right? > > If so, this would be a new DNSSEC CT mechanism, not an X.509 PKI > CT. It would prevent parent zones from lying about DS key signatures, > and support for this would be in the DNSSEC libraries, not in the > application TLS libraries. Correct. From 35nlv6@nottheoilrig.com Tue Jul 16 11:27:04 2013 Return-Path: <35nlv6@nottheoilrig.com> X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3B211E8104 for ; Tue, 16 Jul 2013 11:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KvDdxg5KLaLo for ; Tue, 16 Jul 2013 11:26:56 -0700 (PDT) Received: from mail.nottheoilrig.com (mail.nottheoilrig.com [50.16.249.74]) by ietfa.amsl.com (Postfix) with ESMTP id C129F21E8050 for ; Tue, 16 Jul 2013 11:26:46 -0700 (PDT) Received: from mail.nottheoilrig.com (localhost [127.0.0.1]) by mail.nottheoilrig.com (Postfix) with ESMTP id BA5CC40BBC for ; Tue, 16 Jul 2013 18:26:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nottheoilrig.com; s=mail; t=1373999202; bh=Otsmc7HMGMVnkEVkHNFH4z3YTVB0XDYJe1zAI7oG5zo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=ZET3xBW8PSe2lsLQc2BGe5sQyV/54Eemksn+C6AA4ZKiv4E/ORtmBqCLnAdOqXAWd 1s90NjzHTDUU5CurOEWV4LtTUvo4IKphZ1nC2WcPaHVA32EJnxHoA1cITEQgJdA0eB B9ZNTyVSQnNFxtnCVOER6dIVJOuaT+sG9KokvpL4= Received: from kolibri (S0106c8fb26402908.ek.shawcable.net [24.66.136.12]) by mail.nottheoilrig.com (Postfix) with ESMTPSA; Tue, 16 Jul 2013 18:26:42 +0000 (UTC) Received: from nottheoilrig by kolibri with local (Exim 4.72) (envelope-from ) id 1Uz9xU-0002jx-6q; Tue, 16 Jul 2013 11:26:44 -0700 Date: Tue, 16 Jul 2013 11:26:44 -0700 From: Jack Bates <35nlv6@nottheoilrig.com> To: "Marco Davids (SIDN)" Message-ID: <20130716182632.GA17532@kolibri> References: <51E19900.9020306@nottheoilrig.com> <51E3AE56.5030102@sidn.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: dane WG list Subject: Re: [dane] List of resources? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Jul 2013 18:27:05 -0000 On Mon, Jul 15, 2013 at 02:49:57PM -0400, Paul Wouters wrote: > On Mon, 15 Jul 2013, Marco Davids (SIDN) wrote: > >Are you familiar with: > > > >http://check.sidnlabs.nl/dane/ ? > > Oh, I was not :) > > Is there a way to deeplink, eg like: http://check.sidnlabs.nl/dane/?q=rogue.nohats.ca Great, the debugging messages from this website are helpful, thank you Marco. I think it could also be a useful resource for getting more details about a TLSA setup, if for example it also displayed the certificate usage, etc. Thanks! From viktor1dane@dukhovni.org Tue Jul 16 12:27:07 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 711DA21F9D71 for ; Tue, 16 Jul 2013 12:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNYozpw1W4fG for ; Tue, 16 Jul 2013 12:27:02 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF1821F9D6B for ; Tue, 16 Jul 2013 12:26:58 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id C1B782AAD06; Tue, 16 Jul 2013 19:26:54 +0000 (UTC) Date: Tue, 16 Jul 2013 19:26:54 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130716192654.GH29420@mournblade.imrryr.org> References: <0lk3krz888.fsf@wjh.hardakers.net> <20130716151132.GD29420@mournblade.imrryr.org> <20130716160112.GG29420@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] [internet-drafts@ietf.org] New Version Notification for draft-dukhovni-dane-ops-01.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 19:27:07 -0000 On Tue, Jul 16, 2013 at 06:18:34PM +0100, Ben Laurie wrote: > On 16 July 2013 17:01, Viktor Dukhovni wrote: > >> Also, as I have said before, we could mitigate this problem in DNSSEC > >> by also applying transparency to it. > > > > The place to apply transparency here is not to the certificate in > > the TLSA RR published by the domain owner, but to the chain DNSSEC > > of key and signature records that lead to the TLSA RRset. Right? > > > > If so, this would be a new DNSSEC CT mechanism, not an X.509 PKI > > CT. It would prevent parent zones from lying about DS key signatures, > > and support for this would be in the DNSSEC libraries, not in the > > application TLS libraries. > > Correct. I have nothing against this, sounds cool, if it can scale and has a chance to get adopted by the various registries. Should we amend the draft to change "CT interaction" to "X.509 hierarchy CT interaction"? To me these were synonymous. We wanted to make sure that it is understood that X.509 CT does not apply to DANE. If there is someday a separate CT mechanism for DNSSEC, it is a mechanism for determining whether DNSSEC responses are trustworthy, and so may well be transparent to the DNSSEC consumer, or in any case lives below the layer where the TLS client is processing already validated TLSA RRs and trying to decide whether they patch peer certificates. So I think we're in violent agreement then. What if anything needs to be changed in the dane-ops draft? -- Viktor. From stpeter@stpeter.im Tue Jul 16 13:42:36 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5392821F97E6 for ; Tue, 16 Jul 2013 13:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-b+j-um09Vk for ; Tue, 16 Jul 2013 13:42:32 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E502C21F91B7 for ; Tue, 16 Jul 2013 13:42:28 -0700 (PDT) Received: from sjc-vpn6-1669.cisco.com (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D82014145D; Tue, 16 Jul 2013 14:43:51 -0600 (MDT) Message-ID: <51E5B02E.4020809@stpeter.im> Date: Tue, 16 Jul 2013 14:42:22 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Olle E. Johansson" References: <5B0A4B86-1D09-4F33-B170-08D8E2A830F0@edvina.net> In-Reply-To: <5B0A4B86-1D09-4F33-B170-08D8E2A830F0@edvina.net> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dane@ietf.org list" Subject: Re: [dane] draft-ietf-dane-srv-02 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Jul 2013 20:42:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/6/13 7:43 AM, Olle E. Johansson wrote: > Hi! > > While working on the SIP-dane draft, I'm trying to follow > draft-ietf-dane-srv and add the missing parts for SIP. > > I note that in section 6 the draft requires support for TLS SNI > (RFC 6066). > > Why is this a requirement? I don't see the need to require SNI > here. Supporting SNI makes life much easier for everyone, but as I > haven't seen many SIP implementations using it (mostly because the > support hasn't been in the installed versions of OpenSSL/GnuTLS and > ...hummm... TLS is not widely used). > > Adding a requirement on this (a must level) is in my view a bit too > harsh. > > One could rephrase it a bit, to say "if a server is addressed using > multiple names TLS SNI must be supported". I previously commented on this list that some technologies have an SNI equivalent, so requiring SNI and only SNI seems overly restrictive. The technology I'm familiar with here is XMPP, wherein the 'to' address of the XML stream header is treated as an indication of the domain at which the client wants to connect. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJR5bAuAAoJEOoGpJErxa2p4gMP/A6IaGvwSnHcDKQXzfSMIoIu xbvLAvcerZ65spRQ1lFfJtaBCEdg5jwc/V83BDWJ3RN2BZO+3JF+SiFdd0AdFdOX 7SHI0RBN2xb0oK4gySZnWvfiP90Z+M1DRCMR01oFq3LooMNraxY2N4CLc6k4IrHS RJyFk15c8+4aM3Y/A6T1q0C+ldl2FR2fLlAXRo0bAEjMVevU4WxCtqU7AkYDqb7a /SbpXD2kvFB9u+pq8ppc6N0us4qx8RZPwYLaIr/uACa2UUXBJzkg2ZmiWQt7BxAX eyT3QnPyyiQMhjjs8qTxjVTb/lfU6MzBfcKlZW8L9Z4n/mEV9G514dZ5bTB9Lt1c QyfK4XLxDcK4MOFtBC1LBbgnp+u+wNhBO8Dvew2j3DiAxYyXvA+X09Bp1bOIOsCb IAPlZmgh6BCOLWpPzAtQBAIOuUAnAWVgl8ghPOcZzfuwRJCB70/msmOdc66f5Hw6 5NN2puPvTqkJhRCcnC/0QwdyQzx1ifSq22y9LAcsBTD0hvmqNUVJ42QnHrM/Vt2g hqCk1FrUhO0R0G5QDCHFLBK24syIOWa0FsFZ+1+b1WKWR8VMXAiS+WWPvmwOZYcT LfQtBFrt8S4wM5SO+J5VliZbJ3pu2mG+4ydgen74ySd6XHrt6y8pBN2Pgmr+3t4o WzZtFKPYWHOUWy54QudK =zeKz -----END PGP SIGNATURE----- From benl@google.com Fri Jul 19 03:33:17 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7599E21F888F for ; Fri, 19 Jul 2013 03:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qC0UxZK0u3AL for ; Fri, 19 Jul 2013 03:33:17 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 1B92821F848A for ; Fri, 19 Jul 2013 03:33:15 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id w15so811214iea.36 for ; Fri, 19 Jul 2013 03:33:12 -0700 (PDT) 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=bwaFaJnfUJqgm4bm7vJNWDXPCZy0YltmvfYtdidiEK0=; b=E1ox7/QgnscZDLuR8eQbDGIZYZf8LLtMJXnefM4aafcHcgH6LyhqYoRUxfmsCrWirs fvHL+94R5D9jkNOldQLobJMb/XfMiHASPThm/USkhD0/XywpT5JYinPyUqvKoy+WHRr5 Pys4oTeSSbZd9oZ/JC7lRUpDZMe8naFC0cBiIHm7m1hSdFskOLxH+4Shtb4hAExNOEJl XSn1F1BYfB5SpcERMvO52hNJpqd9pdid2exayqnexuHrkdHGPajp/gxYibZY+f4e0por xC4uMS3nq0FneiEjXBMD+nNC7z2GCSkmf7/PhB0rFOsYHX7IhNH1WpkxDKWhSsApZ8LI jIcQ== 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=bwaFaJnfUJqgm4bm7vJNWDXPCZy0YltmvfYtdidiEK0=; b=e3IOTDxNsV7hiGa3lufPhgrRZNLNtqjlEB0XD4ST1V3d//jl/CEhlSttJDwZdmzXUg Xj/vHe0hFKazjPvjjPIWfU43xk+5e4vvL5WLIyY6Fd4Q4zCSMMXGcI0i3mE7uKccHl6G 6LNB7LqM5/Py9hJErM4xqs9HUAT+rggIX+yX6poKNaPjvLYJIW5wJawi2WNlvJ2OOIBF FxCYEYvCCSgQoAEvpm0OAhEGY70xmIB1p9c0T358IKS0dRhMkKunIOV/iTd5470ygGh0 t+hJuNiFyg7qw5Ghg1kHvgM4+wZRAqwifD2mx6uFtQQq1heenKj0RcK8az0esUZSo3dm qjQg== MIME-Version: 1.0 X-Received: by 10.42.254.8 with SMTP id nc8mr9247640icb.49.1374229991955; Fri, 19 Jul 2013 03:33:11 -0700 (PDT) Received: by 10.64.100.207 with HTTP; Fri, 19 Jul 2013 03:33:11 -0700 (PDT) Date: Fri, 19 Jul 2013 11:33:11 +0100 Message-ID: From: Ben Laurie To: "tls@ietf.org" , IETF DANE WG list , certificate-transparency@googlegroups.com Content-Type: multipart/alternative; boundary=bcaec50e5f9582c54304e1dadabc X-Gm-Message-State: ALoCoQm2VGFbljZ1Pad8KzrNvogUNudR0YNE4LGKO7FUQurx87mth9kloEQm3YihrDFcsiYg50tm3xZV3hUuGDlCmGq6QiLvxWvEdueyQLlXL27Lu+y8eNEBpt08jWZSCsmj4A6SmnxAavszNmyMv1Td22ylMBNmFgDvL35EHDIUtMK5UhoQaTKGc+YWmUcvzP3UlWbFktF4 Subject: [dane] Certificate Transparency Hack Day X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jul 2013 10:33:17 -0000 --bcaec50e5f9582c54304e1dadabc Content-Type: text/plain; charset=ISO-8859-1 The Certificate Transparency team are considering hosting a hack day at Google's London office during the week of Aug 27-30 (Mon Aug 26 is a bank holiday). On the agenda would likely be: * log dashboard and data visualization * an appengine port of the dashboard * browser plugins * binary transparency * DNSSEC transparency * revocation transparency * anything else people find interesting If you'd be interested in attending such an event, please let Ben Laurie (benl@google.com) know and indicate any preference for which day. Thanks! --bcaec50e5f9582c54304e1dadabc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The Certificate Transparency team are considering hosting a hack day
at Google's London office = during the week of Aug 27-30 (Mon Aug 26 is
a bank holiday)= . On the agenda would likely be:

* log dashboard= and data visualization
* = an appengine port of the dashboard
* browser plugi= ns
* binary transparency
* DNSSEC transp= arency
* revocation transp= arency
* anything else= people find interesting

If you'd be in= terested in attending such an event, please let Ben
Laurie (= benl@google.com) know and indicate any preference for which
day.

Thanks!
--bcaec50e5f9582c54304e1dadabc-- From benl@google.com Tue Jul 23 04:19:25 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4B7811E820B for ; Tue, 23 Jul 2013 04:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tClUYfunqXTm for ; Tue, 23 Jul 2013 04:19:25 -0700 (PDT) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 66E1A11E81A5 for ; Tue, 23 Jul 2013 04:19:25 -0700 (PDT) Received: by mail-ob0-f181.google.com with SMTP id 16so9741889obc.40 for ; Tue, 23 Jul 2013 04:19:25 -0700 (PDT) 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 :content-type; bh=EYZSNm9JYcDBKoBjz7e42ZpVSA+yaWHaXe/xhjnxNx0=; b=gJ/IupDUY7HK466f0OFDwI47ffXzopS39QbPNmm0oaIssrBvOqfJSbO411p5pgRtIq zDPvRvLaLYqO8yZT8cEBFdjrkFmood0F8LBRGrHZ3qGBNuK2vVSE3No3fQlghtz0stKG uTxZ28DdaKF3qbwfdC3r5cE1gcwansry3qCm7qILCiIV8FvM5fDMUyU9cbJD0/nP6G3v +wGDejEDR20vu4JUd3dp1Ja/LzEBdM6ADiOBlc5N9CTfceD4HtkULmcRymxsk2TquU+P G/S7QaNZ5541EPb+5s+qRwSRAFrxgtN0RIjf799fnf+osN08F9ulUVxyyI+0FT8vglYN pzzA== 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 :content-type:x-gm-message-state; bh=EYZSNm9JYcDBKoBjz7e42ZpVSA+yaWHaXe/xhjnxNx0=; b=KkfEIkZ9EgVdUZrJ2Auost2iOkz84JO1i3JxzzrlH5xQgcWkiG3gJUZr3y6OUGKLdy rS5zoRxCsFKw3ysurm+OAabQEhz8JtYAB/6Jc0XzWJmEu4JvNcPxaqhRHFt++AOd59u9 aG3q6k9BwiL7lq85kD8qJn/Ubm9BUSqA75aBFjGzU3ncJlj7FA7zk1np6jxkvk0qW/fR rv8Ph2EyAduop03UVuPiqfiDgLfAocvxFhmIHk0oWpJmKU6aujQmZpgaAy2LbSk9aVP3 1xnwJWzqypaDLMF9rMVTeQaMTMi0iJka4GzWWlIwSQYveNIME3wZNhv54CoCxXzfgSol h1CA== MIME-Version: 1.0 X-Received: by 10.50.20.232 with SMTP id q8mr12259604ige.0.1374578364902; Tue, 23 Jul 2013 04:19:24 -0700 (PDT) Received: by 10.64.100.207 with HTTP; Tue, 23 Jul 2013 04:19:24 -0700 (PDT) In-Reply-To: <20130716160112.GG29420@mournblade.imrryr.org> References: <0lk3krz888.fsf@wjh.hardakers.net> <20130716151132.GD29420@mournblade.imrryr.org> <20130716160112.GG29420@mournblade.imrryr.org> Date: Tue, 23 Jul 2013 12:19:24 +0100 Message-ID: From: Ben Laurie To: IETF DANE WG list Content-Type: multipart/alternative; boundary=047d7bd7584e28441e04e22bf75d X-Gm-Message-State: ALoCoQk6H80WqYAKghBY2hiogJCmaOOXm2pR0Yhe9+z6zkE3AjAkF3XFz1Mjc/POylPjdcw2jGJrl2iyEYzSwPGNdkH+t0T7Llx03AUMc+ifwsQM/GdP5cpoNo/W7Y0CtXq2a8fF81lwSgjiiUyJ0oq4hTOzZ9bddpfvvY2Xvy3vGofy55PuxIlfxH99dQY4GNxbr2syyuIa Subject: Re: [dane] [internet-drafts@ietf.org] New Version Notification for draft-dukhovni-dane-ops-01.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 11:19:26 -0000 --047d7bd7584e28441e04e22bf75d Content-Type: text/plain; charset=ISO-8859-1 On 16 July 2013 17:01, Viktor Dukhovni wrote: > > It would help because if I don't follow your SHOULD NOT, then I would > > decline that certificate. As we have said before, we cannot allow DANE > > to do an end-run around CT. There is no point in finding a way to fix > > the problem with one set of trusted third parties only to reintroduce > > it via another set of trusted third parties. > > You would decline all DANE self-signed 3 1 1 certificates. None > of them can be verified via CT. This removes one of the primary > use cases for DANE. So I stand by the observation that you basically > don't trust DANE (at least in its present form) regardless of CT. > This seems to me to miss the point. The problem is that if we allow DANE to verify self-signed certs, what stops an attacker from taking over DNS and using it to certify a self-signed cert for google.com? --047d7bd7584e28441e04e22bf75d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On 16 July 2013 17:01, Viktor Dukhovni <viktor1dane@dukhovni.org> wrote:
> It would help because= if I don't follow your SHOULD NOT, then I would
> decline that certificate. As we have said before, we cannot allow DANE=
> to do an end-run around CT. There is no point in finding a way to fix<= br> > the problem with one set of trusted third parties only to reintroduce<= br> > it via another set of trusted third parties.

You would decline all DANE self-signed 3 1 1 certificates. =A0None of them can be verified via CT. =A0This removes one of the primary
use cases for DANE. =A0So I stand by the observation that you basically
don't trust DANE (at least in its present form) regardless of CT.

This seems to me to miss the= point. The problem is that if we allow DANE to verify self-signed certs, w= hat stops an attacker from taking over DNS and using it to certify a self-s= igned cert for google.com?


<= /div> --047d7bd7584e28441e04e22bf75d-- From fneves@registro.br Tue Jul 23 05:44:29 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DAE011E8142 for ; Tue, 23 Jul 2013 05:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NpeiQJt1Qlbk for ; Tue, 23 Jul 2013 05:44:27 -0700 (PDT) Received: from clone.registro.br (clone.registro.br [IPv6:2001:12ff:0:2::4]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8D111E80F7 for ; Tue, 23 Jul 2013 05:44:27 -0700 (PDT) Received: by clone.registro.br (Postfix, from userid 1000) id 056EBE046E; Tue, 23 Jul 2013 09:44:21 -0300 (BRT) Date: Tue, 23 Jul 2013 09:44:21 -0300 From: Frederico A C Neves To: Ben Laurie Message-ID: <20130723124420.GM64849@registro.br> References: <0lk3krz888.fsf@wjh.hardakers.net> <20130716151132.GD29420@mournblade.imrryr.org> <20130716160112.GG29420@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: IETF DANE WG list Subject: Re: [dane] [internet-drafts@ietf.org] New Version Notification for draft-dukhovni-dane-ops-01.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 12:44:29 -0000 On Tue, Jul 23, 2013 at 12:19:24PM +0100, Ben Laurie wrote: > On 16 July 2013 17:01, Viktor Dukhovni wrote: > > > > It would help because if I don't follow your SHOULD NOT, then I would > > > decline that certificate. As we have said before, we cannot allow DANE > > > to do an end-run around CT. There is no point in finding a way to fix > > > the problem with one set of trusted third parties only to reintroduce > > > it via another set of trusted third parties. > > > > You would decline all DANE self-signed 3 1 1 certificates. None > > of them can be verified via CT. This removes one of the primary > > use cases for DANE. So I stand by the observation that you basically > > don't trust DANE (at least in its present form) regardless of CT. > > > > This seems to me to miss the point. The problem is that if we allow DANE to > verify self-signed certs, what stops an attacker from taking over DNS and > using it to certify a self-signed cert for google.com? How is this different from taking over the CT "information publisher" point/process? From benl@google.com Tue Jul 23 05:46:50 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7D311E80F7 for ; Tue, 23 Jul 2013 05:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQqNkbqJmwfJ for ; Tue, 23 Jul 2013 05:46:47 -0700 (PDT) Received: from mail-oa0-x22d.google.com (mail-oa0-x22d.google.com [IPv6:2607:f8b0:4003:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 1735911E80CC for ; Tue, 23 Jul 2013 05:46:46 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id j1so11067088oag.18 for ; Tue, 23 Jul 2013 05:46:46 -0700 (PDT) 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=/MH7zlwUgdYLswh1NtiiNLd2WOWDLpdXquoKle1mUfM=; b=BybRIyoYmfCU7xwQM7trL0YOjmNVvo44OolaqBpeCurmx2JXyjCI5jmaWIm+O4kWu+ 9Xoo19x3NyS7QYalsP9GvsvP8AuR9skrgUSiy14qtGhUenT3SmwWzTjzauf7UzdGeulX gdYQynUoHTPI9tGog9sl2MvP+ubwRgns21EbsRwYKBv85X9XzSjDSuRoBAcNpFLoBE8d d8R6dN2sknAHl8Rkwb/Mh/au1hzn2tZPZcqs5GGiib/oYEo9lgJWQoHdKTpCZo/Pq25Y tcsFBBfdSCQhFfO/jEAmKI4rz4KdwkpuowwwyuL13Jmqhm/tJTwAhI+IU6O2hV/yhz1L pmMg== 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=/MH7zlwUgdYLswh1NtiiNLd2WOWDLpdXquoKle1mUfM=; b=SnhH3UxjQFIpSCyj0rGqJal124tRsyrJuCwllLXk+uANDkKjujO/+0WpsR9KZ3dsq1 EOAoj6ze0g5LFd2aL7A4RAbeRUCaeHFtFbVMXjizqNJzTCFRTSEBSYE98/cBVoGlo8Yq NclRXgEY3SJe/Nyfpruytnr/V1S1VVnjGszPaCwEF2XhZsD1Z7SiUWobTgLVCL+1A2i7 E39hJUJvrB8Cu+K3DfM1iSjqUvfteFHzPWLYVCC5cFhGCMlWa57z1aXXxDakwZ3DTE6Y GtqdY3YDMu+GtHedd4mhwieenvvn8a1ofenGxUgHnomB+BdxCRiSR8/6SWw8K3TelzpW kQ5g== MIME-Version: 1.0 X-Received: by 10.50.112.105 with SMTP id ip9mr11824671igb.59.1374583606292; Tue, 23 Jul 2013 05:46:46 -0700 (PDT) Received: by 10.64.100.207 with HTTP; Tue, 23 Jul 2013 05:46:46 -0700 (PDT) In-Reply-To: <20130723124420.GM64849@registro.br> References: <0lk3krz888.fsf@wjh.hardakers.net> <20130716151132.GD29420@mournblade.imrryr.org> <20130716160112.GG29420@mournblade.imrryr.org> <20130723124420.GM64849@registro.br> Date: Tue, 23 Jul 2013 13:46:46 +0100 Message-ID: From: Ben Laurie To: Frederico A C Neves Content-Type: multipart/alternative; boundary=047d7b414ad6916df004e22d2feb X-Gm-Message-State: ALoCoQlVR6mPB18J2ni0wmb9ho6gWkvBPD7TgsVeMD3LrEgKnt2VC2q0oaCsGOjpfrkOGEITpEn1BE2s5cq1fLEWCaQYspjdz8AYQL70ZGU0kX5F4QCURjIjg8edUK5/QYF+gm+jnjoqVHZxdVqcAOv6xXN4393w3I12zVJhYhHz/DmXhxzJG2UIUBTJkO95JfEBXKmF3iWd Cc: IETF DANE WG list Subject: Re: [dane] [internet-drafts@ietf.org] New Version Notification for draft-dukhovni-dane-ops-01.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 12:46:50 -0000 --047d7b414ad6916df004e22d2feb Content-Type: text/plain; charset=ISO-8859-1 On 23 July 2013 13:44, Frederico A C Neves wrote: > On Tue, Jul 23, 2013 at 12:19:24PM +0100, Ben Laurie wrote: > > On 16 July 2013 17:01, Viktor Dukhovni wrote: > > > > > > It would help because if I don't follow your SHOULD NOT, then I would > > > > decline that certificate. As we have said before, we cannot allow > DANE > > > > to do an end-run around CT. There is no point in finding a way to fix > > > > the problem with one set of trusted third parties only to reintroduce > > > > it via another set of trusted third parties. > > > > > > You would decline all DANE self-signed 3 1 1 certificates. None > > > of them can be verified via CT. This removes one of the primary > > > use cases for DANE. So I stand by the observation that you basically > > > don't trust DANE (at least in its present form) regardless of CT. > > > > > > > This seems to me to miss the point. The problem is that if we allow DANE > to > > verify self-signed certs, what stops an attacker from taking over DNS and > > using it to certify a self-signed cert for google.com? > > How is this different from taking over the CT "information publisher" > point/process? > CT is an untrusted, verifiable service. --047d7b414ad6916df004e22d2feb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 23 July 2013 13:44, Frederico A C Neves <fneves@registro.br> wrote:
On T= ue, Jul 23, 2013 at 12:19:24PM +0100, Ben Laurie wrote:
> On 16 July 2013 17:01, Viktor Dukhovni <viktor1dane@dukhovni.org> wrote:
>
> > > It would help because if I don't follow your SHOULD NOT,= then I would
> > > decline that certificate. As we have said before, we cannot = allow DANE
> > > to do an end-run around CT. There is no point in finding a w= ay to fix
> > > the problem with one set of trusted third parties only to re= introduce
> > > it via another set of trusted third parties.
> >
> > You would decline all DANE self-signed 3 1 1 certificates. =A0Non= e
> > of them can be verified via CT. =A0This removes one of the primar= y
> > use cases for DANE. =A0So I stand by the observation that you bas= ically
> > don't trust DANE (at least in its present form) regardless of= CT.
> >
>
> This seems to me to miss the point. The problem is that if we allow DA= NE to
> verify self-signed certs, what stops an attacker from taking over DNS = and
> using it to certify a self-signed cert for google.com?

How is this different from taking over the CT "information= publisher"
point/process?

CT is an untrusted,= verifiable service.

--047d7b414ad6916df004e22d2feb-- From jeremy.rowley@digicert.com Tue Jul 23 06:55:41 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87B2521E804B for ; Tue, 23 Jul 2013 06:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-SMXLDHMIKw for ; Tue, 23 Jul 2013 06:55:34 -0700 (PDT) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) by ietfa.amsl.com (Postfix) with ESMTP id 434FE11E8146 for ; Tue, 23 Jul 2013 06:55:34 -0700 (PDT) Received: from JROWLEYL1 (c-174-52-94-24.hsd1.ut.comcast.net [174.52.94.24]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPSA id 638678FA448; Tue, 23 Jul 2013 07:55:30 -0600 (MDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1374587730; bh=41iCSTenFPaPGgVX/H9qDK4y5IgW5sr1wxgzh7TWSOU=; h=Reply-To:From:To:Cc:References:In-Reply-To:Subject:Date; b=rSohiN7R18dkla6mWfeI7g20pPlygQbuR6N/BX31aD8hArYsAt625Ey8h0kz9kEEo zzjJBrA9yxve62DQnXu7JaVX/bpFY2/ScRMVd+LQwLVNJjVy/giwqMTEUjrvjpvqTZ 2yYfPqOpww7R94vCmLIYE3YXzumVJia4hGJoVHI8= From: "Jeremy Rowley" To: "'Ben Laurie'" , "'Frederico A C Neves'" References: <0lk3krz888.fsf@wjh.hardakers.net> <20130716151132.GD29420@mournblade.imrryr.org> <20130716160112.GG29420@mournblade.imrryr.org> <20130723124420.GM64849@registro.br> In-Reply-To: Date: Tue, 23 Jul 2013 07:55:30 -0600 Organization: DigiCert Message-ID: <01e301ce87ac$4b753420$e25f9c60$@digicert.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01E4_01CE877A.00DB6060" X-Mailer: Microsoft Outlook 14.0 Thread-index: AQGIIAYPT7dfiVZ0tuWuF1ovZDgpUgIbUXWeAjesPrEBtOJ3QwHVS4LGAlMmhp4Cu6BSHgFkggF3mYyUm8A= Content-Language: en-us Cc: 'IETF DANE WG list' Subject: Re: [dane] [internet-drafts@ietf.org] New Version Notification for draft-dukhovni-dane-ops-01.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jeremy.rowley@digicert.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 13:55:41 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01E4_01CE877A.00DB6060 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Right - It doesn't matter who takes over the log. Either the certificate is present in the log or it isn't. From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of Ben Laurie Sent: Tuesday, July 23, 2013 6:47 AM To: Frederico A C Neves Cc: IETF DANE WG list Subject: Re: [dane] [internet-drafts@ietf.org] New Version Notification for draft-dukhovni-dane-ops-01.txt On 23 July 2013 13:44, Frederico A C Neves wrote: On Tue, Jul 23, 2013 at 12:19:24PM +0100, Ben Laurie wrote: > On 16 July 2013 17:01, Viktor Dukhovni wrote: > > > > It would help because if I don't follow your SHOULD NOT, then I would > > > decline that certificate. As we have said before, we cannot allow DANE > > > to do an end-run around CT. There is no point in finding a way to fix > > > the problem with one set of trusted third parties only to reintroduce > > > it via another set of trusted third parties. > > > > You would decline all DANE self-signed 3 1 1 certificates. None > > of them can be verified via CT. This removes one of the primary > > use cases for DANE. So I stand by the observation that you basically > > don't trust DANE (at least in its present form) regardless of CT. > > > > This seems to me to miss the point. The problem is that if we allow DANE to > verify self-signed certs, what stops an attacker from taking over DNS and > using it to certify a self-signed cert for google.com? How is this different from taking over the CT "information publisher" point/process? CT is an untrusted, verifiable service. ------=_NextPart_000_01E4_01CE877A.00DB6060 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Right – It doesn’t matter who takes over the log.  = Either the certificate is present in the log or it isn’t. =

 

From:= = dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of = Ben Laurie
Sent: Tuesday, July 23, 2013 6:47 = AM
To: Frederico A C Neves
Cc: IETF DANE WG = list
Subject: Re: [dane] [internet-drafts@ietf.org] New = Version Notification for = draft-dukhovni-dane-ops-01.txt

 

 

 

On 23 July 2013 13:44, Frederico A C Neves <fneves@registro.br> = wrote:

On Tue, Jul 23, 2013 at 12:19:24PM +0100, = Ben Laurie wrote:
> On 16 July 2013 17:01, Viktor Dukhovni <viktor1dane@dukhovni.org>= wrote:
>
> > > It would help because if I don't = follow your SHOULD NOT, then I would
> > > decline that = certificate. As we have said before, we cannot allow DANE
> > = > to do an end-run around CT. There is no point in finding a way to = fix
> > > the problem with one set of trusted third parties = only to reintroduce
> > > it via another set of trusted = third parties.
> >
> > You would decline all DANE = self-signed 3 1 1 certificates.  None
> > of them can be = verified via CT.  This removes one of the primary
> > use = cases for DANE.  So I stand by the observation that you = basically
> > don't trust DANE (at least in its present form) = regardless of CT.
> >
>
> This seems to me to miss = the point. The problem is that if we allow DANE to
> verify = self-signed certs, what stops an attacker from taking over DNS = and
> using it to certify a self-signed cert for google.com?

How is this different from taking over the CT = "information = publisher"
point/process?

 

CT is an untrusted, verifiable = service.

 

------=_NextPart_000_01E4_01CE877A.00DB6060-- From viktor1dane@dukhovni.org Tue Jul 23 07:54:45 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E49E611E826F for ; Tue, 23 Jul 2013 07:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NdfawChmCaqZ for ; Tue, 23 Jul 2013 07:54:38 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id BE3E311E826D for ; Tue, 23 Jul 2013 07:54:36 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 6E1212AAC89; Tue, 23 Jul 2013 14:54:32 +0000 (UTC) Date: Tue, 23 Jul 2013 14:54:32 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130723145432.GT29420@mournblade.imrryr.org> References: <0lk3krz888.fsf@wjh.hardakers.net> <20130716151132.GD29420@mournblade.imrryr.org> <20130716160112.GG29420@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] [internet-drafts@ietf.org] New Version Notification for draft-dukhovni-dane-ops-01.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 14:54:45 -0000 On Tue, Jul 23, 2013 at 12:19:24PM +0100, Ben Laurie wrote: > On 16 July 2013 17:01, Viktor Dukhovni wrote: > > > > It would help because if I don't follow your SHOULD NOT, then I would > > > decline that certificate. As we have said before, we cannot allow DANE > > > to do an end-run around CT. There is no point in finding a way to fix > > > the problem with one set of trusted third parties only to reintroduce > > > it via another set of trusted third parties. > > > > You would decline all DANE self-signed 3 1 1 certificates. None > > of them can be verified via CT. This removes one of the primary > > use cases for DANE. So I stand by the observation that you basically > > don't trust DANE (at least in its present form) regardless of CT. > > This seems to me to miss the point. The problem is that if we allow DANE to > verify self-signed certs, what stops an attacker from taking over DNS and > using it to certify a self-signed cert for google.com? - If you don't trust "IN TLSA 3 1 1", you don't trust DANE, but there is no DANE without "3 1 1", the majority of published TLSA RRsets will be "3 1 1". It sure looks like the major browsers are not in a hurry to implement DANE, which is ironic, since RFC 6698 is mostly focused on browser-like applications, and needs adjustments for protocols like SMTP, where DANE will be actively implemented first. We're in violent agreement, you don't trust DNSSEC/DANE. You don't have to implement DANE. - With "3 1 1" the attacker would in no sense certify a self-signed cert for "google.com", they would temporarily bind a set public keys to a specific set of TLS service endpoints (e.g. _25._tcp.smtp.gmail.com), this binding trusted by applications that (are configured to) trust DNSSEC. - "Taking over DNS" (really DNSSEC) is not that simple, why do you believe that "taking over DNS" is easier than compromising the user's desktop or the target server or bribe an employee with access to the server keys, or infect the employee's desktop. - You're proposing DNSSEC transparency, which would be similar in spirit to the recently published spec for X.509 CT. That's cool. The substance of the draft language Wes and I propose is to explain that X.509 CT is fundamentally at odds with DANE. There will in the majority of cases be no issuing CA for the certificates of DANE validated servers. And if there is one, it will typically not be a public CA. The real chain of trust with DANE is the sequence of DS, DNSKEY and RRSIG records from the root down to the domain, not any chain of X.509 certificate signatures. So if you want accountability for DANE along the lines of CT, I would support your future work on transparency for DNSSEC. I don't know whether this is likely to lead to a usable, politically acceptable standard and ultimately deployed standard, but you may as well try. -- Viktor. From viktor1dane@dukhovni.org Tue Jul 23 08:26:10 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81AAB11E812E for ; Tue, 23 Jul 2013 08:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p0Uo-uDm9e2n for ; Tue, 23 Jul 2013 08:26:05 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 517F411E825C for ; Tue, 23 Jul 2013 08:26:05 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 908742AAAF5; Tue, 23 Jul 2013 15:26:02 +0000 (UTC) Date: Tue, 23 Jul 2013 15:26:02 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130723152602.GU29420@mournblade.imrryr.org> References: <0lk3krz888.fsf@wjh.hardakers.net> <20130716151132.GD29420@mournblade.imrryr.org> <20130716160112.GG29420@mournblade.imrryr.org> <20130723124420.GM64849@registro.br> <01e301ce87ac$4b753420$e25f9c60$@digicert.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01e301ce87ac$4b753420$e25f9c60$@digicert.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] [internet-drafts@ietf.org] New Version Notification for draft-dukhovni-dane-ops-01.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 15:26:10 -0000 On Tue, Jul 23, 2013 at 07:55:30AM -0600, Jeremy Rowley wrote: > Right - It doesn't matter who takes over the log. Either the certificate is > present in the log or it isn't. Not that simple, since there is a window during which the data is not yet in the log. If the attacker only needs to convice a victim that a fraudulent site is legimate for a brief time, the log is not a major deterrent. Compromise a weak CA, and don't publish the promised chain to the log. Serve the chain to a victim (compromise that victim and erase its memory of ever seeing the evil cert chain). Various other difficult, but not impossible attacks. No security system is perfect. Audit trails are very useful, but there is no perfect audit trail either. One can attack the audit trail. I have nothing against CT, all I am saying is that X.509 CT is not for DANE (TLSA). Clients that trust DANE dont't benefit from X.509 CT. They could benefit from a hypothetical implementation of DNSSEC transparency, but that would happen at the DNSSEC lookup layer, and would not involve the vestigial X.509 certificates. By all means harden DNSSEC with any reasonably appropriate mechanisms. -- Viktor. From 35nlv6@nottheoilrig.com Tue Jul 23 08:47:07 2013 Return-Path: <35nlv6@nottheoilrig.com> X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE3A121E8064 for ; Tue, 23 Jul 2013 08:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQFJZXgJ7s+f for ; Tue, 23 Jul 2013 08:47:03 -0700 (PDT) Received: from mail.nottheoilrig.com (mail.nottheoilrig.com [50.16.249.74]) by ietfa.amsl.com (Postfix) with ESMTP id F2F0311E8111 for ; Tue, 23 Jul 2013 08:47:02 -0700 (PDT) Received: from mail.nottheoilrig.com (localhost [127.0.0.1]) by mail.nottheoilrig.com (Postfix) with ESMTP id 58E1140BBB; Tue, 23 Jul 2013 15:47:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nottheoilrig.com; s=mail; t=1374594422; bh=9LWgVvCrX83JiCmZ0rygfF45moP3JvUHVK3sf4Czoaw=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=MF/ngrI0ofZ+o02nluh7q7w3JtLKEsrFyhQkPqlxc3VATMQp5J2poe01WCb3qumAy 6ZBp+4ZqcTmIgJirtix5U9X7dgZCIvkS3u4XzuZ1x06MUF+f9Gq/cBy1HhMbgqbvmw Cu74XpXMhaYXAwYAUgR3OCEnlD7SWZh//usmjlWQ= Received: from [192.168.0.11] (S0106c8fb26402908.ek.shawcable.net [24.66.136.12]) by mail.nottheoilrig.com (Postfix) with ESMTPSA; Tue, 23 Jul 2013 15:47:01 +0000 (UTC) Message-ID: <51EEA573.5020303@nottheoilrig.com> Date: Tue, 23 Jul 2013 08:46:59 -0700 From: Jack Bates <35nlv6@nottheoilrig.com> User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Ben Laurie References: <0lk3krz888.fsf@wjh.hardakers.net> <20130716151132.GD29420@mournblade.imrryr.org> <20130716160112.GG29420@mournblade.imrryr.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF DANE WG list Subject: Re: [dane] [internet-drafts@ietf.org] New Version Notification for draft-dukhovni-dane-ops-01.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 15:47:08 -0000 On 23/07/13 04:19 AM, Ben Laurie wrote: > > On 16 July 2013 17:01, Viktor Dukhovni > wrote: > > > It would help because if I don't follow your SHOULD NOT, then I would > > decline that certificate. As we have said before, we cannot allow > DANE > > to do an end-run around CT. There is no point in finding a way to fix > > the problem with one set of trusted third parties only to reintroduce > > it via another set of trusted third parties. > > You would decline all DANE self-signed 3 1 1 certificates. None > of them can be verified via CT. This removes one of the primary > use cases for DANE. So I stand by the observation that you basically > don't trust DANE (at least in its present form) regardless of CT. > > > This seems to me to miss the point. The problem is that if we allow DANE > to verify self-signed certs, what stops an attacker from taking over DNS > and using it to certify a self-signed cert for google.com > ? Could I upload a self-signed certificate to CT, and have CT add it to the log if it matched a DANE DNS record? Would that add any protection? CT normally checks that the certificate is rooted in a known CA certificate, to avoid logs being spammed into uselessness. Could it also accept self-signed certificates that match a DANE DNS record? If you take over DNS, you can probably get a certificate issued by some known CA? CT adds protection by requiring that certificate to be published, where it can be audited. If in addition to publishing a self-signed certificate with DANE, you also publish it with CT, does that similarly add any protection? Or is auditing CT just the same as auditing DNS? (Auditing that the DNS for google.com isn't compromised) From viktor1dane@dukhovni.org Tue Jul 23 09:10:48 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5046E21E809C for ; Tue, 23 Jul 2013 09:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQTE-lkCEbLq for ; Tue, 23 Jul 2013 09:10:43 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 224D821E80A1 for ; Tue, 23 Jul 2013 09:10:43 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 5A9F82AACA4; Tue, 23 Jul 2013 16:10:37 +0000 (UTC) Date: Tue, 23 Jul 2013 16:10:37 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130723161037.GW29420@mournblade.imrryr.org> References: <0lk3krz888.fsf@wjh.hardakers.net> <20130716151132.GD29420@mournblade.imrryr.org> <20130716160112.GG29420@mournblade.imrryr.org> <51EEA573.5020303@nottheoilrig.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51EEA573.5020303@nottheoilrig.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] [internet-drafts@ietf.org] New Version Notification for draft-dukhovni-dane-ops-01.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 16:10:48 -0000 On Tue, Jul 23, 2013 at 08:46:59AM -0700, Jack Bates wrote: > Could I upload a self-signed certificate to CT, and have CT add it > to the log if it matched a DANE DNS record? Would that add any > protection? To be useful, it would have to be submitted along with the chain of DNSKEY and RRSIG records that validated it. Otherwise one learns nothing (anyone can submit bogus certificates claiming they were matched by DANE and make the system useless). Note that there would also be little point in submitting the actual certificate, it is uniquely fingerprinted by the TLSA RRset and the domain owner could check that any log contains no unauthorized public key digests, ... more efficiently than looking for a certificate. Furthermore, there is not even much point in submitting the TLSA RRset, since if all the keys in the chain are legitimate, the actual record is sound and not needed in the log, provided the leaf key is not leaked to the attacker. The only thing that submitting the TLSA RRset audits is attacks that steal the leaf key of the domain owner. So we're back to DNSSEC transparency, with a question as to which records DNSSEC transparency would cover, just the chains of DS, DNSKEY and RRSIGs, or also security-related leaf records (TLSA, SMIMEA, SSHFP, ...). I don't known that covering all the leaf records would scale well. Note that attacks that compromise the domain owner's keys can equally compromise other elements of their infrastructure, CT is primarily about keeping 3rd parties honest. -- Viktor. From wjhns1@hardakers.net Tue Jul 23 09:38:44 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29C3F11E82DC for ; Tue, 23 Jul 2013 09:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQ8CHbsIch+J for ; Tue, 23 Jul 2013 09:38:39 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by ietfa.amsl.com (Postfix) with ESMTP id D6EE411E82CE for ; Tue, 23 Jul 2013 09:38:38 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:470:1f00:187:81ef:4eb5:ab94:3797]) by mail.hardakers.net (Postfix) with ESMTPSA id B622328EEE; Tue, 23 Jul 2013 09:38:26 -0700 (PDT) From: Wes Hardaker To: Ben Laurie References: <0lk3krz888.fsf@wjh.hardakers.net> <20130716151132.GD29420@mournblade.imrryr.org> <20130716160112.GG29420@mournblade.imrryr.org> Date: Tue, 23 Jul 2013 09:38:25 -0700 In-Reply-To: (Ben Laurie's message of "Tue, 23 Jul 2013 12:19:24 +0100") Message-ID: <0la9ldteny.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: IETF DANE WG list Subject: Re: [dane] [internet-drafts@ietf.org] New Version Notification for draft-dukhovni-dane-ops-01.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 16:38:44 -0000 Ben Laurie writes: > This seems to me to miss the point. The problem is that if we allow > DANE to verify self-signed certs, what stops an attacker from taking > over DNS and using it to certify a self-signed cert for google.com? I think the wording in the current draft doesn't explain the context very well, just like you agreed a while back that the wording in the CT document doesn't explain things well either in terms of when CT does apply. What I would like for the -ops draft to state clearly where dane applies and how it may or may not interact with CT. The reality is that CT and DANE are two very different models, and they interact heavily in odd ways and I think the end result is that we need a document that simply says "it probably won't help you to do both at once". Each has negative impacts on the other. The reality is that there are two different models. And *each* use case needs to pick one: CT: - Places trust in CAs, and their assurance statements - Trust in the audit records provided to logs by the CAs - Zones can check that no one else has issued certs they don't know about by checking the log (but requires everyone who cares to check the log) - Eventually does away self-signed certificates entirely in the long term future and requires registration with a CA when an application refuses anything not in a log - most vulnerable points: CAs and the audit logging systems DANE: - Places trust in DNSSEC - Requires DNSSEC to be deployed, but it's not deployed heavily yet - Allows for CA signed and self-signed infrastructures - Vulnerable point: the dns (insert a fake TLSA record and the game is won). Each protocol, or an implementation of a protocol must chose which model they trust. Simply put, if you trust the CT system then you don't do DANE. If you trust the DANE system, then it's pointless to trust CT (as you spelled out above). Each system must pick one. For the web with browsers, it's clear that browser and CA vendors want the CA/CT path. Great! Then DANE is not of consequence, because it won't be implemented. Thus the part in the DANE ops draft that talks about interaction with CT clearly does not apply, because the implementations won't be doing DANE in the first place. For the web with scripts (curl, etc), I could see command line options to select between them (--ct or --dane) so that the criteria can be picked at run-time. I'd love to see that preference radio dialog in a web browser too, but I'm not holding my breath. For SMTP, clearly DANE is the choice going forward both because the dominate implementations are selecting it and because the CA model can't work in a STARTTLS environment. Clearly, they shouldn't do CT at all. The draft, however, tries to discuss the oddball cases where people actually do attempt to use both. The security considerations section really needs a strong note that says if you trust in both, you end up in a situation that is broken. So don't do that. Pick one. Because you're right: turning on DANE support when CT is in play breaks CT. And clearly, CT breaks DANE because it rules out discoverable self-signed certs. Ideally, there should be a document that compares and contrasts and points all of this out. The problem, however, is that it shouldn't be in either a dane specific draft (like the dane-ops draft), nor should it be in a CT specific draft (not that there are any more coming). There is no "current" place to document the important elements of the choice that must be made for protocol designs and/or implementers. -- Wes Hardaker Parsons From benl@google.com Wed Jul 24 02:41:40 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDCA211E83D2 for ; Wed, 24 Jul 2013 02:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tx1Pv8dmxzi5 for ; Wed, 24 Jul 2013 02:41:40 -0700 (PDT) Received: from mail-oa0-x22e.google.com (mail-oa0-x22e.google.com [IPv6:2607:f8b0:4003:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 4D16E11E83D0 for ; Wed, 24 Jul 2013 02:41:36 -0700 (PDT) Received: by mail-oa0-f46.google.com with SMTP id h1so410988oag.5 for ; Wed, 24 Jul 2013 02:41:35 -0700 (PDT) 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 :content-type; bh=6smIGR6c6lRWCihDjhlkpOtJ7LuLTqSe7Z9zlcvX6i0=; b=YJ/2lZKQM6OMSNummGZ65nU3K01+JHxQQgNAkAcIvC1NRGo1yd4Uw3g3IA5BIkvrH+ wmlGEQK1igglNu/DSw+arfj2tHV/mkDSsLn6+tlrb9In+Eev1In2vvXYfdv3TK6NUdK2 jEveXGPbS6bJourGrYgNcJf2/nEFSVAdzcmx5ktnB56zxLfa031X3HZoBvIGu/uubY7H pbzx8Rf9JVhGkpaeAuQNjuK7RCGQnz7giFNSeiDzYPH7INoko/wBQ6mDmWb1TKROtKwC AKtmGFvBk1YG46Jy/6VMaFtYrSl0fEalFfkWTqdmcM6mPSsSDASjUt6UbGNO+PYpK8Oi WHGw== 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 :content-type:x-gm-message-state; bh=6smIGR6c6lRWCihDjhlkpOtJ7LuLTqSe7Z9zlcvX6i0=; b=agyHZJ/qe36mYTkh73No7aJOOFdgdm8fcesV47xiOJyLBY20yONIWK1BdL7jD30FxO iC8XVG/7q2dx5sTNKF2A1SZMrohy+EcthNBKVJe8xt5r1a6U73BtktAFMPLHXvx8bimm Er+4DufB0uhVC0nx6Lw0csnxPJV2kb9z6isoRRykOuz60VtpFoDd3WPceeZblkBiSyIW uHPlA4YEykdXjhiJUREpnXhVypmZod4XrotPn3Ai9w1S6inOgqxnw/2Cdf9lJM/jzclD BMadoEFF63jrTn5nGWaoNGBKir1xqXqeFOpAGmSa31qQoxBCBBuJZNc9hQ1HprGFgEM+ /Y+A== MIME-Version: 1.0 X-Received: by 10.43.1.134 with SMTP id nq6mr19679321icb.55.1374658895712; Wed, 24 Jul 2013 02:41:35 -0700 (PDT) Received: by 10.64.100.207 with HTTP; Wed, 24 Jul 2013 02:41:35 -0700 (PDT) In-Reply-To: <20130723145432.GT29420@mournblade.imrryr.org> References: <0lk3krz888.fsf@wjh.hardakers.net> <20130716151132.GD29420@mournblade.imrryr.org> <20130716160112.GG29420@mournblade.imrryr.org> <20130723145432.GT29420@mournblade.imrryr.org> Date: Wed, 24 Jul 2013 10:41:35 +0100 Message-ID: From: Ben Laurie To: IETF DANE WG list Content-Type: multipart/alternative; boundary=bcaec51619852ac33c04e23eb7c2 X-Gm-Message-State: ALoCoQkCmCXku4NiIU1YrZuhsx+9aep13N+8ecEfE++6R+GKR+g1KC/5Y+53IvlF8kGQ5+t8BBkMqG7Ma3eqNV4Ub4ISVJZPx+D9VHKGYvqnr/m0MMkr3E+xXxQXQnyZ+i0oAkc5wuWOVtjDCYpIUk5b/BFLdod5ka+Cml0D+D6Xn8JekLARwZD6yaPBrb20HB+pduAaR9oN Subject: Re: [dane] [internet-drafts@ietf.org] New Version Notification for draft-dukhovni-dane-ops-01.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 09:41:41 -0000 --bcaec51619852ac33c04e23eb7c2 Content-Type: text/plain; charset=ISO-8859-1 On 23 July 2013 15:54, Viktor Dukhovni wrote: > On Tue, Jul 23, 2013 at 12:19:24PM +0100, Ben Laurie wrote: > > > On 16 July 2013 17:01, Viktor Dukhovni wrote: > > > > > > It would help because if I don't follow your SHOULD NOT, then I would > > > > decline that certificate. As we have said before, we cannot allow > DANE > > > > to do an end-run around CT. There is no point in finding a way to fix > > > > the problem with one set of trusted third parties only to reintroduce > > > > it via another set of trusted third parties. > > > > > > You would decline all DANE self-signed 3 1 1 certificates. None > > > of them can be verified via CT. This removes one of the primary > > > use cases for DANE. So I stand by the observation that you basically > > > don't trust DANE (at least in its present form) regardless of CT. > > > > This seems to me to miss the point. The problem is that if we allow DANE > to > > verify self-signed certs, what stops an attacker from taking over DNS and > > using it to certify a self-signed cert for google.com? > > - If you don't trust "IN TLSA 3 1 1", you don't trust DANE, > but there is no DANE without "3 1 1", the majority of published > TLSA RRsets will be "3 1 1". > > It sure looks like the major browsers are not in a hurry to implement > DANE, which is ironic, since RFC 6698 is mostly focused on > browser-like > applications, and needs adjustments for protocols like SMTP, where > DANE will be actively implemented first. > SMTP starts from a position of no assurance at all, so even DANE improves it. > > We're in violent agreement, you don't trust DNSSEC/DANE. > You don't have to implement DANE. > > - With "3 1 1" the attacker would in no sense certify a > self-signed cert for "google.com", they would temporarily > bind a set public keys to a specific set of TLS service > endpoints (e.g. _25._tcp.smtp.gmail.com), this binding trusted > by applications that (are configured to) trust DNSSEC. > > - "Taking over DNS" (really DNSSEC) is not that simple, why do you > believe that "taking over DNS" is easier than compromising the > user's desktop or the target server or bribe an employee with > access to the server keys, or infect the employee's desktop. > Two points: 1. I believe it because I see DNS getting taken over on a regular basis - perhaps not as often as user's desktops are taken over, but then, targeted attacks are not the only attacks. And not all desktops are equally vulnerable. 2. Just because an attack is not the easiest attack, that does not mean we should not defend against it. > > - You're proposing DNSSEC transparency, which would be similar > in spirit to the recently published spec for X.509 CT. That's > cool. The substance of the draft language Wes and I propose is > to explain that X.509 CT is fundamentally at odds with DANE. > What it says, though, is that DANE trumps CT, which is not really the position. > > There will in the majority of cases be no issuing CA for the > certificates of DANE validated servers. And if there is one, > it will typically not be a public CA. > > The real chain of trust with DANE is the sequence of DS, > DNSKEY and RRSIG records from the root down to the domain, > not any chain of X.509 certificate signatures. So if you > want accountability for DANE along the lines of CT, I would > support your future work on transparency for DNSSEC. I don't > know whether this is likely to lead to a usable, politically > acceptable standard and ultimately deployed standard, but you > may as well try. > > -- > Viktor. > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > --bcaec51619852ac33c04e23eb7c2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 23 July 2013 15:54, Viktor Dukhovni <viktor1dane@dukhovn= i.org> wrote:
On Tue, Jul 23, 2013 at 12= :19:24PM +0100, Ben Laurie wrote:

> On 16 July 2013 17:01, Viktor Dukhovni &l= t;viktor1dane@dukhovni.org&= gt; wrote:
>
> > > It would help because if I don't follow your SHOULD NOT,= then I would
> > > decline that certificate. As we have said before, we cannot = allow DANE
> > > to do an end-run around CT. There is no point in finding a w= ay to fix
> > > the problem with one set of trusted third parties only to re= introduce
> > > it via another set of trusted third parties.
> >
> > You would decline all DANE self-signed 3 1 1 certificates. =A0Non= e
> > of them can be verified via CT. =A0This removes one of the primar= y
> > use cases for DANE. =A0So I stand by the observation that you bas= ically
> > don't trust DANE (at least in its present form) regardless of= CT.
>
> This seems to me to miss the point. The problem is that if we allow DA= NE to
> verify self-signed certs, what stops an attacker from taking over DNS = and
> using it to certify a self-signed cert for google.com?

=A0 =A0 - If you don't trust "IN TLSA 3 1 1", you= don't trust DANE,
=A0 =A0 =A0 but there is no DANE without "3 1 1", the majority of= published
=A0 =A0 =A0 TLSA RRsets will be "3 1 1".

=A0 =A0 =A0 It sure looks like the major browsers are not in a hurry to imp= lement
=A0 =A0 =A0 DANE, which is ironic, since RFC 6698 is mostly focused on brow= ser-like
=A0 =A0 =A0 applications, and needs adjustments for protocols like SMTP, wh= ere
=A0 =A0 =A0 DANE will be actively implemented first.
<= br>
SMTP starts from a position of no assurance at all, so even D= ANE improves it.
=A0

=A0 =A0 =A0 We're in violent agreement, you don't trust DNSSEC/DANE= .
=A0 =A0 =A0 You don't have to implement DANE.

=A0 =A0 - With "3 1 1" the attacker would in no sense certify a =A0 =A0 =A0 self-signed cert for "google.com", they would temporarily
=A0 =A0 =A0 bind a set public keys to a specific set of TLS service
=A0 =A0 =A0 endpoints (e.g. =A0_25._tcp.smtp.gmail.com), this binding trusted
=A0 =A0 =A0 by applications that (are configured to) trust DNSSEC.

=A0 =A0 - "Taking over DNS" (really DNSSEC) is not that simple, w= hy do you
=A0 =A0 =A0 believe that "taking over DNS" is easier than comprom= ising the
=A0 =A0 =A0 user's desktop or the target server or bribe an employee wi= th
=A0 =A0 =A0 access to the server keys, or infect the employee's desktop= .

Two points:

= 1. I believe it because I see DNS getting taken over on a regular basis - p= erhaps not as often as user's desktops are taken over, but then, target= ed attacks are not the only attacks. And not all desktops are equally vulne= rable.

2. Just because an attack is not the easiest attack, th= at does not mean we should not defend against it.
=A0

=A0 =A0 - You're proposing DNSSEC transparency, which would be similar<= br> =A0 =A0 =A0 in spirit to the recently published spec for X.509 CT. =A0That&= #39;s
=A0 =A0 =A0 cool. =A0The substance of the draft language Wes and I propose = is
=A0 =A0 =A0 to explain that X.509 CT is fundamentally at odds with DANE.

What it says, though, is that DANE trumps= CT, which is not really the position.
=A0

=A0 =A0 =A0 There will in the majority of cases be no issuing CA for the =A0 =A0 =A0 certificates of DANE validated servers. =A0And if there is one,=
=A0 =A0 =A0 it will typically not be a public CA.

=A0 =A0 =A0 The real chain of trust with DANE is the sequence of DS,
=A0 =A0 =A0 DNSKEY and RRSIG records from the root down to the domain,
=A0 =A0 =A0 not any chain of X.509 certificate signatures. =A0So if you
=A0 =A0 =A0 want accountability for DANE along the lines of CT, I would
=A0 =A0 =A0 support your future work on transparency for DNSSEC. =A0I don&#= 39;t
=A0 =A0 =A0 know whether this is likely to lead to a usable, politically =A0 =A0 =A0 acceptable standard and ultimately deployed standard, but you =A0 =A0 =A0 may as well try.

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

--bcaec51619852ac33c04e23eb7c2-- From benl@google.com Wed Jul 24 02:47:31 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0A3E11E839F for ; Wed, 24 Jul 2013 02:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJrbvRc3FZXr for ; Wed, 24 Jul 2013 02:47:31 -0700 (PDT) Received: from mail-oa0-x236.google.com (mail-oa0-x236.google.com [IPv6:2607:f8b0:4003:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id E8E6D11E839B for ; Wed, 24 Jul 2013 02:47:30 -0700 (PDT) Received: by mail-oa0-f54.google.com with SMTP id o6so414748oag.41 for ; Wed, 24 Jul 2013 02:47:30 -0700 (PDT) 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=xD/C6C88zdqCJrRPYjfBnsy5CaYcvgVKEXSrvlTqFMM=; b=kLQTW/RceLT6BW9+6Dk/TQxTdKyo84T8Cv6Y/J8IU2giAMapBDeDq1PPiur7whPPK9 uaAlSjIpD77mbweyPd1aCYtiWMAIpZV8eE6GTjqL2V1FnJi6/hBK1YkLmFNURK5073J7 nDg7qxtGUh6Fzorjn8PHTNnEA5Zbmefngs8Vhtwtjco886JEHsXpaK8Mjd07yPXx4aBq mfCFzwZJdHOThbzjIijYsIvtr+QdyjmunycF/XAFkCUMB1L4Pyde3SDu/vqwgpRUj3MQ S/x8Bv5KkTiAlHq2nh7FOiyw6kFQ9X8vcCsHNoXSguijwsU6TN9RfyoyX37g0Wxyd8cj KcgA== 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=xD/C6C88zdqCJrRPYjfBnsy5CaYcvgVKEXSrvlTqFMM=; b=KnvRAClk2e96fwCkpGR98PKUWkIvuzG5c1N/s6aThYAgD6f5SZHHICRbROtntp18po s6Fhsm5zDoJeUIzRPp7Kp7uYVqWP6Lt4dcAP1X4kov5cFLQ7VjTEGU3DsYgQE6EWXYV8 8pcH97h3f85HXiTRM9OISLWSsDEJGXprFADIYsgIftC0wpMGP2UijPKtm/ejTaQXx/5M H4FAHJe14wWlxfQFE3YfLz4WmRKD83GHdbEg9csPWNIaXnBHERgtiCiLMcSPw8s23elf Mkxl+z1gmDydUii3hLG2dSTeQH0k8jSNt09E8ke1DjTvlUfCAdUyd3Rw+k/yqRZjg4lK 7vww== MIME-Version: 1.0 X-Received: by 10.43.1.134 with SMTP id nq6mr19681138icb.55.1374659250388; Wed, 24 Jul 2013 02:47:30 -0700 (PDT) Received: by 10.64.100.207 with HTTP; Wed, 24 Jul 2013 02:47:30 -0700 (PDT) In-Reply-To: <0la9ldteny.fsf@wjh.hardakers.net> References: <0lk3krz888.fsf@wjh.hardakers.net> <20130716151132.GD29420@mournblade.imrryr.org> <20130716160112.GG29420@mournblade.imrryr.org> <0la9ldteny.fsf@wjh.hardakers.net> Date: Wed, 24 Jul 2013 10:47:30 +0100 Message-ID: From: Ben Laurie To: Wes Hardaker Content-Type: multipart/alternative; boundary=bcaec51619854ea13f04e23eccd9 X-Gm-Message-State: ALoCoQmvYqbVN6BK9MhriXzo407nL8Xr89LoeDVRayXQ91XP7PYIbmgrvq1iT43PJaJwEQf8gug17SEOIhYWANDiD+rQITTpDM15kmfLKgvbPNGNkEyQdgbD4LuTPcx+T8oaUUK7LAvh4FsSBk8hV/4Zkj4rMpZpjE/xhwBidwTmoAcax02V5xvR5+wow7+FF5CBXrUwx4A0 Cc: IETF DANE WG list Subject: Re: [dane] [internet-drafts@ietf.org] New Version Notification for draft-dukhovni-dane-ops-01.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 09:47:32 -0000 --bcaec51619854ea13f04e23eccd9 Content-Type: text/plain; charset=ISO-8859-1 On 23 July 2013 17:38, Wes Hardaker wrote: > Ben Laurie writes: > > > This seems to me to miss the point. The problem is that if we allow > > DANE to verify self-signed certs, what stops an attacker from taking > > over DNS and using it to certify a self-signed cert for google.com? > > I think the wording in the current draft doesn't explain the context > very well, just like you agreed a while back that the wording in the CT > document doesn't explain things well either in terms of when CT does > apply. What I would like for the -ops draft to state clearly where dane > applies and how it may or may not interact with CT. The reality is that > CT and DANE are two very different models, and they interact heavily in > odd ways and I think the end result is that we need a document that > simply says "it probably won't help you to do both at once". Each has > negative impacts on the other. > > The reality is that there are two different models. And *each* use case > needs to pick one: > > CT: > - Places trust in CAs, and their assurance statements > The whole point of CT is avoiding placing trust in anyone. > - Trust in the audit records provided to logs by the CAs > Again, no trust. > - Zones can check that no one else has issued certs they don't know > about by checking the log (but requires everyone who cares to > check the log) > A quibble, really, but: people who care can hire others to check for them - and I imagine this will be what happens for the most part. > - Eventually does away self-signed certificates entirely in the long > term future and requires registration with a CA when an > application refuses anything not in a log > One reason I would like to make DNSSEC/DANE an acceptable alternative is because it would be unfortunate to do away with self-signed certs. > - most vulnerable points: CAs and the audit logging systems > It depends what you mean by vulnerable - CAs vulnerability is mostly unchanged by CT, and logs are untrusted... > > DANE: > - Places trust in DNSSEC > - Requires DNSSEC to be deployed, but it's not deployed heavily yet > - Allows for CA signed and self-signed infrastructures > - Vulnerable point: the dns (insert a fake TLSA record and the game > is won). > > Each protocol, or an implementation of a protocol must chose which model > they trust. Simply put, if you trust the CT system then you don't do > DANE. Once more: the point of CT is you don't have to trust it. > If you trust the DANE system, then it's pointless to trust CT (as > you spelled out above). Each system must pick one. > > For the web with browsers, it's clear that browser and CA vendors want > the CA/CT path. Great! Then DANE is not of consequence, because it > won't be implemented. Thus the part in the DANE ops draft that talks > about interaction with CT clearly does not apply, because the > implementations won't be doing DANE in the first place. > > For the web with scripts (curl, etc), I could see command line options > to select between them (--ct or --dane) so that the criteria can be > picked at run-time. I'd love to see that preference radio dialog in a > web browser too, but I'm not holding my breath. > > For SMTP, clearly DANE is the choice going forward both because the > dominate implementations are selecting it and because the CA model > can't work in a STARTTLS environment. Clearly, they shouldn't do CT > at all. > Why is that clear? CT is perfectly applicable to SMTP - also, I don't understand why CAs can't work with STARTTLS? > > > The draft, however, tries to discuss the oddball cases where people > actually do attempt to use both. The security considerations section > really needs a strong note that says if you trust in both, you end up in > a situation that is broken. So don't do that. Pick one. Because > you're right: turning on DANE support when CT is in play breaks CT. And > clearly, CT breaks DANE because it rules out discoverable self-signed > certs. > > Ideally, there should be a document that compares and contrasts and > points all of this out. The problem, however, is that it shouldn't be > in either a dane specific draft (like the dane-ops draft), nor should it > be in a CT specific draft (not that there are any more coming). There > is no "current" place to document the important elements of the choice > that must be made for protocol designs and/or implementers. > > -- > Wes Hardaker > Parsons > --bcaec51619854ea13f04e23eccd9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 23 July 2013 17:38, Wes Hardaker <wjhns1@hardakers.net= > wrote:
Ben Laurie <benl@google.com> writes:

> This seems to me to miss the point. The problem is that if we allow > DANE to verify self-signed certs, what stops an attacker from taking > over DNS and using it to certify a self-signed cert for google.com?

I think the wording in the current draft doesn't explain the cont= ext
very well, just like you agreed a while back that the wording in the CT
document doesn't explain things well either in terms of when CT does apply. =A0What I would like for the -ops draft to state clearly where dane<= br> applies and how it may or may not interact with CT. =A0The reality is that<= br> CT and DANE are two very different models, and they interact heavily in
odd ways and I think the end result is that we need a document that
simply says "it probably won't help you to do both at once". = =A0Each has
negative impacts on the other.

The reality is that there are two different models. =A0And *each* use case<= br> needs to pick one:

=A0 CT:
=A0 =A0 - Places trust in CAs, and their assurance statements

The whole point of CT is avoiding placing trust in a= nyone.
=A0
=A0 =A0 - Trust in the audit records provided to logs by the CAs

Again, no trust.
=A0
=A0 =A0 - Zones can check that no one else has issued certs they don't = know
=A0 =A0 =A0 about by checking the log (but requires everyone who cares to =A0 =A0 =A0 check the log)

A quibble, r= eally, but: people who care can hire others to check for them - and I imagi= ne this will be what happens for the most part.
=A0
=A0 =A0 - Eventually does away self-signed certificates entirely in the lon= g
=A0 =A0 =A0 term future and requires registration with a CA when an
=A0 =A0 =A0 application refuses anything not in a log
=
One reason I would like to make DNSSEC/DANE an acceptable al= ternative is because it would be unfortunate to do away with self-signed ce= rts.
=A0
=A0 =A0 - most vulnerable points: CAs and the audit logging systems

It depends what you mean by vulnerable - CAs v= ulnerability is mostly unchanged by CT, and logs are untrusted...
=A0

=A0 DANE:
=A0 =A0 - Places trust in DNSSEC
=A0 =A0 - Requires DNSSEC to be deployed, but it's not deployed heavily= yet
=A0 =A0 - Allows for CA signed and self-signed infrastructures
=A0 =A0 - Vulnerable point: the dns (insert a fake TLSA record and the game=
=A0 =A0 =A0 is won).

Each protocol, or an implementation of a protocol must chose which model they trust. =A0Simply put, if you trust the CT system then you don't do=
DANE.

Once more: the point of CT is you don= 't have to trust it.
=A0
= =A0If you trust the DANE system, then it's pointless to trust CT (as you spelled out above). =A0Each system must pick one.

For the web with browsers, it's clear that browser and CA vendors want<= br> the CA/CT path. =A0Great! =A0Then DANE is not of consequence, because it won't be implemented. =A0Thus the part in the DANE ops draft that talks=
about interaction with CT clearly does not apply, because the
implementations won't be doing DANE in the first place.

For the web with scripts (curl, etc), I could see command line options
to select between them (--ct or --dane) so that the criteria can be
picked at run-time. =A0I'd love to see that preference radio dialog in = a
web browser too, but I'm not holding my breath.

For SMTP, clearly DANE is the choice going forward both because the
dominate implementations are selecting it and because the CA model
can't work in a STARTTLS environment. =A0Clearly, they shouldn't do= CT
at all.

Why is that clear? CT is perfec= tly applicable to SMTP - also, I don't understand why CAs can't wor= k with STARTTLS?
=A0


The draft, however, tries to discuss the oddball cases where people
actually do attempt to use both. =A0The security considerations section
really needs a strong note that says if you trust in both, you end up in a situation that is broken. =A0So don't do that. =A0Pick one. =A0Becaus= e
you're right: turning on DANE support when CT is in play breaks CT. =A0= And
clearly, CT breaks DANE because it rules out discoverable self-signed
certs.

Ideally, there should be a document that compares and contrasts and
points all of this out. =A0The problem, however, is that it shouldn't b= e
in either a dane specific draft (like the dane-ops draft), nor should it be in a CT specific draft (not that there are any more coming). =A0There is no "current" place to document the important elements of the c= hoice
that must be made for protocol designs and/or implementers.

--
Wes Hardaker
Parsons

--bcaec51619854ea13f04e23eccd9-- From stephen.farrell@cs.tcd.ie Wed Jul 24 02:58:29 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 661A911E839B for ; Wed, 24 Jul 2013 02:58: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e10W-zILpxLh for ; Wed, 24 Jul 2013 02:58:18 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0CEF211E8156 for ; Wed, 24 Jul 2013 02:58:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B0B99BE97; Wed, 24 Jul 2013 10:57:53 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvo-bjP+xmZq; Wed, 24 Jul 2013 10:57:53 +0100 (IST) Received: from [IPv6:2001:770:10:203:bdef:eca1:a64f:4f6a] (unknown [IPv6:2001:770:10:203:bdef:eca1:a64f:4f6a]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 91BF1BE6E; Wed, 24 Jul 2013 10:57:53 +0100 (IST) Message-ID: <51EFA521.5020608@cs.tcd.ie> Date: Wed, 24 Jul 2013 10:57:53 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Ben Laurie References: <0lk3krz888.fsf@wjh.hardakers.net> <20130716151132.GD29420@mournblade.imrryr.org> <20130716160112.GG29420@mournblade.imrryr.org> <0la9ldteny.fsf@wjh.hardakers.net> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF DANE WG list Subject: Re: [dane] [internet-drafts@ietf.org] New Version Notification for draft-dukhovni-dane-ops-01.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 09:58:29 -0000 On 07/24/2013 10:47 AM, Ben Laurie wrote: > One reason I would like to make DNSSEC/DANE an acceptable alternative is > because it would be unfortunate to do away with self-signed certs. I think that's an excellent reason fwiw. There are I guess a large number of web sites with self-signed certs that work just fine now, and making that work better somehow, rather than making 'em worse seems like a good goal. Even if making that situation better via DNSSEC might not be the easiest path one could imagine, its still well worth having the option worked out. S. From ondrej.sury@nic.cz Wed Jul 24 05:51:52 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCC6711E80F1 for ; Wed, 24 Jul 2013 05:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZzxXEIfZY+e for ; Wed, 24 Jul 2013 05:51:51 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id D77AA11E80E0 for ; Wed, 24 Jul 2013 05:51:50 -0700 (PDT) Received: from labs.ondrej.sury.ws.eth.9.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id B372B13FDFA; Wed, 24 Jul 2013 14:51:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1374670309; bh=VGwk301vzSlm2sZKm/2j86QFWz4hLlp1xzcKtPbZAtk=; h=From:Content-Type:Subject:Message-Id:Date:To:Mime-Version; b=nApddFJpY0vaswH1JSjShEiFPBYcSvPaQpKn3C+/FlqvjaqF5vjHvub5h5lfhqI6M sIGtC7VJgvdpEtN7SZoFKHVNgylNIXMGjxuTqn+1HxRjeNAcCli06Z9r3woxBu2+Mt CMxC/RoX95s50E1pO8Abrq1kZqzBXirFQ2Wftk0k= From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= Content-Type: multipart/signed; boundary="Apple-Mail=_BD798282-946C-4F83-B4A5-5CFD9E848863"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: <05487DD9-BC5E-4B28-A154-6ED3739DE8F2@nic.cz> Date: Wed, 24 Jul 2013 14:51:47 +0200 To: dane@ietf.org list , Wes Hardaker , Olafur Gudmundsson Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1784.1\)) X-Mailer: Apple Mail (2.1784.1) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Subject: [dane] Agenda of IETF 87 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jul 2013 12:51:52 -0000 --Apple-Mail=_BD798282-946C-4F83-B4A5-5CFD9E848863 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hey DANE WG and Wes & Olafur, I have uploaded Agenda v0 to the IETF site: http://www.ietf.org/proceedings/87/agenda/agenda-87-dane Please review and if you want to have any changes, feel free to ping me = or Warren. O. -- Ond=C5=99ej Sur=C3=BD -- Chief Science Officer ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- --Apple-Mail=_BD798282-946C-4F83-B4A5-5CFD9E848863 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMKTCCBgYw ggTuoAMCAQICAQIwDQYJKoZIhvcNAQEFBQAwga8xCzAJBgNVBAYTAk5MMSAwHgYDVQQKExdUcnVz dGVkIEludHJvZHVjZXIgKFRJKTEgMB4GA1UECxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxMzAx BgNVBAMTKlRydXN0ZWQgSW50cm9kdWNlciAoVEkpIFRvcGxldmVsIENBIC0gRzAwMTEnMCUGCSqG SIb3DQEJARYYY2FAdHJ1c3RlZC1pbnRyb2R1Y2VyLm5sMB4XDTA0MTIwNzEwMzYxN1oXDTMwMTIw NjAwMDAwMFowga0xCzAJBgNVBAYTAk5MMSAwHgYDVQQKExdUcnVzdGVkIEludHJvZHVjZXIgKFRJ KTEgMB4GA1UECxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxMTAvBgNVBAMTKFRydXN0ZWQgSW50 cm9kdWNlciAoVEkpIENsaWVudCBDQSAtIEcwMDExJzAlBgkqhkiG9w0BCQEWGGNhQHRydXN0ZWQt aW50cm9kdWNlci5ubDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOKQxMR3KDUpfJBz AhY2BPCByKo9SMp/V0RIboLBD6vO0miSYO9FmP3Q07OKPYR5WdlQyrpKqB1zl0SRz2cDjnYkzvDF vK5kvMvlTYeQlHypQlvhkTsYWD4ZZxxEhAYBb1s7cYaIahLw6H/RZz+kyWTOc9TncPBvBWIQ1Ypo S+uQqpopH8s5ebtB/17SbUty5yXiHoaPh/ScdMKqxbyJiL0YRM6SU4YX4HVZ5YGS9aWuiUSiA0YF 8dCR56nErx67wgq8O1GtsSKKOf/ueUxSmrqwgQNlfM9Or5O8kb61s1O2iACHtixoV3ENanylBafU mRYpNo5tSZsElGfntMoGBy8CAwEAAaOCAiswggInMB0GA1UdDgQWBBSeX93lU8ExaSlN1ZaXxfOP h2iHTjCB3AYDVR0jBIHUMIHRgBRdbehwJx/8iwlxnguJECc7MUXvoqGBtaSBsjCBrzELMAkGA1UE BhMCTkwxIDAeBgNVBAoTF1RydXN0ZWQgSW50cm9kdWNlciAoVEkpMSAwHgYDVQQLExdDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTEzMDEGA1UEAxMqVHJ1c3RlZCBJbnRyb2R1Y2VyIChUSSkgVG9wbGV2 ZWwgQ0EgLSBHMDAxMScwJQYJKoZIhvcNAQkBFhhjYUB0cnVzdGVkLWludHJvZHVjZXIubmyCAQAw DwYDVR0TAQH/BAUwAwEB/zAjBgNVHRIEHDAagRhjYUB0cnVzdGVkLWludHJvZHVjZXIubmwwgasG A1UdHwSBozCBoDBOoEygSoZIaHR0cDovL2NybDEudHJ1c3RlZC1pbnRyb2R1Y2VyLm5sL2NhL3g1 MDkvZzEvZGF0YS9jcmxzL2NybC1yb290LWNhLTEuY3JsME6gTKBKhkhodHRwOi8vY3JsMi50cnVz dGVkLWludHJvZHVjZXIubmwvY2EveDUwOS9nMS9kYXRhL2NybHMvY3JsLXJvb3QtY2EtMS5jcmww IwYDVR0RBBwwGoEYY2FAdHJ1c3RlZC1pbnRyb2R1Y2VyLm5sMAsGA1UdDwQEAwIBBjARBglghkgB hvhCAQEEBAMCAAcwDQYJKoZIhvcNAQEFBQADggEBAI1sC2l8st3ElC74az6gH7tGXSiS7jicpHeI 10A3KY+7OEPT7BAJDpjMXxSvAwU1vBDFfwEAXGj42xAPB6cynOTDn0OiFpYGvi3EZV3khXYkGPLs fxZttUyDKqhXcWYy4nnI3fBxqCgLboJFw6OO/SVj5qQdXMZ7VhyFBWJMQkVOnlt6i3xFkG3O5LMI BDmdL5bZPEe8b6bJkMr+rUYEvorPJmV+CkiewYMaruCbdhwRkpkhXB3qLwB2ppnKxSinAU4f9Rcp p73h8iDVQ9389iliUKomVQqj9NJv2G6SyJdDQdN2vrldLszNpw6t+zIzCjpgQ//kem5BJ1k4YG3L CpAwggYbMIIFA6ADAgECAgIGSDANBgkqhkiG9w0BAQUFADCBrTELMAkGA1UEBhMCTkwxIDAeBgNV BAoTF1RydXN0ZWQgSW50cm9kdWNlciAoVEkpMSAwHgYDVQQLExdDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTExMC8GA1UEAxMoVHJ1c3RlZCBJbnRyb2R1Y2VyIChUSSkgQ2xpZW50IENBIC0gRzAwMTEn MCUGCSqGSIb3DQEJARYYY2FAdHJ1c3RlZC1pbnRyb2R1Y2VyLm5sMB4XDTEyMDgwMTA3NTEyNloX DTE0MDgwMTA3NTEyNlowejELMAkGA1UEBhMCTkwxGzAZBgNVBAoTElRydXN0ZWQgSW50cm9kdWNl cjEVMBMGA1UECxMMQ1ouTklDLUNTSVJUMRQwEgYDVQQDEwtPbmRyZWogU3VyeTEhMB8GCSqGSIb3 DQEJARYSb25kcmVqLnN1cnlAbmljLmN6MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA xlmN+hSg6RxWm1X6QOI3OXHSAqhRzWGb8ismR2+3LGDS640luS8x4VdWo490Ceqz+BZvMhQJwfny 9mb0IejFpx7kBOM7k2rMfOYUXa/pq07ysWEI8bXDcXRBf2ZcG0B/gajLPFA9MADlCWHSf7cNZF6S XnIHwTn5DowxpbF403NqLWFnTM08wTJkFgGB7WZAtE6KoSigztI39NrtKRsnosZoBMNZS/JG1CLt VdZPvkHVuiVQWEGYgswBEMGXoR7jtzVNhHr2F1atoBICJVGWFNA8fHvQRLAcXWJTXhKxb2uSq9Yp kKaZPZ6rrp88qtemvwVnQKE9r3/iPFeTARY7AQIDAQABo4ICdTCCAnEwDAYDVR0TAQH/BAIwADAd BgNVHQ4EFgQUgizwG0IeMZQlCSduLVeM1zDBdUEwgdwGA1UdIwSB1DCB0YAUnl/d5VPBMWkpTdWW l8Xzj4doh06hgbWkgbIwga8xCzAJBgNVBAYTAk5MMSAwHgYDVQQKExdUcnVzdGVkIEludHJvZHVj ZXIgKFRJKTEgMB4GA1UECxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxMzAxBgNVBAMTKlRydXN0 ZWQgSW50cm9kdWNlciAoVEkpIFRvcGxldmVsIENBIC0gRzAwMTEnMCUGCSqGSIb3DQEJARYYY2FA dHJ1c3RlZC1pbnRyb2R1Y2VyLm5sggECMCMGA1UdEgQcMBqBGGNhQHRydXN0ZWQtaW50cm9kdWNl ci5ubDAdBgNVHREEFjAUgRJvbmRyZWouc3VyeUBuaWMuY3owCwYDVR0PBAQDAgSwMCcGA1UdJQQg MB4GCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwEQYJYIZIAYb4QgEBBAQDAgSwMIHVBgNV HR8Egc0wgcowY6BhoF+GXWh0dHA6Ly9jcmwxLnRydXN0ZWQtaW50cm9kdWNlci5ubC9jYS94NTA5 L2cxL2NhLXNzbC1jbGllbnQvZzEvZGF0YS9jcmxzL2NybC1jbGllbnQtY2EtMS0xLmNybDBjoGGg X4ZdaHR0cDovL2NybDIudHJ1c3RlZC1pbnRyb2R1Y2VyLm5sL2NhL3g1MDkvZzEvY2Etc3NsLWNs aWVudC9nMS9kYXRhL2NybHMvY3JsLWNsaWVudC1jYS0xLTEuY3JsMA0GCSqGSIb3DQEBBQUAA4IB AQAZP/dznHW3BWajBVQ3fTaDsx/3csUE6+jX83r1dgzYjUOmapOzXQVZ2/VTwZTzJSsD7rDgzUN6 sk6YWmUJOwqoEcPasYG9zt9e+bpwc/PURjSowb+WjEE2e4L47x3mPgL0dtlGj4guhRaj247K9N1f grvlyX0h/IL9JO4CN0I5lAuOaZ3Yfl0euHpHLlXZ9czxkc6dCbtGSZwr3RrltNmMjhp0O3D51fDd D6mG1vvOEV9Kj1JfSE2cQI5j3GpMlNleZA6noZ93drs2G9/D7WP4uVLCtJfGmG6PJsy4+qN46qXu ekJR/8WH1aNcH0Ya+JsYrwIFPwL4Cr+JXrbFqUOFMYIDzzCCA8sCAQEwgbQwga0xCzAJBgNVBAYT Ak5MMSAwHgYDVQQKExdUcnVzdGVkIEludHJvZHVjZXIgKFRJKTEgMB4GA1UECxMXQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkxMTAvBgNVBAMTKFRydXN0ZWQgSW50cm9kdWNlciAoVEkpIENsaWVudCBD QSAtIEcwMDExJzAlBgkqhkiG9w0BCQEWGGNhQHRydXN0ZWQtaW50cm9kdWNlci5ubAICBkgwCQYF Kw4DAhoFAKCCAe8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMw NzI0MTI1MTQ5WjAjBgkqhkiG9w0BCQQxFgQUte4cxpoSXB6nViB0eddfJS30rhEwgcUGCSsGAQQB gjcQBDGBtzCBtDCBrTELMAkGA1UEBhMCTkwxIDAeBgNVBAoTF1RydXN0ZWQgSW50cm9kdWNlciAo VEkpMSAwHgYDVQQLExdDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTExMC8GA1UEAxMoVHJ1c3RlZCBJ bnRyb2R1Y2VyIChUSSkgQ2xpZW50IENBIC0gRzAwMTEnMCUGCSqGSIb3DQEJARYYY2FAdHJ1c3Rl ZC1pbnRyb2R1Y2VyLm5sAgIGSDCBxwYLKoZIhvcNAQkQAgsxgbeggbQwga0xCzAJBgNVBAYTAk5M MSAwHgYDVQQKExdUcnVzdGVkIEludHJvZHVjZXIgKFRJKTEgMB4GA1UECxMXQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxMTAvBgNVBAMTKFRydXN0ZWQgSW50cm9kdWNlciAoVEkpIENsaWVudCBDQSAt IEcwMDExJzAlBgkqhkiG9w0BCQEWGGNhQHRydXN0ZWQtaW50cm9kdWNlci5ubAICBkgwDQYJKoZI hvcNAQEBBQAEggEANmwAm5gm9WRq1/HcdEeGAA57xLJ1tbxKmZjVD5lATuTbfdA1cDmucBdYxaXU CVqVyJh+igyotpKLQE8fxxJKzRn3QpN+hehbpwcG3QmrmNNAYSkNSVOvtJdA8VTrt1DNnIo9ukP3 6fZAG+OC+fy0HS5y6J4ImIlnzmdayGQxqgIlEcl4u108VORj7a+mbYkqOx1ar8GqBwWvT5O3oqeg snIXk2VeauP2RhPxUAurZ2q20JqbCVvmoSti0PsJej83sU0Y74wODvdvjgZA7vZIKSrDbPJqYfME KuLaRcmvgoiBnb1c/zcr7WBPI9VW7TzEaK/cf/e3zIVmxSDQdKcgNQAAAAAAAA== --Apple-Mail=_BD798282-946C-4F83-B4A5-5CFD9E848863-- From viktor1dane@dukhovni.org Wed Jul 24 07:11:32 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F11911E8104 for ; Wed, 24 Jul 2013 07:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9uoUNZOmicR for ; Wed, 24 Jul 2013 07:11:02 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id D1D1F11E8106 for ; Wed, 24 Jul 2013 07:10:16 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 5A39E2AAD0E; Wed, 24 Jul 2013 14:10:12 +0000 (UTC) Date: Wed, 24 Jul 2013 14:10:12 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130724141012.GB29420@mournblade.imrryr.org> References: <0lk3krz888.fsf@wjh.hardakers.net> <20130716151132.GD29420@mournblade.imrryr.org> <20130716160112.GG29420@mournblade.imrryr.org> <0la9ldteny.fsf@wjh.hardakers.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] [internet-drafts@ietf.org] New Version Notification for draft-dukhovni-dane-ops-01.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 14:11:32 -0000 On Wed, Jul 24, 2013 at 10:47:30AM +0100, Ben Laurie wrote: > > - Eventually does away self-signed certificates entirely in the long > > term future and requires registration with a CA when an > > application refuses anything not in a log > > One reason I would like to make DNSSEC/DANE an acceptable alternative is > because it would be unfortunate to do away with self-signed certs. I generate a self-signed certificate and publish: _25._tcp.mx.example.com. IN TLSA 3 1 1 how is a TLS-enabled SMTP client to apply CT in this situation? My reading of 6962 (particularly the text I took the liberty to shout out in upper case): Each log consists of certificate chains, which can be submitted by anyone. It is expected that public CAs will contribute all their newly issued certificates to one or more logs; it is also expected that certificate holders will contribute their own certificate chains. In order to avoid logs being spammed into uselessness, IT IS REQUIRED THAT EACH CHAIN IS ROOTED IN A KNOWN CA CERTIFICATE. When a chain is submitted to a log, a signed timestamp is returned, which can later be used to provide evidence to clients that the chain has been submitted. TLS clients can thus require that all certificates they see have been logged. is that it it impossible to apply X.509 certificate chain transparency here. What am I missing? If there were a DNSSEC transparency standard, it could well be applicable and would help with keeping the 1LDs, 2LDs, ... honest if there is a concern about unauthorized DS RRs being signed by parent zones. > > For SMTP, clearly DANE is the choice going forward both because the > > dominate implementations are selecting it and because the CA model > > can't work in a STARTTLS environment. Clearly, they shouldn't do CT > > at all. > > Why is that clear? CT is perfectly applicable to SMTP - also, I don't > understand why CAs can't work with STARTTLS? In the tiny fraction of cases where SMTP is compatible with PKIX, CT is then indeed compatible with SMTP. See: https://tools.ietf.org/html/draft-dukhovni-smtp-opportunistic-tls-01#section-1.2 The Simple Mail Transport Protocol (SMTP) ([RFC5321]) is multi-hop store & forward, while TLS security is hop-by-hop. The number of hops from the sender's Mail User Agent to the recipient mailbox is rarely less than 2 and is often higher. Some hops may be TLS protected, some may not. The same SMTP TCP endpoint can serve both TLS and non-TLS clients, with TLS negotiated via the SMTP STARTTLS command ([RFC3207]). MX RRs abstract hop destinations via DNS. SMTP addresses are not transport addresses and are security agnostic. Unlike HTTP, there is no URI scheme for email addresses to designate whether the SMTP server should be contacted with or without security. A Mail Transport Agent (MTA) may need to forward a message to a particular email recipient . To deliver the message, the MTA needs to retrieve the MX hosts of example.com from DNS, and then deliver the message to one of them. Absent DNSSEC, the MX lookup is vulnerable to man-in-the-middle and cache poisoning attacks. As a result, verifying MX host certificates without using DNSSEC is futile as the attacker can simply forge DNS replies and issue bogus MX records, directing traffic to a server of his choice. [ Given DNSSEC nomenclature, "bogus" is unfortunate above, we should say "fake", fixed in Git. ] One might try to harden STARTTLS with SMTP against DNS attacks by requiring each MX host to posess an X.509 certificate for the recipient domain that is obtained from the message envelope and is not subject to DNS reply forgery. Unfortunately, this is impractical, as email for many domains is handled by third parties, which are not in a position to obtain certificates for all the domains they serve. Deployment of SNI (see [RFC6066] Section 3.1) is no panacea, since the key management is operationally challenging at large scale unless the email service provider is also the domain's registrar and its certificate issuer; this is rarely the case for email. A man-in-the-middle can also suppress the MX host's STARTTLS EHLO response. Unless the sending MTA is statically configured to use TLS for mail sent to example.com, the message will be sent unauthenticated and in the clear. Sender-side configuration of peer- domains for which TLS must be used can protect an organization and a few of its business partners, but is not a viable approach to securing the Internet email backbone. Internet email requires contacting many new domains for which security configurations can not be established in advance. > > Each protocol, or an implementation of a protocol must chose which model > > they trust. Simply put, if you trust the CT system then you don't do > > DANE. > > Once more: the point of CT is you don't have to trust it. CT is part of the broader story of PKIX CAs, with CT to keep them honest. So a more clear statement could be that if one is doing PKIX with CT one is not doing DANE. Thus the dichotomy is between trusting DNSSEC + DANE vs. trusting a set of public CAs plus CT as an audit trail. So more to the point conversely, if one is doing DANE (which necessarily includes support for "IN TLSA 3 1 1" EE public keys) if this case is not protected by X.509 CT (please explain how it could be, perhaps we've missed some import detail of CT) then since attackers who compromise DNSSEC are free to choose "3 1 1", there is no defence against DNSSEC compromising attacks via CT. > > - most vulnerable points: CAs and the audit logging systems > > It depends what you mean by vulnerable - CAs vulnerability is mostly > unchanged by CT, and logs are untrusted... My incomplete reading of 6692 suggests that logs are "trusted" to not disclose their signing keys and to actually publish the data they've committed to publish. This is not the same as trusted to authenticate the peer, but it seems they are trusted to securely play their role in the protocol. -- Viktor. From viktor1dane@dukhovni.org Wed Jul 24 07:24:09 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D748A11E80F7 for ; Wed, 24 Jul 2013 07:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vkqx+D8BnStH for ; Wed, 24 Jul 2013 07:24:00 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id E589E11E80FC for ; Wed, 24 Jul 2013 07:23:59 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 4F4752AAD0E; Wed, 24 Jul 2013 14:23:33 +0000 (UTC) Date: Wed, 24 Jul 2013 14:23:33 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130724142333.GC29420@mournblade.imrryr.org> References: <0lk3krz888.fsf@wjh.hardakers.net> <20130716151132.GD29420@mournblade.imrryr.org> <20130716160112.GG29420@mournblade.imrryr.org> <20130723145432.GT29420@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] [internet-drafts@ietf.org] New Version Notification for draft-dukhovni-dane-ops-01.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 14:24:09 -0000 On Wed, Jul 24, 2013 at 10:41:35AM +0100, Ben Laurie wrote: > > It sure looks like the major browsers are not in a hurry to implement > > DANE, which is ironic, since RFC 6698 is mostly focused on > > browser-like > > applications, and needs adjustments for protocols like SMTP, where > > DANE will be actively implemented first. > > > > SMTP starts from a position of no assurance at all, so even DANE improves > it. Yes, but the key observation is that PKIX cannot improve it absent DNSSEC (which must therefor be trusted, Wes will explain this in Berlin). So the *only* path to securing SMTP on Internet scale is with DANE. > > We're in violent agreement, you don't trust DNSSEC/DANE. > > You don't have to implement DANE. > > > > - With "3 1 1" the attacker would in no sense certify a > > self-signed cert for "google.com", they would temporarily > > bind a set public keys to a specific set of TLS service > > endpoints (e.g. _25._tcp.smtp.gmail.com), this binding trusted > > by applications that (are configured to) trust DNSSEC. > > > > - "Taking over DNS" (really DNSSEC) is not that simple, why do you > > believe that "taking over DNS" is easier than compromising the > > user's desktop or the target server or bribe an employee with > > access to the server keys, or infect the employee's desktop. > > > > Two points: > > 1. I believe it because I see DNS getting taken over on a regular basis - > perhaps not as often as user's desktops are taken over, but then, targeted > attacks are not the only attacks. And not all desktops are equally > vulnerable. Do you mean attacks on the client<->registrar authentication weak link? Hijacking of domains that are not registrar locked? Or DNS reply forgery? With DANE, as you know, we are assuming DNSSEC, so presumably the reply forgery attack is out of the picture. > > - You're proposing DNSSEC transparency, which would be similar > > in spirit to the recently published spec for X.509 CT. That's > > cool. The substance of the draft language Wes and I propose is > > to explain that X.509 CT is fundamentally at odds with DANE. > > What it says, though, is that DANE trumps CT, which is not really the > position. We are trying to say that clients that choose to trust DANE, can't benefit from CT, given the required support for DANE's primary use case: 3 1 1. Perhaps we failed to understand how to apply CT to this case. My reading of the CT RFC could well have glossed over some critical ingredient. How does CT work with EE self-signed certificates? Perhaps there is more to it than the text below indicates: https://tools.ietf.org/html/rfc6962#section-1 Each log consists of certificate chains, which can be submitted by anyone. It is expected that public CAs will contribute all their newly issued certificates to one or more logs; it is also expected that certificate holders will contribute their own certificate chains. In order to avoid logs being spammed into uselessness, it is required that each chain is rooted in a known CA certificate. When a chain is submitted to a log, a signed timestamp is returned, which can later be used to provide evidence to clients that the chain has been submitted. TLS clients can thus require that all certificates they see have been logged. -- Viktor. From benl@google.com Thu Jul 25 02:14:40 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B292221F9B0A for ; Thu, 25 Jul 2013 02:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zy-+7sJmX-8v for ; Thu, 25 Jul 2013 02:14:40 -0700 (PDT) Received: from mail-oa0-x22e.google.com (mail-oa0-x22e.google.com [IPv6:2607:f8b0:4003:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 1651421F9B03 for ; Thu, 25 Jul 2013 02:14:39 -0700 (PDT) Received: by mail-oa0-f46.google.com with SMTP id h1so3671140oag.5 for ; Thu, 25 Jul 2013 02:14:39 -0700 (PDT) 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 :content-type; bh=Q28tQnvoCXeC+42ANFOrEssdoCPgx8drBrJYbyCVMwg=; b=nBMSMfjg1jG33hxjWV7n4dh27CSWspH+irPjlqf7nHfp+K6z6alxjWFeO2YIHoLVHX XZVFNljzFnsgT2SZ2F8ygsT2z15CjDT9z71bE4pecifoNZvZNHXx5BYxJFa0dra0O02x XnVUJ0MdHHpMJsSF7wj5tmgd4SeqNrIpzOPv7uXf8o/t01lfas95Sq7ZP8u1wc3IDCRS EQJrECImoChh1jdz1iq3mCBbiPjj278wqC7Ct0D9g1XIXbBHhE/KyxyzyJVA1wJR9/pl XUoZ4f7tSRsL+iFr3oEjYzx524FjIianuA3vi8q0Ve/HBZOhJQ6oY7RMT2ufzI5+WH/B RJuQ== 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 :content-type:x-gm-message-state; bh=Q28tQnvoCXeC+42ANFOrEssdoCPgx8drBrJYbyCVMwg=; b=YzJP2R9ID8n6UUs1dasdKSyJMJX+zGGQL9P2bPwCFRSNpoAqpBSylkORwoQiBCKj+C XuiQm3+b0xDSoIyQREG9uWIj/4p6YIVBVOeslgD77RjrJFhFrwrv9Mo5fvBNkGBqfU7S 9uwZTmuqDsw/2eNgxBmlaIUk5xJxuYaatHk6QAlIF5Ced2YaK3Al3LucupRKqSEVCrWa 8R4pV7kcNDtOplWSH9DVbYexmb6RxUeqkvyn+sK1f1l8v2UYO11EJyfE77VNXBfYx3wN MsLSoF9feALxMBkP3/XXw4mkrRjNvzFIsB+1rURNPMNg3VzmC7hYQGe+pfZ58lmzsDyP JebA== MIME-Version: 1.0 X-Received: by 10.43.1.134 with SMTP id nq6mr20181986icb.55.1374743679468; Thu, 25 Jul 2013 02:14:39 -0700 (PDT) Received: by 10.64.100.207 with HTTP; Thu, 25 Jul 2013 02:14:39 -0700 (PDT) In-Reply-To: <20130724141012.GB29420@mournblade.imrryr.org> References: <0lk3krz888.fsf@wjh.hardakers.net> <20130716151132.GD29420@mournblade.imrryr.org> <20130716160112.GG29420@mournblade.imrryr.org> <0la9ldteny.fsf@wjh.hardakers.net> <20130724141012.GB29420@mournblade.imrryr.org> Date: Thu, 25 Jul 2013 10:14:39 +0100 Message-ID: From: Ben Laurie To: IETF DANE WG list Content-Type: multipart/alternative; boundary=bcaec5161985ac335404e2527445 X-Gm-Message-State: ALoCoQnKwvctnwWov8sXvn3IbUkMp69nM5+XXcITjOpIrTT7ng0xpKewFFy46xnIipUU/e8539fNZWADpBTW6QnYZiu8rzXWl11WqjVQe61FWLhHtAz4lNzX0AObjneKCoQhZ8iEcv1Sij1Gm5JZup6nlG9idYuej0WfwzMy4Tb3YEeOwxjrFgIX9U5uP05tMBymKdZDQct+ Subject: Re: [dane] [internet-drafts@ietf.org] New Version Notification for draft-dukhovni-dane-ops-01.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 09:14:41 -0000 --bcaec5161985ac335404e2527445 Content-Type: text/plain; charset=ISO-8859-1 On 24 July 2013 15:10, Viktor Dukhovni wrote: > > > - most vulnerable points: CAs and the audit logging systems > > > > It depends what you mean by vulnerable - CAs vulnerability is mostly > > unchanged by CT, and logs are untrusted... > > My incomplete reading of 6692 suggests that logs are "trusted" to > not disclose their signing keys and to actually publish the data > they've committed to publish. This is not the same as trusted to > authenticate the peer, but it seems they are trusted to securely > play their role in the protocol. This is incorrect - if logs fail to publish (or otherwise fail to follow the protocol), this can be detected - no trust involved. Disclosing a log's signing keys would be unwise, because whoever has them might decide not to follow the protocol (indeed, it would be hard to correctly follow it without all key holders collaborating closely), in which case the log will no longer be usable. But one does not have to trust the log to not do this, again, abuse of the key can be detected. --bcaec5161985ac335404e2527445 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On 24 July 2013 15:10, Viktor Dukhovni <viktor1dane@dukhovni.org> wrote:
> > =A0 =A0 - most v= ulnerable points: CAs and the audit logging systems
>
> It depends what you mean by vulnerable - CAs vulnerability is mostly > unchanged by CT, and logs are untrusted...

My incomplete reading of 6692 suggests that logs are "trusted&qu= ot; to
not disclose their signing keys and to actually publish the data
they've committed to publish. =A0This is not the same as trusted to
authenticate the peer, but it seems they are trusted to securely
play their role in the protocol.

This is incorrect - = if logs fail to publish (or otherwise fail to follow the protocol), this ca= n be detected - no trust involved.

Disclosing a log's signing keys would be unw= ise, because whoever has them might decide not to follow the protocol (inde= ed, it would be hard to correctly follow it without all key holders collabo= rating closely), in which case the log will no longer be usable. But one do= es not have to trust the log to not do this, again, abuse of the key can be= detected.

--bcaec5161985ac335404e2527445-- From benl@google.com Thu Jul 25 02:21:24 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA4B421F9AE6 for ; Thu, 25 Jul 2013 02:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YmIjbol28YFN for ; Thu, 25 Jul 2013 02:21:24 -0700 (PDT) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id E886521F8607 for ; Thu, 25 Jul 2013 02:21:23 -0700 (PDT) Received: by mail-ob0-f170.google.com with SMTP id ef5so988702obb.29 for ; Thu, 25 Jul 2013 02:21:22 -0700 (PDT) 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 :content-type; bh=4e0s5e5RU5MvurIFeDwyydQ4u/YQFToK5P8SYeNgfy4=; b=jI3tgLWerXIQy+SKJ17LgPjCtimsqfXIOVoJgYlg0n/JfMhk8ETswD1BpWgKK2bFq5 1KEShromKHxlHSkp3ByPirWbu1ytavsb8SICz2ZgT0hYzydAaqXpfkTpnRe8f0l2f7hv uXehlKOwQRS7XZYEzswAOGoIGBBJ3bBEpRpeySgsagzgcDAB28pyQTa6khKsf44hUBS/ 1JS9AHUxH5MdIyRQpPT1uF0HWDcg7YcjzK/hCcZajbh2fQLkJt5A42ogIuSGxxp363p9 jvFyU+rXac/kIgORgKfuAqGLBfKVVnALAJ0oSwWL4obfqJ4/Zt6wAhqjjTv4Q+cPv81T HGmw== 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 :content-type:x-gm-message-state; bh=4e0s5e5RU5MvurIFeDwyydQ4u/YQFToK5P8SYeNgfy4=; b=TcojttWewikTcjUSPhzUxGL3LH8gZfVpvOvpMVTu9pDB4u0/1u2V8FlH4HF3hl8v07 0jBNqDruR+s6k7GxBfM6C4eXAGgpPgNPR1VgrpuAxU2vbJ/U8wr32rhBdQCssS5X22uK dx6EHpMmV4fN89wDxpNdjw/am4rOx4kjOiZMSkY+s7yFU3a3wHSdhzCMz4NJIJS7mkL8 mjI164BjA2G+Ebs46wRT3yixH4j0PqEzXzjzz5loo7rj93EMu+EV6IdjI9Xz6yvnwrHS neSaTqzsAZJFZS9AlEkFI5FPMkJFYm9yYolN0Gr3bUrRLkw017cdXgLs7h1V0r1Uj2a3 EMmg== MIME-Version: 1.0 X-Received: by 10.43.1.134 with SMTP id nq6mr20185134icb.55.1374744082820; Thu, 25 Jul 2013 02:21:22 -0700 (PDT) Received: by 10.64.100.207 with HTTP; Thu, 25 Jul 2013 02:21:22 -0700 (PDT) In-Reply-To: <20130724142333.GC29420@mournblade.imrryr.org> References: <0lk3krz888.fsf@wjh.hardakers.net> <20130716151132.GD29420@mournblade.imrryr.org> <20130716160112.GG29420@mournblade.imrryr.org> <20130723145432.GT29420@mournblade.imrryr.org> <20130724142333.GC29420@mournblade.imrryr.org> Date: Thu, 25 Jul 2013 10:21:22 +0100 Message-ID: From: Ben Laurie To: IETF DANE WG list Content-Type: multipart/alternative; boundary=bcaec5161985b6e2d504e2528c2a X-Gm-Message-State: ALoCoQn82IA0/ikBH7Pct5j+WgLEEnF1rPr5wQLBkxnrGswxi2faHp/u7SQKH7fvx+lm2jIaQ9Kig4fps8SJbOMDyrLmYRjZtCR3sPsxLpxTvTBot1fo7XKSNMm1VTNfiaYfZyvbAeiDKhybF+pSDRCA1BO6PlNPxaADzcU++3Ia0CBDrUSvsTs2+RVJ+1tv9gbVX05aA/Y4 Subject: Re: [dane] [internet-drafts@ietf.org] New Version Notification for draft-dukhovni-dane-ops-01.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 09:21:25 -0000 --bcaec5161985b6e2d504e2528c2a Content-Type: text/plain; charset=ISO-8859-1 On 24 July 2013 15:23, Viktor Dukhovni wrote: > On Wed, Jul 24, 2013 at 10:41:35AM +0100, Ben Laurie wrote: > > > > It sure looks like the major browsers are not in a hurry to > implement > > > DANE, which is ironic, since RFC 6698 is mostly focused on > > > browser-like > > > applications, and needs adjustments for protocols like SMTP, > where > > > DANE will be actively implemented first. > > > > > > > SMTP starts from a position of no assurance at all, so even DANE improves > > it. > > Yes, but the key observation is that PKIX cannot improve it absent > DNSSEC (which must therefor be trusted, Wes will explain this in > Berlin). So the *only* path to securing SMTP on Internet scale is > with DANE. > That is a strong claim which I find a little hard to swallow, certainly without some supporting evidence. > > > > We're in violent agreement, you don't trust DNSSEC/DANE. > > > You don't have to implement DANE. > > > > > > - With "3 1 1" the attacker would in no sense certify a > > > self-signed cert for "google.com", they would temporarily > > > bind a set public keys to a specific set of TLS service > > > endpoints (e.g. _25._tcp.smtp.gmail.com), this binding trusted > > > by applications that (are configured to) trust DNSSEC. > > > > > > - "Taking over DNS" (really DNSSEC) is not that simple, why do you > > > believe that "taking over DNS" is easier than compromising the > > > user's desktop or the target server or bribe an employee with > > > access to the server keys, or infect the employee's desktop. > > > > > > > Two points: > > > > 1. I believe it because I see DNS getting taken over on a regular basis - > > perhaps not as often as user's desktops are taken over, but then, > targeted > > attacks are not the only attacks. And not all desktops are equally > > vulnerable. > > Do you mean attacks on the client<->registrar authentication weak > link? Hijacking of domains that are not registrar locked? I mean attacks on registrars and registries. Registrar lock is not a magic spell that suddenly makes the DNS invulnerable. > Or DNS > reply forgery? > > With DANE, as you know, we are assuming DNSSEC, so presumably the > reply forgery attack is out of the picture. > Forgery attacks are available even in DNSSEC to the parent. > > > > - You're proposing DNSSEC transparency, which would be similar > > > in spirit to the recently published spec for X.509 CT. That's > > > cool. The substance of the draft language Wes and I propose is > > > to explain that X.509 CT is fundamentally at odds with DANE. > > > > What it says, though, is that DANE trumps CT, which is not really the > > position. > > We are trying to say that clients that choose to trust DANE, can't > benefit from CT, given the required support for DANE's primary use > case: 3 1 1. Perhaps we failed to understand how to apply CT to > this case. > No, I think you understand it correctly - and I think Wes has summed it up best: what we really need is a document that discusses tradeoffs between the two protocols. Or, really, what we need is a way to make DNSSEC stronger than PKIX (+ CT), not weaker, then this discussion would be moot. > > My reading of the CT RFC could well have glossed over some critical > ingredient. How does CT work with EE self-signed certificates? Perhaps > there is more to it than the text below indicates: > > https://tools.ietf.org/html/rfc6962#section-1 > > Each log consists of certificate chains, which can be submitted by > anyone. It is expected that public CAs will contribute all their > newly issued certificates to one or more logs; it is also expected > that certificate holders will contribute their own certificate > chains. In order to avoid logs being spammed into uselessness, it is > required that each chain is rooted in a known CA certificate. When a > chain is submitted to a log, a signed timestamp is returned, which > can later be used to provide evidence to clients that the chain has > been submitted. TLS clients can thus require that all certificates > they see have been logged. > > -- > Viktor. > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > --bcaec5161985b6e2d504e2528c2a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 24 July 2013 15:23, Viktor Dukhovni <viktor1dane@dukhovn= i.org> wrote:
On Wed, Jul 24, 2013 at 10= :41:35AM +0100, Ben Laurie wrote:

> > =A0 =A0 =A0 It sure looks like the major browsers are not in a hu= rry to implement
> > =A0 =A0 =A0 DANE, which is ironic, since RFC 6698 is mostly focus= ed on
> > browser-like
> > =A0 =A0 =A0 applications, and needs adjustments for protocols lik= e SMTP, where
> > =A0 =A0 =A0 DANE will be actively implemented first.
> >
>
> SMTP starts from a position of no assurance at all, so even DANE impro= ves
> it.

Yes, but the key observation is that PKIX cannot improve it absent DNSSEC (which must therefor be trusted, Wes will explain this in
Berlin). =A0So the *only* path to securing SMTP on Internet scale is
with DANE.

That is a strong claim which= I find a little hard to swallow, certainly without some supporting evidenc= e.
=A0

> > =A0 =A0 =A0 We're in violent agreement, you don't trust D= NSSEC/DANE.
> > =A0 =A0 =A0 You don't have to implement DANE.
> >
> > =A0 =A0 - With "3 1 1" the attacker would in no sense c= ertify a
> > =A0 =A0 =A0 self-signed cert for "google.com", they would temporarily
> > =A0 =A0 =A0 bind a set public keys to a specific set of TLS servi= ce
> > =A0 =A0 =A0 endpoints (e.g. =A0_25._tcp.smtp.gmail.com), this binding trusted > > =A0 =A0 =A0 by applications that (are configured to) trust DNSSEC= .
> >
> > =A0 =A0 - "Taking over DNS" (really DNSSEC) is not that= simple, why do you
> > =A0 =A0 =A0 believe that "taking over DNS" is easier th= an compromising the
> > =A0 =A0 =A0 user's desktop or the target server or bribe an e= mployee with
> > =A0 =A0 =A0 access to the server keys, or infect the employee'= ;s desktop.
> >
>
> Two points:
>
> 1. I believe it because I see DNS getting taken over on a regular basi= s -
> perhaps not as often as user's desktops are taken over, but then, = targeted
> attacks are not the only attacks. And not all desktops are equally
> vulnerable.

Do you mean attacks on the client<->registrar authentication we= ak
link? =A0Hijacking of domains that are not registrar locked?

I mean attacks on registrars and registries. Registrar lo= ck is not a magic spell that suddenly makes the DNS invulnerable.
=A0
=A0Or DNS
reply forgery?

With DANE, as you know, we are assuming DNSSEC, so presumably the
reply forgery attack is out of the picture.

=
Forgery attacks are available even in DNSSEC to the parent.
= =A0

> > =A0 =A0 - You're proposing DNSSEC transparency, which would b= e similar
> > =A0 =A0 =A0 in spirit to the recently published spec for X.509 CT= . =A0That's
> > =A0 =A0 =A0 cool. =A0The substance of the draft language Wes and = I propose is
> > =A0 =A0 =A0 to explain that X.509 CT is fundamentally at odds wit= h DANE.
>
> What it says, though, is that DANE trumps CT, which is not really the<= br> > position.

We are trying to say that clients that choose to trust DANE, can'= t
benefit from CT, given the required support for DANE's primary use
case: 3 1 1. =A0Perhaps we failed to understand how to apply CT to
this case.

No, I think you understand i= t correctly - and I think Wes has summed it up best: what we really need is= a document that discusses tradeoffs between the two protocols.

Or, really, what we need is a way to make DNSSEC stronger th= an PKIX (+ CT), not weaker, then this discussion would be moot.
= =A0

My reading of the CT RFC could well have glossed over some critical
ingredient. =A0How does CT work with EE self-signed certificates? Perhaps there is more to it than the text below indicates:

=A0 =A0https://tools.ietf.org/html/rfc6962#section-1

=A0 =A0Each log consists of certificate chains, which can be submitted by =A0 =A0anyone. =A0It is expected that public CAs will contribute all their<= br> =A0 =A0newly issued certificates to one or more logs; it is also expected =A0 =A0that certificate holders will contribute their own certificate
=A0 =A0chains. =A0In order to avoid logs being spammed into uselessne= ss, it is
=A0 =A0required that each chain is rooted in a known CA certificate. =A0Whe= n a
=A0 =A0chain is submitted to a log, a signed times= tamp is returned, which
=A0 =A0can later be used to provide evidence to clients that the chain has<= br> =A0 =A0been submitted. =A0TLS clients can thus require that all certificate= s
=A0 =A0they see have been logged.

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

--bcaec5161985b6e2d504e2528c2a-- From viktor1dane@dukhovni.org Thu Jul 25 10:26:38 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 457EF21F9956 for ; Thu, 25 Jul 2013 10:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-bc4-Jfmi0F for ; Thu, 25 Jul 2013 10:26:33 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id C081021F977A for ; Thu, 25 Jul 2013 10:26:32 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 448DE2AAD12; Thu, 25 Jul 2013 17:26:25 +0000 (UTC) Date: Thu, 25 Jul 2013 17:26:25 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130725172625.GE29420@mournblade.imrryr.org> References: <0lk3krz888.fsf@wjh.hardakers.net> <20130716151132.GD29420@mournblade.imrryr.org> <20130716160112.GG29420@mournblade.imrryr.org> <20130723145432.GT29420@mournblade.imrryr.org> <20130724142333.GC29420@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] [internet-drafts@ietf.org] New Version Notification for draft-dukhovni-dane-ops-01.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 17:26:38 -0000 On Thu, Jul 25, 2013 at 10:21:22AM +0100, Ben Laurie wrote: > > Yes, but the key observation is that PKIX cannot improve it absent > > DNSSEC (which must therefor be trusted, Wes will explain this in > > Berlin). So the *only* path to securing SMTP on Internet scale is > > with DANE. > > > > That is a strong claim which I find a little hard to swallow, certainly > without some supporting evidence. The supporting evidence is in the draft. SMTP security is inextricably bound to the security of DNS, if DNS is insecure, SMTP is compromised, thus DANE is the only reasonable security architecture for SMTP (for the Internet at large). - SMTP addresses are transport security agnostic, and STARTTLS discovery is subject to obvious MITM downgrade attacks. - SMTP addresses are end-to-end, TLS security is hop by hop, the security for a given hop must is necessarily out of band (not implied by the address). - MX records indirect from the recipient domain to the target server. Absent DNSSEC and barring a miraculously scalable implementation of SNI with every MX host holding certificates for the hosted domain (which may also let it impersonate web servers for the domain, ...) the SMTP client has no secure mechanism to perform certificate name checks. In short without DNSSEC the SMTP client does not have a secure copy of the server's name, and does not know whether the server supports TLS. DANE addresses both downgrade-resistant TLS *discovery* (does the peer support TLS), clarifies which name to expect in the peer's certificate (the TLSA base domain) and provides relevant key material to support authentication (MTAs often have empty or incomplete lists of root CAs, with DANE usage 2/3 an empty CA list works fine). -- Viktor. From marka@isc.org Thu Jul 25 15:19:10 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D79121F8F24 for ; Thu, 25 Jul 2013 15:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LETh+PUha8Qr for ; Thu, 25 Jul 2013 15:19:05 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id A59B521F8F32 for ; Thu, 25 Jul 2013 15:18:59 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 8E95BC947E; Thu, 25 Jul 2013 22:18:45 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1374790739; bh=lHSKvoCsFFjbQSxG0aSO4UtIkliObx0nCwosfJKFL0Y=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=lAdMWXH5t/C6D5Xj31YkLg2dBRhhhHMob3WH2tafOe90qULT/q2LIEQfiliqOAY6l p/++I0xaXhck0S2YxCS39GUYYSm7kTNallXdLRzNSbkqyk4DwLG0j9To/y4QwN2w0u OfnzUUzQnG+/IP1ZB35hztyBtMSBErH0jMRF9gpM= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Thu, 25 Jul 2013 22:18:45 +0000 (UTC) (envelope-from marka@isc.org) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 3B681160271; Thu, 25 Jul 2013 22:22:06 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id SPi1FtAxpV0b; Thu, 25 Jul 2013 22:22:05 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 3EBFF160270; Thu, 25 Jul 2013 22:22:05 +0000 (UTC) X-Virus-Scanned: amavisd-new at zmx1.isc.org Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 2jR-6UqpZvGk; Thu, 25 Jul 2013 22:22:05 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id E948B16026F; Thu, 25 Jul 2013 22:22:04 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 6BAE537AD193; Fri, 26 Jul 2013 08:18:32 +1000 (EST) To: Ben Laurie From: Mark Andrews References: <0lk3krz888.fsf@wjh.hardakers.net> <20130716151132.GD29420@mournblade.imrryr.org> <20130716160112.GG29420@mournblade.imrryr.org> <20130723145432.GT29420@mournblade.imrryr.org> <20130724142333.GC29420@mournblade.imrryr.org> In-reply-to: Your message of "Thu, 25 Jul 2013 10:21:22 +0100." Date: Fri, 26 Jul 2013 08:18:32 +1000 Message-Id: <20130725221832.6BAE537AD193@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: IETF DANE WG list Subject: Re: [dane] [internet-drafts@ietf.org] New Version Notification for draft-dukhovni-dane-ops-01.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 22:19:10 -0000 In message , Ben Laurie writes: > > On 24 July 2013 15:23, Viktor Dukhovni wrote: > > > On Wed, Jul 24, 2013 at 10:41:35AM +0100, Ben Laurie wrote: > > > > > > It sure looks like the major browsers are not in a hurry to > > implement > > > > DANE, which is ironic, since RFC 6698 is mostly focused on > > > > browser-like > > > > applications, and needs adjustments for protocols like SMTP, > > where > > > > DANE will be actively implemented first. > > > > > > > > > > SMTP starts from a position of no assurance at all, so even DANE improves > > > it. > > > > Yes, but the key observation is that PKIX cannot improve it absent > > DNSSEC (which must therefor be trusted, Wes will explain this in > > Berlin). So the *only* path to securing SMTP on Internet scale is > > with DANE. > > > > That is a strong claim which I find a little hard to swallow, certainly > without some supporting evidence. You need to secure the MX lookup. This is 100% dependent on DNSSEC working. After that DANE/PKIX can be used with STARTTLS. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From viktor1dane@dukhovni.org Thu Jul 25 15:36:52 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4069F21F8E70 for ; Thu, 25 Jul 2013 15:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-r96ez0lTlY for ; Thu, 25 Jul 2013 15:36:47 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA5D21F859A for ; Thu, 25 Jul 2013 15:36:46 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 8445F2AAD13; Thu, 25 Jul 2013 22:36:46 +0000 (UTC) Date: Thu, 25 Jul 2013 22:36:46 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130725223646.GH29420@mournblade.imrryr.org> References: <20130716151132.GD29420@mournblade.imrryr.org> <20130716160112.GG29420@mournblade.imrryr.org> <20130723145432.GT29420@mournblade.imrryr.org> <20130724142333.GC29420@mournblade.imrryr.org> <20130725221832.6BAE537AD193@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130725221832.6BAE537AD193@drugs.dv.isc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] [internet-drafts@ietf.org] New Version Notification for draft-dukhovni-dane-ops-01.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 22:36:52 -0000 On Fri, Jul 26, 2013 at 08:18:32AM +1000, Mark Andrews wrote: > > That is a strong claim which I find a little hard to swallow, certainly > > without some supporting evidence. > > You need to secure the MX lookup. This is 100% dependent on DNSSEC working. > After that DANE/PKIX can be used with STARTTLS. One also needs a downgrade-immune indication of STARTTLS support. And without DANE one has no idea what to expect to find in the server certificate, it may be and often is self-signed, ... Since trust in DNS is unavoidable, securing SMTP via DNSSEC is the only sensible thing to do. Throwing PKIX into the mix adds no value, if DNSSEC is compromised, game over. Thus the new SMTP draft you (those attending) will be discussing in Berlin. -- Viktor. From benl@google.com Fri Jul 26 01:33:40 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D444121F8618 for ; Fri, 26 Jul 2013 01:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwFnQCCXGUGA for ; Fri, 26 Jul 2013 01:33:40 -0700 (PDT) Received: from mail-oa0-x22e.google.com (mail-oa0-x22e.google.com [IPv6:2607:f8b0:4003:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id C22EF21F84E3 for ; Fri, 26 Jul 2013 01:33:39 -0700 (PDT) Received: by mail-oa0-f46.google.com with SMTP id h1so6775193oag.5 for ; Fri, 26 Jul 2013 01:33:39 -0700 (PDT) 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=5kW5msV+mqEhmLeqWq/0T+lMBm+gqU4/GRMCZvV90nM=; b=h+tPiqrFtPPmZ5oB4wLB2tlUNbpPIbpa1pYOmIQ6zfuhVcG179GNpIZstH+YZ4oY6Z bafiP8J7sV04iospNXdoA8XiU3/Ca/H7aKHdcAcOVl0ibu/Mnd5gUjT35ZuWwS0lIl3w uPj0lvQe+pTFEUsjAhi4x+qSIbYoLBL0ZMBkGNMl229Hdng1bIh4tWBldln7lkDWRKtB Rl04W0T+COT+5GaabpCU/LH+bH+9g+YoYVHZfvbd3lY4mIovQaT+8TXHkihjLQ9wUT34 lQYx3V7cjn8fKofH0BomflVET1jnBWkmOMD8iL8RHhFlsO5c3Iepya35+jRN5n0u4u6r rMug== 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=5kW5msV+mqEhmLeqWq/0T+lMBm+gqU4/GRMCZvV90nM=; b=opFvk7lFJFiCHq2LPNVZ6p3dYRW472+ZJyd3qmqSUI8G7md5w4xiUo302AgW6nQOuX mAzxW5wbKGoQblSoD8kSBwRmPMSIYiCEqrVqUAApT0d3fgv9Zl9e47BosvbKtqcbilu9 2or92DOsuDrijkvv65xZIZh4F5lM6lXgcqf/pfv+guG0NWEucm0pfB3M8bNE42/rD/Ks vlyA5xSv1e8qbd9g6zhzGddqCjyKf2sYeJcNiIrRYNk+9BFQ/cWp+8bh7ewEhUMCBq2G FKZ8Tk4OGloc1zbPEsAKQlh/Q/R0cpFwoYLpOj0Jn8q5OwXPIxCEOKxJxc4elpbqu1O2 hgsg== MIME-Version: 1.0 X-Received: by 10.43.1.134 with SMTP id nq6mr20758451icb.55.1374827619237; Fri, 26 Jul 2013 01:33:39 -0700 (PDT) Received: by 10.64.100.207 with HTTP; Fri, 26 Jul 2013 01:33:38 -0700 (PDT) In-Reply-To: <20130725221832.6BAE537AD193@drugs.dv.isc.org> References: <0lk3krz888.fsf@wjh.hardakers.net> <20130716151132.GD29420@mournblade.imrryr.org> <20130716160112.GG29420@mournblade.imrryr.org> <20130723145432.GT29420@mournblade.imrryr.org> <20130724142333.GC29420@mournblade.imrryr.org> <20130725221832.6BAE537AD193@drugs.dv.isc.org> Date: Fri, 26 Jul 2013 09:33:38 +0100 Message-ID: From: Ben Laurie To: Mark Andrews Content-Type: multipart/alternative; boundary=bcaec5161985df7cc704e265fffa X-Gm-Message-State: ALoCoQkw75QQyWSiC1RS1wTHt8ivHg0YbNffTX6seO8Gxx/NiEyCp7O4e8ywmTDimoE1GwZpZP46tv53PNJ2en3weQzgja/OVdgnKbGtWE72t5kSpbfVWSkJcbDbfjj/oz1layXmgMMCLt/Vd7+h43Jszyyw3+50dCJ+Do3rpieAFxUJS/fJ59QXVzSRl7B5Rd2agyg0mNFU Cc: IETF DANE WG list Subject: Re: [dane] [internet-drafts@ietf.org] New Version Notification for draft-dukhovni-dane-ops-01.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: Fri, 26 Jul 2013 08:33:40 -0000 --bcaec5161985df7cc704e265fffa Content-Type: text/plain; charset=ISO-8859-1 On 25 July 2013 23:18, Mark Andrews wrote: > > In message xPgwLZkJ0u9PGnmeRQ@mail.gmail.com> > , Ben Laurie writes: > > > > On 24 July 2013 15:23, Viktor Dukhovni wrote: > > > > > On Wed, Jul 24, 2013 at 10:41:35AM +0100, Ben Laurie wrote: > > > > > > > > It sure looks like the major browsers are not in a hurry to > > > implement > > > > > DANE, which is ironic, since RFC 6698 is mostly focused on > > > > > browser-like > > > > > applications, and needs adjustments for protocols like SMTP, > > > where > > > > > DANE will be actively implemented first. > > > > > > > > > > > > > SMTP starts from a position of no assurance at all, so even DANE > improves > > > > it. > > > > > > Yes, but the key observation is that PKIX cannot improve it absent > > > DNSSEC (which must therefor be trusted, Wes will explain this in > > > Berlin). So the *only* path to securing SMTP on Internet scale is > > > with DANE. > > > > > > > That is a strong claim which I find a little hard to swallow, certainly > > without some supporting evidence. > > You need to secure the MX lookup. This is 100% dependent on DNSSEC > working. > After that DANE/PKIX can be used with STARTTLS. > Ah! Fair point. > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > --bcaec5161985df7cc704e265fffa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 25 July 2013 23:18, Mark Andrews <marka@isc.org> wr= ote:

In message <CABrd9SS7sHA8gAO_OzPdt3XV33EiyW+=3DxPgwLZkJ0u9PGnmeRQ@mail.gmail.com>
, Ben Laurie writes:
>
> On 24 July 2013 15:23, Viktor Dukhovni <viktor1dane@dukhovni.org> wrote:
>
> > On Wed, Jul 24, 2013 at 10:41:35AM +0100, Ben Laurie wrote:
> >
> > > > =A0 =A0 =A0 It sure looks like the major browsers are n= ot in a hurry to
> > implement
> > > > =A0 =A0 =A0 DANE, which is ironic, since RFC 6698 is mo= stly focused on
> > > > browser-like
> > > > =A0 =A0 =A0 applications, and needs adjustments for pro= tocols like SMTP,
> > where
> > > > =A0 =A0 =A0 DANE will be actively implemented first. > > > >
> > >
> > > SMTP starts from a position of no assurance at all, so even = DANE improves
> > > it.
> >
> > Yes, but the key observation is that PKIX cannot improve it absen= t
> > DNSSEC (which must therefor be trusted, Wes will explain this in<= br> > > Berlin). =A0So the *only* path to securing SMTP on Internet scale= is
> > with DANE.
> >
>
> That is a strong claim which I find a little hard to swallow, certainl= y
> without some supporting evidence.

You need to secure the MX lookup. =A0This is 100% dependent on DNSSEC= working.
After that DANE/PKIX can be used with STARTTLS.

Ah! Fair point.
=A0

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2= 9871 4742 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka@isc.org

--bcaec5161985df7cc704e265fffa-- From rick@openfortress.nl Fri Jul 26 07:19:02 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ADC221F9622; Fri, 26 Jul 2013 07:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.204 X-Spam-Level: X-Spam-Status: No, score=-0.204 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5E91J073vyL5; Fri, 26 Jul 2013 07:18:57 -0700 (PDT) Received: from smtp-vbr12.xs4all.nl (smtp-vbr12.xs4all.nl [194.109.24.32]) by ietfa.amsl.com (Postfix) with ESMTP id 1816621F842A; Fri, 26 Jul 2013 07:18:55 -0700 (PDT) Received: from [10.0.1.225] (phantom.vanrein.org [83.161.146.46]) (authenticated bits=0) by smtp-vbr12.xs4all.nl (8.13.8/8.13.8) with ESMTP id r6QEIreD053957 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 26 Jul 2013 16:18:54 +0200 (CEST) (envelope-from rick@openfortress.nl) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: "Rick van Rein (OpenFortress)" Date: Fri, 26 Jul 2013 16:19:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <030F2A8C-1C25-4C91-88FD-C81AF44FA98E@openfortress.nl> To: dane@ietf.org, openpgp@ietf.org X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: by XS4ALL Virus Scanner X-Mailman-Approved-At: Fri, 26 Jul 2013 07:20:26 -0700 Subject: [dane] =?windows-1252?q?Storing_public_keys_in_DNS=85_or_LDAP?= X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 26 Jul 2013 14:19:02 -0000 Hello Paul Wouters, I came across your work on storing public key credentials of users in = the DNS: * draft-wouters-dane-openpgp-00 * draft-wouters-dane-otrfp-00 As I am currently trying to achieve similar, secure end-to-end exchanges = of public key material for secure communication, this is very = interesting. Thanks for the work! When I read them, I found that you made a choice that we deliberately = abandoned as unpractical, so I thought it good to share our thoughts. = The background of our work is http://networkeffectalliance.org/ with = which we aim to get more end user and technical facilities incorporated = into hosting packages. Doing this, we are rather keen on privacy and = security, as you are in your drafts. We decided against the sort of options in DNS that you are describing = because we felt that the DNS is not meant for storing individual user = credentials. One reason for this opinion is that DNS is ultimately = treated public data, and no DNS admin will accept responsibility for = "leaking" information through DNS, whereas most users will not want that = kind of treatment with their electronically addressable contact = channels. Another reason is that DNS management is usually considered = too sensitive to update for end user changes; which is why it is often = in the hands of another (class of) operator. We are embarking in another direction, and thought this might also be = useful for you, also because it can be used without RFC work. Instead = of using DNS for user data, we are looking at LDAP (with DANE to secure = it). It is a very suitable mechanism for retrieval of end-user = descriptive information, ranging from postalAddress to pgpKey = descriptions. It also has a well-established notion of a Global = Directory that is based on DNS-names derived from dc=3D,dc=3D trailers = to distinguishedNames, and SRV record lookups of LDAP service under such = domains. Given an email address, the username part can then be sought = with (uid=3D=85) filtering, and PGP keys and such can be located under = that node. I am not aware of any XMPP profile for LDAP, but that is as = straightforward to define as it has been for OpenPGP, SSH and even SRP. = It is probably easier to get such an LDAP attribute spec standardised as = an RFC or even just a XEP than your proposed use of DNS. The searchable structured data in LDAP can have privacy issues when used = as a public-facing service when published without restraint; we are = resolving that with a filtering practice (for which we are developing = software) that can filter out considered-private attributes (or objects) = unless their attribute values are explicitly mentioned in a query. So, = searching for (uid=3Drick) under dc=3Dopenfortress,dc=3Dnl would deliver = my account record with email address and SIP phone number as well as = being a parent for key material, but searching for (uid=3D*) would not = deliver this if I configured LDAP to treat uid as too private to publish = in that case. Another reason not to publish LDAP is that it is often = used for data about local infra; this can be solved by separating = in-house and public directory services. If you want to know more about this work, you can visit this site with = the work in progress: http://rickywiki.vanrein.org/doku.php?id=3Dglobaldir= Specifically note how, for OpenPGP, there is a solution that already = works with PGP tools -- they will perform that LDAP queries to = per-domain LDAP service. I detailed it on the subpage = http://rickywiki.vanrein.org/doku.php?id=3Dglobaldir-5-openpgp I hope this is helpful! Cheers, Rick van Rein OpenFortress +31.53.4782239 rick@openfortress.nl (SMTP, XMPP, SIP)= From paul@cypherpunks.ca Fri Jul 26 07:29:12 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1B1321F9971 for ; Fri, 26 Jul 2013 07:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G0UkM1YXnVyt for ; Fri, 26 Jul 2013 07:29:07 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id D10F021F8E79 for ; Fri, 26 Jul 2013 07:29:06 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3c1t2k1mRtzB5 for ; Fri, 26 Jul 2013 10:29:02 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id HTOv3QDGqpfC for ; Fri, 26 Jul 2013 10:28:52 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP for ; Fri, 26 Jul 2013 10:28:52 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id E5BF780E8F; Fri, 26 Jul 2013 10:28:52 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id DAF1E80E86 for ; Fri, 26 Jul 2013 10:28:52 -0400 (EDT) Date: Fri, 26 Jul 2013 10:28:52 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: dane WG list In-Reply-To: <20130725223646.GH29420@mournblade.imrryr.org> Message-ID: References: <20130716151132.GD29420@mournblade.imrryr.org> <20130716160112.GG29420@mournblade.imrryr.org> <20130723145432.GT29420@mournblade.imrryr.org> <20130724142333.GC29420@mournblade.imrryr.org> <20130725221832.6BAE537AD193@drugs.dv.isc.org> <20130725223646.GH29420@mournblade.imrryr.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [dane] [internet-drafts@ietf.org] New Version Notification for draft-dukhovni-dane-ops-01.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: Fri, 26 Jul 2013 14:29:12 -0000 On Thu, 25 Jul 2013, Viktor Dukhovni wrote: > On Fri, Jul 26, 2013 at 08:18:32AM +1000, Mark Andrews wrote: > >>> That is a strong claim which I find a little hard to swallow, certainly >>> without some supporting evidence. >> >> You need to secure the MX lookup. This is 100% dependent on DNSSEC working. >> After that DANE/PKIX can be used with STARTTLS. > > One also needs a downgrade-immune indication of STARTTLS support. Note that (contrary to my opinion at the time) people decided that the precense of a TLSA record would not indicate "TLS only". A draft was written for the HASTLS record to specify that, which seems to have been pretty much ignored. So now people really have no choice but to take the presence of a TLSA record as the only indication not to downgrade to no TLS. I guess an ERRATA is not the proper way for clarifying this - perhaps a small RFC should be written to formalize this behaviour? [*] > Since trust in DNS is unavoidable, securing SMTP via DNSSEC is the > only sensible thing to do. Throwing PKIX into the mix adds no > value, if DNSSEC is compromised, game over. That's not entirely true. If you get the TLS certificate via other means, eg PKIX or certificate pinning (or TACK) or via another reputation system, you could in fact decide that _despite_ DNSSEC saying otherwise, you will not connect to a different TLS certificate as it seems DNS was compromised. Paul [*] chairs can add this to "other business" in Berlin :) From viktor1dane@dukhovni.org Fri Jul 26 08:03:02 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD0521F8A85 for ; Fri, 26 Jul 2013 08:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQbnHpd34r8J for ; Fri, 26 Jul 2013 08:02:58 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id CDB2E21F8F67 for ; Fri, 26 Jul 2013 08:02:57 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 737A52AAD13; Fri, 26 Jul 2013 15:02:53 +0000 (UTC) Date: Fri, 26 Jul 2013 15:02:53 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130726150253.GJ29420@mournblade.imrryr.org> References: <20130716160112.GG29420@mournblade.imrryr.org> <20130723145432.GT29420@mournblade.imrryr.org> <20130724142333.GC29420@mournblade.imrryr.org> <20130725221832.6BAE537AD193@drugs.dv.isc.org> <20130725223646.GH29420@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] [internet-drafts@ietf.org] New Version Notification for draft-dukhovni-dane-ops-01.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 15:03:02 -0000 On Fri, Jul 26, 2013 at 10:28:52AM -0400, Paul Wouters wrote: > >One also needs a downgrade-immune indication of STARTTLS support. > > Note that (contrary to my opinion at the time) people decided that the > precense of a TLSA record would not indicate "TLS only". A draft was > written for the HASTLS record to specify that, which seems to have > been pretty much ignored. So now people really have no choice but to > take the presence of a TLSA record as the only indication not to > downgrade to no TLS. > > I guess an ERRATA is not the proper way for clarifying this - perhaps a > small RFC should be written to formalize this behaviour? [*] Perhaps the lack of general (application protocol independent) guidance on this topic is due in part to the fact that with some application layers TLS is required by the destination address syntax (e.g. HTTPS URL). Tony's SRV and SMTP drafts, as well as SMTP draft, therefore specify that for DANE with SMTP "TLSA" presence implies a TLS requirement (subsumes HASTLS). So I am not too worried about lack of precision on this point in 6698. > >Since trust in DNS is unavoidable, securing SMTP via DNSSEC is the > >only sensible thing to do. Throwing PKIX into the mix adds no > >value, if DNSSEC is compromised, game over. > > That's not entirely true. If you get the TLS certificate via other > means, eg PKIX or certificate pinning (or TACK) or via another > reputation system, you could in fact decide that _despite_ DNSSEC > saying otherwise, you will not connect to a different TLS certificate > as it seems DNS was compromised. DNSSEC secures the MX record, and TLSA RRs provide a mandatory TLS indication, plus base domain for TA usages plus authenticated key material. Client maintained out-of-band TLS information does not scale. MTAs are non-interactive, when a site updates MX records, the MTA must send to the MX records it finds, it can't pop a dialogue to ask the user. Pinning the MX hosts and or certificates for a set of domains is not an architecture for securing SMTP on an Internet scale. It can certainly be done (and is done at some sites) for a handful of "high value" (to the sender) domains, but this ad-hoc approach does not scale. Until recently I was the postmaster of a site with O(100) such manual TLS policies, each one was a pain to setup (30minutes of conf call with the peer site's email admins) and the resulting static configurations were fragile. FWIW, when I say that SMTP with PKIX does not scale, I mean it, and have the scars to prove it. I chose to implement DANE in Postfix because it addresses a real problem which has resisted solution for over a decade. http://www.postfix.org/TLS_README.html#client_tls_limits -- Viktor. From trevp@trevp.net Fri Jul 26 14:19:33 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8E021F9396 for ; Fri, 26 Jul 2013 14:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jzJa2hegov7k for ; Fri, 26 Jul 2013 14:19:28 -0700 (PDT) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7FE21F9A64 for ; Fri, 26 Jul 2013 14:19:27 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id k13so3202575wgh.1 for ; Fri, 26 Jul 2013 14:19:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:content-type:x-gm-message-state; bh=G2tRi/bd0GuXvdF5pphzhB+jSSGcMBPo8hg9y7vo3PU=; b=eLMoIJ/WxaO8dZEdIhpGtkdCw205fQg8o2hxeKR2jeL86BGUlwlD+Mg7cyj4bPSv7z 13SaWYh8yjRcrK4HuJlnyIhSYgbXalRnJ9pnNS2qeor/CBh/FQv8Gei2QeG3rxDI+roq vTS9Wh9MBcGz/WFBCBd0J25q8a5nzgUa4VtpeV9yoGTrEy/55oK4qCmFzPZHfJxd4s4G E5bnNWckwTCt9iTB58n0hOwHVGpAomBQhhcyXZ4xUepZS0rXlbHDA25B19229jKy7Gku edmZHfU8rEZUY8peUlj+R8XN23npB/H3Ez1ItdyA4cMez4S7CS9XMDyXalk09zIsjoVs sauQ== MIME-Version: 1.0 X-Received: by 10.194.83.195 with SMTP id s3mr36679506wjy.82.1374873566358; Fri, 26 Jul 2013 14:19:26 -0700 (PDT) Received: by 10.216.212.9 with HTTP; Fri, 26 Jul 2013 14:19:26 -0700 (PDT) X-Originating-IP: [173.11.71.218] In-Reply-To: <20130726150253.GJ29420@mournblade.imrryr.org> References: <20130716160112.GG29420@mournblade.imrryr.org> <20130723145432.GT29420@mournblade.imrryr.org> <20130724142333.GC29420@mournblade.imrryr.org> <20130725221832.6BAE537AD193@drugs.dv.isc.org> <20130725223646.GH29420@mournblade.imrryr.org> <20130726150253.GJ29420@mournblade.imrryr.org> Date: Fri, 26 Jul 2013 14:19:26 -0700 Message-ID: From: Trevor Perrin To: dane@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQko1HNNRSV3kn/DhMwzfqf6/39lFAZGZQFRq05OhIt97L0bv+Z2t0qmcbM6+tJ5Y3qszH/P Subject: Re: [dane] [internet-drafts@ietf.org] New Version Notification for draft-dukhovni-dane-ops-01.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: Fri, 26 Jul 2013 21:19:33 -0000 Hi Victor, all, Don't mean to derail discussion but I heard the word pinning... :-) > Until recently I was the postmaster of a site with O(100) such > manual TLS policies, each one was a pain to setup (30minutes of > conf call with the peer site's email admins) and the resulting > static configurations were fragile. That's pretty interesting, I didn't know there was SMTP manual pinning on that scale. If you don't mind sharing, I'm curious: - Can you configure TLS pins on common mail servers? - Is this a common practice? - Are there any efforts at aggregating and sharing pin lists, so they don't need pairwise phone calls? FWIW, the way we saw cross-domain SMTP working for TACK was: If the sending MTA indicates TACK support in its TLS ClientHello, the receiving MTA could return a "tack", and the sender could activate a pin between the TACK Signing Key and the email recipient's domain name. (NOT the mailserver's name - this would be special cross-domain SMTP semantics). This assumes the sending MTA would send the MX hostname in TLS SNI, and the receiving MTA would use this to determine which certs / tacks to return. (Not sure this is workable, but I think DANE SRV [1] expects to use SNI in a similar way?) Anyways, aside from this, the MX hostname wouldn't matter for the pin validation. Trevor [1] http://tools.ietf.org/html/draft-ietf-dane-srv-02 From viktor1dane@dukhovni.org Fri Jul 26 14:36:51 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C32AA11E8168 for ; Fri, 26 Jul 2013 14:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ly1m7DRraLSj for ; Fri, 26 Jul 2013 14:36:46 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 8940E11E8162 for ; Fri, 26 Jul 2013 14:36:46 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 19F6C2AAD13; Fri, 26 Jul 2013 21:36:40 +0000 (UTC) Date: Fri, 26 Jul 2013 21:36:40 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130726213640.GL29420@mournblade.imrryr.org> References: <20130723145432.GT29420@mournblade.imrryr.org> <20130724142333.GC29420@mournblade.imrryr.org> <20130725221832.6BAE537AD193@drugs.dv.isc.org> <20130725223646.GH29420@mournblade.imrryr.org> <20130726150253.GJ29420@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] [internet-drafts@ietf.org] New Version Notification for draft-dukhovni-dane-ops-01.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 21:36:51 -0000 On Fri, Jul 26, 2013 at 02:19:26PM -0700, Trevor Perrin wrote: > > Until recently I was the postmaster of a site with O(100) such > > manual TLS policies, each one was a pain to setup (30minutes of > > conf call with the peer site's email admins) and the resulting > > static configurations were fragile. > > That's pretty interesting, I didn't know there was SMTP manual pinning > on that scale. If you don't mind sharing, I'm curious: > > - Can you configure TLS pins on common mail servers? Postfix supports a "fingerprint" security level, but in most cases, the manual security arrangements used PKIX with hand-crafted name checks. So we did not often "pin" certificates with outside parties, such pins were only used from time to time on SMTP links where we controlled the certificates on both ends. > - Is this a common practice? > - Are there any efforts at aggregating and sharing pin lists, > so they don't need pairwise phone calls? Yes, there was an industry effort to aggregate TLS configuration data, but it never went very far. I am hoping DANE will obviate the need for this, provided we can get people to adopt DNSSEC. > FWIW, the way we saw cross-domain SMTP working for TACK was: If the > sending MTA indicates TACK support in its TLS ClientHello, the > receiving MTA could return a "tack", and the sender could activate a > pin between the TACK Signing Key and the email recipient's domain > name. (NOT the mailserver's name - this would be special cross-domain > SMTP semantics). I don't think this is practical for SMTP. My focus is on DANE. -- Viktor. From ondrej.sury@nic.cz Tue Jul 30 04:23:32 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A797A11E814F for ; Tue, 30 Jul 2013 04:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NyIt1p602TCJ for ; Tue, 30 Jul 2013 04:23:31 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 02E2E11E81E8 for ; Tue, 30 Jul 2013 04:23:11 -0700 (PDT) Received: from [172.20.26.41] (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id BB93E13F628; Tue, 30 Jul 2013 13:22:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1375183369; bh=UsvKqNRXrq9aG4562Z8Q9xB9zNjZqK7et0JTXRX4S28=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=ZqLnBeCOJ0BTKYmSVINMvMWAdIMyEFE8TCiShWbFQrWoP3aLE9esp3SmkRxfVyzmv G8am2N9iy0cZVQzxI2oKgDgiACk1REUhohcFkGyGD8T+rp/ronmA1q2MsBxenI9Ud0 U4FRBnf9DGv8l7IBdpV/K/ngs/hvEezoLyYZOwRw= Content-Type: multipart/signed; boundary="Apple-Mail=_92DEB043-54CF-4616-802E-EA32D3508F9F"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1786.1\)) From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <0lk3krz888.fsf@wjh.hardakers.net> Date: Tue, 30 Jul 2013 13:22:43 +0200 Message-Id: <495AEED3-2877-41E6-868B-B47EE6A5F4DA@nic.cz> References: <0lk3krz888.fsf@wjh.hardakers.net> To: Wes Hardaker , Viktor Dukhovni X-Mailer: Apple Mail (2.1786.1) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: dane@ietf.org, dane@ietf.orglist Subject: Re: [dane] [internet-drafts@ietf.org] New Version Notification for draft-dukhovni-dane-ops-01.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 11:23:32 -0000 --Apple-Mail=_92DEB043-54CF-4616-802E-EA32D3508F9F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, I am (re-)reading the drafts before the meeting and I have few comments: 1. the high/low bit part in "2. DANE TLSA record overview". Please drop/rewrite the bit part since it will become confusing when we = adopt draft-ietf-tls-oob-pubkey for DANE. 2. Section 3.5 on CNAMES The recommendation to follow the CNAME chain and do hop-by-hop checks = won't work with most used protocol - HTTPS. Generally you expect an TLS = certificate for "www.iamconnecting.to" and not for "server.provider.srv" = as suggested by the draft. Also checking for CNAME means that the DANE PKI client would have to = (re-)implement whole follow-the-CNAME login instead of using simple = getaddrinfo(). So I am not sure if this is a sensible default. O. On 16. 7. 2013, at 1:58, Wes Hardaker wrote: >=20 > FYI: >=20 >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-dukhovni-dane-ops-01.txt > Date: 16. =C4=8Dervence 2013 1:45:48 GMT+2 > To: Viktor Dukhovni , Wes Hardaker = , Wesley Hardaker >=20 >=20 >=20 > A new version of I-D, draft-dukhovni-dane-ops-01.txt > has been successfully submitted by Viktor Dukhovni and posted to the > IETF repository. >=20 > Filename: draft-dukhovni-dane-ops > Revision: 01 > Title: DANE TLSA implementation and operational = guidance > Creation date: 2013-07-15 > Group: Individual Submission > Number of pages: 18 > URL: = http://www.ietf.org/internet-drafts/draft-dukhovni-dane-ops-01.txt > Status: = http://datatracker.ietf.org/doc/draft-dukhovni-dane-ops > Htmlized: http://tools.ietf.org/html/draft-dukhovni-dane-ops-01 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-dukhovni-dane-ops-01 >=20 > Abstract: > This memo provides operational guidance to server operators to help > ensure that clients will be able to authenticate a server's > certificate chain via published TLSA records. Guidance is also > provided to clients for selecting reliable TLSA record parameters to > use for server authentication. Finally, guidance is given to > protocol designers who wish to make use of TLSA records to secure > protocols using a TLS and TLSA combination. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 >=20 >=20 >=20 >=20 > --=20 > Wes Hardaker > Parsons > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- Ond=C5=99ej Sur=C3=BD -- Chief Science Officer ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- --Apple-Mail=_92DEB043-54CF-4616-802E-EA32D3508F9F Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMKTCCBgYw ggTuoAMCAQICAQIwDQYJKoZIhvcNAQEFBQAwga8xCzAJBgNVBAYTAk5MMSAwHgYDVQQKExdUcnVz dGVkIEludHJvZHVjZXIgKFRJKTEgMB4GA1UECxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxMzAx BgNVBAMTKlRydXN0ZWQgSW50cm9kdWNlciAoVEkpIFRvcGxldmVsIENBIC0gRzAwMTEnMCUGCSqG SIb3DQEJARYYY2FAdHJ1c3RlZC1pbnRyb2R1Y2VyLm5sMB4XDTA0MTIwNzEwMzYxN1oXDTMwMTIw NjAwMDAwMFowga0xCzAJBgNVBAYTAk5MMSAwHgYDVQQKExdUcnVzdGVkIEludHJvZHVjZXIgKFRJ KTEgMB4GA1UECxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxMTAvBgNVBAMTKFRydXN0ZWQgSW50 cm9kdWNlciAoVEkpIENsaWVudCBDQSAtIEcwMDExJzAlBgkqhkiG9w0BCQEWGGNhQHRydXN0ZWQt aW50cm9kdWNlci5ubDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOKQxMR3KDUpfJBz AhY2BPCByKo9SMp/V0RIboLBD6vO0miSYO9FmP3Q07OKPYR5WdlQyrpKqB1zl0SRz2cDjnYkzvDF vK5kvMvlTYeQlHypQlvhkTsYWD4ZZxxEhAYBb1s7cYaIahLw6H/RZz+kyWTOc9TncPBvBWIQ1Ypo S+uQqpopH8s5ebtB/17SbUty5yXiHoaPh/ScdMKqxbyJiL0YRM6SU4YX4HVZ5YGS9aWuiUSiA0YF 8dCR56nErx67wgq8O1GtsSKKOf/ueUxSmrqwgQNlfM9Or5O8kb61s1O2iACHtixoV3ENanylBafU mRYpNo5tSZsElGfntMoGBy8CAwEAAaOCAiswggInMB0GA1UdDgQWBBSeX93lU8ExaSlN1ZaXxfOP h2iHTjCB3AYDVR0jBIHUMIHRgBRdbehwJx/8iwlxnguJECc7MUXvoqGBtaSBsjCBrzELMAkGA1UE BhMCTkwxIDAeBgNVBAoTF1RydXN0ZWQgSW50cm9kdWNlciAoVEkpMSAwHgYDVQQLExdDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTEzMDEGA1UEAxMqVHJ1c3RlZCBJbnRyb2R1Y2VyIChUSSkgVG9wbGV2 ZWwgQ0EgLSBHMDAxMScwJQYJKoZIhvcNAQkBFhhjYUB0cnVzdGVkLWludHJvZHVjZXIubmyCAQAw DwYDVR0TAQH/BAUwAwEB/zAjBgNVHRIEHDAagRhjYUB0cnVzdGVkLWludHJvZHVjZXIubmwwgasG A1UdHwSBozCBoDBOoEygSoZIaHR0cDovL2NybDEudHJ1c3RlZC1pbnRyb2R1Y2VyLm5sL2NhL3g1 MDkvZzEvZGF0YS9jcmxzL2NybC1yb290LWNhLTEuY3JsME6gTKBKhkhodHRwOi8vY3JsMi50cnVz dGVkLWludHJvZHVjZXIubmwvY2EveDUwOS9nMS9kYXRhL2NybHMvY3JsLXJvb3QtY2EtMS5jcmww IwYDVR0RBBwwGoEYY2FAdHJ1c3RlZC1pbnRyb2R1Y2VyLm5sMAsGA1UdDwQEAwIBBjARBglghkgB hvhCAQEEBAMCAAcwDQYJKoZIhvcNAQEFBQADggEBAI1sC2l8st3ElC74az6gH7tGXSiS7jicpHeI 10A3KY+7OEPT7BAJDpjMXxSvAwU1vBDFfwEAXGj42xAPB6cynOTDn0OiFpYGvi3EZV3khXYkGPLs fxZttUyDKqhXcWYy4nnI3fBxqCgLboJFw6OO/SVj5qQdXMZ7VhyFBWJMQkVOnlt6i3xFkG3O5LMI BDmdL5bZPEe8b6bJkMr+rUYEvorPJmV+CkiewYMaruCbdhwRkpkhXB3qLwB2ppnKxSinAU4f9Rcp p73h8iDVQ9389iliUKomVQqj9NJv2G6SyJdDQdN2vrldLszNpw6t+zIzCjpgQ//kem5BJ1k4YG3L CpAwggYbMIIFA6ADAgECAgIGSDANBgkqhkiG9w0BAQUFADCBrTELMAkGA1UEBhMCTkwxIDAeBgNV BAoTF1RydXN0ZWQgSW50cm9kdWNlciAoVEkpMSAwHgYDVQQLExdDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTExMC8GA1UEAxMoVHJ1c3RlZCBJbnRyb2R1Y2VyIChUSSkgQ2xpZW50IENBIC0gRzAwMTEn MCUGCSqGSIb3DQEJARYYY2FAdHJ1c3RlZC1pbnRyb2R1Y2VyLm5sMB4XDTEyMDgwMTA3NTEyNloX DTE0MDgwMTA3NTEyNlowejELMAkGA1UEBhMCTkwxGzAZBgNVBAoTElRydXN0ZWQgSW50cm9kdWNl cjEVMBMGA1UECxMMQ1ouTklDLUNTSVJUMRQwEgYDVQQDEwtPbmRyZWogU3VyeTEhMB8GCSqGSIb3 DQEJARYSb25kcmVqLnN1cnlAbmljLmN6MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA xlmN+hSg6RxWm1X6QOI3OXHSAqhRzWGb8ismR2+3LGDS640luS8x4VdWo490Ceqz+BZvMhQJwfny 9mb0IejFpx7kBOM7k2rMfOYUXa/pq07ysWEI8bXDcXRBf2ZcG0B/gajLPFA9MADlCWHSf7cNZF6S XnIHwTn5DowxpbF403NqLWFnTM08wTJkFgGB7WZAtE6KoSigztI39NrtKRsnosZoBMNZS/JG1CLt VdZPvkHVuiVQWEGYgswBEMGXoR7jtzVNhHr2F1atoBICJVGWFNA8fHvQRLAcXWJTXhKxb2uSq9Yp kKaZPZ6rrp88qtemvwVnQKE9r3/iPFeTARY7AQIDAQABo4ICdTCCAnEwDAYDVR0TAQH/BAIwADAd BgNVHQ4EFgQUgizwG0IeMZQlCSduLVeM1zDBdUEwgdwGA1UdIwSB1DCB0YAUnl/d5VPBMWkpTdWW l8Xzj4doh06hgbWkgbIwga8xCzAJBgNVBAYTAk5MMSAwHgYDVQQKExdUcnVzdGVkIEludHJvZHVj ZXIgKFRJKTEgMB4GA1UECxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxMzAxBgNVBAMTKlRydXN0 ZWQgSW50cm9kdWNlciAoVEkpIFRvcGxldmVsIENBIC0gRzAwMTEnMCUGCSqGSIb3DQEJARYYY2FA dHJ1c3RlZC1pbnRyb2R1Y2VyLm5sggECMCMGA1UdEgQcMBqBGGNhQHRydXN0ZWQtaW50cm9kdWNl ci5ubDAdBgNVHREEFjAUgRJvbmRyZWouc3VyeUBuaWMuY3owCwYDVR0PBAQDAgSwMCcGA1UdJQQg MB4GCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwEQYJYIZIAYb4QgEBBAQDAgSwMIHVBgNV HR8Egc0wgcowY6BhoF+GXWh0dHA6Ly9jcmwxLnRydXN0ZWQtaW50cm9kdWNlci5ubC9jYS94NTA5 L2cxL2NhLXNzbC1jbGllbnQvZzEvZGF0YS9jcmxzL2NybC1jbGllbnQtY2EtMS0xLmNybDBjoGGg X4ZdaHR0cDovL2NybDIudHJ1c3RlZC1pbnRyb2R1Y2VyLm5sL2NhL3g1MDkvZzEvY2Etc3NsLWNs aWVudC9nMS9kYXRhL2NybHMvY3JsLWNsaWVudC1jYS0xLTEuY3JsMA0GCSqGSIb3DQEBBQUAA4IB AQAZP/dznHW3BWajBVQ3fTaDsx/3csUE6+jX83r1dgzYjUOmapOzXQVZ2/VTwZTzJSsD7rDgzUN6 sk6YWmUJOwqoEcPasYG9zt9e+bpwc/PURjSowb+WjEE2e4L47x3mPgL0dtlGj4guhRaj247K9N1f grvlyX0h/IL9JO4CN0I5lAuOaZ3Yfl0euHpHLlXZ9czxkc6dCbtGSZwr3RrltNmMjhp0O3D51fDd D6mG1vvOEV9Kj1JfSE2cQI5j3GpMlNleZA6noZ93drs2G9/D7WP4uVLCtJfGmG6PJsy4+qN46qXu ekJR/8WH1aNcH0Ya+JsYrwIFPwL4Cr+JXrbFqUOFMYIDzzCCA8sCAQEwgbQwga0xCzAJBgNVBAYT Ak5MMSAwHgYDVQQKExdUcnVzdGVkIEludHJvZHVjZXIgKFRJKTEgMB4GA1UECxMXQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkxMTAvBgNVBAMTKFRydXN0ZWQgSW50cm9kdWNlciAoVEkpIENsaWVudCBD QSAtIEcwMDExJzAlBgkqhkiG9w0BCQEWGGNhQHRydXN0ZWQtaW50cm9kdWNlci5ubAICBkgwCQYF Kw4DAhoFAKCCAe8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMw NzMwMTEyMjQ2WjAjBgkqhkiG9w0BCQQxFgQUJJyHgYAIP24tCLrXaNbL9JfiU68wgcUGCSsGAQQB gjcQBDGBtzCBtDCBrTELMAkGA1UEBhMCTkwxIDAeBgNVBAoTF1RydXN0ZWQgSW50cm9kdWNlciAo VEkpMSAwHgYDVQQLExdDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTExMC8GA1UEAxMoVHJ1c3RlZCBJ bnRyb2R1Y2VyIChUSSkgQ2xpZW50IENBIC0gRzAwMTEnMCUGCSqGSIb3DQEJARYYY2FAdHJ1c3Rl ZC1pbnRyb2R1Y2VyLm5sAgIGSDCBxwYLKoZIhvcNAQkQAgsxgbeggbQwga0xCzAJBgNVBAYTAk5M MSAwHgYDVQQKExdUcnVzdGVkIEludHJvZHVjZXIgKFRJKTEgMB4GA1UECxMXQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxMTAvBgNVBAMTKFRydXN0ZWQgSW50cm9kdWNlciAoVEkpIENsaWVudCBDQSAt IEcwMDExJzAlBgkqhkiG9w0BCQEWGGNhQHRydXN0ZWQtaW50cm9kdWNlci5ubAICBkgwDQYJKoZI hvcNAQEBBQAEggEAXFd/GlGRWbxoZWk4UlOTZPoR9M16dXd3O76zgvb40JQSRos+IMD2g8jVwfUI rBqyDbahiQ4mtCMe/bGpdLjwjStTKWjn4mHYeZ9SLSZLNVQWfbf73nTkNW91gdeTNZ5BoaDYBwDO hwE+h/UMtqYAWek89PA/VQQYT1otP5LsYf7Cz+CKvY6Wvy5Btcp6kvItPw/mVr3WULj6GIak+Y/X UTvngCjJGT+9itzp+jpDSnyG6Js/OndgLXlLBo78skZye7MqPuG8Ev6YkLCa8uGj86bjNel6pdFa c6eJaK6D0pyGQ1MgNJ9hvltWH9Fyw2lAmOKb2tqzyjoisKE2mWAp4gAAAAAAAA== --Apple-Mail=_92DEB043-54CF-4616-802E-EA32D3508F9F-- From viktor1dane@dukhovni.org Tue Jul 30 08:23:52 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF0FC21E8100 for ; Tue, 30 Jul 2013 08:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-A1FUpZtIs2 for ; Tue, 30 Jul 2013 08:23:45 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 5543D21E80E3 for ; Tue, 30 Jul 2013 08:23:38 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 861CD2AAD1D; Tue, 30 Jul 2013 15:23:32 +0000 (UTC) Date: Tue, 30 Jul 2013 15:23:32 +0000 From: Viktor Dukhovni To: "dane@ietf.org list" Message-ID: <20130730152332.GA2603@mournblade.imrryr.org> References: <0lk3krz888.fsf@wjh.hardakers.net> <495AEED3-2877-41E6-868B-B47EE6A5F4DA@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <495AEED3-2877-41E6-868B-B47EE6A5F4DA@nic.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] [internet-drafts@ietf.org] New Version Notification for draft-dukhovni-dane-ops-01.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 15:23:53 -0000 On Tue, Jul 30, 2013 at 01:22:43PM +0200, Ond?ej Sur? wrote: > 1. the high/low bit part in "2. DANE TLSA record overview". > > Please drop/rewrite the bit part since it will become confusing when we > adopt draft-ietf-tls-oob-pubkey for DANE. Since we only discuss usages 0-3, perhaps the "bit part" can be restricted to cover just those 4 usages. Clearly usages 4 and up are likely to break the pattern. Or we can change the wording. It really is not important that the feature matrix for 0-3 is bit-aligned. By the way, is there any reason to adopt a new usage for bare public keys? What's wrong with "3 1 1"? Existing TLSA associations that match public keys inside an EE certificate can equally match public keys that are not inside a certificate. > 2. Section 3.5 on CNAMES > > The recommendation to follow the CNAME chain and do hop-by-hop > checks won't work with most used protocol - HTTPS. Generally you > expect an TLS certificate for "www.iamconnecting.to" and not for > "server.provider.srv" as suggested by the draft. What may be missing from the draft, but was intended to be there, is a fallback to the initial name when no TLSA RRs are found at the CNAME expanded target. Certainly, for example, when the final target is in an insecure zone (prime example from Wes: www.paypal.com). If however, there is a TLSA RRset on the right side of a secure alias, it makes sense to use that in preference to the initial name. As explained loudly in the POSH BOF on Monday, key sharing with SNI is not for everyone, and finding a way to use the provider's keys securely is far better. In effect all that POSH is trying to do is a secure redirect, but in a complicated ad-hoc manner via PKIX HTTPS servers. That's a bit lame IMHO. But they are identifying a real need to get past SNI. If we model the old world of HTTPS too closely, we capture its unintended faults (no CNAME chasing and hence SNI, because without DNSSEC CNAMEs are MITM vulnerable) as well as its useful features. There is no axiom that HTTPS secure names must be what the user typed. It is just that's all that was possible previously. With DNSSEC+DANE we *can* do better (obviate SNI and solve the issue that motivates POSH). Also keep in mind that the browsers seem to be the least likely to implement DANE any time soon. Basing DANE on the application least likely to adopt it seems a bit perverse. Anyway, I'll be in the chat room on Thursday, I am hoping Wes will cover this issue in detail. > Also checking for CNAME means that the DANE PKI client would have > to (re-)implement whole follow-the-CNAME login instead of using > simple getaddrinfo(). They already need a DNS API. This is not a big deal. > So I am not sure if this is a sensible default. It is certainly worthy of discussion! But I would point out the POSH BOF as a strong signal that dealing with hosting is a very important issue. For protocols with SRV (and SRV-like MX, â¦) records indirection is already largely dealt with. I wanted to make CNAMEs behave like poor-man's SRV records and deliver the same benefit. That's is allow the client to discover the hosting provider's name! Thereby avoiding the pain and suffering of SNI. -- Viktor.