From dan-ietf@danyork.org Mon Oct 1 06:38:15 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1915A11E810E for ; Mon, 1 Oct 2012 06:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.619 X-Spam-Level: X-Spam-Status: No, score=-1.619 tagged_above=-999 required=5 tests=[AWL=-1.079, BAYES_20=-0.74, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s30+NE54bamw for ; Mon, 1 Oct 2012 06:38:13 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 583D31F0D31 for ; Mon, 1 Oct 2012 06:38:13 -0700 (PDT) Received: by qabj40 with SMTP id j40so1631111qab.10 for ; Mon, 01 Oct 2012 06:37:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=UFMlZPBFJDSb1ImRUrJuMwh3LkL039byWUROI+n36Qs=; b=nXtpasvGcIFRlLXxLg+pc38PNEmtto5ENuj6i+u6ZNWx+JkcsNko4xnTc7zewT8L3H LrA22R80TaglnM4dsbDdiN71jzfPK9WSuz8bW+Ai819JPXs861Q8cxL3K65E3ma9IeiY ROGOfc1MjBkPmC4OM1IKxNVomsMV41Dk9zuviHphQ1O/3T0oECEMebZw47neHkiMV/so jnAbWumRUZy/OypRv5ZMHDOM3P9P0B7XEzq0ZJ/hPqLocxrIJBGrkD4hQa00xqsduWwp zaT3qxH1B+60IGTOMqJt/Y8FTfaXYmlhvUiwZM3FQDDHu0WYz+QyRbhx0R4zBB9gwthV qLDg== Received: by 10.224.179.7 with SMTP id bo7mr36617497qab.96.1349098674731; Mon, 01 Oct 2012 06:37:54 -0700 (PDT) Received: from [172.20.12.152] (cpe-74-75-92-114.maine.res.rr.com. [74.75.92.114]) by mx.google.com with ESMTPS id em3sm24503534qab.5.2012.10.01.06.37.53 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 01 Oct 2012 06:37:54 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_B00F4439-2651-440C-AD66-17E44C5E29FE" From: Dan York In-Reply-To: Date: Mon, 1 Oct 2012 09:37:51 -0400 Message-Id: <15ED757A-9B2F-45CD-A1B6-0A0C8DFC2397@danyork.org> References: To: Warren Kumari X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQnXGvgAWX/DpcXJktmq7hSeR2APX0Ovbi2dQQaRLeEPXJF6DG5FqXA7RK8ScltG5fAAng4J Cc: dane WG list Subject: [dane] Deployment focus? Re: IETF 85 - meet or not to meet? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 01 Oct 2012 13:38:15 -0000 --Apple-Mail=_B00F4439-2651-440C-AD66-17E44C5E29FE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Warren and Ond=C5=99ej, >>> Any comments (if saying yes, please also say why and attach an = agenda item suggestion :))? I see more of a "strategic" reason for meeting at IETF 85 in that I am = seeing a lot of positive response to the value of DANE when I am = speaking about it within industry circles. It's clear to me that DANE = can provide real value to companies/organizations and that it can also = provide a strong reason for organizations to be interested in deploying = DNSSEC. I guess I feel that NOT meeting feels a bit like "taking the = foot off the gas pedal" at a time when we need to be pushing people = towards getting DANE deployed. Having said that, I agree there's not much point in meeting if there is = only one draft to discuss. Could we perhaps have an agenda more focused on the question of "what = comes next?" and looking at obstacles to DANE deployment? Some ideas: - Discussion of what needs to be done to get DANE more widely deployed, = specifically: 1. What steps do we collectively need to take to get adding DANE = support on the radar of browser vendors? 2. What do we need to do to get more registrars/DNS hosting = providers accepting TLSA records? 3. What do we need to do to get more organizations publishing TLSA = records?=20 - Exploration of the various tools available (some discussed recently = on the list) and identification of tools that need to be created (Could = we perhaps include some quick demos of those tools?) - Discussion of what "Using DANE With $foo Protocol" documents would be = logical to create (where $foo is the various networking protocols) and = identification of people willing to create such drafts - Discussion of ways to measure DANE deployment (how can we do that?) I'd certainly be willing to present and lead a discussion on the first = of those ideas and to participate in other discussions. If a draft is = needed for agenda time I can probably work something up before the -00 = deadine of October 15th. =20 We could of course discuss Paul's S/MIME draft as it fits into the = "Using DANE with $foo" category. Thoughts? Comments? Dan On Sep 30, 2012, at 5:00 AM, Warren Kumari wrote: >=20 > On Sep 24, 2012, at 3:10 PM, Ond=C5=99ej Sur=C3=BD = wrote: >=20 >> More specifically, we are going to cancel the session after Oct 4th = unless we hear from you that you want to meet and we have an agenda. >>=20 >=20 > Apologies all -- due to the contention for meeting slots and the = difficulty of scheduling all these slots we are moving the cutoff to the = 2nd. >=20 > W >=20 >=20 >> O. >>=20 >> On 23. 9. 2012, at 12:28, Ond=C5=99ej Sur=C3=BD = wrote: >>=20 >>> Dear WG, >>>=20 >>> we did register a slot for IETF 85 (just in case), but from the = volume of the mailing list and just one WG draft (we have just adopted), = we are quite unsure if there's enough interest in meeting. >>>=20 >>> I am personally inclined of canceling this meeting and reschedule = for next year. >>>=20 >>> Any comments (if saying yes, please also say why and attach an = agenda item suggestion :))? >>>=20 >>> 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 >>> ------------------------------------------- >>>=20 >>> _______________________________________________ >>> dane mailing list >>> dane@ietf.org >>> https://www.ietf.org/mailman/listinfo/dane >>=20 >> -- >> 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 >> ------------------------------------------- >>=20 >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane --=20 Dan York dyork@lodestar2.com http://www.danyork.me/ skype:danyork Phone: +1-802-735-1624 Twitter - http://twitter.com/danyork --Apple-Mail=_B00F4439-2651-440C-AD66-17E44C5E29FE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Any= comments (if saying yes, please also say why and attach an agenda item = suggestion :))?

I see = more of a "strategic" reason for meeting at IETF 85 in that I am seeing = a lot of positive response to the value of DANE when I am speaking about = it within industry circles. It's clear to me that DANE can provide real = value to companies/organizations and that it can also provide a strong = reason for organizations to be interested in deploying DNSSEC.  I = guess I feel that NOT meeting feels a bit like "taking the foot off the = gas pedal" at a time when we need to be pushing people towards getting = DANE deployed.

Having said that, I agree = there's not much point in meeting if there is only one draft to = discuss.

Could we perhaps have an agenda more = focused on the question of "what comes next?" and looking at obstacles = to DANE deployment?

Some = ideas:
 - Discussion of what needs to be done to get DANE = more widely deployed, specifically:
      1. = What steps do we collectively need to take to get adding DANE support on = the radar of browser vendors?
      2. What do = we need to do to get more registrars/DNS hosting providers accepting = TLSA records?
      3. What do we need to do to = get more organizations publishing TLSA records? 
 - = Exploration of the various tools available (some discussed recently on = the list) and identification of tools that need to be created (Could we = perhaps include some quick demos of those tools?)
 - = Discussion of what "Using DANE With $foo Protocol" documents would be = logical to create (where $foo is the various networking protocols) and = identification of people willing to create such drafts
 - = Discussion of ways to measure DANE deployment (how can we do = that?)

I'd certainly be willing to present and = lead a discussion on the first of those ideas and to participate in = other discussions.  If a draft is needed for agenda time I can = probably work something up before the -00 deadine of October 15th. =  

We could of course discuss Paul's S/MIME = draft as it fits into the "Using DANE with $foo" = category.

Thoughts? =  Comments?

Dan

On = Sep 30, 2012, at 5:00 AM, Warren Kumari wrote:


On = Sep 24, 2012, at 3:10 PM, Ond=C5=99ej Sur=C3=BD <ondrej.sury@nic.cz> = wrote:

More specifically, we are going = to cancel the session after Oct 4th unless we hear from you that you = want to meet and we have an agenda.


Apologies all -- due to the = contention for meeting slots and the difficulty of scheduling all these = slots we are moving the cutoff to the = 2nd.

W


O.

On 23. 9. 2012, = at 12:28, Ond=C5=99ej Sur=C3=BD <ondrej.sury@nic.cz> = wrote:

Dear WG,

we did register a slot for IETF = 85 (just in case), but from the volume of the mailing list and just one = WG draft (we have just adopted), we are quite unsure if there's enough = interest in meeting.

I am personally inclined of = canceling this meeting and reschedule for next = year.

Any comments (if saying yes, = please also say why and attach an agenda item suggestion = :))?

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
-------------------------------------------
=

_______________________________________________
dane = mailing list
dane@ietf.org
https://www.ietf.org/m= ailman/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
-------------------------------------------
=

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

_____________________________= __________________
dane mailing list
dane@ietf.org
https://www.ietf.org/ma= ilman/listinfo/dane

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

= --Apple-Mail=_B00F4439-2651-440C-AD66-17E44C5E29FE-- From paul.hoffman@vpnc.org Mon Oct 1 07:24:29 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C42161F0C7E for ; Mon, 1 Oct 2012 07:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOw1qzN2WWLi for ; Mon, 1 Oct 2012 07:24:29 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id BC2EF1F0CEE for ; Mon, 1 Oct 2012 07:24:28 -0700 (PDT) Received: from [10.20.30.108] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q91EOPu9026253 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 1 Oct 2012 07:24:25 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Paul Hoffman In-Reply-To: <15ED757A-9B2F-45CD-A1B6-0A0C8DFC2397@danyork.org> Date: Mon, 1 Oct 2012 07:24:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <76960946-F768-422B-A76A-17D951D29C8C@vpnc.org> References: <15ED757A-9B2F-45CD-A1B6-0A0C8DFC2397@danyork.org> To: Dan York X-Mailer: Apple Mail (2.1498) Cc: dane WG list Subject: Re: [dane] Deployment focus? Re: IETF 85 - meet or not to meet? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 01 Oct 2012 14:24:30 -0000 On Oct 1, 2012, at 6:37 AM, Dan York wrote: > I see more of a "strategic" reason for meeting at IETF 85 in that I am = seeing a lot of positive response to the value of DANE when I am = speaking about it within industry circles. It's clear to me that DANE = can provide real value to companies/organizations and that it can also = provide a strong reason for organizations to be interested in deploying = DNSSEC. =20 Yes. > I guess I feel that NOT meeting feels a bit like "taking the foot off = the gas pedal" at a time when we need to be pushing people towards = getting DANE deployed. The IETF is not a protocol promotion body. We do it sometimes, but often = with bad results. > Having said that, I agree there's not much point in meeting if there = is only one draft to discuss. And there is no draft on "how to promote DANE usage". > Could we perhaps have an agenda more focused on the question of "what = comes next?" and looking at obstacles to DANE deployment? >=20 > Some ideas: > - Discussion of what needs to be done to get DANE more widely = deployed, specifically: > 1. What steps do we collectively need to take to get adding DANE = support on the radar of browser vendors? > 2. What do we need to do to get more registrars/DNS hosting = providers accepting TLSA records? > 3. What do we need to do to get more organizations publishing = TLSA records?=20 > - Exploration of the various tools available (some discussed recently = on the list) and identification of tools that need to be created (Could = we perhaps include some quick demos of those tools?) > - Discussion of what "Using DANE With $foo Protocol" documents would = be logical to create (where $foo is the various networking protocols) = and identification of people willing to create such drafts > - Discussion of ways to measure DANE deployment (how can we do that?) That proposed agenda is much more in the realm of Internet Society work = than IETF work. Perhaps you should talk to people at ISOC about hosting = an meeting to discuss these things? :-) > I'd certainly be willing to present and lead a discussion on the first = of those ideas and to participate in other discussions. If a draft is = needed for agenda time I can probably work something up before the -00 = deadine of October 15th. =20 >=20 > We could of course discuss Paul's S/MIME draft as it fits into the = "Using DANE with $foo" category. Jakob and I will have another draft this week that covers the issue = brought up earlier about us not dealing with the TLS-specific topic = diffs. It is not at all clear that a face-to-face meeting will be useful = in finding more of those or in fixing other errors in our draft. --Paul Hoffman= From dan-ietf@danyork.org Mon Oct 1 08:07:26 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1DA1F0D17 for ; Mon, 1 Oct 2012 08:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[AWL=0.986, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffYSSmlKxNaa for ; Mon, 1 Oct 2012 08:07:24 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 92B3611E8117 for ; Mon, 1 Oct 2012 08:07:23 -0700 (PDT) Received: by qcac10 with SMTP id c10so2966971qca.31 for ; Mon, 01 Oct 2012 08:07:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=CIDsP6n1185msHgzRPsdQlBrYs2/8aTjmhGsTLxcmQk=; b=EfZXVbH8e8nj2WNHu6JE++pYRTHBQdeTqzNfAuMfkGcsALlohgMOyD3ZvSYENXCUP/ bi+4WXMY9MuejPCRy833CBGzBSWvmdQz2WJMFo8OAkRCntWuM031mtMHn/3429cqTVjh f7+DGfDAoObV/nxs1bjbHIBZNB1lexRwJYWp+vtUfc1/Dx5m7eUtCpE/Czv+t9OcFyYb F4phwUdjNIilTudpOKyMJgfwZyYVSQxx2g3C7JzOK1+H+ZoyTIF1ljgtDE/7ETQccqPN 34TtWMSRUEDs1HremOSsokDvoWdK5zQU+XvI+YsN0/lAUyVhiBLr0/MTzrGt4MGCVvSW /VcQ== Received: by 10.224.168.83 with SMTP id t19mr37650269qay.8.1349104036439; Mon, 01 Oct 2012 08:07:16 -0700 (PDT) Received: from ?IPv6:2001:470:1f07:309:d9e7:4498:ffca:c4b3? ([2001:470:1f07:309:d9e7:4498:ffca:c4b3]) by mx.google.com with ESMTPS id gx8sm24752331qab.12.2012.10.01.08.07.15 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 01 Oct 2012 08:07:15 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_319FAF05-F497-460E-928B-FD9A6FF51F52" From: Dan York In-Reply-To: <76960946-F768-422B-A76A-17D951D29C8C@vpnc.org> Date: Mon, 1 Oct 2012 11:07:13 -0400 Message-Id: References: <15ED757A-9B2F-45CD-A1B6-0A0C8DFC2397@danyork.org> <76960946-F768-422B-A76A-17D951D29C8C@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQl4Ofsr9Has2jCwt1S+DHL9qz5/tq9OOsTcWfrX6+yroeF8gbZUJphmfZlrrZRJLt9EAgym Cc: dane WG list Subject: Re: [dane] Deployment focus? Re: IETF 85 - meet or not to meet? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 01 Oct 2012 15:07:26 -0000 --Apple-Mail=_319FAF05-F497-460E-928B-FD9A6FF51F52 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Paul, > The IETF is not a protocol promotion body. We do it sometimes, but = often with bad results. Good point... and I realize that my first idea listed is well off in the = "promotion" area. Perhaps a better/safer area to discuss would be "are = there technical issues or barriers that would prevent DANE from being = deployed?" > That proposed agenda is much more in the realm of Internet Society = work than IETF work. Perhaps you should talk to people at ISOC about = hosting an meeting to discuss these things? :-) (smiling) I assume by the :-) that you know that these kind of = deployment issues are precisely what I am employed by the Internet = Society to work on via the Deploy360 Programme. So yes, my brain is = kind of hard-wired into looking at "creating these standards is nice, = but how do we get people to actually *use* them?" Certainly ISOC *could* hold a meeting to discuss how to get DANE more = widely deployed ... and the people that would need to be at that meeting = would be, well, probably pretty much many of the people who would be at = the DANE working group meeting at IETF!=20 Regards, Dan --=20 Dan York dyork@lodestar2.com http://www.danyork.me/ skype:danyork Phone: +1-802-735-1624 Twitter - http://twitter.com/danyork --Apple-Mail=_319FAF05-F497-460E-928B-FD9A6FF51F52 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
The IETF is = not a protocol promotion body. We do it sometimes, but often with bad = results.

Good point... and I realize = that my first idea listed is well off in the "promotion" area. Perhaps a = better/safer area to discuss would be "are there technical issues or = barriers that would prevent DANE from being = deployed?"

That = proposed agenda is much more in the realm of Internet Society work than = IETF work. Perhaps you should talk to people at ISOC about hosting an = meeting to discuss these things? = :-)

(smiling) I assume by the :-) that = you know that these kind of deployment issues are precisely what I am = employed by the Internet Society to work on via the Deploy360 Programme. =  So yes, my brain is kind of hard-wired into looking at "creating = these standards is nice, but how do we get people to actually *use* = them?"

Certainly ISOC *could* hold a meeting to = discuss how to get DANE more widely deployed ... and the people that = would need to be at that meeting would be, well, probably pretty much = many of the people who would be at the DANE working group meeting at = IETF! 

Regards,
Dan
<= br>
-- 
Dan York  dyork@lodestar2.com
http://www.danyork.me/  &nb= sp;skype:danyork
Phone: = +1-802-735-1624
Twitter - http://twitter.com/danyork

= --Apple-Mail=_319FAF05-F497-460E-928B-FD9A6FF51F52-- From sm@resistor.net Mon Oct 1 08:46:32 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77DEB1F0D28 for ; Mon, 1 Oct 2012 08:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ylm1Y+NiXDeD for ; Mon, 1 Oct 2012 08:46:32 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id D6AB91F0C7E for ; Mon, 1 Oct 2012 08:46:31 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q91FkMpT012322 for ; Mon, 1 Oct 2012 08:46:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1349106391; bh=s9b0bOqoiPRi5IPpOkjguUM7krIhxGMheuqH3snGyI8=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=v/JjRdlUMUUEZxPZn8pucnV/ej+tfdz4w6XT5mhyuzvTE/mhYVTVq1VRT9pzM7LHA bvG02qcKnI3kFMeO/OvPo8q1T47R723R6Eezi0sdTB+UE/glSC50EuxRrrYfqu60Yg zwPsWtMMKNM866FdZAjt39XTbDL3U55khTjS0Ng4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1349106391; i=@resistor.net; bh=s9b0bOqoiPRi5IPpOkjguUM7krIhxGMheuqH3snGyI8=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=gIKqeZPlMvyhV6IoRxlNDN3yWFSc9RxeHcJuzlpxxxhFlHGgkyRm+0HjKzFI7yR1V rxRH962pd9JSbrBiQzfPS3l+NQ66Ak0TS3EQOmOegwDa8TsQ6LNkuHwHYd1Kzo2chB S7M8wssYomJy0OXAMSv/VTvL6IRxcDn9pKbsw5w0= Message-Id: <6.2.5.6.2.20121001081410.0b34dab0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 01 Oct 2012 08:22:52 -0700 To: dane@ietf.org From: SM In-Reply-To: <15ED757A-9B2F-45CD-A1B6-0A0C8DFC2397@danyork.org> References: <15ED757A-9B2F-45CD-A1B6-0A0C8DFC2397@danyork.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [dane] Deployment focus? Re: IETF 85 - meet or not to meet? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 01 Oct 2012 15:46:32 -0000 At 06:37 01-10-2012, Dan York wrote: >Could we perhaps have an agenda more focused on the question of >"what comes next?" and looking at obstacles to DANE deployment? > >Some ideas: > - Discussion of what needs to be done to get DANE more widely > deployed, specifically: > 1. What steps do we collectively need to take to get adding > DANE support on the radar of browser vendors? Send patch is usually a first step. > 2. What do we need to do to get more registrars/DNS hosting > providers accepting TLSA records? There have been some long threads about a similar question. In my opinion it's not making effective use of a meeting slot if there isn't any WG issues which need face time. Regards, -sm From paul.hoffman@vpnc.org Mon Oct 1 08:52:49 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE51D21F893B for ; Mon, 1 Oct 2012 08:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4s20ekwezHP for ; Mon, 1 Oct 2012 08:52:49 -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 21D7321F8932 for ; Mon, 1 Oct 2012 08:52:49 -0700 (PDT) Received: from [10.20.30.108] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q91Fqkcl029055 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 1 Oct 2012 08:52:46 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Paul Hoffman In-Reply-To: Date: Mon, 1 Oct 2012 08:52:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2931E1FC-20D3-4045-9146-368D3AC9D989@vpnc.org> References: <15ED757A-9B2F-45CD-A1B6-0A0C8DFC2397@danyork.org> <76960946-F768-422B-A76A-17D951D29C8C@vpnc.org> To: Dan York X-Mailer: Apple Mail (2.1498) Cc: dane WG list Subject: Re: [dane] Deployment focus? Re: IETF 85 - meet or not to meet? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 01 Oct 2012 15:52:49 -0000 On Oct 1, 2012, at 8:07 AM, Dan York wrote: >> The IETF is not a protocol promotion body. We do it sometimes, but = often with bad results. >=20 > Good point... and I realize that my first idea listed is well off in = the "promotion" area. Perhaps a better/safer area to discuss would be = "are there technical issues or barriers that would prevent DANE from = being deployed?" If there are, that would be an excellent topic for the dnsop WG. That = is, if there are technical issues with DANE, there are likely to be = issues with other new RRtypes as well. >> That proposed agenda is much more in the realm of Internet Society = work than IETF work. Perhaps you should talk to people at ISOC about = hosting an meeting to discuss these things? :-) >=20 > (smiling) I assume by the :-) that you know that these kind of = deployment issues are precisely what I am employed by the Internet = Society to work on via the Deploy360 Programme. So yes, my brain is = kind of hard-wired into looking at "creating these standards is nice, = but how do we get people to actually *use* them?" >=20 > Certainly ISOC *could* hold a meeting to discuss how to get DANE more = widely deployed ... and the people that would need to be at that meeting = would be, well, probably pretty much many of the people who would be at = the DANE working group meeting at IETF!=20 We fully disagree there. Protocol developers are often not protocol = deployers. For example, I do not contribute to DNS server or DNS admin = projects; the same would be true for the large majority of the people = who contributed ideas and comments to the DANE protocol. ISOC could pull together a meeting of such protocol deployers, as well = as enterprises who might find DANE useful, and I suspect the overlap = between people at that meeting and the last DANE WG meeting would be = very small. --Paul Hoffman= From dan-ietf@danyork.org Tue Oct 2 12:35:03 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7440821F856C for ; Tue, 2 Oct 2012 12:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.488 X-Spam-Level: X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=0.510, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4jLv4a3BytKI for ; Tue, 2 Oct 2012 12:35:02 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id F327321F8570 for ; Tue, 2 Oct 2012 12:35:01 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id 25so1006974qao.10 for ; Tue, 02 Oct 2012 12:35:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=Az7bfH1rHWlTG5jPOVimfXHx88BZit2sBSKEFcwazvM=; b=bI31uda0LbIBgVkX3tJOHBfzU3UJrCh+7cC5dsI2394PjUnS3ZLDnJ0Ails6SWtOz/ zC2AqExc+isQByt8iA+vBq4lBp69xiZXqz5Om8XBnmc7n5BKfQANavIkPbh2vfCYN6fC BJ8cSRwzchy92GcTzRwjfPO29rDsoOk1nEJvokR0GM3l8g9D1pEizmKYlcIxG+ZK9vvv jquNDRoZkuB+wm5FqmFQ/y5LX24B87Xghfsq6E4/DyAtI2YffLmdXBOAzX0qJytCdo4N 6PyGmuYvUejSUnsD6BabgHsht/yR8w60Pevx0uqcHorApeg40e14DfneD1xHlQxTrxLJ FfbA== Received: by 10.49.132.38 with SMTP id or6mr7240388qeb.26.1349206501373; Tue, 02 Oct 2012 12:35:01 -0700 (PDT) Received: from [172.20.12.152] (cpe-74-75-92-114.maine.res.rr.com. [74.75.92.114]) by mx.google.com with ESMTPS id ck11sm2198935qab.17.2012.10.02.12.34.59 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 02 Oct 2012 12:35:00 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_9B59F277-21BA-446E-ABD9-D5B37AF95212" From: Dan York In-Reply-To: <2931E1FC-20D3-4045-9146-368D3AC9D989@vpnc.org> Date: Tue, 2 Oct 2012 15:34:57 -0400 Message-Id: References: <15ED757A-9B2F-45CD-A1B6-0A0C8DFC2397@danyork.org> <76960946-F768-422B-A76A-17D951D29C8C@vpnc.org> <2931E1FC-20D3-4045-9146-368D3AC9D989@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQlcMjqOj24cRv8IjwNh15Io8NsSnGROjnqmIxdPPqJHSdSmrUXuQgOud2Ayr39tofjIMdnN Cc: dane WG list Subject: Re: [dane] Deployment focus? Re: IETF 85 - meet or not to meet? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 02 Oct 2012 19:35:03 -0000 --Apple-Mail=_9B59F277-21BA-446E-ABD9-D5B37AF95212 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Paul, On Oct 1, 2012, at 11:52 AM, Paul Hoffman wrote: > On Oct 1, 2012, at 8:07 AM, Dan York wrote: >=20 >> Certainly ISOC *could* hold a meeting to discuss how to get DANE more = widely deployed ... and the people that would need to be at that meeting = would be, well, probably pretty much many of the people who would be at = the DANE working group meeting at IETF!=20 >=20 > We fully disagree there. Protocol developers are often not protocol = deployers. For example, I do not contribute to DNS server or DNS admin = projects; the same would be true for the large majority of the people = who contributed ideas and comments to the DANE protocol. >=20 > ISOC could pull together a meeting of such protocol deployers, as well = as enterprises who might find DANE useful, and I suspect the overlap = between people at that meeting and the last DANE WG meeting would be = very small. Sigh... I will have to confess that you are probably on target here, = particularly as no one else has chimed in on this general thread in the = last 24 hours.=20 And thus we continue with the challenge that we in the IETF typically = define something as "done" when "the protocol is defined" and not when = "people can actually use the protocol". =20 Here we have this truly awesome piece of work, DANE, and here it will = linger in limbo until eventually maybe someday someone somewhere can = implement it in some fashion that some people can use in some way. Certainly I can - and will - do everything I can both personally and = within ISOC's various means to get people talking about DANE and moving = toward deployment. Within the Deploy360 Programme, we've been talking = to a good number of people about how to advance the advocacy and = promotion of DNSSEC... and we have been planning to incorporate DANE = into that effort. But as much as we can do, we're still one = organization - or even a group of organizations and companies. We need = many more people involved. I know you may not think of yourself as a "protocol deployer", Paul, but = I would argue that we do need everyone on this list thinking about how = we can get DANE deployed. DANE is far too awesome - and far too powerful - to let it linger in = limbo. My 2 cents, Dan --=20 Dan York dyork@lodestar2.com http://www.danyork.me/ skype:danyork Phone: +1-802-735-1624 Twitter - http://twitter.com/danyork --Apple-Mail=_9B59F277-21BA-446E-ABD9-D5B37AF95212 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Oct 1, 2012, at 8:07 AM, Dan York <dan-ietf@danyork.org> = wrote:

Certainly ISOC *could* hold a = meeting to discuss how to get DANE more widely deployed ... and the = people that would need to be at that meeting would be, well, probably = pretty much many of the people who would be at the DANE working group = meeting at IETF! 

We fully disagree there. Protocol = developers are often not protocol deployers. For example, I do not = contribute to DNS server or DNS admin projects; the same would be true = for the large majority of the people who contributed ideas and comments = to the DANE protocol.

ISOC could pull together a meeting of such = protocol deployers, as well as enterprises who might find DANE useful, = and I suspect the overlap between people at that meeting and the last = DANE WG meeting would be very = small.

Sigh... I will have to = confess that you are probably on target here, particularly as no one = else has chimed in on this general thread in the last 24 = hours. 

And thus we continue with the = challenge that we in the IETF typically define something as "done" when = "the protocol is defined" and not when "people can actually use the = protocol".  

Here we have this truly = awesome piece of work, DANE, and here it will linger in limbo until = eventually maybe someday someone somewhere can implement it in some = fashion that some people can use in some = way.

Certainly I can - and will - do everything = I can both personally and within ISOC's various means to get people = talking about DANE and moving toward deployment.  Within the = Deploy360 Programme, we've been talking to a good number of people about = how to advance the advocacy and promotion of DNSSEC... and we have been = planning to incorporate DANE into that effort.  But as much as we = can do, we're still one organization - or even a group of organizations = and companies.  We need many more people = involved.

I know you may not think of yourself = as a "protocol deployer", Paul, but I would argue that we do need = everyone on this list thinking about how we can get DANE = deployed.

DANE is far too awesome - and far too = powerful - to let it linger in limbo.

My 2 = cents,
Dan

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

= --Apple-Mail=_9B59F277-21BA-446E-ABD9-D5B37AF95212-- From warren@kumari.net Tue Oct 2 14:27:51 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB39121F8448 for ; Tue, 2 Oct 2012 14:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_57=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AjHLT6X80drC for ; Tue, 2 Oct 2012 14:27:51 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2198521F84F9 for ; Tue, 2 Oct 2012 14:27:51 -0700 (PDT) Received: from [192.168.194.120] (216-239-44-65.google.com [216.239.44.65]) by vimes.kumari.net (Postfix) with ESMTPSA id 571ED1B4041C; Tue, 2 Oct 2012 17:27:50 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Warren Kumari In-Reply-To: Date: Tue, 2 Oct 2012 17:27:47 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9AC8675C-22B6-4502-9E00-FB51B9D36F34@kumari.net> References: <15ED757A-9B2F-45CD-A1B6-0A0C8DFC2397@danyork.org> <76960946-F768-422B-A76A-17D951D29C8C@vpnc.org> <2931E1FC-20D3-4045-9146-368D3AC9D989@vpnc.org> To: Dan York X-Mailer: Apple Mail (2.1498) Cc: Paul Hoffman , dane WG list Subject: Re: [dane] Deployment focus? Re: IETF 85 - meet or not to meet? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 02 Oct 2012 21:27:52 -0000 On Oct 2, 2012, at 3:34 PM, Dan York wrote: > Paul, >=20 > On Oct 1, 2012, at 11:52 AM, Paul Hoffman wrote: >=20 >> On Oct 1, 2012, at 8:07 AM, Dan York wrote: >>=20 >>> Certainly ISOC *could* hold a meeting to discuss how to get DANE = more widely deployed ... and the people that would need to be at that = meeting would be, well, probably pretty much many of the people who = would be at the DANE working group meeting at IETF!=20 >>=20 >> We fully disagree there. Protocol developers are often not protocol = deployers. For example, I do not contribute to DNS server or DNS admin = projects; the same would be true for the large majority of the people = who contributed ideas and comments to the DANE protocol. >>=20 >> ISOC could pull together a meeting of such protocol deployers, as = well as enterprises who might find DANE useful, and I suspect the = overlap between people at that meeting and the last DANE WG meeting = would be very small. >=20 > Sigh... I will have to confess that you are probably on target here, = particularly as no one else has chimed in on this general thread in the = last 24 hours.=20 >=20 > And thus we continue with the challenge that we in the IETF typically = define something as "done" when "the protocol is defined" and not when = "people can actually use the protocol". =20 >=20 > Here we have this truly awesome piece of work, DANE, and here it will = linger in limbo until eventually maybe someday someone somewhere can = implement it in some fashion that some people can use in some way. >=20 > Certainly I can - and will - do everything I can both personally and = within ISOC's various means to get people talking about DANE and moving = toward deployment. Within the Deploy360 Programme, we've been talking = to a good number of people about how to advance the advocacy and = promotion of DNSSEC... and we have been planning to incorporate DANE = into that effort. But as much as we can do, we're still one = organization - or even a group of organizations and companies. We need = many more people involved. >=20 > I know you may not think of yourself as a "protocol deployer", Paul, = but I would argue that we do need everyone on this list thinking about = how we can get DANE deployed. >=20 > DANE is far too awesome - and far too powerful - to let it linger in = limbo. Thanks, we are glad you like it :-) More seriously though, this is yet another chicken-and-egg problem=85 In this particular case I think that the easiest / fastest way to get = better deployment is to convince the browser manufactures to include = support for DANE -- this will incentivize[0] folk to deploy records=85 W [0]: Whoohoo, "incentivize" ! >=20 > My 2 cents, > Dan >=20 > --=20 > Dan York dyork@lodestar2.com > http://www.danyork.me/ skype:danyork > Phone: +1-802-735-1624 > Twitter - http://twitter.com/danyork >=20 >=20 >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From n.mavrogiannopoulos@gmail.com Wed Oct 3 02:11:10 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0910D21F86B2 for ; Wed, 3 Oct 2012 02:11:10 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afEEEJhbnpfH for ; Wed, 3 Oct 2012 02:11:09 -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 6386821F86AF for ; Wed, 3 Oct 2012 02:11:09 -0700 (PDT) Received: by vbbfc26 with SMTP id fc26so8605940vbb.31 for ; Wed, 03 Oct 2012 02:11:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=p4mTIUX9z+SbjlwYaE/SVc+FX1v+wLOyUiTpqo3mYts=; b=JWWiXFXqOqhduolHKxusnq7G7zKB+PvbtYSqCyKD7b7LNZt4zZg8VSmGasU7IB2mf1 kQoT9GXQtSimRfNKf2TjT+Qlpvm3jy+MFv4OBM6aqgVJ3YJ2sH7KoUC1ER6mQdjmBu1h UxckRQtOTnVixAxW8zl2D6q3gCrHCTp+qcgth2qQixjOsvVbW7TrRlm0RY9XcvzKymPz yT4vaZD658Ja+pghTEP8VGBM33Kz13kmSRqlYNRcu+kFb/fYuD34tHZ37EjltIF9RUgO 4toiFE4n4uRlgUZAI+eqKF3wNbLHoCQwZAo2UuU5HUCsas5yFMiMV71vsv95VwPNaX6Q V6ig== MIME-Version: 1.0 Received: by 10.52.92.11 with SMTP id ci11mr650877vdb.7.1349255468597; Wed, 03 Oct 2012 02:11:08 -0700 (PDT) Received: by 10.58.128.133 with HTTP; Wed, 3 Oct 2012 02:11:08 -0700 (PDT) Date: Wed, 3 Oct 2012 11:11:08 +0200 Message-ID: From: Nikos Mavrogiannopoulos To: dane@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [dane] DANE test sites X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Oct 2012 09:11:10 -0000 Are there any test or even real world https sites that support DANE? regards, Nikos From bortzmeyer@nic.fr Wed Oct 3 02:28:09 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20B9A21F86B7 for ; Wed, 3 Oct 2012 02:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.453 X-Spam-Level: X-Spam-Status: No, score=-101.453 tagged_above=-999 required=5 tests=[AWL=-0.342, BAYES_05=-1.11, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRrmnj2AQgM0 for ; Wed, 3 Oct 2012 02:28:08 -0700 (PDT) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [IPv6:2001:4b98:dc0:41:216:3eff:fece:1902]) by ietfa.amsl.com (Postfix) with ESMTP id 32BD321F8680 for ; Wed, 3 Oct 2012 02:28:08 -0700 (PDT) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 46C8E3B43D; Wed, 3 Oct 2012 09:28:06 +0000 (UTC) Received: by mail.sources.org (Postfix, from userid 1000) id 7219E1907CB; Wed, 3 Oct 2012 11:27:22 +0200 (CEST) Date: Wed, 3 Oct 2012 11:27:22 +0200 From: Stephane Bortzmeyer To: Nikos Mavrogiannopoulos Message-ID: <20121003092722.GA8041@sources.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 6.0.5 User-Agent: Mutt/1.5.20 (2009-06-14) Cc: dane@ietf.org Subject: Re: [dane] DANE test sites X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Oct 2012 09:28:09 -0000 On Wed, Oct 03, 2012 at 11:11:08AM +0200, Nikos Mavrogiannopoulos wrote a message of 8 lines which said: > Are there any test or even real world https sites that support DANE? A test one is https://dane.rd.nic.fr/ If you want a broken one, use https://dane-broken.rd.nic.fr/ From n.mavrogiannopoulos@gmail.com Wed Oct 3 02:58:06 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C74921F86AA for ; Wed, 3 Oct 2012 02:58:06 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mgt3IewM8dlg for ; Wed, 3 Oct 2012 02:58:05 -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 2586721F84DC for ; Wed, 3 Oct 2012 02:58:05 -0700 (PDT) Received: by vbbfc26 with SMTP id fc26so8656669vbb.31 for ; Wed, 03 Oct 2012 02:58:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fkm+kxP8UC93fpaMgKGK32Ry8pv2e9MJJKvQQt3LAho=; b=rCr+Z+HiSaWZDQtUwXCawysYvHC/EEbMvwUZval/B06zJkuijhvdFn8Jcu9batLFTm ApmfXZllGyWbh/W5MgF9VbwyqTn7gBJi64kC9jVd4/kZGHaM6WkK6UoZIGm/dkJYtbOe /njQXiPUguGDWHtyB5lR48nR1l4hjFWqLmaBazqhv+GMaImUEH+PqqXv55zrFVE8+AFp PKZDA6rKnGp1YzOKu4XpOKprgjDbDXfO+cm02Adhw+HY/qITX+1qGYKiTNz94ye2hXFV w5AAj57vF2hLiSbfmwtUpvDXoQ3KrxHAJFKMfQ1Fi382foXw1nWV/spU8hs1HyOiMBiA UM1Q== MIME-Version: 1.0 Received: by 10.220.205.200 with SMTP id fr8mr816217vcb.34.1349258284368; Wed, 03 Oct 2012 02:58:04 -0700 (PDT) Received: by 10.58.128.133 with HTTP; Wed, 3 Oct 2012 02:58:04 -0700 (PDT) In-Reply-To: <20121003092722.GA8041@sources.org> References: <20121003092722.GA8041@sources.org> Date: Wed, 3 Oct 2012 11:58:04 +0200 Message-ID: From: Nikos Mavrogiannopoulos To: Stephane Bortzmeyer , marco.davids@sidn.nl Content-Type: text/plain; charset=UTF-8 Cc: dane@ietf.org Subject: Re: [dane] DANE test sites X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Oct 2012 09:58:06 -0000 On Wed, Oct 3, 2012 at 11:27 AM, Stephane Bortzmeyer wrote: >> Are there any test or even real world https sites that support DANE? >> My own domain has a TLSA record: https://forfun.net > A test one is https://dane.rd.nic.fr/ > If you want a broken one, use https://dane-broken.rd.nic.fr/ Thank you! Nikos From wouter@nlnetlabs.nl Wed Oct 3 05:18:32 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7366321F84FF for ; Wed, 3 Oct 2012 05:18:32 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLd7QDIQWhJp for ; Wed, 3 Oct 2012 05:18:31 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id DED8421F84FC for ; Wed, 3 Oct 2012 05:18:30 -0700 (PDT) Received: from [192.168.254.2] (82-170-121-249.ip.open.net [82.170.121.249]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.5/8.14.4) with ESMTP id q93CIPTW065765 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 3 Oct 2012 14:18:25 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) X-DKIM: OpenDKIM Filter v2.6.7 open.nlnetlabs.nl q93CIPTW065765 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1349266706; bh=4ers9IBlVyTgWAz5NyLBxD7qJFexRNPJJVBH8s0yL/M=; h=Date:From:To:Subject:References:In-Reply-To; b=O4t6XNvGwwKH4ijtsjSCuHMFn43KlXMHUsc/+Yvw3FvaMHjl0Nz+wX9zrH95+7DaW laXsk/ytgxsPmUQ3nQ/Zug0s1CqUf2Rz587SWvcQBcwiXpM1Gf1b8UL/W14jJeHJf+ 0BWjMoAvU8qEBSGQ/SL6ePrQ1sMVtfmsCaeCVIx8= Message-ID: <506C2D18.9010100@nlnetlabs.nl> Date: Wed, 03 Oct 2012 14:18:32 +0200 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120825 Thunderbird/15.0 MIME-Version: 1.0 To: dane@ietf.org References: <20121003092722.GA8041@sources.org> In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [213.154.224.1]); Wed, 03 Oct 2012 14:18:25 +0200 (CEST) Subject: Re: [dane] DANE test sites X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Oct 2012 12:18:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Nikos, On 10/03/2012 11:58 AM, Nikos Mavrogiannopoulos wrote: > On Wed, Oct 3, 2012 at 11:27 AM, Stephane Bortzmeyer > wrote: > >>> Are there any test or even real world https sites that support >>> DANE? My own domain has a TLSA record: https://forfun.net >> A test one is https://dane.rd.nic.fr/ If you want a broken one, >> use https://dane-broken.rd.nic.fr/ www.nlnetlabs.nl has dane. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQbC0YAAoJEJ9vHC1+BF+NO5gP/3qqcjyHpYU3P5U05RdGgMPH eYbXBguHcNgF0ymzd1CwsL5J3oLd71aSBkTWJN3yUWXvkEvVSw7S6gWz+DG828u4 DXWd2EDmmyAaQIbCNVmDIilLePSgoDdvwZ7ciIijchmXbnfgHNS8FZEL5PtSlqWU Do0u8pSQFhxeM62RcPJbsmp26/SpgsMaKYVKAbuBESws8U9ssOp6j+Y55st5R8aq NVh1VtGmTur4Mbwt7RathaVm9wZ0XDDrvYXiGV+GwFfo33y7B07bK+s/DMkiIRpn e/TzP5/PuAq6aC1/goRp6LxsOGQ+PBeOnpfxqZUaX2ROEUFZag/iM9XinyU18Eo/ SCBtD/CXsIBBJrJPTLXeRDnRIMQWROIjcTXBaqrrVdNARSpYSBERgm5biI/J77Ml Fj7e7GlgBsCkk1mC0hzd/d7Est5kzct1IGgS9Dl3uWPDK/uj80l82vr3VwROwDxx JL0EAMgce5b7ka7fROafFU5l8XMitngcDwoMy35H39DISbWXcg+IwJnL+xNGcWxy 7wkO6ZFvKrVY/sVA7dQ6Y0vENoZr5d84/an3TNFz6yzRRszNq0rUwvmIi35iQePB nI+bFd1ZKbou3Fyt5VWwbOqo6yiQg7EcfO4BOV5sz0BkfNvbgphSrtQqIxrXcb68 Fi591F6iyczznYtf/16X =eild -----END PGP SIGNATURE----- From paul@cypherpunks.ca Wed Oct 3 07:34:38 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6D4721F8680 for ; Wed, 3 Oct 2012 07:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6ySpgN6DPGu for ; Wed, 3 Oct 2012 07:34:37 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 482B921F866C for ; Wed, 3 Oct 2012 07:34:37 -0700 (PDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 0AFEB8046E; Wed, 3 Oct 2012 10:34:33 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id F023280460; Wed, 3 Oct 2012 10:34:33 -0400 (EDT) Date: Wed, 3 Oct 2012 10:34:33 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Nikos Mavrogiannopoulos In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: dane WG list Subject: Re: [dane] DANE test sites X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Oct 2012 14:34:38 -0000 On Wed, 3 Oct 2012, Nikos Mavrogiannopoulos wrote: > Are there any test or even real world https sites that support DANE? fedoraproject.org torproject.org hacklab.to nohats.ca rogue.nohats.ca (though that ssl cert should get renewed, just didn't want to pay $250) Paul From sm@resistor.net Wed Oct 3 07:36:47 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7044221F8652 for ; Wed, 3 Oct 2012 07:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ww34bzQfkfHP for ; Wed, 3 Oct 2012 07:36:46 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id AEF5621F84F6 for ; Wed, 3 Oct 2012 07:36:46 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q93EaeIc009446; Wed, 3 Oct 2012 07:36:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1349275005; bh=xc1LAO6r1dKOuPy17sKSJSAONuxL5L+ovuWvBLh6OSs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=PnwKob6PtvFLgbKyqb3FluM2Uw49e8hdTvZbtmLPPiGuRaLh6b2VL6ojGly9JfNBZ c8zHyJMugh0+fptbkkoLc/TqQfEDCfK66Lb+geWylH+4UIPbCGR4IKM0HKgs904iyz V6RfksMp09Elc8xjcwioA18xJ/kKlSqrjlPVinPU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1349275005; i=@resistor.net; bh=xc1LAO6r1dKOuPy17sKSJSAONuxL5L+ovuWvBLh6OSs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=PrYy+r0ZEkXTVwNjVXY5UpWPEVa7ecR6C9CsqbbrFrS7wvbG+ca5Q5MPgksVn5zWA 70M4AyfdKVTTI0OLmftbmYCEHecYQ39wfHBUofKlnwDQNtvsmwz+MAn0gg30W6lKPX ruER0yuGb1ZelApZuGwhPkKW8Is5ADSXtP0rA2+I= Message-Id: <6.2.5.6.2.20121003072919.0b377858@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 03 Oct 2012 07:32:15 -0700 To: Stephane Bortzmeyer From: SM In-Reply-To: <20121003092722.GA8041@sources.org> References: <20121003092722.GA8041@sources.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: dane@ietf.org Subject: Re: [dane] DANE test sites X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Oct 2012 14:36:47 -0000 Hi Stephane, At 02:27 03-10-2012, Stephane Bortzmeyer wrote: >A test one is https://dane.rd.nic.fr/ The certificate is only valid for www.dane.rd.nic.fr. See DNS reply below: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57147 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;www.dane.rd.nic.fr. IN A ;; AUTHORITY SECTION: dane.rd.nic.fr. 3600 IN NS dane.rd.nic.fr. dane.rd.nic.fr. 3600 IN NS ns3.nic.fr. Regards, -sm From daniel.piggott@switch2it.co.uk Wed Oct 3 08:58:54 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20F0821F84B5 for ; Wed, 3 Oct 2012 08:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.55 X-Spam-Level: X-Spam-Status: No, score=-0.55 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_57=0.6, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6lwkMmYm+e9g for ; Wed, 3 Oct 2012 08:58:53 -0700 (PDT) Received: from mail50.extendcp.co.uk (mail50.extendcp.co.uk [79.170.44.50]) by ietfa.amsl.com (Postfix) with ESMTP id 523F821F8484 for ; Wed, 3 Oct 2012 08:58:53 -0700 (PDT) Received: from switchtx.gotadsl.co.uk ([62.3.238.89] helo=88181134W) by mail50.extendcp.com with esmtpa (Exim 4.77) id 1TJRLX-0004Zo-9q for dane@ietf.org; Wed, 03 Oct 2012 16:58:51 +0100 From: "Daniel Piggott" To: References: <15ED757A-9B2F-45CD-A1B6-0A0C8DFC2397@danyork.org> <76960946-F768-422B-A76A-17D951D29C8C@vpnc.org> <2931E1FC-20D3-4045-9146-368D3AC9D989@vpnc.org> <9AC8675C-22B6-4502-9E00-FB51B9D36F34@kumari.net> In-Reply-To: <9AC8675C-22B6-4502-9E00-FB51B9D36F34@kumari.net> Date: Wed, 3 Oct 2012 16:58:39 +0100 Organization: Switch2IT Ltd Message-ID: <014301cda17f$f46460b0$dd2d2210$@piggott@switch2it.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2g5MRNYYJBEZI/RhGt2Dcm6vdVfAAmkuqQ Content-Language: en-gb X-Authenticated-As: daniel.piggott@switch2it.co.uk X-Mailman-Approved-At: Wed, 03 Oct 2012 10:44:36 -0700 Subject: Re: [dane] Deployment focus? Re: IETF 85 - meet or not to meet? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: daniel.piggott@switch2it.co.uk List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 17:42:10 -0000 Is google not already using this in chrome? -----Original Message----- From: Warren Kumari [mailto:warren@kumari.net] Sent: 02 October 2012 22:28 To: Dan York Cc: Paul Hoffman; dane WG list Subject: Re: [dane] Deployment focus? Re: IETF 85 - meet or not to meet? On Oct 2, 2012, at 3:34 PM, Dan York wrote: > Paul, > > On Oct 1, 2012, at 11:52 AM, Paul Hoffman wrote: > >> On Oct 1, 2012, at 8:07 AM, Dan York wrote: >> >>> Certainly ISOC *could* hold a meeting to discuss how to get DANE more widely deployed ... and the people that would need to be at that meeting would be, well, probably pretty much many of the people who would be at the DANE working group meeting at IETF! >> >> We fully disagree there. Protocol developers are often not protocol deployers. For example, I do not contribute to DNS server or DNS admin projects; the same would be true for the large majority of the people who contributed ideas and comments to the DANE protocol. >> >> ISOC could pull together a meeting of such protocol deployers, as well as enterprises who might find DANE useful, and I suspect the overlap between people at that meeting and the last DANE WG meeting would be very small. > > Sigh... I will have to confess that you are probably on target here, particularly as no one else has chimed in on this general thread in the last 24 hours. > > And thus we continue with the challenge that we in the IETF typically define something as "done" when "the protocol is defined" and not when "people can actually use the protocol". > > Here we have this truly awesome piece of work, DANE, and here it will linger in limbo until eventually maybe someday someone somewhere can implement it in some fashion that some people can use in some way. > > Certainly I can - and will - do everything I can both personally and within ISOC's various means to get people talking about DANE and moving toward deployment. Within the Deploy360 Programme, we've been talking to a good number of people about how to advance the advocacy and promotion of DNSSEC... and we have been planning to incorporate DANE into that effort. But as much as we can do, we're still one organization - or even a group of organizations and companies. We need many more people involved. > > I know you may not think of yourself as a "protocol deployer", Paul, but I would argue that we do need everyone on this list thinking about how we can get DANE deployed. > > DANE is far too awesome - and far too powerful - to let it linger in limbo. Thanks, we are glad you like it :-) More seriously though, this is yet another chicken-and-egg problem. In this particular case I think that the easiest / fastest way to get better deployment is to convince the browser manufactures to include support for DANE -- this will incentivize[0] folk to deploy records. W [0]: Whoohoo, "incentivize" ! > > My 2 cents, > Dan > > -- > Dan York dyork@lodestar2.com > http://www.danyork.me/ skype:danyork > Phone: +1-802-735-1624 > Twitter - http://twitter.com/danyork > > > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From warren@kumari.net Wed Oct 3 10:50:47 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25DC321F84EA for ; Wed, 3 Oct 2012 10:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_57=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8AEHcAJjTcqf for ; Wed, 3 Oct 2012 10:50:46 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC2521F84D9 for ; Wed, 3 Oct 2012 10:50:46 -0700 (PDT) Received: from [192.168.1.139] (unknown [66.84.81.102]) by vimes.kumari.net (Postfix) with ESMTPSA id 9351B1B401FA; Wed, 3 Oct 2012 13:50:45 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Warren Kumari In-Reply-To: <014301cda17f$f46460b0$dd2d2210$@piggott@switch2it.co.uk> Date: Wed, 3 Oct 2012 13:50:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4AAF64D0-9413-468E-BD8C-3382EEFF3C40@kumari.net> References: <15ED757A-9B2F-45CD-A1B6-0A0C8DFC2397@danyork.org> <76960946-F768-422B-A76A-17D951D29C8C@vpnc.org> <2931E1FC-20D3-4045-9146-368D3AC9D989@vpnc.org> <9AC8675C-22B6-4502-9E00-FB51B9D36F34@kumari.net> <014301cda17f$f46460b0$dd2d2210$@piggott@switch2it.co.uk> To: daniel.piggott@switch2it.co.uk X-Mailer: Apple Mail (2.1498) Cc: dane@ietf.org Subject: Re: [dane] Deployment focus? Re: IETF 85 - meet or not to meet? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Oct 2012 17:50:47 -0000 On Oct 3, 2012, at 11:58 AM, "Daniel Piggott" = wrote: > Is google not already using this in chrome? Nope -- Chrome does do pinning = (http://www.imperialviolet.org/2011/05/04/pinning.html), HSTS, etc. Perhaps you were thinking of DNSSEC stapled certificates = (http://www.imperialviolet.org/2011/06/16/dnssecchrome.html ) -- this is = similar, bit different to DANE=85 W >=20 > -----Original Message----- > From: Warren Kumari [mailto:warren@kumari.net]=20 > Sent: 02 October 2012 22:28 > To: Dan York > Cc: Paul Hoffman; dane WG list > Subject: Re: [dane] Deployment focus? Re: IETF 85 - meet or not to = meet? >=20 >=20 > On Oct 2, 2012, at 3:34 PM, Dan York wrote: >=20 >> Paul, >>=20 >> On Oct 1, 2012, at 11:52 AM, Paul Hoffman wrote: >>=20 >>> On Oct 1, 2012, at 8:07 AM, Dan York wrote: >>>=20 >>>> Certainly ISOC *could* hold a meeting to discuss how to get DANE = more > widely deployed ... and the people that would need to be at that = meeting > would be, well, probably pretty much many of the people who would be = at the > DANE working group meeting at IETF!=20 >>>=20 >>> We fully disagree there. Protocol developers are often not protocol > deployers. For example, I do not contribute to DNS server or DNS admin > projects; the same would be true for the large majority of the people = who > contributed ideas and comments to the DANE protocol. >>>=20 >>> ISOC could pull together a meeting of such protocol deployers, as = well as > enterprises who might find DANE useful, and I suspect the overlap = between > people at that meeting and the last DANE WG meeting would be very = small. >>=20 >> Sigh... I will have to confess that you are probably on target here, > particularly as no one else has chimed in on this general thread in = the last > 24 hours.=20 >>=20 >> And thus we continue with the challenge that we in the IETF typically > define something as "done" when "the protocol is defined" and not when > "people can actually use the protocol". =20 >>=20 >> Here we have this truly awesome piece of work, DANE, and here it will > linger in limbo until eventually maybe someday someone somewhere can > implement it in some fashion that some people can use in some way. >>=20 >> Certainly I can - and will - do everything I can both personally and > within ISOC's various means to get people talking about DANE and = moving > toward deployment. Within the Deploy360 Programme, we've been talking = to a > good number of people about how to advance the advocacy and promotion = of > DNSSEC... and we have been planning to incorporate DANE into that = effort. > But as much as we can do, we're still one organization - or even a = group of > organizations and companies. We need many more people involved. >>=20 >> I know you may not think of yourself as a "protocol deployer", Paul, = but I > would argue that we do need everyone on this list thinking about how = we can > get DANE deployed. >>=20 >> DANE is far too awesome - and far too powerful - to let it linger in > limbo. >=20 > Thanks, we are glad you like it :-) >=20 > More seriously though, this is yet another chicken-and-egg problem. >=20 > In this particular case I think that the easiest / fastest way to get = better > deployment is to convince the browser manufactures to include support = for > DANE -- this will incentivize[0] folk to deploy records. >=20 > W >=20 > [0]: Whoohoo, "incentivize" ! >>=20 >> My 2 cents, >> Dan >>=20 >> --=20 >> Dan York dyork@lodestar2.com >> http://www.danyork.me/ skype:danyork >> Phone: +1-802-735-1624 >> Twitter - http://twitter.com/danyork >>=20 >>=20 >>=20 >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >=20 >=20 >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 From warren@kumari.net Wed Oct 3 11:06:24 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD22D21F845B for ; Wed, 3 Oct 2012 11:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.849 X-Spam-Level: X-Spam-Status: No, score=-101.849 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgD9B9NkTkbq for ; Wed, 3 Oct 2012 11:06:24 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 070B321F8203 for ; Wed, 3 Oct 2012 11:06:24 -0700 (PDT) Received: from [192.168.1.139] (unknown [66.84.81.102]) by vimes.kumari.net (Postfix) with ESMTPSA id A2D581B401FA; Wed, 3 Oct 2012 14:06:23 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Warren Kumari In-Reply-To: Date: Wed, 3 Oct 2012 14:06:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= , Stephen Farrell X-Mailer: Apple Mail (2.1498) Cc: dane WG list Subject: Re: [dane] IETF 85 - meet or not to meet? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Oct 2012 18:06:24 -0000 On Sep 30, 2012, at 5:00 AM, Warren Kumari wrote: >=20 > On Sep 24, 2012, at 3:10 PM, Ond=C5=99ej Sur=C3=BD = wrote: >=20 >> More specifically, we are going to cancel the session after Oct 4th = unless we hear from you that you want to meet and we have an agenda. >>=20 >=20 > Apologies all -- due to the contention for meeting slots and the = difficulty of scheduling all these slots we are moving the cutoff to the = 2nd. >=20 And sadly enough it looks like we should cancel this slot. I am very grateful to folk, Dan especially for wanting to meet, and for = being interested in driving adoption, but it simply looks like we will = not have a full enough schedule to justify using IETF meeting time=E2=80=A6= . We will try and spend some time (finally) getting the new charter = organized, and also discuss deployment, etc=E2=80=A6 Just to be clear -- DANE WILL NOT BE MEETING IN DALLAS=E2=80=A6. W > W >=20 >=20 >> O. >>=20 >> On 23. 9. 2012, at 12:28, Ond=C5=99ej Sur=C3=BD = wrote: >>=20 >>> Dear WG, >>>=20 >>> we did register a slot for IETF 85 (just in case), but from the = volume of the mailing list and just one WG draft (we have just adopted), = we are quite unsure if there's enough interest in meeting. >>>=20 >>> I am personally inclined of canceling this meeting and reschedule = for next year. >>>=20 >>> Any comments (if saying yes, please also say why and attach an = agenda item suggestion :))? >>>=20 >>> 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 >>> ------------------------------------------- >>>=20 >>> _______________________________________________ >>> dane mailing list >>> dane@ietf.org >>> https://www.ietf.org/mailman/listinfo/dane >>=20 >> -- >> 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 >> ------------------------------------------- >>=20 >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >=20 From ietf@augustcellars.com Wed Oct 3 11:31:14 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4BC921F85B8 for ; Wed, 3 Oct 2012 11:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.847 X-Spam-Level: X-Spam-Status: No, score=-2.847 tagged_above=-999 required=5 tests=[AWL=-0.148, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjn3xQcTpKZ6 for ; Wed, 3 Oct 2012 11:31:13 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 3260D21F8566 for ; Wed, 3 Oct 2012 11:31:13 -0700 (PDT) Received: from Tobias (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id EBF8A38F1C; Wed, 3 Oct 2012 11:31:12 -0700 (PDT) From: "Jim Schaad" To: "'Warren Kumari'" , =?UTF-8?Q?'Ondrej_Sur=C3=BD'?= , "'Stephen Farrell'" References: In-Reply-To: Date: Wed, 3 Oct 2012 11:29:47 -0700 Message-ID: <00cd01cda195$11b1dac0$35159040$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIEYFY/VCUy0gVjvT3yNECkGOm9TgGoEocpAaVfyiUBhk9HgZcTy1AQ Content-Language: en-us Cc: 'dane WG list' Subject: Re: [dane] IETF 85 - meet or not to meet? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Oct 2012 18:31:14 -0000 > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf = Of > Warren Kumari > Sent: Wednesday, October 03, 2012 11:06 AM > To: Ondrej Sur=C3=BD; Stephen Farrell > Cc: dane WG list > Subject: Re: [dane] IETF 85 - meet or not to meet? >=20 >=20 > On Sep 30, 2012, at 5:00 AM, Warren Kumari wrote: >=20 > > > > On Sep 24, 2012, at 3:10 PM, Ondrej Sur=EF=BF=BD = wrote: > > > >> More specifically, we are going to cancel the session after Oct 4th = unless > we hear from you that you want to meet and we have an agenda. > >> > > > > Apologies all -- due to the contention for meeting slots and the = difficulty of > scheduling all these slots we are moving the cutoff to the 2nd. > > >=20 > And sadly enough it looks like we should cancel this slot. >=20 > I am very grateful to folk, Dan especially for wanting to meet, and = for being > interested in driving adoption, but it simply looks like we will not = have a full > enough schedule to justify using IETF meeting time=EF=BF=BD. >=20 > We will try and spend some time (finally) getting the new charter = organized, > and also discuss deployment, etc=EF=BF=BD >=20 > Just to be clear -- DANE WILL NOT BE MEETING IN DALLAS=EF=BF=BD. That is good, the IETF is meeting in Atlanta Jim >=20 > W >=20 >=20 > > W > > > > > >> O. > >> > >> On 23. 9. 2012, at 12:28, Ondrej Sur=EF=BF=BD = wrote: > >> > >>> Dear WG, > >>> > >>> we did register a slot for IETF 85 (just in case), but from the = volume of > the mailing list and just one WG draft (we have just adopted), we are = quite > unsure if there's enough interest in meeting. > >>> > >>> I am personally inclined of canceling this meeting and reschedule = for > next year. > >>> > >>> Any comments (if saying yes, please also say why and attach an = agenda > item suggestion :))? > >>> > >>> O. > >>> -- > >>> Ondrej Sur=EF=BF=BD -- Chief Science Officer > >>> ------------------------------------------- > >>> CZ.NIC, z.s.p.o. -- Laboratore CZ.NIC > >>> Americka 23, 120 00 Praha 2, Czech Republic > >>> mailto:ondrej.sury@nic.cz http://nic.cz/ > >>> tel:+420.222745110 fax:+420.222745112 > >>> ------------------------------------------- > >>> > >>> _______________________________________________ > >>> dane mailing list > >>> dane@ietf.org > >>> https://www.ietf.org/mailman/listinfo/dane > >> > >> -- > >> Ondrej Sur=EF=BF=BD -- Chief Science Officer > >> ------------------------------------------- > >> CZ.NIC, z.s.p.o. -- Laboratore CZ.NIC > >> Americka 23, 120 00 Praha 2, Czech Republic > >> mailto:ondrej.sury@nic.cz http://nic.cz/ > >> tel:+420.222745110 fax:+420.222745112 > >> ------------------------------------------- > >> > >> _______________________________________________ > >> dane mailing list > >> dane@ietf.org > >> https://www.ietf.org/mailman/listinfo/dane > > >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From warren@kumari.net Wed Oct 3 12:07:59 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16AF71F040A for ; Wed, 3 Oct 2012 12:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.103 X-Spam-Level: X-Spam-Status: No, score=-101.103 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2YAb0OF6V+L7 for ; Wed, 3 Oct 2012 12:07:58 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47A9121F8516 for ; Wed, 3 Oct 2012 12:07:58 -0700 (PDT) Received: from [192.168.1.140] (unknown [66.84.81.102]) by vimes.kumari.net (Postfix) with ESMTPSA id 7C0391B4068C; Wed, 3 Oct 2012 15:07:57 -0400 (EDT) References: <00cd01cda195$11b1dac0$35159040$@augustcellars.com> In-Reply-To: <00cd01cda195$11b1dac0$35159040$@augustcellars.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: X-Mailer: iPhone Mail (10A405) From: Warren Kumari Date: Wed, 3 Oct 2012 15:07:56 -0400 To: Jim Schaad Cc: dane WG list Subject: Re: [dane] IETF 85 - meet or not to meet? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Oct 2012 19:07:59 -0000 Sorry, too many trips...=20 Dallas was NANOG -- I meant Atlanta :-) W Warren Kumari ------ Please excuse typing, etc -- This was sent from a device with a tiny keyboar= d. On Oct 3, 2012, at 2:29 PM, "Jim Schaad" wrote: >=20 >=20 >> -----Original Message----- >> From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of >> Warren Kumari >> Sent: Wednesday, October 03, 2012 11:06 AM >> To: Ondrej Sur=C3=BD; Stephen Farrell >> Cc: dane WG list >> Subject: Re: [dane] IETF 85 - meet or not to meet? >>=20 >>=20 >> On Sep 30, 2012, at 5:00 AM, Warren Kumari wrote: >>=20 >>>=20 >>> On Sep 24, 2012, at 3:10 PM, Ondrej Sur=EF=BF=BD wr= ote: >>>=20 >>>> More specifically, we are going to cancel the session after Oct 4th unl= ess >> we hear from you that you want to meet and we have an agenda. >>>=20 >>> Apologies all -- due to the contention for meeting slots and the difficu= lty of >> scheduling all these slots we are moving the cutoff to the 2nd. >>=20 >> And sadly enough it looks like we should cancel this slot. >>=20 >> I am very grateful to folk, Dan especially for wanting to meet, and for b= eing >> interested in driving adoption, but it simply looks like we will not have= a full >> enough schedule to justify using IETF meeting time=EF=BF=BD. >>=20 >> We will try and spend some time (finally) getting the new charter organiz= ed, >> and also discuss deployment, etc=EF=BF=BD >>=20 >> Just to be clear -- DANE WILL NOT BE MEETING IN DALLAS=EF=BF=BD. >=20 > That is good, the IETF is meeting in Atlanta >=20 > Jim >=20 >>=20 >> W >>=20 >>=20 >>> W >>>=20 >>>=20 >>>> O. >>>>=20 >>>> On 23. 9. 2012, at 12:28, Ondrej Sur=EF=BF=BD wrot= e: >>>>=20 >>>>> Dear WG, >>>>>=20 >>>>> we did register a slot for IETF 85 (just in case), but from the volume= of >> the mailing list and just one WG draft (we have just adopted), we are qui= te >> unsure if there's enough interest in meeting. >>>>>=20 >>>>> I am personally inclined of canceling this meeting and reschedule for >> next year. >>>>>=20 >>>>> Any comments (if saying yes, please also say why and attach an agenda >> item suggestion :))? >>>>>=20 >>>>> O. >>>>> -- >>>>> Ondrej Sur=EF=BF=BD -- Chief Science Officer >>>>> ------------------------------------------- >>>>> CZ.NIC, z.s.p.o. -- Laboratore CZ.NIC >>>>> Americka 23, 120 00 Praha 2, Czech Republic >>>>> mailto:ondrej.sury@nic.cz http://nic.cz/ >>>>> tel:+420.222745110 fax:+420.222745112 >>>>> ------------------------------------------- >>>>>=20 >>>>> _______________________________________________ >>>>> dane mailing list >>>>> dane@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dane >>>>=20 >>>> -- >>>> Ondrej Sur=EF=BF=BD -- Chief Science Officer >>>> ------------------------------------------- >>>> CZ.NIC, z.s.p.o. -- Laboratore CZ.NIC >>>> Americka 23, 120 00 Praha 2, Czech Republic >>>> mailto:ondrej.sury@nic.cz http://nic.cz/ >>>> tel:+420.222745110 fax:+420.222745112 >>>> ------------------------------------------- >>>>=20 >>>> _______________________________________________ >>>> dane mailing list >>>> dane@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dane >>=20 >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >=20 From cloos@jhcloos.com Wed Oct 3 13:17:07 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6074C21F8559 for ; Wed, 3 Oct 2012 13:17: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PoHOUliwVhTC for ; Wed, 3 Oct 2012 13:17:06 -0700 (PDT) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by ietfa.amsl.com (Postfix) with ESMTP id C727621F854F for ; Wed, 3 Oct 2012 13:17:06 -0700 (PDT) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 2BD44401E8; Wed, 3 Oct 2012 20:16:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1349295425; bh=wTTucaLN6H3i1m/HV7EbokiBRe+NTVtRqTpOAWC+HxU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=j1iNU1MUKR7hLrNTcEX1noSaEF6MSiTCcn8EuMz6AjVkYq0lniAJ8Nr1zialp8tG9 2HRnXYrTXyGsOCIu8gufPSsTTre7KrIAe8/fRk3KPuDBYyLOIJnDp02maYyJTpKZni 3J4Y9des+yJ8dBdvTdgsNBwmUdhVdQdOJZh+6Z+4= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 59A244004A; Wed, 3 Oct 2012 20:10:02 +0000 (UTC) From: James Cloos To: Nikos Mavrogiannopoulos In-Reply-To: (Nikos Mavrogiannopoulos's message of "Wed, 3 Oct 2012 11:11:08 +0200") References: User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2012 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Wed, 03 Oct 2012 16:10:02 -0400 Message-ID: Lines: 11 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:121003:n.mavrogiannopoulos@gmail.com::B1SUQRKAzsnWORIa:0000000000000000000000000000000xd6Ig X-Hashcash: 1:30:121003:dane@ietf.org::wcZ16oerlbg80VWP:000UqqEV Cc: dane@ietf.org Subject: Re: [dane] DANE test sites X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Oct 2012 20:17:07 -0000 >>>>> "NM" == Nikos Mavrogiannopoulos writes: NM> Are there any test or even real world https sites that support DANE? https://jhcloos.com/ (also supports spdy). Outside of http, my MXs have TLSA RRs, too. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From warren@kumari.net Wed Oct 3 15:22:45 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDBF211E809B for ; Wed, 3 Oct 2012 15:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[AWL=0.623, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ylYWlFIl-eU for ; Wed, 3 Oct 2012 15:22:45 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7A511E8091 for ; Wed, 3 Oct 2012 15:22:44 -0700 (PDT) Received: from [192.168.1.139] (unknown [66.84.81.102]) by vimes.kumari.net (Postfix) with ESMTPSA id D1A001B4068C; Wed, 3 Oct 2012 18:22:43 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Warren Kumari In-Reply-To: Date: Wed, 3 Oct 2012 18:22:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <77A5BEE4-9BFD-4C99-8CBE-0CC637E8C05F@kumari.net> References: To: James Cloos X-Mailer: Apple Mail (2.1498) Cc: dane@ietf.org Subject: Re: [dane] DANE test sites X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Oct 2012 22:22:46 -0000 On Oct 3, 2012, at 4:10 PM, James Cloos wrote: >>>>>> "NM" =3D=3D Nikos Mavrogiannopoulos = writes: >=20 > NM> Are there any test or even real world https sites that support = DANE? >=20 > https://jhcloos.com/ (also supports spdy). www.kumari.net=85 Unfortunately the CN is *.kumari.net, and swede verify complains that = that: WARNING: Name on the certificate (Subject: = /serialNumber=3D20Vw66yC802bGJ8IiSaq/ICmQRp2wah0/C=3DUS/O=3D*.kumari.net/O= U=3DGT03082892/OU=3DSee www.rapidssl.com/resources/cps (c)11/OU=3DDomain = Control Validated - RapidSSL(R)/CN=3D*.kumari.net, SubjectAltName: = DNS:*.kumari.net, DNS:kumari.net) doesn't match requested hostname = (www.kumari.net). I started writing a patch for swede to deal with wildcards, but then = got sidetracked :-P W >=20 > Outside of http, my MXs have TLSA RRs, too. >=20 > -JimC > --=20 > James Cloos OpenPGP: 1024D/ED7DAEA6 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 From rbarnes@bbn.com Wed Oct 3 15:52:57 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C21321F856C for ; Wed, 3 Oct 2012 15:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.552 X-Spam-Level: X-Spam-Status: No, score=-106.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mlWKDNzM-Jh9 for ; Wed, 3 Oct 2012 15:52:56 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id B87EC21F8568 for ; Wed, 3 Oct 2012 15:52:56 -0700 (PDT) Received: from [128.89.253.48] (port=60961) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TJXoA-000Gv6-Hl; Wed, 03 Oct 2012 18:52:50 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Richard Barnes In-Reply-To: <77A5BEE4-9BFD-4C99-8CBE-0CC637E8C05F@kumari.net> Date: Wed, 3 Oct 2012 18:52:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <47128C87-2E1A-4E3C-9A19-54562AB3AD41@bbn.com> References: <77A5BEE4-9BFD-4C99-8CBE-0CC637E8C05F@kumari.net> To: Warren Kumari X-Mailer: Apple Mail (2.1283) Cc: dane@ietf.org Subject: Re: [dane] DANE test sites X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Oct 2012 22:52:57 -0000 On Oct 3, 2012, at 6:22 PM, Warren Kumari wrote: >=20 > On Oct 3, 2012, at 4:10 PM, James Cloos wrote: >=20 >>>>>>> "NM" =3D=3D Nikos Mavrogiannopoulos = writes: >>=20 >> NM> Are there any test or even real world https sites that support = DANE? >>=20 >> https://jhcloos.com/ (also supports spdy). >=20 > www.kumari.net=85 >=20 > Unfortunately the CN is *.kumari.net, and swede verify complains that = that: > WARNING: Name on the certificate (Subject: = /serialNumber=3D20Vw66yC802bGJ8IiSaq/ICmQRp2wah0/C=3DUS/O=3D*.kumari.net/O= U=3DGT03082892/OU=3DSee www.rapidssl.com/resources/cps (c)11/OU=3DDomain = Control Validated - RapidSSL(R)/CN=3D*.kumari.net, SubjectAltName: = DNS:*.kumari.net, DNS:kumari.net) doesn't match requested hostname = (www.kumari.net). >=20 >=20 > I started writing a patch for swede to deal with wildcards, but then = got sidetracked :-P >=20 > W Seems to me like the patch should just comment out the whole part that = checks the CN, since that's an application-layer issue, not a DANE = issue. Doesn't seem *that* harmful to throw a warning, though.= From sandoche.balakrichenan@afnic.fr Thu Oct 4 02:38:57 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF32321F8686 for ; Thu, 4 Oct 2012 02:38:57 -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_FR=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MqtJevplc3HM for ; Thu, 4 Oct 2012 02:38:56 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [192.134.4.12]) by ietfa.amsl.com (Postfix) with ESMTP id B8FA021F867B for ; Thu, 4 Oct 2012 02:38:56 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id A3B3628050B; Thu, 4 Oct 2012 11:38:25 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id 9EE7A2801C1; Thu, 4 Oct 2012 11:38:25 +0200 (CEST) Received: from sandoche-world (tirodite.tech.prive.sqy.nic.fr [10.10.86.63]) by relay2.nic.fr (Postfix) with ESMTP id 9D42AB38066; Thu, 4 Oct 2012 11:37:55 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by sandoche-world (Postfix) with ESMTP id 8CF18A415F4; Thu, 4 Oct 2012 11:37:55 +0200 (CEST) Message-ID: <506D58F3.8000908@afnic.fr> Date: Thu, 04 Oct 2012 11:37:55 +0200 From: sandoche BALAKRICHENAN User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: SM References: <20121003092722.GA8041@sources.org> <6.2.5.6.2.20121003072919.0b377858@resistor.net> In-Reply-To: <6.2.5.6.2.20121003072919.0b377858@resistor.net> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dane@ietf.org Subject: Re: [dane] DANE test sites X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Oct 2012 09:38:57 -0000 Thanks for pointing out. Now it has been corrected. Sandoche. On 10/03/2012 04:32 PM, SM wrote: > Hi Stephane, > At 02:27 03-10-2012, Stephane Bortzmeyer wrote: >> A test one is https://dane.rd.nic.fr/ > > The certificate is only valid for www.dane.rd.nic.fr. See DNS reply > below: > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57147 > ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2 > ;; WARNING: recursion requested but not available > > ;; QUESTION SECTION: > ;www.dane.rd.nic.fr. IN A > > ;; AUTHORITY SECTION: > dane.rd.nic.fr. 3600 IN NS dane.rd.nic.fr. > dane.rd.nic.fr. 3600 IN NS ns3.nic.fr. > > Regards, > -sm > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From dan-ietf@danyork.org Thu Oct 4 05:38:40 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E6E621F862B for ; Thu, 4 Oct 2012 05:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.616 X-Spam-Level: X-Spam-Status: No, score=-2.616 tagged_above=-999 required=5 tests=[AWL=0.382, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ey41g9RL7DKc for ; Thu, 4 Oct 2012 05:38:39 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 09FC221F854C for ; Thu, 4 Oct 2012 05:38:38 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id c10so391299qca.31 for ; Thu, 04 Oct 2012 05:38:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=C0V4z2mjLJV71prI+hEQSplPXBTue6YHWSqGkaeTEuY=; b=FuUXaMp6wJbw5BmhTls312zxVdXI8DGmUOhQgUkEC7yrqJK1B+6Lq71rAc/0AG78NP OjRLolGEL1EaKolLfpB9dOjwnAxYxL44sgXc1KQurQVtO/mtBcPE4a6oR3VITkaEs5lU bHYhHAWzgDdHqAbiouZHnGhW9gOly6KWbHaxLr27TxezBc9V3xjO4VlWiDSMLfOEkynx csj4DlEpaiCcFKeabyrPLKRnW9TSSeWmkMW1yTqGjd+0ESOtKV6joDtGq3YvD/tHcuKk FB5gTeg+QQjO1TA8hrFWEQw9DntrwaH5CQEuQ+81aYafyIv8Ncs5PkWzlhYUSD+QW+vN kQzQ== Received: by 10.224.180.132 with SMTP id bu4mr11963869qab.62.1349354318231; Thu, 04 Oct 2012 05:38:38 -0700 (PDT) Received: from [172.20.12.152] (cpe-74-75-92-114.maine.res.rr.com. [74.75.92.114]) by mx.google.com with ESMTPS id gz7sm7125905qab.8.2012.10.04.05.38.37 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Oct 2012 05:38:37 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_135F85D7-E246-4786-BB4F-C99CB49797C6" From: Dan York In-Reply-To: <9AC8675C-22B6-4502-9E00-FB51B9D36F34@kumari.net> Date: Thu, 4 Oct 2012 08:38:35 -0400 Message-Id: <5428271E-CB00-4C5B-A9B6-922039C830B1@danyork.org> References: <15ED757A-9B2F-45CD-A1B6-0A0C8DFC2397@danyork.org> <76960946-F768-422B-A76A-17D951D29C8C@vpnc.org> <2931E1FC-20D3-4045-9146-368D3AC9D989@vpnc.org> <9AC8675C-22B6-4502-9E00-FB51B9D36F34@kumari.net> To: Warren Kumari X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQneM4bNgZbcw0VH8z5GK2XcuWQLoIZ2GQkqR+lgOsayC/cyNO8ddnmLXO+9U9ILA3A3ZvAF Cc: Paul Hoffman , dane WG list Subject: Re: [dane] Deployment focus? Re: IETF 85 - meet or not to meet? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Oct 2012 12:38:40 -0000 --Apple-Mail=_135F85D7-E246-4786-BB4F-C99CB49797C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 2, 2012, at 5:27 PM, Warren Kumari wrote: > More seriously though, this is yet another chicken-and-egg problem=85 Agreed. > In this particular case I think that the easiest / fastest way to get = better deployment is to convince the browser manufactures to include = support for DANE -- this will incentivize[0] folk to deploy records=85 Indeed, but as you yourself noted in an earlier thread: >> Something that would be very helpful for getting this deployed / = implemented in browsers is number of folk (and more importantly, = organizations) stating that they are planning on / would do DANE if the = browsers supported it natively. Of course, even more helpful would be = folk actually publishing TLSA records :-P >>=20 >> The browser vendors all have limited cycles, and many many things to = implement -- showing that this is something that users (and not just = security weenie users) want and plan to use helps to prioritize = developer time.=20 So the best way to get the attention of the browser manufacturers is to = get *other* people talking about DANE and requesting DANE from the = browser manufacturers. Which speaks to the need for a broader outreach = to people who might be consumers/users of the DANE protocol. > [0]: Whoohoo, "incentivize" ! Ah, the joys of the English language "evolving"... :-) Dan --=20 Dan York dyork@lodestar2.com http://www.danyork.me/ skype:danyork Phone: +1-802-735-1624 Twitter - http://twitter.com/danyork --Apple-Mail=_135F85D7-E246-4786-BB4F-C99CB49797C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
More seriously though, this is yet another = chicken-and-egg = problem=85

Agreed.

In this particular case I think that the = easiest / fastest way to get better deployment is to convince the = browser manufactures to include support for DANE -- this will = incentivize[0] folk to deploy = records=85

Indeed, but as you = yourself noted in an earlier = thread:

Something that would be = very helpful for getting this deployed / implemented in browsers is = number of folk (and more importantly, organizations) stating that they = are planning on / would do DANE if the browsers supported it natively. = Of course, even more helpful would be folk actually publishing TLSA = records :-P

The browser vendors all have = limited cycles, and many many things to implement -- showing that this = is something that users (and not just security weenie users) want and = plan to use helps to prioritize developer = time. 

So the = best way to get the attention of the browser manufacturers is to get = *other* people talking about DANE and requesting DANE from the browser = manufacturers.  Which speaks to the need for a broader outreach to = people who might be consumers/users of the DANE = protocol.

[0]: Whoohoo, = "incentivize" !

Ah, the joys of the = English language "evolving"... = :-)

Dan

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

= --Apple-Mail=_135F85D7-E246-4786-BB4F-C99CB49797C6-- From dan-ietf@danyork.org Thu Oct 4 06:34:37 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10D6D21F86D3 for ; Thu, 4 Oct 2012 06:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.136 X-Spam-Level: X-Spam-Status: No, score=-2.136 tagged_above=-999 required=5 tests=[AWL=0.862, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDEHXndNmWNp for ; Thu, 4 Oct 2012 06:34:36 -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 9A1BE21F86B3 for ; Thu, 4 Oct 2012 06:34:35 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so631832vbb.31 for ; Thu, 04 Oct 2012 06:34:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=EXgeGypdugpDpMQut5m2Hy4dLDBbvjougaUFZh7Hdjk=; b=aBjIi4KE2rNexTglPWShM8RDMcEbxIYUFDNH3yoKt3IX1n119MV/2SNcDkcDD+RF+T QyKEyxvRvS1clbdU2Ve/Al+t+h48EdhiCjFRNlGRflziUxVWbyI+NnrrzEkICH41iu6r Ie4JYErAAR0gWUAqdIq354feyEJS32mPUN3qtihmVQHEWkupPMF30vgIOLLkxGBBizAt Pheijx9pD9kmvfjosG+oFNqrApS5vvxYPrpNSOhm5OfTKmk8zsksIvkVR4ZRzutzT7Se vdmbUkk9RZVkone/IMBHhVoFtdncok/im4SF45zkoPJQyuClfY+axlorgVUmTGPwMW01 gZBw== Received: by 10.52.29.141 with SMTP id k13mr1816046vdh.131.1349357674966; Thu, 04 Oct 2012 06:34:34 -0700 (PDT) Received: from ?IPv6:2001:470:1f07:309:315a:28a2:82d5:9c19? ([2001:470:1f07:309:315a:28a2:82d5:9c19]) by mx.google.com with ESMTPS id y15sm830082vdg.22.2012.10.04.06.34.33 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Oct 2012 06:34:33 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_C80A8520-BEF5-4227-A245-28F4E331EE06" From: Dan York In-Reply-To: Date: Thu, 4 Oct 2012 09:34:31 -0400 Message-Id: <15DD6FE2-04F1-46D1-8A9A-D3C6B930D327@danyork.org> References: To: Nikos Mavrogiannopoulos X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQkA0e4PCOTT1/vJnhHYqUI2BgG2raT4yQg+/tJ4cBY4ghNqLpBG0hVJfvSP2XNCjEQkVv80 Cc: dane@ietf.org Subject: [dane] Capturing the list of sites - Re: DANE test sites X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Oct 2012 13:34:37 -0000 --Apple-Mail=_C80A8520-BEF5-4227-A245-28F4E331EE06 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 3, 2012, at 5:11 AM, Nikos Mavrogiannopoulos wrote: > Are there any test or even real world https sites that support DANE? So that this excellent list of test sites can be easily found for = others, I've added a page to our Deploy360 site listing out all the = sites mentioned so far: http://www.internetsociety.org/deploy360/resources/dane-test-sites/ If you have other sites publishing TLSA records right now that you would = like me to list, please contact me and I'll be glad to add it. In = particular it would be interesting to list other invalid/broken sites = that people could use for testing. It also strikes me that it might be interesting to break the list of = test sites out into: - HTTP - Valid TLSA Record with Valid CA-Certified TLS Certificate - HTTP - Valid TLSA Record with Valid Self-Signed TLS Certificate I'm also wondering about this case: - HTTP - Valid TLSA Record with Invalid CA-Certified TLS Certificate = (ex. Paul's site where the CA-cert hasn't been renewed) Which of course also brings up: - HTTP - Valid TLSA Record with Invalid Self-Signed TLS Certificate=20 It seems to be that it would be useful if test sites were out there for = all those cases. Are there other test cases for which sites would be = useful? Also, if anyone has test sites using protocols other than HTTP I would = be glad to add those, too. Regards, Dan --=20 Dan York dyork@lodestar2.com http://www.danyork.me/ skype:danyork Phone: +1-802-735-1624 Twitter - http://twitter.com/danyork --Apple-Mail=_C80A8520-BEF5-4227-A245-28F4E331EE06 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Are there any test or even real world https sites = that support DANE?

So that this = excellent list of test sites can be easily found for others, I've added = a page to our Deploy360 site listing out all the sites mentioned so = far:

http://www.internetsociety.org/deploy360/resources/dane-test-sites/=

If you have other sites publishing TLSA records = right now that you would like me to list, please contact me and I'll be = glad to add it.    In particular it would be interesting to = list other invalid/broken sites that people could use for = testing.

It also strikes me that it might be = interesting to break the list of test sites out = into:

  - HTTP - Valid TLSA Record with = Valid CA-Certified TLS Certificate
  - HTTP - Valid TLSA = Record with Valid Self-Signed TLS = Certificate

I'm also wondering about this = case:

  - HTTP - Valid TLSA Record with = Invalid CA-Certified TLS Certificate (ex. Paul's site where the CA-cert = hasn't been renewed)

Which of course also = brings up:

  - HTTP - Valid TLSA Record = with Invalid Self-Signed TLS = Certificate 

It seems to be that it would = be useful if test sites were out there for all those cases.  Are = there other test cases for which sites would be = useful?

Also, if anyone has test sites using = protocols other than HTTP I would be glad to add those, = too.

Regards,
Dan

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

= --Apple-Mail=_C80A8520-BEF5-4227-A245-28F4E331EE06-- From fanf2@hermes.cam.ac.uk Thu Oct 4 08:06:41 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5E421F8233 for ; Thu, 4 Oct 2012 08:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.101 X-Spam-Level: X-Spam-Status: No, score=-6.101 tagged_above=-999 required=5 tests=[AWL=0.498, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kwr0XAAHynGS for ; Thu, 4 Oct 2012 08:06:37 -0700 (PDT) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by ietfa.amsl.com (Postfix) with ESMTP id EABAC21F859C for ; Thu, 4 Oct 2012 08:06:36 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:56487) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1TJn0T-0007bS-RN (Exim 4.72) (return-path ); Thu, 04 Oct 2012 16:06:33 +0100 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1TJn0T-0008Ok-F6 (Exim 4.72) (return-path ); Thu, 04 Oct 2012 16:06:33 +0100 Date: Thu, 4 Oct 2012 16:06:33 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: James Cloos In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dane@ietf.org Subject: Re: [dane] DANE test sites X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Oct 2012 15:06:41 -0000 James Cloos wrote: > > Outside of http, my MXs have TLSA RRs, too. Nice :-) Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From dan-ietf@danyork.org Thu Oct 4 08:57:35 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85D1121F86F0 for ; Thu, 4 Oct 2012 08:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.231 X-Spam-Level: X-Spam-Status: No, score=-2.231 tagged_above=-999 required=5 tests=[AWL=0.767, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7EMjl8pAfi3 for ; Thu, 4 Oct 2012 08:57:27 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id B480621F8688 for ; Thu, 4 Oct 2012 08:57:27 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id c10so607001qca.31 for ; Thu, 04 Oct 2012 08:57:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:mime-version:content-type:subject:date:in-reply-to:to :references:message-id:x-mailer:x-gm-message-state; bh=pMGixDz80M5iuhisMVjUMso3o2l9g1s/xoM31d7NTmA=; b=pChjJXpJCKvMESol44bDrDSFk/T10As5jfkdv5yWy0dmIAzhVg0ud6+G8NdFCGbjNh g0n7jh/V+zB7Us5YQ/0zQShdt35Y1pHIX3RGjG+pPinEXUpCzS6Roj4F1vZCyphfe2xF Q2Sl8PfBrjkkqnmTYCvtz15kg1l00nKsyV6x9iNWK/3ir35fa1HFgQttcRRJXdVBnnSg 3Vn7Pn15AFUSvgD1k5EESraQBMhhmPrsj6adw/IiKea+09aCR9SWATmY9UpVJdVlGkB1 8L5vRuFKmyYLBdowquxTTg3UT/6sFIDWPtjM2wovarjUjuJSSCC1ubBQhbrtjsaHbWhc kK/Q== Received: by 10.224.198.131 with SMTP id eo3mr13093587qab.78.1349366247135; Thu, 04 Oct 2012 08:57:27 -0700 (PDT) Received: from ?IPv6:2001:470:1f07:309:315a:28a2:82d5:9c19? ([2001:470:1f07:309:315a:28a2:82d5:9c19]) by mx.google.com with ESMTPS id ck11sm7493993qab.17.2012.10.04.08.57.25 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Oct 2012 08:57:26 -0700 (PDT) From: Dan York Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_92577D2B-2682-4F8E-B591-8702BB6136CE" Date: Thu, 4 Oct 2012 11:57:21 -0400 In-Reply-To: <15DD6FE2-04F1-46D1-8A9A-D3C6B930D327@danyork.org> To: dane WG list References: <15DD6FE2-04F1-46D1-8A9A-D3C6B930D327@danyork.org> Message-Id: X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQlM9gMOqEZ1gJaOfUyAGTP9ObQK5s+JkkFvq2YCGGOJY0IiLo3bdxipCuauNxG7Wujonmja Subject: [dane] Updated and categorized - Re: Capturing the list of sites - Re: DANE test sites X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Oct 2012 15:57:35 -0000 --Apple-Mail=_92577D2B-2682-4F8E-B591-8702BB6136CE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii FYI, I've now updated this page of DANE test sites to add a couple of = more that were sent to me and to break it out according to the different = types of sites: http://www.internetsociety.org/deploy360/resources/dane-test-sites/ I put the sites in different categories based on what I could see using = my browser. Please feel free to let me know if you don't think I = categorized your site correctly. I'm also glad to keep adding more = sites, too, if you let me know about them. Regards, Dan P.S. And yes, I'll work on getting the Deploy360 site (well, the larger = ISOC site of which Deploy360 is a part) to have a TLSA record, too. = This was part of why I was asking about tutorials to help people = understand how to publish TLSA records. I don't control the DNS or the = web server for the site, and so I need a simple step-by-step process I = can forward to the IT team responsible for the site. On Oct 4, 2012, at 9:34 AM, Dan York wrote: >=20 > On Oct 3, 2012, at 5:11 AM, Nikos Mavrogiannopoulos wrote: >=20 >> Are there any test or even real world https sites that support DANE? >=20 > So that this excellent list of test sites can be easily found for = others, I've added a page to our Deploy360 site listing out all the = sites mentioned so far: >=20 > http://www.internetsociety.org/deploy360/resources/dane-test-sites/ >=20 > If you have other sites publishing TLSA records right now that you = would like me to list, please contact me and I'll be glad to add it. = In particular it would be interesting to list other invalid/broken sites = that people could use for testing. >=20 > It also strikes me that it might be interesting to break the list of = test sites out into: >=20 > - HTTP - Valid TLSA Record with Valid CA-Certified TLS Certificate > - HTTP - Valid TLSA Record with Valid Self-Signed TLS Certificate >=20 > I'm also wondering about this case: >=20 > - HTTP - Valid TLSA Record with Invalid CA-Certified TLS Certificate = (ex. Paul's site where the CA-cert hasn't been renewed) >=20 > Which of course also brings up: >=20 > - HTTP - Valid TLSA Record with Invalid Self-Signed TLS Certificate=20= >=20 > It seems to be that it would be useful if test sites were out there = for all those cases. Are there other test cases for which sites would = be useful? >=20 > Also, if anyone has test sites using protocols other than HTTP I would = be glad to add those, too. >=20 > Regards, > Dan >=20 > --=20 > Dan York dyork@lodestar2.com > http://www.danyork.me/ skype:danyork > Phone: +1-802-735-1624 > Twitter - http://twitter.com/danyork >=20 >=20 >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane --=20 Dan York dyork@lodestar2.com http://www.danyork.me/ skype:danyork Phone: +1-802-735-1624 Twitter - http://twitter.com/danyork --Apple-Mail=_92577D2B-2682-4F8E-B591-8702BB6136CE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii FYI, = I've now updated this page of DANE test sites to add a couple of more = that were sent to me and to break it out according to the different = types of sites:


I put the sites in different categories based on = what I could see using my browser.  Please feel free to let me know = if you don't think I categorized your site correctly.  I'm also = glad to keep adding more sites, too, if you let me know about = them.

Regards,
Dan

=
P.S. And yes, I'll work on getting the Deploy360 site (well, the = larger ISOC site of which Deploy360 is a part) to have a TLSA record, = too.  This was part of why I was asking about tutorials to help = people understand how to publish TLSA records.  I don't control the = DNS or the web server for the site, and so I need a simple step-by-step = process I can forward to the IT team responsible for the = site.

On Oct 4, 2012, at 9:34 AM, Dan York = wrote:


On Oct 3, = 2012, at 5:11 AM, Nikos Mavrogiannopoulos wrote:

Are = there any test or even real world https sites that support = DANE?

So that this excellent list = of test sites can be easily found for others, I've added a page to our = Deploy360 site listing out all the sites mentioned so = far:

http://www.internetsociety.org/deploy360/resources/dane-test-sites/=

If you have other sites publishing TLSA records = right now that you would like me to list, please contact me and I'll be = glad to add it.    In particular it would be interesting to = list other invalid/broken sites that people could use for = testing.

It also strikes me that it might be = interesting to break the list of test sites out = into:

  - HTTP - Valid TLSA Record with = Valid CA-Certified TLS Certificate
  - HTTP - Valid TLSA = Record with Valid Self-Signed TLS = Certificate

I'm also wondering about this = case:

  - HTTP - Valid TLSA Record with = Invalid CA-Certified TLS Certificate (ex. Paul's site where the CA-cert = hasn't been renewed)

Which of course also = brings up:

  - HTTP - Valid TLSA Record = with Invalid Self-Signed TLS = Certificate 

It seems to be that it would = be useful if test sites were out there for all those cases.  Are = there other test cases for which sites would be = useful?

Also, if anyone has test sites using = protocols other than HTTP I would be glad to add those, = too.

Regards,
Dan

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

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

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

= --Apple-Mail=_92577D2B-2682-4F8E-B591-8702BB6136CE-- From warren@kumari.net Thu Oct 4 09:21:26 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9E21F0C9A for ; Thu, 4 Oct 2012 09:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.501 X-Spam-Level: X-Spam-Status: No, score=-101.501 tagged_above=-999 required=5 tests=[AWL=-0.101, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, J_CHICKENPOX_54=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wC1oRtgPO+0 for ; Thu, 4 Oct 2012 09:21:25 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA76A1F0C94 for ; Thu, 4 Oct 2012 09:21:25 -0700 (PDT) Received: from [192.168.1.139] (unknown [66.84.81.102]) by vimes.kumari.net (Postfix) with ESMTPSA id 08DF21B40740; Thu, 4 Oct 2012 12:21:24 -0400 (EDT) Date: Thu, 4 Oct 2012 12:21:23 -0400 From: Warren Kumari To: Richard Barnes Message-ID: In-Reply-To: <47128C87-2E1A-4E3C-9A19-54562AB3AD41@bbn.com> References: <77A5BEE4-9BFD-4C99-8CBE-0CC637E8C05F@kumari.net> <47128C87-2E1A-4E3C-9A19-54562AB3AD41@bbn.com> X-Mailer: sparrow 1.6.3 (build 1172) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: dane@ietf.org Subject: Re: [dane] DANE test sites X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Oct 2012 16:21:26 -0000 On Wednesday, October 3, 2012 at 6:52 PM, Richard Barnes wrote: =20 > =20 > On Oct 3, 2012, at 6:22 PM, Warren Kumari wrote: > =20 > > =20 > > On Oct 3, 2012, at 4:10 PM, James Cloos wrote: > > =20 > > > > > > > > =22NM=22 =3D=3D Nikos Mavrogiannopoulos writes: > > > =20 > > > NM> Are there any test or even real world https sites that support = DANE=3F > > > =20 > > > https://jhcloos.com/ (also supports spdy). > > =20 > > www.kumari.net (http://www.kumari.net)=E2=80=A6 > > =20 > > Unfortunately the CN is *.kumari.net (http://kumari.net), and swede v= erify complains that that: > > WARNING: Name on the certificate (Subject: /serialNumber=3D20Vw66yC80= 2bGJ8IiSaq/ICmQRp2wah0/C=3DUS/O=3D*.kumari.net/OU=3DGT03082892/OU=3DSee w= ww.rapidssl.com/resources/cps (http://www.rapidssl.com/resources/cps) (c)= 11/OU=3DDomain Control Validated - RapidSSL(R)/CN=3D*.kumari.net, Subject= AltName: DNS:*.kumari.net, DNS:kumari.net) doesn't match requested hostna= me (www.kumari.net (http://www.kumari.net)). > > =20 > > =20 > > I started writing a patch for swede to deal with wildcards, but then = got sidetracked :-P > > =20 > > W > =20 > Seems to me like the patch should just comment out the whole part that = checks the CN, since that's an application-layer issue, not a DANE issue.= Doesn't seem *that* harmful to throw a warning, though. =20 =5B Apologies if this mail is formatted oddly, testing a new MUA =5D =20 Yeah, thats what I did (well, actually I just made it return True if the = specific match doesn't work. I also commented out the AAAA checks. Someti= me I plan to go back and make it cleaner=E2=80=A6 Output: Received the following record for name =5F443.=5Ftcp.www.kumari.net.: Usage: 1 (End-Entity Constraint + chain to CA) Selector: 0 (Certificate) Matching Type: 1 (SHA-256) Certificate for Association: 4209129179ca542ed5df797e84d4de4d4cc8689b8aba= 579fda3f8844ec144dd5 This record is valid (well-formed). Attempting to verify the record with the TLS service... Got the following IP: 198.186.192.250 WARNING: Name on the certificate (Subject: /serialNumber=3D20Vw66yC802bGJ= 8IiSaq/ICmQRp2wah0/C=3DUS/O=3D*.kumari.net/OU=3DGT03082892/OU=3DSee www.r= apidssl.com/resources/cps (c)11/OU=3DDomain Control Validated - RapidSSL(= R)/CN=3D*.kumari.net, SubjectAltName: DNS:*.kumari.net, DNS:kumari.net) d= oesn't match requested hostname (www.kumari.net). SUCCESS (Usage 1): Certificate offered by the server matches the one ment= ioned in the TLSA record and chains to a valid CA certificate The matched certificate has Subject: /serialNumber=3D20Vw66yC802bGJ8IiSaq= /ICmQRp2wah0/C=3DUS/O=3D*.kumari.net/OU=3DGT03082892/OU=3DSee www.rapidss= l.com/resources/cps (c)11/OU=3DDomain Control Validated - RapidSSL(R)/CN=3D= *.kumari.net Patch: --- swede.orig 2012-10-02 17:17:22.358961230 -0400 +++ swede 2012-10-04 12:11:11.300255130 -0400 =40=40 -254,7 +254,9 =40=40 else: if with=5Fmsg: print 'WARNING: Name on the certificate (Subject: %s, SubjectAltName: %s)= doesn=5C't match requested hostname (%s).' % (str(cert.get=5Fsubject()),= altnames=5Fon=5Fcert, hostname) - return =46alse + =23 return =46alse + =23 WK : deal with wildcards. Need to make this less icky... + return True class TLSARecord: =22=22=22When instanciated, this class contains all the fields of a TLSA = record. =40=40 -465,7 +467,8 =40=40 if not args.quiet: print 'Attempting to verify the record with the TLS service...' - addresses =3D getA(args.host, secure=3Dsecure) + getAAAA(args.host, sec= ure=3Dsecure) +=23 addresses =3D getA(args.host, secure=3Dsecure) + getAAAA(args.host, = secure=3Dsecure) + addresses =3D getA(args.host, secure=3Dsecure) for address in addresses: if not args.quiet: print 'Got the following IP: %s' % str(address) =40=40 -601,7 +604,8 =40=40 sys.stdout.write('Port %s not numerical or within correct range (1 <=3D p= ort <=3D 65535), try again (hit enter for default 443): ' % user=5Finput)= =23 Get the address records for the host try: - addresses =3D getA(args.host, secure=3Dsecure) + getAAAA(args.host, sec= ure=3Dsecure) +=23 addresses =3D getA(args.host, secure=3Dsecure) + getAAAA(args.host, = secure=3Dsecure) + addresses =3D getA(args.host, secure=3Dsecure) except InsecureLookupException, e: print >> sys.stderr, str(e) sys.exit(1) From ondrej.mikle@nic.cz Thu Oct 4 12:03:02 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D53A11E80E5 for ; Thu, 4 Oct 2012 12: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwDaaIWDICfj for ; Thu, 4 Oct 2012 12:03:01 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 98A5E11E80E0 for ; Thu, 4 Oct 2012 12:03:01 -0700 (PDT) Received: from [172.30.152.100] (unknown [89.177.113.169]) by mail.nic.cz (Postfix) with ESMTPSA id 99F9F13F993 for ; Thu, 4 Oct 2012 21:03:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1349377380; bh=tRuNT9r5cTV09EgpehnTE/vMEBe4PHb0+8Fvjem0lf4=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type; b=dd3ZWWRLSf2mrgyy2M+WpyLjKG2rt0f6M9WI81rkHtSXlYj1y4Duod9hBwDdXDgIA 8W9sk8q25mr/a5kfiu9/sdfOwuhBADJvU6q7piSRnKxwFdSQagoaXSgjAkRfjQwkK0 nlTOBRMcKt03YWjkSHIBVWooUsZukuAJj2SQ+h5o= Message-ID: <506DDD5E.1020207@nic.cz> Date: Thu, 04 Oct 2012 21:02:54 +0200 From: Ondrej Mikle User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: dane WG list X-Enigmail-Version: 1.4.4 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigD0DE70B4EBD52D1007EFDB1B" X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: [dane] TLSA Firefox addon for testing X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Oct 2012 19:03:02 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD0DE70B4EBD52D1007EFDB1B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, thanks for the testing sites, they were helpful. We started working on an addon for Firefox - it's a Certificate Patrol cl= one that can do TLSA queries and also store multiple certs per site (that las= t part was a bit nuisance with CertPatrol). There are more possible states/cases in the TLSA+CertPatrol combination t= han just TLSA. So if anyone wants to poke holes, it could use a bit testing. For now I've put a git repo snapshot and compiled addon onto a temporary = site, later there'll be a proper repo. The temp site with alpha version (sorry,= for now linux only): https://www.constructibleuniverse.net/DANE-Patrol/ The "override unknown cert page" is not yet implemented (FF has different= hooks for it). Also, it's not a "proper TLSA implementation", because FF API wo= n't allow you to check TLS connection just after TLS handshake and abort it. = The README on the site has more details. Ondrej --------------enigD0DE70B4EBD52D1007EFDB1B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iQEcBAEBCAAGBQJQbd1kAAoJEAy6xNgMZCEgH4wH/3/hJan8ynkjgcJF/iANPmCj 0+NJStgDPf9kZ+mxRGy6NkZxg7K9w7f7AclVoSs8Jp/7vs/mzRD+UNfJ15y0V55B Exf0Rd0URxg+g22mnVpYEWwUteKel2UVegI4yaodLiLU0Gm7A1i98iaWJMJjfOXD oJNOj1SOCDp+nwqR8jXYGiUpcN3V47WDCdKSjf6RDi42q9ZI8deyfglxvhul5yuy zvKuVVZzokKcJrMeAFnIlPND9AdZAqUV8Hfyvk+Z981Ab3+ovpOLab01fssd1DMA rCwOTcVfsBJtMpEsqqXlmNpUOLyjaWU/XD5TDPvSViv9fFo0uA5QlpgWgyqOugE= =R+PX -----END PGP SIGNATURE----- --------------enigD0DE70B4EBD52D1007EFDB1B-- From dan-ietf@danyork.org Fri Oct 5 11:15:45 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC79421F864A for ; Fri, 5 Oct 2012 11:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_20=-0.74, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RIh7uLgg6ho0 for ; Fri, 5 Oct 2012 11:15:45 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id C0CC021F861B for ; Fri, 5 Oct 2012 11:15:44 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id c10so1535292qca.31 for ; Fri, 05 Oct 2012 11:15:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:content-type:subject:date:message-id:to:mime-version:x-mailer :x-gm-message-state; bh=zBzKzfX8itLsYDz1XtSgV83nWcxlyjsFt9uKVZMpnfY=; b=n0ReEg2sKZEZyyvBPUieRvS1NWYbrftY814IST1XGUoMNTsn8Lm6OvKDvSb0TAUm4O gvahKSUIr08BeN5QeCFMPsJUZu0vg+CInR9hY33I923DsiRytRTvBC7Q+Q1cLnhxlRuZ /uE+MEah26Z8LlQ+/qbnKxq7/DoNlmT34VXjMtAu5IPDh3nZPficifAci1yMI402Ho6T 5QjLwFCAdwnqk6tvtRjTXUzNiBpvmnzKtXzuvAl8Zc9iIf8JJgsHQyUbhC0e+tdL7pI7 p3erWZmPw8ulSEPxV2F2R21jeWx8QXbnw8hC8kO3mPPih6QWWubg3VMtKRYs69LCRkhH a3Aw== Received: by 10.224.203.193 with SMTP id fj1mr18522873qab.13.1349460944095; Fri, 05 Oct 2012 11:15:44 -0700 (PDT) Received: from ?IPv6:2001:470:1f07:309:2d09:55f5:43d9:b298? ([2001:470:1f07:309:2d09:55f5:43d9:b298]) by mx.google.com with ESMTPS id a8sm10649210qew.11.2012.10.05.11.15.43 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Oct 2012 11:15:43 -0700 (PDT) From: Dan York Content-Type: multipart/alternative; boundary="Apple-Mail=_42749CA9-E811-4289-ABA8-C90A1F27A4F8" Date: Fri, 5 Oct 2012 14:15:41 -0400 Message-Id: <3CCB7A6B-4A82-471F-81EA-41B1F5534C5C@danyork.org> To: dane WG list Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQmfMZRT+ZFOm3mGeU8taBdbW7inerDfvvyfGbFUj4w4schgmujcckBYeSCZrkoDh08pcrL0 Subject: [dane] Video - Warren explaining what DANE is all about X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Oct 2012 18:15:45 -0000 --Apple-Mail=_42749CA9-E811-4289-ABA8-C90A1F27A4F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii At the Vancouver IETF, I went off into a corner with Warren and recorded = a video interview talking about what DANE is all about. It is now up on = YouTube for your viewing pleasure: = http://www.internetsociety.org/deploy360/blog/2012/10/video-the-dane-proto= col-what-it-is-and-how-it-helps-make-the-internet-secure/ Direct YouTube link: http://www.youtube.com/watch?v=3DemDxUQl1NvA That post is also out on the Deploy360 accounts on Twitter, Facebook, = Google+. Retweets, shares, likes, +1s, etc. would naturally all be = welcome. =20 I'll also be down at IETF 85 in Atlanta (with a new camera) and would = love to record some more videos about DANE / DNSSEC. If you are would = be interested in doing a short interview about a DANE / DNSSEC (tool | = service | case study | whatever), please drop me a note (probably best = to york@isoc.org ) and let's see what we can do. Enjoy, Dan P.S. And those of you who may know what shirt Warren is wearing will = realize that I did not zoom out for a wider shot in order to keep the = video "safe for work" ;-) --=20 Dan York dyork@lodestar2.com http://www.danyork.me/ skype:danyork Phone: +1-802-735-1624 Twitter - http://twitter.com/danyork --Apple-Mail=_42749CA9-E811-4289-ABA8-C90A1F27A4F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii At = the Vancouver IETF, I went off into a corner with Warren and recorded a = video interview talking about what DANE is all about.  It is now up = on YouTube for your viewing pleasure:



That post is also = out on the Deploy360 accounts on Twitter, Facebook, Google+. Retweets, = shares, likes, +1s, etc. would naturally all be welcome. =  

I'll also be down at IETF 85 in Atlanta = (with a new camera) and would love to record some more videos about DANE = / DNSSEC.  If you are would be interested in doing a short = interview about a DANE / DNSSEC (tool | service | case study | = whatever), please drop me a note (probably best to york@isoc.org ) and let's see what we = can = do.

Enjoy,
Dan

P.S. And those of you who may know what shirt Warren is wearing will = realize that I did not zoom out for a wider shot in order to keep the = video "safe for work"  ;-)

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



= --Apple-Mail=_42749CA9-E811-4289-ABA8-C90A1F27A4F8-- From gnu@toad.com Fri Oct 5 11:34:25 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 459E921F8592 for ; Fri, 5 Oct 2012 11:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.511 X-Spam-Level: ** X-Spam-Status: No, score=2.511 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_NJABL_RELAY=2.696] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bikMIuppV9+M for ; Fri, 5 Oct 2012 11:34:24 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id 9557B21F8573 for ; Fri, 5 Oct 2012 11:34:24 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id q95IYMk7028421 for ; Fri, 5 Oct 2012 11:34:22 -0700 Message-Id: <201210051834.q95IYMk7028421@new.toad.com> To: dane@ietf.org Date: Fri, 05 Oct 2012 11:34:22 -0700 From: John Gilmore Subject: [dane] FYI: Verisign files patent application for way of transfering hosting on DNSSEC Domains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 18:34:25 -0000 [Sounds like somebody should tell the Patent Office that this "invention" is obvious to anyone skilled in the field, before those lovely monopolists at Verisign find themselves with yet another government-granted monopoly.] http://domainnamewire.com/2012/10/05/verisign-files-patent-application-for-way-of-transfering-hosting-on-dnssec-domains/ Verisign files patent application for way of transfering hosting on DNSSEC Domains Application describes way to change hosting on DNSSEC enabled domains without any downtime. Domain Name System Security Extensions (DNSSEC) bring all sorts of security benefits, but it can make changing hosting providers more challenging. Verisign has filed a patent for systems and methods for making the process of changing web hosts on a DNSSEC-enabled domain easier. Here's the challenge, as the company describes in its application named "Transfer of DNSSEC Domains": With the introduction of DNSSEC into vast registries, such as the .com and .net registries, DNS hosting transfer of a DNSSEC enabled domain brings with it the potential for resolution problems. Such problems may result in domains not resolving securely, or not resolving at all, which can have significant detrimental effects on e-commerce and other high-traffic sites. For DNSSEC, enabled domains, in addition to managing the switchover of nameservers, the change in registrars and/or hosts involves managing the Delegation Signer (DS) resource records in the parent zone and the list of DNSKEY records across the old and new child zones to ensure that the DNSSEC chain will continuously validate during the transfer. And here's the gist of what Verisign wants to patent: Systems and methods of transferring a DNSSEC enabled domain from a losing hosting provider to a gaining hosting provider are described in which the transfer of the domain may be achieved without disruption to a DNSSEC validation of the domain. Systems and methods, such as those directed to registry and/or registrar servers, may include transferring a DNSKEY or Delegation Signer (DS) record from a gaining hosting provider to a losing hosting provider prior to transferring the domain from the losing hosting provider to the gaining hosting provider. A gaining hosting provider may sign DNS records of the domain with the gaining hosting provider DNSKEY prior to transferring the domain from the losing hosting provider to the gaining hosting provider. Additionally, a registry server, or similar device, may be configured to act as an intermediary between the losing hosting provider and the gaining hosting provider during the transfer process. The application was filed April 1, 2011 and just published yesterday. From n.mavrogiannopoulos@gmail.com Sat Oct 6 02:16:23 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1953221F8672 for ; Sat, 6 Oct 2012 02:16:23 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mWU4Pd-s4Bw for ; Sat, 6 Oct 2012 02:16:22 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 209C621F865D for ; Sat, 6 Oct 2012 02:16:21 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so1445794wgb.13 for ; Sat, 06 Oct 2012 02:16:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=XT08usTEw0szMDkF4D7KSuzp4B289rj+nWzmG3p8GDI=; b=dwP1SytxGOAFj31479ylsZNGeTLnqivybMnLr8B9PnTKSReTQdz2uCSpiQGxHZKVsK PaCrsswIjywUyHKT/3mfO1TxK9ve/JvIPmHJ2p1ZBaTLqNCpV4do5VIDs4tJV0vGgRGt 6g/4VkrCDc7CA/g2zo4UxpPFJUULMdF2UpDcJ3Va23kdDJ6SpsGSxeWD5E+AFhHa5Z04 m596gi4XsxmKhbzGTMX2/sYnSZroo5kKg4lWwviG74nMY206emI9WIaxI2ykKerjVa9X ldvdSWrqGJXOONopwh44wKc7MgbRmb8rpoBiZEYKyJYOP1T6u0RPGrYSONI2VUkuNoR7 LMzw== Received: by 10.216.255.18 with SMTP id i18mr6757072wes.45.1349514981130; Sat, 06 Oct 2012 02:16:21 -0700 (PDT) Received: from [10.100.2.17] (94-224-100-5.access.telenet.be. [94.224.100.5]) by mx.google.com with ESMTPS id cn6sm7987446wib.9.2012.10.06.02.16.19 (version=SSLv3 cipher=OTHER); Sat, 06 Oct 2012 02:16:20 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <506FF6DD.9020902@gnutls.org> Date: Sat, 06 Oct 2012 11:16:13 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.6esrpre) Gecko/20120805 Icedove/10.0.6 MIME-Version: 1.0 To: dane@ietf.org X-Enigmail-Version: 1.4.1 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dane] an implementor's comments on DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 09:16:23 -0000 Hello, In this mail I list the issues I noticed while implementing DANE. No matter the direct language they are comments in good faith. They may be wrong because of my misunderstanding of the protocol, so feel free to correct me if this is the case. I think that DANE is _too_ complex for its purpose. 1. DANE does not imply DNSSEC, and verified using DANE may mean nothing. Why? Is there any reason not to require DNSSEC? How would a user that uses DANE over DNS and a user that uses it over DNSSEC understand the difference? What is the added value of using DANE over DNS? The RFC claims that there is no harm, but there is no reason either and in addition it introduces issues due to misconfiguration. Bottom line: DANE w/DNS adds no additional security and has the risk of verification false positives due to misconfiguration, so IMO no point for it. (DANE w/DNSSEC also introduces the risk of misconfiguration _but_ it adds additional security if configured properly) It is also a marketing issue. DANE should mean something better than before (i.e. dnssec), not just the same thing as before with a new name. 2. Too many certificate usage fields to indicate the _same_ thing. It is nice to see that there is a document (RFC6394) describing DANE real-world use-cases, but then the main protocol instead of defining a single protocol to cover all use cases, it makes several subprotocols for each use case. There are 4 certificate usage fields but only 2 of them are actually different. Certificate usage 0 is exactly the same as 2, and usage 1 is the same as 3. The difference is that if my certificate is signed by a CA I use 1, but if the CA signature expires but I don't renew I have to notify the DNS administrator to change it to 3. That's quite interesting. What is that for? So that the user knows that my certificate is expired? He already knows that. The same if I have a self-signed certificate that one can verify using DANE. If I decide to buy a signature from a CA to increase security, I actually create confusion for the users of DANE. Users of DANE would see the certificate usage 3 in my public key, and what should they think? That they are under attack, or that 3==0 and that this is a common misconfiguration? 3. Too many options for the selector field. Note that having more options is not better, it is worse because of incompatibilities. People will ignore DANE verification due to the many false positives. Why allow _both_ full X.509 and SubjectPublicKeyInfo fields? What is the advantage? The answer is none. You could also have allowed raw RSA keys, raw RSA keys that have e and m reversed and so on. But more options do not add additional security. My suggestion would be to simplify DANE by having a profile that is simple to implement and understand its purpose. That is: * Restrict DANE only with DNSSEC. If there is no DNSSEC, then there no DANE. * Deprecate usage fields 2 and 3. The serve no real purpose. * Only allow selectors for SubjectPublicKeyInfo. regards, Nikos From ilari.liusvaara@elisanet.fi Sat Oct 6 06:03:31 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD3B21F846C for ; Sat, 6 Oct 2012 06:03:31 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FT1kBkCio5Hb for ; Sat, 6 Oct 2012 06:03:30 -0700 (PDT) Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) by ietfa.amsl.com (Postfix) with ESMTP id B8B1E21F8464 for ; Sat, 6 Oct 2012 06:03:28 -0700 (PDT) Received: from saunalahti-vams (vs3-10.mail.saunalahti.fi [62.142.5.94]) by emh04.mail.saunalahti.fi (Postfix) with SMTP id E23DA1A261F; Sat, 6 Oct 2012 16:03:26 +0300 (EEST) Received: from emh02.mail.saunalahti.fi ([62.142.5.108]) by vs3-10.mail.saunalahti.fi ([62.142.5.94]) with SMTP (gateway) id A03977DC657; Sat, 06 Oct 2012 16:03:26 +0300 Received: from LK-Perkele-VI (a88-112-55-20.elisa-laajakaista.fi [88.112.55.20]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id 8B6EE81868; Sat, 6 Oct 2012 16:03:26 +0300 (EEST) Date: Sat, 6 Oct 2012 16:03:25 +0300 From: Ilari Liusvaara To: Nikos Mavrogiannopoulos Message-ID: <20121006130325.GA2926@LK-Perkele-VI.localdomain> References: <506FF6DD.9020902@gnutls.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <506FF6DD.9020902@gnutls.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Ilari Liusvaara X-Antivirus: VAMS Cc: dane@ietf.org Subject: Re: [dane] an implementor's comments on DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 13:03:31 -0000 On Sat, Oct 06, 2012 at 11:16:13AM +0200, Nikos Mavrogiannopoulos wrote: > I think that DANE is _too_ complex for its purpose. > > 1. DANE does not imply DNSSEC, and verified using DANE may mean nothing. > Why? Is there any reason not to require DNSSEC? DANE (at least as documented by the RFC 6698) _does_ require DNSSEC. RFC 6698, Section 4.1. > 2. Too many certificate usage fields to indicate the _same_ thing. Nope, no two certificate usages are the same. > Certificate usage 0 is exactly the same as 2, and usage 1 is the same as > 3. The difference is that if my certificate is signed by a CA I use 1, > but if the CA signature expires but I don't renew I have to notify the > DNS administrator to change it to 3. That's quite interesting. What is > that for? Nope, those are not the same. E.g. usage 1 _requires_ performing PKIX path validation, whereas usage 3 does _not_ require path validation. (In fact, usage 3 is by far the simplest one to implement; does the EE cert slot match one of these, yes/no). You can use 2/3 even if your certificate is signed by public CA. You just likely won't get any indications of security above DV level. 0/1 are only really useful if you have a OV or EV certificate. > The same if I have a self-signed certificate that one can verify using > DANE. If I decide to buy a signature from a CA to increase security, I > actually create confusion for the users of DANE. Users of DANE would see > the certificate usage 3 in my public key, and what should they think? If the usage 3 entry matches, ignore your CA certificate and proceed with the connection. If those don't match, consider other entries as usual (if none matches, reject the connection). Of course, if your CA certificate is EV (or OV), you only get DV security. > 3. Too many options for the selector field. > Note that having more options is not better, it is worse because of > incompatibilities. People will ignore DANE verification due to the many > false positives. Why allow _both_ full X.509 and SubjectPublicKeyInfo > fields? What is the advantage? The answer is none. This goes to dark territories of PKIX, but sometimes certificates are internally replaced without changing then SPKI. As to being able to bind to full certificate, there may be some advantage under rather contrived scenarios. But it is simpler to implement, since you won't need to even rip the SPKI out of the certificate... > You could also have > allowed raw RSA keys, raw RSA keys that have e and m reversed and so on. > But more options do not add additional security. There selectors truly do not add anything and are thus not there. In contrast, SPKI is always a proper substring of the certificate, and there is no room for interpretation how it should be put together given certificate. If there ever will be a raw RSA key type (seems unlikely, as it would require TLS WG to standardize a raw RSA key type), it will be its own usage, not its own selector. -Ilari From i.grok@comcast.net Sat Oct 6 06:32:05 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C14621F8625 for ; Sat, 6 Oct 2012 06:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTdLowc58n+0 for ; Sat, 6 Oct 2012 06:32:04 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED8C21F85A2 for ; Sat, 6 Oct 2012 06:32:04 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta15.westchester.pa.mail.comcast.net with comcast id 7obY1k0091ZXKqc5FpYXpt; Sat, 06 Oct 2012 13:32:31 +0000 Received: from odin.ulthar.us ([IPv6:2001:470:8c86:0:225:64ff:fe8b:c2f2]) by omta21.westchester.pa.mail.comcast.net with comcast id 7pZ71k00W2Ekl483hpZ9wk; Sat, 06 Oct 2012 13:33:09 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.5) with ESMTP id q96DW1wo031395 for ; Sat, 6 Oct 2012 09:32:01 -0400 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id q96DW1oC031394 for dane@ietf.org; Sat, 6 Oct 2012 09:32:01 -0400 Date: Sat, 6 Oct 2012 09:32:01 -0400 From: Scott Schmit To: dane@ietf.org Message-ID: <20121006133201.GA31319@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <506FF6DD.9020902@gnutls.org> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="KsGdsel6WgEHnImy" Content-Disposition: inline In-Reply-To: <506FF6DD.9020902@gnutls.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] an implementor's comments on DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 13:32:05 -0000 --KsGdsel6WgEHnImy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Oct 06, 2012 at 11:16:13AM +0200, Nikos Mavrogiannopoulos wrote: > Hello, > In this mail I list the issues I noticed while implementing DANE. No > matter the direct language they are comments in good faith. They may be > wrong because of my misunderstanding of the protocol, so feel free to > correct me if this is the case. >=20 > 1. DANE does not imply DNSSEC, and verified using DANE may mean nothing. Incorrect. Re-read section 4.1. If you don't understand the DNSSEC states cited there, you're going to need to read RFC 4033. > 2. Too many certificate usage fields to indicate the _same_ thing. > It is nice to see that there is a document (RFC6394) describing DANE > real-world use-cases, but then the main protocol instead of defining a > single protocol to cover all use cases, it makes several subprotocols > for each use case. There are 4 certificate usage fields but only 2 of > them are actually different. >=20 > Certificate usage 0 is exactly the same as 2, and usage 1 is the same as > 3. They aren't. 0 & 1 validate against your client's trust anchors. 2 & 3 do not. If we didn't have 2 & 3, then self-signed certificates cannot be used with DANE. If we didn't have 0 & 1, then certificate revocation and trust anchor changes would be ignored. (Think DigiNotar.) Different people care about different things. > If I decide to buy a signature from a CA to increase security, I > actually create confusion for the users of DANE. Users of DANE would > see the certificate usage 3 in my public key, and what should they > think? That they are under attack, or that 3=3D=3D0 and that this is a > common misconfiguration? Ignoring whether an end-user should ever be exposed to this level of detail, they should think that the person configuring the record used a CA for compatibility with non-DANE clients but doesn't put a lot of trust in the CA they got their certificate from. Also, maybe, they serve clients that don't have their CA in their trust store, so they might be hoping that using 3 lets them reach a few more people without trouble (I don't think any CA is in 100% of clients -- I usually see 9x.x% numbers). > 3. Too many options for the selector field. > Note that having more options is not better, it is worse because of > incompatibilities. Incompatiblities? > People will ignore DANE verification due to the many > false positives. Why allow _both_ full X.509 and SubjectPublicKeyInfo > fields? Because: (full X.509) fields other than the SubjectPublicKeyInfo affect X.509 validation, so being able to prevent them from changing may be important to you. (SPKI only) transvalidity is evil, but an unfortunate reality. Sometimes I can't be sure of anything but the key. See Appendix A.1. Hope this helps, --=20 Scott Schmit --KsGdsel6WgEHnImy Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQBAYJKoZIhvcNAQcCoIIP9TCCD/ECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DTUwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBvkwggXhoAMCAQICAwR4CjANBgkqhkiG 9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEyMDcwNDEz NTc1MVoXDTEzMDcwNTA1MjcyNlowQDEbMBkGA1UEAwwSaS5ncm9rQGNvbWNhc3QubmV0MSEw HwYJKoZIhvcNAQkBFhJpLmdyb2tAY29tY2FzdC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCxn+QJTgdUJ1RAOi6JbFsDfl21ZX/OPx/ttuXWQP1vWwBZybHU+4/+bRXH 5ONhjbc5ikZvz/E406iQLy2xMT5PI/hx4uIZQQYpkjxd4rCbbvLNACz5L+cFaGj4WfGwAXDv bw4nx8Mh3WjbR5yjBCWYqadiv7HWAWmhaJmuaTp/e+mO2EEOOdoNQ8b2mxMyN43TlElx6Zos t7g/eQUcLWgTB5apPhowCCGnFU6uHK053QsPmsmZ67gg8acpb5ic0+P+X1j+IgD3jcsDzjrF TPlrvU4ZuBYQJISqngbc2ua/uutx75Xs4iFXWNRlnYfZMFJy96USzrhIBRqcORrjbyGXAgMB AAGjggOtMIIDqTAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcD AgYIKwYBBQUHAwQwHQYDVR0OBBYEFAxkdHPHW3mhf+gXJjezdazgoDRuMB8GA1UdIwQYMBaA FFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB0GA1UdEQQWMBSBEmkuZ3Jva0Bjb21jYXN0Lm5ldDCC AiEGA1UdIASCAhgwggIUMIICEAYLKwYBBAGBtTcBAgIwggH/MC4GCCsGAQUFBwIBFiJodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFy dENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3 YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVt ZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUg aW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9i bGlnYXRpb25zLjCBnAYIKwYBBQUHAgIwgY8wJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBAhpkTGlhYmlsaXR5IGFuZCB3YXJyYW50aWVzIGFyZSBsaW1pdGVkISBT ZWUgc2VjdGlvbiAiTGVnYWwgYW5kIExpbWl0YXRpb25zIiBvZiB0aGUgU3RhcnRDb20gQ0Eg cG9saWN5LjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9h aWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQELBQADggEBACJi0f4m 0bSVq+pq4AHeC2Rj4S8rciW+Uce6LC69UlyVMijKv/pZNFM08vqRXEI9WpKQhKXacJ+rK9az DBmnxq1scqKhn7991V6Yt2t0tEY8vUX7q330GybUB/rQLNrh66GFXaEWU/S692pGzvUXeV+w zz48snMpoMHQdxkHHW5sQkpo99SF/vOA5/sqvFmJ+ai1iDRjtKcChjkmAtFmCKv/dNrXnvew 5+QnLlnE/TsW4Sdv3bcLdlthD4eavS3BdgXfX7dfj0ykel53J2Us3CikNbyuCsJpwMH+gX1j LcXZOYIDLzZXCFEOFajhgsAZ5JQrW0fFRxjGIp8Rs+rxdFwxggKXMIICkwIBATCBlDCBjDEL MAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBE aWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEg UHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMEeAowCQYFKw4DAhoFAKCB2DAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjEwMDYxMzMyMDFaMCMG CSqGSIb3DQEJBDEWBBS7gX/xw3g+FZ4sjNomH4htGRH/tzB5BgkqhkiG9w0BCQ8xbDBqMAsG CWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkq hkiG9w0BAQEFAASCAQA7eYTtinhb5b+D7ZIbTpvssm3WqZeH/5i927dNklaroliX6BxeWHkW fjNKxrdngW0UIiQXX/QZD5PKrnFCU+MHY921t6r6UeXziiiYl7Xyv55LEeF7/JBGopamgr0q yDQJoJmb8qDA+/49ILPBMCnxUMCPWBLAu7KNuvY8ZQBxjOKwrMwTZwqCQDm+IUqxXtdKH4Wy /1uCDAOXUZUfnY6G4OKgZRGP0iuj4D5fVqy+UvcOfgpDNN50Y1qxTJlgolUmgp4L+Yf5jWmp NpT7uP8TrojggL2vbZP4VUlFeNTYgAM9sS6rAD9YfTNEqwQoBQl9Xv+9j618ZtVqRGyUXxy9 --KsGdsel6WgEHnImy-- From paul.hoffman@vpnc.org Sat Oct 6 08:07:24 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0047221F8518 for ; Sat, 6 Oct 2012 08:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AApErW1s7cR5 for ; Sat, 6 Oct 2012 08:07:23 -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 5F07A21F84B5 for ; Sat, 6 Oct 2012 08:07:23 -0700 (PDT) Received: from [10.20.30.108] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q96F7G2T036182 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 6 Oct 2012 08:07:17 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: <506FF6DD.9020902@gnutls.org> Date: Sat, 6 Oct 2012 08:07:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2C8956F7-CB42-4173-B132-21D310CDE4EB@vpnc.org> References: <506FF6DD.9020902@gnutls.org> To: Nikos Mavrogiannopoulos X-Mailer: Apple Mail (2.1499) Cc: dane@ietf.org Subject: Re: [dane] an implementor's comments on DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 15:07:24 -0000 Ilari made some good comments, but I need to emphasize one thing: On Oct 6, 2012, at 2:16 AM, Nikos Mavrogiannopoulos = wrote: > You could also have > allowed raw RSA keys, raw RSA keys that have e and m reversed and so = on. If those ever become valid ways to authenticate TLS sessions, we expect = to add those to DANE. We said as much, multiple times, on the mailing = list. --Paul Hoffman From paul@nohats.ca Sat Oct 6 15:57:39 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A832221F84C5 for ; Sat, 6 Oct 2012 15:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.622 X-Spam-Level: X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[AWL=-0.512, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbToVUGOUG4X for ; Sat, 6 Oct 2012 15:57:39 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 29FF721F84C4 for ; Sat, 6 Oct 2012 15:57:38 -0700 (PDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 7CB3D82B21; Sat, 6 Oct 2012 18:57:35 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 71D4982A5B; Sat, 6 Oct 2012 18:57:35 -0400 (EDT) Date: Sat, 6 Oct 2012 18:57:35 -0400 (EDT) From: Paul Wouters To: John Gilmore , David Blacka In-Reply-To: <201210051834.q95IYMk7028421@new.toad.com> Message-ID: References: <201210051834.q95IYMk7028421@new.toad.com> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: dane WG list Subject: Re: [dane] FYI: Verisign files patent application for way of transfering hosting on DNSSEC Domains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 22:57:39 -0000 On Fri, 5 Oct 2012, John Gilmore wrote: > [Sounds like somebody should tell the Patent Office that this > "invention" is obvious to anyone skilled in the field, before > those lovely monopolists at Verisign find themselves with yet > another government-granted monopoly.] > > http://domainnamewire.com/2012/10/05/verisign-files-patent-application-for-way-of-transfering-hosting-on-dnssec-domains/ > > Verisign files patent application for way of transfering > hosting on DNSSEC Domains David, As one of the contributors to that patent, can you tell us more about this and any IPR disclosure submited to the IETF and the "Note Well"? Paul From paul.hoffman@vpnc.org Sat Oct 6 16:13:26 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5C121F84DE for ; Sat, 6 Oct 2012 16:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUKiV+Gpv3yS for ; Sat, 6 Oct 2012 16:13:23 -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 796A621F84D8 for ; Sat, 6 Oct 2012 16:13:23 -0700 (PDT) Received: from [10.20.30.108] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q96NDJRn050039 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 6 Oct 2012 16:13:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: Date: Sat, 6 Oct 2012 16:13:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <87B403A3-D814-4DF4-88B9-FF313AB004B1@vpnc.org> References: <201210051834.q95IYMk7028421@new.toad.com> To: dane WG list X-Mailer: Apple Mail (2.1499) Subject: Re: [dane] FYI: Verisign files patent application for way of transfering hosting on DNSSEC Domains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 23:13:26 -0000 No hats, because I am not a WG chair here, but: Could this discussion move to a list where it is more appropriate? There = is *nothing* about transferring hosting of domains with DNSSEC that is = more relevant to the DANE WG than, say, DNSEXT or DNSOP. It is even more = relevant on the IETF general mailing than here. If anything useful comes = of this thread, it will be missed by some of those who should see it if = it is in this WG. --Paul Hoffman= From hallam@gmail.com Sat Oct 6 19:26:59 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7383021F84E6 for ; Sat, 6 Oct 2012 19:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.889 X-Spam-Level: X-Spam-Status: No, score=-3.889 tagged_above=-999 required=5 tests=[AWL=-0.291, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELmA7inZCvzu for ; Sat, 6 Oct 2012 19:26:58 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id B0A7121F84DE for ; Sat, 6 Oct 2012 19:26:58 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n5so3476226oag.31 for ; Sat, 06 Oct 2012 19:26:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CEzJfH//ZcXGi9aZ2Imip3Sxgnoyqwcx6t5i9Rajsno=; b=RMfLp7gGaifxcp3D4UAsB/tzCNeYQcCaDYmWL2+tFA7oM8DG/XwolH3LBHT0IDtNMd PIRv94eBEoYjdI3Iqcgp4WhsmutOUZZvmj53ZvnnhBPjvPO6kA/kZSd3rpg16lK1kocL 6gswt+qYHVeNLcaTFQCM/jzp9spZ+OcLRs5AUmLuMuWglC9EaMSFHZ09lmhQ3ROonIod e+HoLjUU/gPosTK15E3iTR1NjftD4i1QUyt9gJ0y3QTKTTPH4aD3mxfyuhhxeA8qexRy qHWRlaaP96xOkUQgAyhdoyb090XhKHwQtZDleWvrTpFp670hcrP5ZrDfN1RhkdgoA7cx o5bQ== MIME-Version: 1.0 Received: by 10.60.170.9 with SMTP id ai9mr9899851oec.36.1349576818275; Sat, 06 Oct 2012 19:26:58 -0700 (PDT) Received: by 10.76.27.103 with HTTP; Sat, 6 Oct 2012 19:26:58 -0700 (PDT) In-Reply-To: <87B403A3-D814-4DF4-88B9-FF313AB004B1@vpnc.org> References: <201210051834.q95IYMk7028421@new.toad.com> <87B403A3-D814-4DF4-88B9-FF313AB004B1@vpnc.org> Date: Sat, 6 Oct 2012 22:26:58 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=bcaec54a3e02d9b50804cb6ed60e Cc: dane WG list Subject: Re: [dane] FYI: Verisign files patent application for way of transfering hosting on DNSSEC Domains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 02:26:59 -0000 --bcaec54a3e02d9b50804cb6ed60e Content-Type: text/plain; charset=ISO-8859-1 +1 to that And it is usually a good idea to find out the intent of a patent filer before sounding of about monopolists and such. One of the sad facts about our industry is that the patent system is a prisoner's dilema game with a huge number of prisoners. Not patenting an idea means someone else will try. Lets get facts before making accusations on any other lists either. If the WG has not discussed the practical question of how to transfer DNSSEC domains from one registrar to another on the DNSEXT list then that possibly raises the question of whether the spec has been properly vetted. [I did work for VeriSign in the past but this application was made after my time there and there have been significant management changes since.] On Sat, Oct 6, 2012 at 7:13 PM, Paul Hoffman wrote: > No hats, because I am not a WG chair here, but: > > Could this discussion move to a list where it is more appropriate? There > is *nothing* about transferring hosting of domains with DNSSEC that is more > relevant to the DANE WG than, say, DNSEXT or DNSOP. It is even more > relevant on the IETF general mailing than here. If anything useful comes of > this thread, it will be missed by some of those who should see it if it is > in this WG. > > --Paul Hoffman > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > -- Website: http://hallambaker.com/ --bcaec54a3e02d9b50804cb6ed60e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1 to that

And it is usually a good idea to find out the= intent of a patent filer before sounding of about monopolists and such.=A0=

One of the sad facts about our industry is that t= he patent system is a prisoner's dilema game with a huge number of pris= oners. Not patenting an idea means someone else will try. Lets get facts be= fore making accusations on any other lists either.

If the WG has not discussed the practical question of h= ow to transfer DNSSEC domains from one registrar to another on the DNSEXT l= ist then that possibly raises the question of whether the spec has been pro= perly vetted.=A0


[I did work for VeriSign in the past but= this application was made after my time there and there have been signific= ant management changes since.]

--bcaec54a3e02d9b50804cb6ed60e-- From ahu@xs.powerdns.com Sat Oct 6 23:47:41 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5FE21F8472 for ; Sat, 6 Oct 2012 23:47:41 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPfNkts-CDwP for ; Sat, 6 Oct 2012 23:47:40 -0700 (PDT) Received: from xs.powerdns.com (xs.powerdns.com [IPv6:2001:888:2000:1d::2]) by ietfa.amsl.com (Postfix) with ESMTP id BB68121F844C for ; Sat, 6 Oct 2012 23:47:40 -0700 (PDT) Received: from ahu by xs.powerdns.com with local (Exim 4.71) (envelope-from ) id 1TKke9-0000bo-MI; Sun, 07 Oct 2012 08:47:29 +0200 Date: Sun, 7 Oct 2012 08:47:29 +0200 From: bert hubert To: Paul Wouters Message-ID: <20121007064729.GB1686@xs.powerdns.com> References: <201210051834.q95IYMk7028421@new.toad.com> 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: David Blacka , dane WG list Subject: Re: [dane] FYI: Verisign files patent application for way of transfering hosting on DNSSEC Domains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 06:47:41 -0000 On Sat, Oct 06, 2012 at 06:57:35PM -0400, Paul Wouters wrote: > David, > As one of the contributors to that patent, can you tell us more > about this and any IPR disclosure submited to the IETF and the "Note > Well"? Also, please be real. David works on technology. No public corporation the US is ever going to allow an engineer to say anything in response to a question like this. Please don't make life hard on David. bert From n.mavrogiannopoulos@gmail.com Sun Oct 7 00:04:57 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0C9821F847F for ; Sun, 7 Oct 2012 00:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dq9PZ87392sA for ; Sun, 7 Oct 2012 00:04:55 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAC821F8452 for ; Sun, 7 Oct 2012 00:04:54 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u46so2106137wey.31 for ; Sun, 07 Oct 2012 00:04:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; bh=rXbqcAOuvmaR2nrx59PktkMt7cLugl0PivMelneDoOA=; b=PugD0/HeMrHvQL3RV3Dlf/8UHenWXgJEkbH/byPvGADXeSVeX1wfslrmLoIxxDRNTH HVeivkCuiTMmEi/dyvbsk/Uu9kuAZwpTMvzARQntq3iJzh6nSANvADBbwnGIVpOe783j 8JkAkLMQY/jmBLox6NwfC0jUjMTO2YVqtj/qR18VbNBL8ufPixgbfuN1Hm23CFSwIcfs psbMxNFQxzfHdDWXZpVLfKjMomW81IRSQLLx0gc+ZxM0cHb41OyXcb2Zo4K6fbfqltn0 w3JOeKBewo9gTp4gjtwVj9UYpnWzQB30FfJYp4x5s4I54mrbgzDdPo35jkKzBwJR8rnD LT8g== Received: by 10.216.147.199 with SMTP id t49mr7513098wej.54.1349593493739; Sun, 07 Oct 2012 00:04:53 -0700 (PDT) Received: from [10.100.2.17] (94-224-100-5.access.telenet.be. [94.224.100.5]) by mx.google.com with ESMTPS id b7sm12316599wiz.3.2012.10.07.00.04.52 (version=SSLv3 cipher=OTHER); Sun, 07 Oct 2012 00:04:53 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <5071298E.9020602@gnutls.org> Date: Sun, 07 Oct 2012 09:04:46 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.6esrpre) Gecko/20120805 Icedove/10.0.6 MIME-Version: 1.0 To: Ilari Liusvaara References: <506FF6DD.9020902@gnutls.org> <20121006130325.GA2926@LK-Perkele-VI.localdomain> In-Reply-To: <20121006130325.GA2926@LK-Perkele-VI.localdomain> X-Enigmail-Version: 1.4.1 OpenPGP: id=96865171 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: dane@ietf.org Subject: Re: [dane] an implementor's comments on 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: Sun, 07 Oct 2012 07:04:57 -0000 On 10/06/2012 03:03 PM, Ilari Liusvaara wrote: >> 1. DANE does not imply DNSSEC, and verified using DANE may mean nothing. >> Why? Is there any reason not to require DNSSEC? > DANE (at least as documented by the RFC 6698) _does_ require DNSSEC. > RFC 6698, Section 4.1. At least 3 host names in the list of DANE test sites do not use DNSSEC. http://www.internetsociety.org/deploy360/resources/dane-test-sites/ >> 2. Too many certificate usage fields to indicate the _same_ thing. > Nope, no two certificate usages are the same. >> Certificate usage 0 is exactly the same as 2, and usage 1 is the same as >> 3. The difference is that if my certificate is signed by a CA I use 1, >> but if the CA signature expires but I don't renew I have to notify the >> DNS administrator to change it to 3. That's quite interesting. What is >> that for? > Nope, those are not the same. E.g. usage 1 _requires_ performing PKIX path > validation, whereas usage 3 does _not_ require path validation. Well, my point is that they transfer exactly the same data. 0 transfers an end-entity certificate and so does 2. They differ, as you say, on what the receiving party does on that data. Why bother? How would a server operator ever know what the receiving party will do on the data? Let's say I'm on an company that has it's main web site signed with a CA certificate that is installed on all employees computers. Do I use 0 or 2? All employees perform PKIX path validation so it should be 0. Now you connect to this site, but you don't trust this CA. So it should have been 2, or both? PKIX path validation is a process that runs on the client and the server has no indication whether it will actually occur, or that it will share a common trusted party at all. DANE would help in the cases the peers do not share a common trusted party by providing an indication of the identity of peer. However, the DANE protocol goes to extremes only. Either the server shares nothing with no-one (self-signed), or shares a CA with everyone. Reality is somewhere between those extremes. What the writer of the RFC may have meant, is whether you do a verification against the commercial CA set in a browser. However, this set varies from browser to browser and scenarios like the one above will occur. > You can use 2/3 even if your certificate is signed by public CA. > You just likely won't get any indications of security above DV level. > 0/1 are only really useful if you have a OV or EV certificate. OV or EV are pretty much marketing terms, they shouldn't have been considered in a protocol. >> The same if I have a self-signed certificate that one can verify using >> DANE. If I decide to buy a signature from a CA to increase security, I >> actually create confusion for the users of DANE. Users of DANE would see >> the certificate usage 3 in my public key, and what should they think? > If the usage 3 entry matches, ignore your CA certificate and proceed with > the connection. Doing that I would reduce the security of the connection. By ignoring the CA certificate I put the trust on the DNS administrator only. My goal as an implementor of DANE is to disperse the trust to various parties and warn the user of any discrepancy. With the mix or 0,2 and 1,3 I see many cases of false alarms and eventually users disabling the DANE verification. >> 3. Too many options for the selector field. >> Note that having more options is not better, it is worse because of >> incompatibilities. People will ignore DANE verification due to the many >> false positives. Why allow _both_ full X.509 and SubjectPublicKeyInfo >> fields? What is the advantage? The answer is none. > This goes to dark territories of PKIX, but sometimes certificates are > internally replaced without changing then SPKI. Indeed, and this is why only the SubjectPublicKeyInfo should have been defined. Now several DANE tools support only the X.509 format but not the SubjectPublicKeyInfo. I expect other tools from other implementors to only support the SubjectPublicKeyInfo (we had this in other protocols), just to be incompatible with them. Not to mention misconfigured servers that indicate a SubjectPublicKeyInfo, but send an X.509 hash. Those are not things that typically occur in a _new_ protocol like DANE. You see these in a 10 year protocol with a gazillion of options added through the years. DANE has already too many in its first incarnation. > As to being able to bind to full certificate, there may be some advantage > under rather contrived scenarios. But it is simpler to implement, since > you won't need to even rip the SPKI out of the certificate... Does it really worth it? Was it like 3 lines of code saved, at the cost of an extra protocol option? Now as a library author, I had to implement _all_ cases actually coding much more than if only one of the SubjectPublicKeyInfo or X.509 had been defined. >> You could also have >> allowed raw RSA keys, raw RSA keys that have e and m reversed and so on. >> But more options do not add additional security. > There selectors truly do not add anything and are thus not there. They add the same as X.509 adds to SubjectPublicKeyInfo (or vice-versa). That is nothing indeed. regards, Nikos From i.grok@comcast.net Sun Oct 7 08:31:39 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8D3221F86CB for ; Sun, 7 Oct 2012 08:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9AoipPz1zzX for ; Sun, 7 Oct 2012 08:31:39 -0700 (PDT) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:228]) by ietfa.amsl.com (Postfix) with ESMTP id 22DF721F853F for ; Sun, 7 Oct 2012 08:31:39 -0700 (PDT) Received: from omta13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by qmta15.emeryville.ca.mail.comcast.net with comcast id 8FTo1k00117UAYkAFFXe5K; Sun, 07 Oct 2012 15:31:38 +0000 Received: from odin.ulthar.us ([IPv6:2001:470:8c86:0:225:64ff:fe8b:c2f2]) by omta13.emeryville.ca.mail.comcast.net with comcast id 8FXb1k00U2Ekl488ZFXezm; Sun, 07 Oct 2012 15:31:38 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.5) with ESMTP id q97FVYUt002435 for ; Sun, 7 Oct 2012 11:31:34 -0400 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id q97FVXON002434 for dane@ietf.org; Sun, 7 Oct 2012 11:31:33 -0400 Date: Sun, 7 Oct 2012 11:31:33 -0400 From: Scott Schmit To: dane@ietf.org Message-ID: <20121007153133.GA2216@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <506FF6DD.9020902@gnutls.org> <20121006130325.GA2926@LK-Perkele-VI.localdomain> <5071298E.9020602@gnutls.org> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="TB36FDmn/VVEgNH/" Content-Disposition: inline In-Reply-To: <5071298E.9020602@gnutls.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] an implementor's comments on 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: Sun, 07 Oct 2012 15:31:39 -0000 --TB36FDmn/VVEgNH/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 07, 2012 at 09:04:46AM +0200, Nikos Mavrogiannopoulos wrote: > On 10/06/2012 03:03 PM, Ilari Liusvaara wrote: > >> 2. Too many certificate usage fields to indicate the _same_ thing. >=20 > > Nope, no two certificate usages are the same. > >> Certificate usage 0 is exactly the same as 2, and usage 1 is the same = as > >> 3. The difference is that if my certificate is signed by a CA I use 1, > >> but if the CA signature expires but I don't renew I have to notify the > >> DNS administrator to change it to 3. That's quite interesting. What is > >> that for? > > Nope, those are not the same. E.g. usage 1 _requires_ performing PKIX p= ath > > validation, whereas usage 3 does _not_ require path validation. >=20 > Well, my point is that they transfer exactly the same data. 0 transfers > an end-entity certificate and so does 2. They differ, as you say, on > what the receiving party does on that data. Why bother? How would a > server operator ever know what the receiving party will do on the data? How does any server operator deploy a TLS-protected site if they don't know what trust anchors their users have available? Today, without DANE, if you deploy a TLS service and don't pay attention to that, you're going to get complaints from (some subset of) your users about certificate errors (or they aren't being checked at all, which isn't exactly secure). All CA certificates are not equal. > Let's say I'm on an company that has it's main web site signed with a CA > certificate that is installed on all employees computers. Do I use 0 or > 2? All employees perform PKIX path validation so it should be 0. Now you > connect to this site, but you don't trust this CA. So it should have > been 2, or both? If you expect only your employees to connect, then 0. If it's facing the public and you want them to be able to use it, then 2. This is no different than the decisions you had to make when chosing a CA in the first place. This is the same as asking "but what CA should I use for my web site?" When I go to get a certificate from a CA, they all talk about being trusted by X% of web browsers, and/or name the browser platforms they are trusted by. If your users have the CA in their trust anchor sets (however that is, whether by local customization or because the clients have done it for you), then use 0/1. Otherwise, you'll need to use 2/3 or it won't work in some percent of cases. > PKIX path validation is a process that runs on the client and the server > has no indication whether it will actually occur, or that it will share > a common trusted party at all. DANE would help in the cases the peers do > not share a common trusted party by providing an indication of the > identity of peer. However, the DANE protocol goes to extremes only. > Either the server shares nothing with no-one (self-signed), or shares a > CA with everyone. Reality is somewhere between those extremes. You can always deploy like so: example.com. IN TLSA 0 0 1 ..... example.com. IN TLSA 2 0 0 ..... If the cert is in their trust store, the first record will work (so will the second, but will either never get used or get used 50% of the time, depending on the implementation). If it's not in their trust store, only the second will work, but it will work. I'm not sure how we could have done better--CA certificates are either trusted or not, there is no in between. Do you have a proposal, other than to cut options which would (apparently) make us even more extreme? > What the writer of the RFC may have meant, is whether you do a > verification against the commercial CA set in a browser. However, this > set varies from browser to browser and scenarios like the one above will > occur. DANE is complicated by the fact that PKIX is complicated. > > You can use 2/3 even if your certificate is signed by public CA.=20 > > You just likely won't get any indications of security above DV level. > > 0/1 are only really useful if you have a OV or EV certificate. >=20 > OV or EV are pretty much marketing terms, they shouldn't have been > considered in a protocol. Who said they were? You aren't reading very carefully--he said "likely won't" -- this is all up to the people defining OV/EV, which isn't the IETF. > >> The same if I have a self-signed certificate that one can verify using > >> DANE. If I decide to buy a signature from a CA to increase security, I > >> actually create confusion for the users of DANE. Users of DANE would s= ee > >> the certificate usage 3 in my public key, and what should they think? > > If the usage 3 entry matches, ignore your CA certificate and proceed wi= th > > the connection. >=20 > Doing that I would reduce the security of the connection. By ignoring > the CA certificate I put the trust on the DNS administrator only. My > goal as an implementor of DANE is to disperse the trust to various > parties and warn the user of any discrepancy. With the mix or 0,2 and > 1,3 I see many cases of false alarms and eventually users disabling the > DANE verification. Read (or reread) Section 8. If you think that 0/1 isn't putting trust in the DNS admins I suggest you look into what it takes to get a certificate from a CA. > Those are not things that typically occur in a _new_ protocol like DANE. > You see these in a 10 year protocol with a gazillion of options added > through the years. DANE has already too many in its first incarnation. You aren't the only one looking to deploy this. DANE is more complex than I'd like because PKIX and the reality of its deployment is more complex than I'd like. DANE may be new, but PKIX is not. --=20 Scott Schmit --TB36FDmn/VVEgNH/ Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQBAYJKoZIhvcNAQcCoIIP9TCCD/ECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DTUwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBvkwggXhoAMCAQICAwR4CjANBgkqhkiG 9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEyMDcwNDEz NTc1MVoXDTEzMDcwNTA1MjcyNlowQDEbMBkGA1UEAwwSaS5ncm9rQGNvbWNhc3QubmV0MSEw HwYJKoZIhvcNAQkBFhJpLmdyb2tAY29tY2FzdC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCxn+QJTgdUJ1RAOi6JbFsDfl21ZX/OPx/ttuXWQP1vWwBZybHU+4/+bRXH 5ONhjbc5ikZvz/E406iQLy2xMT5PI/hx4uIZQQYpkjxd4rCbbvLNACz5L+cFaGj4WfGwAXDv bw4nx8Mh3WjbR5yjBCWYqadiv7HWAWmhaJmuaTp/e+mO2EEOOdoNQ8b2mxMyN43TlElx6Zos t7g/eQUcLWgTB5apPhowCCGnFU6uHK053QsPmsmZ67gg8acpb5ic0+P+X1j+IgD3jcsDzjrF TPlrvU4ZuBYQJISqngbc2ua/uutx75Xs4iFXWNRlnYfZMFJy96USzrhIBRqcORrjbyGXAgMB AAGjggOtMIIDqTAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcD AgYIKwYBBQUHAwQwHQYDVR0OBBYEFAxkdHPHW3mhf+gXJjezdazgoDRuMB8GA1UdIwQYMBaA FFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB0GA1UdEQQWMBSBEmkuZ3Jva0Bjb21jYXN0Lm5ldDCC AiEGA1UdIASCAhgwggIUMIICEAYLKwYBBAGBtTcBAgIwggH/MC4GCCsGAQUFBwIBFiJodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFy dENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3 YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVt ZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUg aW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9i bGlnYXRpb25zLjCBnAYIKwYBBQUHAgIwgY8wJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBAhpkTGlhYmlsaXR5IGFuZCB3YXJyYW50aWVzIGFyZSBsaW1pdGVkISBT ZWUgc2VjdGlvbiAiTGVnYWwgYW5kIExpbWl0YXRpb25zIiBvZiB0aGUgU3RhcnRDb20gQ0Eg cG9saWN5LjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9h aWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQELBQADggEBACJi0f4m 0bSVq+pq4AHeC2Rj4S8rciW+Uce6LC69UlyVMijKv/pZNFM08vqRXEI9WpKQhKXacJ+rK9az DBmnxq1scqKhn7991V6Yt2t0tEY8vUX7q330GybUB/rQLNrh66GFXaEWU/S692pGzvUXeV+w zz48snMpoMHQdxkHHW5sQkpo99SF/vOA5/sqvFmJ+ai1iDRjtKcChjkmAtFmCKv/dNrXnvew 5+QnLlnE/TsW4Sdv3bcLdlthD4eavS3BdgXfX7dfj0ykel53J2Us3CikNbyuCsJpwMH+gX1j LcXZOYIDLzZXCFEOFajhgsAZ5JQrW0fFRxjGIp8Rs+rxdFwxggKXMIICkwIBATCBlDCBjDEL MAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBE aWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEg UHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMEeAowCQYFKw4DAhoFAKCB2DAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjEwMDcxNTMxMzNaMCMG CSqGSIb3DQEJBDEWBBRlyO4KeVw6L3h2F9WN33VB/Qb5WjB5BgkqhkiG9w0BCQ8xbDBqMAsG CWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkq hkiG9w0BAQEFAASCAQBN5cPJcN0jRHblKnXuGLHsIij5SJNNhYqFoFhGPczKnNKyhQV0bKZK 7T63XuvoeM22LTUbgnOl73rser9W+V4Nka6hHeN6hgySG1Y/dechWoKlqEozhFisUkYiyJd1 dY2Bbih5sPyoiPWRM0KLXH4lgN5K0XpFMTd7c85MNFhDHC+QIPshxv6DM765HbpZ6+Yo3H0g +GduFh9MdaTTfYzJHpVHXpQyHmP2Gu7qxidUvCRj1qkWNjDEDoVazFDBC9r7Jrqz6DiWDblE qD3kXaz1XRhtOCpgIXKmp2F3QC2lbqB36YLJyL0rIn16jJysYNHuE417KQDnSDOiGjViNe83 --TB36FDmn/VVEgNH/-- From paul@cypherpunks.ca Sun Oct 7 12:11:46 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E655D21F870B for ; Sun, 7 Oct 2012 12:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NprNw87eCpI5 for ; Sun, 7 Oct 2012 12:11:45 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 1100021F870A for ; Sun, 7 Oct 2012 12:11:44 -0700 (PDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 63881804B4; Sun, 7 Oct 2012 15:11:40 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 5791E804B3; Sun, 7 Oct 2012 15:11:40 -0400 (EDT) Date: Sun, 7 Oct 2012 15:11:40 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Nikos Mavrogiannopoulos In-Reply-To: <5071298E.9020602@gnutls.org> Message-ID: References: <506FF6DD.9020902@gnutls.org> <20121006130325.GA2926@LK-Perkele-VI.localdomain> <5071298E.9020602@gnutls.org> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: dane WG list Subject: Re: [dane] an implementor's comments on 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: Sun, 07 Oct 2012 19:11:46 -0000 On Sun, 7 Oct 2012, Nikos Mavrogiannopoulos wrote: > At least 3 host names in the list of DANE test sites do not use DNSSEC. > http://www.internetsociety.org/deploy360/resources/dane-test-sites/ The fedoraproject.org and nohats.ca one require you enable DLV to get a full DNSSEC chain that can be validated. > Indeed, and this is why only the SubjectPublicKeyInfo should have been > defined. I tried :) Paul From gnu@toad.com Mon Oct 8 18:40:18 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9B911E80DE for ; Mon, 8 Oct 2012 18:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.304 X-Spam-Level: * X-Spam-Status: No, score=1.304 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, RCVD_IN_NJABL_RELAY=2.696] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9qdS3AM1S4o for ; Mon, 8 Oct 2012 18:40:17 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id AB97F11E80DF for ; Mon, 8 Oct 2012 18:40:13 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id q991dsk7020839; Mon, 8 Oct 2012 18:39:54 -0700 Message-Id: <201210090139.q991dsk7020839@new.toad.com> To: Nikos Mavrogiannopoulos In-reply-to: <5071298E.9020602@gnutls.org> References: <506FF6DD.9020902@gnutls.org> <20121006130325.GA2926@LK-Perkele-VI.localdomain> <5071298E.9020602@gnutls.org> Comments: In-reply-to Nikos Mavrogiannopoulos message dated "Sun, 07 Oct 2012 09:04:46 +0200." Date: Mon, 08 Oct 2012 18:39:54 -0700 From: John Gilmore Cc: dane@ietf.org Subject: Re: [dane] an implementor's comments on 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: Tue, 09 Oct 2012 01:40:18 -0000 > At least 3 host names in the list of DANE test sites do not use DNSSEC. > http://www.internetsociety.org/deploy360/resources/dane-test-sites/ Then it's a good thing that we're testing that case, isn't it? :-) DANE implementations should refuse to connect to those test sites, which don't have DNSSEC signatures all the way back to the root key. (The fact that DANE should fail with them should be mentioned in that page tho.) > >> Certificate usage 0 is exactly the same as 2, and usage 1 is the same as > >> 3. The difference is that if my certificate is signed by a CA I use 1, > > Well, my point is that they transfer exactly the same data. 0 transfers > an end-entity certificate and so does 2. They differ, as you say, on > what the receiving party does on that data. Why bother? How would a > server operator ever know what the receiving party will do on the data? This is a protocol. It defines what both parties do -- not just one party. Two parties interoperate in a protocol when BOTH implement it correctly. The whole reason for the "duplication" in certificate usages is to protect the business models of the CA operators. For 98% of web sites, there is no real need for usage 0 or 1 or 2. Just use 3 and the DNS will let your TLS application know that it can trust the public key that the TLS server provides. Indeed, the CA companies tried to kill off usage 3 -- and succeeded to the extent that you have to read between the lines of a complicated RFC to figure out that you don't need the CAs anymore. You can continue to pay a CA for your TLS server's cert, so that clients who don't implement DANE can still access your server with the same security that you and they had last year. But any client that does implement DANE will just use your "usage 3" TLSA record, will ignore the CAs, and will have higher security. But the CA companies can say, "Use DANE with our certificates" and still sucker a bunch of businesses into paying them $$$$$ that they don't need to pay, for security that isn't really there. And indeed DANE does provide a way to improve the security of the CA model, by limiting the number of CAs who can betray you, from hundreds down to one. Of course, if you use DANE with usage model 3, NONE of the CAs can betray you to a DANE client -- but they won't tell you that. By the way, you're confused about which cert usage numbers do what. The TLS server always sends the client a chain of certs, containing at least one cert. The client only has to pay attention to the first of those, which is the "end-entity" cert for this TLS server. The rest are "hints" about how the client might determine whether to trust that "end-entity" (TLS server's) cert. Unfortunately the process that the client goes through is undocumented and unstandardized and will remain so for business reasons (different clients do it differently and none of them wants to be declared non-compliant). They all rely on "trust anchors" which are keys that are inherently trusted by that particular client, usually because those keys were installed automatically along with its OS or along with its browser. DANE provides three ways to *modify* that undocumented process, and one way to bypass it completely: 0 = I'm telling you one of the PKIX CA certs (or its key) 1 = I'm telling you the PKIX end-endity cert (or its key) 2 = I'm giving you a PKIX cert that provides a new trust anchor (or a key of one that the server sent in its chain) 3 = I'm telling you the non-PKIX key or cert of this TLS server. 3 is the complete bypass of the PKIX hierarchy of certs. 0,1,2 all use the PKIX certs and require that the TLS connection fail if the undocumented PKIX client processing says "insecure". They also require that the TLS connection fail if PKIX says "secure" but its ultimate trust-chain doesn't match any cert or key that DANE provides. (That's DANE protecting you from corrupt CAs.) Normally, usage 2 does NOT use an end-entity cert. There's a way to bastardize usage 2 by providing the end-entity cert or key as the "trust anchor", but that's just a slow way to do usage 3, so there's no point to it. What it's really for is to provide a CA "trust anchor" certificate that you don't expect clients to already trust. For example, IBM might run its own CA for all its internal machines, and could provide this CA's trust anchor cert in its internal DNS with DANE usage 2, rather than having to reconfigure every machine in its network to add a trust anchor manually. John Gilmore From n.mavrogiannopoulos@gmail.com Tue Oct 9 00:04:44 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3F821F8810 for ; Tue, 9 Oct 2012 00:04:44 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AYhBbX7Oh2ZS for ; Tue, 9 Oct 2012 00:04:43 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 807B121F8750 for ; Tue, 9 Oct 2012 00:04:42 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so12599447iec.31 for ; Tue, 09 Oct 2012 00:04:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=FMZMbAFAgA90uV8/9dM1h2PF5/TrMXksb8+qi7h43Tw=; b=fEJc1KVL/Geh19ut4nw7G6ldU2ca5UswOjGis5IuV9FGCRd+CVWtgMrgqEDOPKsDbZ ZsMlsNgGoGVkifd7UtjdeYiIBhw/BgOaqpoI/O7RJm7dI2912S+p925S5+pAeSvVFPYN KETNoSos6KuxX29rKC4bHl2n7FWwSRI92Hhhvf6pYO+pIwDeg2UxDq1VUfaZOmCSAvWm cSNgVfHXMHXRNSmR1fYIPusqBCgQWA+PjIUd++STg/m6I6Kmd5YlVQqo/I4kPeYxUw8p 6wCcf+M3AjWJWkFtA2iwItNBxGuIrLgGVeDz5obMwi6SGz6qFhTLa0Gm94JrN//TZe3/ xSgw== MIME-Version: 1.0 Received: by 10.50.152.137 with SMTP id uy9mr701017igb.62.1349766278403; Tue, 09 Oct 2012 00:04:38 -0700 (PDT) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.64.127.39 with HTTP; Tue, 9 Oct 2012 00:04:38 -0700 (PDT) In-Reply-To: <201210090139.q991dsk7020839@new.toad.com> References: <506FF6DD.9020902@gnutls.org> <20121006130325.GA2926@LK-Perkele-VI.localdomain> <5071298E.9020602@gnutls.org> <201210090139.q991dsk7020839@new.toad.com> Date: Tue, 9 Oct 2012 09:04:38 +0200 X-Google-Sender-Auth: v2FNmsFTHcGBWWu5hdAcayre8rA Message-ID: From: Nikos Mavrogiannopoulos To: John Gilmore Content-Type: text/plain; charset=UTF-8 Cc: dane@ietf.org Subject: Re: [dane] an implementor's comments on 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: Tue, 09 Oct 2012 07:04:44 -0000 On Tue, Oct 9, 2012 at 3:39 AM, John Gilmore wrote: >> Well, my point is that they transfer exactly the same data. 0 transfers >> an end-entity certificate and so does 2. They differ, as you say, on >> what the receiving party does on that data. Why bother? How would a >> server operator ever know what the receiving party will do on the data? > This is a protocol. It defines what both parties do -- not just > one party. Two parties interoperate in a protocol when BOTH implement > it correctly. Indeed, but DANE is not a verification protocol. It defines (or should define) a _part_ of a verification protocol. And this should be because DANE can be used in many more scenarios than the typical web browser HTTPS scenario which is implied all over the document. The "PKIX certification path validation" that is mentioned in the document happens (or not) in those browsers irrespective of DANE, so there is no point for DANE to mandate it. What DANE provides is an alternative method to this path verification. It can be used in addition to path verification or instead of it. The server operator shouldn't care or bother how each client would use it (eg. by specifying usage 1 or 3). He should only specify the key of its server. > The whole reason for the "duplication" in certificate usages is to > protect the business models of the CA operators. For 98% of web > sites, there is no real need for usage 0 or 1 or 2. Ok thanks for providing some context. The reason of the bloat in the usage field is now apparent. best regards, Nikos From matt@mattmccutchen.net Tue Oct 9 01:07:43 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5947621F8814 for ; Tue, 9 Oct 2012 01:07:43 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0aHbQWpbKoP for ; Tue, 9 Oct 2012 01:07:42 -0700 (PDT) Received: from homiemail-a6.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 8E34C21F8810 for ; Tue, 9 Oct 2012 01:07:42 -0700 (PDT) Received: from homiemail-a6.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTP id 24909598070; Tue, 9 Oct 2012 01:07:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=message-id :subject:from:to:cc:date:in-reply-to:references:content-type :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=MNg+6rSAWQJsUUOfM1cGRZn9hsC3ee5tTFBjryIQEYi iYFzQ1+CAtOZVEZlV6sR923Lb4iz23t4Yj1Xf442rCYFrohiK9WUOS6v7PpVlZO1 jIGtgzyaH20EQ6k8OnDjmTiQyoITSjxM2pyCK/ev8oq3pLJxXn8ywqX81z7qFqg8 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= message-id:subject:from:to:cc:date:in-reply-to:references :content-type:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=dtjRuI2URBl5hZXafl4xuEX2aEQ=; b=DW+/L6fpvR ZrPfESZM6ZaCNK6XOnHiFUgXZUb2T2itTdVbtBQLlWFmfeegjZ3NRqp/wSfrXNDE d0nAJbvMfqNMbN0spf+03c3bghRbBko+cvJdsqNkq2Eo++L6GilNnLhrwX9HavnD aUQMh95nNq9eHkb9D05Tmm6pJaKyyJ7bU= Received: from [IPv6:::1] (c-98-248-34-40.hsd1.ca.comcast.net [98.248.34.40]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTPSA id DA12559806B; Tue, 9 Oct 2012 01:07:41 -0700 (PDT) Message-ID: <1349770061.3438.20.camel@localhost> From: Matt McCutchen To: Nikos Mavrogiannopoulos Date: Tue, 09 Oct 2012 01:07:41 -0700 In-Reply-To: References: <506FF6DD.9020902@gnutls.org> <20121006130325.GA2926@LK-Perkele-VI.localdomain> <5071298E.9020602@gnutls.org> <201210090139.q991dsk7020839@new.toad.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: dane@ietf.org Subject: Re: [dane] an implementor's comments on 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: Tue, 09 Oct 2012 08:07:43 -0000 On Tue, 2012-10-09 at 09:04 +0200, Nikos Mavrogiannopoulos wrote: > On Tue, Oct 9, 2012 at 3:39 AM, John Gilmore wrote: > > >> Well, my point is that they transfer exactly the same data. 0 transfers > >> an end-entity certificate and so does 2. They differ, as you say, on > >> what the receiving party does on that data. Why bother? How would a > >> server operator ever know what the receiving party will do on the data? > > This is a protocol. It defines what both parties do -- not just > > one party. Two parties interoperate in a protocol when BOTH implement > > it correctly. > > Indeed, but DANE is not a verification protocol. It defines (or should > define) a _part_ of a verification protocol. And this should be > because DANE can be used in many more scenarios than the typical web > browser HTTPS scenario which is implied all over the document. The > "PKIX certification path validation" that is mentioned in the document > happens (or not) in those browsers irrespective of DANE, so there is > no point for DANE to mandate it. What DANE provides is an alternative > method to this path verification. It can be used in addition to path > verification or instead of it. The server operator shouldn't care or > bother how each client would use it (eg. by specifying usage 1 or 3). > He should only specify the key of its server. This is awfully late to raise an objection. I believe the argument for the current design was that a server operator may care: he may want a revocation via the CA to be effective on DANE clients without having to also pull the certificate from the DNS, particularly if he has to revoke via the CA anyway for the benefit of non-DANE clients. To ensure this, he has to use usage 1 rather than 3. (Or for an intermediate certificate, usage 0 rather than 2 for revocations at or above the intermediate certificate to be effective. Revocations below the intermediate certificate break the chain from the server certificate to the RR, so they are effective under either usage.) -- Matt From hallam@gmail.com Tue Oct 9 05:14:58 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 643271F0C59 for ; Tue, 9 Oct 2012 05:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.886 X-Spam-Level: X-Spam-Status: No, score=-3.886 tagged_above=-999 required=5 tests=[AWL=-0.288, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjvefleJRwfD for ; Tue, 9 Oct 2012 05:14:57 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id E5BC921F8869 for ; Tue, 9 Oct 2012 05:14:56 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n5so1435992oag.31 for ; Tue, 09 Oct 2012 05:14:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mpftmuty84wdGo6d/Utp+qKJZAnh2zJZLtcfLOuVt2s=; b=Tst9MRhAIuWJJqTW5yeDCDTJSS0k9fEWKrlCVK3yiHhdg9ddK7y0dz8gKZPHwUZOIi WJlMv2UPZ37Sh8Cy67Tht8FgCj65R1WakanlcVF3EgWo8Aja2BmrwvknneYG2zuv6wr4 UAMIO6AWFRn9txt0DVXJVU8H+RyNe/QgCBXZm/dC8YSZ3zaed5iAC3oTCXi0AIzDMK6P 9uvKAPsJ79oPP0dDBrP9iFmOCf0mMDfYOssIx41Lrm//xTlrXkJWNTAx0dSB6/LqurmA wTDwLwcVmTAU+EklRJJDKNkSXdlsg5vSnskagCY3yVMlIzFeCAkf7Z89WBh4OWy9GpzI qBcQ== MIME-Version: 1.0 Received: by 10.182.95.205 with SMTP id dm13mr2674252obb.9.1349784896219; Tue, 09 Oct 2012 05:14:56 -0700 (PDT) Received: by 10.76.27.103 with HTTP; Tue, 9 Oct 2012 05:14:56 -0700 (PDT) In-Reply-To: <201210090139.q991dsk7020839@new.toad.com> References: <506FF6DD.9020902@gnutls.org> <20121006130325.GA2926@LK-Perkele-VI.localdomain> <5071298E.9020602@gnutls.org> <201210090139.q991dsk7020839@new.toad.com> Date: Tue, 9 Oct 2012 13:14:56 +0100 Message-ID: From: Phillip Hallam-Baker To: John Gilmore Content-Type: multipart/alternative; boundary=14dae93b63204328db04cb9f49c3 Cc: Nikos Mavrogiannopoulos , dane@ietf.org Subject: Re: [dane] an implementor's comments on 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: Tue, 09 Oct 2012 12:14:58 -0000 --14dae93b63204328db04cb9f49c3 Content-Type: text/plain; charset=ISO-8859-1 John, Your model for why people buy certs is completely wrong. The biggest cost in providing SSL certs is training the customer how to use and deploy them. An SSL cert is a heck of a lot cheaper than a course on PKI. The typical cost of training is $800 per person per day. How many days does it take to know enough crypto for it to be more good than harm? Probably more than one. DNSSEC deployment is far, far beyond the capabilities of the average Internet user. It is also far beyond the capabilities of the typical ISP. We both have more than twenty years experience using this stuff and neither of us is signing our emails, that should say something about the technology. Attacking the service industry that supports crypto does nothing to advance the cause of making crypto ubiquitous, quite the reverse. Those DNS registrars that you hope are going to provide free crypto to the masses are what CAs call their sales channel. Selling DNS names is not a profitable business, most are sold at a loss in order to acquire customers that the registrar then monetizes though sales of added value services, in particular SSL certificates. >From a security point of view, I think the whole approach taken in DANE is wrong. It regards security policy statement as commands from the server to the client rather than as evidence that a client MAY chose to evaluate in making a security decision. No client is going to interpret the DANE MUSTs as mandates no matter how hard people stamp their feet. The client providers refuse to deploy software that hardfails on OCSP status requests despite a considerably cleaner path to the client than is available in the DNS world. On Tue, Oct 9, 2012 at 2:39 AM, John Gilmore wrote: > > At least 3 host names in the list of DANE test sites do not use DNSSEC. > > http://www.internetsociety.org/deploy360/resources/dane-test-sites/ > > Then it's a good thing that we're testing that case, isn't it? :-) > DANE implementations should refuse to connect to those test sites, > which don't have DNSSEC signatures all the way back to the root key. > (The fact that DANE should fail with them should be mentioned in that > page tho.) > > > >> Certificate usage 0 is exactly the same as 2, and usage 1 is the same > as > > >> 3. The difference is that if my certificate is signed by a CA I use 1, > > > > Well, my point is that they transfer exactly the same data. 0 transfers > > an end-entity certificate and so does 2. They differ, as you say, on > > what the receiving party does on that data. Why bother? How would a > > server operator ever know what the receiving party will do on the data? > > This is a protocol. It defines what both parties do -- not just > one party. Two parties interoperate in a protocol when BOTH implement > it correctly. > > The whole reason for the "duplication" in certificate usages is to > protect the business models of the CA operators. For 98% of web > sites, there is no real need for usage 0 or 1 or 2. Just use 3 and > the DNS will let your TLS application know that it can trust the > public key that the TLS server provides. Indeed, the CA companies > tried to kill off usage 3 -- and succeeded to the extent that you have > to read between the lines of a complicated RFC to figure out that you > don't need the CAs anymore. > > You can continue to pay a CA for your TLS server's cert, so that > clients who don't implement DANE can still access your server with the > same security that you and they had last year. But any client that > does implement DANE will just use your "usage 3" TLSA record, will > ignore the CAs, and will have higher security. > > But the CA companies can say, "Use DANE with our certificates" and > still sucker a bunch of businesses into paying them $$$$$ that they > don't need to pay, for security that isn't really there. And indeed > DANE does provide a way to improve the security of the CA model, by > limiting the number of CAs who can betray you, from hundreds down to > one. Of course, if you use DANE with usage model 3, NONE of the CAs > can betray you to a DANE client -- but they won't tell you that. > > By the way, you're confused about which cert usage numbers do what. > The TLS server always sends the client a chain of certs, containing at > least one cert. The client only has to pay attention to the first of > those, which is the "end-entity" cert for this TLS server. The rest > are "hints" about how the client might determine whether to trust that > "end-entity" (TLS server's) cert. Unfortunately the process that the > client goes through is undocumented and unstandardized and will remain > so for business reasons (different clients do it differently and none > of them wants to be declared non-compliant). They all rely on "trust > anchors" which are keys that are inherently trusted by that particular > client, usually because those keys were installed automatically along > with its OS or along with its browser. DANE provides three ways to > *modify* that undocumented process, and one way to bypass it > completely: > > 0 = I'm telling you one of the PKIX CA certs (or its key) > 1 = I'm telling you the PKIX end-endity cert (or its key) > 2 = I'm giving you a PKIX cert that provides a new trust anchor (or > a key of one that the server sent in its chain) > 3 = I'm telling you the non-PKIX key or cert of this TLS server. > > 3 is the complete bypass of the PKIX hierarchy of certs. 0,1,2 all > use the PKIX certs and require that the TLS connection fail if the > undocumented PKIX client processing says "insecure". They also require > that the TLS connection fail if PKIX says "secure" but its ultimate > trust-chain doesn't match any cert or key that DANE provides. (That's > DANE protecting you from corrupt CAs.) > > Normally, usage 2 does NOT use an end-entity cert. There's a way to > bastardize usage 2 by providing the end-entity cert or key as the > "trust anchor", but that's just a slow way to do usage 3, so there's > no point to it. What it's really for is to provide a CA "trust > anchor" certificate that you don't expect clients to already trust. > For example, IBM might run its own CA for all its internal machines, > and could provide this CA's trust anchor cert in its internal DNS with > DANE usage 2, rather than having to reconfigure every machine in its > network to add a trust anchor manually. > > John Gilmore > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > -- Website: http://hallambaker.com/ --14dae93b63204328db04cb9f49c3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable John,

Your model for why people buy certs is completely = wrong.

The biggest cost in providing SSL certs is = training the customer how to use and deploy them. An SSL cert is a heck of = a lot cheaper than a course on PKI. The typical cost of training is $800 pe= r person per day. How many days does it take to know enough crypto for it t= o be more good than harm? Probably more than one.

DNSSEC deployment is far, far beyond the capabilities o= f the average Internet user. It is also far beyond the capabilities of the = typical ISP. We both have more than twenty years experience using this stuf= f and neither of us is signing our emails, that should say something about = the technology. Attacking the service industry that supports crypto does no= thing to advance the cause of making crypto ubiquitous, quite the reverse.<= /div>

Those DNS registrars that you hope are going to provide= free crypto to the masses are what CAs call their sales channel. Selling D= NS names is not a profitable business, most are sold at a loss in order to = acquire customers that the registrar then monetizes though sales of added v= alue services, in particular SSL certificates.


From a security point of view, I think t= he whole approach taken in DANE is wrong. It regards security policy statem= ent as commands from the server to the client rather than as evidence that = a client MAY chose to evaluate in making a security decision.=A0

No client is going to interpret the DANE MUSTs as manda= tes no matter how hard people stamp their feet. The client providers refuse= to deploy software that hardfails on OCSP status requests despite a consid= erably cleaner path to the client than is available in the DNS world.




On Tu= e, Oct 9, 2012 at 2:39 AM, John Gilmore <gnu@toad.com> wrote:
=
> At least 3 host names in the list of DANE test sites= do not use DNSSEC.
> http://www.internetsociety.org/deploy360/resour= ces/dane-test-sites/

Then it's a good thing that we're testing that case, isn'= t it? =A0:-)
DANE implementations should refuse to connect to those test sites,
which don't have DNSSEC signatures all the way back to the root key. (The fact that DANE should fail with them should be mentioned in that
page tho.)

> >> Certificate usage 0 is exactly the same as 2, and usage 1 is = the same as
> >> 3. The difference is that if my certificate is signed by a CA= I use 1,
>
> Well, my point is that they transfer exactly t= he same data. 0 transfers
> an end-entity certificate and so does 2. They differ, as you say, on > what the receiving party does on that data. Why bother? How would a > server operator ever know what the receiving party will do on the data= ?

This is a protocol. =A0It defines what both parties do -- not just one party. =A0Two parties interoperate in a protocol when BOTH implement it correctly.

The whole reason for the "duplication" in certificate usages is t= o
protect the business models of the CA operators. =A0For 98% of web
sites, there is no real need for usage 0 or 1 or 2. =A0Just use 3 and
the DNS will let your TLS application know that it can trust the
public key that the TLS server provides. =A0Indeed, the CA companies
tried to kill off usage 3 -- and succeeded to the extent that you have
to read between the lines of a complicated RFC to figure out that you
don't need the CAs anymore.

You can continue to pay a CA for your TLS server's cert, so that
clients who don't implement DANE can still access your server with the<= br> same security that you and they had last year. =A0But any client that
does implement DANE will just use your "usage 3" TLSA record, wil= l
ignore the CAs, and will have higher security.

But the CA companies can say, "Use DANE with our certificates" an= d
still sucker a bunch of businesses into paying them $$$$$ that they
don't need to pay, for security that isn't really there. =A0And ind= eed
DANE does provide a way to improve the security of the CA model, by
limiting the number of CAs who can betray you, from hundreds down to
one. =A0Of course, if you use DANE with usage model 3, NONE of the CAs
can betray you to a DANE client -- but they won't tell you that.

By the way, you're confused about which cert usage numbers do what.
The TLS server always sends the client a chain of certs, containing at
least one cert. =A0The client only has to pay attention to the first of
those, which is the "end-entity" cert for this TLS server. =A0The= rest
are "hints" about how the client might determine whether to trust= that
"end-entity" (TLS server's) cert. =A0Unfortunately the proces= s that the
client goes through is undocumented and unstandardized and will remain
so for business reasons (different clients do it differently and none
of them wants to be declared non-compliant). =A0They all rely on "trus= t
anchors" which are keys that are inherently trusted by that particular=
client, usually because those keys were installed automatically along
with its OS or along with its browser. =A0DANE provides three ways to
*modify* that undocumented process, and one way to bypass it
completely:

=A0 0 =3D I'm telling you one of the PKIX CA certs (or its key)
=A0 1 =3D I'm telling you the PKIX end-endity cert (or its key)
=A0 2 =3D I'm giving you a PKIX cert that provides a new trust anchor (= or
=A0 =A0 =A0 a key of one that the server sent in its chain)
=A0 3 =3D I'm telling you the non-PKIX key or cert of this TLS server.<= br>
3 is the complete bypass of the PKIX hierarchy of certs. =A00,1,2 all
use the PKIX certs and require that the TLS connection fail if the
undocumented PKIX client processing says "insecure". =A0They also= require
that the TLS connection fail if PKIX says "secure" but its ultima= te
trust-chain doesn't match any cert or key that DANE provides. =A0(That&= #39;s
DANE protecting you from corrupt CAs.)

Normally, usage 2 does NOT use an end-entity cert. =A0There's a way to<= br> bastardize usage 2 by providing the end-entity cert or key as the
"trust anchor", but that's just a slow way to do usage 3, so = there's
no point to it. =A0What it's really for is to provide a CA "trust<= br> anchor" certificate that you don't expect clients to already trust= .
For example, IBM might run its own CA for all its internal machines,
and could provide this CA's trust anchor cert in its internal DNS with<= br> DANE usage 2, rather than having to reconfigure every machine in its
network to add a trust anchor manually.

=A0 =A0 =A0 =A0 John Gilmore

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



--
= Website: http://hallambaker.com/
--14dae93b63204328db04cb9f49c3-- From paul@cypherpunks.ca Tue Oct 9 07:50:42 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3C491F0C8C for ; Tue, 9 Oct 2012 07:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.08 X-Spam-Level: X-Spam-Status: No, score=-2.08 tagged_above=-999 required=5 tests=[AWL=0.519, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rd6aFk6z2HPl for ; Tue, 9 Oct 2012 07:50:41 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 723BC1F0C7E for ; Tue, 9 Oct 2012 07:50:41 -0700 (PDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 3148282B21; Tue, 9 Oct 2012 10:50:36 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 2545B82A5B; Tue, 9 Oct 2012 10:50:36 -0400 (EDT) Date: Tue, 9 Oct 2012 10:50:36 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Matt McCutchen In-Reply-To: <1349770061.3438.20.camel@localhost> Message-ID: References: <506FF6DD.9020902@gnutls.org> <20121006130325.GA2926@LK-Perkele-VI.localdomain> <5071298E.9020602@gnutls.org> <201210090139.q991dsk7020839@new.toad.com> <1349770061.3438.20.camel@localhost> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Nikos Mavrogiannopoulos , dane WG list Subject: Re: [dane] an implementor's comments on 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: Tue, 09 Oct 2012 14:50:42 -0000 On Tue, 9 Oct 2012, Matt McCutchen wrote: > This is awfully late to raise an objection. I believe the argument for > the current design was that a server operator may care: he may want a > revocation via the CA to be effective on DANE clients without having to > also pull the certificate from the DNS Why would you _ever_ want to keep a revoked key in the DNS? If the key is revoked, it should not be in use, and therefor should not be in the DNS. While you will still need to revoke the key at the CA, because someone else might have a stolen copy of your private key and not be DANE aware, that's the slow offline process that in no way has to slow down your key update mechanism inside your own DNS tree. Paul From paul@cypherpunks.ca Tue Oct 9 08:09:13 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91A901F0420 for ; Tue, 9 Oct 2012 08:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.383 X-Spam-Level: X-Spam-Status: No, score=-1.383 tagged_above=-999 required=5 tests=[AWL=-0.273, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BG-LSHbc1o1c for ; Tue, 9 Oct 2012 08:09:12 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 766AF21F852E for ; Tue, 9 Oct 2012 08:09:10 -0700 (PDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 69C8D82B21; Tue, 9 Oct 2012 11:09:06 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 5A58F82A5B; Tue, 9 Oct 2012 11:09:06 -0400 (EDT) Date: Tue, 9 Oct 2012 11:09:06 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <506FF6DD.9020902@gnutls.org> <20121006130325.GA2926@LK-Perkele-VI.localdomain> <5071298E.9020602@gnutls.org> <201210090139.q991dsk7020839@new.toad.com> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Cc: Nikos Mavrogiannopoulos , dane WG list Subject: Re: [dane] an implementor's comments on 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: Tue, 09 Oct 2012 15:09:13 -0000 On Tue, 9 Oct 2012, Phillip Hallam-Baker wrote: > Your model for why people buy certs is completely wrong. > > The biggest cost in providing SSL certs is training the customer how to use and deploy them. I could not have summarized the failure of the CA industry better. If they had made $5 certs for everyone, we would have never seen the explosion in people using unvalidatable self-signed certificates. DANE is indeed a method where obtaining the validation is totally free, and it does not raise the bar for any non-enterprise that cannot afford a training budget. > An SSL cert is a heck of a lot cheaper than a course on PKI. The fact that one would need a course on PKI to secure one's webserver is a pretty bad failure of the security industry. We're paying the price now (and offloading that mostly to the browser vendors to fixup in gui elements) > The typical cost of training is $800 per person per day. How many days does it take to know enough crypto for it to be more good > than harm? Probably more than one. I would cost me $800 to go on a locksmith course for one day, yet I can easilly buy a lock or cylinder and install it myself. All one needs is knowledge of a generic tool such as a screw driver. Another example would be getting my drivers license, which was far cheaper then the price of my car. > DNSSEC deployment is far, far beyond the capabilities of the average Internet user. Funny, because these days signing your zone takes 4 commands you don't have to understand, and one more website visit to get your DS published. (Willing to give a 5 minute / 2 slide training at ICANN Toronto for less then $800) > We both have more than twenty years experience using this stuff and neither of us is signing our emails, that should say something about the > technology. no it says something about the value of signed emails. A few months ago I had to use SMIME for the first time ever. With thunderbird this took me about an hour (most time wasted on a website's interface for validating my generated cert). It also took one person to spend a little more time, and writing up a simple step by step manual. It did not take a full day course (nor knowledge of crypto - anything more then "red wax dot means your software signed the email" > Those DNS registrars that you hope are going to provide free crypto to the masses are what CAs call their sales channel. Selling DNS names is > not a profitable business, most are sold at a loss in order to acquire customers that the registrar then monetizes though sales of added value > services, in particular SSL certificates. If only they had started to give away free SSL certs 10 years ago, and perhaps by now port 443 would be the default instead of port 80. Forgive me for not having much sympathy for the CAs economic struggles. > From a security point of view, I think the whole approach taken in DANE is wrong. It regards security policy statement as commands from the > server to the client rather than as evidence that a client MAY chose to evaluate in making a security decision. > > No client is going to interpret the DANE MUSTs as mandates no matter how hard people stamp their feet. The client providers refuse to deploy > software that hardfails on OCSP status requests despite a considerably cleaner path to the client than is available in the DNS world. That could be said for any MUST in any Security Considerations RFC section. We set out to write what's best. If local policy dictates shooting yourself in the foot, we can at best help you not pull the trigger again. Paul From daniel.piggott@switch2it.co.uk Tue Oct 9 12:12:38 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A84AA11E813A for ; Tue, 9 Oct 2012 12:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.115 X-Spam-Level: * X-Spam-Status: No, score=1.115 tagged_above=-999 required=5 tests=[AWL=0.776, BAYES_05=-1.11, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RfoNrzIxRZ9r for ; Tue, 9 Oct 2012 12:12:38 -0700 (PDT) Received: from mail50.extendcp.co.uk (mail50.extendcp.co.uk [79.170.44.50]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4FF11E812B for ; Tue, 9 Oct 2012 12:12:34 -0700 (PDT) Received: from switchtx.gotadsl.co.uk ([62.3.238.89] helo=88181134W) by mail50.extendcp.com with esmtpa (Exim 4.77) id 1TLfEG-0001l9-62 for dane@ietf.org; Tue, 09 Oct 2012 20:12:32 +0100 From: "Daniel Piggott" To: References: In-Reply-To: Date: Tue, 9 Oct 2012 20:12:08 +0100 Organization: Switch2IT Ltd Message-ID: <006f01cda651$faa63210$eff29630$@piggott@switch2it.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2mUG4ycrOTQnWMRhqxUieAWh8RtgAADcwQ Content-Language: en-gb X-Authenticated-As: daniel.piggott@switch2it.co.uk Subject: [dane] an implementor's comments on DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: daniel.piggott@switch2it.co.uk List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 19:12:38 -0000 Just stepping back with a commercial third party hat on, can I add a few questions to this debate. If my understanding of DANE is wrong please let me know. I am talking here from the SME perspective. What if a business never handles it's dns but leaves it it's third party IT supplier? What if the host that controls the domain does not support dnssec currently? What if websites are sitting on shared virtual boxes and a reseller cannot make revenue from ssl certificates currently, why would they pursue dane from a commercial perspective? From an technical and security viewpoint I am completely sold on DANE but i see the current real world commercial and technical reality stopping deployment. Daniel On Tue, 9 Oct 2012, Phillip Hallam-Baker wrote: > Your model for why people buy certs is completely wrong. > > The biggest cost in providing SSL certs is training the customer how to use and deploy them. I could not have summarized the failure of the CA industry better. If they had made $5 certs for everyone, we would have never seen the explosion in people using unvalidatable self-signed certificates. DANE is indeed a method where obtaining the validation is totally free, and it does not raise the bar for any non-enterprise that cannot afford a training budget. > An SSL cert is a heck of a lot cheaper than a course on PKI. The fact that one would need a course on PKI to secure one's webserver is a pretty bad failure of the security industry. We're paying the price now (and offloading that mostly to the browser vendors to fixup in gui elements) > The typical cost of training is $800 per person per day. How many days > does it take to know enough crypto for it to be more good than harm? Probably more than one. I would cost me $800 to go on a locksmith course for one day, yet I can easilly buy a lock or cylinder and install it myself. All one needs is knowledge of a generic tool such as a screw driver. Another example would be getting my drivers license, which was far cheaper then the price of my car. > DNSSEC deployment is far, far beyond the capabilities of the average Internet user. Funny, because these days signing your zone takes 4 commands you don't have to understand, and one more website visit to get your DS published. (Willing to give a 5 minute / 2 slide training at ICANN Toronto for less then $800) > We both have more than twenty years experience using this stuff and > neither of us is signing our emails, that should say something about the technology. no it says something about the value of signed emails. A few months ago I had to use SMIME for the first time ever. With thunderbird this took me about an hour (most time wasted on a website's interface for validating my generated cert). It also took one person to spend a little more time, and writing up a simple step by step manual. It did not take a full day course (nor knowledge of crypto - anything more then "red wax dot means your software signed the email" > Those DNS registrars that you hope are going to provide free crypto to > the masses are what CAs call their sales channel. Selling DNS names is > not a profitable business, most are sold at a loss in order to acquire customers that the registrar then monetizes though sales of added value services, in particular SSL certificates. If only they had started to give away free SSL certs 10 years ago, and perhaps by now port 443 would be the default instead of port 80. Forgive me for not having much sympathy for the CAs economic struggles. > From a security point of view, I think the whole approach taken in > DANE is wrong. It regards security policy statement as commands from the server to the client rather than as evidence that a client MAY chose to evaluate in making a security decision. > > No client is going to interpret the DANE MUSTs as mandates no matter > how hard people stamp their feet. The client providers refuse to deploy software that hardfails on OCSP status requests despite a considerably cleaner path to the client than is available in the DNS world. That could be said for any MUST in any Security Considerations RFC section. We set out to write what's best. If local policy dictates shooting yourself in the foot, we can at best help you not pull the trigger again. Paul From mlarson@verisign.com Tue Oct 9 13:25:03 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A09B221F86FD for ; Tue, 9 Oct 2012 13:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.932 X-Spam-Level: X-Spam-Status: No, score=-6.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8QjagaKPTtL for ; Tue, 9 Oct 2012 13:25:03 -0700 (PDT) Received: from exprod6og112.obsmtp.com (exprod6og112.obsmtp.com [64.18.1.29]) by ietfa.amsl.com (Postfix) with ESMTP id A5F3F21F86F8 for ; Tue, 9 Oct 2012 13:25:02 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob112.postini.com ([64.18.5.12]) with SMTP ID DSNKUHSIGpcVkisWe0asbe1b52Ha1nakPz4A@postini.com; Tue, 09 Oct 2012 13:25:02 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q99KOwZ3020971 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 9 Oct 2012 16:24:58 -0400 Received: from BRN1WNEXMBX02.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0318.001; Tue, 9 Oct 2012 16:24:58 -0400 From: "Larson, Matt" To: "dane@ietf.org" Thread-Topic: [dane] DANE test sites Thread-Index: AQHNoUcbqOTGlLFZkky+9ZRYJ+JjGZexuMyA Date: Tue, 9 Oct 2012 20:24:57 +0000 Message-ID: <637D346676F2314FBDE3AEE58CF45CF00DCC73CA@BRN1WNEXMBX02.vcorp.ad.vrsn.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <29CD86F1B6D15248BBABA73517A173A2@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Wessels, Duane" Subject: Re: [dane] DANE test sites X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Oct 2012 20:25:03 -0000 On Oct 3, 2012, at 5:11 AM, Nikos Mavrogiannopoulos wrote: > Are there any test or even real world https sites that support DANE? Please see http://dane.verisignlabs.com for various kinds of working and br= oken examples. (Thanks to Duane Wessels, who also gave the world http://te= st.dnssec-or-not.net :-) ) Matt From marka@isc.org Tue Oct 9 16:29:39 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A862D11E80ED for ; Tue, 9 Oct 2012 16:29: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id grMzNZEjdI09 for ; Tue, 9 Oct 2012 16:29:38 -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 7831811E80EC for ; Tue, 9 Oct 2012 16:29:38 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 04EC8C9553; Tue, 9 Oct 2012 23:29:31 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:9f3:121d:449:3cf4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 92D98216C89; Tue, 9 Oct 2012 23:29:30 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id C51AF298DBB0; Wed, 10 Oct 2012 10:29:24 +1100 (EST) To: daniel.piggott@switch2it.co.uk From: Mark Andrews References: <006f01cda651$faa63210$eff29630$@piggott@switch2it.co.uk> In-reply-to: Your message of "Tue, 09 Oct 2012 20:12:08 BST." <006f01cda651$faa63210$eff29630$@piggott@switch2it.co.uk> Date: Wed, 10 Oct 2012 10:29:24 +1100 Message-Id: <20121009232924.C51AF298DBB0@drugs.dv.isc.org> Cc: dane@ietf.org Subject: Re: [dane] an implementor's comments on 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: Tue, 09 Oct 2012 23:29:39 -0000 In message <006f01cda651$faa63210$eff29630$@piggott@switch2it.co.uk>, "Daniel P iggott" writes: > Just stepping back with a commercial third party hat on, can I add a few > questions to this debate. If my understanding of DANE is wrong please let me > know. I am talking here from the SME perspective. What if a business never > handles it's dns but leaves it it's third party IT supplier? Perfectly do able. You just pass them the TLSA record to be added to the zone or you pass them the CERT and tell them to generate the TLSA record for it. CERT to TLSA is a mechanical processs. The only thing addition is what type of TLSA you are going to generate and for that you have a choice of 1 of 4 values. This really is no different to passing them a A record for a server. > What if the host that controls the domain does not support dnssec currently? Ask them to fix their infrastucture or find another company to out source to. Nameserver have supported this for 1/2 a decade now. This is like IPv6. They just need to get off their butts and do it. > What if websites are sitting on shared virtual boxes and a reseller cannot > make revenue from ssl certificates currently, why would they pursue dane > from a commercial perspective? As long as you have a seperate IP addresses (IPv4 and IPv6) for your virtual machine you just need to add the CERT to the server's config. This is no different on the server side to traditional CA derived CERTs. If the provider can install a CA derived CERT they can install a self generated CERT. > From an technical and security viewpoint I am completely sold on DANE but > i see the current real world commercial and technical reality stopping > deployment. Daniel This stuff isn't rocket science. It's the client side that need extensions to be able to validate. The server side is "same old same old". Mark > On Tue, 9 Oct 2012, Phillip Hallam-Baker wrote: > > > Your model for why people buy certs is completely wrong. > > > > The biggest cost in providing SSL certs is training the customer how to > use and deploy them. > > I could not have summarized the failure of the CA industry better. > > If they had made $5 certs for everyone, we would have never seen the > explosion in people using unvalidatable self-signed certificates. > > DANE is indeed a method where obtaining the validation is totally free, and > it does not raise the bar for any non-enterprise that cannot afford a > training budget. > > > An SSL cert is a heck of a lot cheaper than a course on PKI. > > The fact that one would need a course on PKI to secure one's webserver is a > pretty bad failure of the security industry. We're paying the price now (and > offloading that mostly to the browser vendors to fixup in gui > elements) > > > The typical cost of training is $800 per person per day. How many days > > does it take to know enough crypto for it to be more good than harm? > Probably more than one. > > I would cost me $800 to go on a locksmith course for one day, yet I can > easilly buy a lock or cylinder and install it myself. All one needs is > knowledge of a generic tool such as a screw driver. Another example would > be getting my drivers license, which was far cheaper then the price of my > car. > > > DNSSEC deployment is far, far beyond the capabilities of the average > Internet user. > > Funny, because these days signing your zone takes 4 commands you don't have > to understand, and one more website visit to get your DS published. > > (Willing to give a 5 minute / 2 slide training at ICANN Toronto for less > then $800) > > > We both have more than twenty years experience using this stuff and > > neither of us is signing our emails, that should say something about the > technology. > > no it says something about the value of signed emails. A few months ago I > had to use SMIME for the first time ever. With thunderbird this took me > about an hour (most time wasted on a website's interface for validating my > generated cert). It also took one person to spend a little more time, and > writing up a simple step by step manual. It did not take a full day course > (nor knowledge of crypto - anything more then "red wax dot means your > software signed the email" > > > Those DNS registrars that you hope are going to provide free crypto to > > the masses are what CAs call their sales channel. Selling DNS names is > > not a profitable business, most are sold at a loss in order to acquire > customers that the registrar then monetizes though sales of added value > services, in particular SSL certificates. > > If only they had started to give away free SSL certs 10 years ago, and > perhaps by now port 443 would be the default instead of port 80. Forgive me > for not having much sympathy for the CAs economic struggles. > > > From a security point of view, I think the whole approach taken in > > DANE is wrong. It regards security policy statement as commands from the > server to the client rather than as evidence that a client MAY chose to > evaluate in making a security decision. > > > > No client is going to interpret the DANE MUSTs as mandates no matter > > how hard people stamp their feet. The client providers refuse to deploy > software that hardfails on OCSP status requests despite a considerably > cleaner path to the client than is available in the DNS world. > > That could be said for any MUST in any Security Considerations RFC section. > We set out to write what's best. If local policy dictates shooting yourself > in the foot, we can at best help you not pull the trigger again. > > Paul > > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From gnu@toad.com Wed Oct 10 01:24:56 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB3621F87B4 for ; Wed, 10 Oct 2012 01:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2 X-Spam-Level: ** X-Spam-Status: No, score=2 tagged_above=-999 required=5 tests=[AWL=-0.697, BAYES_50=0.001, RCVD_IN_NJABL_RELAY=2.696] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GrjhwKfJIxf5 for ; Wed, 10 Oct 2012 01:24:55 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id 3852521F87B3 for ; Wed, 10 Oct 2012 01:24:54 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id q9A8Okk7026428; Wed, 10 Oct 2012 01:24:46 -0700 Message-Id: <201210100824.q9A8Okk7026428@new.toad.com> To: Phillip Hallam-Baker In-reply-to: References: <506FF6DD.9020902@gnutls.org> <20121006130325.GA2926@LK-Perkele-VI.localdomain> <5071298E.9020602@gnutls.org> <201210090139.q991dsk7020839@new.toad.com> Comments: In-reply-to Phillip Hallam-Baker message dated "Tue, 09 Oct 2012 13:14:56 +0100." Date: Wed, 10 Oct 2012 01:24:46 -0700 From: John Gilmore Cc: Nikos Mavrogiannopoulos , dane@ietf.org Subject: Re: [dane] an implementor's comments on 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, 10 Oct 2012 08:24:56 -0000 > Selling DNS names is not a profitable business... There's no need to pick apart Phillip's message in detail. Let's just pick that one phrase apart, and leave the rest behind. It happens to be something I know something about. I guess everybody wants to "lose money" selling DNS names, since when ICANN offered people the chance to sell names in their own TLD, only 1,930 applications arrived, at a non-refundable $185K apiece, bringing in only $357 million, completely on speculation, long before ICANN would promise them ANYTHING. Even before the gTLD goldrush, ICANN certainly seemed to raise and spend a pile of money selling DNS names. The Internet Society certainly has a *lot* more money since they won the ICANN "lottery" to run the .ORG domain. (I used to be on their board, back when fundraising was a significant issue for them.) I personally started a domain name business (Moniker) and was closely involved in starting up the CORE registry and working out all the details among the CORE registrars, most of whom went on to become ICANN registrars. The costs involved in *providing* domain name service are fixed and trivial compared to most businesses. People are basically buying small numbers of bits on a disk drive from you. The prices are more than a dozen times the total costs. And the costs are spread over a huge volume of registrations, which has been created by domain-name speculators (which of course the registrars/registries have taken pains to encourage). In .COM with 100,000,000 domains, it should cost a few cents a year to handle a domain registration; in other domains, perhaps a dime. And the cost of servers and storage is going... down. See for example: http://www.solorwell.com/ex-icann-board-member-verisigns-cost-per-domain-is-014/ http://web.archive.org/web/20070409034330/http://dev.blog.domaintools.com/2007/04/ex-icann-board-member-says-com-costs-014/ Now it's possible for incompetent or corrupt businesses to waste even a 1200% profit margin -- not to name any names or anything. But if there was actual competition in domain names, they would retail for something like 30c/year rather than $10-20 per year. The incentives of everyone inside the domain business are to keep prices high, not to lower them. Normally, competition would restrict that behavior, but look at what they're selling: monopolies on virtual real estate. The ultimate rulemaker is a corrupt nonprofit monopolist that is accountable to exactly nobody (I know the lawyer who set up its structure; that was their main goal, and they largely succeeded), that sets its own prices. ICANN sets a base price per domain by charging registries 25c per domain, which is already 2x to 20x the actual costs at the registry. 100 million .com's bring ICANN 25 million dollars - every year - for the "service" of having your input ignored by the ICANN insiders. At each level below ICANN, those obscene prices only get multiplied more (e.g. $6+ at VeriSign) -- and oh, they hate it all the way to the bank. John From warren@kumari.net Wed Oct 10 07:53:51 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5352B21F85A3 for ; Wed, 10 Oct 2012 07:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.413 X-Spam-Level: X-Spam-Status: No, score=-101.413 tagged_above=-999 required=5 tests=[AWL=-0.303, BAYES_05=-1.11, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4hhTmTpxhS6 for ; Wed, 10 Oct 2012 07:53:50 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51BEA21F8582 for ; Wed, 10 Oct 2012 07:53:50 -0700 (PDT) Received: from [192.168.1.139] (unknown [66.84.81.102]) by vimes.kumari.net (Postfix) with ESMTPSA id 5318C1B40600; Wed, 10 Oct 2012 10:53:43 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Warren Kumari In-Reply-To: <201210100824.q9A8Okk7026428@new.toad.com> Date: Wed, 10 Oct 2012 10:53:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9391EEEF-806B-46FD-984C-412DF382C456@kumari.net> References: <506FF6DD.9020902@gnutls.org> <20121006130325.GA2926@LK-Perkele-VI.localdomain> <5071298E.9020602@gnutls.org> <201210090139.q991dsk7020839@new.toad.com> <201210100824.q9A8Okk7026428@new.toad.com> To: John Gilmore X-Mailer: Apple Mail (2.1498) Cc: Nikos Mavrogiannopoulos , dane@ietf.org Subject: Re: [dane] an implementor's comments on 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, 10 Oct 2012 14:53:51 -0000 [ Top-post ]=20 =85and we've finally gone sufficiently off-topic that I'm = (unfortunately) going to jump in and ask that we take this elsewhere=85 W On Oct 10, 2012, at 4:24 AM, John Gilmore wrote: >> Selling DNS names is not a profitable business... >=20 > There's no need to pick apart Phillip's message in detail. Let's just > pick that one phrase apart, and leave the rest behind. It happens to > be something I know something about. >=20 > I guess everybody wants to "lose money" selling DNS names, since when > ICANN offered people the chance to sell names in their own TLD, only > 1,930 applications arrived, at a non-refundable $185K apiece, bringing > in only $357 million, completely on speculation, long before ICANN > would promise them ANYTHING. >=20 > Even before the gTLD goldrush, ICANN certainly seemed to raise and > spend a pile of money selling DNS names. The Internet Society > certainly has a *lot* more money since they won the ICANN "lottery" to > run the .ORG domain. (I used to be on their board, back when > fundraising was a significant issue for them.) >=20 > I personally started a domain name business (Moniker) and was closely > involved in starting up the CORE registry and working out all the > details among the CORE registrars, most of whom went on to become > ICANN registrars. The costs involved in *providing* domain name > service are fixed and trivial compared to most businesses. People are > basically buying small numbers of bits on a disk drive from you. The > prices are more than a dozen times the total costs. And the costs are > spread over a huge volume of registrations, which has been created by > domain-name speculators (which of course the registrars/registries > have taken pains to encourage). In .COM with 100,000,000 domains, it > should cost a few cents a year to handle a domain registration; > in other domains, perhaps a dime. And the cost of servers and > storage is going... down. See for example: >=20 > = http://www.solorwell.com/ex-icann-board-member-verisigns-cost-per-domain-i= s-014/ > = http://web.archive.org/web/20070409034330/http://dev.blog.domaintools.com/= 2007/04/ex-icann-board-member-says-com-costs-014/ >=20 > Now it's possible for incompetent or corrupt businesses to waste even > a 1200% profit margin -- not to name any names or anything. But if > there was actual competition in domain names, they would retail for > something like 30c/year rather than $10-20 per year. The incentives > of everyone inside the domain business are to keep prices high, not to > lower them. Normally, competition would restrict that behavior, but > look at what they're selling: monopolies on virtual real estate. The > ultimate rulemaker is a corrupt nonprofit monopolist that is > accountable to exactly nobody (I know the lawyer who set up its > structure; that was their main goal, and they largely succeeded), that > sets its own prices. ICANN sets a base price per domain by charging > registries 25c per domain, which is already 2x to 20x the actual costs > at the registry. 100 million .com's bring ICANN 25 million dollars - > every year - for the "service" of having your input ignored by the > ICANN insiders. At each level below ICANN, those obscene prices only > get multiplied more (e.g. $6+ at VeriSign) -- and oh, they hate it all > the way to the bank. >=20 > John > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 From warren@kumari.net Wed Oct 10 14:22:55 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 073EF11E80A2 for ; Wed, 10 Oct 2012 14:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.119 X-Spam-Level: X-Spam-Status: No, score=-102.119 tagged_above=-999 required=5 tests=[AWL=0.480, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zm93vKc9UKoc for ; Wed, 10 Oct 2012 14:22:54 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1413A11E809A for ; Wed, 10 Oct 2012 14:22:53 -0700 (PDT) Received: from [192.168.1.139] (unknown [66.84.81.102]) by vimes.kumari.net (Postfix) with ESMTPSA id AD20C1B40600; Wed, 10 Oct 2012 17:22:50 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Warren Kumari In-Reply-To: <637D346676F2314FBDE3AEE58CF45CF00DCC73CA@BRN1WNEXMBX02.vcorp.ad.vrsn.com> Date: Wed, 10 Oct 2012 17:22:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3C2CD468-959C-4549-89BE-AC50A383F4BC@kumari.net> References: <637D346676F2314FBDE3AEE58CF45CF00DCC73CA@BRN1WNEXMBX02.vcorp.ad.vrsn.com> To: "Larson, Matt" X-Mailer: Apple Mail (2.1498) Cc: "Wessels, Duane" , "dane@ietf.org" Subject: Re: [dane] DANE test sites X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Oct 2012 21:22:55 -0000 Whoohoo! Thanks DuANE. W On Oct 9, 2012, at 4:24 PM, "Larson, Matt" wrote: >=20 > On Oct 3, 2012, at 5:11 AM, Nikos Mavrogiannopoulos wrote: >=20 >> Are there any test or even real world https sites that support DANE? >=20 > Please see http://dane.verisignlabs.com for various kinds of working = and broken examples. (Thanks to Duane Wessels, who also gave the world = http://test.dnssec-or-not.net :-) ) >=20 > Matt >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 From marc.lampo.ietf@gmail.com Fri Oct 12 00:28:39 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 512E721F8438 for ; Fri, 12 Oct 2012 00:28:39 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQ368rsZ9eNt for ; Fri, 12 Oct 2012 00:28:38 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id BF4DE21F841E for ; Fri, 12 Oct 2012 00:28:38 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id 25so270356qao.10 for ; Fri, 12 Oct 2012 00:28:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Luwi2ig45N6/sSJrbJzqD+bxOevJQsfDOvkVkBsavzM=; b=BztStTsAkz0KggJ/fb/Eh9R5YiCLcr+Q3tG+M7jo9p8s8fUTsC7wcLxLxCJaCxFQht hlHkgUhrnkJ4EPupKI+g66s/tnoQO1PSux3IYr7Rb8gdTqXRZj45xtEKKvvVCkPOmu2k gpxEqN/b/xaMkMCbUX8YqZT33vO9BmVQ/VKORJk/BFBoY3oR7JFBbFzJya31dm0Zov6u GQPFCnZ1539ZpaQcglOB8GteROQ2oLvuRD0f1Tjqd24XpVv56sfxAC6t/Ynp7w88nF61 ++ylmsaGGSuNa84+uYslJgcihuHL2g93e0BnhXjeVjO6WqVg365R5AzV8ggr3+QqTqv7 XxRw== MIME-Version: 1.0 Received: by 10.224.200.196 with SMTP id ex4mr5995390qab.46.1350026915758; Fri, 12 Oct 2012 00:28:35 -0700 (PDT) Received: by 10.49.105.97 with HTTP; Fri, 12 Oct 2012 00:28:35 -0700 (PDT) Date: Fri, 12 Oct 2012 09:28:35 +0200 Message-ID: From: Marc Lampo To: dane@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [dane] + add security ... (was : Re: an implementor's comments on 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, 12 Oct 2012 07:28:39 -0000 Before the draft was adopted as RFC I asked how to cope with proxies. On Sector 2012, last week, I was quite shocked to hear a speaker (also reading this, I assume) to simply state to get rid of them ! I'd rather see continued work on how to make the principle of DANE apply/work even in the presence of proxies. The other security remark is that, in order for the browser to use info in TLSA record, the host needs access to public DNS. (with the use of a proxy, a setup with internal-roots is possible, internal hosts don't need access to public IP addresses if they use proxies) However, TLSA is not "an address", so access to public DNS is needed. But that (access to public DNS) allows for new threats in the area of data leakage !!! One can do file transfer, both in and out of a network, using correct DNS messages, if access to public DNS is available. (as I addressed, when still Security Officer for EURid, on CENTR Security WG meeting in June 2012, in Frankfurt) In summary : Usage of TLSA, in its present form, opens new can of worms. Which can only be kept closed if somehow collaboration of DANE (TLSA) and proxies can be achieved. Regarding DNSSEC : do not forget that adding signatures without verifying them is almost useless. And since *lots* of networks use AD, with its (non DNSSEC capable) DNS servers, only few users actually benefit, at this moment. ("non DNSSEC capable" : since MS DNS does not support a protocol higher than 5, and treats everything higher as "unsigned": + since the root zone uses protocol 8 --> this comes down to "not capable DNSSEC") So, wether or not the TLSA record is coming from a signed domain, most users are not capable of noticing this anyway. Kind regards, Marc Lampo From fanf2@hermes.cam.ac.uk Fri Oct 12 01:45:33 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 110A421F849C for ; Fri, 12 Oct 2012 01:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.416 X-Spam-Level: X-Spam-Status: No, score=-3.416 tagged_above=-999 required=5 tests=[AWL=-2.306, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U85Btq4DUAwl for ; Fri, 12 Oct 2012 01:45:31 -0700 (PDT) Received: from ppsw-43.csi.cam.ac.uk (ppsw-43.csi.cam.ac.uk [131.111.8.143]) by ietfa.amsl.com (Postfix) with ESMTP id 7F49B21F847D for ; Fri, 12 Oct 2012 01:45:31 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:38884) by ppsw-43.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1TMas5-0002On-ny (Exim 4.72) (return-path ); Fri, 12 Oct 2012 09:45:29 +0100 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1TMas5-0005Qk-F9 (Exim 4.72) (return-path ); Fri, 12 Oct 2012 09:45:29 +0100 Date: Fri, 12 Oct 2012 09:45:29 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Marc Lampo In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dane@ietf.org Subject: Re: [dane] + add security ... (was : Re: an implementor's comments on 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, 12 Oct 2012 08:45:33 -0000 Marc Lampo wrote: > Before the draft was adopted as RFC I asked how to cope with proxies. Why are proxies a problem for DANE in particular, rather than TLS in general? Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From nweaver@icsi.berkeley.edu Fri Oct 12 01:57:02 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8B6A21F843E for ; Fri, 12 Oct 2012 01:57: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFPb-OQ4lGNF for ; Fri, 12 Oct 2012 01:57:01 -0700 (PDT) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id D036321F842B for ; Fri, 12 Oct 2012 01:57:01 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id C1AB12C4018; Fri, 12 Oct 2012 01:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ymgoSUKljMae; Fri, 12 Oct 2012 01:57:01 -0700 (PDT) Received: from [10.143.213.190] (unknown [109.144.229.49]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id A92522C400C; Fri, 12 Oct 2012 01:57:00 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: Date: Fri, 12 Oct 2012 09:57:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Tony Finch X-Mailer: Apple Mail (2.1283) Cc: dane@ietf.org Subject: Re: [dane] + add security ... (was : Re: an implementor's comments on 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, 12 Oct 2012 08:57:02 -0000 On Oct 12, 2012, at 9:45 AM, Tony Finch wrote: > Marc Lampo wrote: >=20 >> Before the draft was adopted as RFC I asked how to cope with proxies. >=20 > Why are proxies a problem for DANE in particular, rather than TLS in > general? Because how the proxies work is they add an additional root key into the = (victim) browser during some form of configuration. DANE makes the = injected root key no longer valid. Of course, certificate pinning and other techniques has the same = problem, and IMO, killing the idea of TLS proxies is a feature, so = DANE's general incompatibility with TLS proxies is a feature, not a bug. From lutz@iks-jena.de Fri Oct 12 02:00:47 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA5F321F843A for ; Fri, 12 Oct 2012 02:00: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JnVhNwE1FNjJ for ; Fri, 12 Oct 2012 02:00:47 -0700 (PDT) Received: from annwfn.iks-jena.de (annwfn-eth.iks-jena.de [IPv6:2001:4bd8:0:104:20a:e4ff:fe80:3138]) by ietfa.amsl.com (Postfix) with ESMTP id D7B3421F842B for ; Fri, 12 Oct 2012 02:00:46 -0700 (PDT) X-SMTP-Sender: IPv6:2001:4bd8:0:666:248:54ff:fe12:ee3f Received: from belenus.iks-jena.de (belenus.iks-jena.de [IPv6:2001:4bd8:0:666:248:54ff:fe12:ee3f]) by annwfn.iks-jena.de (8.14.3/8.14.1) with ESMTP id q9C90dgb026004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Oct 2012 11:00:42 +0200 X-MSA-Host: belenus.iks-jena.de Received: (from lutz@localhost) by belenus.iks-jena.de (8.14.3/8.14.1/Submit) id q9C90d5d001816; Fri, 12 Oct 2012 11:00:39 +0200 Date: Fri, 12 Oct 2012 11:00:39 +0200 From: Lutz Donnerhacke To: Tony Finch Message-ID: <20121012090039.GC29092@belenus.iks-jena.de> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.17 (2007-11-01) Cc: dane@ietf.org Subject: Re: [dane] + add security ... (was : Re: an implementor's comments on 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, 12 Oct 2012 09:00:47 -0000 On Fri, Oct 12, 2012 at 09:45:29AM +0100, Tony Finch wrote: > Marc Lampo wrote: > > Before the draft was adopted as RFC I asked how to cope with proxies. > > Why are proxies a problem for DANE in particular, rather than TLS in > general? TLS man in the middle proxies are easy to implement with faking certificates (on the fly for local enterprise CA or by obtaining fake certs from well known CAs). With DANE, there is a problem: You need to modify the DNSSEC chain on the fly. So what Marc is asking for is a way to forge DNSSEC answers for legal and illegal purposes, cooperate and secret services. It's sufficent to provide such a system for DANE only. The most obvious solution is to install mandantory DLV in the resolvers, so urging such support for DANE applications. From ynir@checkpoint.com Fri Oct 12 02:24:59 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2E5A21F84E2 for ; Fri, 12 Oct 2012 02:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.561 X-Spam-Level: X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bs3TEfGGJ51F for ; Fri, 12 Oct 2012 02:24:59 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id CF5B521F84D9 for ; Fri, 12 Oct 2012 02:24:58 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id q9C9Ottg020350; Fri, 12 Oct 2012 11:24:55 +0200 X-CheckPoint: {5077E05D-14-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([194.29.34.26]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Fri, 12 Oct 2012 11:24:54 +0200 From: Yoav Nir To: Marc Lampo Date: Fri, 12 Oct 2012 11:24:52 +0200 Thread-Topic: [dane] + add security ... (was : Re: an implementor's comments on DANE) Thread-Index: Ac2oW2/pAO+pcNgITOqqrLg0WW64pQ== Message-ID: <5F03EFE3-C687-41A8-8C93-130A5F76650A@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dane@ietf.org" Subject: Re: [dane] + add security ... (was : Re: an implementor's comments on 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, 12 Oct 2012 09:24:59 -0000 Hi Marc I assume you're talking about TLS proxies rather than HTTP proxies. Those a= re in a position to sign certificates on behalf of al the https servers in = the world, that would be trusted by the client. If they have that kind of c= ontrol, I don't see how they'd have any problem either filtering out TLSA r= ecords from DNS queries and responses or getting the client to trust their = own signatures. A draft from a few months ago ( http://tools.ietf.org/html/draft-mcgrew-tls= -proxy-server-01 ) would solve this problem, as it allows the client to see= the real certificate. But that TLS extension was rejected, so it's pretty = much dead. Yoav On Oct 12, 2012, at 9:28 AM, Marc Lampo wrote: > Before the draft was adopted as RFC I asked how to cope with proxies. >=20 > On Sector 2012, last week, I was quite shocked to hear a speaker (also > reading this, I assume) to simply state to get rid of them ! > I'd rather see continued work on how to make the principle of DANE > apply/work even in the presence of proxies. >=20 > The other security remark is that, in order for the browser to use > info in TLSA record, the host needs access to public DNS. > (with the use of a proxy, a setup with internal-roots is possible, > internal hosts don't need access to public IP addresses > if they use proxies) > However, TLSA is not "an address", so access to public DNS is needed. > But that (access to public DNS) allows for new threats in the area of > data leakage !!! > One can do file transfer, both in and out of a network, using correct > DNS messages, if access to public DNS is available. > (as I addressed, when still Security Officer for EURid, on CENTR > Security WG meeting in June 2012, in Frankfurt) >=20 > In summary : > Usage of TLSA, in its present form, opens new can of worms. > Which can only be kept closed if somehow collaboration of DANE (TLSA) > and proxies can be achieved. >=20 > Regarding DNSSEC : > do not forget that adding signatures without verifying them is almost use= less. > And since *lots* of networks use AD, with its (non DNSSEC capable) DNS > servers, only few users actually benefit, at this moment. > ("non DNSSEC capable" : since MS DNS does not support a protocol > higher than 5, and treats everything higher as "unsigned": > + since the root zone uses protocol 8 > --> this comes down to "not capable DNSSEC") >=20 > So, wether or not the TLSA record is coming from a signed domain, most > users are not capable of noticing this anyway. >=20 > Kind regards, >=20 > Marc Lampo > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 > Scanned by Check Point Total Security Gateway. From n.mavrogiannopoulos@gmail.com Fri Oct 12 02:37:18 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D746F21F855F for ; Fri, 12 Oct 2012 02:37:18 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWMteZsO+YlA for ; Fri, 12 Oct 2012 02:37:18 -0700 (PDT) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9BF21F8559 for ; Fri, 12 Oct 2012 02:37:18 -0700 (PDT) Received: by mail-ia0-f172.google.com with SMTP id o25so2237536iad.31 for ; Fri, 12 Oct 2012 02:37:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=N5WCYpqWLdhKWtEH9QrYP0S6TD/ot7quiLVbzubb8ZI=; b=kPQnY1ZzTUkiDIB5D3wvO2hWvjDt5isc0B2WmCH/k/pYfbP25F/ZIf3tbF6JkurHgZ p37qZm+niWZsuAG7Lw4vPLMWMiM1D4OeYi1F8VHcjttGZr+F0jb0slB1TGb5c1IEFye/ vnh5fgLCVMHrHGa3LrmjJ0k7+PA73fwlBw046Vn0HBcb4X6cSBDT/3QV1Riswvl1rf+G rSWaAvUboFXtQjhg6Twc6pMLKd6KoHQvWXVailoOg4vETOYxz+8CmFrhAuMRxv1zAm33 LKo1VkvkpPlEsE8O2W4ebN5USqE0JX3cRyvfqxHPGaxEpvCml1AkQCuzGzBnVffxWY/V /UdQ== MIME-Version: 1.0 Received: by 10.50.161.169 with SMTP id xt9mr46806igb.62.1350034637866; Fri, 12 Oct 2012 02:37:17 -0700 (PDT) Received: by 10.64.86.80 with HTTP; Fri, 12 Oct 2012 02:37:17 -0700 (PDT) In-Reply-To: References: Date: Fri, 12 Oct 2012 11:37:17 +0200 Message-ID: From: Nikos Mavrogiannopoulos To: Marc Lampo Content-Type: text/plain; charset=UTF-8 Cc: dane@ietf.org Subject: Re: [dane] + add security ... (was : Re: an implementor's comments on 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, 12 Oct 2012 09:37:18 -0000 On Fri, Oct 12, 2012 at 9:28 AM, Marc Lampo wrote: > Before the draft was adopted as RFC I asked how to cope with proxies. > On Sector 2012, last week, I was quite shocked to hear a speaker (also > reading this, I assume) to simply state to get rid of them ! > I'd rather see continued work on how to make the principle of DANE > apply/work even in the presence of proxies. There are no proxies defined for TLS at least in the IETF context. TLS is an end-to-end protocol. What you call a proxy is performing a man-in-the-middle attack on the protocol. It succeeds by inserting a "proxy" certificate in the user's trusted CA list. In that context it is good that DANE detects those attacks. I suppose that such "proxies" would just insert their key as a DNSSEC root key. regards, Nikos From wouter@nlnetlabs.nl Fri Oct 12 02:37:39 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A259721F8559 for ; Fri, 12 Oct 2012 02:37:39 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJjo3oO9wQiP for ; Fri, 12 Oct 2012 02:37:38 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7377521F853A for ; Fri, 12 Oct 2012 02:37:38 -0700 (PDT) Received: from axiom.nlnetlabs.nl (axiom.nlnetlabs.nl [IPv6:2001:7b8:206:1:222:4dff:fe55:4d46]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.5/8.14.4) with ESMTP id q9C9bWgK021617 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 12 Oct 2012 11:37:33 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) X-DKIM: OpenDKIM Filter v2.6.7 open.nlnetlabs.nl q9C9bWgK021617 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1350034653; bh=atWMC6OBA1n/SlSYzLV/G6yJ4P0ojFDCuyF6HTZKFCc=; h=Date:From:To:Subject:References:In-Reply-To; b=pHmrkcJUU+HN33qduYowLA0GLvgf6JYZ8XFaU9uyE+G85LRjQzQoz7Xsee9JU/OYq z8E9mpwrtwW83isWraFKa5hmJ8/TiK8Jt/j3E6FD6IgTKtFJqjlqQkZDKJoASChkIs jqjiLRAoLHnHmE3EzKsdj54X7qWJd+lzsQygQ8rQ= Message-ID: <5077E4E0.3000000@nlnetlabs.nl> Date: Fri, 12 Oct 2012 11:37:36 +0200 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 MIME-Version: 1.0 To: dane@ietf.org References: <5F03EFE3-C687-41A8-8C93-130A5F76650A@checkpoint.com> In-Reply-To: <5F03EFE3-C687-41A8-8C93-130A5F76650A@checkpoint.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Fri, 12 Oct 2012 11:37:33 +0200 (CEST) Subject: Re: [dane] + add security ... (was : Re: an implementor's comments on 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, 12 Oct 2012 09:37:39 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Yoav, About: DNSSEC can detect filtered out information (often not understood as it involves that complicated denial of existance part of DNSSEC). On 10/12/2012 11:24 AM, Yoav Nir wrote: > Hi Marc > > I assume you're talking about TLS proxies rather than HTTP > proxies. Those are in a position to sign certificates on behalf of > al the https servers in the world, that would be trusted by the > client. If they have that kind of control, I don't see how they'd > have any problem either filtering out TLSA records from DNS queries > and responses or getting the client to trust their own signatures. A resolver can detect that TLSA records have been filtered out. (but cannot then reconstruct that data, i.e. no connection). > A draft from a few months ago ( > http://tools.ietf.org/html/draft-mcgrew-tls-proxy-server-01 ) > would solve this problem, as it allows the client to see the real > certificate. But that TLS extension was rejected, so it's pretty > much dead. Well, would not see the real certificate, but know that trouble exists (TLSA got filtered) and can stop the connection. Technically, the resolver knows that 'it could not successfully prove that the TLSA did not exist', and it cannot get a TLSA. So, the fallback to plain PKIX should not be performed. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQd+TgAAoJEJ9vHC1+BF+NI0kQAKs+k0s4hZKXFiGmo2ZUoBD2 IUbLdOGwKCEn4e2t1pZMidMOYxBgBdWj4PqiLTIb9iss9kJSYd1AKcm6AJUgaXyc 7n+fQO6VilixLAGrpw63p/HuvCQif50KZCcc6zJHKz5US9U7utULh+CEQIdv+cnf U3+UjyWv8dqeULFrNYwowUG1MgF2gquSOiZJb5IWFBIjm3G5vKDkzdnRSAp7x0Pq qvBr9wDeP9znTsjhVOh78wTOJWVyQWRR/xoZGxd8k0CwF0pA9uPzbO/pXJ7XOy92 9EJ3uYaFviApgv1suW4/Y9GKZ1JSJYt8lPpJ/KTKOr5F2wn1E/MAZAgSPgvqBrsf ZF+ZTy0xO17ulpLyTQ5bsvePiNu8Z6n6eluXoUUzFLern+CKMj1VoUgftYS+j6xv sqbUoPjD+SkVIyqPF4+Gc7waw7vzW8vTzbVBwRFRqlhjAm6nCYIxUHe484fuGXL5 GaHN37IFfSaws890k0sEOnyQ17t6J9uoLBV8gqdDnXn2NDbgYJTBnU2pXAIV+ib8 +GblV6Kwz947cc9vOrWuKaktpz9qUEQ1iLq8lgTVrnHMHF+bpnLCocgCXFkEgRut FjTgdTY6UjBP9/64n5waRmxJlKVCcxuRVdKLycUCOjtb38lsmefqFy+FQM8JQSmf XNprdST3uRblIm17rWb7 =704F -----END PGP SIGNATURE----- From tom@ritter.vg Fri Oct 12 05:01:03 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1DC21F857D for ; Fri, 12 Oct 2012 05:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.410, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PmyLBbU-yWkv for ; Fri, 12 Oct 2012 05:01:02 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D641821F856D for ; Fri, 12 Oct 2012 05:01:01 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so3761997vcb.31 for ; Fri, 12 Oct 2012 05:01:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=qIHxPaPeL60Rl0Dt1+UgpA58JEltk5YAqa5el4z0am0=; b=bmy6BvffEoCgKJjDtzzBMxYkcCqIo3IGDvj1qu3gP0lZvTfOv6R7WxvbxhRO3cNr89 E91EL8Ft/SSaxKEdUwoVtiTXsluxBAmsz2m+wnJBuRHjJ5qmNL308QVUfeIWAzUQ4RZX o8qpE0f639IZf3SsWMh71MBmiik3prQOEZ2Nw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=qIHxPaPeL60Rl0Dt1+UgpA58JEltk5YAqa5el4z0am0=; b=G1r9sb1SpuzjsMuJAcxJkumjVHgz3rSdBP7sSoTLhFfRGLYMRuiB65vsTmcCM8H83Q Ut7S0FmtCjE/Phznh2MPtT2kBEgoZKrlbboRfF8IIHh+7ZQUnvnMFcRh8GEJVui2nwsE dU2vquS/8N7ZaKuNvYwbREXGY8mxllI+Rns/bMUGILAm5yqOtBh/FieBB4ZRocevk+vW ddkg4T6Fkvdy8FU/YSgoFbBG2cA603tDLAhvGqJLoAkaP0FM+nZBjyjlPWWSI12QlU59 FOe6/CijaOoPACdVNTy7dTYcxjOqwtcBZIxkz0mbKE8+5XabArs8mBP8AGiz///UI/7O LE+w== Received: by 10.58.18.239 with SMTP id z15mr2517041ved.27.1350043261002; Fri, 12 Oct 2012 05:01:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.59.7.135 with HTTP; Fri, 12 Oct 2012 05:00:40 -0700 (PDT) In-Reply-To: References: From: Tom Ritter Date: Fri, 12 Oct 2012 08:00:40 -0400 Message-ID: To: Marc Lampo Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlK8soVBIdqwVg8p2apF+OzjQglm+phLjrUzIOXYz03ZkB1CqJnB+O7VSVbWK/by0S0ggSR Cc: dane@ietf.org Subject: Re: [dane] + add security ... (was : Re: an implementor's comments on 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, 12 Oct 2012 12:01:03 -0000 If the DNSSEC verifier (or whatever the correct term is) is inside the application doing TLS - it isn't a problem. (This *should* cover browsers, when they get around to implementing DANE.) It will probably be handled in the same way Certificate Pinning is handled. If a certificate is signed by a Root CA that is installed locally into the trust store - Certificate Pinning does not apply. Likewise, DANE would (probably) not apply. For any application that does not have a local trust store to install root certificates in or does not perform it's own DNSSEC validation - proxies would indeed break DANE. And as mentioned, I think that is a feature, not a problem. If the application was willing to be proxied, it would support those features as hook points to manipulation trust validation. -tom On 12 October 2012 03:28, Marc Lampo wrote: > Before the draft was adopted as RFC I asked how to cope with proxies. > > On Sector 2012, last week, I was quite shocked to hear a speaker (also > reading this, I assume) to simply state to get rid of them ! > I'd rather see continued work on how to make the principle of DANE > apply/work even in the presence of proxies. > > The other security remark is that, in order for the browser to use > info in TLSA record, the host needs access to public DNS. > (with the use of a proxy, a setup with internal-roots is possible, > internal hosts don't need access to public IP addresses > if they use proxies) > However, TLSA is not "an address", so access to public DNS is needed. > But that (access to public DNS) allows for new threats in the area of > data leakage !!! > One can do file transfer, both in and out of a network, using correct > DNS messages, if access to public DNS is available. > (as I addressed, when still Security Officer for EURid, on CENTR > Security WG meeting in June 2012, in Frankfurt) > > In summary : > Usage of TLSA, in its present form, opens new can of worms. > Which can only be kept closed if somehow collaboration of DANE (TLSA) > and proxies can be achieved. > > Regarding DNSSEC : > do not forget that adding signatures without verifying them is almost useless. > And since *lots* of networks use AD, with its (non DNSSEC capable) DNS > servers, only few users actually benefit, at this moment. > ("non DNSSEC capable" : since MS DNS does not support a protocol > higher than 5, and treats everything higher as "unsigned": > + since the root zone uses protocol 8 > --> this comes down to "not capable DNSSEC") > > So, wether or not the TLSA record is coming from a signed domain, most > users are not capable of noticing this anyway. > > Kind regards, > > Marc Lampo > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From n.mavrogiannopoulos@gmail.com Fri Oct 12 08:59:23 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 167DD21F86E8 for ; Fri, 12 Oct 2012 08:59:23 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oCf2es8cso8L for ; Fri, 12 Oct 2012 08:59:22 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id CDAC221F8723 for ; Fri, 12 Oct 2012 08:59:21 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id d4so2078170eek.31 for ; Fri, 12 Oct 2012 08:59:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; bh=VzLI3ygHYtj1knn+Dxs9HhMFUe0AyVKofKQ4R9MABDI=; b=gVe+4csLYZro0lJkqbco6IQ9Y+MGvO/mslSoXpIpLAqMSrapM9fCfQquERQfRWKEf0 BQLl5AphVobZSt8I471E8E+fq5aQpsyr74CTffBGDQJfOXwtLZPJ0idoKflMXrVo+967 eJHBiy1u7GHbhn+8GFk2qhanWEJ8MdqCEaPfgoCARlTo3RbbAt8fF9x7KnKfXEUFpr2z zDxqPSuLWML0oKkv/TfuL9O+smiMpt1N63lZShZBDRlsH4IYHk8ScNhrfajYT29lrsrk wTwJXWd+2YIQe0V32tz4YwIiz3gFrDhLOglj/8mH5NkpZ+oaqxUPmK6nfbKNFRu/6wP9 6QRw== Received: by 10.14.209.129 with SMTP id s1mr7414821eeo.24.1350057561057; Fri, 12 Oct 2012 08:59:21 -0700 (PDT) Received: from [10.100.2.17] (94-224-100-5.access.telenet.be. [94.224.100.5]) by mx.google.com with ESMTPS id g5sm12308073eem.4.2012.10.12.08.59.19 (version=SSLv3 cipher=OTHER); Fri, 12 Oct 2012 08:59:20 -0700 (PDT) Message-ID: <50783E56.5040504@gmail.com> Date: Fri, 12 Oct 2012 17:59:18 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.6esrpre) Gecko/20120805 Icedove/10.0.6 MIME-Version: 1.0 To: dane@ietf.org X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dane] SubjectPublicKeyInfo claimed but X.509 hash is present X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 12 Oct 2012 15:59:23 -0000 In two of the sites that were previously sent for testing in this list have an issue. Even though in their DANE entry they claim to contain a SubjectPublicKeyInfo hash, in reality they contain a hash of the X.509 certificate. One of these sites is being listed as valid in: http://www.internetsociety.org/deploy360/resources/dane-test-sites/ The sites with issues are: dane.nox.su 030101 forfun.net 010101 The 3 first bytes of the TLSA entry are also above. The issue is in the "Selector" field which has 1 instead of zero. I contacted the forfun.net admin who said that he just used the dane.py script. Is this known or am I missing something? regards, Nikos From paul@cypherpunks.ca Fri Oct 12 10:07:47 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8DE721F87B3 for ; Fri, 12 Oct 2012 10:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.105 X-Spam-Level: X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[AWL=0.494, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3VDk2v8kZX7 for ; Fri, 12 Oct 2012 10:07:46 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id CDF0321F87A8 for ; Fri, 12 Oct 2012 10:07:42 -0700 (PDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 01FCC80504; Fri, 12 Oct 2012 13:07:39 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id EBD3B80453; Fri, 12 Oct 2012 13:07:39 -0400 (EDT) Date: Fri, 12 Oct 2012 13:07:39 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Nikos Mavrogiannopoulos In-Reply-To: <50783E56.5040504@gmail.com> Message-ID: References: <50783E56.5040504@gmail.com> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: dane WG list Subject: Re: [dane] SubjectPublicKeyInfo claimed but X.509 hash is present X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 12 Oct 2012 17:07:47 -0000 On Fri, 12 Oct 2012, Nikos Mavrogiannopoulos wrote: > The 3 first bytes of the TLSA entry are also above. The issue is in the > "Selector" field which has 1 instead of zero. > > I contacted the forfun.net admin who said that he just used the dane.py > script. Is this known or am I missing something? The dane.py script was an old script based on an earlier draft, and the usage had different meanings then. They should use a more modern tool to generate TLSA records. The hash-slinger tlsa command, swede or ldns-dane (coming in the next version of ldns) are known to be good. Paul From paul@nohats.ca Fri Oct 12 10:23:15 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4126E21F87CD for ; Fri, 12 Oct 2012 10:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oAbJE03bFY51 for ; Fri, 12 Oct 2012 10:23:10 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 6283E21F87D0 for ; Fri, 12 Oct 2012 10:23:09 -0700 (PDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 0934980504; Fri, 12 Oct 2012 13:23:08 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id F3FCF80453; Fri, 12 Oct 2012 13:23:08 -0400 (EDT) Date: Fri, 12 Oct 2012 13:23:08 -0400 (EDT) From: Paul Wouters To: Marc Lampo In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dane@ietf.org Subject: Re: [dane] + add security ... (was : Re: an implementor's comments on 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, 12 Oct 2012 17:23:15 -0000 On Fri, 12 Oct 2012, Marc Lampo wrote: > Before the draft was adopted as RFC I asked how to cope with proxies. And we had the same discussion we are having now. > On Sector 2012, last week, I was quite shocked to hear a speaker (also > reading this, I assume) to simply state to get rid of them ! I clearly stated when when making remark that it was my _person_ view, with no hats on. I personally believe MITM proxies are bad for security. I understand that there is a need for them both in the enterprise and at the dictatorship levels, neither of which affect me personally. > I'd rather see continued work on how to make the principle of DANE > apply/work even in the presence of proxies. Please go re-read RFC 1984. If you are legitimately needing to dictate local policy to ignore TLSA records, ask your vendor (browser, OS, etc) for support in enforcing such an override on the application/OS level. It cannot ever be part of the protocol level. > The other security remark is that, in order for the browser to use > info in TLSA record, the host needs access to public DNS. > (with the use of a proxy, a setup with internal-roots is possible, > internal hosts don't need access to public IP addresses > if they use proxies) As I explained during that talk, but perhaps not clearly enough, is that you have the option of using a SOCKS proxy, in which case DNS lookups should done by your SOCKS proxy server, and any DNS and DANE processing would be done there. I would assume any browser supporting SOCKS would disable TLSA checking when SOCKS is enabled. If not, file a bug with the vendor. i.e. see: http://kb.mozillazine.org/Network.proxy.socks_remote_dns > However, TLSA is not "an address", so access to public DNS is needed. No, when configured using SOCKS, you should not need to do DNS yourself. You just get your TCP streams. > Regarding DNSSEC : > do not forget that adding signatures without verifying them is almost useless. > And since *lots* of networks use AD, with its (non DNSSEC capable) DNS > servers, only few users actually benefit, at this moment. Give it another year or so and you'll see the proliferation of validating resolvers on lots of end nodes. > So, wether or not the TLSA record is coming from a signed domain, most > users are not capable of noticing this anyway. "most users" would dramatically change if say firefox, chrome or android would start validating DNSSEC. And that's really a matter of "when", not "if". Paul From lists@8191.ru Fri Oct 12 11:51:47 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6125F21F86FA for ; Fri, 12 Oct 2012 11:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6e8IFtRAqxU for ; Fri, 12 Oct 2012 11:51:46 -0700 (PDT) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 58AA621F86F5 for ; Fri, 12 Oct 2012 11:51:43 -0700 (PDT) Received: by mail-da0-f44.google.com with SMTP id h15so1459710dan.31 for ; Fri, 12 Oct 2012 11:51:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=8191.ru; s=dkim; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=9MlMcScauTVt7X7h79WEReWMO6VGCuKDG9cImnGN4XM=; b=IcWK+peDeB6zexqqbvo/JG4/63DmEwv9btnOBnae27y2dDfixOMwBLr5t3X2ALbqje AvfMUH8PWmaYPuwLiGrozDyojMQz1SQca0RX8PtJfb6lRvfnvGohx+LpIFMWMcrGoZ46 RhNcTF8+pt8JB/x1wpAYlX6EDLl8XfKqllYD8= 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=9MlMcScauTVt7X7h79WEReWMO6VGCuKDG9cImnGN4XM=; b=Cu2HmFUCm2oPUcD5244ArHMlcUoitbdCF+c1p9jTlXAvLnerPbHPY26UvdDoP47k+k vAPvEgsBQ0QS33JpVzlVFl1PbXxgpXeKN5/4LzetQBiNSbAZXO0mZACsEzunT3bO6aNW zF5HrP/uCjEveBgzPdtfPfBrTH825U6gLlG8PkzMwOcJRMXHmhiomoy0MEcvS7A7HzZp ad28wl9oIk7/EyXkm4MA5aeErbVR/eIQqXm6KoMS+eIRUxUKIG94oPAh0Vl2KM4vt1Uo 8G6emqJs3BEiKNVmmfffjzLTzEIivPBhX7XkjqDulg83u6jvRYXyXxV5Q8hSPHcwyyI6 9Fug== MIME-Version: 1.0 Received: by 10.66.86.133 with SMTP id p5mr13474273paz.35.1350067902773; Fri, 12 Oct 2012 11:51:42 -0700 (PDT) Received: by 10.66.255.67 with HTTP; Fri, 12 Oct 2012 11:51:42 -0700 (PDT) X-Originating-IP: [93.188.185.54] In-Reply-To: <50783E56.5040504@gmail.com> References: <50783E56.5040504@gmail.com> Date: Fri, 12 Oct 2012 22:51:42 +0400 Message-ID: From: "Alex Venedioukhin (lists)" To: dane@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmTjkjBdUt0pLlm4DyGySjqIb3dcK0DjQM6hRhpmcfoBY1RWU2tqQpsTDnbQ/o9LA7kRgQW Subject: Re: [dane] SubjectPublicKeyInfo claimed but X.509 hash is present X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 12 Oct 2012 18:51:47 -0000 On Fri, Oct 12, 2012 at 7:59 PM, Nikos Mavrogiannopoulos wrote: > One of these sites is being listed as valid in: > http://www.internetsociety.org/deploy360/resources/dane-test-sites/ > > The sites with issues are: > dane.nox.su 030101 Fixed for dane.nox.su. The 1 was in selector field just because the DANE-plugin for Firefox (Extended DNSSEC Validator) seems to use the selector in such a way. Well, there is still a TYPE65468 record in dane.nox.su with 030101 - so the plugin works. Regards, Alexander Venedioukhin, http://dxdt.ru/ From n.mavrogiannopoulos@gmail.com Fri Oct 12 13:24:14 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA5421F85C3 for ; Fri, 12 Oct 2012 13:24:14 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DiU1TFC2B6BZ for ; Fri, 12 Oct 2012 13:24:13 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5413521F85C2 for ; Fri, 12 Oct 2012 13:24:12 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so1773260wgb.13 for ; Fri, 12 Oct 2012 13:24:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=3wUDBPWJL8G/1d4Z1u9QZSY/OdsVVPHUr5aTPGocOkU=; b=VPr8q+tRDGDCS2RhRgFPgR0YMLMCe2LnFzGEb2PFOg0rh8iqI3LcuFaADT36C8+9NZ hUPyo3nZaLRrCzMq/JZCjjp62cUdUN/xP/QeVUfXRER+F4MW2oj22JiCk7uz69+bHtBw u0QMLKgdlJqnFpj5peIcMKmI/NRgwFedD/Lr8uL+nLzC/qee5fhBbWHaR1IgsqqNFtvQ n1yIbCzOShzVNzUgwV2Q8SoQzePGLt8zy3fZ1AUa1E3wc128/RNo4nf41lAA8hFzNeTJ BiwDEOU41M1GMts7h7QxCOV7klbzoS+6R2BCansrZwC2hmT+IVUcTrujCIW8ANTLsTIq MJ1Q== Received: by 10.216.203.1 with SMTP id e1mr3406783weo.103.1350073452180; Fri, 12 Oct 2012 13:24:12 -0700 (PDT) Received: from [10.100.2.17] (94-224-100-5.access.telenet.be. [94.224.100.5]) by mx.google.com with ESMTPS id f1sm4901333wiy.2.2012.10.12.13.24.10 (version=SSLv3 cipher=OTHER); Fri, 12 Oct 2012 13:24:10 -0700 (PDT) Message-ID: <50787C69.1000909@gmail.com> Date: Fri, 12 Oct 2012 22:24:09 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.6esrpre) Gecko/20120805 Icedove/10.0.6 MIME-Version: 1.0 To: Paul Wouters References: <50783E56.5040504@gmail.com> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dane WG list Subject: Re: [dane] SubjectPublicKeyInfo claimed but X.509 hash is present X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 12 Oct 2012 20:24:14 -0000 On 10/12/2012 07:07 PM, Paul Wouters wrote: > On Fri, 12 Oct 2012, Nikos Mavrogiannopoulos wrote: > >> The 3 first bytes of the TLSA entry are also above. The issue is in the >> "Selector" field which has 1 instead of zero. >> >> I contacted the forfun.net admin who said that he just used the dane.py >> script. Is this known or am I missing something? > > The dane.py script was an old script based on an earlier draft, and the > usage had different meanings then. They should use a more modern tool > to generate TLSA records. The hash-slinger tlsa command, swede or > ldns-dane (coming in the next version of ldns) are known to be good. I've also added a tool to generate dane TLSA entries in the latest gnutls. regards, Nikos From mrex@sap.com Fri Oct 12 16:39:12 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6F2D21F855F for ; Fri, 12 Oct 2012 16:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.201 X-Spam-Level: X-Spam-Status: No, score=-10.201 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7ye0OmVqRQf for ; Fri, 12 Oct 2012 16:39:12 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id F026721F8559 for ; Fri, 12 Oct 2012 16:39:11 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q9CNd9ZL010010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 13 Oct 2012 01:39:09 +0200 (MEST) In-Reply-To: To: Marc Lampo Date: Sat, 13 Oct 2012 01:39:09 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20121012233909.3145D1A2C5@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] + add security ... (was : Re: an implementor's comments on DANE) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 23:39:12 -0000 Marc Lampo wrote: > Before the draft was adopted as RFC I asked how to cope with proxies. > > On Sector 2012, last week, I was quite shocked to hear a speaker (also > reading this, I assume) to simply state to get rid of them ! > I'd rather see continued work on how to make the principle of DANE > apply/work even in the presence of proxies. > > The other security remark is that, in order for the browser to use > info in TLSA record, the host needs access to public DNS. > (with the use of a proxy, a setup with internal-roots is possible, > internal hosts don't need access to public IP addresses > if they use proxies) > However, TLSA is not "an address", so access to public DNS is needed. "Proxy" is a very generic term and means different things to different people. What would need to have extended is the information exchange between the TLS client and the proxy when performing the proxy traversal. A solution for client-side HTTP Proxies that support the "HTTP CONNECT" method would be to have the Proxy perform the TLSA lookups just the way that it performs the DNS lookup for the target hostnames, and return all relevant raw DNS records base64-encoded in header fields of the proxy response to the HTTP CONNECT method. -Martin From danny@tcb.net Sun Oct 14 18:48:05 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29EBB21F8528 for ; Sun, 14 Oct 2012 18:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.603 X-Spam-Level: X-Spam-Status: No, score=-101.603 tagged_above=-999 required=5 tests=[AWL=-0.863, BAYES_20=-0.74, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kdD46CS2FyYK for ; Sun, 14 Oct 2012 18:48:04 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id B70CB21F8523 for ; Sun, 14 Oct 2012 18:48:04 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 358E92680D7; Sun, 14 Oct 2012 19:48:04 -0600 (MDT) Received: from dul1dmcphers-m2.home (pool-71-171-124-149.clppva.fios.verizon.net [71.171.124.149]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for dane@ietf.org; Sun, 14 Oct 2012 19:48:04 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=71.171.124.149; client-port=63081; syn-fingerprint=65535:48:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: Danny McPherson In-Reply-To: Date: Sun, 14 Oct 2012 21:47:55 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: dane@ietf.org X-Mailer: Apple Mail (2.1283) Subject: Re: [dane] + add security ... (was : Re: an implementor's comments on 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: Mon, 15 Oct 2012 01:48:05 -0000 On Oct 12, 2012, at 4:57 AM, Nicholas Weaver wrote: > Of course, certificate pinning and other techniques has the same = problem, and IMO, killing the idea of TLS proxies is a feature, so = DANE's general incompatibility with TLS proxies is a feature, not a bug. Not to pile on, but I concur; definitely feature; in both the context of = pinning and proxies. =20 -danny= From ryan-ietf@sleevi.com Sun Oct 14 20:13:24 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC2521F853F for ; Sun, 14 Oct 2012 20:13:24 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUmEL-t8yjRc for ; Sun, 14 Oct 2012 20:13:23 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id C3AE321F853D for ; Sun, 14 Oct 2012 20:13:23 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id 5CE0059805F; Sun, 14 Oct 2012 20:13:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :date:subject:from:to:cc:reply-to:mime-version:content-type: content-transfer-encoding; s=sleevi.com; bh=ATYqn1IhWP1xZugBzv3A S+88x/U=; b=ojR5xzvY58VeNB70raGKpY6wqvqkGWIf8JcXgMXGzw8zMbSfK+m1 d2sUvTq6BOyBmnf8ilJGdEzYfgvCpfQWuZ+pBylLDWgDNAZPRbyDQH0dBuv/mmO+ EbooQOv9nvbuLdD9B2N0o6p9rdkw/eAfxzELv13o96/A85q5NsaSWUs= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPA id 4B3A4598058; Sun, 14 Oct 2012 20:13:23 -0700 (PDT) Received: from 173.8.157.162 (proxying for 173.8.157.162) (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Sun, 14 Oct 2012 20:13:23 -0700 Message-ID: <5d02bc4a698aacf66886e72842b87514.squirrel@webmail.dreamhost.com> Date: Sun, 14 Oct 2012 20:13:23 -0700 From: "Ryan Sleevi" To: "Nicholas Weaver" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dane@ietf.org Subject: Re: [dane] + add security ... (was : Re: an implementor's comments on DANE) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ryan-ietf@sleevi.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 03:13:24 -0000 On Fri, October 12, 2012 1:57 am, Nicholas Weaver wrote: > > On Oct 12, 2012, at 9:45 AM, Tony Finch wrote: > > > Marc Lampo wrote: > > > >> Before the draft was adopted as RFC I asked how to cope with proxies= . > > > > Why are proxies a problem for DANE in particular, rather than TLS in > > general? > > Because how the proxies work is they add an additional root key into t= he > (victim) browser during some form of configuration. DANE makes the > injected root key no longer valid. > > Of course, certificate pinning and other techniques has the same probl= em, > and IMO, killing the idea of TLS proxies is a feature, so DANE's gener= al > incompatibility with TLS proxies is a feature, not a bug. Public Key Pinning, as implemented in Chromium, only evaluates pins against publicly trusted root certificates (that is, roots which participate in the various platforms' root certificate programs). When the certificate chain that was validated in the client does not terminate in a "publicy trusted" anchor, pinning is not enforced. If you have sufficient privileges to install a local trust anchor on a users machine - whether by means technical or policy - then such local settings are respected by Chromium. For users who are not operating in such scenarios, public key pinning offers a robust defense against future Diginotar-like misissuance. For users who do operate in such environments, it is presumed (albeit unlikely) that the (enterprise) endpoint terminating the TLS connection i= s performing these checks. In the reality that many such solutions are not, proposals such as http://tools.ietf.org/html/draft-mcgrew-tls-proxy-server-01 or http://tools.ietf.org/html/draft-rpeon-httpbis-exproxy-00 would allow clients to implement such security policies. Such scenarios are not strictly relegated to "enterprise" scenarios, wher= e there are effectively three parties participating in the end-to-end session (user, enterprise, site). It's unfortunately common that a number of antivirus vendors have begun shipping local "TLS proxies" as part of their traffic inspection anti-virus/user-protection platforms. These are solutions that the user directly opts in to (by choice of installing the antivirus and configuring it to do so). Thus, I'm not sure that RFC 1984 really comes into play here - this is the user wanting to configure a local policy that can be respected regardless of the applications running on their machine. For DANE, presumably solutions would use some form of DNSSEC rewriting, with DLV, to accomplish the equivalent. That, or individual applications would have explicit options to configure such scenarios. Of course, without some form of central trust mechanism - as exists on Windows and O= S X, and as does not exist on most Linux-based distros - it's likely that many applications will end up trying to roll their own settings, and getting them wrong or being otherwise unmaintainable at scale. The same a= s it is today with application support for explicit (not TLS) proxies such as SOCKS or HTTP. From paul@cypherpunks.ca Mon Oct 15 08:57:17 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60CF91F0C44 for ; Mon, 15 Oct 2012 08:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.204 X-Spam-Level: X-Spam-Status: No, score=-2.204 tagged_above=-999 required=5 tests=[AWL=0.396, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCnwOk-sil6t for ; Mon, 15 Oct 2012 08:57:17 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id E3F531F042B for ; Mon, 15 Oct 2012 08:57:16 -0700 (PDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 5A26F82A2C; Mon, 15 Oct 2012 11:56:56 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 4E10D82574; Mon, 15 Oct 2012 11:56:56 -0400 (EDT) Date: Mon, 15 Oct 2012 11:56:56 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Ryan Sleevi In-Reply-To: <5d02bc4a698aacf66886e72842b87514.squirrel@webmail.dreamhost.com> Message-ID: References: <5d02bc4a698aacf66886e72842b87514.squirrel@webmail.dreamhost.com> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: dane WG list Subject: Re: [dane] + add security ... (was : Re: an implementor's comments on 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: Mon, 15 Oct 2012 15:57:17 -0000 On Sun, 14 Oct 2012, Ryan Sleevi wrote: > For DANE, presumably solutions would use some form of DNSSEC rewriting, > with DLV That's not the purpose of DLV. DLV is going to die sooner rather then later, and no infrastructure should be build up to use it for such purpose. I hope the operator of the DLV registry will confirm this in strong terms. Paul From benl@google.com Tue Oct 16 04:01:34 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D17D21F88B2 for ; Tue, 16 Oct 2012 04:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlmVxG6SjTxI for ; Tue, 16 Oct 2012 04:01:33 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id C6DFB21F88A4 for ; Tue, 16 Oct 2012 04:01:29 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hq12so2769108wib.13 for ; Tue, 16 Oct 2012 04:01:28 -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:x-system-of-record; bh=yvzf0SWiJJWfU8PbRR9gPPKFGVpUXmdajNEixVOs+ew=; b=B170rJ0uLT2PA4ZYPmPe3gZPZREv8+j6NILNsU9l2bGkMS2OSckCeOJl73Y3eZ7oXX 5Tx6T99LYqaekmsGfeApw0T73fJWocNoH7Clb8p6UphE+BS/LoxDh1/K6IKxlsMM7SG+ C06OYU5J4uGMR57f1S2+EblinePq+2Ehhjz31TO5dkG0GLBewO7tAdbVaUZF2hv/QNa6 HrItWARLUeoZYcLZlnA+oxaOEal3JDnq28H9iZa5T3QZ1m2VQrnbr0lKDXgFo5wc2z+6 GSDToemuXOaTlmxcUdElMjB8M+fqmYJAIDo7qVJnz33ftQU5yqC12+C+JbWR5eKXDl4M X+Hg== 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-system-of-record:x-gm-message-state; bh=yvzf0SWiJJWfU8PbRR9gPPKFGVpUXmdajNEixVOs+ew=; b=X2KKaXatP2yffMf/+Ky9Vy9fUTDraq5Kxpclqe7rxqGEP6D5dMFtp0Sg1A0V1J9Nbx CpskByeb+ZuTt+cQ4XuLBPCHMPY1f+IzitOu4e4HfvAFPeK2HWZABwlCiIJcm27m+MB6 T3kScqndyFNpvoWhrVa7F5+EdNUztX9gulBoq4XAlG3nl61L7JpagRyheCAUATHuzE3z EliMCp2JLRRTjqhoSahRRAUnCSzwVlzlVBCBlingBZNTCGAhFW74Nxx4y6T1qkT4PuD7 fs+fcv87K5YwrYaO/yIAOOxMcZeobLfPtBXhPDELH2MFdAgvcH1Elz567lwZ5YrmDeFw KhlA== MIME-Version: 1.0 Received: by 10.180.104.97 with SMTP id gd1mr31084781wib.4.1350385288730; Tue, 16 Oct 2012 04:01:28 -0700 (PDT) Received: by 10.216.236.201 with HTTP; Tue, 16 Oct 2012 04:01:28 -0700 (PDT) In-Reply-To: <50787C69.1000909@gmail.com> References: <50783E56.5040504@gmail.com> <50787C69.1000909@gmail.com> Date: Tue, 16 Oct 2012 12:01:28 +0100 Message-ID: From: Ben Laurie To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkJLRUDXuU6fIhRnkSj6HDdl7jAnOVYNZ9vEeGkMZ3sGb1oQnmQSqLWnvYVfsJluF51hqz2ESLlJ2uP3Vk7bghV3rXeRnVcLSTpvn8smYy4wJjRr3Sv0Ld8aXRfES1R7vnfD8w7BA9CG8dV7S6tIVt7bTS5rboVywyzsuU0XL/jHFsldlzcPib6sJWN7pXMEE7lH0+H Cc: dane WG list Subject: Re: [dane] SubjectPublicKeyInfo claimed but X.509 hash is present X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Oct 2012 11:01:34 -0000 On 12 October 2012 21:24, Nikos Mavrogiannopoulos wrote: > On 10/12/2012 07:07 PM, Paul Wouters wrote: > >> On Fri, 12 Oct 2012, Nikos Mavrogiannopoulos wrote: >> >>> The 3 first bytes of the TLSA entry are also above. The issue is in the >>> "Selector" field which has 1 instead of zero. >>> >>> I contacted the forfun.net admin who said that he just used the dane.py >>> script. Is this known or am I missing something? >> >> The dane.py script was an old script based on an earlier draft, and the >> usage had different meanings then. They should use a more modern tool >> to generate TLSA records. The hash-slinger tlsa command, swede or >> ldns-dane (coming in the next version of ldns) are known to be good. > > > I've also added a tool to generate dane TLSA entries in the latest gnutls. Hmm, good point, I should add that to OpenSSL. > > regards, > Nikos > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From hallam@gmail.com Tue Oct 16 07:48:04 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C53221F87C1 for ; Tue, 16 Oct 2012 07:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 tagged_above=-999 required=5 tests=[AWL=-1.115, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yiO6oA1vMTte for ; Tue, 16 Oct 2012 07:48:03 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB5521F877D for ; Tue, 16 Oct 2012 07:48:03 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so7523578obq.31 for ; Tue, 16 Oct 2012 07:48:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uYq4io8aeTjEVzR4I5RZtto6Zu0yeKKATJgCEFTvpdA=; b=ieGPNBZ0cqs9U4vx95YqJDO9bL9+Cy8Mxq4sl1Ae5GP+LDvmgSt32VzJQSWDfo35IH THJMx84qJQ2Kr7/MiCBGjjVbzOXZYj2viSy4WJ7Wy5NdGcF/sbXyhSzCWpV8vtSUKjg1 +fNBNisSxy6phwy7qUPkxy5RIqXzoMREmxMElzjYbrsR2B3BLEeFZWIiqv84rTfS5R5k UJ6WHixGWN7SmLEczVQ5wmhzr3Ml+ZxsT76bSWjKUUQTYONJ1xKtGPdYj+3Buk5TSe6e 7E/KTjydGvhSOmPVoPKNgRRjIokbCrUX9WWH98uskdhME1ovJ3S1w3TnOpiS0IPCeOIt yQ6g== MIME-Version: 1.0 Received: by 10.60.170.9 with SMTP id ai9mr12221447oec.36.1350398882642; Tue, 16 Oct 2012 07:48:02 -0700 (PDT) Received: by 10.76.27.103 with HTTP; Tue, 16 Oct 2012 07:48:02 -0700 (PDT) In-Reply-To: References: <5d02bc4a698aacf66886e72842b87514.squirrel@webmail.dreamhost.com> Date: Tue, 16 Oct 2012 10:48:02 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Wouters Content-Type: multipart/alternative; boundary=bcaec54a3e02b47beb04cc2e3dc8 Cc: dane WG list Subject: Re: [dane] + add security ... (was : Re: an implementor's comments on 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: Tue, 16 Oct 2012 14:48:04 -0000 --bcaec54a3e02b47beb04cc2e3dc8 Content-Type: text/plain; charset=ISO-8859-1 I think that is a rather naive assessment. Most of us do not want to be dependent on a single root of trust that is ultimately under the physical control of VeriSign and the legal control of ICANN, a body whose insistence that it is above criticism should be deeply troubling. Attempts to concentrate trust in one place have invariably proved to be unstable. DLV is not the solution but it may be a useful contribution to a solution. On Mon, Oct 15, 2012 at 11:56 AM, Paul Wouters wrote: > On Sun, 14 Oct 2012, Ryan Sleevi wrote: > > For DANE, presumably solutions would use some form of DNSSEC rewriting, >> with DLV >> > > That's not the purpose of DLV. DLV is going to die sooner rather then > later, > and no infrastructure should be build up to use it for such purpose. > > I hope the operator of the DLV registry will confirm this in strong terms. > > Paul > > ______________________________**_________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/**listinfo/dane > -- Website: http://hallambaker.com/ --bcaec54a3e02b47beb04cc2e3dc8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think that is a rather naive assessment.

Most of us do= not want to be dependent on a single root of trust that is ultimately unde= r the physical control of VeriSign and the legal control of ICANN, a body w= hose insistence that it is above criticism should be deeply troubling. Atte= mpts to concentrate trust in one place have invariably proved to be unstabl= e.

DLV is not the solution but it may be a useful contribu= tion to a solution.



=
On Mon, Oct 15, 2012 at 11:56 AM, Paul Woute= rs <paul@cypherpunks.ca> wrote:
On Sun, 14 Oct 2012, Ryan = Sleevi wrote:

For DANE, presumably solutions would use some form of DNSSEC rewriting,
with DLV

That's not the purpose of DLV. DLV is going to die sooner rather then l= ater,
and no infrastructure should be build up to use it for such purpose.

I hope the operator of the DLV registry will confirm this in strong terms.<= span class=3D"HOEnZb">

Paul

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



--
= Website: http://hallambaker.com/
--bcaec54a3e02b47beb04cc2e3dc8-- From paul@cypherpunks.ca Tue Oct 16 08:12:06 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B45EE21F89C5 for ; Tue, 16 Oct 2012 08:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWwu8bxxBvqe for ; Tue, 16 Oct 2012 08:12:06 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 1BCD521F89C2 for ; Tue, 16 Oct 2012 08:12:05 -0700 (PDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 162C882B21; Tue, 16 Oct 2012 11:11:45 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 0884082A5B; Tue, 16 Oct 2012 11:11:45 -0400 (EDT) Date: Tue, 16 Oct 2012 11:11:45 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <5d02bc4a698aacf66886e72842b87514.squirrel@webmail.dreamhost.com> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dane WG list Subject: Re: [dane] + add security ... (was : Re: an implementor's comments on 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: Tue, 16 Oct 2012 15:12:06 -0000 On Tue, 16 Oct 2012, Phillip Hallam-Baker wrote: > I think that is a rather naive assessment. > Most of us do not want to be dependent on a single root of trust that is ultimately under the physical control of VeriSign and the legal > control of ICANN, a body whose insistence that it is above criticism should be deeply troubling. Attempts to concentrate trust in one place > have invariably proved to be unstable. > > DLV is not the solution but it may be a useful contribution to a solution. You are confusing the DLV method with the dlv.isc.org instance. Paul From hallam@gmail.com Wed Oct 17 17:28:58 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1662421F8557 for ; Wed, 17 Oct 2012 17:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.933 X-Spam-Level: X-Spam-Status: No, score=-3.933 tagged_above=-999 required=5 tests=[AWL=-0.335, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kk3o3VWNcAwa for ; Wed, 17 Oct 2012 17:28:57 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD2721F8539 for ; Wed, 17 Oct 2012 17:28:57 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so9601635obq.31 for ; Wed, 17 Oct 2012 17:28:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qssJVCcqNH1OM9fpBdUm8eeOPSDQAEwCgBdkYYruLXc=; b=TbpbfWt/V/yxxKL1ZhFSHinzq1BO6W89XFsImm8svv8IO7ec+SiMpyg0i2XGMsSki0 Zy4nu8hi53cynxHGmijjxG/kx5AgvsZ+mxOhxO363J1ultv9AfmXFFeav+pzFkfC9nbE 63dkZEAr35i2mb/EuJ24o8rtZyl5RFMohBecz5mmlQvE/CNheC7FIczWtzVN6Qn7whQE oFTBLWdZAlxYEhmQgx9hrx1qQXmlfEs4hh2A2GmmWaggjau1N2QtjK8EHhvZSZNpJHa+ 7FHzdr5W/YBy1Mafi2VGGfcSx7W7kr7LcsexYMCFtyFYUtptUETL+C2cm5XYVa0e2uN5 lkDA== MIME-Version: 1.0 Received: by 10.60.29.229 with SMTP id n5mr16598355oeh.76.1350520136830; Wed, 17 Oct 2012 17:28:56 -0700 (PDT) Received: by 10.76.27.103 with HTTP; Wed, 17 Oct 2012 17:28:56 -0700 (PDT) In-Reply-To: References: <5d02bc4a698aacf66886e72842b87514.squirrel@webmail.dreamhost.com> Date: Wed, 17 Oct 2012 20:28:56 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Wouters Content-Type: multipart/alternative; boundary=e89a8ff253fe048e6804cc4a7907 Cc: dane WG list Subject: Re: [dane] + add security ... (was : Re: an implementor's comments on 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, 18 Oct 2012 00:28:58 -0000 --e89a8ff253fe048e6804cc4a7907 Content-Type: text/plain; charset=ISO-8859-1 I don't understand why you would think that. Handing control of the Internet to Paul V. is obviously not a solution to the concentration of trust issue. The problem is not who is in control but the monopoly of control. A system of multiple DLV registries with different signing keys would be much better. Especially if zones were signed by multiple registries. On Tue, Oct 16, 2012 at 11:11 AM, Paul Wouters wrote: > On Tue, 16 Oct 2012, Phillip Hallam-Baker wrote: > > I think that is a rather naive assessment. >> Most of us do not want to be dependent on a single root of trust that is >> ultimately under the physical control of VeriSign and the legal >> control of ICANN, a body whose insistence that it is above criticism >> should be deeply troubling. Attempts to concentrate trust in one place >> have invariably proved to be unstable. >> >> DLV is not the solution but it may be a useful contribution to a solution. >> > > You are confusing the DLV method with the dlv.isc.org instance. > > Paul > -- Website: http://hallambaker.com/ --e89a8ff253fe048e6804cc4a7907 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I don't understand why you would think that.

Handing= control of the Internet to Paul V. is obviously not a solution to the conc= entration of trust issue. The problem is not who is in control but the mono= poly of control.

A system of multiple DLV registries with different sign= ing keys would be much better. Especially if zones were signed by multiple = registries.

On Tue, Oct 16, 2012 a= t 11:11 AM, Paul Wouters <paul@cypherpunks.ca> wrote:
On Tue, 16 Oct 2012, Phill= ip Hallam-Baker wrote:

I think that is a rather naive assessment.
Most of us do not want to be dependent on a single root of trust that is ul= timately under the physical control of VeriSign and the legal
control of ICANN, a body whose insistence that it is above criticism should= be deeply troubling. Attempts to concentrate trust in one place
have invariably proved to be unstable.

DLV is not the solution but it may be a useful contribution to a solution.<= br>

You are confusing the DLV method with the dlv.isc.org instance.

Paul



-- Website: http://hallambaker.com/<= br>
--e89a8ff253fe048e6804cc4a7907-- From sandoche.balakrichenan@afnic.fr Thu Oct 18 00:45:25 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF3D321F85DA for ; Thu, 18 Oct 2012 00:45:25 -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_FR=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDoaKd-saD1v for ; Thu, 18 Oct 2012 00:45:24 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [192.134.4.12]) by ietfa.amsl.com (Postfix) with ESMTP id 766B121F85AC for ; Thu, 18 Oct 2012 00:45:24 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 250D12801A4; Thu, 18 Oct 2012 09:44:51 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id 1F571280187; Thu, 18 Oct 2012 09:44:51 +0200 (CEST) Received: from sandoche-world (tirodite.tech.ipv6.nic.fr [IPv6:2001:67c:2219:7::86:63]) by relay2.nic.fr (Postfix) with ESMTP id 1D726B38066; Thu, 18 Oct 2012 09:44:21 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by sandoche-world (Postfix) with ESMTP id 05579A400E7; Thu, 18 Oct 2012 09:44:22 +0200 (CEST) Message-ID: <507FB355.4030908@afnic.fr> Date: Thu, 18 Oct 2012 09:44:21 +0200 From: sandoche BALAKRICHENAN User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: Paul Wouters References: <201207311641.q6VGf8EK078660@calcite.rhyolite.com> <50360192.7080806@afnic.fr> <50362FE0.40407@afnic.fr> <50507EF9.7030803@sidn.nl> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dns-operations@mail.dns-oarc.net, dane@ietf.org Subject: Re: [dane] [dns-operations] DNSSEC DANE testing X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 18 Oct 2012 07:45:25 -0000 Hi Paul, I have deliberately added a bogus RRSIG record to "https://dane-broken.rd.nic.fr". But the firefox add-on seems to successfully validate mentioning "the domain is secured by DNSSEC". Sandoche. On 09/12/2012 10:44 PM, Paul Wouters wrote: > On Wed, 12 Sep 2012, Marco Davids (SIDN) wrote: > >> On 08/23/12 20:02, Paul Wouters wrote: >> >>> I put up the xpi as well, you can grab it at: >>> http://people.redhat.com/pwouters/mozilla-extval-0.7.xpi >> >> I like it. >> >> However, there might be room for improvent in the wording of the the >> messages. >> >> I deliberately broke the TLSA record (https://forfun.net/) and the >> message is (in green): >> >> "Domainname is secured by DNSSEC and the certificate is validated by >> CA." >> >> Both true, but as a paranoid user, I would have appreciated a little bit >> more information, like: >> >> "... but the certificate did not pass a DANE check" >> >> (or something similar) > > It should do that. When I check your domain it tells me there is no TLSA > record, but I checked all name servers and it is there (and incorrect) > > I'll add it on my TODO list :) > > Paul > _______________________________________________ > dns-operations mailing list > dns-operations@lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations > dns-jobs mailing list > https://lists.dns-oarc.net/mailman/listinfo/dns-jobs From marka@isc.org Thu Oct 18 14:56:24 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA9A21F8501 for ; Thu, 18 Oct 2012 14:56:24 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48lLOmFWDbjz for ; Thu, 18 Oct 2012 14:56:23 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id C628721F844D for ; Thu, 18 Oct 2012 14:56:22 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 683B15F983B; Thu, 18 Oct 2012 21:56:10 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:c501:27de:9a78:48f1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id A5B90216C7B; Thu, 18 Oct 2012 21:56:08 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id CBB8929FFFAA; Fri, 19 Oct 2012 08:56:05 +1100 (EST) To: sandoche BALAKRICHENAN From: Mark Andrews References: <201207311641.q6VGf8EK078660@calcite.rhyolite.com> <50360192.7080806@afnic.fr> <50362FE0.40407@afnic.fr> <50507EF9.7030803@sidn.nl> <507FB355.4030908@afnic.fr> In-reply-to: Your message of "Thu, 18 Oct 2012 09:44:21 +0200." <507FB355.4030908@afnic.fr> Date: Fri, 19 Oct 2012 08:56:05 +1100 Message-Id: <20121018215605.CBB8929FFFAA@drugs.dv.isc.org> Cc: dns-operations@mail.dns-oarc.net, dane@ietf.org Subject: Re: [dane] [dns-operations] DNSSEC DANE testing X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 18 Oct 2012 21:56:24 -0000 In message <507FB355.4030908@afnic.fr>, sandoche BALAKRICHENAN writes: > Hi Paul, > > I have deliberately added a bogus RRSIG record to > "https://dane-broken.rd.nic.fr". But the firefox add-on seems to > successfully validate mentioning "the domain is secured by DNSSEC". > > Sandoche. Well the TLSA is secure. As long as that matches the CERT returned it *is* secured even if the RRSIG on the A RRset is broken. ; <<>> DiG 9.10.0pre-alpha <<>> _443._tcp.dane-broken.rd.nic.fr tlsa +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52053 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;_443._tcp.dane-broken.rd.nic.fr. IN TLSA ;; ANSWER SECTION: _443._tcp.dane-broken.rd.nic.fr. 1 IN TLSA 3 0 1 6E013C54DF90D42D3C016E1AC9EB21E6DA45403D3A5AE9B2D8F21FC3 600D409C _443._tcp.dane-broken.rd.nic.fr. 1 IN RRSIG TLSA 5 6 1 20130415134103 20121017134103 24975 dane-broken.rd.nic.fr. UFaeHhxVp8zy1tpcR049JqGEvNZrmDLkpgoo63v4gvEtwLp0KRbSBL5J vVlNnz8s5Uk68i8diY/zGt1epP72C2S6C3AUHKdYZiwvxBQwd34Sawna jZMjfAkXEH5z9cjkk1AVm0ReRPs9kbVc0iPDLcH+z21VJBZyFmloOflM EXU= ;; Query time: 838 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Oct 19 08:49:24 2012 ;; MSG SIZE rcvd: 288 > On 09/12/2012 10:44 PM, Paul Wouters wrote: > > On Wed, 12 Sep 2012, Marco Davids (SIDN) wrote: > > > >> On 08/23/12 20:02, Paul Wouters wrote: > >> > >>> I put up the xpi as well, you can grab it at: > >>> http://people.redhat.com/pwouters/mozilla-extval-0.7.xpi > >> > >> I like it. > >> > >> However, there might be room for improvent in the wording of the the > >> messages. > >> > >> I deliberately broke the TLSA record (https://forfun.net/) and the > >> message is (in green): > >> > >> "Domainname is secured by DNSSEC and the certificate is validated by > >> CA." > >> > >> Both true, but as a paranoid user, I would have appreciated a little bit > >> more information, like: > >> > >> "... but the certificate did not pass a DANE check" > >> > >> (or something similar) > > > > It should do that. When I check your domain it tells me there is no TLSA > > record, but I checked all name servers and it is there (and incorrect) > > > > I'll add it on my TODO list :) > > > > Paul > > _______________________________________________ > > dns-operations mailing list > > dns-operations@lists.dns-oarc.net > > https://lists.dns-oarc.net/mailman/listinfo/dns-operations > > dns-jobs mailing list > > https://lists.dns-oarc.net/mailman/listinfo/dns-jobs > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From warren@kumari.net Thu Oct 18 15:43:42 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7A4021F8417 for ; Thu, 18 Oct 2012 15:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.096 X-Spam-Level: X-Spam-Status: No, score=-102.096 tagged_above=-999 required=5 tests=[AWL=0.503, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4O34Ogs1DsHS for ; Thu, 18 Oct 2012 15:43:42 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB5D121F8435 for ; Thu, 18 Oct 2012 15:43:41 -0700 (PDT) Received: from [10.196.196.235] (1-193.icannmeeting.org [199.91.193.1]) by vimes.kumari.net (Postfix) with ESMTPSA id 606FB1B40187; Thu, 18 Oct 2012 18:43:40 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Warren Kumari In-Reply-To: <20121018215605.CBB8929FFFAA@drugs.dv.isc.org> Date: Thu, 18 Oct 2012 18:43:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201207311641.q6VGf8EK078660@calcite.rhyolite.com> <50360192.7080806@afnic.fr> <50362FE0.40407@afnic.fr> <50507EF9.7030803@sidn.nl> <507FB355.4030908@afnic.fr> <20121018215605.CBB8929FFFAA@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1499) Cc: dns-operations@mail.dns-oarc.net, dane@ietf.org Subject: Re: [dane] [dns-operations] DNSSEC DANE testing X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 18 Oct 2012 22:43:43 -0000 On Oct 18, 2012, at 5:56 PM, Mark Andrews wrote: >=20 > In message <507FB355.4030908@afnic.fr>, sandoche BALAKRICHENAN writes: >> Hi Paul, >>=20 >> I have deliberately added a bogus RRSIG record to >> "https://dane-broken.rd.nic.fr". But the firefox add-on seems to >> successfully validate mentioning "the domain is secured by DNSSEC". >>=20 >> Sandoche. >=20 > Well the TLSA is secure. As long as that matches the CERT returned = it *is* > secured even if the RRSIG on the A RRset is broken. Ooooh=85 This is an interesting case (which I personally hadn't = considered)...=20 This all makes sense, but "feels" odd=85 Not proposing that we do = anything, but it did make me blink=85. W >=20 > ; <<>> DiG 9.10.0pre-alpha <<>> _443._tcp.dane-broken.rd.nic.fr tlsa = +dnssec > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52053 > ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: = 1 >=20 > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 4096 > ;; QUESTION SECTION: > ;_443._tcp.dane-broken.rd.nic.fr. IN TLSA >=20 > ;; ANSWER SECTION: > _443._tcp.dane-broken.rd.nic.fr. 1 IN TLSA 3 0 1 = 6E013C54DF90D42D3C016E1AC9EB21E6DA45403D3A5AE9B2D8F21FC3 600D409C > _443._tcp.dane-broken.rd.nic.fr. 1 IN RRSIG TLSA 5 6 1 = 20130415134103 20121017134103 24975 dane-broken.rd.nic.fr. = UFaeHhxVp8zy1tpcR049JqGEvNZrmDLkpgoo63v4gvEtwLp0KRbSBL5J = vVlNnz8s5Uk68i8diY/zGt1epP72C2S6C3AUHKdYZiwvxBQwd34Sawna = jZMjfAkXEH5z9cjkk1AVm0ReRPs9kbVc0iPDLcH+z21VJBZyFmloOflM EXU=3D >=20 > ;; Query time: 838 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Fri Oct 19 08:49:24 2012 > ;; MSG SIZE rcvd: 288 >=20 >=20 >> On 09/12/2012 10:44 PM, Paul Wouters wrote: >>> On Wed, 12 Sep 2012, Marco Davids (SIDN) wrote: >>>=20 >>>> On 08/23/12 20:02, Paul Wouters wrote: >>>>=20 >>>>> I put up the xpi as well, you can grab it at: >>>>> http://people.redhat.com/pwouters/mozilla-extval-0.7.xpi >>>>=20 >>>> I like it. >>>>=20 >>>> However, there might be room for improvent in the wording of the = the >>>> messages. >>>>=20 >>>> I deliberately broke the TLSA record (https://forfun.net/) and the >>>> message is (in green): >>>>=20 >>>> "Domainname is secured by DNSSEC and the certificate is validated = by >>>> CA." >>>>=20 >>>> Both true, but as a paranoid user, I would have appreciated a = little bit >>>> more information, like: >>>>=20 >>>> "... but the certificate did not pass a DANE check" >>>>=20 >>>> (or something similar) >>>=20 >>> It should do that. When I check your domain it tells me there is no = TLSA >>> record, but I checked all name servers and it is there (and = incorrect) >>>=20 >>> I'll add it on my TODO list :) >>>=20 >>> Paul >>> _______________________________________________ >>> dns-operations mailing list >>> dns-operations@lists.dns-oarc.net >>> https://lists.dns-oarc.net/mailman/listinfo/dns-operations >>> dns-jobs mailing list >>> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs >>=20 >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane > --=20 > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 -- After you'd known Christine for any length of time, you found yourself = fighting a desire to look into her ear to see if you could spot daylight = coming the other way. -- (Terry Pratchett, Maskerade) From marka@isc.org Thu Oct 18 15:52:17 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 938E51F0424 for ; Thu, 18 Oct 2012 15:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id noBMD7OCjEd1 for ; Thu, 18 Oct 2012 15:52:17 -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 E55B01F0417 for ; Thu, 18 Oct 2012 15:52:16 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 80FFFC947E; Thu, 18 Oct 2012 22:52:08 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 4A046216C7B; Thu, 18 Oct 2012 22:52:08 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 393372A0069B; Fri, 19 Oct 2012 09:52:06 +1100 (EST) To: Warren Kumari From: Mark Andrews References: <201207311641.q6VGf8EK078660@calcite.rhyolite.com> <50360192.7080806@afnic.fr> <50362FE0.40407@afnic.fr> <50507EF9.7030803@sidn.nl> <507FB355.4030908@afnic.fr> <20121018215605.CBB8929FFFAA@drugs.dv.isc.org> In-reply-to: Your message of "Thu, 18 Oct 2012 18:43:38 EDT." Date: Fri, 19 Oct 2012 09:52:06 +1100 Message-Id: <20121018225206.393372A0069B@drugs.dv.isc.org> Cc: dns-operations@mail.dns-oarc.net, dane@ietf.org Subject: Re: [dane] [dns-operations] DNSSEC DANE testing X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 18 Oct 2012 22:52:17 -0000 In message , Warren Kumari wri tes: > > On Oct 18, 2012, at 5:56 PM, Mark Andrews wrote: > > >=20 > > In message <507FB355.4030908@afnic.fr>, sandoche BALAKRICHENAN writes: > >> Hi Paul, > >>=20 > >> I have deliberately added a bogus RRSIG record to > >> "https://dane-broken.rd.nic.fr". But the firefox add-on seems to > >> successfully validate mentioning "the domain is secured by DNSSEC". > >>=20 > >> Sandoche. > >=20 > > Well the TLSA is secure. As long as that matches the CERT returned = > it *is* > > secured even if the RRSIG on the A RRset is broken. > > Ooooh=85 This is an interesting case (which I personally hadn't = > considered)...=20 > > This all makes sense, but "feels" odd=85 Not proposing that we do = > anything, but it did make me blink=85. It also helps w/ DNS64. You don't need to care if the AAAA lookups are forged or not for https connections as long as you get to a server which presents the correct certificate and passes the handshake. You do need to care for http connection. Mark > W -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From benl@google.com Fri Oct 19 03:08:28 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2A5D21F8634 for ; Fri, 19 Oct 2012 03:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSG9fH61YTgX for ; Fri, 19 Oct 2012 03:08:28 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 8F2D121F8643 for ; Fri, 19 Oct 2012 03:08:27 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id hm2so63185wib.1 for ; Fri, 19 Oct 2012 03:08:26 -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:content-transfer-encoding:x-system-of-record; bh=lqzhHOI9+ctbvrEUJThq4Z9QsvPzx/3MqXy8z48skv8=; b=U/0MOJeeWLk+L39SRsNLkYScM2Yj8+OMepfOrzwL3eb/3E94A+Jym3wb809INZojFI aAzgmIHsrSSrE/WocM8mJpLov3KjOXNPMGxrXEkEUbzNpnLMgt6lUwKTwIxLXlqlHGBe UGRd8m//Yq70avMorczGqm+10Y/cDvNCX+xB2j0vBPcTQKOFDqFwmbq5nQX9zp5IpeSh cgHw/bm/94RKRhBlhcRHzVhoKBpCGkIShRWqxAxclcegohVWeRzNnLwtSqvqgJJ8Fg7C hFqIFBb3Ac0MTuYTlOQk6cFqeenYN3ortBmJbcROnQJ7wMqSgud2dZtshqxnlhuvAiPa nAUg== 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:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=lqzhHOI9+ctbvrEUJThq4Z9QsvPzx/3MqXy8z48skv8=; b=HgcvWNix3P3XxsRzg20iI/E+QdVT4YuY/fOIAkdk2RxZsKiUrRIAgQVCJb6JMkczkU Jnv/bav/9dha4onN0xhx1/5BMGvawHKjMJ/omU4FpVvgqpJEpvNY7mnoN5FWBTxMOOFm MfBufS7PF7NWyyO644izqfNE8dvmcOJ6eLXkfWgt2YLBwtkp0P/KkgFXV4QJ1FYiQ5a2 9mH3hWiMo7hbjN2hnBdthWUEm9AOKGhUvn8NgYXcD973nepDXcmYmgxWAhRMf2fs9UiI HS/1ivILBy4dKd0is9Ybhuf0oJ0tLIGz0zIqxH1XlPuVR2AkjRwz5ZErtxM7B+KkOuop ECuQ== MIME-Version: 1.0 Received: by 10.180.104.97 with SMTP id gd1mr2065800wib.4.1350641303965; Fri, 19 Oct 2012 03:08:23 -0700 (PDT) Received: by 10.216.236.201 with HTTP; Fri, 19 Oct 2012 03:08:23 -0700 (PDT) In-Reply-To: References: <201207311641.q6VGf8EK078660@calcite.rhyolite.com> <50360192.7080806@afnic.fr> <50362FE0.40407@afnic.fr> <50507EF9.7030803@sidn.nl> <507FB355.4030908@afnic.fr> <20121018215605.CBB8929FFFAA@drugs.dv.isc.org> Date: Fri, 19 Oct 2012 11:08:23 +0100 Message-ID: From: Ben Laurie To: Warren Kumari Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQnSu4R6bPh+GtyT8k6ZyeuJUGx2xFggGG6AznQaKn+tVx8XXeRwk2lhDCLmh8/B4lNE+XbvFTgmv8ZS+bwXAa7E3xUkUTPWgM6jrH4m2syEbtLJDLq2eCuFa3gj4VMcEZXKca1CmVOqVuCNhYbInM/U3y+0H+UMo8PQXDeBMgDMlPqORZN2vBjR5muUlfHoOYcmdSUr Cc: dns-operations@mail.dns-oarc.net, dane@ietf.org Subject: Re: [dane] [dns-operations] DNSSEC DANE testing X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Oct 2012 10:08:29 -0000 On 18 October 2012 23:43, Warren Kumari wrote: > > On Oct 18, 2012, at 5:56 PM, Mark Andrews wrote: > >> >> In message <507FB355.4030908@afnic.fr>, sandoche BALAKRICHENAN writes: >>> Hi Paul, >>> >>> I have deliberately added a bogus RRSIG record to >>> "https://dane-broken.rd.nic.fr". But the firefox add-on seems to >>> successfully validate mentioning "the domain is secured by DNSSEC". >>> >>> Sandoche. >> >> Well the TLSA is secure. As long as that matches the CERT returned it = *is* >> secured even if the RRSIG on the A RRset is broken. > > Ooooh=85 This is an interesting case (which I personally hadn't considere= d)... > > This all makes sense, but "feels" odd=85 Not proposing that we do anythin= g, but it did make me blink=85. Feels right to me - who cares what the address is if they have the right ce= rt? > > W > > > >> >> ; <<>> DiG 9.10.0pre-alpha <<>> _443._tcp.dane-broken.rd.nic.fr tlsa +dn= ssec >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52053 >> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 >> >> ;; OPT PSEUDOSECTION: >> ; EDNS: version: 0, flags: do; udp: 4096 >> ;; QUESTION SECTION: >> ;_443._tcp.dane-broken.rd.nic.fr. IN TLSA >> >> ;; ANSWER SECTION: >> _443._tcp.dane-broken.rd.nic.fr. 1 IN TLSA 3 0 1 6E013C54DF90D42D3C01= 6E1AC9EB21E6DA45403D3A5AE9B2D8F21FC3 600D409C >> _443._tcp.dane-broken.rd.nic.fr. 1 IN RRSIG TLSA 5 6 1 20130415134103 = 20121017134103 24975 dane-broken.rd.nic.fr. UFaeHhxVp8zy1tpcR049JqGEvNZrmDL= kpgoo63v4gvEtwLp0KRbSBL5J vVlNnz8s5Uk68i8diY/zGt1epP72C2S6C3AUHKdYZiwvxBQwd= 34Sawna jZMjfAkXEH5z9cjkk1AVm0ReRPs9kbVc0iPDLcH+z21VJBZyFmloOflM EXU=3D >> >> ;; Query time: 838 msec >> ;; SERVER: 127.0.0.1#53(127.0.0.1) >> ;; WHEN: Fri Oct 19 08:49:24 2012 >> ;; MSG SIZE rcvd: 288 >> >> >>> On 09/12/2012 10:44 PM, Paul Wouters wrote: >>>> On Wed, 12 Sep 2012, Marco Davids (SIDN) wrote: >>>> >>>>> On 08/23/12 20:02, Paul Wouters wrote: >>>>> >>>>>> I put up the xpi as well, you can grab it at: >>>>>> http://people.redhat.com/pwouters/mozilla-extval-0.7.xpi >>>>> >>>>> I like it. >>>>> >>>>> However, there might be room for improvent in the wording of the the >>>>> messages. >>>>> >>>>> I deliberately broke the TLSA record (https://forfun.net/) and the >>>>> message is (in green): >>>>> >>>>> "Domainname is secured by DNSSEC and the certificate is validated by >>>>> CA." >>>>> >>>>> Both true, but as a paranoid user, I would have appreciated a little = bit >>>>> more information, like: >>>>> >>>>> "... but the certificate did not pass a DANE check" >>>>> >>>>> (or something similar) >>>> >>>> It should do that. When I check your domain it tells me there is no TL= SA >>>> record, but I checked all name servers and it is there (and incorrect) >>>> >>>> I'll add it on my TODO list :) >>>> >>>> Paul >>>> _______________________________________________ >>>> dns-operations mailing list >>>> dns-operations@lists.dns-oarc.net >>>> https://lists.dns-oarc.net/mailman/listinfo/dns-operations >>>> dns-jobs mailing list >>>> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs >>> >>> _______________________________________________ >>> dane mailing list >>> dane@ietf.org >>> https://www.ietf.org/mailman/listinfo/dane >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: marka@isc.org >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >> > > -- > After you'd known Christine for any length of time, you found yourself fi= ghting a desire to look into her ear to see if you could spot daylight comi= ng the other way. > > -- (Terry Pratchett, Maskerade) > > > > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From mrex@sap.com Fri Oct 19 03:59:42 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27BA321F8779 for ; Fri, 19 Oct 2012 03:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.203 X-Spam-Level: X-Spam-Status: No, score=-10.203 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHD58uojpxFg for ; Fri, 19 Oct 2012 03:59:41 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id CE76B21F8698 for ; Fri, 19 Oct 2012 03:59:40 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q9JAxcZV008872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 19 Oct 2012 12:59:39 +0200 (MEST) In-Reply-To: To: Warren Kumari Date: Fri, 19 Oct 2012 12:59:38 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20121019105938.98D621A2E1@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: dns-operations@mail.dns-oarc.net, dane@ietf.org Subject: Re: [dane] [dns-operations] DNSSEC DANE testing X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 10:59:42 -0000 Warren Kumari wrote: > > Mark Andrews wrote: >> >> sandoche BALAKRICHENAN writes: >>> Hi Paul, >>> >>> I have deliberately added a bogus RRSIG record to >>> "https://dane-broken.rd.nic.fr". But the firefox add-on seems to >>> successfully validate mentioning "the domain is secured by DNSSEC". >>> >>> Sandoche. >> >> Well the TLSA is secure. As long as that matches the CERT returned it *is* >> secured even if the RRSIG on the A RRset is broken. > > Ooooh? This is an interesting case (which I personally hadn't considered)... > > This all makes sense, but "feels" odd? Not proposing that we do > anything, but it did make me blink?. Somehow I can not follow your discussion. What exactly do you mean by "added a bogus RRSIG record"? If the DNSSEC signature on the TLSA record can _not_ be verified, then the Browser MUST NOT flag the Server as being DANE-verified. When the server cert has been issued from a public CA, and the zone is either without DNSSEC or verifiably without TLSA record for the server, then the browser is doing a regular TLS handshake and traditional (rfc2818 section 3.1) server endpoint identification. Certs from private CAs or self-signed certs must continue to result in the scary-page. -Martin From fanf2@hermes.cam.ac.uk Fri Oct 19 04:13:31 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E94E21F8589 for ; Fri, 19 Oct 2012 04:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.06 X-Spam-Level: X-Spam-Status: No, score=-4.06 tagged_above=-999 required=5 tests=[AWL=-1.461, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dughl7nNT5Rs for ; Fri, 19 Oct 2012 04:13:30 -0700 (PDT) Received: from ppsw-43.csi.cam.ac.uk (ppsw-43.csi.cam.ac.uk [131.111.8.143]) by ietfa.amsl.com (Postfix) with ESMTP id CBB1021F852B for ; Fri, 19 Oct 2012 04:13:29 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:53139) by ppsw-43.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1TPAW1-0006GI-ot (Exim 4.72) (return-path ); Fri, 19 Oct 2012 12:13:21 +0100 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1TPAW1-0006eA-OT (Exim 4.72) (return-path ); Fri, 19 Oct 2012 12:13:21 +0100 Date: Fri, 19 Oct 2012 12:13:21 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Warren Kumari In-Reply-To: Message-ID: References: <201207311641.q6VGf8EK078660@calcite.rhyolite.com> <50360192.7080806@afnic.fr> <50362FE0.40407@afnic.fr> <50507EF9.7030803@sidn.nl> <507FB355.4030908@afnic.fr> <20121018215605.CBB8929FFFAA@drugs.dv.isc.org> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1870869256-1172412539-1350645201=:20044" Sender: Tony Finch Cc: dns-operations@mail.dns-oarc.net, dane@ietf.org Subject: Re: [dane] [dns-operations] DNSSEC DANE testing X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Oct 2012 11:13:31 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1870869256-1172412539-1350645201=:20044 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Warren Kumari wrote: > On Oct 18, 2012, at 5:56 PM, Mark Andrews wrote: > > > > Well the TLSA is secure. As long as that matches the CERT returned it= *is* > > secured even if the RRSIG on the A RRset is broken. > > Ooooh=E2=80=A6 This is an interesting case (which I personally hadn't con= sidered)... > > This all makes sense, but "feels" odd=E2=80=A6 Not proposing that we do > anything, but it did make me blink=E2=80=A6. This came up when I was working on the SRV/MX drafts. The SRV indirection needs to be secure, and the TLSA needs to be secure, but that's it. Tony. --=20 f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first= =2E Rough, becoming slight or moderate. Showers, rain at first. Moderate or goo= d, occasionally poor at first. --1870869256-1172412539-1350645201=:20044-- From marka@isc.org Fri Oct 19 06:01:00 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8DA221F8521 for ; Fri, 19 Oct 2012 06:01:00 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id du1pM1YuTlq1 for ; Fri, 19 Oct 2012 06:01:00 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 09B6021F851E for ; Fri, 19 Oct 2012 06:01:00 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 784CD5F9908; Fri, 19 Oct 2012 13:00:48 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:c501:27de:9a78:48f1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id A1687216C3B; Fri, 19 Oct 2012 13:00:46 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id AC0D92A0A4D5; Sat, 20 Oct 2012 00:00:39 +1100 (EST) To: mrex@sap.com From: Mark Andrews References: <20121019105938.98D621A2E1@ld9781.wdf.sap.corp> In-reply-to: Your message of "Fri, 19 Oct 2012 12:59:38 +0200." <20121019105938.98D621A2E1@ld9781.wdf.sap.corp> Date: Sat, 20 Oct 2012 00:00:39 +1100 Message-Id: <20121019130039.AC0D92A0A4D5@drugs.dv.isc.org> Cc: dns-operations@mail.dns-oarc.net, dane@ietf.org Subject: Re: [dane] [dns-operations] DNSSEC DANE testing X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Oct 2012 13:01:00 -0000 In message <20121019105938.98D621A2E1@ld9781.wdf.sap.corp>, Martin Rex writes: > Warren Kumari wrote: > > > > Mark Andrews wrote: > >> > >> sandoche BALAKRICHENAN writes: > >>> Hi Paul, > >>> > >>> I have deliberately added a bogus RRSIG record to > >>> "https://dane-broken.rd.nic.fr". But the firefox add-on seems to > >>> successfully validate mentioning "the domain is secured by DNSSEC". > >>> > >>> Sandoche. > >> > >> Well the TLSA is secure. As long as that matches the CERT returned it *i > s* > >> secured even if the RRSIG on the A RRset is broken. > > > > Ooooh? This is an interesting case (which I personally hadn't considered).. > . > > > > This all makes sense, but "feels" odd? Not proposing that we do > > anything, but it did make me blink?. > > > Somehow I can not follow your discussion. > What exactly do you mean by "added a bogus RRSIG record"? The A and SOA signatures were broken, not the TLSA. > If the DNSSEC signature on the TLSA record can _not_ be verified, > then the Browser MUST NOT flag the Server as being DANE-verified. It could be verified. > When the server cert has been issued from a public CA, and the > zone is either without DNSSEC or verifiably without TLSA record > for the server, then the browser is doing a regular TLS handshake > and traditional (rfc2818 section 3.1) server endpoint identification. > > Certs from private CAs or self-signed certs must continue to > result in the scary-page. > > -Martin > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From benl@google.com Fri Oct 19 06:54:27 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0AA21F8589 for ; Fri, 19 Oct 2012 06:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNlgzSeAuV70 for ; Fri, 19 Oct 2012 06:54:26 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 75DCF21F8570 for ; Fri, 19 Oct 2012 06:54:26 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hq12so228102wib.13 for ; Fri, 19 Oct 2012 06:54: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 :cc:content-type:x-system-of-record; bh=SdTzhjKYbVLHVuaSflqHCgdnDugMPKYB2hmL7CGziUo=; b=Q4YpKgK3QwdeEWl6ddoh6/JcJLcwCp48eJvRo1idlhYtpwheaP5yI/4qXqyPSyJlpC i1qouY3TPVvQk6F1Z4hSZgWPbNuix7H5nV6nqJWLjrnPRAw8ChUhyc7dBiZ1EoCYdbMu ooeYXL4XntuK6vTnwSEVYQEEMmjKoni3h7E5rHIsBuQwBM1Z+EgTwa1V/1ymt3vKRi/d C6J1ERDeNM+jBO5ppAffVSisu+6hoZ/iwzr2+yKdU3pFvDmVkoMUjZFiJpRrfqdv4DT0 qlM9ZsiNc3zvrLnOylsBo4nZfXYS/O2aScAFIrEV46qKLN3xYAxyj753u82R5NPnwIy2 jlag== 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-system-of-record:x-gm-message-state; bh=SdTzhjKYbVLHVuaSflqHCgdnDugMPKYB2hmL7CGziUo=; b=i7Lyf3jSk/D8z9D0sFWsTYgTl6wP+X1z410qaCtltOqTXUkqDD4BIAJ8LSTxfnHFgJ OwSbBSMN5BaTHjiMQM7+ifYeOpAj20OxkDnhLZCCuJ5RNNNiETwYX9k+Wt5zfp0aRQGZ 1V/ZagAMFD/kFjenMPzMffctZNywdpKZuYqaTRWMla38PLhptwIVirSbbEKpThxd+6+x DtAnTy73AuDWV0KkgA286pDswlGRvSwABRcMR3N2rgZ/CoQ1r3TDVRO2k9hdeawNdDk2 Sw6ADc+cG5r1/UP3mMU9Qqt2b2V631RCixbiwas/Z+7G0jYMgUm83opjwwLXceJfZa+V L7Nw== MIME-Version: 1.0 Received: by 10.216.131.161 with SMTP id m33mr906368wei.13.1350654865460; Fri, 19 Oct 2012 06:54:25 -0700 (PDT) Received: by 10.216.236.201 with HTTP; Fri, 19 Oct 2012 06:54:25 -0700 (PDT) In-Reply-To: References: <5d02bc4a698aacf66886e72842b87514.squirrel@webmail.dreamhost.com> Date: Fri, 19 Oct 2012 14:54:25 +0100 Message-ID: From: Ben Laurie To: Phillip Hallam-Baker Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkxHeurYQ6v0Yo/SFJH/vxVB0GE8a+f9VTOXFZKRdmZ69dv5DKgYHitG6yhOkTJO3Jxl5scbK3vSX0Evr1tEmi57hq+qk9i9Ngs+6mI4aP78nUe9gLukrTQvWktEV6Xo5wm09F5YDgpurDW/8Yv9zSu/U/rSkeGH1WK122A4wFu2gIUNYwkp25yngH7awmybrbR2CAk Cc: dane WG list Subject: Re: [dane] + add security ... (was : Re: an implementor's comments on 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, 19 Oct 2012 13:54:27 -0000 On 16 October 2012 15:48, Phillip Hallam-Baker wrote: > I think that is a rather naive assessment. > > Most of us do not want to be dependent on a single root of trust that is > ultimately under the physical control of VeriSign and the legal control of > ICANN, a body whose insistence that it is above criticism should be deeply > troubling. Attempts to concentrate trust in one place have invariably proved > to be unstable. > > DLV is not the solution but it may be a useful contribution to a solution. How about a solution that doesn't require you to trust anyone - namely Certificate Transparency? > > > > > On Mon, Oct 15, 2012 at 11:56 AM, Paul Wouters wrote: >> >> On Sun, 14 Oct 2012, Ryan Sleevi wrote: >> >>> For DANE, presumably solutions would use some form of DNSSEC rewriting, >>> with DLV >> >> >> That's not the purpose of DLV. DLV is going to die sooner rather then >> later, >> and no infrastructure should be build up to use it for such purpose. >> >> I hope the operator of the DLV registry will confirm this in strong terms. >> >> Paul >> >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane > > > > > -- > Website: http://hallambaker.com/ > > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > From rbarnes@bbn.com Fri Oct 19 07:07:36 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE4FA21F8639 for ; Fri, 19 Oct 2012 07:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.591 X-Spam-Level: X-Spam-Status: No, score=-106.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTT3DjLahwov for ; Fri, 19 Oct 2012 07:07:34 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 7781021F8596 for ; Fri, 19 Oct 2012 07:07:34 -0700 (PDT) Received: from ros-dhcp192-1-51-103.bbn.com ([192.1.51.103]:64002) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TPDEQ-0000LK-U4; Fri, 19 Oct 2012 10:07:22 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Richard Barnes In-Reply-To: Date: Fri, 19 Oct 2012 10:07:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <817270F4-5501-408B-BC78-A95D547E6713@bbn.com> References: <5d02bc4a698aacf66886e72842b87514.squirrel@webmail.dreamhost.com> To: Ben Laurie X-Mailer: Apple Mail (2.1283) Cc: dane WG list Subject: Re: [dane] + add security ... (was : Re: an implementor's comments on 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, 19 Oct 2012 14:07:36 -0000 On Oct 19, 2012, at 9:54 AM, Ben Laurie wrote: > On 16 October 2012 15:48, Phillip Hallam-Baker = wrote: >> I think that is a rather naive assessment. >>=20 >> Most of us do not want to be dependent on a single root of trust that = is >> ultimately under the physical control of VeriSign and the legal = control of >> ICANN, a body whose insistence that it is above criticism should be = deeply >> troubling. Attempts to concentrate trust in one place have invariably = proved >> to be unstable. >>=20 >> DLV is not the solution but it may be a useful contribution to a = solution. >=20 > How about a solution that doesn't require you to trust anyone - namely > Certificate Transparency? Let's not be hyperbolic here. You still have to trust the whitelist/log = operator, since he can DoS by not including certificates in his log. But this is drifting pretty far off-topic... --Richard >>=20 >>=20 >>=20 >>=20 >> On Mon, Oct 15, 2012 at 11:56 AM, Paul Wouters = wrote: >>>=20 >>> On Sun, 14 Oct 2012, Ryan Sleevi wrote: >>>=20 >>>> For DANE, presumably solutions would use some form of DNSSEC = rewriting, >>>> with DLV >>>=20 >>>=20 >>> That's not the purpose of DLV. DLV is going to die sooner rather = then >>> later, >>> and no infrastructure should be build up to use it for such purpose. >>>=20 >>> I hope the operator of the DLV registry will confirm this in strong = terms. >>>=20 >>> Paul >>>=20 >>> _______________________________________________ >>> dane mailing list >>> dane@ietf.org >>> https://www.ietf.org/mailman/listinfo/dane >>=20 >>=20 >>=20 >>=20 >> -- >> Website: http://hallambaker.com/ >>=20 >>=20 >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >>=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From benl@google.com Fri Oct 19 07:22:58 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5760021F86E9 for ; Fri, 19 Oct 2012 07:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xn-V5QeNEMzH for ; Fri, 19 Oct 2012 07:22:57 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 44D9821F85A4 for ; Fri, 19 Oct 2012 07:22:57 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hr7so248091wib.13 for ; Fri, 19 Oct 2012 07:22:55 -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:x-system-of-record; bh=fIgZ+GN5NHsLAruz3LnSKqW6skqyk4k6siJTsCubpEk=; b=kAqJl+yRROao6Ab+ugnTajRIrl7bX0Whpu9UYcFAm8Cx4HvGGxIWbT0HVVT9R4Gbzx pih2UvmTzZ3T/6ZdIarQCEXK7i1TjYqCIPCGyBGY0bG6f9FGnUZQPZNWRGT+K0fRDMyn A9auPkCUFAyBKOKQ4RrO9TofnHWtjhUrP1ZqQipFzUV6yGqu09o7uS8O3OaFM4QSLSZt PskS8WibAyeTiVef0QeLS0leyx4SZprLRz8az9XLHlQoyfqZ7wR86vaPxIFsBgrNoI7V bhUgXtA/zSSjGBjd8aFiJAMVx4A3ow9KA+V3T48sUl+K12rtAtnDkay3iAs4oi/2j3jy iE5Q== 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-system-of-record:x-gm-message-state; bh=fIgZ+GN5NHsLAruz3LnSKqW6skqyk4k6siJTsCubpEk=; b=ByWwnAJXG3Z6LJYGMxE3tY8QRGZbPRjy61uTfdYxHFBJQ8WSNbnVRaW1sMfyak+Nsr XlRE8Hayrtvaq6jx4EXuXGcUJx7hG4QmQyNDfCu3DopFrc2zoUceFTO/q6qYkfm4RqwT f40eD8auq8OguCu4M81BXTAb0Ni0ilijArWiHzRRY+h9m8SEsissFAWJMjA9+zW8Cz/T /HJcctE75CewTKfKQY4rTk5ZFr7LOTz7qA3dZMhWzSWmKQKOZWZg0D9D/gg40n323tKN GVU70ezNDVPgZ9Td0Hkjmn0GuVQEjUQvESMYpu1RTAfmuRmvdTRcYaCNQWQizBZqTnGI Mvog== MIME-Version: 1.0 Received: by 10.216.197.133 with SMTP id t5mr832108wen.176.1350656575439; Fri, 19 Oct 2012 07:22:55 -0700 (PDT) Received: by 10.216.236.201 with HTTP; Fri, 19 Oct 2012 07:22:54 -0700 (PDT) In-Reply-To: <817270F4-5501-408B-BC78-A95D547E6713@bbn.com> References: <5d02bc4a698aacf66886e72842b87514.squirrel@webmail.dreamhost.com> <817270F4-5501-408B-BC78-A95D547E6713@bbn.com> Date: Fri, 19 Oct 2012 15:22:54 +0100 Message-ID: From: Ben Laurie To: Richard Barnes Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnBDAccvdcdYWc5m9rimijjcx34rZAdVQETQjdcInAnrZ7zneW/MD5mYYm7GTr1ScsBOf9WCKISwOHVq+IQKSSKTLYZbnopvyUtYLM4fL/pL5724Ae+0em8poFaI3MRkKzqAQw2lKxxuFJikx6uvAnTDIeF5AUsejR/1qBu6X5IJguAwl9ukGfw+WxtVjjRrH+WhamH Cc: dane WG list Subject: Re: [dane] + add security ... (was : Re: an implementor's comments on 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, 19 Oct 2012 14:22:58 -0000 On 19 October 2012 15:07, Richard Barnes wrote: > > On Oct 19, 2012, at 9:54 AM, Ben Laurie wrote: > >> On 16 October 2012 15:48, Phillip Hallam-Baker wrote: >>> I think that is a rather naive assessment. >>> >>> Most of us do not want to be dependent on a single root of trust that is >>> ultimately under the physical control of VeriSign and the legal control of >>> ICANN, a body whose insistence that it is above criticism should be deeply >>> troubling. Attempts to concentrate trust in one place have invariably proved >>> to be unstable. >>> >>> DLV is not the solution but it may be a useful contribution to a solution. >> >> How about a solution that doesn't require you to trust anyone - namely >> Certificate Transparency? > > Let's not be hyperbolic here. You still have to trust the whitelist/log operator, since he can DoS by not including certificates in his log. I guess it would not be hard to prove that the log is doing that - the whole point of CT being that misbehaviour can always be demonstrated. > But this is drifting pretty far off-topic... Well, DANE is about improving TLS, and so is CT :-) > > --Richard > > > > >>> >>> >>> >>> >>> On Mon, Oct 15, 2012 at 11:56 AM, Paul Wouters wrote: >>>> >>>> On Sun, 14 Oct 2012, Ryan Sleevi wrote: >>>> >>>>> For DANE, presumably solutions would use some form of DNSSEC rewriting, >>>>> with DLV >>>> >>>> >>>> That's not the purpose of DLV. DLV is going to die sooner rather then >>>> later, >>>> and no infrastructure should be build up to use it for such purpose. >>>> >>>> I hope the operator of the DLV registry will confirm this in strong terms. >>>> >>>> Paul >>>> >>>> _______________________________________________ >>>> dane mailing list >>>> dane@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dane >>> >>> >>> >>> >>> -- >>> Website: http://hallambaker.com/ >>> >>> >>> _______________________________________________ >>> dane mailing list >>> dane@ietf.org >>> https://www.ietf.org/mailman/listinfo/dane >>> >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane > From hallam@gmail.com Fri Oct 19 07:42:52 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A239721F847B for ; Fri, 19 Oct 2012 07:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.926 X-Spam-Level: X-Spam-Status: No, score=-3.926 tagged_above=-999 required=5 tests=[AWL=-0.328, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7JuApVImdOVt for ; Fri, 19 Oct 2012 07:42:51 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id A44D021F850B for ; Fri, 19 Oct 2012 07:42:51 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n5so619777oag.31 for ; Fri, 19 Oct 2012 07:42:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Lide29TFzltU+uFGyXb+jTKHHsDwqp0pencA5ouAMFE=; b=IjUz3bglZIAiDWK8l50m7NZaLxy4n8PKFHTNOVrB53lHALGGEr0L7JT8JiREwJ8Wyb +U8w/jNRiIOun7YAZ+iJ6mJ7rN/P1i1TbI88qW2dhkI8/4C3QPHUXs1uYAqOm+HrMRzG lTa07fHFQgvxRFdkbqV7DD/rSvVdHo9neLDS85haYm4h1/FUMl7FKCg2F+VMaomnmUEf NNiGCcKRcnukqDuvqlJ+a+P1nhdYOpPuHnS71GYQGTPHoRM3zS0jLGar99EwpOhUpTs8 wz48mk5GnKjkqwaPDahhjeLYZQ4eekBu+unqjz75HMEoZH3EIvrZFakZICv7SZ4RrdTk 5kWw== MIME-Version: 1.0 Received: by 10.182.54.103 with SMTP id i7mr585524obp.62.1350657771165; Fri, 19 Oct 2012 07:42:51 -0700 (PDT) Received: by 10.76.27.103 with HTTP; Fri, 19 Oct 2012 07:42:50 -0700 (PDT) In-Reply-To: References: <5d02bc4a698aacf66886e72842b87514.squirrel@webmail.dreamhost.com> Date: Fri, 19 Oct 2012 10:42:50 -0400 Message-ID: From: Phillip Hallam-Baker To: Ben Laurie Content-Type: multipart/alternative; boundary=14dae93a113da9d8f704cc6a84f6 Cc: dane WG list Subject: Re: [dane] + add security ... (was : Re: an implementor's comments on 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, 19 Oct 2012 14:42:52 -0000 --14dae93a113da9d8f704cc6a84f6 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 19, 2012 at 9:54 AM, Ben Laurie wrote: > On 16 October 2012 15:48, Phillip Hallam-Baker wrote: > > I think that is a rather naive assessment. > > > > Most of us do not want to be dependent on a single root of trust that is > > ultimately under the physical control of VeriSign and the legal control > of > > ICANN, a body whose insistence that it is above criticism should be > deeply > > troubling. Attempts to concentrate trust in one place have invariably > proved > > to be unstable. > > > > DLV is not the solution but it may be a useful contribution to a > solution. > > How about a solution that doesn't require you to trust anyone - namely > Certificate Transparency? I would not go that far for CT. I think Transparency is the most important new idea in security for quite a while. But Transparency does not remove the need to trust the certificate issuer to do the job right. It merely creates a more effective feedback loop. While there is not a lot of difference in terms of the strength of the trust provided, the consequences for the cost of providing that cost are significant. CT does not eliminate the need for CAs to run their facilities correctly and validate cert requests effectively. All CT does is to create a new stick to beat the ones that don't. Now if you had actually created a mechanism that did not require trust at all and it was possible to administer it in a practical way (contra Sovereign Keys) then you could eliminate those costs. Now there might be a way to graft CT onto DNSSEC via DLV and maybe we should look at that as well. There is a big policy level incentive to do that as the mono-root structure is far too much of a liability right now. I don't think any of us would be at all comfortable with ITU running that root. And the SCO faction are certainly not going to accept ICANN running that root. So what we are headed for right now is a fracture of the root. At present I think we should concentrate on CT for PKIX. But if things spin out of control in Dubai we might well find that this is a much more urgent question. Though not one that is likely to be viable in IETF given the popularity of my IPv6 Sovereign Allocation proposal here. -- Website: http://hallambaker.com/ --14dae93a113da9d8f704cc6a84f6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Oct 19, 2012 at 9:54 AM, Ben Lau= rie <benl@google.com> wrote:
On 16 October 2012 15:48, Phillip Hallam-Baker <hallam@gmail.com> wrote:
> I think that is a rather naive assessment.
>
> Most of us do not want to be dependent on a single root of trust that = is
> ultimately under the physical control of VeriSign and the legal contro= l of
> ICANN, a body whose insistence that it is above criticism should be de= eply
> troubling. Attempts to concentrate trust in one place have invariably = proved
> to be unstable.
>
> DLV is not the solution but it may be a useful contribution to a solut= ion.

How about a solution that doesn't require you to trust anyone - n= amely
Certificate Transparency?

I would not go th= at far for CT.

I think Transparency is the most im= portant new idea in security for quite a while. But Transparency does not r= emove the need to trust the certificate issuer to do the job right. It mere= ly creates a more effective feedback loop.

While there is not a lot of difference in terms of the = strength of the trust provided, the consequences for the cost of providing = that cost are significant. CT does not eliminate the need for CAs to run th= eir facilities correctly and validate cert requests effectively. All CT doe= s is to create a new stick to beat the ones that don't.


Now if you had actually created a mechan= ism that did not require trust at all and it was possible to administer it = in a practical way (contra Sovereign Keys) then you could eliminate those c= osts.

Now there might be a way to graft CT onto DNSSEC via DL= V and maybe we should look at that as well. There is a big policy level inc= entive to do that as the mono-root structure is far too much of a liability= right now. I don't think any of us would be at all comfortable with IT= U running that root. And the SCO faction are certainly not going to accept = ICANN running that root. So what we are headed for right now is a fracture = of the root.

At present I think we should concentrate on CT for PKIX= . But if things spin out of control in Dubai we might well find =A0that thi= s is a much more urgent question. Though not one that is likely to be viabl= e in IETF given the popularity of my IPv6 Sovereign Allocation proposal her= e.=A0
=A0

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

--14dae93a113da9d8f704cc6a84f6-- From paul@cypherpunks.ca Fri Oct 19 15:30:32 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1409721F8839 for ; Fri, 19 Oct 2012 15:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.287 X-Spam-Level: X-Spam-Status: No, score=-2.287 tagged_above=-999 required=5 tests=[AWL=0.312, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YzDOUzg+f6G1 for ; Fri, 19 Oct 2012 15:30:31 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 9126121F8838 for ; Fri, 19 Oct 2012 15:30:31 -0700 (PDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id E5C4382B34; Fri, 19 Oct 2012 18:30:08 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id DD2FE82B2B; Fri, 19 Oct 2012 18:30:08 -0400 (EDT) Date: Fri, 19 Oct 2012 18:30:08 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Mark Andrews In-Reply-To: <20121019130039.AC0D92A0A4D5@drugs.dv.isc.org> Message-ID: References: <20121019105938.98D621A2E1@ld9781.wdf.sap.corp> <20121019130039.AC0D92A0A4D5@drugs.dv.isc.org> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dns-operations@mail.dns-oarc.net, dane WG list Subject: Re: [dane] [dns-operations] DNSSEC DANE testing X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Oct 2012 22:30:32 -0000 On Sat, 20 Oct 2012, Mark Andrews wrote: >> Somehow I can not follow your discussion. >> What exactly do you mean by "added a bogus RRSIG record"? > > The A and SOA signatures were broken, not the TLSA. > >> If the DNSSEC signature on the TLSA record can _not_ be verified, >> then the Browser MUST NOT flag the Server as being DANE-verified. > > It could be verified. Of course, in my case, I could not reach the server because my DNSSEC capable resolver could not get a proper A record. When going "insecure", I could reach it, but then it flags red because _you_ are not using a DNSSEC resolver, and it does mistakenly claim "domainname is secured by DNSSEC", which with a broken A record is not the case. I'll work on fixing this. Paul From alex@net-me.net Tue Oct 23 04:27:24 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D52E21F86F4 for ; Tue, 23 Oct 2012 04:27:24 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b39SbixiBrwd for ; Tue, 23 Oct 2012 04:27:23 -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 5F45021F86E9 for ; Tue, 23 Oct 2012 04:27:23 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so4500224vbb.31 for ; Tue, 23 Oct 2012 04:27:22 -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:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=umnPJtfh7uTjGoTEEqUIUJL8q0SPf7J+Xrm2mYw3NJQ=; b=GxUmyEkCJDv3ZEkQMwvEzJv1ICG+JRd6zSxtCHSoetrsfgcGhhIJkKITSqnt9+lADe eBhGwH7q3ptzqVGEttAv0Cwx8AKGE2Ge3lRFjCC3nE15a4zb8zlmzIYTkPjLnoLp0HAH 6MmPpMqaejJ6rCoRzcWhMABJLuqGEyeAaQxXIx6ZdMrknJIePS10+pke+OTWAt/r1M1R G6fU2rD5LyFm7YDlOlYbjMn4A8aZAHKc79z9kjq07pZG+LzKhT0SX6dcITZruTM+9KR3 IBEaKyfRKP6JzqjHWQveENqYHuKle7tX4fUirxh5IK7Mk9mNclZFSfnFhmFWxaWOwZRb D8sg== MIME-Version: 1.0 Received: by 10.58.243.166 with SMTP id wz6mr3146202vec.28.1350991642330; Tue, 23 Oct 2012 04:27:22 -0700 (PDT) Received: by 10.58.162.135 with HTTP; Tue, 23 Oct 2012 04:27:22 -0700 (PDT) X-Originating-IP: [194.90.125.170] Date: Tue, 23 Oct 2012 13:27:22 +0200 Message-ID: From: Alexander Gurvitz To: dane@ietf.org Content-Type: multipart/alternative; boundary=047d7b86f4b2ef876504ccb84074 X-Gm-Message-State: ALoCoQmTFoBBftzjV8lQ+rT1yHSUy+TDlD/ChbZF3pk93Ty6mXgmqMLLYUUPRhU2doqQC3mg8Ij/ Subject: [dane] Cert. Usage 0/1 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 11:27:24 -0000 --047d7b86f4b2ef876504ccb84074 Content-Type: text/plain; charset=ISO-8859-1 Hello. http://tools.ietf.org/html/rfc6394#section-3.1 : > Continuing to require PKIX validation also limits the degree to which > DNS operators (as distinct from the holders of domains) can interfere > with TLS authentication through this mechanism. As above, even if a > DNS operator falsifies DANE records, it cannot masquerade as the > target server unless it can also obtain a certificate for the target > domain. This seems like a mistake to me - DNS operator can always issue a fraudulent usage 2/3 record, and thus skip the CA validation. The only advantage I can see in usage 0/1, is that it allows CA-based certificate revocation in case of the private key compromise. Alexaner Gurvitz, net-me.net --047d7b86f4b2ef876504ccb84074 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello.
=A0
Continuing to require PKIX validation = also limits the degree to which
DNS operators (as distinct from the holders of domains) can interfere
wi= th TLS authentication through this mechanism. As above, even if a
DNS op= erator falsifies DANE records, it cannot masquerade as the
target server= unless it can also obtain a certificate for the target
domain.

This seems like a mistake to me= - DNS operator can always=A0issue a fraudulent usage 2/3 record,
and thus skip the CA validation.

The only advantage I can see in usage 0/1, is that it allows CA-based certi= ficate revocation
in case of the private key compromise.

Alexaner Gurvitz,

--047d7b86f4b2ef876504ccb84074-- From mrex@sap.com Tue Oct 23 06:59:36 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4714A21F8686 for ; Tue, 23 Oct 2012 06:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.211 X-Spam-Level: X-Spam-Status: No, score=-10.211 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDp6ZsA7FScf for ; Tue, 23 Oct 2012 06:59:35 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 82A8421F8678 for ; Tue, 23 Oct 2012 06:59:35 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q9NDxXjj015825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 23 Oct 2012 15:59:34 +0200 (MEST) In-Reply-To: To: Alexander Gurvitz Date: Tue, 23 Oct 2012 15:59:32 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20121023135932.3D86C1A2EE@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] Cert. Usage 0/1 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 13:59:36 -0000 Alexander Gurvitz wrote: > > http://tools.ietf.org/html/rfc6394#section-3.1 : > > > Continuing to require PKIX validation also limits the degree to which > > DNS operators (as distinct from the holders of domains) can interfere > > with TLS authentication through this mechanism. As above, even if a > > DNS operator falsifies DANE records, it cannot masquerade as the > > target server unless it can also obtain a certificate for the target > > domain. > > > This seems like a mistake to me - DNS operator can always issue a > fraudulent usage 2/3 record, and thus skip the CA validation. Nope. The DNS operator can only indicate his intention. The TLS client might not even look at DANE / TLSA records at all, or the TLS client might be configure to warn for DANE TLSA 2/3 records (although maybe with a less intimidating scary page than what current browsers are showing for untrusted server certs today). > > The only advantage I can see in usage 0/1, is that it allows CA-based > certificate revocation in case of the private key compromise. The information that is stored in DNS really is not trustworthy, and the desired continued low cost of adding/changing DNS records ensures that DNS records will never become trustworthy. DNSSEC may add data integrity protection and data origin authentication for the DNS records that it protects, but it does exactly ZERO about the lack of trustworthyness of most data in the DNS. If you search google via HTTPS rather than HTTP, the result list is not going to become any more trustworthy. It will only be harder for attackers anywhere between google and you to modify your request or google's response. -Martin PS: however, the entry-level "Domain validated" (DV) certs from public CAs feed on DNS data (AFAIK minus typosquatting), so it is difficult to conceive how DV-certs could be noticably more trustworthy than information provided through DANE. From dgq2011@gmail.com Tue Oct 23 07:38:54 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7836321F8673 for ; Tue, 23 Oct 2012 07:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.774 X-Spam-Level: X-Spam-Status: No, score=-0.774 tagged_above=-999 required=5 tests=[AWL=2.825, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id opSROqzKLDPr for ; Tue, 23 Oct 2012 07:38:53 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA9921F8659 for ; Tue, 23 Oct 2012 07:38:53 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so6317243iec.31 for ; Tue, 23 Oct 2012 07:38:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=j+mWkJ2mE3uLgqDUHEXWRWH4s+QLt9wBRVFLdLF8ZQg=; b=fIrAZWH5pTpHJvFyxIEZDTdLC2upA2AJSLvTQBZKzAbqUz9S8svlJ3SSs8hBEoOYOG u6AUkdrtxMfeXQMeQY6WTv2v+XNs4glKlcGDK76TGk5kkqDOkgYf/XpX894qape1gsKp jiI5kWgzU4/9g2XcftWb/Y+Cc579iWaWvB5mhAAZXPKEWGzLDJWCnBaNfKLi9sq2KFO5 JLBbdew3UYY0+mYEpgO5gZkdUpZiYjcnZsZbs0I8qadVmvRcN0Mur6YK8iE0Xn3kgzQ5 /f7Ka9d07q0cbk13PU//985w+2AUnA3/8HIqXX4AiY8Ztxr7j0VMWep0InL7k0X4kcsI maGg== MIME-Version: 1.0 Received: by 10.50.155.193 with SMTP id vy1mr12589651igb.67.1351003133184; Tue, 23 Oct 2012 07:38:53 -0700 (PDT) Received: by 10.64.39.137 with HTTP; Tue, 23 Oct 2012 07:38:53 -0700 (PDT) In-Reply-To: References: Date: Tue, 23 Oct 2012 22:38:53 +0800 Message-ID: From: Guangqing Deng To: Alexander Gurvitz Content-Type: multipart/alternative; boundary=e89a8f3bafe5d80a9604ccbaedeb Cc: dane@ietf.org Subject: Re: [dane] Cert. Usage 0/1 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 14:38:54 -0000 --e89a8f3bafe5d80a9604ccbaedeb Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 2012/10/23 Alexander Gurvitz > Hello. > > http://tools.ietf.org/html/rfc6394#section-3.1 : > > >> Continuing to require PKIX validation also limits the degree to which >> DNS operators (as distinct from the holders of domains) can interfere >> with TLS authentication through this mechanism. As above, even if a >> DNS operator falsifies DANE records, it cannot masquerade as the >> target server unless it can also obtain a certificate for the target >> domain. > > > This seems like a mistake to me - DNS operator can always issue a > fraudulent usage 2/3 record, > and thus skip the CA validation. > Remind that the section 3.1 just discusses the =93CA Constraints=94 which refers to usage 0 TLSA record but not usage 2/3 TLSA records, which is discussed in other sections. So, the statement =93even if a DNS operator falsifies DANE records, it cannot masquerade as the target server unless it can also obtain a certificate for the target domain=94 is correct. > > The only advantage I can see in usage 0/1, is that it allows CA-based > certificate revocation > in case of the private key compromise. > > Alexaner Gurvitz, > net-me.net > > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > > --=20 Guangqing Deng --e89a8f3bafe5d80a9604ccbaedeb Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

2012/10/23 Alexander Gurvitz <alex@net-= me.net>
Hello.
=A0
Continuing to require PKIX validation = also limits the degree to which
DNS operators (as distinct from the holders of domains) can interfere
wi= th TLS authentication through this mechanism. As above, even if a
DNS op= erator falsifies DANE records, it cannot masquerade as the
target server= unless it can also obtain a certificate for the target
domain.

This seems like a mistake to me= - DNS operator can always=A0issue a fraudulent usage 2/3 record,
and thus skip the CA validation.
=A0
=

Remind that the section 3.1 jus= t discusses the =93CA Constraints=94 which refers to usage 0 TLSA record but not usage 2/3 TLSA r= ecords, which is discussed in other sections. So, the statement =93even if a DNS op= erator falsifies DANE records, it cannot masquerade as the target server unless it= can also obtain a certificate for the target domain=94 is correct.

=A0

The only advantage I can see in usage 0/1, is that it allows CA-based certi= ficate revocation
in case of the private key compromise.

Alexaner Gurvitz,


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




--
Guangqing Deng
<= br> --e89a8f3bafe5d80a9604ccbaedeb-- From paul@cypherpunks.ca Tue Oct 23 14:02:23 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B78D1F0C92 for ; Tue, 23 Oct 2012 14:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.317 X-Spam-Level: X-Spam-Status: No, score=-2.317 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QB83-PRLBbBH for ; Tue, 23 Oct 2012 14:02:22 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id D859C1F0424 for ; Tue, 23 Oct 2012 14:02:22 -0700 (PDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id ED3DC8101E; Tue, 23 Oct 2012 17:01:48 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id E1E3F802A5; Tue, 23 Oct 2012 17:01:48 -0400 (EDT) Date: Tue, 23 Oct 2012 17:01:48 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Guangqing Deng In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=UTF-8 Content-Transfer-Encoding: 8BIT Cc: dane WG list Subject: Re: [dane] Cert. Usage 0/1 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 21:02:23 -0000 On Tue, 23 Oct 2012, Guangqing Deng wrote: > 2012/10/23 Alexander Gurvitz > Hello. >   > http://tools.ietf.org/html/rfc6394#section-3.1 : >   > Continuing to require PKIX validation also limits the degree to which > DNS operators (as distinct from the holders of domains) can interfere > with TLS authentication through this mechanism. As above, even if a > DNS operator falsifies DANE records, it cannot masquerade as the > target server unless it can also obtain a certificate for the target > domain. > > > This seems like a mistake to me - DNS operator can always issue a fraudulent usage 2/3 record, > and thus skip the CA validation. > >   > > Remind that the section 3.1 just discusses the “CA Constraints” which refers to usage 0 TLSA record but not usage 2/3 TLSA records, which > is discussed in other sections. So, the statement “even if a DNS operator falsifies DANE records, it cannot masquerade as the target > server unless it can also obtain a certificate for the target domain” is correct. But it can, just by updating the A/AAAA record to a server it owns. I vague remember pointing out this exact mistake in the draft. I guess we all kind of missed updating it in the end. Paul From marka@isc.org Tue Oct 23 16:20:56 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFCA41F0C96 for ; Tue, 23 Oct 2012 16:20:55 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEPQ-PNME4a0 for ; Tue, 23 Oct 2012 16:20:54 -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 4C8391F0C3A for ; Tue, 23 Oct 2012 16:20:54 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 61F3EC9483; Tue, 23 Oct 2012 23:20:46 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:a472:c6c7:f410:8e42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 2A455216C3B; Tue, 23 Oct 2012 23:20:46 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 2424F2A2553C; Wed, 24 Oct 2012 10:20:44 +1100 (EST) To: Paul Wouters From: Mark Andrews References: In-reply-to: Your message of "Tue, 23 Oct 2012 17:01:48 EDT." Date: Wed, 24 Oct 2012 10:20:44 +1100 Message-Id: <20121023232044.2424F2A2553C@drugs.dv.isc.org> Cc: dane WG list Subject: Re: [dane] Cert. Usage 0/1 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 23:20:56 -0000 In message , Paul Wouters w rites: > On Tue, 23 Oct 2012, Guangqing Deng wrote: > > > 2012/10/23 Alexander Gurvitz > > Hello. > >   > > http://tools.ietf.org/html/rfc6394#section-3.1 : > >   > > Continuing to require PKIX validation also limits the degree to > which > > DNS operators (as distinct from the holders of domains) can > interfere > > with TLS authentication through this mechanism. As above, even if > a > > DNS operator falsifies DANE records, it cannot masquerade as the > > target server unless it can also obtain a certificate for the > target > > domain. > > > > > > This seems like a mistake to me - DNS operator can always issue a > fraudulent usage 2/3 record, > > and thus skip the CA validation. > > > >   > > > > Remind that the section 3.1 just discusses the “CA Constraints” which > refers to usage 0 TLSA record but not usage 2/3 TLSA records, which > > is discussed in other sections. So, the statement “even if a DNS > operator falsifies DANE records, it cannot masquerade as the target > > server unless it can also obtain a certificate for the target domain” > is correct. > > But it can, just by updating the A/AAAA record to a server it owns. It can masquerade as the machine hosting the server/service, not the server/service itself. > I vague remember pointing out this exact mistake in the draft. I guess > we all kind of missed updating it in the end. > > Paul > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From dgq2011@gmail.com Tue Oct 23 18:43:26 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47BAA11E8160 for ; Tue, 23 Oct 2012 18:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.186 X-Spam-Level: X-Spam-Status: No, score=-2.186 tagged_above=-999 required=5 tests=[AWL=1.412, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHujWpc6Fe+f for ; Tue, 23 Oct 2012 18:43:24 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id ADEA011E8153 for ; Tue, 23 Oct 2012 18:43:24 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so14091iec.31 for ; Tue, 23 Oct 2012 18:43:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rXGEhMRysQml8/yHJPSYo3sB/A18xP8jY4lptbLgMCg=; b=HRF8CQn8P76fD8UjKC3p/ThGt/PJVckhZwocOq2ecfPFlCVRyWUHhfRNDJfUP/d54j VKusWtlj7uH2uazq/rG8QQPUPsIDxZxVfd0iLdQ46PsSnsqXNuvMAX2kbCvdrif1E/cM 5I46TUv1qQ6+aybyE9+cZKqnzI0qCPavd4E+B0IYGbPLEwkNFfM3v9dRLa9QLPSgw9Tn gOdKLxZ+z9YhMrkF3l+TBqxPXSgpQYQUDkwQ1f22O1AYPUaXYt1gQvRHvA49fRXHQ5Sp HmH26lUbFGOWa8h+AifEElpODdVFuljqNMpX0DrYrsgx7OV/F02FWNARZqygICg4Qvpo g/8A== MIME-Version: 1.0 Received: by 10.50.185.230 with SMTP id ff6mr735275igc.7.1351043004363; Tue, 23 Oct 2012 18:43:24 -0700 (PDT) Received: by 10.64.39.137 with HTTP; Tue, 23 Oct 2012 18:43:24 -0700 (PDT) In-Reply-To: References: Date: Wed, 24 Oct 2012 09:43:24 +0800 Message-ID: From: Guangqing Deng To: Paul Wouters Content-Type: multipart/alternative; boundary=14dae934068159f23f04ccc436b0 Cc: dane WG list Subject: Re: [dane] Cert. Usage 0/1 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 01:43:26 -0000 --14dae934068159f23f04ccc436b0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 2012/10/24 Paul Wouters > On Tue, 23 Oct 2012, Guangqing Deng wrote: > > 2012/10/23 Alexander Gurvitz >> Hello. >> >> http://tools.ietf.org/html/rfc6394#section-3.1 : >> >> Continuing to require PKIX validation also limits the degree to >> which >> DNS operators (as distinct from the holders of domains) can >> interfere >> with TLS authentication through this mechanism. As above, even if = a >> DNS operator falsifies DANE records, it cannot masquerade as the >> target server unless it can also obtain a certificate for the targ= et >> domain. >> >> >> This seems like a mistake to me - DNS operator can always issue a >> fraudulent usage 2/3 record, >> and thus skip the CA validation. >> >> >> >> Remind that the section 3.1 just discusses the =93CA Constraints=94 whic= h >> refers to usage 0 TLSA record but not usage 2/3 TLSA records, which >> is discussed in other sections. So, the statement =93even if a DNS opera= tor >> falsifies DANE records, it cannot masquerade as the target >> server unless it can also obtain a certificate for the target domain=94 = is >> correct. >> > > But it can, just by updating the A/AAAA record to a server it owns. > What you pointed out is about the incorrect configuration of DNS resource records, which may be another story. Just as previously discussed in this mailing list, DNSSEC may add data integrity protection and data origin authentication but definitely not the trustworthiness for the DNS resource records that it protects. If the DNS operator is going to do something bad (such as incorrectly configuring DNS resource records) intentionally or unintentionally, DNSSEC cannot stop the DNS operator from doing that. > > I vague remember pointing out this exact mistake in the draft. I guess > we all kind of missed updating it in the end. > > Paul > --=20 Guangqing Deng --14dae934068159f23f04ccc436b0 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable

2012/10/24 Paul Wouters <paul@cypherp= unks.ca>
On Tue, 23 Oct 2012, Guangqing Deng wrote:

2012/10/23 Alexander Gurvitz <alex@net-me.net>
      Hello.
 
http://tools.ietf.org/html/rfc6394#section-3.1 :
 
      Continuing to require PKIX validation also limits the = degree to which
      DNS operators (as distinct from the holders of domains= ) can interfere
      with TLS authentication through this mechanism. As abo= ve, even if a
      DNS operator falsifies DANE records, it cannot masquer= ade as the
      target server unless it can also obtain a certificate = for the target
      domain.


This seems like a mistake to me - DNS operator can always issue a frau= dulent usage 2/3 record,
and thus skip the CA validation.

 

Remind that the section 3.1 just discusses the “CA Constraints”= which refers to usage 0 TLSA record but not usage 2/3 TLSA records, which<= br> is discussed in other sections. So, the statement “even if a DNS oper= ator falsifies DANE records, it cannot masquerade as the target
server unless it can also obtain a certificate for the target domain”= is correct.

But it can, just by updating the A/AAAA record to a server it owns.
 
What you poin= ted out is about the incorrect configuration of DNS resource records, which may be ano= ther story. Just as previously discussed in this mailing list, DNSSEC may add da= ta integrity protection and data origin authentication but definitely not the = trustworthiness for the DNS resource records tha= t it protects. If the DNS operator is going to do something bad (such as inco= rrectly configuring DNS resource records) intentionally or unintentionally, DNSSEC cannot stop the DNS operator from doing that.
 

I vague remember pointing out this exact mistake in the draft. I guess
we all kind of missed updating it in the end.

Paul



--
Guangqing= Deng

--14dae934068159f23f04ccc436b0-- From paul@cypherpunks.ca Tue Oct 23 19:07:05 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8926411E811E for ; Tue, 23 Oct 2012 19:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.329 X-Spam-Level: X-Spam-Status: No, score=-2.329 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cDKv+7-vknPS for ; Tue, 23 Oct 2012 19:07:04 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB1511E80E9 for ; Tue, 23 Oct 2012 19:07:04 -0700 (PDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 1FAC88101E; Tue, 23 Oct 2012 22:06:28 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 0E718802A5; Tue, 23 Oct 2012 22:06:28 -0400 (EDT) Date: Tue, 23 Oct 2012 22:06:28 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Guangqing Deng In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Cc: dane WG list Subject: Re: [dane] Cert. Usage 0/1 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 02:07:05 -0000 On Wed, 24 Oct 2012, Guangqing Deng wrote: > usage 0 TLSA record but not usage 2/3 TLSA records, which > is discussed in other sections. So, the statement “even if a DNS operator falsifies > DANE records, it cannot masquerade as the target > server unless it can also obtain a certificate for the target domain” is correct. > > > But it can, just by updating the A/AAAA record to a server it owns. > >   > What you pointed out is about the incorrect configuration of DNS resource records, which may be another > story. Just as previously discussed in this mailing list, DNSSEC may add data integrity protection and data > origin authentication but definitely not the trustworthiness for the DNS resource records that it protects. > If the DNS operator is going to do something bad (such as incorrectly configuring DNS resource records) > intentionally or unintentionally, DNSSEC cannot stop the DNS operator from doing that. And if DNSSEC TLSA records claim things about PKIX, that can be changed too. So I still don't understand your point (or Mark's) Paul From dgq2011@gmail.com Tue Oct 23 19:45:51 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD7E11F0C89 for ; Tue, 23 Oct 2012 19:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.657 X-Spam-Level: X-Spam-Status: No, score=-2.657 tagged_above=-999 required=5 tests=[AWL=0.942, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D+HCa3gQiitC for ; Tue, 23 Oct 2012 19:45:51 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 145C81F0C7E for ; Tue, 23 Oct 2012 19:45:51 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so72245iec.31 for ; Tue, 23 Oct 2012 19:45:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=O1kkA3ivFYYkVqn01YLbes8XSBAP0+P3R7OZBxA9qtg=; b=LCGzvfcHUYP+edcCxGdsXnfMEFGOmusg/mIZEtxmLVDpiSyTnbVh0SYTf04FpRZvkS DlTqt0va5d5VzVfrJAA/WENkxBrPFK4d3mFBT+HyrvQJY7UH1v572nTdWSwIgEcih4FU ojcJIpFZXSlxSEZUn0ZvHDVwo/iVSwJHX4IV4k98pwZlWrChINUHhHvL21m0Sdcx3+zU bCmGCLgNEkwZRd0VNlXC7KEqlbwsabt/ZOgLYXCtvnzHPv2ws4MAJpphqTzKls6ZyYdO 1RQ9Stssei9o5I0fSmrV5e+qLAPpDBwI9kWKqSYe/0nJFBrSplw21xPVbxuJCkTDmpRB 9OZg== MIME-Version: 1.0 Received: by 10.50.216.129 with SMTP id oq1mr742530igc.7.1351046750735; Tue, 23 Oct 2012 19:45:50 -0700 (PDT) Received: by 10.64.39.137 with HTTP; Tue, 23 Oct 2012 19:45:50 -0700 (PDT) In-Reply-To: References: Date: Wed, 24 Oct 2012 10:45:50 +0800 Message-ID: From: Guangqing Deng To: Paul Wouters Content-Type: multipart/alternative; boundary=14dae9340cf1a70bf504ccc5157b Cc: dane WG list Subject: Re: [dane] Cert. Usage 0/1 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 02:45:51 -0000 --14dae9340cf1a70bf504ccc5157b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 2012/10/24 Paul Wouters > On Wed, 24 Oct 2012, Guangqing Deng wrote: > > usage 0 TLSA record but not usage 2/3 TLSA records, which >> is discussed in other sections. So, the statement =93even if= a >> DNS operator falsifies >> DANE records, it cannot masquerade as the target >> server unless it can also obtain a certificate for the targe= t >> domain=94 is correct. >> >> >> But it can, just by updating the A/AAAA record to a server it owns. >> >> >> What you pointed out is about the incorrect configuration of DNS resourc= e >> records, which may be another >> story. Just as previously discussed in this mailing list, DNSSEC may add >> data integrity protection and data >> origin authentication but definitely not the trustworthiness for the DNS >> resource records that it protects. >> If the DNS operator is going to do something bad (such as incorrectly >> configuring DNS resource records) >> intentionally or unintentionally, DNSSEC cannot stop the DNS operator >> from doing that. >> > > And if DNSSEC TLSA records claim things about PKIX, that can be changed > too. > Definitely, DNSSEC TLSA records claiming things about PKIX can be changed by the DNS operator. And one goal of DANE protocol is to restrict the scope of certificate used by the TLS client to authenticate the TLS server. For example, DNS operator can put the public key of a specific CA in the TLSA record to tell the TLS client that just the certificate issued by that CA is reliable. If the currently recommended CA is not reliable any more, of course, DNS operator can modify the TLSA record and add the information of a newly chosen CA in the TLSA record. > > So I still don't understand your point (or Mark's) > > Paul > --=20 Guangqing Deng --14dae9340cf1a70bf504ccc5157b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

2012/10/24 Paul Wouters <paul@cypherp= unks.ca>
On Wed, 24 Oct 2012, Guangqing Deng wrote:

=A0 =A0 =A0 =A0 =A0 =A0 usage 0 TLSA record but not usage 2/3 TLSA records,= which
=A0 =A0 =A0 =A0 =A0 =A0 is discussed in other sections. So, the statement = =93even if a DNS operator falsifies
=A0 =A0 =A0 =A0 =A0 =A0 DANE records, it cannot masquerade as the target =A0 =A0 =A0 =A0 =A0 =A0 server unless it can also obtain a certificate for = the target domain=94 is correct.


But it can, just by updating the A/AAAA record to a server it owns.

=A0
What you pointed out is about the incorrect configuration of DNS resource r= ecords, which may be another
story. Just as previously discussed in this mailing list, DNSSEC may add da= ta integrity protection and data
origin authentication but definitely not the trustworthiness for the DNS re= source records that it protects.
If the DNS operator is going to do something bad (such as incorrectly confi= guring DNS resource records)
intentionally or unintentionally, DNSSEC cannot stop the DNS operator from = doing that.

And if DNSSEC TLSA records claim things about PKIX, that can be changed
too.
=A0
Definitely, DNSSEC TLSA records cla= iming things about PKIX can be changed by the DNS operator. And one goal of= DANE protocol is to restrict the scope of certificate used by the TLS clie= nt to authenticate the TLS server. For example, DNS operator can put the pu= blic key of a specific CA in the TLSA record to tell the TLS client that ju= st the certificate issued by that CA is reliable. If the currently recommen= ded CA is not reliable any more, of course, DNS operator can modify the TLS= A record and add the information of a newly chosen CA in the TLSA record. =A0

So I still don't understand your point (or Mark's)

Paul



--
Guangqing= Deng

--14dae9340cf1a70bf504ccc5157b-- From gnu@toad.com Wed Oct 24 00:08:49 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B771521F8CF6 for ; Wed, 24 Oct 2012 00:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.933 X-Spam-Level: X-Spam-Status: No, score=0.933 tagged_above=-999 required=5 tests=[AWL=0.836, BAYES_00=-2.599, RCVD_IN_NJABL_RELAY=2.696] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mm-tkW+In7D8 for ; Wed, 24 Oct 2012 00:08:30 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id D34CC21F8CF5 for ; Wed, 24 Oct 2012 00:08:30 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id q9O78P2N008118; Wed, 24 Oct 2012 00:08:25 -0700 Message-Id: <201210240708.q9O78P2N008118@new.toad.com> To: Mark Andrews In-reply-to: <20121023232044.2424F2A2553C@drugs.dv.isc.org> References: <20121023232044.2424F2A2553C@drugs.dv.isc.org> Comments: In-reply-to Mark Andrews message dated "Wed, 24 Oct 2012 10:20:44 +1100." Date: Wed, 24 Oct 2012 00:08:25 -0700 From: John Gilmore Cc: dane WG list Subject: Re: [dane] Cert. Usage 0/1 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 07:08:49 -0000 Yes, section 3.1's statement is foolish, because it limits itself by saying "through this mechanism" at the end of the first sentence: Continuing to require PKIX validation also limits the degree to which DNS operators (as distinct from the holders of domains) can interfere with TLS authentication through this mechanism. As above, even if a DNS operator falsifies DANE records, it cannot masquerade as the target server unless it can also obtain a certificate for the target domain. Through the "CA Constraints" mechanism, a DNS operator cannot falsify DANE records to masquerade as the target server. However, through other readily available mechanisms, a DNS operator can EASILY falsify DANE records to masquerade as the target server. The statement is literally true as written, but is misleading about the actual level of security provided in the real world by publishing a "CA Constraint" TLSA record through an untrustworthy DNS operator. John