Re: [keyassure] Objective: Restrictive versus Supplementary Models

[Paul Wouters <[e-mail]>]

On Thu, 31 Mar 2011, Yoav Nir wrote:

> Cert-lock (and CA-lock) are what EKR calls supplementary, while the others are the restrictive. While the sever (and domain owner) can't dictate client policy, they should be able to indicate whether the Certificate (TA or EE) that's in the TLSA record is supposed to be validatable or not. The client (relying party) may have a policy to ignore records that push a non-valid certificate, but if you're going to publish a record with a certificate that you have just issued using openssl on your laptop and expires in 1975, the TLSA record had better reflect that this certificate is just a container for a public key, not something you can chain and validate.
>
> So I think the requirements document should describe EKR's use cases, and require that the TLSA record be able to differentiate between records that are appropriate for the two use cases.

Are you really suggesting some kind of indicator that says "you can ignore the cruft from the cert that is bogus
that I vouched for via the RRSIG"?

Paul


From [e-mail]  Mon Apr  4 12:04:42 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69EB63A67AA for <[e-mail]>; Mon,  4 Apr 2011 12:04:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.303
X-Spam-Level: 
X-Spam-Status: No, score=-1.303 tagged_above=-999 required=5 tests=[AWL=0.600,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396,  RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPBLS3aO8TqY for <[e-mail]>; Mon,  4 Apr 2011 12:04:41 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 456E53A6452 for <[e-mail]>; Mon,  4 Apr 2011 12:04:37 -0700 (PDT)
Received: by bwz13 with SMTP id 13so4678343bwz.31 for <[e-mail]>; Mon, 04 Apr 2011 12:06:20 -0700 (PDT)
Received: by 10.204.22.202 with SMTP id o10mr334259bkb.70.1301943979964; Mon, 04 Apr 2011 12:06:19 -0700 (PDT)
Received: from [109.183.187.166] (109-183-187-166.tmcz.cz [109.183.187.166]) by mx.google.com with ESMTPS id z18sm3285780bkf.20.2011.04.04.12.06.13 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Apr 2011 12:06:19 -0700 (PDT)
From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= <[e-mail]>
Content-Type: text/plain; charset=utf-8
X-Mailer: iPhone Mail (8G4)
Message-Id: <[e-mail]>
Date: Mon, 4 Apr 2011 21:06:02 +0200
To: "[e-mail]" <[e-mail]>
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (iPhone Mail 8G4)
X-Mailman-Approved-At: Mon, 04 Apr 2011 14:31:11 -0700
Subject: [dane] The dane list was created
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 04 Apr 2011 19:04:42 -0000

Hi,

the new list was created and all settings have been created. Please start us=
ing the new name.

Thank you,
Ond=C5=99ej Sur=C3=BD=

From [e-mail]  Mon Apr  4 16:38:37 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E1823A6805 for <[e-mail]>; Mon,  4 Apr 2011 16:38:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.055
X-Spam-Level: 
X-Spam-Status: No, score=-3.055 tagged_above=-999 required=5 tests=[AWL=-0.457, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhOoOlOkyxNw for <[e-mail]>; Mon,  4 Apr 2011 16:38:36 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id C304A3A6767 for <[e-mail]>; Mon,  4 Apr 2011 16:38:35 -0700 (PDT)
Received: by vxg33 with SMTP id 33so5475088vxg.31 for <[e-mail]>; Mon, 04 Apr 2011 16:40:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=05uziXFZYxxai9Ri4YnxMEgr38YM2LItJTNe6Mi2t2o=; b=MS6er74i1+NzNSGHK67T0HABpoRAGb95cz8QJLfncJ8m4zbCVWUp1yxgyQYkmB9mGQ e/8kMLpReJgbtT2OBVnZfdMfCx52TWOZWrTjEYhLJF7qc5UF5MR8czyJQPy1p8wl+WjL 7i4jolRt0moCQmqk+Kr59wfHHNEQSIs2VJaWM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=TNfx9xdSJyEr9oCadBT0F+qVhZ5MoeBU4Ks1TVCug/3CeZho8PUaNaO8tHIlCz0o6U tjWzNwhTWniDrnAn/6hjTzPVhg/dKLP0gvf4NDl3LNdyvJBVumBz61Jl5wGIS5sgteKU Kaq4L4nemT2jvI8Ic2uZodmezN3bTveLUIUiI=
MIME-Version: 1.0
Received: by 10.52.97.165 with SMTP id eb5mr9993695vdb.298.1301960417452; Mon, 04 Apr 2011 16:40:17 -0700 (PDT)
Received: by 10.52.161.42 with HTTP; Mon, 4 Apr 2011 16:40:17 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Tue, 5 Apr 2011 01:40:17 +0200
Message-ID: <BANLkTi=[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: Warren Kumari <[e-mail]>
Content-Type: multipart/alternative; boundary=20cf307d040831a18704a02048da
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 04 Apr 2011 23:38:37 -0000

--20cf307d040831a18704a02048da
Content-Type: text/plain; charset=ISO-8859-1

I have rather a lot of use cases and I really think people would prefer that
I edit and cull mine first. Or at minimum get them into some sort of
structured representation.

Getting them all done by Thursday is going to be rather optimistic.

On Thu, Mar 31, 2011 at 12:03 AM, Warren Kumari <[e-mail]> wrote:

> Hi there all,
>
> So it became (blindingly) clear during the meeting today that we need a
> use-cases type document to clearly explain what we believe the actual use
> cases are, what we think we can do, etc.
>
> This discussion has already progressed nicely on-list ("Objective:
> Restrictive versus Supplementary Models"), but we would like to keep the
> momentum going, strike while the iron is hot and various similar idioms, so:
>
> 1: We are asking folk to please send any additional use cases to the list
> by Thursday April 7th.
>
> 2: We are starting a consensus call to add a milestone for the use-case
> document.
> From the meeting it seems that there is likely to be strong consensus for
> creating this, but please provide input on list....
>
> I would like to apologize for not realizing earlier that the group wanted
> this document -- it is very easy to get swept up in the "Let's fix this
> thing" and assuming that everyone has the same idea of what the "thing"
> actually is.... I thought that we had figured this out on-list right back at
> the beginning of time, but a: not as clearly as I thought and b: we didn't
> clearly capture this....
>
> W
> _______________________________________________
> keyassure mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/keyassure
>



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

--20cf307d040831a18704a02048da
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<meta charset=3D"utf-8"><span class=3D"Apple-style-span" style=3D"border-co=
llapse: collapse; color: rgb(51, 51, 51); font-family: arial, sans-serif; f=
ont-size: 13px; ">I have rather a lot of use cases and I really think peopl=
e would prefer that I edit and cull mine first. Or at minimum get them into=
 some sort of structured representation.<br>
<br><div>Getting them all done by Thursday is going to be rather optimistic=
.</div></span><br><div class=3D"gmail_quote">On Thu, Mar 31, 2011 at 12:03 =
AM, Warren Kumari <span dir=3D"ltr">&lt;<a href=3D"mailto:[e-mail]=
">[e-mail]</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;">Hi there all,<br>
<br>
So it became (blindingly) clear during the meeting today that we need a use=
-cases type document to clearly explain what we believe the actual use case=
s are, what we think we can do, etc.<br>
<br>
This discussion has already progressed nicely on-list (&quot;Objective: Res=
trictive versus Supplementary Models&quot;), but we would like to keep the =
momentum going, strike while the iron is hot and various similar idioms, so=
:<br>

<br>
1: We are asking folk to please send any additional use cases to the list b=
y Thursday April 7th.<br>
<br>
2: We are starting a consensus call to add a milestone for the use-case doc=
ument.<br>
>From the meeting it seems that there is likely to be strong consensus for c=
reating this, but please provide input on list....<br>
<br>
I would like to apologize for not realizing earlier that the group wanted t=
his document -- it is very easy to get swept up in the &quot;Let&#39;s fix =
this thing&quot; and assuming that everyone has the same idea of what the &=
quot;thing&quot; actually is.... I thought that we had figured this out on-=
list right back at the beginning of time, but a: not as clearly as I though=
t and b: we didn&#39;t clearly capture this....<br>

<br>
W<br>
_______________________________________________<br>
keyassure mailing list<br>
<a href=3D"mailto:[e-mail]">[e-mail]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/keyassure" target=3D"_blan=
k">https://www.ietf.org/mailman/listinfo/keyassure</a><br>
</blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a href=3D"htt=
p://hallambaker.com/">http://hallambaker.com/</a><br><br>

--20cf307d040831a18704a02048da--

From [e-mail]  Mon Apr  4 18:26:46 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEB9A3A6833 for <[e-mail]>; Mon,  4 Apr 2011 18:26:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.558
X-Spam-Level: 
X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K0s3mywI+ZZk for <[e-mail]>; Mon,  4 Apr 2011 18:26:45 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 5DE143A6817 for <[e-mail]>; Mon,  4 Apr 2011 18:26:45 -0700 (PDT)
Received: from [128.89.255.166] (port=54970 helo=[192.168.1.10]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from <[e-mail]>) id 1Q6v4E-000Gtt-8i; Mon, 04 Apr 2011 21:28:28 -0400
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: "Richard L. Barnes" <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Mon, 4 Apr 2011 21:28:20 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]>
To: Warren Kumari <[e-mail]>
X-Mailer: Apple Mail (2.1082)
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2011 01:26:46 -0000

I kind of agree with Phillip on the deadline.  I would propose pushing =
it back to the 14th.  My responses:

1. It occurs to me that all of the technologies we're talking about =
entail a domain owner putting something in the DNS to assert something =
about their domain, which implies some expectation about how the client =
should process TLS certs.  So it might be useful to phrase use cases in =
terms of what the domain owner is asserting.  Re-stating Ekr's use cases =
in this format:

Use Case 1 "CA Lock":=20
-- The certificate my server presents in TLS will be chain to this CA. =20=

-- Clients should accept a TLS server certificate only if it chains to =
this CA, but may also require that it chain to an existing trust anchor. =
=20

Use Case 2 "Cert Lock":=20
-- The certificate my server presents in TLS will be this specific =
certificate. =20
-- Clients should accept a TLS certificate only if it matches this =
certificate, but may also require that it chain to an existing trust =
anchor.

Use Case 3 "New TA":=20
-- The certificate my server presents in TLS will chain to this CA, =
which should be treated as a TA. =20
-- Clients should accept a TLS server certificate if and only if it =
chains to this CA.

Use Case 4 "Certificate as Bare Key":=20
-- The certificate my server presents in TLS will be this specific =
certificate. =20
-- Clients should accept a TLS certificate if and only if it matches =
this certificate.

Others should feel free to use this structure for any further use cases. =
=20


2. I support the addition of the milestone.




On Mar 30, 2011, at 6:03 PM, Warren Kumari wrote:

> Hi there all,
>=20
> So it became (blindingly) clear during the meeting today that we need =
a use-cases type document to clearly explain what we believe the actual =
use cases are, what we think we can do, etc.
>=20
> This discussion has already progressed nicely on-list ("Objective: =
Restrictive versus Supplementary Models"), but we would like to keep the =
momentum going, strike while the iron is hot and various similar idioms, =
so:
>=20
> 1: We are asking folk to please send any additional use cases to the =
list by Thursday April 7th.
>=20
> 2: We are starting a consensus call to add a milestone for the =
use-case document.
> =46rom the meeting it seems that there is likely to be strong =
consensus for creating this, but please provide input on list....
>=20
> I would like to apologize for not realizing earlier that the group =
wanted this document -- it is very easy to get swept up in the "Let's =
fix this thing" and assuming that everyone has the same idea of what the =
"thing" actually is.... I thought that we had figured this out on-list =
right back at the beginning of time, but a: not as clearly as I thought =
and b: we didn't clearly capture this....
>=20
> W
> _______________________________________________
> keyassure mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/keyassure


From [e-mail]  Mon Apr  4 18:34:57 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A49E93A683B for <[e-mail]>; Mon,  4 Apr 2011 18:34:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.05
X-Spam-Level: 
X-Spam-Status: No, score=-102.05 tagged_above=-999 required=5 tests=[AWL=0.549, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYNVfOz0jHbk for <[e-mail]>; Mon,  4 Apr 2011 18:34:56 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by core3.amsl.com (Postfix) with ESMTP id 49A933A6817 for <[e-mail]>; Mon,  4 Apr 2011 18:34:56 -0700 (PDT)
Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p351abRc016593 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <[e-mail]>; Mon, 4 Apr 2011 18:36:38 -0700 (MST) (envelope-from [e-mail])
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1084)
From: Paul Hoffman <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Mon, 4 Apr 2011 18:36:37 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
To: [e-mail]
X-Mailer: Apple Mail (2.1084)
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2011 01:34:58 -0000

On Apr 4, 2011, at 6:28 PM, Richard L. Barnes wrote:

> I kind of agree with Phillip on the deadline.  I would propose pushing =
it back to the 14th.  My responses:
>=20
> 1. It occurs to me that all of the technologies we're talking about =
entail a domain owner putting something in the DNS to assert something =
about their domain, which implies some expectation about how the client =
should process TLS certs.  So it might be useful to phrase use cases in =
terms of what the domain owner is asserting.  Re-stating Ekr's use cases =
in this format:
>=20
> Use Case 1 "CA Lock":=20
> -- The certificate my server presents in TLS will be chain to this CA. =
=20
> -- Clients should accept a TLS server certificate only if it chains to =
this CA, but may also require that it chain to an existing trust anchor. =
=20
>=20
> Use Case 2 "Cert Lock":=20
> -- The certificate my server presents in TLS will be this specific =
certificate. =20
> -- Clients should accept a TLS certificate only if it matches this =
certificate, but may also require that it chain to an existing trust =
anchor.
>=20
> Use Case 3 "New TA":=20
> -- The certificate my server presents in TLS will chain to this CA, =
which should be treated as a TA. =20
> -- Clients should accept a TLS server certificate if and only if it =
chains to this CA.
>=20
> Use Case 4 "Certificate as Bare Key":=20
> -- The certificate my server presents in TLS will be this specific =
certificate. =20
> -- Clients should accept a TLS certificate if and only if it matches =
this certificate.

I like the wording in this taxonomy.

I consider 3 and 2 to be requirements, 1 to be useful, and 4 to be =
mostly uninteresting if if 3 and/or 2 are implemented.

--Paul Hoffman


From [e-mail]  Tue Apr  5 03:20:36 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48DDF28C0F0 for <[e-mail]>; Tue,  5 Apr 2011 03:20:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.977
X-Spam-Level: 
X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3mYQyNnxeY0 for <[e-mail]>; Tue,  5 Apr 2011 03:20:29 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 1ADA83A691A for <[e-mail]>; Tue,  5 Apr 2011 03:20:28 -0700 (PDT)
Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id p35AMBi0002315 for <[e-mail]>; Tue, 5 Apr 2011 03:22:11 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1301998931; bh=9vTWJ/LhiX7N4QVK83TLjIBU3e8=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=Yzse3X7VU3EXrmGM1ORgM2eEZAKp1jeyRrRe9CDppExi/+9tVkRlGwpNnnZWWST1w HWpIjAPgohJMxxZJx4fTg==
Received: from vws18 (vws18.prod.google.com [10.241.21.146]) by hpaq5.eem.corp.google.com with ESMTP id p35AM98V006086 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <[e-mail]>; Tue, 5 Apr 2011 03:22:10 -0700
Received: by vws18 with SMTP id 18so171152vws.41 for <[e-mail]>; Tue, 05 Apr 2011 03:22:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=fcrs+VZB0j9gBtCR/LGavQSVKjuoLPIz+3FfAdzBck0=; b=KLMxZG4tlnQ4fbqRP9rhM/pY6Be3DKzh28XSknQC68ng/8A1DJ4vLW8kOYOTM7y+qX bDy9xvZxh1Rjmq3J86jw==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=qJiyV/bv7dwvL5QRdSQ69eR9cX1hkNKX7JCzv5mcBoLDx4IX5IqFwYPXhpb9febvwO qPJC2vHSG32oQm7YvIVQ==
MIME-Version: 1.0
Received: by 10.52.88.233 with SMTP id bj9mr1068371vdb.131.1301998929249; Tue, 05 Apr 2011 03:22:09 -0700 (PDT)
Received: by 10.220.5.144 with HTTP; Tue, 5 Apr 2011 03:22:09 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 5 Apr 2011 11:22:09 +0100
Message-ID: <[e-mail]>
From: Ben Laurie <[e-mail]>
To: Paul Hoffman <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2011 10:20:36 -0000

On 5 April 2011 02:36, Paul Hoffman <[e-mail]> wrote:
>
> On Apr 4, 2011, at 6:28 PM, Richard L. Barnes wrote:
>
>> I kind of agree with Phillip on the deadline. =A0I would propose pushing=
 it back to the 14th. =A0My responses:
>>
>> 1. It occurs to me that all of the technologies we're talking about enta=
il a domain owner putting something in the DNS to assert something about th=
eir domain, which implies some expectation about how the client should proc=
ess TLS certs. =A0So it might be useful to phrase use cases in terms of wha=
t the domain owner is asserting. =A0Re-stating Ekr's use cases in this form=
at:
>>
>> Use Case 1 "CA Lock":
>> -- The certificate my server presents in TLS will be chain to this CA.
>> -- Clients should accept a TLS server certificate only if it chains to t=
his CA, but may also require that it chain to an existing trust anchor.
>>
>> Use Case 2 "Cert Lock":
>> -- The certificate my server presents in TLS will be this specific certi=
ficate.
>> -- Clients should accept a TLS certificate only if it matches this certi=
ficate, but may also require that it chain to an existing trust anchor.
>>
>> Use Case 3 "New TA":
>> -- The certificate my server presents in TLS will chain to this CA, whic=
h should be treated as a TA.
>> -- Clients should accept a TLS server certificate if and only if it chai=
ns to this CA.
>>
>> Use Case 4 "Certificate as Bare Key":
>> -- The certificate my server presents in TLS will be this specific certi=
ficate.
>> -- Clients should accept a TLS certificate if and only if it matches thi=
s certificate.
>
> I like the wording in this taxonomy.
>
> I consider 3 and 2 to be requirements, 1 to be useful, and 4 to be mostly=
 uninteresting if if 3 and/or 2 are implemented.

OTOH, I think 4 is vital - otherwise self-signed certs cannot be first
class citizens.

>
> --Paul Hoffman
>
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane
>

From [e-mail]  Tue Apr  5 03:41:42 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DCBA28C0E1 for <[e-mail]>; Tue,  5 Apr 2011 03:41:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.316
X-Spam-Level: 
X-Spam-Status: No, score=-3.316 tagged_above=-999 required=5 tests=[AWL=0.283,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftNcWCy+qXxZ for <[e-mail]>; Tue,  5 Apr 2011 03:41:36 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id B33793A6921 for <[e-mail]>; Tue,  5 Apr 2011 03:41:35 -0700 (PDT)
Received: by wyb29 with SMTP id 29so225727wyb.31 for <[e-mail]>; Tue, 05 Apr 2011 03:43:18 -0700 (PDT)
Received: by 10.227.177.143 with SMTP id bi15mr6279442wbb.96.1302000198010; Tue, 05 Apr 2011 03:43:18 -0700 (PDT)
Received: from bblfish.home (ALagny-751-1-3-136.w86-218.abo.wanadoo.fr [86.218.42.136]) by mx.google.com with ESMTPS id z13sm3466115wbd.63.2011.04.05.03.43.16 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Apr 2011 03:43:17 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: Henry Story <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Tue, 5 Apr 2011 12:43:14 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
To: Ben Laurie <[e-mail]>
X-Mailer: Apple Mail (2.1082)
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2011 10:41:42 -0000

On 5 Apr 2011, at 12:22, Ben Laurie wrote:

> On 5 April 2011 02:36, Paul Hoffman <[e-mail]> wrote:
>>=20
>> On Apr 4, 2011, at 6:28 PM, Richard L. Barnes wrote:
>>=20
>>> I kind of agree with Phillip on the deadline.  I would propose =
pushing it back to the 14th.  My responses:
>>>=20
>>> 1. It occurs to me that all of the technologies we're talking about =
entail a domain owner putting something in the DNS to assert something =
about their domain, which implies some expectation about how the client =
should process TLS certs.  So it might be useful to phrase use cases in =
terms of what the domain owner is asserting.  Re-stating Ekr's use cases =
in this format:
>>>=20
>>> Use Case 1 "CA Lock":
>>> -- The certificate my server presents in TLS will be chain to this =
CA.
>>> -- Clients should accept a TLS server certificate only if it chains =
to this CA, but may also require that it chain to an existing trust =
anchor.
>>>=20
>>> Use Case 2 "Cert Lock":
>>> -- The certificate my server presents in TLS will be this specific =
certificate.
>>> -- Clients should accept a TLS certificate only if it matches this =
certificate, but may also require that it chain to an existing trust =
anchor.
>>>=20
>>> Use Case 3 "New TA":
>>> -- The certificate my server presents in TLS will chain to this CA, =
which should be treated as a TA.
>>> -- Clients should accept a TLS server certificate if and only if it =
chains to this CA.
>>>=20
>>> Use Case 4 "Certificate as Bare Key":
>>> -- The certificate my server presents in TLS will be this specific =
certificate.
>>> -- Clients should accept a TLS certificate if and only if it matches =
this certificate.
>>=20
>> I like the wording in this taxonomy.
>>=20
>> I consider 3 and 2 to be requirements, 1 to be useful, and 4 to be =
mostly uninteresting if if 3 and/or 2 are implemented.
>=20
> OTOH, I think 4 is vital - otherwise self-signed certs cannot be first
> class citizens.

Indeed 4 is vital. It is what can create the biggest boost for SSL =
deployment ever. As mentioned a month or so ago on this list, MOST TLS =
endpoints deployed by far are running self signed certificates according =
to the http://www.eff.org/observatory (3 times more that working TLS =
deployments). By making it easy for those to be integrated properly, =
browsers can show TLS error messages for real cases of fraudulent sites, =
thereby increasing security dramatically on the web.

Henry


>=20
>>=20
>> --Paul Hoffman

Social Web Architect
http://bblfish.net/


From [e-mail]  Tue Apr  5 04:31:26 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19FF828C0F7 for <[e-mail]>; Tue,  5 Apr 2011 04:31:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.05
X-Spam-Level: 
X-Spam-Status: No, score=-3.05 tagged_above=-999 required=5 tests=[AWL=-0.452,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id So+-fN95+Lgy for <[e-mail]>; Tue,  5 Apr 2011 04:31:17 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 4EEE528C0DD for <[e-mail]>; Tue,  5 Apr 2011 04:31:17 -0700 (PDT)
Received: by vxg33 with SMTP id 33so232788vxg.31 for <[e-mail]>; Tue, 05 Apr 2011 04:33:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ujai8HQuBCc0Ld9SROI7t2YPRUIH0R3wDMg2YAktuDE=; b=g5TVT+Lm/Qr1S8ZfevjTLw/y2sIa0BOGz4HTl67XzUH03zsc8ywSBynLT+715loxYM ERwAuzOxrdHqlDFBAIT/GfCNu7al/2NScNJJyMCVgOnhZzv0es+hrZUopjXrUp2LJfok yIe9I5af6EBR+Xs1FSgcjqBfUU63kJun1nJkI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=t+FwPYePpfFmK9QtYp/S6tEcR421cpbU/tZvQo4nEZjWrIvL2NI8BXWxLOAiBKvIeX ZRTlLYSjYccrMlpqLGfEWGLFE2El4ovwnteNLRljH/Mir5goOruBrBaZuNnj9ntBK8kh 5oB83Kyrc5hzXWR0ocW8oBI028nds+j/ZndUY=
MIME-Version: 1.0
Received: by 10.52.70.174 with SMTP id n14mr10645964vdu.258.1302003180004; Tue, 05 Apr 2011 04:33:00 -0700 (PDT)
Received: by 10.52.161.42 with HTTP; Tue, 5 Apr 2011 04:32:59 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 5 Apr 2011 13:32:59 +0200
Message-ID: <BANLkTimNauWFBSvsvzfx4TUcU=[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: Henry Story <[e-mail]>
Content-Type: multipart/alternative; boundary=20cf3071c9d00a65df04a02a3d2f
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2011 11:31:26 -0000

--20cf3071c9d00a65df04a02a3d2f
Content-Type: text/plain; charset=ISO-8859-1

This is not a use case approach.

What we have is simply a statement of requirements which does not have any
justification in supporting use cases.


What was asked for were use cases:

[U-WS-OPP] Alice finds Sally's server through a search engine. Alice prefers
to protect her communications with cryptography if this is supported by the
sever but will communicate in plaintext otherwise.

etc. etc.



On Tue, Apr 5, 2011 at 12:43 PM, Henry Story <[e-mail]>wrote:

>
> On 5 Apr 2011, at 12:22, Ben Laurie wrote:
>
> > On 5 April 2011 02:36, Paul Hoffman <[e-mail]> wrote:
> >>
> >> On Apr 4, 2011, at 6:28 PM, Richard L. Barnes wrote:
> >>
> >>> I kind of agree with Phillip on the deadline.  I would propose pushing
> it back to the 14th.  My responses:
> >>>
> >>> 1. It occurs to me that all of the technologies we're talking about
> entail a domain owner putting something in the DNS to assert something about
> their domain, which implies some expectation about how the client should
> process TLS certs.  So it might be useful to phrase use cases in terms of
> what the domain owner is asserting.  Re-stating Ekr's use cases in this
> format:
> >>>
> >>> Use Case 1 "CA Lock":
> >>> -- The certificate my server presents in TLS will be chain to this CA.
> >>> -- Clients should accept a TLS server certificate only if it chains to
> this CA, but may also require that it chain to an existing trust anchor.
> >>>
> >>> Use Case 2 "Cert Lock":
> >>> -- The certificate my server presents in TLS will be this specific
> certificate.
> >>> -- Clients should accept a TLS certificate only if it matches this
> certificate, but may also require that it chain to an existing trust anchor.
> >>>
> >>> Use Case 3 "New TA":
> >>> -- The certificate my server presents in TLS will chain to this CA,
> which should be treated as a TA.
> >>> -- Clients should accept a TLS server certificate if and only if it
> chains to this CA.
> >>>
> >>> Use Case 4 "Certificate as Bare Key":
> >>> -- The certificate my server presents in TLS will be this specific
> certificate.
> >>> -- Clients should accept a TLS certificate if and only if it matches
> this certificate.
> >>
> >> I like the wording in this taxonomy.
> >>
> >> I consider 3 and 2 to be requirements, 1 to be useful, and 4 to be
> mostly uninteresting if if 3 and/or 2 are implemented.
> >
> > OTOH, I think 4 is vital - otherwise self-signed certs cannot be first
> > class citizens.
>
> Indeed 4 is vital. It is what can create the biggest boost for SSL
> deployment ever. As mentioned a month or so ago on this list, MOST TLS
> endpoints deployed by far are running self signed certificates according to
> the http://www.eff.org/observatory (3 times more that working TLS
> deployments). By making it easy for those to be integrated properly,
> browsers can show TLS error messages for real cases of fraudulent sites,
> thereby increasing security dramatically on the web.
>
> Henry
>
>
> >
> >>
> >> --Paul Hoffman
>
> Social Web Architect
> http://bblfish.net/
>
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane
>



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

--20cf3071c9d00a65df04a02a3d2f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This is not a use case approach.<div><br></div><div>What we have is simply =
a statement of requirements which does not have any justification in suppor=
ting use cases.</div><div><br></div><div><br></div><div>What was asked for =
were use cases:</div>
<div><br></div><div>[U-WS-OPP] Alice finds Sally&#39;s server through a sea=
rch engine. Alice prefers to protect her communications with cryptography i=
f this is supported by the sever but will communicate in plaintext otherwis=
e. =A0</div>
<div><br></div><div>etc. etc.</div><div><br></div><div><br></div><div><br><=
div class=3D"gmail_quote">On Tue, Apr 5, 2011 at 12:43 PM, Henry Story <spa=
n dir=3D"ltr">&lt;<a href=3D"mailto:[e-mail]">henry.story@bb=
lfish.net</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;"><div class=3D"im"><br>
On 5 Apr 2011, at 12:22, Ben Laurie wrote:<br>
<br>
&gt; On 5 April 2011 02:36, Paul Hoffman &lt;<a href=3D"mailto:paul.hoffman=
@vpnc.org">[e-mail]</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; On Apr 4, 2011, at 6:28 PM, Richard L. Barnes wrote:<br>
&gt;&gt;<br>
&gt;&gt;&gt; I kind of agree with Phillip on the deadline. =A0I would propo=
se pushing it back to the 14th. =A0My responses:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; 1. It occurs to me that all of the technologies we&#39;re talk=
ing about entail a domain owner putting something in the DNS to assert some=
thing about their domain, which implies some expectation about how the clie=
nt should process TLS certs. =A0So it might be useful to phrase use cases i=
n terms of what the domain owner is asserting. =A0Re-stating Ekr&#39;s use =
cases in this format:<br>

&gt;&gt;&gt;<br>
&gt;&gt;&gt; Use Case 1 &quot;CA Lock&quot;:<br>
&gt;&gt;&gt; -- The certificate my server presents in TLS will be chain to =
this CA.<br>
&gt;&gt;&gt; -- Clients should accept a TLS server certificate only if it c=
hains to this CA, but may also require that it chain to an existing trust a=
nchor.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Use Case 2 &quot;Cert Lock&quot;:<br>
&gt;&gt;&gt; -- The certificate my server presents in TLS will be this spec=
ific certificate.<br>
&gt;&gt;&gt; -- Clients should accept a TLS certificate only if it matches =
this certificate, but may also require that it chain to an existing trust a=
nchor.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Use Case 3 &quot;New TA&quot;:<br>
&gt;&gt;&gt; -- The certificate my server presents in TLS will chain to thi=
s CA, which should be treated as a TA.<br>
&gt;&gt;&gt; -- Clients should accept a TLS server certificate if and only =
if it chains to this CA.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Use Case 4 &quot;Certificate as Bare Key&quot;:<br>
&gt;&gt;&gt; -- The certificate my server presents in TLS will be this spec=
ific certificate.<br>
&gt;&gt;&gt; -- Clients should accept a TLS certificate if and only if it m=
atches this certificate.<br>
&gt;&gt;<br>
&gt;&gt; I like the wording in this taxonomy.<br>
&gt;&gt;<br>
&gt;&gt; I consider 3 and 2 to be requirements, 1 to be useful, and 4 to be=
 mostly uninteresting if if 3 and/or 2 are implemented.<br>
&gt;<br>
&gt; OTOH, I think 4 is vital - otherwise self-signed certs cannot be first=
<br>
&gt; class citizens.<br>
<br>
</div>Indeed 4 is vital. It is what can create the biggest boost for SSL de=
ployment ever. As mentioned a month or so ago on this list, MOST TLS endpoi=
nts deployed by far are running self signed certificates according to the <=
a href=3D"http://www.eff.org/observatory" target=3D"_blank">http://www.eff.=
org/observatory</a> (3 times more that working TLS deployments). By making =
it easy for those to be integrated properly, browsers can show TLS error me=
ssages for real cases of fraudulent sites, thereby increasing security dram=
atically on the web.<br>

<br>
Henry<br>
<br>
<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; --Paul Hoffman<br>
<br>
Social Web Architect<br>
<a href=3D"http://bblfish.net/" target=3D"_blank">http://bblfish.net/</a><b=
r>
<div><div></div><div class=3D"h5"><br>
_______________________________________________<br>
dane mailing list<br>
<a href=3D"mailto:[e-mail]">[e-mail]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/dane</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a=
 href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--20cf3071c9d00a65df04a02a3d2f--

From [e-mail]  Tue Apr  5 04:32:30 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39C5428C0F3 for <[e-mail]>; Tue,  5 Apr 2011 04:32:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.977
X-Spam-Level: 
X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jfo8Hgv6qLU6 for <[e-mail]>; Tue,  5 Apr 2011 04:32:22 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 9C2E628C0DD for <[e-mail]>; Tue,  5 Apr 2011 04:32:22 -0700 (PDT)
Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id p35BY5dc016797 for <[e-mail]>; Tue, 5 Apr 2011 04:34:05 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1302003245; bh=Pz9d1JCEasQRioz6LXNihBgwpDc=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=rmQYU4EMMAUVLJJUEjvLCw/tSr4Fudxcby0tCOg/toI6swfhcxFEqQwftTgFrvrBF 4tJqDCXFfwG22qsD5zhWA==
Received: from vws12 (vws12.prod.google.com [10.241.21.140]) by wpaz21.hot.corp.google.com with ESMTP id p35BY39H009904 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <[e-mail]>; Tue, 5 Apr 2011 04:34:04 -0700
Received: by vws12 with SMTP id 12so159673vws.3 for <[e-mail]>; Tue, 05 Apr 2011 04:34:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=AkA6fJeGUBKmFT29dkxsuYvZHQHk29hL23W0dOhHsBg=; b=kyjViUJvZ29HKqiyYc45qIBH/8MsFtqcHwrKSi7365S3+5u3ujmvhiaCzfFWlZsN1w jIEg02IkpVBKLYuJpuQw==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=cGN5LtlL1DpcID71bjBEpyJJfcmSyICUL1lW+7BLblBydU2je/E5xx/WsSs3gzkJRq j64KxGrT3tau3YmG3xQA==
MIME-Version: 1.0
Received: by 10.52.88.233 with SMTP id bj9mr1176646vdb.131.1302003243528; Tue, 05 Apr 2011 04:34:03 -0700 (PDT)
Received: by 10.220.5.144 with HTTP; Tue, 5 Apr 2011 04:34:03 -0700 (PDT)
In-Reply-To: <BANLkTimNauWFBSvsvzfx4TUcU=[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <BANLkTimNauWFBSvsvzfx4TUcU=[e-mail]>
Date: Tue, 5 Apr 2011 12:34:03 +0100
Message-ID: <[e-mail]>
From: Ben Laurie <[e-mail]>
To: Phillip Hallam-Baker <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2011 11:32:30 -0000

On 5 April 2011 12:32, Phillip Hallam-Baker <[e-mail]> wrote:
> This is not a use case approach.
> What we have is simply a statement of requirements which does not have an=
y
> justification in supporting use cases.

This does not alter the fact that 4 is vital :-)

>
> What was asked for were use cases:
> [U-WS-OPP] Alice finds Sally's server through a search engine. Alice pref=
ers
> to protect her communications with cryptography if this is supported by t=
he
> sever but will communicate in plaintext otherwise.
> etc. etc.
>
>
> On Tue, Apr 5, 2011 at 12:43 PM, Henry Story <[e-mail]>
> wrote:
>>
>> On 5 Apr 2011, at 12:22, Ben Laurie wrote:
>>
>> > On 5 April 2011 02:36, Paul Hoffman <[e-mail]> wrote:
>> >>
>> >> On Apr 4, 2011, at 6:28 PM, Richard L. Barnes wrote:
>> >>
>> >>> I kind of agree with Phillip on the deadline. =A0I would propose pus=
hing
>> >>> it back to the 14th. =A0My responses:
>> >>>
>> >>> 1. It occurs to me that all of the technologies we're talking about
>> >>> entail a domain owner putting something in the DNS to assert somethi=
ng about
>> >>> their domain, which implies some expectation about how the client sh=
ould
>> >>> process TLS certs. =A0So it might be useful to phrase use cases in t=
erms of
>> >>> what the domain owner is asserting. =A0Re-stating Ekr's use cases in=
 this
>> >>> format:
>> >>>
>> >>> Use Case 1 "CA Lock":
>> >>> -- The certificate my server presents in TLS will be chain to this C=
A.
>> >>> -- Clients should accept a TLS server certificate only if it chains =
to
>> >>> this CA, but may also require that it chain to an existing trust anc=
hor.
>> >>>
>> >>> Use Case 2 "Cert Lock":
>> >>> -- The certificate my server presents in TLS will be this specific
>> >>> certificate.
>> >>> -- Clients should accept a TLS certificate only if it matches this
>> >>> certificate, but may also require that it chain to an existing trust=
 anchor.
>> >>>
>> >>> Use Case 3 "New TA":
>> >>> -- The certificate my server presents in TLS will chain to this CA,
>> >>> which should be treated as a TA.
>> >>> -- Clients should accept a TLS server certificate if and only if it
>> >>> chains to this CA.
>> >>>
>> >>> Use Case 4 "Certificate as Bare Key":
>> >>> -- The certificate my server presents in TLS will be this specific
>> >>> certificate.
>> >>> -- Clients should accept a TLS certificate if and only if it matches
>> >>> this certificate.
>> >>
>> >> I like the wording in this taxonomy.
>> >>
>> >> I consider 3 and 2 to be requirements, 1 to be useful, and 4 to be
>> >> mostly uninteresting if if 3 and/or 2 are implemented.
>> >
>> > OTOH, I think 4 is vital - otherwise self-signed certs cannot be first
>> > class citizens.
>>
>> Indeed 4 is vital. It is what can create the biggest boost for SSL
>> deployment ever. As mentioned a month or so ago on this list, MOST TLS
>> endpoints deployed by far are running self signed certificates according=
 to
>> the http://www.eff.org/observatory (3 times more that working TLS
>> deployments). By making it easy for those to be integrated properly,
>> browsers can show TLS error messages for real cases of fraudulent sites,
>> thereby increasing security dramatically on the web.
>>
>> Henry
>>
>>
>> >
>> >>
>> >> --Paul Hoffman
>>
>> Social Web Architect
>> http://bblfish.net/
>>
>> _______________________________________________
>> dane mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dane
>
>
>
> --
> Website: http://hallambaker.com/
>
>

From [e-mail]  Tue Apr  5 04:46:49 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 999C128C0FF for <[e-mail]>; Tue,  5 Apr 2011 04:46:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.128
X-Spam-Level: 
X-Spam-Status: No, score=-2.128 tagged_above=-999 required=5 tests=[AWL=0.121,  BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wufwL7vHFKAy for <[e-mail]>; Tue,  5 Apr 2011 04:46:42 -0700 (PDT)
Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id 609C23A68BC for <[e-mail]>; Tue,  5 Apr 2011 04:46:40 -0700 (PDT)
Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1Q74kB-0006p3-4f for [e-mail]; Tue, 05 Apr 2011 11:48:23 +0000
Received: by bfk.de with local id 1Q74kB-0001N3-1z for [e-mail]; Tue, 05 Apr 2011 11:48:23 +0000
Resent-To: [e-mail]
Resent-From: Florian Weimer <[e-mail]>
Resent-Date: Tue, 05 Apr 2011 11:48:23 +0000
Resent-Message-ID: <[e-mail]>
To: Eric Rescorla <[e-mail]>
References: <[e-mail]>
From: Florian Weimer <[e-mail]>
Date: Tue, 05 Apr 2011 11:13:12 +0000
In-Reply-To: <[e-mail]> (Eric Rescorla's message of "Wed\, 30 Mar 2011 10\:48\:53 +0200")
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Lines: 26
Resent-Date: Tue, 05 Apr 2011 11:48:23 +0000
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Objective: Restrictive versus Supplementary Models
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2011 11:46:49 -0000

* Eric Rescorla:

> In the second case, the intention is to allow clients to effectively
> bypass the existing trust hierarchy by injecting a new trust point
> via the DNS. Thus, either the certificate validation simply will not
> be used at all (in the case where a terminal certificate is
> provided) or will be used up to a newly inserted trust anchor. In
> either case, the presumptive rationale here is that it's too
> inconvenient to deal with the existing CAs and that DANE will be
> easier.  This version of DANE *does* need to be protected via DNSSEC
> because tampering with these records allows the attacker to
> impersonate the authenticating party to the relying party.

If you switch HTTPS transparently (meaning: no UI indicators, secure
cookies are not sent, SOP checks run against :80 instead of :443),
then you don't need DNSSEC.

I'm pretty sure it's politically and technically infeasible to
introduce DNSSEC-driven UI changes on a larger scale, so I doubt that
any non-transparent approach will fly.

--=20
Florian Weimer                <[e-mail]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstra=DFe 100              tel: [phone]
D-76133 Karlsruhe             fax: [phone]

From [e-mail]  Tue Apr  5 05:00:34 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA7943A68BC for <[e-mail]>; Tue,  5 Apr 2011 05:00:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.558
X-Spam-Level: 
X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUROKwds7WPy for <[e-mail]>; Tue,  5 Apr 2011 05:00:28 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id ECEF63A6936 for <[e-mail]>; Tue,  5 Apr 2011 05:00:27 -0700 (PDT)
Received: from [128.89.255.236] (port=56754 helo=[192.168.1.10]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from <[e-mail]>) id 1Q74xU-0005R8-Ru; Tue, 05 Apr 2011 08:02:09 -0400
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: "Richard L. Barnes" <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Tue, 5 Apr 2011 08:02:05 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
To: Ben Laurie <[e-mail]>
X-Mailer: Apple Mail (2.1082)
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2011 12:00:35 -0000

>>> I kind of agree with Phillip on the deadline.  I would propose =
pushing it back to the 14th.  My responses:
>>>=20
>>> 1. It occurs to me that all of the technologies we're talking about =
entail a domain owner putting something in the DNS to assert something =
about their domain, which implies some expectation about how the client =
should process TLS certs.  So it might be useful to phrase use cases in =
terms of what the domain owner is asserting.  Re-stating Ekr's use cases =
in this format:
>>>=20
>>> Use Case 1 "CA Lock":
>>> -- The certificate my server presents in TLS will be chain to this =
CA.
>>> -- Clients should accept a TLS server certificate only if it chains =
to this CA, but may also require that it chain to an existing trust =
anchor.
>>>=20
>>> Use Case 2 "Cert Lock":
>>> -- The certificate my server presents in TLS will be this specific =
certificate.
>>> -- Clients should accept a TLS certificate only if it matches this =
certificate, but may also require that it chain to an existing trust =
anchor.
>>>=20
>>> Use Case 3 "New TA":
>>> -- The certificate my server presents in TLS will chain to this CA, =
which should be treated as a TA.
>>> -- Clients should accept a TLS server certificate if and only if it =
chains to this CA.
>>>=20
>>> Use Case 4 "Certificate as Bare Key":
>>> -- The certificate my server presents in TLS will be this specific =
certificate.
>>> -- Clients should accept a TLS certificate if and only if it matches =
this certificate.
>>=20
>> I like the wording in this taxonomy.
>>=20
>> I consider 3 and 2 to be requirements, 1 to be useful, and 4 to be =
mostly uninteresting if if 3 and/or 2 are implemented.
>=20
> OTOH, I think 4 is vital - otherwise self-signed certs cannot be first
> class citizens.

Just one technical point: You can arguably do self-signed certs with 3, =
either because self-signed certs chain to themselves, or because you can =
issue a second cert under a self-signed TA you put in DANE.  Pretty =
picture on slide 8 of this:
<http://tools.ietf.org/agenda/80/slides/dane-2.pdf>

--Richard=

From [e-mail]  Tue Apr  5 05:01:04 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED1FD3A68BC for <[e-mail]>; Tue,  5 Apr 2011 05:01:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.558
X-Spam-Level: 
X-Spam-Status: No, score=-10.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F06lGBKEx4Wf for <[e-mail]>; Tue,  5 Apr 2011 05:00:57 -0700 (PDT)
Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 6F6233A6781 for <[e-mail]>; Tue,  5 Apr 2011 05:00:57 -0700 (PDT)
Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p35C2aL8006923;  Tue, 5 Apr 2011 15:02:37 +0300
X-CheckPoint: {4D9B12B6-A-1B221DC2-FFFF}
Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 5 Apr 2011 15:02:36 +0300
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Tue, 5 Apr 2011 14:02:36 +0200
From: Yoav Nir <[e-mail]>
To: Henry Story <[e-mail]>
Date: Tue, 5 Apr 2011 14:02:35 +0200
Thread-Topic: [dane] [keyassure] Use cases document.
Thread-Index: AcvziVpG4p441p+7S02xzYQNpBSI4w==
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2011 12:01:05 -0000

On Apr 5, 2011, at 1:43 PM, Henry Story wrote:

>=20
> On 5 Apr 2011, at 12:22, Ben Laurie wrote:
>=20
>>>>=20
>>>> Use Case 1 "CA Lock":
>>>> -- The certificate my server presents in TLS will be chain to this CA.
>>>> -- Clients should accept a TLS server certificate only if it chains to=
 this CA, but may also require that it chain to an existing trust anchor.
>>>>=20
>>>> Use Case 2 "Cert Lock":
>>>> -- The certificate my server presents in TLS will be this specific cer=
tificate.
>>>> -- Clients should accept a TLS certificate only if it matches this cer=
tificate, but may also require that it chain to an existing trust anchor.
>>>>=20
>>>> Use Case 3 "New TA":
>>>> -- The certificate my server presents in TLS will chain to this CA, wh=
ich should be treated as a TA.
>>>> -- Clients should accept a TLS server certificate if and only if it ch=
ains to this CA.
>>>>=20
>>>> Use Case 4 "Certificate as Bare Key":
>>>> -- The certificate my server presents in TLS will be this specific cer=
tificate.
>>>> -- Clients should accept a TLS certificate if and only if it matches t=
his certificate.
>>>=20
>>> I like the wording in this taxonomy.
>>>=20
>>> I consider 3 and 2 to be requirements, 1 to be useful, and 4 to be most=
ly uninteresting if if 3 and/or 2 are implemented.
>>=20
>> OTOH, I think 4 is vital - otherwise self-signed certs cannot be first
>> class citizens.
>=20
> Indeed 4 is vital. It is what can create the biggest boost for SSL deploy=
ment ever. As mentioned a month or so ago on this list, MOST TLS endpoints =
deployed by far are running self signed certificates according to the http:=
//www.eff.org/observatory (3 times more that working TLS deployments). By m=
aking it easy for those to be integrated properly, browsers can show TLS er=
ror messages for real cases of fraudulent sites, thereby increasing securit=
y dramatically on the web.

+1=

From [e-mail]  Tue Apr  5 05:12:36 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D6F63A6938 for <[e-mail]>; Tue,  5 Apr 2011 05:12:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.545
X-Spam-Level: 
X-Spam-Status: No, score=-3.545 tagged_above=-999 required=5 tests=[AWL=0.053,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WbTnA1KG0+sh for <[e-mail]>; Tue,  5 Apr 2011 05:12:28 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 3C7F73A6926 for <[e-mail]>; Tue,  5 Apr 2011 05:12:28 -0700 (PDT)
Received: by vws12 with SMTP id 12so264289vws.31 for <[e-mail]>; Tue, 05 Apr 2011 05:14:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=PVp/+xc4tVtm7Xi6ykympskoQq6hauH0KUImYZtw16w=; b=nYrXqBJuLd7/DrCcQq+iNIO7/1/8D2GCWHkQE/JY+7qiPAhS0+D3Fv47ox+ZsGmVkG dylhVXCMaW0BtTmBY6mxDmA79i1m+KWBovMiKpvY/Wa5svT2soDSaEidb/O79EJnDJPa Lkrf+dze42PbL4OIpK7EonYyc9Sjo3B2RAEic=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=vkapwMDMLSC1n+Ec4QWDVIHXiXb69BL+gaE/kQ01MVZAqTcS2NNHOxofPXWyjIkq9c 9/pa6UFcLy4oUueAdXQRIIqLovoze52yf3+tEXt6AyTArvh/iZ9+aRx2FS7JA6JwaznM 034Upo2xpKttoxAVL2Pr1hAlrczhtGgg7P8ks=
MIME-Version: 1.0
Received: by 10.52.70.174 with SMTP id n14mr10703976vdu.258.1302005651000; Tue, 05 Apr 2011 05:14:11 -0700 (PDT)
Received: by 10.52.161.42 with HTTP; Tue, 5 Apr 2011 05:14:10 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <BANLkTimNauWFBSvsvzfx4TUcU=[e-mail]> <[e-mail]>
Date: Tue, 5 Apr 2011 14:14:10 +0200
Message-ID: <[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: Ben Laurie <[e-mail]>
Content-Type: multipart/alternative; boundary=20cf3071c9d052ccc604a02ad0d5
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2011 12:12:36 -0000

--20cf3071c9d052ccc604a02ad0d5
Content-Type: text/plain; charset=ISO-8859-1

But what are the circumstances in which it is to be used?

Does Alice have a preference for confidentiality or is this essential? Does
Alice need to be able to verify that encryption is in use? Does Alice need
to know anything about the accountability, reputation or otherwise of the
subject?


There is a very low end security approach where all we want to do is to turn
on encryption if possible and connect with plaintext otherwise. Alice is
willing to accept the possibility of a man in the middle approach and is not
going to verify the status of the connection.

There is also a very high end security approach where we wish to ensure
strict security on first and every contact and ensure that compatible trust
anchors are employed.

And there are shades in between.


The first case can be addressed without DNSSEC: Just use encryption and
don't provide any security signal (e.g. padlock) in primary chrome.

The second case needs DNSSEC and more to add trust in.


While the precise definition of what 'strict security' turns out to be is
something we can leave to =Jeff and co in WebSec. I think we need to have a
story for how we could present the 'strict' indicator through the DNS along
with the trust anchor/key restrictions.

We may not want to add such capability to the standard immediately, but we
can have extensibility without impact on what people assert are the 'core'
use cases. I don't see why we have to accept the idea that because some
people are only interested in X we should deliberately design the spec so
that it is only capable of doing X and can never, ever be extended to do
anything else whatsoever.


The consensus at the Prague meeting was very clearly that DANE needs to go
back and do use cases and requirements.

In my view that means that the room rejected the idea of simply writing a
set of requirements that precisely describe the capabilities of the only
proposal that has been allowed to be considered.

There was a very strong view in the room that DANE has tried to move too
fast to propose a solution. Now that may in part be my fault, I have been
thinking about this particular problem for many years. But I think that
there was also a feeling that the WG had defined the problem it was trying
to solve to be the need to use the exact technology being proposed rather
than look at what a potential adopter of the scheme might be looking for.


I agree that your requirement is essential. But I disagree with the idea
that we should therefore design a spec that stovepipes that single
requirement.


On Tue, Apr 5, 2011 at 1:34 PM, Ben Laurie <[e-mail]> wrote:

> On 5 April 2011 12:32, Phillip Hallam-Baker <[e-mail]> wrote:
> > This is not a use case approach.
> > What we have is simply a statement of requirements which does not have
> any
> > justification in supporting use cases.
>
> This does not alter the fact that 4 is vital :-)
>
> >
> > What was asked for were use cases:
> > [U-WS-OPP] Alice finds Sally's server through a search engine. Alice
> prefers
> > to protect her communications with cryptography if this is supported by
> the
> > sever but will communicate in plaintext otherwise.
> > etc. etc.
> >
> >
> > On Tue, Apr 5, 2011 at 12:43 PM, Henry Story <[e-mail]>
> > wrote:
> >>
> >> On 5 Apr 2011, at 12:22, Ben Laurie wrote:
> >>
> >> > On 5 April 2011 02:36, Paul Hoffman <[e-mail]> wrote:
> >> >>
> >> >> On Apr 4, 2011, at 6:28 PM, Richard L. Barnes wrote:
> >> >>
> >> >>> I kind of agree with Phillip on the deadline.  I would propose
> pushing
> >> >>> it back to the 14th.  My responses:
> >> >>>
> >> >>> 1. It occurs to me that all of the technologies we're talking about
> >> >>> entail a domain owner putting something in the DNS to assert
> something about
> >> >>> their domain, which implies some expectation about how the client
> should
> >> >>> process TLS certs.  So it might be useful to phrase use cases in
> terms of
> >> >>> what the domain owner is asserting.  Re-stating Ekr's use cases in
> this
> >> >>> format:
> >> >>>
> >> >>> Use Case 1 "CA Lock":
> >> >>> -- The certificate my server presents in TLS will be chain to this
> CA.
> >> >>> -- Clients should accept a TLS server certificate only if it chains
> to
> >> >>> this CA, but may also require that it chain to an existing trust
> anchor.
> >> >>>
> >> >>> Use Case 2 "Cert Lock":
> >> >>> -- The certificate my server presents in TLS will be this specific
> >> >>> certificate.
> >> >>> -- Clients should accept a TLS certificate only if it matches this
> >> >>> certificate, but may also require that it chain to an existing trust
> anchor.
> >> >>>
> >> >>> Use Case 3 "New TA":
> >> >>> -- The certificate my server presents in TLS will chain to this CA,
> >> >>> which should be treated as a TA.
> >> >>> -- Clients should accept a TLS server certificate if and only if it
> >> >>> chains to this CA.
> >> >>>
> >> >>> Use Case 4 "Certificate as Bare Key":
> >> >>> -- The certificate my server presents in TLS will be this specific
> >> >>> certificate.
> >> >>> -- Clients should accept a TLS certificate if and only if it matches
> >> >>> this certificate.
> >> >>
> >> >> I like the wording in this taxonomy.
> >> >>
> >> >> I consider 3 and 2 to be requirements, 1 to be useful, and 4 to be
> >> >> mostly uninteresting if if 3 and/or 2 are implemented.
> >> >
> >> > OTOH, I think 4 is vital - otherwise self-signed certs cannot be first
> >> > class citizens.
> >>
> >> Indeed 4 is vital. It is what can create the biggest boost for SSL
> >> deployment ever. As mentioned a month or so ago on this list, MOST TLS
> >> endpoints deployed by far are running self signed certificates according
> to
> >> the http://www.eff.org/observatory (3 times more that working TLS
> >> deployments). By making it easy for those to be integrated properly,
> >> browsers can show TLS error messages for real cases of fraudulent sites,
> >> thereby increasing security dramatically on the web.
> >>
> >> Henry
> >>
> >>
> >> >
> >> >>
> >> >> --Paul Hoffman
> >>
> >> Social Web Architect
> >> http://bblfish.net/
> >>
> >> _______________________________________________
> >> dane mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/dane
> >
> >
> >
> > --
> > Website: http://hallambaker.com/
> >
> >
>



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

--20cf3071c9d052ccc604a02ad0d5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

But what are the circumstances in which it is to be used?<div><br></div><di=
v>Does Alice have a preference for confidentiality or is this essential? Do=
es Alice need to be able to verify that encryption is in use? Does Alice ne=
ed to know anything about the accountability, reputation or otherwise of th=
e subject?</div>
<div><br></div><div><br></div><div>There is a very low end security approac=
h where all we want to do is to turn on encryption if possible and connect =
with plaintext otherwise. Alice is willing to accept the possibility of a m=
an in the middle approach and is not going to verify the status of the conn=
ection.</div>
<div><br></div><div>There is also a very high end security approach where w=
e wish to ensure strict security on first and every contact and ensure that=
 compatible trust anchors are employed.</div><div><br></div><div>And there =
are shades in between.</div>
<div><br></div><div><br></div><div>The first case can be addressed without =
DNSSEC: Just use encryption and don&#39;t provide any security signal (e.g.=
 padlock) in primary chrome.</div><div><br></div><div>The second case needs=
 DNSSEC and more to add trust in.</div>
<div><br></div><div><br></div><div>While the precise definition of what &#3=
9;strict security&#39; turns out to be is something we can leave to =3DJeff=
 and co in WebSec. I think we need to have a story for how we could present=
 the &#39;strict&#39; indicator through the DNS along with the trust anchor=
/key restrictions.</div>
<div><br></div><div>We may not want to add such capability to the standard =
immediately, but we can have extensibility without impact on what people as=
sert are the &#39;core&#39; use cases. I don&#39;t see why we have to accep=
t the idea that because some people are only interested in X we should deli=
berately design the spec so that it is only capable of doing X and can neve=
r, ever be extended to do anything else whatsoever.</div>
<div><br></div><div><br></div><div>The consensus at the Prague meeting was =
very clearly that DANE needs to go back and do use cases and requirements.<=
/div><div><br></div><div>In my view that means that the room rejected the i=
dea of simply writing a set of requirements that precisely describe the cap=
abilities of the only proposal that has been allowed to be considered.</div=
>
<div><br></div><div>There was a very strong view in the room that DANE has =
tried to move too fast to propose a solution. Now that may in part be my fa=
ult, I have been thinking about this particular problem for many years. But=
 I think that there was also a feeling that the WG had defined the problem =
it was trying to solve to be the need to use the exact technology being pro=
posed rather than look at what a potential adopter of the scheme might be l=
ooking for.</div>
<div><br></div><div><br></div><div>I agree that your requirement is essenti=
al. But I disagree with the idea that we should therefore design a spec tha=
t stovepipes that single requirement.</div><div><br></div><div><br></div>
<div><div class=3D"gmail_quote">On Tue, Apr 5, 2011 at 1:34 PM, Ben Laurie =
<span dir=3D"ltr">&lt;<a href=3D"mailto:[e-mail]">[e-mail]</a=
>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">On 5 April 2011 12:32, Phillip Hallam-Baker &lt;<a href=
=3D"mailto:[e-mail]">[e-mail]</a>&gt; wrote:<br>
&gt; This is not a use case approach.<br>
&gt; What we have is simply a statement of requirements which does not have=
 any<br>
&gt; justification in supporting use cases.<br>
<br>
</div>This does not alter the fact that 4 is vital :-)<br>
<div><div></div><div class=3D"h5"><br>
&gt;<br>
&gt; What was asked for were use cases:<br>
&gt; [U-WS-OPP] Alice finds Sally&#39;s server through a search engine. Ali=
ce prefers<br>
&gt; to protect her communications with cryptography if this is supported b=
y the<br>
&gt; sever but will communicate in plaintext otherwise.<br>
&gt; etc. etc.<br>
&gt;<br>
&gt;<br>
&gt; On Tue, Apr 5, 2011 at 12:43 PM, Henry Story &lt;<a href=3D"mailto:hen=
[e-mail]">[e-mail]</a>&gt;<br>
&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; On 5 Apr 2011, at 12:22, Ben Laurie wrote:<br>
&gt;&gt;<br>
&gt;&gt; &gt; On 5 April 2011 02:36, Paul Hoffman &lt;<a href=3D"mailto:pau=
[e-mail]">[e-mail]</a>&gt; wrote:<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; On Apr 4, 2011, at 6:28 PM, Richard L. Barnes wrote:<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt; I kind of agree with Phillip on the deadline. =A0I wo=
uld propose pushing<br>
&gt;&gt; &gt;&gt;&gt; it back to the 14th. =A0My responses:<br>
&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt; 1. It occurs to me that all of the technologies we&#3=
9;re talking about<br>
&gt;&gt; &gt;&gt;&gt; entail a domain owner putting something in the DNS to=
 assert something about<br>
&gt;&gt; &gt;&gt;&gt; their domain, which implies some expectation about ho=
w the client should<br>
&gt;&gt; &gt;&gt;&gt; process TLS certs. =A0So it might be useful to phrase=
 use cases in terms of<br>
&gt;&gt; &gt;&gt;&gt; what the domain owner is asserting. =A0Re-stating Ekr=
&#39;s use cases in this<br>
&gt;&gt; &gt;&gt;&gt; format:<br>
&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt; Use Case 1 &quot;CA Lock&quot;:<br>
&gt;&gt; &gt;&gt;&gt; -- The certificate my server presents in TLS will be =
chain to this CA.<br>
&gt;&gt; &gt;&gt;&gt; -- Clients should accept a TLS server certificate onl=
y if it chains to<br>
&gt;&gt; &gt;&gt;&gt; this CA, but may also require that it chain to an exi=
sting trust anchor.<br>
&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt; Use Case 2 &quot;Cert Lock&quot;:<br>
&gt;&gt; &gt;&gt;&gt; -- The certificate my server presents in TLS will be =
this specific<br>
&gt;&gt; &gt;&gt;&gt; certificate.<br>
&gt;&gt; &gt;&gt;&gt; -- Clients should accept a TLS certificate only if it=
 matches this<br>
&gt;&gt; &gt;&gt;&gt; certificate, but may also require that it chain to an=
 existing trust anchor.<br>
&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt; Use Case 3 &quot;New TA&quot;:<br>
&gt;&gt; &gt;&gt;&gt; -- The certificate my server presents in TLS will cha=
in to this CA,<br>
&gt;&gt; &gt;&gt;&gt; which should be treated as a TA.<br>
&gt;&gt; &gt;&gt;&gt; -- Clients should accept a TLS server certificate if =
and only if it<br>
&gt;&gt; &gt;&gt;&gt; chains to this CA.<br>
&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt; Use Case 4 &quot;Certificate as Bare Key&quot;:<br>
&gt;&gt; &gt;&gt;&gt; -- The certificate my server presents in TLS will be =
this specific<br>
&gt;&gt; &gt;&gt;&gt; certificate.<br>
&gt;&gt; &gt;&gt;&gt; -- Clients should accept a TLS certificate if and onl=
y if it matches<br>
&gt;&gt; &gt;&gt;&gt; this certificate.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; I like the wording in this taxonomy.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; I consider 3 and 2 to be requirements, 1 to be useful, an=
d 4 to be<br>
&gt;&gt; &gt;&gt; mostly uninteresting if if 3 and/or 2 are implemented.<br=
>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; OTOH, I think 4 is vital - otherwise self-signed certs cannot=
 be first<br>
&gt;&gt; &gt; class citizens.<br>
&gt;&gt;<br>
&gt;&gt; Indeed 4 is vital. It is what can create the biggest boost for SSL=
<br>
&gt;&gt; deployment ever. As mentioned a month or so ago on this list, MOST=
 TLS<br>
&gt;&gt; endpoints deployed by far are running self signed certificates acc=
ording to<br>
&gt;&gt; the <a href=3D"http://www.eff.org/observatory" target=3D"_blank">h=
ttp://www.eff.org/observatory</a> (3 times more that working TLS<br>
&gt;&gt; deployments). By making it easy for those to be integrated properl=
y,<br>
&gt;&gt; browsers can show TLS error messages for real cases of fraudulent =
sites,<br>
&gt;&gt; thereby increasing security dramatically on the web.<br>
&gt;&gt;<br>
&gt;&gt; Henry<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; --Paul Hoffman<br>
&gt;&gt;<br>
&gt;&gt; Social Web Architect<br>
&gt;&gt; <a href=3D"http://bblfish.net/" target=3D"_blank">http://bblfish.n=
et/</a><br>
&gt;&gt;<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; dane mailing list<br>
&gt;&gt; <a href=3D"mailto:[e-mail]">[e-mail]</a><br>
&gt;&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_=
blank">https://www.ietf.org/mailman/listinfo/dane</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt; Website: <a href=3D"http://hallambaker.com/" target=3D"_blank">http://=
hallambaker.com/</a><br>
&gt;<br>
&gt;<br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a=
 href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--20cf3071c9d052ccc604a02ad0d5--

From [e-mail]  Tue Apr  5 05:18:10 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE20C28C0E4 for <[e-mail]>; Tue,  5 Apr 2011 05:18:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.054
X-Spam-Level: 
X-Spam-Status: No, score=-102.054 tagged_above=-999 required=5 tests=[AWL=0.545, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJsjo7BHwMiP for <[e-mail]>; Tue,  5 Apr 2011 05:18:02 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by core3.amsl.com (Postfix) with ESMTP id 68C1228C0DD for <[e-mail]>; Tue,  5 Apr 2011 05:18:02 -0700 (PDT)
Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p35CJXrA044541 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Apr 2011 05:19:34 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Paul Hoffman <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Tue, 5 Apr 2011 05:19:33 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
To: "Richard L. Barnes" <[e-mail]>
X-Mailer: Apple Mail (2.1084)
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2011 12:18:11 -0000

On Apr 5, 2011, at 5:02 AM, Richard L. Barnes wrote:

>>>> I kind of agree with Phillip on the deadline.  I would propose =
pushing it back to the 14th.  My responses:
>>>>=20
>>>> 1. It occurs to me that all of the technologies we're talking about =
entail a domain owner putting something in the DNS to assert something =
about their domain, which implies some expectation about how the client =
should process TLS certs.  So it might be useful to phrase use cases in =
terms of what the domain owner is asserting.  Re-stating Ekr's use cases =
in this format:
>>>>=20
>>>> Use Case 1 "CA Lock":
>>>> -- The certificate my server presents in TLS will be chain to this =
CA.
>>>> -- Clients should accept a TLS server certificate only if it chains =
to this CA, but may also require that it chain to an existing trust =
anchor.
>>>>=20
>>>> Use Case 2 "Cert Lock":
>>>> -- The certificate my server presents in TLS will be this specific =
certificate.
>>>> -- Clients should accept a TLS certificate only if it matches this =
certificate, but may also require that it chain to an existing trust =
anchor.
>>>>=20
>>>> Use Case 3 "New TA":
>>>> -- The certificate my server presents in TLS will chain to this CA, =
which should be treated as a TA.
>>>> -- Clients should accept a TLS server certificate if and only if it =
chains to this CA.
>>>>=20
>>>> Use Case 4 "Certificate as Bare Key":
>>>> -- The certificate my server presents in TLS will be this specific =
certificate.
>>>> -- Clients should accept a TLS certificate if and only if it =
matches this certificate.
>>>=20
>>> I like the wording in this taxonomy.
>>>=20
>>> I consider 3 and 2 to be requirements, 1 to be useful, and 4 to be =
mostly uninteresting if if 3 and/or 2 are implemented.
>>=20
>> OTOH, I think 4 is vital - otherwise self-signed certs cannot be =
first
>> class citizens.
>=20
> Just one technical point: You can arguably do self-signed certs with =
3, either because self-signed certs chain to themselves, or because you =
can issue a second cert under a self-signed TA you put in DANE.  Pretty =
picture on slide 8 of this:
> <http://tools.ietf.org/agenda/80/slides/dane-2.pdf>

That's not a "technical point", it is a fundamental feature. With #3, #4 =
becomes pretty irrelevant and implementers have fewer different =
semantics to deal with.

--Paul Hoffman


From [e-mail]  Tue Apr  5 05:19:27 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 003223A6919 for <[e-mail]>; Tue,  5 Apr 2011 05:19:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.977
X-Spam-Level: 
X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qx0jWG2rDhDY for <[e-mail]>; Tue,  5 Apr 2011 05:19:18 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 7662B28C0DD for <[e-mail]>; Tue,  5 Apr 2011 05:19:18 -0700 (PDT)
Received: from hpaq13.eem.corp.google.com (hpaq13.eem.corp.google.com [172.25.149.13]) by smtp-out.google.com with ESMTP id p35CL0dI014344 for <[e-mail]>; Tue, 5 Apr 2011 05:21:00 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1302006061; bh=p2TL0UWTJLuNPJc2shDcKV5Gx1k=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=TGTdni+MenD1z+Pnt9LxLZssq+NHsWTRmbOtPkVkBjDhqrHcDAI/1JQYq2lm6nOIZ 6qxLygA4OoU1VTd6H+5iw==
Received: from vxc40 (vxc40.prod.google.com [10.241.33.168]) by hpaq13.eem.corp.google.com with ESMTP id p35CKKks006626 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <[e-mail]>; Tue, 5 Apr 2011 05:20:59 -0700
Received: by vxc40 with SMTP id 40so302510vxc.16 for <[e-mail]>; Tue, 05 Apr 2011 05:20:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3RZkv/4rYqZ7s9M/edlp8ur4XnuUKfwDtbg+tgrrREg=; b=atGzKpPLFmlpYTtlcl7PGaiLh+D5aihKa3Vz3M8A0Me6RZnw9OL+odlABtBppZA8OB oNkbbsx+9qxPIikdDk6Q==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=T0KlqOxdBk8DUKzRjLJCYqL+Dq9h2fHIl6SgiULwTAXvX0vxZDxkgpQ6G/lpiyjXUl YXBpMmoMh1D6nF/gqDdA==
MIME-Version: 1.0
Received: by 10.220.175.199 with SMTP id bb7mr511833vcb.225.1302006058958; Tue, 05 Apr 2011 05:20:58 -0700 (PDT)
Received: by 10.220.5.144 with HTTP; Tue, 5 Apr 2011 05:20:58 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <BANLkTimNauWFBSvsvzfx4TUcU=[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 5 Apr 2011 13:20:58 +0100
Message-ID: <[e-mail]>
From: Ben Laurie <[e-mail]>
To: Phillip Hallam-Baker <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2011 12:19:27 -0000

On 5 April 2011 13:14, Phillip Hallam-Baker <[e-mail]> wrote:
> But what are the circumstances in which it is to be used?
> Does Alice have a preference for confidentiality or is this essential? Do=
es
> Alice need to be able to verify that encryption is in use? Does Alice nee=
d
> to know anything about the accountability, reputation or otherwise of the
> subject?
>
> There is a very low end security approach where all we want to do is to t=
urn
> on encryption if possible and connect with plaintext otherwise. Alice is
> willing to accept the possibility of a man in the middle approach and is =
not
> going to verify the status of the connection.
> There is also a very high end security approach where we wish to ensure
> strict security on first and every contact and ensure that compatible tru=
st
> anchors are employed.
> And there are shades in between.
>
> The first case can be addressed without DNSSEC: Just use encryption and
> don't provide any security signal (e.g. padlock) in primary chrome.
> The second case needs DNSSEC and more to add trust in.
>
> While the precise definition of what 'strict security' turns out to be is
> something we can leave to =3DJeff and co in WebSec. I think we need to ha=
ve a
> story for how we could present the 'strict' indicator through the DNS alo=
ng
> with the trust anchor/key restrictions.
> We may not want to add such capability to the standard immediately, but w=
e
> can have extensibility without impact on what people assert are the 'core=
'
> use cases. I don't see why we have to accept the idea that because some
> people are only interested in X we should deliberately design the spec so
> that it is only capable of doing X and can never, ever be extended to do
> anything else whatsoever.
>
> The consensus at the Prague meeting was very clearly that DANE needs to g=
o
> back and do use cases and requirements.
> In my view that means that the room rejected the idea of simply writing a
> set of requirements that precisely describe the capabilities of the only
> proposal that has been allowed to be considered.
> There was a very strong view in the room that DANE has tried to move too
> fast to propose a solution. Now that may in part be my fault, I have been
> thinking about this particular problem for many years. But I think that
> there was also a feeling that the WG had defined the problem it was tryin=
g
> to solve to be the need to use the exact technology being proposed rather
> than look at what a potential adopter of the scheme might be looking for.
>
> I agree that your requirement is essential. But I disagree with the idea
> that we should therefore design a spec that stovepipes that single
> requirement.

All I was doing was disagreeing with Paul, not attempting to define
the sole agenda of the WG.

>
> On Tue, Apr 5, 2011 at 1:34 PM, Ben Laurie <[e-mail]> wrote:
>>
>> On 5 April 2011 12:32, Phillip Hallam-Baker <[e-mail]> wrote:
>> > This is not a use case approach.
>> > What we have is simply a statement of requirements which does not have
>> > any
>> > justification in supporting use cases.
>>
>> This does not alter the fact that 4 is vital :-)
>>
>> >
>> > What was asked for were use cases:
>> > [U-WS-OPP] Alice finds Sally's server through a search engine. Alice
>> > prefers
>> > to protect her communications with cryptography if this is supported b=
y
>> > the
>> > sever but will communicate in plaintext otherwise.
>> > etc. etc.
>> >
>> >
>> > On Tue, Apr 5, 2011 at 12:43 PM, Henry Story <[e-mail]>
>> > wrote:
>> >>
>> >> On 5 Apr 2011, at 12:22, Ben Laurie wrote:
>> >>
>> >> > On 5 April 2011 02:36, Paul Hoffman <[e-mail]> wrote:
>> >> >>
>> >> >> On Apr 4, 2011, at 6:28 PM, Richard L. Barnes wrote:
>> >> >>
>> >> >>> I kind of agree with Phillip on the deadline. =A0I would propose
>> >> >>> pushing
>> >> >>> it back to the 14th. =A0My responses:
>> >> >>>
>> >> >>> 1. It occurs to me that all of the technologies we're talking abo=
ut
>> >> >>> entail a domain owner putting something in the DNS to assert
>> >> >>> something about
>> >> >>> their domain, which implies some expectation about how the client
>> >> >>> should
>> >> >>> process TLS certs. =A0So it might be useful to phrase use cases i=
n
>> >> >>> terms of
>> >> >>> what the domain owner is asserting. =A0Re-stating Ekr's use cases=
 in
>> >> >>> this
>> >> >>> format:
>> >> >>>
>> >> >>> Use Case 1 "CA Lock":
>> >> >>> -- The certificate my server presents in TLS will be chain to thi=
s
>> >> >>> CA.
>> >> >>> -- Clients should accept a TLS server certificate only if it chai=
ns
>> >> >>> to
>> >> >>> this CA, but may also require that it chain to an existing trust
>> >> >>> anchor.
>> >> >>>
>> >> >>> Use Case 2 "Cert Lock":
>> >> >>> -- The certificate my server presents in TLS will be this specifi=
c
>> >> >>> certificate.
>> >> >>> -- Clients should accept a TLS certificate only if it matches thi=
s
>> >> >>> certificate, but may also require that it chain to an existing
>> >> >>> trust anchor.
>> >> >>>
>> >> >>> Use Case 3 "New TA":
>> >> >>> -- The certificate my server presents in TLS will chain to this C=
A,
>> >> >>> which should be treated as a TA.
>> >> >>> -- Clients should accept a TLS server certificate if and only if =
it
>> >> >>> chains to this CA.
>> >> >>>
>> >> >>> Use Case 4 "Certificate as Bare Key":
>> >> >>> -- The certificate my server presents in TLS will be this specifi=
c
>> >> >>> certificate.
>> >> >>> -- Clients should accept a TLS certificate if and only if it
>> >> >>> matches
>> >> >>> this certificate.
>> >> >>
>> >> >> I like the wording in this taxonomy.
>> >> >>
>> >> >> I consider 3 and 2 to be requirements, 1 to be useful, and 4 to be
>> >> >> mostly uninteresting if if 3 and/or 2 are implemented.
>> >> >
>> >> > OTOH, I think 4 is vital - otherwise self-signed certs cannot be
>> >> > first
>> >> > class citizens.
>> >>
>> >> Indeed 4 is vital. It is what can create the biggest boost for SSL
>> >> deployment ever. As mentioned a month or so ago on this list, MOST TL=
S
>> >> endpoints deployed by far are running self signed certificates
>> >> according to
>> >> the http://www.eff.org/observatory (3 times more that working TLS
>> >> deployments). By making it easy for those to be integrated properly,
>> >> browsers can show TLS error messages for real cases of fraudulent
>> >> sites,
>> >> thereby increasing security dramatically on the web.
>> >>
>> >> Henry
>> >>
>> >>
>> >> >
>> >> >>
>> >> >> --Paul Hoffman
>> >>
>> >> Social Web Architect
>> >> http://bblfish.net/
>> >>
>> >> _______________________________________________
>> >> dane mailing list
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/dane
>> >
>> >
>> >
>> > --
>> > Website: http://hallambaker.com/
>> >
>> >
>
>
>
> --
> Website: http://hallambaker.com/
>
>

From [e-mail]  Tue Apr  5 05:21:38 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 416ED28C0EB for <[e-mail]>; Tue,  5 Apr 2011 05:21:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.059
X-Spam-Level: 
X-Spam-Status: No, score=-102.059 tagged_above=-999 required=5 tests=[AWL=0.540, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQoJCSwGRVwb for <[e-mail]>; Tue,  5 Apr 2011 05:21:37 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by core3.amsl.com (Postfix) with ESMTP id D058F28C0E4 for <[e-mail]>; Tue,  5 Apr 2011 05:21:36 -0700 (PDT)
Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p35CNICY044902 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <[e-mail]>; Tue, 5 Apr 2011 05:23:19 -0700 (MST) (envelope-from [e-mail])
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1084)
From: Paul Hoffman <[e-mail]>
In-Reply-To: <BANLkTimNauWFBSvsvzfx4TUcU=[e-mail]>
Date: Tue, 5 Apr 2011 05:23:18 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <BANLkTimNauWFBSvsvzfx4TUcU=[e-mail]>
To: [e-mail]
X-Mailer: Apple Mail (2.1084)
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2011 12:21:38 -0000

On Apr 5, 2011, at 4:32 AM, Phillip Hallam-Baker wrote:

> This is not a use case approach.

Correct: it is a requirements approach. As we have seen in the =
discussion thread so far, use cases often are tinged with what the =
proposed technical solution should be. This is not to say that use cases =
are bad; in fact, they would be a helpful addition to this discussion.

> What we have is simply a statement of requirements which does not have =
any justification in supporting use cases.

We disagree: the requirements listed by various people so far can be =
mapped to some use cases.

> What was asked for were use cases:

Were we in the same meeting? What was asked for was requirements and use =
cases.

> [U-WS-OPP] Alice finds Sally's server through a search engine. Alice =
prefers to protect her communications with cryptography if this is =
supported by the sever but will communicate in plaintext otherwise. =20
>=20
> etc. etc.

This highlights what will be interesting in the use case scenario: will =
the use cases be driven by the TLS client users or TLS server users?

--Paul Hoffman


From [e-mail]  Tue Apr  5 05:35:11 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D28F03A67A1 for <[e-mail]>; Tue,  5 Apr 2011 05:35:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.336
X-Spam-Level: 
X-Spam-Status: No, score=-3.336 tagged_above=-999 required=5 tests=[AWL=0.262,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3giYLogGxLsQ for <[e-mail]>; Tue,  5 Apr 2011 05:35:01 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 6DAB43A6403 for <[e-mail]>; Tue,  5 Apr 2011 05:35:00 -0700 (PDT)
Received: by wyb29 with SMTP id 29so318989wyb.31 for <[e-mail]>; Tue, 05 Apr 2011 05:36:43 -0700 (PDT)
Received: by 10.227.196.208 with SMTP id eh16mr8453418wbb.224.1302007002003; Tue, 05 Apr 2011 05:36:42 -0700 (PDT)
Received: from bblfish.home (ALagny-751-1-3-136.w86-218.abo.wanadoo.fr [86.218.42.136]) by mx.google.com with ESMTPS id o6sm3534486wbo.54.2011.04.05.05.36.40 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Apr 2011 05:36:41 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: multipart/alternative; boundary=Apple-Mail-59--570232588
From: Henry Story <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Tue, 5 Apr 2011 14:36:38 +0200
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <BANLkTimNauWFBSvsvzfx4TUcU=[e-mail]> <[e-mail]> <[e-mail]>
To: Phillip Hallam-Baker <[e-mail]>
X-Mailer: Apple Mail (2.1082)
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2011 12:35:11 -0000

--Apple-Mail-59--570232588
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On 5 Apr 2011, at 14:14, Phillip Hallam-Baker wrote:

> But what are the circumstances in which it is to be used?
>=20
> Does Alice have a preference for confidentiality or is this essential? =
Does Alice need to be able to verify that encryption is in use? Does =
Alice need to know anything about the accountability, reputation or =
otherwise of the subject?

The only thing that would be guaranteed to clients connecting to servers =
presenting self signed certificates matching the cert (or its bare key) =
in the DNSsec  is connection to the computer named in the DNS. That is a =
huge improvement for all the servers presenting self signed =
certificates.

The way I see Dane is that it increases trust at every level. It is =
quite easy to understand why: there is now an additional way to confirm =
information:

 - so self signed certs, move from just being useful for guaranteeing =
communication to also guaranteeing identity (they move from no padlock =
to padlock)
 - CA signed certs move away from  the growing danger of irrelevance - =
since they can be undermined by corrupt CAs, aka the weakest link =
problem - to being verified and supported by the DNS



>=20
> There is a very low end security approach where all we want to do is =
to turn on encryption if possible and connect with plaintext otherwise. =
Alice is willing to accept the possibility of a man in the middle =
approach and is not going to verify the status of the connection.

that is self signed certs now, running 3 times as many TLS end points as =
CA signed tls endpoints.

>=20
> There is also a very high end security approach where we wish to =
ensure strict security on first and every contact and ensure that =
compatible trust anchors are employed.

Those are CAs, but they are not very high end because they are being =
undermined by bad or just unlucky CAs.

>=20
> And there are shades in between.
>=20
>=20
> The first case can be addressed without DNSSEC: Just use encryption =
and don't provide any security signal (e.g. padlock) in primary chrome.
>=20
> The second case needs DNSSEC and more to add trust in.

No, both those cases are improved by DANE and DNSsec.

>=20
> While the precise definition of what 'strict security' turns out to be =
is something we can leave to =3DJeff and co in WebSec. I think we need =
to have a story for how we could present the 'strict' indicator through =
the DNS along with the trust anchor/key restrictions.
>=20
> We may not want to add such capability to the standard immediately, =
but we can have extensibility without impact on what people assert are =
the 'core' use cases. I don't see why we have to accept the idea that =
because some people are only interested in X we should deliberately =
design the spec so that it is only capable of doing X and can never, =
ever be extended to do anything else whatsoever.

I don't think I ever claimed that supporting self signed certs should be =
the *only* requirement . Just that it is a very important use case.  =
Dane is Win/Win for all.


>=20
> The consensus at the Prague meeting was very clearly that DANE needs =
to go back and do use cases and requirements.
>=20
> In my view that means that the room rejected the idea of simply =
writing a set of requirements that precisely describe the capabilities =
of the only proposal that has been allowed to be considered.
>=20
> There was a very strong view in the room that DANE has tried to move =
too fast to propose a solution. Now that may in part be my fault, I have =
been thinking about this particular problem for many years. But I think =
that there was also a feeling that the WG had defined the problem it was =
trying to solve to be the need to use the exact technology being =
proposed rather than look at what a potential adopter of the scheme =
might be looking for.
>=20
>=20
> I agree that your requirement is essential. But I disagree with the =
idea that we should therefore design a spec that stovepipes that single =
requirement.

I think it follows naturally. No stovepiping needed. But that's =
something one can discuss later. The requirement is pretty appealing.


Henry

>=20
>=20
> On Tue, Apr 5, 2011 at 1:34 PM, Ben Laurie <[e-mail]> wrote:
> On 5 April 2011 12:32, Phillip Hallam-Baker <[e-mail]> wrote:
> > This is not a use case approach.
> > What we have is simply a statement of requirements which does not =
have any
> > justification in supporting use cases.
>=20
> This does not alter the fact that 4 is vital :-)
>=20
> >
> > What was asked for were use cases:
> > [U-WS-OPP] Alice finds Sally's server through a search engine. Alice =
prefers
> > to protect her communications with cryptography if this is supported =
by the
> > sever but will communicate in plaintext otherwise.
> > etc. etc.
> >
> >
> > On Tue, Apr 5, 2011 at 12:43 PM, Henry Story =
<[e-mail]>
> > wrote:
> >>
> >> On 5 Apr 2011, at 12:22, Ben Laurie wrote:
> >>
> >> > On 5 April 2011 02:36, Paul Hoffman <[e-mail]> =
wrote:
> >> >>
> >> >> On Apr 4, 2011, at 6:28 PM, Richard L. Barnes wrote:
> >> >>
> >> >>> I kind of agree with Phillip on the deadline.  I would propose =
pushing
> >> >>> it back to the 14th.  My responses:
> >> >>>
> >> >>> 1. It occurs to me that all of the technologies we're talking =
about
> >> >>> entail a domain owner putting something in the DNS to assert =
something about
> >> >>> their domain, which implies some expectation about how the =
client should
> >> >>> process TLS certs.  So it might be useful to phrase use cases =
in terms of
> >> >>> what the domain owner is asserting.  Re-stating Ekr's use cases =
in this
> >> >>> format:
> >> >>>
> >> >>> Use Case 1 "CA Lock":
> >> >>> -- The certificate my server presents in TLS will be chain to =
this CA.
> >> >>> -- Clients should accept a TLS server certificate only if it =
chains to
> >> >>> this CA, but may also require that it chain to an existing =
trust anchor.
> >> >>>
> >> >>> Use Case 2 "Cert Lock":
> >> >>> -- The certificate my server presents in TLS will be this =
specific
> >> >>> certificate.
> >> >>> -- Clients should accept a TLS certificate only if it matches =
this
> >> >>> certificate, but may also require that it chain to an existing =
trust anchor.
> >> >>>
> >> >>> Use Case 3 "New TA":
> >> >>> -- The certificate my server presents in TLS will chain to this =
CA,
> >> >>> which should be treated as a TA.
> >> >>> -- Clients should accept a TLS server certificate if and only =
if it
> >> >>> chains to this CA.
> >> >>>
> >> >>> Use Case 4 "Certificate as Bare Key":
> >> >>> -- The certificate my server presents in TLS will be this =
specific
> >> >>> certificate.
> >> >>> -- Clients should accept a TLS certificate if and only if it =
matches
> >> >>> this certificate.
> >> >>
> >> >> I like the wording in this taxonomy.
> >> >>
> >> >> I consider 3 and 2 to be requirements, 1 to be useful, and 4 to =
be
> >> >> mostly uninteresting if if 3 and/or 2 are implemented.
> >> >
> >> > OTOH, I think 4 is vital - otherwise self-signed certs cannot be =
first
> >> > class citizens.
> >>
> >> Indeed 4 is vital. It is what can create the biggest boost for SSL
> >> deployment ever. As mentioned a month or so ago on this list, MOST =
TLS
> >> endpoints deployed by far are running self signed certificates =
according to
> >> the http://www.eff.org/observatory (3 times more that working TLS
> >> deployments). By making it easy for those to be integrated =
properly,
> >> browsers can show TLS error messages for real cases of fraudulent =
sites,
> >> thereby increasing security dramatically on the web.
> >>
> >> Henry
> >>
> >>
> >> >
> >> >>
> >> >> --Paul Hoffman
> >>
> >> Social Web Architect
> >> http://bblfish.net/
> >>
> >> _______________________________________________
> >> dane mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/dane
> >
> >
> >
> > --
> > Website: http://hallambaker.com/
> >
> >
>=20
>=20
>=20
> --=20
> Website: http://hallambaker.com/
>=20

Social Web Architect
http://bblfish.net/


--Apple-Mail-59--570232588
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><br><div><div>On 5 Apr 2011, at 14:14, Phillip Hallam-Baker =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite">But what are the circumstances in which it is to be =
used?<div><br></div><div>Does Alice have a preference for =
confidentiality or is this essential? Does Alice need to be able to =
verify that encryption is in use? Does Alice need to know anything about =
the accountability, reputation or otherwise of the =
subject?</div></blockquote><div><br></div><div>The only thing that would =
be guaranteed to clients connecting to servers presenting self signed =
certificates matching the cert (or its bare key) in the DNSsec &nbsp;is =
connection to the computer named in the DNS. That is a huge improvement =
for all the servers presenting self signed =
certificates.</div><div><br></div><div>The way I see Dane is that it =
increases trust at every level. It is quite easy to understand why: =
there is now an additional way to confirm =
information:</div><div><br></div><div>&nbsp;- so self signed certs, move =
from just being useful for guaranteeing communication to also =
guaranteeing identity (they move from no padlock to =
padlock)</div><div>&nbsp;- CA signed certs move away from &nbsp;the =
growing danger of irrelevance - since they can be undermined by corrupt =
CAs, aka the weakest link problem - to being verified and supported by =
the DNS</div><div><br></div><div><br></div><br><blockquote =
type=3D"cite"><div><br></div><div>There is a very low end security =
approach where all we want to do is to turn on encryption if possible =
and connect with plaintext otherwise. Alice is willing to accept the =
possibility of a man in the middle approach and is not going to verify =
the status of the connection.</div></blockquote><div><br></div><div>that =
is self signed certs now, running 3 times as many TLS end points as CA =
signed tls endpoints.</div><br><blockquote type=3D"cite">
<div><br></div><div>There is also a very high end security approach =
where we wish to ensure strict security on first and every contact and =
ensure that compatible trust anchors are =
employed.</div></blockquote><div><br></div><div>Those are CAs, but they =
are not very high end because they are being undermined by bad or just =
unlucky CAs.</div><br><blockquote type=3D"cite"><div><br></div><div>And =
there are shades in between.</div>
<div><br></div><div><br></div><div>The first case can be addressed =
without DNSSEC: Just use encryption and don't provide any security =
signal (e.g. padlock) in primary chrome.</div><div><br></div><div>The =
second case needs DNSSEC and more to add trust =
in.</div></blockquote><div><br></div>No, both those cases are improved =
by DANE and DNSsec.<br><br><blockquote =
type=3D"cite"><div><br></div><div>While the precise definition of what =
'strict security' turns out to be is something we can leave to =3DJeff =
and co in WebSec. I think we need to have a story for how we could =
present the 'strict' indicator through the DNS along with the trust =
anchor/key restrictions.</div>
<div><br></div><div>We may not want to add such capability to the =
standard immediately, but we can have extensibility without impact on =
what people assert are the 'core' use cases. I don't see why we have to =
accept the idea that because some people are only interested in X we =
should deliberately design the spec so that it is only capable of doing =
X and can never, ever be extended to do anything else =
whatsoever.</div></blockquote><div><br></div><div>I don't think I ever =
claimed that supporting self signed certs should be the *only* =
requirement . Just that it is a very important use case. &nbsp;Dane is =
Win/Win for all.</div><div><br></div><br><blockquote =
type=3D"cite"><div><font class=3D"Apple-style-span" =
color=3D"#000000"><br></font></div><div>The consensus at the Prague =
meeting was very clearly that DANE needs to go back and do use cases and =
requirements.</div><div><br></div><div>In my view that means that the =
room rejected the idea of simply writing a set of requirements that =
precisely describe the capabilities of the only proposal that has been =
allowed to be considered.</div>
<div><br></div><div>There was a very strong view in the room that DANE =
has tried to move too fast to propose a solution. Now that may in part =
be my fault, I have been thinking about this particular problem for many =
years. But I think that there was also a feeling that the WG had defined =
the problem it was trying to solve to be the need to use the exact =
technology being proposed rather than look at what a potential adopter =
of the scheme might be looking for.</div>
<div><br></div><div><br></div><div>I agree that your requirement is =
essential. But I disagree with the idea that we should therefore design =
a spec that stovepipes that single =
requirement.</div></blockquote><div><br></div><div>I think it follows =
naturally. No stovepiping needed. But that's something one can discuss =
later. The requirement is pretty =
appealing.</div><div><br></div><div><br></div><div>Henry</div><br><blockqu=
ote type=3D"cite"><div><br></div><div><br></div>
<div><div class=3D"gmail_quote">On Tue, Apr 5, 2011 at 1:34 PM, Ben =
Laurie <span dir=3D"ltr">&lt;<a =
href=3D"mailto:[e-mail]">[e-mail]</a>&gt;</span> =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">On 5 April 2011 12:32, Phillip Hallam-Baker &lt;<a =
href=3D"mailto:[e-mail]">[e-mail]</a>&gt; wrote:<br>
&gt; This is not a use case approach.<br>
&gt; What we have is simply a statement of requirements which does not =
have any<br>
&gt; justification in supporting use cases.<br>
<br>
</div>This does not alter the fact that 4 is vital :-)<br>
<div><div></div><div class=3D"h5"><br>
&gt;<br>
&gt; What was asked for were use cases:<br>
&gt; [U-WS-OPP] Alice finds Sally's server through a search engine. =
Alice prefers<br>
&gt; to protect her communications with cryptography if this is =
supported by the<br>
&gt; sever but will communicate in plaintext otherwise.<br>
&gt; etc. etc.<br>
&gt;<br>
&gt;<br>
&gt; On Tue, Apr 5, 2011 at 12:43 PM, Henry Story &lt;<a =
href=3D"mailto:[e-mail]">[e-mail]</a>&gt;<br=
>
&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; On 5 Apr 2011, at 12:22, Ben Laurie wrote:<br>
&gt;&gt;<br>
&gt;&gt; &gt; On 5 April 2011 02:36, Paul Hoffman &lt;<a =
href=3D"mailto:[e-mail]">[e-mail]</a>&gt; =
wrote:<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; On Apr 4, 2011, at 6:28 PM, Richard L. Barnes =
wrote:<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt; I kind of agree with Phillip on the deadline. =
&nbsp;I would propose pushing<br>
&gt;&gt; &gt;&gt;&gt; it back to the 14th. &nbsp;My responses:<br>
&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt; 1. It occurs to me that all of the technologies =
we're talking about<br>
&gt;&gt; &gt;&gt;&gt; entail a domain owner putting something in the DNS =
to assert something about<br>
&gt;&gt; &gt;&gt;&gt; their domain, which implies some expectation about =
how the client should<br>
&gt;&gt; &gt;&gt;&gt; process TLS certs. &nbsp;So it might be useful to =
phrase use cases in terms of<br>
&gt;&gt; &gt;&gt;&gt; what the domain owner is asserting. =
&nbsp;Re-stating Ekr's use cases in this<br>
&gt;&gt; &gt;&gt;&gt; format:<br>
&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt; Use Case 1 "CA Lock":<br>
&gt;&gt; &gt;&gt;&gt; -- The certificate my server presents in TLS will =
be chain to this CA.<br>
&gt;&gt; &gt;&gt;&gt; -- Clients should accept a TLS server certificate =
only if it chains to<br>
&gt;&gt; &gt;&gt;&gt; this CA, but may also require that it chain to an =
existing trust anchor.<br>
&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt; Use Case 2 "Cert Lock":<br>
&gt;&gt; &gt;&gt;&gt; -- The certificate my server presents in TLS will =
be this specific<br>
&gt;&gt; &gt;&gt;&gt; certificate.<br>
&gt;&gt; &gt;&gt;&gt; -- Clients should accept a TLS certificate only if =
it matches this<br>
&gt;&gt; &gt;&gt;&gt; certificate, but may also require that it chain to =
an existing trust anchor.<br>
&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt; Use Case 3 "New TA":<br>
&gt;&gt; &gt;&gt;&gt; -- The certificate my server presents in TLS will =
chain to this CA,<br>
&gt;&gt; &gt;&gt;&gt; which should be treated as a TA.<br>
&gt;&gt; &gt;&gt;&gt; -- Clients should accept a TLS server certificate =
if and only if it<br>
&gt;&gt; &gt;&gt;&gt; chains to this CA.<br>
&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt; Use Case 4 "Certificate as Bare Key":<br>
&gt;&gt; &gt;&gt;&gt; -- The certificate my server presents in TLS will =
be this specific<br>
&gt;&gt; &gt;&gt;&gt; certificate.<br>
&gt;&gt; &gt;&gt;&gt; -- Clients should accept a TLS certificate if and =
only if it matches<br>
&gt;&gt; &gt;&gt;&gt; this certificate.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; I like the wording in this taxonomy.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; I consider 3 and 2 to be requirements, 1 to be useful, =
and 4 to be<br>
&gt;&gt; &gt;&gt; mostly uninteresting if if 3 and/or 2 are =
implemented.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; OTOH, I think 4 is vital - otherwise self-signed certs =
cannot be first<br>
&gt;&gt; &gt; class citizens.<br>
&gt;&gt;<br>
&gt;&gt; Indeed 4 is vital. It is what can create the biggest boost for =
SSL<br>
&gt;&gt; deployment ever. As mentioned a month or so ago on this list, =
MOST TLS<br>
&gt;&gt; endpoints deployed by far are running self signed certificates =
according to<br>
&gt;&gt; the <a href=3D"http://www.eff.org/observatory" =
target=3D"_blank">http://www.eff.org/observatory</a> (3 times more that =
working TLS<br>
&gt;&gt; deployments). By making it easy for those to be integrated =
properly,<br>
&gt;&gt; browsers can show TLS error messages for real cases of =
fraudulent sites,<br>
&gt;&gt; thereby increasing security dramatically on the web.<br>
&gt;&gt;<br>
&gt;&gt; Henry<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; --Paul Hoffman<br>
&gt;&gt;<br>
&gt;&gt; Social Web Architect<br>
&gt;&gt; <a href=3D"http://bblfish.net/" =
target=3D"_blank">http://bblfish.net/</a><br>
&gt;&gt;<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; dane mailing list<br>
&gt;&gt; <a href=3D"mailto:[e-mail]">[e-mail]</a><br>
&gt;&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/dane" =
target=3D"_blank">https://www.ietf.org/mailman/listinfo/dane</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt; Website: <a href=3D"http://hallambaker.com/" =
target=3D"_blank">http://hallambaker.com/</a><br>
&gt;<br>
&gt;<br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: =
<a href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>
</blockquote></div><br><div>
<span class=3D"Apple-style-span" style=3D"border-collapse: separate; =
color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; =
font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: 2; text-align: =
auto; text-indent: 0px; text-transform: none; white-space: normal; =
widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; "><span class=3D"Apple-style-span" =
style=3D"border-collapse: separate; color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant: normal; =
font-weight: normal; letter-spacing: normal; line-height: normal; =
orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; =
widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; "><div style=3D"word-wrap: =
break-word; -webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space; "><span class=3D"Apple-style-span" =
style=3D"border-collapse: separate; color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant: normal; =
font-weight: normal; letter-spacing: normal; line-height: normal; =
orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; =
widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; "><div style=3D"word-wrap: =
break-word; -webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space; "><span class=3D"Apple-style-span" =
style=3D"border-collapse: separate; color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant: normal; =
font-weight: normal; letter-spacing: normal; line-height: normal; =
orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; =
widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; "><div style=3D"word-wrap: =
break-word; -webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space; "><span class=3D"Apple-style-span" =
style=3D"border-collapse: separate; -webkit-border-horizontal-spacing: =
0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; -webkit-text-decorations-in-effect: none; =
text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; =
orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><div =
style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; "><span class=3D"Apple-style-span" =
style=3D"border-collapse: separate; -webkit-border-horizontal-spacing: =
0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; -webkit-text-decorations-in-effect: none; =
text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; =
orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; =
-webkit-text-decorations-in-effect: none; text-indent: 0px; =
-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
white-space: normal; widows: 2; word-spacing: 0px; "><span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; =
-webkit-text-decorations-in-effect: none; text-indent: 0px; =
-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
white-space: normal; widows: 2; word-spacing: 0px; "><span><div>Social =
Web Architect<br><a =
href=3D"http://bblfish.net/">http://bblfish.net/</a></div></span></span></=
span></span></div></span></div></span></div></span></div></span></span>
</div>
<br></body></html>=

--Apple-Mail-59--570232588--

From [e-mail]  Tue Apr  5 05:47:50 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70FE428C14A for <[e-mail]>; Tue,  5 Apr 2011 05:47:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.546
X-Spam-Level: 
X-Spam-Status: No, score=-3.546 tagged_above=-999 required=5 tests=[AWL=0.052,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MsZRLJ-+zabk for <[e-mail]>; Tue,  5 Apr 2011 05:47:43 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id E5EBD28C155 for <[e-mail]>; Tue,  5 Apr 2011 05:47:42 -0700 (PDT)
Received: by vws12 with SMTP id 12so292801vws.31 for <[e-mail]>; Tue, 05 Apr 2011 05:49:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=snNT2d9VgRXVqrR9EUVjibfzlye9NNvH3o09sxO21HY=; b=HZ+7SWReCwD7oPArWEEzm1QYH21EMvQYy5iAsAWZpPusPq1IfMGzkZMbizpD/SszAl Bux7+iAXvfyWGjh3KB2gHOyeSkYNQ+VjevCoe1o19l4ZQXOaXEgWikWEkYkZOs87GyDI nmBet+B4brw+/jv3JhHYI3NWDQfPL5i6kO/HA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=h9HDAD+qmoOGpAJxRbCSw9o+iHyIQQ03+tUQtB9bsdBRLAP4CCkDCaDHk1X8ZngIyx ytKWzLVf7ugogESJZdaEQNJ22auDYILXMQ3m8prAKXliJ+BxikGlzFdDeoLz3/0xDZya 54eZHYMgMti2moRWyjg8v+VpmZQmzY21m5DiY=
MIME-Version: 1.0
Received: by 10.52.100.39 with SMTP id ev7mr1580867vdb.218.1302007765770; Tue, 05 Apr 2011 05:49:25 -0700 (PDT)
Received: by 10.52.161.42 with HTTP; Tue, 5 Apr 2011 05:49:25 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <BANLkTimNauWFBSvsvzfx4TUcU=[e-mail]> <[e-mail]>
Date: Tue, 5 Apr 2011 14:49:25 +0200
Message-ID: <[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: Paul Hoffman <[e-mail]>
Content-Type: multipart/alternative; boundary=bcaec50163b95fa32304a02b4e6a
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2011 12:47:50 -0000

--bcaec50163b95fa32304a02b4e6a
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Apr 5, 2011 at 2:23 PM, Paul Hoffman <[e-mail]> wrote:

>
> On Apr 5, 2011, at 4:32 AM, Phillip Hallam-Baker wrote:
>
> > What we have is simply a statement of requirements which does not have
> any justification in supporting use cases.
>
> We disagree: the requirements listed by various people so far can be mapped
> to some use cases.


And we can derive the requirements from the technical proposal.

The point of use cases is that they are a tool for ensuring that the
proposal does at least bear some resemblance to actual user needs. That
point is lost if the use cases are an output of the process and not an
input.

In practice the approach is almost always bi-directional. I usually find I
am working with a client to determine their use cases by reverse engineering
their technical proposals. But the idea is that you should also work the
other way and look to see what OTHER requirements are driven by those use
cases and need to be met.


> What was asked for were use cases:
>
> Were we in the same meeting? What was asked for was requirements and use
> cases.


See the start of this thread. The WG chairs asked for Use Cases.

"1: We are asking folk to please send any additional use cases to the list
by Thursday April 7th."


> [U-WS-OPP] Alice finds Sally's server through a search engine. Alice
> prefers to protect her communications with cryptography if this is supported
> by the sever but will communicate in plaintext otherwise.
> >
> > etc. etc.
>
> This highlights what will be interesting in the use case scenario: will the
> use cases be driven by the TLS client users or TLS server users?


 Hopefully both.

But there is another complication, use case engineering is not really
designed for use in security applications. So we also need and
Assets-Risks-Threat analysis.

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

--bcaec50163b95fa32304a02b4e6a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Tue, Apr 5, 2011 at 2:23 PM, Paul Hof=
fman <span dir=3D"ltr">&lt;<a href=3D"mailto:[e-mail]">paul.ho=
[e-mail]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im"><br>
On Apr 5, 2011, at 4:32 AM, Phillip Hallam-Baker wrote:<br><br></div><div c=
lass=3D"im">
&gt; What we have is simply a statement of requirements which does not have=
 any justification in supporting use cases.<br>
<br>
</div>We disagree: the requirements listed by various people so far can be =
mapped to some use cases.</blockquote><div><br></div><div>And we can derive=
 the requirements from the technical proposal.</div><div><br></div><div>
The point of use cases is that they are a tool for ensuring that the propos=
al does at least bear some resemblance to actual user needs. That point is =
lost if the use cases are an output of the process and not an input.</div>
<div><br></div><div>In practice the approach is almost always bi-directiona=
l. I usually find I am working with a client to determine their use cases b=
y reverse engineering their technical proposals. But the idea is that you s=
hould also work the other way and look to see what OTHER requirements are d=
riven by those use cases and need to be met.</div>
<div>=A0</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class=3D"=
im">
&gt; What was asked for were use cases:<br>
<br>
</div>Were we in the same meeting? What was asked for was requirements and =
use cases.</blockquote><div><br></div><div>See the start of this thread. Th=
e WG chairs asked for Use Cases.</div><div><br></div><div>&quot;<span class=
=3D"Apple-style-span" style=3D"border-collapse: collapse; color: rgb(51, 51=
, 51); font-family: arial, sans-serif; font-size: 13px; ">1: We are asking =
folk to please send any additional use cases to the list by Thursday April =
7th.&quot;</span>=A0</div>
<meta charset=3D"utf-8"><div><br></div><div><br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex;"><div class=3D"im">
&gt; [U-WS-OPP] Alice finds Sally&#39;s server through a search engine. Ali=
ce prefers to protect her communications with cryptography if this is suppo=
rted by the sever but will communicate in plaintext otherwise.<br>
&gt;<br>
&gt; etc. etc.<br>
<br>
</div>This highlights what will be interesting in the use case scenario: wi=
ll the use cases be driven by the TLS client users or TLS server users?</bl=
ockquote><div><br></div><div>=A0Hopefully both.=A0</div><div><br></div><div=
>
But there is another complication, use case engineering is not really desig=
ned for use in security applications. So we also need and Assets-Risks-Thre=
at analysis.</div></div><br>-- <br>Website: <a href=3D"http://hallambaker.c=
om/">http://hallambaker.com/</a><br>
<br>

--bcaec50163b95fa32304a02b4e6a--

From [e-mail]  Tue Apr  5 06:02:25 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA9593A67B2 for <[e-mail]>; Tue,  5 Apr 2011 06:02:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.063
X-Spam-Level: 
X-Spam-Status: No, score=-102.063 tagged_above=-999 required=5 tests=[AWL=0.536, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dstTYL+0I8tU for <[e-mail]>; Tue,  5 Apr 2011 06:02:24 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by core3.amsl.com (Postfix) with ESMTP id 49A0C3A6403 for <[e-mail]>; Tue,  5 Apr 2011 06:02:24 -0700 (PDT)
Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p35D43d5047235 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Apr 2011 06:04:03 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Paul Hoffman <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Tue, 5 Apr 2011 06:04:03 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <BANLkTimNauWFBSvsvzfx4TUcU=[e-mail]> <[e-mail]> <[e-mail]>
To: Phillip Hallam-Baker <[e-mail]>
X-Mailer: Apple Mail (2.1084)
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2011 13:02:25 -0000

On Apr 5, 2011, at 5:49 AM, Phillip Hallam-Baker wrote:

> The point of use cases is that they are a tool for ensuring that the =
proposal does at least bear some resemblance to actual user needs. That =
point is lost if the use cases are an output of the process and not an =
input.

Fully agree.

> In practice the approach is almost always bi-directional. I usually =
find I am working with a client to determine their use cases by reverse =
engineering their technical proposals. But the idea is that you should =
also work the other way and look to see what OTHER requirements are =
driven by those use cases and need to be met.

Yep. We don't do this so well in the IETF, and it would be nice if we =
could do better here.

> > What was asked for were use cases:
>=20
> Were we in the same meeting? What was asked for was requirements and =
use cases.
>=20
> See the start of this thread. The WG chairs asked for Use Cases.
>=20
> "1: We are asking folk to please send any additional use cases to the =
list by Thursday April 7th."=20

Good catch. I was thinking of the discussion in Prague that spurred this =
thread, not the thread itself. Some people kept vehemently saying =
"requirements", and some also said "use cases".

> > [U-WS-OPP] Alice finds Sally's server through a search engine. Alice =
prefers to protect her communications with cryptography if this is =
supported by the sever but will communicate in plaintext otherwise.
> >
> > etc. etc.
>=20
> This highlights what will be interesting in the use case scenario: =
will the use cases be driven by the TLS client users or TLS server =
users?
>=20
>  Hopefully both.=20

I'm not sure of that, but that's because the use cases I'm thinking of =
are all for the TLS server admins. It would be good to see both so we =
can judge.

--Paul Hoffman


From [e-mail]  Tue Apr  5 06:13:57 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CADF828C0F5 for <[e-mail]>; Tue,  5 Apr 2011 06:13:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.150,  BAYES_00=-2.599, HELO_EQ_SE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QP8NM8VKTCHU for <[e-mail]>; Tue,  5 Apr 2011 06:13:57 -0700 (PDT)
Received: from smtp6.webway.se (smtp2.webway.se [87.96.134.128]) by core3.amsl.com (Postfix) with ESMTP id 08AF128C0E4 for <[e-mail]>; Tue,  5 Apr 2011 06:13:56 -0700 (PDT)
Received: from [192.168.20.218] (static-213-115-251-100.sme.bredbandsbolaget.se [213.115.251.100]) by smtp6.webway.se (Postfix) with ESMTPA id DDD44552F5C; Tue,  5 Apr 2011 13:15:37 +0000 (UTC)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: "Olle E. Johansson" <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Tue, 5 Apr 2011 15:15:37 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <BANLkTimNauWFBSvsvzfx4TUcU=[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
To: Paul Hoffman <[e-mail]>
X-Mailer: Apple Mail (2.1084)
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2011 13:13:57 -0000

5 apr 2011 kl. 15.04 skrev Paul Hoffman:

> On Apr 5, 2011, at 5:49 AM, Phillip Hallam-Baker wrote:
>=20
>> The point of use cases is that they are a tool for ensuring that the =
proposal does at least bear some resemblance to actual user needs. That =
point is lost if the use cases are an output of the process and not an =
input.
>=20
> Fully agree.
>=20
>> In practice the approach is almost always bi-directional. I usually =
find I am working with a client to determine their use cases by reverse =
engineering their technical proposals. But the idea is that you should =
also work the other way and look to see what OTHER requirements are =
driven by those use cases and need to be met.
>=20
> Yep. We don't do this so well in the IETF, and it would be nice if we =
could do better here.
>=20
>>> What was asked for were use cases:
>>=20
>> Were we in the same meeting? What was asked for was requirements and =
use cases.
>>=20
>> See the start of this thread. The WG chairs asked for Use Cases.
>>=20
>> "1: We are asking folk to please send any additional use cases to the =
list by Thursday April 7th."=20
>=20
> Good catch. I was thinking of the discussion in Prague that spurred =
this thread, not the thread itself. Some people kept vehemently saying =
"requirements", and some also said "use cases".
>=20
>>> [U-WS-OPP] Alice finds Sally's server through a search engine. Alice =
prefers to protect her communications with cryptography if this is =
supported by the sever but will communicate in plaintext otherwise.
>>>=20
>>> etc. etc.
>>=20
>> This highlights what will be interesting in the use case scenario: =
will the use cases be driven by the TLS client users or TLS server =
users?
>>=20
>> Hopefully both.=20
>=20
> I'm not sure of that, but that's because the use cases I'm thinking of =
are all for the TLS server admins. It would be good to see both so we =
can judge.
>=20
In the SIP world, it's actually both.

Paul's phone client wants to place a secure call to Philip. Philips' =
proxy is the first server, Philip's phone is the next one, contacted by =
the proxy. After initial rendez-vous using the SIP proxy the SIP phones =
may connect p2p, where Philip's phone connect to Paul's phone, whose =
phone is now a server.

I can't get my head around where DANE comes into the picture after step =
one - where Paul use Philip's SIP uri domain to get the cacert for that =
domain or the actual cert for that server (or fingerprints). If DANE has =
a use case in step two - where the proxy contacts a phone or step three, =
where Philips phone contacts Pauls phone directly. If step three is =
using a domain contact URI, DANE has a role. In SIP lingo, that would be =
a gruu.

Just to get a use case which is not clearly client-server following the =
HTTP model.

/O=

From [e-mail]  Tue Apr  5 06:15:28 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77F6228C101 for <[e-mail]>; Tue,  5 Apr 2011 06:15:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.546
X-Spam-Level: 
X-Spam-Status: No, score=-3.546 tagged_above=-999 required=5 tests=[AWL=0.052,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgoHyixE+7ll for <[e-mail]>; Tue,  5 Apr 2011 06:15:20 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id A54AA3A6403 for <[e-mail]>; Tue,  5 Apr 2011 06:15:20 -0700 (PDT)
Received: by vws12 with SMTP id 12so317272vws.31 for <[e-mail]>; Tue, 05 Apr 2011 06:17:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=QCXegnT1xBDg2OEljMvPBkjzXRsQ2Iz1WjCFi9/uhI4=; b=UuOs93L5uXKHdlvnf6YrDB/quFg/A5/NC58Rk9nW24iiQKoSkWqKBymuK0Z4Z/uu6N mvhbzG4qQoK9izsdxZ0FYaCD9PFrlQbJMe+jRIzxcWO3qerZ+7MC8GOUsqXJ4r/lEqgB v2InINyE13t/wTPhdnudAzHLW0E8JHskyn4YY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=bg/gxm+i368G1yx1wP35JKt8Mf2FJUH/th9TbCTmgq/cERONcI564Y31ZtD7zDvjOh GhBfZacctQoVI7/JGcV7VBwCj0BTrRdPdwwdOdf/2kiYieUi6frL9ofvXjsC70HuCwhn +BjjXMa/5cwWqEY0JFkNJCCVhk2JpML7w33XY=
MIME-Version: 1.0
Received: by 10.52.0.205 with SMTP id 13mr11044360vdg.58.1302009423425; Tue, 05 Apr 2011 06:17:03 -0700 (PDT)
Received: by 10.52.161.42 with HTTP; Tue, 5 Apr 2011 06:17:03 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <BANLkTimNauWFBSvsvzfx4TUcU=[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 5 Apr 2011 15:17:03 +0200
Message-ID: <BANLkTik=XV3Qu=LkAEgMhKdn9=[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: Henry Story <[e-mail]>
Content-Type: multipart/alternative; boundary=20cf304346e42d729404a02bb19f
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2011 13:15:28 -0000

--20cf304346e42d729404a02bb19f
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Apr 5, 2011 at 2:36 PM, Henry Story <[e-mail]> wrote:

>
> On 5 Apr 2011, at 14:14, Phillip Hallam-Baker wrote:
>
> But what are the circumstances in which it is to be used?
>
> Does Alice have a preference for confidentiality or is this essential? Does
> Alice need to be able to verify that encryption is in use? Does Alice need
> to know anything about the accountability, reputation or otherwise of the
> subject?
>
>
> The only thing that would be guaranteed to clients connecting to servers
> presenting self signed certificates matching the cert (or its bare key) in
> the DNSsec  is connection to the computer named in the DNS. That is a huge
> improvement for all the servers presenting self signed certificates.
>
> The way I see Dane is that it increases trust at every level. It is quite
> easy to understand why: there is now an additional way to confirm
> information:
>
>  - so self signed certs, move from just being useful for guaranteeing
> communication to also guaranteeing identity (they move from no padlock to
> padlock)
>

I don't think that is justified. We should eliminate the padlock entirely
for all classes of certificate.

The user interprets the padlock icon as proof that they are safe, that the
party they are dealing with is trustworthy.

Owning a DNS name does not make you a good person. So I can't see a
justification for showing the padlock for any Domain Validated certificate.

The user is not going to check the status of the connection in any case, so
why provide information that is only going to confuse the user and be
misinterpreted?

There is a very low end security approach where all we want to do is to turn
> on encryption if possible and connect with plaintext otherwise. Alice is
> willing to accept the possibility of a man in the middle approach and is not
> going to verify the status of the connection.
>
>
> that is self signed certs now, running 3 times as many TLS end points as CA
> signed tls endpoints.
>

How many of those are mail servers?

What is the desired fallback strategy?


Let us say that Alice's mail server is connecting to Bob's mail server to
deliver mail and that Mallet is posing as a man in the middle and presents a
non compliant cert. Note that neither user is present during the exchange
and so we can't fallback to asking the user what to do. What is your
preferred outcome:

1) Alice's mail server refuses to deliver mail to Bob's mail server?

2) Alice's mail server uses the bogus certificate and delivers the mail
anyway?

3) Alice's mail server delivers the mail en-clair?


Now I would guess that the preferred outcome is (1) but none of the outcomes
are exactly good and the outcome that the programmers are likely to code is
probably (3) which is the worst of the lot.

Under the existing DANE draft, Mallet can force outcome #3 by simply
stripping out the STARTTLS request which is (inevitably) sent before we have
authentication.


There are in fact two downgrade attacks possible here:

1) Force the user to accept a bogus certificate

2) Force the user to accept the communication en-clair.

Attack #2 dominates attack #1.

I agree that we should address #1. But we achieve no security benefit unless
we also address #2.

The first case can be addressed without DNSSEC: Just use encryption and
> don't provide any security signal (e.g. padlock) in primary chrome.
>
> The second case needs DNSSEC and more to add trust in.
>
>
> No, both those cases are improved by DANE and DNSsec.
>

Not unless you also address the protocol downgrade attack.

If you allow the SSL stripping downgrade attack, preventing the use of a
bogus cert is irrelevant for Internet services and of marginal utility for
Web browsing transactions.

The user is going to ignore the padlock and click through any warning
screen.


The only case where I can see a value to using DNSSEC here is if we start by
telling the client that TLS is always available at the genuine service.

If there is a mechanism that allows the client to verify the use of TLS
without user involvement, the padlock icon becomes unnecessary.

While the precise definition of what 'strict security' turns out to be is
> something we can leave to =Jeff and co in WebSec. I think we need to have a
> story for how we could present the 'strict' indicator through the DNS along
> with the trust anchor/key restrictions.
>
> We may not want to add such capability to the standard immediately, but we
> can have extensibility without impact on what people assert are the 'core'
> use cases. I don't see why we have to accept the idea that because some
> people are only interested in X we should deliberately design the spec so
> that it is only capable of doing X and can never, ever be extended to do
> anything else whatsoever.
>
>
> I don't think I ever claimed that supporting self signed certs should be
> the *only* requirement . Just that it is a very important use case.
>

I don't think it is useful to get back into an argument of who said what or
argued what.



>  Dane is Win/Win for all.
>

Hopefully not. I would hope that a security protocol is a lose for Mallet.


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

--20cf304346e42d729404a02bb19f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Tue, Apr 5, 2011 at 2:36 PM, Henry St=
ory <span dir=3D"ltr">&lt;<a href=3D"mailto:[e-mail]">henry.=
[e-mail]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style=3D"word-wrap:break-word"><br><div><div class=3D"im"><div>On 5 Ap=
r 2011, at 14:14, Phillip Hallam-Baker wrote:</div><br><blockquote type=3D"=
cite">But what are the circumstances in which it is to be used?<div><br></d=
iv>
<div>Does Alice have a preference for confidentiality or is this essential?=
 Does Alice need to be able to verify that encryption is in use? Does Alice=
 need to know anything about the accountability, reputation or otherwise of=
 the subject?</div>
</blockquote><div><br></div></div><div>The only thing that would be guarant=
eed to clients connecting to servers presenting self signed certificates ma=
tching the cert (or its bare key) in the DNSsec =A0is connection to the com=
puter named in the DNS. That is a huge improvement for all the servers pres=
enting self signed certificates.</div>
<div><br></div><div>The way I see Dane is that it increases trust at every =
level. It is quite easy to understand why: there is now an additional way t=
o confirm information:</div><div><br></div><div>=A0- so self signed certs, =
move from just being useful for guaranteeing communication to also guarante=
eing identity (they move from no padlock to padlock)</div>
</div></div></blockquote><div><br></div><div>I don&#39;t think that is just=
ified. We should eliminate the padlock entirely for all classes of certific=
ate.=A0</div><div><br></div><div>The user interprets the padlock icon as pr=
oof that they are safe, that the party they are dealing with is trustworthy=
.</div>
<div><br></div><div>Owning a DNS name does not make you a good person. So I=
 can&#39;t see a justification for showing the padlock for any Domain Valid=
ated certificate.</div><div><br></div><div>The user is not going to check t=
he status of the connection in any case, so why provide information that is=
 only going to confuse the user and be misinterpreted?</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex;"><div style=3D"word-wrap:brea=
k-word"><div><div class=3D"im"><blockquote type=3D"cite"><div>There is a ve=
ry low end security approach where all we want to do is to turn on encrypti=
on if possible and connect with plaintext otherwise. Alice is willing to ac=
cept the possibility of a man in the middle approach and is not going to ve=
rify the status of the connection.</div>
</blockquote><div><br></div></div><div>that is self signed certs now, runni=
ng 3 times as many TLS end points as CA signed tls endpoints.</div></div></=
div></blockquote><div><br></div><div>How many of those are mail servers?=A0=
</div>
<div><br></div><div>What is the desired fallback strategy?</div><div><br></=
div><div><br></div><div>Let us say that Alice&#39;s mail server is connecti=
ng to Bob&#39;s mail server to deliver mail and that Mallet is posing as a =
man in the middle and presents a non compliant cert. Note that neither user=
 is present during the exchange and so we can&#39;t fallback to asking the =
user what to do. What is your preferred outcome:</div>
<div><br></div><div>1) Alice&#39;s mail server refuses to deliver mail to B=
ob&#39;s mail server?</div><div><br></div><div>2) Alice&#39;s mail server u=
ses the bogus certificate and delivers the mail anyway?</div><div><br></div=
>
<div>3) Alice&#39;s mail server delivers the mail en-clair?</div><div><br><=
/div><div><br></div><div>Now I would guess that the preferred outcome is (1=
) but none of the outcomes are exactly good and the outcome that the progra=
mmers are likely to code is probably (3) which is the worst of the lot.</di=
v>
<div><br></div><div>Under the existing DANE draft, Mallet can force outcome=
 #3 by simply stripping out the STARTTLS request which is (inevitably) sent=
 before we have authentication.</div><div><br></div><div><br></div><div>
There are in fact two downgrade attacks possible here:</div><div><br></div>=
<div>1) Force the user to accept a bogus certificate</div><div><br></div><d=
iv>2) Force the user to accept the communication en-clair.</div><div><br>
</div><div>Attack #2 dominates attack #1.=A0</div><div><br></div><div>I agr=
ee that we should address #1. But we achieve no security benefit unless we =
also address #2.=A0</div><div><br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style=3D"word-wrap:break-word"><div><div class=3D"im"><blockquote type=
=3D"cite"><div>The first case can be addressed without DNSSEC: Just use enc=
ryption and don&#39;t provide any security signal (e.g. padlock) in primary=
 chrome.</div>
<div><br></div><div>The second case needs DNSSEC and more to add trust in.<=
/div></blockquote><div><br></div></div>No, both those cases are improved by=
 DANE and DNSsec.</div></div></blockquote><div><br></div><div>Not unless yo=
u also address the protocol downgrade attack.</div>
<div><br></div><div>If you allow the SSL stripping downgrade attack, preven=
ting the use of a bogus cert is irrelevant for Internet services and of mar=
ginal utility for Web browsing transactions.</div><div><br></div><div>The u=
ser is going to ignore the padlock and click through any warning screen.</d=
iv>
<div><br></div><div><br></div><div>The only case where I can see a value to=
 using DNSSEC here is if we start by telling the client that TLS is always =
available at the genuine service.=A0</div><div><br></div><div>If there is a=
 mechanism that allows the client to verify the use of TLS without user inv=
olvement, the padlock icon becomes unnecessary.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex;"><div style=3D"word-wrap:brea=
k-word"><div><div class=3D"im"><blockquote type=3D"cite"><div>While the pre=
cise definition of what &#39;strict security&#39; turns out to be is someth=
ing we can leave to =3DJeff and co in WebSec. I think we need to have a sto=
ry for how we could present the &#39;strict&#39; indicator through the DNS =
along with the trust anchor/key restrictions.</div>

<div><br></div><div>We may not want to add such capability to the standard =
immediately, but we can have extensibility without impact on what people as=
sert are the &#39;core&#39; use cases. I don&#39;t see why we have to accep=
t the idea that because some people are only interested in X we should deli=
berately design the spec so that it is only capable of doing X and can neve=
r, ever be extended to do anything else whatsoever.</div>
</blockquote><div><br></div></div><div>I don&#39;t think I ever claimed tha=
t supporting self signed certs should be the *only* requirement . Just that=
 it is a very important use case.</div></div></div></blockquote><div><br>
</div><div>I don&#39;t think it is useful to get back into an argument of w=
ho said what or argued what.</div><div><br></div><div>=A0</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex;">
<div style=3D"word-wrap:break-word"><div><div> =A0Dane is Win/Win for all.<=
/div></div></div></blockquote><div><br></div><div>Hopefully not. I would ho=
pe that a security protocol is a lose for Mallet.</div><div><br></div><div>
<br></div></div>-- <br>Website: <a href=3D"http://hallambaker.com/">http://=
hallambaker.com/</a><br><br>

--20cf304346e42d729404a02bb19f--

From [e-mail]  Tue Apr  5 06:24:56 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE2BF28C102 for <[e-mail]>; Tue,  5 Apr 2011 06:24:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.466
X-Spam-Level: 
X-Spam-Status: No, score=-102.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l0rr5ak3Xf9T for <[e-mail]>; Tue,  5 Apr 2011 06:24:56 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 3978E28C101 for <[e-mail]>; Tue,  5 Apr 2011 06:24:56 -0700 (PDT)
Received: from ros-dhcp192-1-51-86.bbn.com ([192.1.51.86]:57111) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from <[e-mail]>) id 1Q76HE-000N9g-NU; Tue, 05 Apr 2011 09:26:37 -0400
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: "Richard L. Barnes" <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Tue, 5 Apr 2011 09:26:34 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <BANLkTimNauWFBSvsvzfx4TUcU=[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
To: "Olle E. Johansson" <[e-mail]>
X-Mailer: Apple Mail (2.1082)
Cc: Paul Hoffman <[e-mail]>, [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2011 13:24:57 -0000

>>>> [U-WS-OPP] Alice finds Sally's server through a search engine. =
Alice prefers to protect her communications with cryptography if this is =
supported by the sever but will communicate in plaintext otherwise.
>>>>=20
>>>> etc. etc.
>>>=20
>>> This highlights what will be interesting in the use case scenario: =
will the use cases be driven by the TLS client users or TLS server =
users?
>>>=20
>>> Hopefully both.=20
>>=20
>> I'm not sure of that, but that's because the use cases I'm thinking =
of are all for the TLS server admins. It would be good to see both so we =
can judge.
>>=20
> In the SIP world, it's actually both.
>=20
> Paul's phone client wants to place a secure call to Philip. Philips' =
proxy is the first server, Philip's phone is the next one, contacted by =
the proxy. After initial rendez-vous using the SIP proxy the SIP phones =
may connect p2p, where Philip's phone connect to Paul's phone, whose =
phone is now a server.
>=20
> I can't get my head around where DANE comes into the picture after =
step one - where Paul use Philip's SIP uri domain to get the cacert for =
that domain or the actual cert for that server (or fingerprints). If =
DANE has a use case in step two - where the proxy contacts a phone or =
step three, where Philips phone contacts Pauls phone directly. If step =
three is using a domain contact URI, DANE has a role. In SIP lingo, that =
would be a gruu.
>=20
> Just to get a use case which is not clearly client-server following =
the HTTP model.
>=20
> /O

On the one hand, I think this case is pretty clearly out of the initial =
scope of the working group, which is focused on single TLS connections.  =
On the other hand, it might be addressed at least in part by Paul's =
S/MIME draft, since SIP identifiers and email identifiers have basically =
the same form.

--Richard


From [e-mail]  Tue Apr  5 06:30:56 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBBD128C11B for <[e-mail]>; Tue,  5 Apr 2011 06:30:56 -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=-0.449, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVORHK4tsXSt for <[e-mail]>; Tue,  5 Apr 2011 06:30:49 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 389DE28C111 for <[e-mail]>; Tue,  5 Apr 2011 06:30:49 -0700 (PDT)
Received: by vxg33 with SMTP id 33so330964vxg.31 for <[e-mail]>; Tue, 05 Apr 2011 06:32:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=q224XDRGTI5NSNKmOFPE2KFEHOvTukhQ0gK/iJLao+g=; b=R3IqXo9L5hiIn9BKqtQMWmdLcExc/+1TT45fCKiy045gjELYvZaY6tt5ofUVc6166g AMER6e3vsvA/gqouvgWSrFXfrHAyUJO0I8GpxcmP5ULBwZcEKK7HKa5kBsyw4kVhRbaJ gHN+JEGIBDfExxy4FfV2nYGNgX4WeoskR+01Q=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ewqRo52xgpEY0DG6NKh+nphL4oXkfg0kM+ZCALlQ1m0tFt7ZG015nluFhAQxVXBuOd i7NX2cMXoNO7cuFdynKSkf7Ts1D8FMoaZjC4kRDBxWYbo0piLm5IelkESpr40dSpY70N voC8WcZJyUeSAeeKYFMxXwDBW3zZhHfiv8sMs=
MIME-Version: 1.0
Received: by 10.52.0.205 with SMTP id 13mr11069278vdg.58.1302010352211; Tue, 05 Apr 2011 06:32:32 -0700 (PDT)
Received: by 10.52.161.42 with HTTP; Tue, 5 Apr 2011 06:32:32 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Tue, 5 Apr 2011 15:32:32 +0200
Message-ID: <[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: Florian Weimer <[e-mail]>
Content-Type: multipart/alternative; boundary=20cf304346e489986c04a02be875
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Objective: Restrictive versus Supplementary Models
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2011 13:30:56 -0000

--20cf304346e489986c04a02be875
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Apr 5, 2011 at 1:13 PM, Florian Weimer <[e-mail]> wrote:

> * Eric Rescorla:
>
> > In the second case, the intention is to allow clients to effectively
> > bypass the existing trust hierarchy by injecting a new trust point
> > via the DNS. Thus, either the certificate validation simply will not
> > be used at all (in the case where a terminal certificate is
> > provided) or will be used up to a newly inserted trust anchor. In
> > either case, the presumptive rationale here is that it's too
> > inconvenient to deal with the existing CAs and that DANE will be
> > easier.  This version of DANE *does* need to be protected via DNSSEC
> > because tampering with these records allows the attacker to
> > impersonate the authenticating party to the relying party.
>
> If you switch HTTPS transparently (meaning: no UI indicators, secure
> cookies are not sent, SOP checks run against :80 instead of :443),
> then you don't need DNSSEC.
>
> I'm pretty sure it's politically and technically infeasible to
> introduce DNSSEC-driven UI changes on a larger scale, so I doubt that
> any non-transparent approach will fly.
>

The trend is certainly to deprecate providing a security signal to indicate
use of DV certs. The only reason it is done today is that this is the legacy
approach and the current protocols require the user to check that TLS is in
use.

So I really can't see how an argument of the form 'DNSSEC validation is just
as good as DV, therefore it should get a padlock icon' is going to get
traction with the browser providers.

The question they are going to ask is 'what level of security notification
is justified and/or necessary'.


Anyone care to argue that mere possession of a DNS domain makes you
trustworthy?


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

--20cf304346e489986c04a02be875
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Tue, Apr 5, 2011 at 1:13 PM, Florian =
Weimer <span dir=3D"ltr">&lt;<a href=3D"mailto:[e-mail]">fweimer@bfk.=
de</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
* Eric Rescorla:<br>
<div class=3D"im"><br>
&gt; In the second case, the intention is to allow clients to effectively<b=
r>
&gt; bypass the existing trust hierarchy by injecting a new trust point<br>
&gt; via the DNS. Thus, either the certificate validation simply will not<b=
r>
&gt; be used at all (in the case where a terminal certificate is<br>
&gt; provided) or will be used up to a newly inserted trust anchor. In<br>
&gt; either case, the presumptive rationale here is that it&#39;s too<br>
&gt; inconvenient to deal with the existing CAs and that DANE will be<br>
&gt; easier. =A0This version of DANE *does* need to be protected via DNSSEC=
<br>
&gt; because tampering with these records allows the attacker to<br>
&gt; impersonate the authenticating party to the relying party.<br>
<br>
</div>If you switch HTTPS transparently (meaning: no UI indicators, secure<=
br>
cookies are not sent, SOP checks run against :80 instead of :443),<br>
then you don&#39;t need DNSSEC.<br>
<br>
I&#39;m pretty sure it&#39;s politically and technically infeasible to<br>
introduce DNSSEC-driven UI changes on a larger scale, so I doubt that<br>
any non-transparent approach will fly.<br></blockquote><div><br></div><div>=
The trend is certainly to deprecate providing a security signal to indicate=
 use of DV certs. The only reason it is done today is that this is the lega=
cy approach and the current protocols require the user to check that TLS is=
 in use.</div>
<div><br></div><div>So I really can&#39;t see how an argument of the form &=
#39;DNSSEC validation is just as good as DV, therefore it should get a padl=
ock icon&#39; is going to get traction with the browser providers.</div>
<div><br></div><div>The question they are going to ask is &#39;what level o=
f security notification is justified and/or necessary&#39;.=A0</div><div><b=
r></div><div><br></div><div>Anyone care to argue that mere possession of a =
DNS domain makes you trustworthy?</div>
</div><div><br></div><div><br></div>-- <br>Website: <a href=3D"http://halla=
mbaker.com/">http://hallambaker.com/</a><br><br>

--20cf304346e489986c04a02be875--

From [e-mail]  Tue Apr  5 07:06:02 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD96A28C145 for <[e-mail]>; Tue,  5 Apr 2011 07:06:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.558
X-Spam-Level: 
X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Ua4GyG5r3BZ for <[e-mail]>; Tue,  5 Apr 2011 07:05:55 -0700 (PDT)
Received: from homiemail-a62.g.dreamhost.com (mx1.spunky.mail.dreamhost.com [208.97.132.47]) by core3.amsl.com (Postfix) with ESMTP id 8393D3A67E7 for <[e-mail]>; Tue,  5 Apr 2011 07:05:55 -0700 (PDT)
Received: from homiemail-a62.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTP id A9789634080; Tue,  5 Apr 2011 07:07:38 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=R3H5eM6PKQQ8LCfKC9iHl50vpS9SRX2GZU12K3wqDb/ jC5NAIhsk4Pi+WHZ0aslkRBa3/xz2TOtVLUKWfxSfahSqByks92PMnA6Sgoi8t1w NE2j1hIdM9PECs/DByez266Uyal6I4Oo12r8FvWA2ZO5lRh2O2MFpMNfcoKWGkC4 =
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=tOMseycukbuqytseSHyJGXH3tiU=; b=tZiB9ch+vB RUm8+MQEykmfxjUWF9d9tW1UWgMyZ2vIjCi1uzc1/c3wHYELHcFVtNU604JGtU8S iITG9YHQ+UAbE5hnUg2Vdwgyz0nTfJdPoNBfuKCluGmMCAhDMiV0xfrYsGSqU9vN l4vqQU6IsiQuPhdidGNwvknIlVD/So4aA=
Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: [e-mail]) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTPA id 0F6DE634075;  Tue,  5 Apr 2011 07:07:37 -0700 (PDT)
From: Matt McCutchen <[e-mail]>
To: Florian Weimer <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 05 Apr 2011 10:07:35 -0400
Message-ID: <1302012455.3356.7.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.3 
Content-Transfer-Encoding: 7bit
Cc: [e-mail]
Subject: Re: [dane] Objective: Restrictive versus Supplementary Models
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2011 14:06:02 -0000

On Tue, 2011-04-05 at 11:13 +0000, Florian Weimer wrote:
> If you switch HTTPS transparently (meaning: no UI indicators, secure
> cookies are not sent, SOP checks run against :80 instead of :443),
> then you don't need DNSSEC.

Indeed, this could be done, but I want server-authenticated connections.

> I'm pretty sure it's politically and technically infeasible to
> introduce DNSSEC-driven UI changes on a larger scale, so I doubt that
> any non-transparent approach will fly.

Technically, the existing Firefox blue badge works with my modified NSS
(https://mattmccutchen.net/cryptid/#nss-dane) if you ignore the
unvalidated certificate details.  Politically, I don't know, but I would
use such a browser.

-- 
Matt


From [e-mail]  Tue Apr  5 07:08:53 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8610F3A6939 for <[e-mail]>; Tue,  5 Apr 2011 07:08:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.196
X-Spam-Level: 
X-Spam-Status: No, score=-3.196 tagged_above=-999 required=5 tests=[AWL=0.087,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wD3N9wzBGO8u for <[e-mail]>; Tue,  5 Apr 2011 07:08:44 -0700 (PDT)
Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by core3.amsl.com (Postfix) with ESMTP id D187828C115 for <[e-mail]>; Tue,  5 Apr 2011 07:08:43 -0700 (PDT)
Received: by wwk4 with SMTP id 4so2785955wwk.1 for <[e-mail]>; Tue, 05 Apr 2011 07:10:26 -0700 (PDT)
Received: by 10.216.141.225 with SMTP id g75mr8237421wej.10.1302012625440; Tue, 05 Apr 2011 07:10:25 -0700 (PDT)
Received: from bblfish.home (ALagny-751-1-3-136.w86-218.abo.wanadoo.fr [86.218.42.136]) by mx.google.com with ESMTPS id t5sm2795771wes.9.2011.04.05.07.10.23 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Apr 2011 07:10:24 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: multipart/alternative; boundary=Apple-Mail-60--564608836
From: Henry Story <[e-mail]>
In-Reply-To: <BANLkTik=XV3Qu=LkAEgMhKdn9=[e-mail]>
Date: Tue, 5 Apr 2011 16:10:21 +0200
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <BANLkTimNauWFBSvsvzfx4TUcU=[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <BANLkTik=XV3Qu=LkAEgMhKdn9=[e-mail]>
To: Phillip Hallam-Baker <[e-mail]>
X-Mailer: Apple Mail (2.1082)
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2011 14:08:53 -0000

--Apple-Mail-60--564608836
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On 5 Apr 2011, at 15:17, Phillip Hallam-Baker wrote:
> On Tue, Apr 5, 2011 at 2:36 PM, Henry Story <[e-mail]> =
wrote:
>=20
> On 5 Apr 2011, at 14:14, Phillip Hallam-Baker wrote:
>=20
>> But what are the circumstances in which it is to be used?
>>=20
>> Does Alice have a preference for confidentiality or is this =
essential? Does Alice need to be able to verify that encryption is in =
use? Does Alice need to know anything about the accountability, =
reputation or otherwise of the subject?
>=20
> The only thing that would be guaranteed to clients connecting to =
servers presenting self signed certificates matching the cert (or its =
bare key) in the DNSsec  is connection to the computer named in the DNS. =
That is a huge improvement for all the servers presenting self signed =
certificates.
>=20
> The way I see Dane is that it increases trust at every level. It is =
quite easy to understand why: there is now an additional way to confirm =
information:
>=20
>  - so self signed certs, move from just being useful for guaranteeing =
communication to also guaranteeing identity (they move from no padlock =
to padlock)
>=20
> I don't think that is justified. We should eliminate the padlock =
entirely for all classes of certificate.=20
>=20
> The user interprets the padlock icon as proof that they are safe, that =
the party they are dealing with is trustworthy.

I don't think it is up to this group to work on the semantics of the =
padlock frankly. Those are UI issues to be discussed by another group, =
browser vendors in particular.=20

> Owning a DNS name does not make you a good person.

Owning a multi billion dollar company that can afford a EV cert does not =
do that either. I think we have seen plenty of examples of that =
recently. Certification does not guarantee moral behavior, just =
identity. With DNS & Dane it is domain-name identity. CA's can then add =
extra information and certify additional properties.

> So I can't see a justification for showing the padlock for any Domain =
Validated certificate.
>=20
> The user is not going to check the status of the connection in any =
case, so why provide information that is only going to confuse the user =
and be misinterpreted?

Again we should not discuss UI elements here, unless we want to get =
completely sidetracked.

You may not see the value of knowing you reached the site you clicked =
on, but I and many people do.
I would love to know when I reach those 10s of millions of sites that =
had self signed certs that they are the sites that I was intending to =
connect to. I would love to know that I reached the web page that the =
site I was on had linked to. I would put a padlock there, you may not. =
But the use case is there and it is the obvious thing one can use Dane =
for.


>=20
>> There is a very low end security approach where all we want to do is =
to turn on encryption if possible and connect with plaintext otherwise. =
Alice is willing to accept the possibility of a man in the middle =
approach and is not going to verify the status of the connection.
>=20
> that is self signed certs now, running 3 times as many TLS end points =
as CA signed tls endpoints.
>=20
> How many of those are mail servers?=20

You can go to the EFF observatory page, download the database of the =
observatory and answer all those
questions yourself. They explain how to do this here:

  http://www.youtube.com/watch?v=3DVUKCDm04AqI

>=20
> What is the desired fallback strategy?
>=20
>=20
> Let us say that Alice's mail server is connecting to Bob's mail server =
to deliver mail and that Mallet is posing as a man in the middle and =
presents a non compliant cert. Note that neither user is present during =
the exchange and so we can't fallback to asking the user what to do. =
What is your preferred outcome:
>=20
> 1) Alice's mail server refuses to deliver mail to Bob's mail server?
>=20
> 2) Alice's mail server uses the bogus certificate and delivers the =
mail anyway?
>=20
> 3) Alice's mail server delivers the mail en-clair?

My question is: how is it done now?  In what percentage of case do =
people choose which option? Then you will find that in a very large =
percentage of cases security is not added at all because the simple =
solution of self signed certs is not available. Make that possible and =
easy and you increase the space in which secure behavior is possible.

With Dane you just increase the security of those servers that wish to =
be secure. You increase the scope of secure behavior. You make secure =
behavior cheaper, and so more widely used, which creates network =
effects.

>  would guess that the preferred outcome is (1) but none of the =
outcomes are exactly good and the outcome that the programmers are =
likely to code is probably (3) which is the worst of the lot.
>=20
> Under the existing DANE draft, Mallet can force outcome #3 by simply =
stripping out the STARTTLS request which is (inevitably) sent before we =
have authentication.
>=20
> There are in fact two downgrade attacks possible here:
>=20
> 1) Force the user to accept a bogus certificate
>=20
> 2) Force the user to accept the communication en-clair.
>=20
> Attack #2 dominates attack #1.=20
>=20
> I agree that we should address #1. But we achieve no security benefit =
unless we also address #2.=20

Ok, I don't see why allowing Dane to publish self signed certs affects =
this at all? Does it not make things easier? In the HTTPS case it =
clearly does.

>=20
>> The first case can be addressed without DNSSEC: Just use encryption =
and don't provide any security signal (e.g. padlock) in primary chrome.
>>=20
>> The second case needs DNSSEC and more to add trust in.
>=20
> No, both those cases are improved by DANE and DNSsec.
>=20
> Not unless you also address the protocol downgrade attack.
>=20
> If you allow the SSL stripping downgrade attack, preventing the use of =
a bogus cert is irrelevant for Internet services and of marginal utility =
for Web browsing transactions.
>=20
> The user is going to ignore the padlock and click through any warning =
screen.

There will be a lot less warning screens in his day to day experience, =
and so it will be possible to teach the user to take  failures more =
seriously. Currently there are many cases where users are taught to =
click through the warning screen, by knowledgeable people. This can =
become a habit. Allowing self signed certs to be published in Dane will =
make it easy to tell people: why don't you just publish your self signed =
cert in DNS? If you can't even bother to do that, then why should I take =
your site/service seriously.

>=20
> The only case where I can see a value to using DNSSEC here is if we =
start by telling the client that TLS is always available at the genuine =
service.

That is indeed the idea: make a web that is very much more widely TLS =
based. Increase the usage of TLS 100 fold or more. Make it the default. =
Why not? Google are doing it now, Facebook is. Soon everyone will. After =
all any web page with links to other sites that is not protected is a =
danger, because it could be man in the middled to rewrite URLs and point =
people to the wrong site.

>  If there is a mechanism that allows the client to verify the use of =
TLS without user involvement, the padlock icon becomes unnecessary.

Again that is a UI issue, which is exceedingly important, but not one we =
should concern ourselves here. Assume UI specialists, graphics artists, =
and people with a humanities background will do their job.

>=20
>> While the precise definition of what 'strict security' turns out to =
be is something we can leave to =3DJeff and co in WebSec. I think we =
need to have a story for how we could present the 'strict' indicator =
through the DNS along with the trust anchor/key restrictions.
>>=20
>> We may not want to add such capability to the standard immediately, =
but we can have extensibility without impact on what people assert are =
the 'core' use cases. I don't see why we have to accept the idea that =
because some people are only interested in X we should deliberately =
design the spec so that it is only capable of doing X and can never, =
ever be extended to do anything else whatsoever.
>=20
> I don't think I ever claimed that supporting self signed certs should =
be the *only* requirement . Just that it is a very important use case.
>=20
> I don't think it is useful to get back into an argument of who said =
what or argued what.
>=20
> =20
>  Dane is Win/Win for all.
>=20
> Hopefully not. I would hope that a security protocol is a lose for =
Mallet.

I seem to have hit a nerve.

Henry

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

Social Web Architect
http://bblfish.net/


--Apple-Mail-60--564608836
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><br><div><div>On 5 Apr 2011, at 15:17, Phillip Hallam-Baker =
wrote:</div><blockquote type=3D"cite"><div class=3D"gmail_quote">On Tue, =
Apr 5, 2011 at 2:36 PM, Henry Story <span dir=3D"ltr">&lt;<a =
href=3D"mailto:[e-mail]">[e-mail]</a>&gt;</s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style=3D"word-wrap:break-word"><br><div><div class=3D"im"><div>On 5 =
Apr 2011, at 14:14, Phillip Hallam-Baker wrote:</div><br><blockquote =
type=3D"cite">But what are the circumstances in which it is to be =
used?<div><br></div>
<div>Does Alice have a preference for confidentiality or is this =
essential? Does Alice need to be able to verify that encryption is in =
use? Does Alice need to know anything about the accountability, =
reputation or otherwise of the subject?</div>
</blockquote><div><br></div></div><div>The only thing that would be =
guaranteed to clients connecting to servers presenting self signed =
certificates matching the cert (or its bare key) in the DNSsec &nbsp;is =
connection to the computer named in the DNS. That is a huge improvement =
for all the servers presenting self signed certificates.</div>
<div><br></div><div>The way I see Dane is that it increases trust at =
every level. It is quite easy to understand why: there is now an =
additional way to confirm information:</div><div><br></div><div>&nbsp;- =
so self signed certs, move from just being useful for guaranteeing =
communication to also guaranteeing identity (they move from no padlock =
to padlock)</div>
</div></div></blockquote><div><br></div><div>I don't think that is =
justified. We should eliminate the padlock entirely for all classes of =
certificate.&nbsp;</div><div><br></div><div>The user interprets the =
padlock icon as proof that they are safe, that the party they are =
dealing with is trustworthy.</div></div></blockquote><div><br></div>I =
don't think it is up to this group to work on the semantics of the =
padlock frankly. Those are UI issues to be discussed by another group, =
browser vendors in particular.&nbsp;<br><br><blockquote type=3D"cite"><div=
 class=3D"gmail_quote"><div>Owning a DNS name does not make you a good =
person. </div></div></blockquote><div><br></div><div>Owning a multi =
billion dollar company that can afford a EV cert does not do that =
either. I think we have seen plenty of examples of that recently. =
Certification does not guarantee moral behavior, just identity. With DNS =
&amp; Dane it is domain-name identity. CA's can then add extra =
information and certify additional properties.</div><br><blockquote =
type=3D"cite"><div class=3D"gmail_quote"><div>So I can't see a =
justification for showing the padlock for any Domain Validated =
certificate.</div><div><br></div><div>The user is not going to check the =
status of the connection in any case, so why provide information that is =
only going to confuse the user and be =
misinterpreted?</div></div></blockquote><div><br></div><div>Again we =
should not discuss UI elements here, unless we want to get completely =
sidetracked.</div><div><br></div><div>You may not see the value of =
knowing you reached the site you clicked on, but I and many people =
do.</div><div>I would love to know when I reach those 10s of millions of =
sites that had self signed certs that they are the sites that I was =
intending to connect to. I would love to know that I reached the web =
page that the site I was on had linked to. I would put a padlock there, =
you may not. But the use case is there and it is the obvious thing one =
can use Dane for.</div><div><br></div><br><blockquote type=3D"cite"><div =
class=3D"gmail_quote">
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex;"><div =
style=3D"word-wrap:break-word"><div><div class=3D"im"><blockquote =
type=3D"cite"><div>There is a very low end security approach where all =
we want to do is to turn on encryption if possible and connect with =
plaintext otherwise. Alice is willing to accept the possibility of a man =
in the middle approach and is not going to verify the status of the =
connection.</div>
</blockquote><div><br></div></div><div>that is self signed certs now, =
running 3 times as many TLS end points as CA signed tls =
endpoints.</div></div></div></blockquote><div><br></div><div>How many of =
those are mail =
servers?&nbsp;</div></div></blockquote><div><br></div><div>You can go to =
the EFF observatory page, download the database of the observatory and =
answer all those</div><div>questions yourself. They explain how to do =
this here:</div><div><br></div><div>&nbsp;&nbsp;<a =
href=3D"http://www.youtube.com/watch?v=3DVUKCDm04AqI">http://www.youtube.c=
om/watch?v=3DVUKCDm04AqI</a></div><div><br></div><blockquote =
type=3D"cite"><div class=3D"gmail_quote">
<div><br></div><div>What is the desired fallback =
strategy?</div><div><br></div><div><br></div><div>Let us say that =
Alice's mail server is connecting to Bob's mail server to deliver mail =
and that Mallet is posing as a man in the middle and presents a non =
compliant cert. Note that neither user is present during the exchange =
and so we can't fallback to asking the user what to do. What is your =
preferred outcome:</div>
<div><br></div><div>1) Alice's mail server refuses to deliver mail to =
Bob's mail server?</div><div><br></div><div>2) Alice's mail server uses =
the bogus certificate and delivers the mail anyway?</div><div><br></div>
<div>3) Alice's mail server delivers the mail =
en-clair?</div></div></blockquote><div><br></div><div>My question is: =
how is it done now? &nbsp;In what percentage of case do people choose =
which option? Then you will find that in a very large percentage of =
cases security is not added at all because the simple solution of self =
signed certs is not available. Make that possible and easy and you =
increase the space in which secure behavior is =
possible.</div><div><br></div><div>With Dane you just increase the =
security of those servers that wish to be secure. You increase the scope =
of secure behavior. You make secure behavior cheaper, and so more widely =
used, which creates network effects.</div><br><blockquote =
type=3D"cite"><div class=3D"gmail_quote"><div>&nbsp;would guess that the =
preferred outcome is (1) but none of the outcomes are exactly good and =
the outcome that the programmers are likely to code is probably (3) =
which is the worst of the lot.</div>
<div><br></div><div>Under the existing DANE draft, Mallet can force =
outcome #3 by simply stripping out the STARTTLS request which is =
(inevitably) sent before we have =
authentication.</div><div><br></div><div>
There are in fact two downgrade attacks possible =
here:</div><div><br></div><div>1) Force the user to accept a bogus =
certificate</div><div><br></div><div>2) Force the user to accept the =
communication en-clair.</div><div><br>
</div><div>Attack #2 dominates attack =
#1.&nbsp;</div><div><br></div><div>I agree that we should address #1. =
But we achieve no security benefit unless we also address =
#2.&nbsp;</div></div></blockquote><div><br></div><div>Ok, I don't see =
why allowing Dane to publish self signed certs affects this at all? Does =
it not make things easier? In the HTTPS case it clearly =
does.</div><div><br></div><blockquote type=3D"cite"><div =
class=3D"gmail_quote"><div><br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex;">
<div style=3D"word-wrap:break-word"><div><div class=3D"im"><blockquote =
type=3D"cite"><div>The first case can be addressed without DNSSEC: Just =
use encryption and don't provide any security signal (e.g. padlock) in =
primary chrome.</div>
<div><br></div><div>The second case needs DNSSEC and more to add trust =
in.</div></blockquote><div><br></div></div>No, both those cases are =
improved by DANE and =
DNSsec.</div></div></blockquote><div><br></div><div>Not unless you also =
address the protocol downgrade attack.</div>
<div><br></div><div>If you allow the SSL stripping downgrade attack, =
preventing the use of a bogus cert is irrelevant for Internet services =
and of marginal utility for Web browsing =
transactions.</div><div><br></div><div>The user is going to ignore the =
padlock and click through any warning =
screen.</div></div></blockquote><div><br></div><div>There will be a lot =
less warning screens in his day to day experience, and so it will be =
possible to teach the user to take &nbsp;failures more seriously. =
Currently there are many cases where users are taught to click through =
the warning screen, by knowledgeable people. This can become a habit. =
Allowing self signed certs to be published in Dane will make it easy to =
tell people: why don't you just publish your self signed cert in DNS? If =
you can't even bother to do that, then why should I take your =
site/service seriously.</div><br><blockquote type=3D"cite"><div =
class=3D"gmail_quote"><div><font class=3D"Apple-style-span" =
color=3D"#000000"><br></font></div><div>The only case where I can see a =
value to using DNSSEC here is if we start by telling the client that TLS =
is always available at the genuine =
service.</div></div></blockquote><div><br></div><div>That is indeed the =
idea: make a web that is very much more widely TLS based. Increase the =
usage of TLS 100 fold or more. Make it the default. Why not? Google are =
doing it now, Facebook is. Soon everyone will. After all any web page =
with links to other sites that is not protected is a danger, because it =
could be man in the middled to rewrite URLs and point people to the =
wrong site.</div><br><blockquote type=3D"cite"><div =
class=3D"gmail_quote"><div>&nbsp;If there is a mechanism that allows the =
client to verify the use of TLS without user involvement, the padlock =
icon becomes =
unnecessary.</div></div></blockquote><div><br></div><div>Again that is a =
UI issue, which is exceedingly important, but not one we should concern =
ourselves here. Assume UI specialists, graphics artists, and people with =
a humanities background will do their job.</div><br><blockquote =
type=3D"cite"><div class=3D"gmail_quote">
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex;"><div =
style=3D"word-wrap:break-word"><div><div class=3D"im"><blockquote =
type=3D"cite"><div>While the precise definition of what 'strict =
security' turns out to be is something we can leave to =3DJeff and co in =
WebSec. I think we need to have a story for how we could present the =
'strict' indicator through the DNS along with the trust anchor/key =
restrictions.</div>

<div><br></div><div>We may not want to add such capability to the =
standard immediately, but we can have extensibility without impact on =
what people assert are the 'core' use cases. I don't see why we have to =
accept the idea that because some people are only interested in X we =
should deliberately design the spec so that it is only capable of doing =
X and can never, ever be extended to do anything else whatsoever.</div>
</blockquote><div><br></div></div><div>I don't think I ever claimed that =
supporting self signed certs should be the *only* requirement . Just =
that it is a very important use =
case.</div></div></div></blockquote><div><br>
</div><div>I don't think it is useful to get back into an argument of =
who said what or argued =
what.</div><div><br></div><div>&nbsp;</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex;">
<div style=3D"word-wrap:break-word"><div><div> &nbsp;Dane is Win/Win for =
all.</div></div></div></blockquote><div><br></div><div>Hopefully not. I =
would hope that a security protocol is a lose for =
Mallet.</div></div></blockquote><div><br></div><div>I seem to have hit a =
nerve.</div><div><br></div><div>Henry</div><br><blockquote =
type=3D"cite"><div class=3D"gmail_quote"><div><br></div><div>
<br></div></div>-- <br>Website: <a =
href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</blockquote></div><br><div>
<span class=3D"Apple-style-span" style=3D"font-size: 12px; "><div =
style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; "><span class=3D"Apple-style-span" =
style=3D"border-collapse: separate; color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant: normal; =
font-weight: normal; letter-spacing: normal; line-height: normal; =
orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; =
widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; "><div style=3D"word-wrap: =
break-word; -webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space; "><span class=3D"Apple-style-span" =
style=3D"border-collapse: separate; color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant: normal; =
font-weight: normal; letter-spacing: normal; line-height: normal; =
orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; =
widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; "><div style=3D"word-wrap: =
break-word; -webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space; "><span class=3D"Apple-style-span" =
style=3D"border-collapse: separate; -webkit-border-horizontal-spacing: =
0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; -webkit-text-decorations-in-effect: none; =
text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; =
orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><div =
style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; "><span class=3D"Apple-style-span" =
style=3D"border-collapse: separate; -webkit-border-horizontal-spacing: =
0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; -webkit-text-decorations-in-effect: none; =
text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; =
orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; =
-webkit-text-decorations-in-effect: none; text-indent: 0px; =
-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
white-space: normal; widows: 2; word-spacing: 0px; "><span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; =
-webkit-text-decorations-in-effect: none; text-indent: 0px; =
-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
white-space: normal; widows: 2; word-spacing: 0px; "><span><div>Social =
Web Architect<br><a =
href=3D"http://bblfish.net/">http://bblfish.net/</a></div></span></span></=
span></span></div></span></div></span></div></span></div></span>
</div>
<br></body></html>=

--Apple-Mail-60--564608836--

From [e-mail]  Tue Apr  5 07:19:24 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AC0328C155 for <[e-mail]>; Tue,  5 Apr 2011 07:19:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.149
X-Spam-Level: 
X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599, HELO_EQ_SE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xKHguZP9qdYL for <[e-mail]>; Tue,  5 Apr 2011 07:19:23 -0700 (PDT)
Received: from smtp6.webway.se (smtp2.webway.se [87.96.134.128]) by core3.amsl.com (Postfix) with ESMTP id 8A91728C14A for <[e-mail]>; Tue,  5 Apr 2011 07:19:22 -0700 (PDT)
Received: from [192.168.20.218] (static-213-115-251-100.sme.bredbandsbolaget.se [213.115.251.100]) by smtp6.webway.se (Postfix) with ESMTPA id 44B74552F58; Tue,  5 Apr 2011 14:21:04 +0000 (UTC)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: "Olle E. Johansson" <[e-mail]>
In-Reply-To: <BANLkTik=XV3Qu=LkAEgMhKdn9=[e-mail]>
Date: Tue, 5 Apr 2011 16:21:03 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <BANLkTimNauWFBSvsvzfx4TUcU=[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <BANLkTik=XV3Qu=LkAEgMhKdn9=[e-mail]>
To: Phillip Hallam-Baker <[e-mail]>
X-Mailer: Apple Mail (2.1084)
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document. - padlock
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2011 14:19:24 -0000

5 apr 2011 kl. 15.17 skrev Phillip Hallam-Baker:

>=20
>  - so self signed certs, move from just being useful for guaranteeing =
communication to also guaranteeing identity (they move from no padlock =
to padlock)
>=20
> I don't think that is justified. We should eliminate the padlock =
entirely for all classes of certificate.=20
>=20
> The user interprets the padlock icon as proof that they are safe, that =
the party they are dealing with is trustworthy.
>=20

The padlock symbol may be out of scope for Dane. It may work for HTTP, =
but not for SIP. The TLS part is only one small part of the concept of a =
"secure call". The SIP group need to standardize the meaning of padlock =
for VoIP and IM - does it mean both secure media, identity and =
signalling or is encrypted signalling enough?

/O=

From [e-mail]  Tue Apr  5 07:20:40 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96DBD28C150 for <[e-mail]>; Tue,  5 Apr 2011 07:20:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.135
X-Spam-Level: 
X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[AWL=0.114,  BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id seM0LfDxf5Tp for <[e-mail]>; Tue,  5 Apr 2011 07:20:30 -0700 (PDT)
Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id 6BA9428C14A for <[e-mail]>; Tue,  5 Apr 2011 07:20:30 -0700 (PDT)
Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1Q7791-0006Eo-W7; Tue, 05 Apr 2011 14:22:11 +0000
Received: by bfk.de with local id 1Q7791-00020q-Sn; Tue, 05 Apr 2011 14:22:11 +0000
To: Matt McCutchen <[e-mail]>
References: <[e-mail]> <[e-mail]> <1302012455.3356.7.camel@localhost>
From: Florian Weimer <[e-mail]>
Date: Tue, 05 Apr 2011 14:22:11 +0000
In-Reply-To: <1302012455.3356.7.camel@localhost> (Matt McCutchen's message of "Tue\, 05 Apr 2011 10\:07\:35 -0400")
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: [e-mail]
Subject: Re: [dane] Objective: Restrictive versus Supplementary Models
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2011 14:20:40 -0000

* Matt McCutchen:

> On Tue, 2011-04-05 at 11:13 +0000, Florian Weimer wrote:
>> If you switch HTTPS transparently (meaning: no UI indicators, secure
>> cookies are not sent, SOP checks run against :80 instead of :443),
>> then you don't need DNSSEC.
>
> Indeed, this could be done, but I want server-authenticated connections.

Then you'll need DNSSEC.  But even without successful DNSSEC
validation, you would get an encrypted connection which is only
vulnerable to active attacks, at modest cost (no UI definition hassle,
no CAs to deal with).  With DNSSEC, it would be very much like HTTPS
today in terms of security properties, except that there is no
perceptible security indicator.  You'd still need to get a certificate
from a browser-approved CA before clients will see the padlock.

--=20
Florian Weimer                <[e-mail]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstra=DFe 100              tel: [phone]
D-76133 Karlsruhe             fax: [phone]

From [e-mail]  Tue Apr  5 07:23:07 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05B2F28C156 for <[e-mail]>; Tue,  5 Apr 2011 07:23:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.476
X-Spam-Level: 
X-Spam-Status: No, score=-102.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hICwc9zWVbl6 for <[e-mail]>; Tue,  5 Apr 2011 07:23:06 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 1C26D28C14A for <[e-mail]>; Tue,  5 Apr 2011 07:23:06 -0700 (PDT)
Received: from ros-dhcp192-1-51-86.bbn.com ([192.1.51.86]:57712) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from <[e-mail]>) id 1Q77BY-000OHn-4o; Tue, 05 Apr 2011 10:24:48 -0400
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: "Richard L. Barnes" <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Tue, 5 Apr 2011 10:24:44 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <BANLkTimNauWFBSvsvzfx4TUcU=[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <BANLkTik=XV3Qu=LkAEgMhKdn9=[e-mail]> <[e-mail]>
To: "Olle E. Johansson" <[e-mail]>
X-Mailer: Apple Mail (2.1082)
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document. - padlock
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2011 14:23:07 -0000

The padlock symbol is out of scope for the IETF in general.  It's a UI =
issue.  Let's move on, please.
--Richard

On Apr 5, 2011, at 10:21 AM, Olle E. Johansson wrote:

>=20
> 5 apr 2011 kl. 15.17 skrev Phillip Hallam-Baker:
>=20
>>=20
>> - so self signed certs, move from just being useful for guaranteeing =
communication to also guaranteeing identity (they move from no padlock =
to padlock)
>>=20
>> I don't think that is justified. We should eliminate the padlock =
entirely for all classes of certificate.=20
>>=20
>> The user interprets the padlock icon as proof that they are safe, =
that the party they are dealing with is trustworthy.
>>=20
>=20
> The padlock symbol may be out of scope for Dane. It may work for HTTP, =
but not for SIP. The TLS part is only one small part of the concept of a =
"secure call". The SIP group need to standardize the meaning of padlock =
for VoIP and IM - does it mean both secure media, identity and =
signalling or is encrypted signalling enough?
>=20
> /O
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane


From [e-mail]  Tue Apr  5 07:25:27 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BDB328C159 for <[e-mail]>; Tue,  5 Apr 2011 07:25:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.223
X-Spam-Level: 
X-Spam-Status: No, score=-10.223 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a67Bs8tJcArY for <[e-mail]>; Tue,  5 Apr 2011 07:25:26 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 3FA6C28C158 for <[e-mail]>; Tue,  5 Apr 2011 07:25:26 -0700 (PDT)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p35ER6ji007006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 Apr 2011 16:27:06 +0200 (MEST)
From: Martin Rex <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail] (Phillip Hallam-Baker)
Date: Tue, 5 Apr 2011 16:27:06 +0200 (MEST)
In-Reply-To: <BANLkTimNauWFBSvsvzfx4TUcU=[e-mail]> from "Phillip Hallam-Baker" at Apr 5, 11 01:32:59 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: [e-mail]
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2011 14:25:27 -0000

Phillip Hallam-Baker wrote:
> 
> What was asked for were use cases:
> 
> [U-WS-OPP] Alice finds Sally's server through a search engine. Alice prefers
> to protect her communications with cryptography if this is supported by the
> sever but will communicate in plaintext otherwise.

But this particular scenario is a completely lost cause anyway.

You do not need the TLS X.509 PKI in Browsers and neither DANE
to obtain an encrypted channel--and identification of the server
endpoint address is impossible, because you do not have a trusted
source for the reference identifier to start with.

This is a classical "good faith" use case, and a "leap-of-faith" on
initial encounter would be perfectly sufficient (if the browsers
had not been turned into commercial CA nagware).


-Martin

From [e-mail]  Tue Apr  5 07:40:44 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46A0328C120 for <[e-mail]>; Tue,  5 Apr 2011 07:40:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.881
X-Spam-Level: 
X-Spam-Status: No, score=-2.881 tagged_above=-999 required=5 tests=[AWL=-0.598, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4wpc46ftgAu for <[e-mail]>; Tue,  5 Apr 2011 07:40:36 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 325043A6803 for <[e-mail]>; Tue,  5 Apr 2011 07:40:36 -0700 (PDT)
Received: by vxg33 with SMTP id 33so404971vxg.31 for <[e-mail]>; Tue, 05 Apr 2011 07:42:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=YcD5UlxP+FDAULKkr6f0NIiNXZZlJ3Nkb892DXpD5c4=; b=omSRX19IVX2W8/W6xQX7A+BitZErkIDLQbJxwBcl93GZWgFFefepsNbwbayyayvHXE e3/wbjoFd3oMRsywVSOn7I99AUamCNsYXrZ2fwHwC2mM0SggXorA/m9YQtYicIyYxFY1 k0f1E6w/iAdTq2HUc/3yKEGguRlMF3/mHiIf8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=q8fbkcQiwusAxEhHQWoFXVvv235YzkQWVYWL9iJ2VGoCwdKvS4dpynlM1r0km6bA9b H1UyLWI/Br76WuQ0Afo0El+28fjroJlIlOmQk0IfD9Q6keBZfT8kljO1+mpGELeKjY9D cYcIwOv/zxIDyMfGNXFBU4cpWaU7iMCN7I7/0=
MIME-Version: 1.0
Received: by 10.52.67.103 with SMTP id m7mr3687252vdt.178.1302014539211; Tue, 05 Apr 2011 07:42:19 -0700 (PDT)
Received: by 10.52.161.42 with HTTP; Tue, 5 Apr 2011 07:42:19 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <BANLkTimNauWFBSvsvzfx4TUcU=[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <BANLkTik=XV3Qu=LkAEgMhKdn9=[e-mail]> <[e-mail]>
Date: Tue, 5 Apr 2011 10:42:19 -0400
Message-ID: <[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: Henry Story <[e-mail]>
Content-Type: multipart/alternative; boundary=20cf307abea71a23d004a02ce208
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2011 14:40:44 -0000

--20cf307abea71a23d004a02ce208
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Apr 5, 2011 at 10:10 AM, Henry Story <[e-mail]>wrote:

>
> On 5 Apr 2011, at 15:17, Phillip Hallam-Baker wrote:
>
>
>>  - so self signed certs, move from just being useful for guaranteeing
>> communication to also guaranteeing identity (they move from no padlock to
>> padlock)
>>
>
> I don't think that is justified. We should eliminate the padlock entirely
> for all classes of certificate.
>
> The user interprets the padlock icon as proof that they are safe, that the
> party they are dealing with is trustworthy.
>
>
> I don't think it is up to this group to work on the semantics of the
> padlock frankly. Those are UI issues to be discussed by another group,
> browser vendors in particular.
>

You just suggested that DNSSEC validation alone should be a qualification
for display of the padlock icon.


Owning a DNS name does not make you a good person.
>
>
> Owning a multi billion dollar company that can afford a EV cert does not do
> that either. I think we have seen plenty of examples of that recently.
> Certification does not guarantee moral behavior, just identity. With DNS &
> Dane it is domain-name identity. CA's can then add extra information and
> certify additional properties.
>

But having been vetted through EV does at least establish a reasonable
probability that they are accountable in law and it is rather likely that
the user already has an idea of the extent to which that is useful.

If someone has an EV cert telling me that they are incorporated in Lagos,
Nigeria that extent may not be very high. If the company is incorporated in
Germany or the UK I have rather more confidence.



> So I can't see a justification for showing the padlock for any Domain
> Validated certificate.
>
> The user is not going to check the status of the connection in any case, so
> why provide information that is only going to confuse the user and be
> misinterpreted?
>
>
> Again we should not discuss UI elements here, unless we want to get
> completely sidetracked.
>

No, if people want to propose a scheme that is predicated on the display of
a padlock icon, then the intended semantics of the padlock icon have to be
up for discussion.

There is actually a pretty clear W3C document on the topic after all.



> You may not see the value of knowing you reached the site you clicked on,
> but I and many people do.
> I would love to know when I reach those 10s of millions of sites that had
> self signed certs that they are the sites that I was intending to connect
> to. I would love to know that I reached the web page that the site I was on
> had linked to. I would put a padlock there, you may not. But the use case is
> there and it is the obvious thing one can use Dane for.
>

And again you come back to proposing to display the padlock one paragraph
after claiming that it is out of scope.

If you want DANE information to be capable of leading to a padlock display
then you are going to have to agree to discuss the semantics of the padlock
and argue that DANE information is sufficient to meet the requirements for
display of the padlock.

I don't need to argue the precise semantics of the padlock because I want to
provide a mechanism that allows it to be eliminated completely.
 Let us say that Alice's mail server is connecting to Bob's mail server to
deliver mail and that Mallet is posing as a man in the middle and presents a
non compliant cert. Note that neither user is present during the exchange
and so we can't fallback to asking the user what to do. What is your
preferred outcome:

>
> 1) Alice's mail server refuses to deliver mail to Bob's mail server?
>
> 2) Alice's mail server uses the bogus certificate and delivers the mail
> anyway?
>
> 3) Alice's mail server delivers the mail en-clair?
>
>
> My question is: how is it done now?  In what percentage of case do people
> choose which option?
>

0%

The option is chosen by the machines, not by the user. That is the point I
am trying to get to here. The padlock icon is only used in a minority of TLS
transactions and it is not very useful even in that case.


> With Dane you just increase the security of those servers that wish to be
> secure. You increase the scope of secure behavior. You make secure behavior
> cheaper, and so more widely used, which creates network effects.
>

Not necessarily.

People are only going to change their behavior if the value proposition for
change crosses some threshold value. Addressing only one attack (downgrade
attack on the certificate) without addressing an attack that dominates it
(downgrade attack on the use of channel security) does not cross that
threshold in my view.


I agree that we should address #1. But we achieve no security benefit unless
> we also address #2.
>
>
> Ok, I don't see why allowing Dane to publish self signed certs affects this
> at all? Does it not make things easier? In the HTTPS case it clearly does.
>

Nobody is arguing against publishing self-signed certs.

I am arguing that
1) We should allow publication of self signed certs to improve security.
2) Security is only in fact improved if it is known that TLS is offered.
3) It is necessary to support both in order to address the use case.

People are using self-signed certs for SMTP with STARTTLS perfectly well
today. What means of attack does DANE provide a control for? Is there any
attacker that is going to be thwarted?


> There will be a lot less warning screens in his day to day experience, and
> so it will be possible to teach the user to take  failures more seriously.
> Currently there are many cases where users are taught to click through the
> warning screen, by knowledgeable people. This can become a habit. Allowing
> self signed certs to be published in Dane will make it easy to tell people:
> why don't you just publish your self signed cert in DNS? If you can't even
> bother to do that, then why should I take your site/service seriously.
>

Again you step into UI while claiming it is out of scope. The UI
implications have to be in scope or the process is nonsense.

Your use case can be handled equally well by simply not showing the padlock
icon for self-signed certs and not raising any UI errors.

>
> The only case where I can see a value to using DNSSEC here is if we start
> by telling the client that TLS is always available at the genuine service.
>
>
> That is indeed the idea: make a web that is very much more widely TLS
> based. Increase the usage of TLS 100 fold or more. Make it the default. Why
> not? Google are doing it now, Facebook is. Soon everyone will. After all any
> web page with links to other sites that is not protected is a danger,
> because it could be man in the middled to rewrite URLs and point people to
> the wrong site.
>

Google can decide that they will always offer SSL. But if I enter
www.google.com into Google's own Chrome browser it will default to http
without TLS.

I agree with the use case you present here. But that use case leads to a
requirement for notifying the client that TLS is always offered so that it
can effect the upgrade.

>  If there is a mechanism that allows the client to verify the use of TLS
> without user involvement, the padlock icon becomes unnecessary.
>
> Again that is a UI issue, which is exceedingly important, but not one we
> should concern ourselves here. Assume UI specialists, graphics artists, and
> people with a humanities background will do their job.
>

I was part of the W3C working group that did just that.

You are the person who is proposing a protocol that depends on the effective
display of a security signal. So you are the person who bears the burden of
seeking out those experts and soliciting their opinions.

You cannot assume that the usability people will do their job because they
are not SECURITY usability people and their interest is to make the
application appear to be simple.


>   Dane is Win/Win for all.
>>
>
> Hopefully not. I would hope that a security protocol is a lose for Mallet.
>
>
> I seem to have hit a nerve.
>

No, and the idea that you have is your fundamental problem here. My
objective here is to make DANE into a protocol that is actually useful in
practice by providing an effective control against real world attacks
without relying on user interface signals that I know are not going to be
prominent enough to have utility.


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

--20cf307abea71a23d004a02ce208
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Tue, Apr 5, 2011 at 10:10 AM, Henry S=
tory <span dir=3D"ltr">&lt;<a href=3D"mailto:[e-mail]">henry=
[e-mail]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"=
>
<div style=3D"word-wrap:break-word"><br><div><div class=3D"im"><div>On 5 Ap=
r 2011, at 15:17, Phillip Hallam-Baker wrote:</div><blockquote type=3D"cite=
"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style=3D"word-wrap:break-word"><div><div><br></div><div>=A0- so self s=
igned certs, move from just being useful for guaranteeing communication to =
also guaranteeing identity (they move from no padlock to padlock)</div>
</div></div></blockquote><div><br></div><div>I don&#39;t think that is just=
ified. We should eliminate the padlock entirely for all classes of certific=
ate.=A0</div><div><br></div><div>The user interprets the padlock icon as pr=
oof that they are safe, that the party they are dealing with is trustworthy=
.</div>
</div></blockquote><div><br></div></div>I don&#39;t think it is up to this =
group to work on the semantics of the padlock frankly. Those are UI issues =
to be discussed by another group, browser vendors in particular.=A0</div>
</div></blockquote><div><br></div><div>You just suggested that DNSSEC valid=
ation alone should be a qualification for display of the padlock icon.</div=
><div><br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style=3D"word-wrap:break-word"><div><div class=3D"im"><blockquote type=
=3D"cite"><div class=3D"gmail_quote"><div>Owning a DNS name does not make y=
ou a good person. </div></div></blockquote><div><br></div></div><div>Owning=
 a multi billion dollar company that can afford a EV cert does not do that =
either. I think we have seen plenty of examples of that recently. Certifica=
tion does not guarantee moral behavior, just identity. With DNS &amp; Dane =
it is domain-name identity. CA&#39;s can then add extra information and cer=
tify additional properties.</div>
</div></div></blockquote><div><br></div><div>But having been vetted through=
 EV does at least establish a reasonable probability that they are accounta=
ble in law and it is rather likely that the user already has an idea of the=
 extent to which that is useful.</div>
<div><br></div><div>If someone has an EV cert telling me that they are inco=
rporated in Lagos, Nigeria that extent may not be very high. If the company=
 is incorporated in Germany or the UK I have rather more confidence.</div>
<div><br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style=3D"=
word-wrap:break-word"><div><div class=3D"im"><blockquote type=3D"cite"><div=
 class=3D"gmail_quote">
<div>So I can&#39;t see a justification for showing the padlock for any Dom=
ain Validated certificate.</div><div><br></div><div>The user is not going t=
o check the status of the connection in any case, so why provide informatio=
n that is only going to confuse the user and be misinterpreted?</div>
</div></blockquote><div><br></div></div><div>Again we should not discuss UI=
 elements here, unless we want to get completely sidetracked.</div></div></=
div></blockquote><div><br></div><div>No, if people want to propose a scheme=
 that is predicated on the display of a padlock icon, then the intended sem=
antics of the padlock icon have to be up for discussion.</div>
<div><br></div><div>There is actually a pretty clear W3C document on the to=
pic after all.</div><div><br></div><div>=A0</div><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex;">
<div style=3D"word-wrap:break-word"><div><div>You may not see the value of =
knowing you reached the site you clicked on, but I and many people do.</div=
><div>I would love to know when I reach those 10s of millions of sites that=
 had self signed certs that they are the sites that I was intending to conn=
ect to. I would love to know that I reached the web page that the site I wa=
s on had linked to. I would put a padlock there, you may not. But the use c=
ase is there and it is the obvious thing one can use Dane for.</div>
</div></div></blockquote><div><br></div><div>And again you come back to pro=
posing to display the padlock one paragraph after claiming that it is out o=
f scope.</div><div><br></div><div>If you want DANE information to be capabl=
e of leading to a padlock display then you are going to have to agree to di=
scuss the semantics of the padlock and argue that DANE information is suffi=
cient to meet the requirements for display of the padlock.</div>
<div><br></div><div>I don&#39;t need to argue the precise semantics of the =
padlock because I want to provide a mechanism that allows it to be eliminat=
ed completely.</div><div>=A0Let us say that Alice&#39;s mail server is conn=
ecting to Bob&#39;s mail server to deliver mail and that Mallet is posing a=
s a man in the middle and presents a non compliant cert. Note that neither =
user is present during the exchange and so we can&#39;t fallback to asking =
the user what to do. What is your preferred outcome:</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;"><div style=3D"word-wrap:break-word"><div><d=
iv class=3D"im"><blockquote type=3D"cite"><div class=3D"gmail_quote">
<div><br></div><div>1) Alice&#39;s mail server refuses to deliver mail to B=
ob&#39;s mail server?</div><div><br></div><div>2) Alice&#39;s mail server u=
ses the bogus certificate and delivers the mail anyway?</div><div><br>
</div>
<div>3) Alice&#39;s mail server delivers the mail en-clair?</div></div></bl=
ockquote><div><br></div></div><div>My question is: how is it done now? =A0I=
n what percentage of case do people choose which option? </div></div></div>
</blockquote><div><br></div><div>0%</div><div><br></div><div>The option is =
chosen by the machines, not by the user. That is the point I am trying to g=
et to here. The padlock icon is only used in a minority of TLS transactions=
 and it is not very useful even in that case.</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex;"><div style=3D"word-wrap:break=
-word"><div><div>With Dane you just increase the security of those servers =
that wish to be secure. You increase the scope of secure behavior. You make=
 secure behavior cheaper, and so more widely used, which creates network ef=
fects.</div>
</div></div></blockquote><div><br></div><div>Not necessarily.=A0</div><div>=
<br></div><div>People are only going to change their behavior if the value =
proposition for change crosses some threshold value. Addressing only one at=
tack (downgrade attack on the certificate) without addressing an attack tha=
t dominates it (downgrade attack on the use of channel security) does not c=
ross that threshold in my view.</div>
<div><br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style=3D=
"word-wrap:break-word"><div><div class=3D"im"><blockquote type=3D"cite"><di=
v class=3D"gmail_quote">
<div>I agree that we should address #1. But we achieve no security benefit =
unless we also address #2.=A0</div></div></blockquote><div><br></div></div>=
<div>Ok, I don&#39;t see why allowing Dane to publish self signed certs aff=
ects this at all? Does it not make things easier? In the HTTPS case it clea=
rly does.</div>
</div></div></blockquote><div><br></div><div>Nobody is arguing against publ=
ishing self-signed certs.</div><div><br></div><div>I am arguing that=A0</di=
v><div>1) We should allow publication of self signed certs to improve secur=
ity.</div>
<div>2) Security is only in fact improved if it is known that TLS is offere=
d.=A0</div><div>3) It is necessary to support both in order to address the =
use case.</div><div><br></div><div>People are using self-signed certs for S=
MTP with STARTTLS perfectly well today. What means of attack does DANE prov=
ide a control for? Is there any attacker that is going to be thwarted?</div=
>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex;"><div style=3D"word-wrap:break=
-word"><div><div>There will be a lot less warning screens in his day to day=
 experience, and so it will be possible to teach the user to take =A0failur=
es more seriously. Currently there are many cases where users are taught to=
 click through the warning screen, by knowledgeable people. This can become=
 a habit. Allowing self signed certs to be published in Dane will make it e=
asy to tell people: why don&#39;t you just publish your self signed cert in=
 DNS? If you can&#39;t even bother to do that, then why should I take your =
site/service seriously.</div>
</div></div></blockquote><div><br></div><div>Again you step into UI while c=
laiming it is out of scope. The UI implications have to be in scope or the =
process is nonsense.</div><div><br></div><div>Your use case can be handled =
equally well by simply not showing the padlock icon for self-signed certs a=
nd not raising any UI errors.=A0</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;"><div style=3D"word-wrap:break-word"><div><d=
iv class=3D"im"><blockquote type=3D"cite"><div class=3D"gmail_quote"><div><=
font color=3D"#000000"><br>
</font></div><div>The only case where I can see a value to using DNSSEC her=
e is if we start by telling the client that TLS is always available at the =
genuine service.</div></div></blockquote><div><br></div></div><div>That is =
indeed the idea: make a web that is very much more widely TLS based. Increa=
se the usage of TLS 100 fold or more. Make it the default. Why not? Google =
are doing it now, Facebook is. Soon everyone will. After all any web page w=
ith links to other sites that is not protected is a danger, because it coul=
d be man in the middled to rewrite URLs and point people to the wrong site.=
</div>
</div></div></blockquote><div><br></div><div>Google can decide that they wi=
ll always offer SSL. But if I enter <a href=3D"http://www.google.com">www.g=
oogle.com</a> into Google&#39;s own Chrome browser it will default to http =
without TLS.</div>
<div><br></div><div>I agree with the use case you present here. But that us=
e case leads to a requirement for notifying the client that TLS is always o=
ffered so that it can effect the upgrade.</div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x;">
<div style=3D"word-wrap:break-word"><div><div class=3D"im"><blockquote type=
=3D"cite"><div class=3D"gmail_quote"><div>=A0If there is a mechanism that a=
llows the client to verify the use of TLS without user involvement, the pad=
lock icon becomes unnecessary.</div>
</div></blockquote></div><div>Again that is a UI issue, which is exceedingl=
y important, but not one we should concern ourselves here. Assume UI specia=
lists, graphics artists, and people with a humanities background will do th=
eir job.</div>
</div></div></blockquote><div><br></div><div>I was part of the W3C working =
group that did just that.</div><div><br></div><div>You are the person who i=
s proposing a protocol that depends on the effective display of a security =
signal. So you are the person who bears the burden of seeking out those exp=
erts and soliciting their opinions.</div>
<div><br></div><div>You cannot assume that the usability people will do the=
ir job because they are not SECURITY usability people and their interest is=
 to make the application appear to be simple.</div><div>=A0=A0</div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex;">
<div style=3D"word-wrap:break-word"><div><div class=3D"im"><blockquote type=
=3D"cite"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style=3D"word-wrap:break-word"><div><div> =A0Dane is Win/Win for all.<=
/div></div></div></blockquote><div><br></div><div>Hopefully not. I would ho=
pe that a security protocol is a lose for Mallet.</div></div></blockquote>
<div><br></div></div><div>I seem to have hit a nerve.</div></div></div></bl=
ockquote><div><br></div><div>No, and the idea that you have is your fundame=
ntal problem here. My objective here is to make DANE into a protocol that i=
s actually useful in practice by providing an effective control against rea=
l world attacks without relying on user interface signals that I know are n=
ot going to be prominent enough to have utility.</div>
<div><br></div><div>=A0</div></div>-- <br>Website: <a href=3D"http://hallam=
baker.com/">http://hallambaker.com/</a><br><br>

--20cf307abea71a23d004a02ce208--

From [e-mail]  Tue Apr  5 08:09:21 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52A463A6947 for <[e-mail]>; Tue,  5 Apr 2011 08:09:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.066
X-Spam-Level: 
X-Spam-Status: No, score=-10.066 tagged_above=-999 required=5 tests=[AWL=-0.132, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vyvu4Fi+DnW3 for <[e-mail]>; Tue,  5 Apr 2011 08:09:20 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 5D0ED3A680D for <[e-mail]>; Tue,  5 Apr 2011 08:09:20 -0700 (PDT)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p35FB0ee021122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 Apr 2011 17:11:00 +0200 (MEST)
From: Martin Rex <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail] (Phillip Hallam-Baker)
Date: Tue, 5 Apr 2011 17:10:59 +0200 (MEST)
In-Reply-To: <[e-mail]> from "Phillip Hallam-Baker" at Apr 5, 11 03:32:32 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Objective: Restrictive versus Supplementary
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: [e-mail]
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2011 15:09:21 -0000

Phillip Hallam-Baker wrote:
> 
> The trend is certainly to deprecate providing a security signal to indicate
> use of DV certs. The only reason it is done today is that this is the legacy
> approach and the current protocols require the user to check that TLS is in
> use.
> 
> So I really can't see how an argument of the form 'DNSSEC validation is just
> as good as DV, therefore it should get a padlock icon' is going to get
> traction with the browser providers.

It depends on whether the Browser vendors&developers see their products as
simple nagware to promote TLS server certificates from commercial CAs,
or as applications to address the needs of their customers/users.


> 
> The question they are going to ask is 'what level of security notification
> is justified and/or necessary'.
> 
> Anyone care to argue that mere possession of a DNS domain makes you
> trustworthy?

That is the implied premise of doing server endpoint identification
based on DNS hostnames (rfc2818, rfc6125) and as it is implemented
and has been used in web browsers and other TLS clients since the
invention of SSL.   It's nowhere close to a real authentication based
on reference identifiers that are actually aligned with human intent,
or a secure re-authentication on successive encounters.

It appears that the majority of folks everywhere (not just in the IETF)
deems this to be "good enough".  But then, there is this huge SSLiverse
of 600+ omnipotent CAs and an unknown number of RAs, and a breach of
any single one of them can be used to subvert the TLS protection for
millions of users worldwide.  So in a way, doing server endpoint
identification based on DNS hostnames and using the TLS X.509 PKI
appears to be equivalent-strength (lack of) security, i.e. well balanced.


-Martin

From [e-mail]  Tue Apr  5 08:10:36 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2DFF3A680A for <[e-mail]>; Tue,  5 Apr 2011 08:10:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.532
X-Spam-Level: 
X-Spam-Status: No, score=-3.532 tagged_above=-999 required=5 tests=[AWL=0.066,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mstx3nvAukm8 for <[e-mail]>; Tue,  5 Apr 2011 08:10:29 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 6D0043A67F5 for <[e-mail]>; Tue,  5 Apr 2011 08:10:29 -0700 (PDT)
Received: by vws12 with SMTP id 12so434495vws.31 for <[e-mail]>; Tue, 05 Apr 2011 08:12:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4CD7je3H1hXHBTY6fdLZaj1smDjW7Ts6qvUokUzJbmI=; b=SD89x+xOXAdLcaw7WbibozX6ex6l95sQDOER8zPG60D5tlULrrymImzeF7xHlbmsDN mosyG8ra2gI0KUepi13QQxfoVxImv+fI9SZffy54zY3IKbP84FEIoS5/6FQmK9jnz5KF 4+hVKWASU5NO9N8uNEIefnOruHMQwCBX5YgqY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=kf2HgrVVn+boRR7LDdfAwzsXx5d2lJ/J6AqeQjE/tYdvLqudtZihE1qjIsxNh7Zcmm uPEYWYRXlwplvybpYffgy365CYxwUNsDjbARjsjzCRii0P0LXcfzn0fQNvi1samDa1EW NshxLTHqrb44tN8ofbBtv0DEsD2SLV3wkDpow=
MIME-Version: 1.0
Received: by 10.52.100.39 with SMTP id ev7mr1810210vdb.218.1302016332537; Tue, 05 Apr 2011 08:12:12 -0700 (PDT)
Received: by 10.52.161.42 with HTTP; Tue, 5 Apr 2011 08:12:12 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <BANLkTimNauWFBSvsvzfx4TUcU=[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <BANLkTik=XV3Qu=LkAEgMhKdn9=[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 5 Apr 2011 11:12:12 -0400
Message-ID: <BANLkTi=[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: "Richard L. Barnes" <[e-mail]>
Content-Type: multipart/alternative; boundary=bcaec50163b9fe1e4c04a02d4c03
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document. - padlock
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2011 15:10:36 -0000

--bcaec50163b9fe1e4c04a02d4c03
Content-Type: text/plain; charset=ISO-8859-1

The manner in which the padlock icon is displayed is out of scope.

But declaring an issue out of scope does not mean that it can then be used
as pixie dust.

I am calling out the padlock icon proposal from Henry and others as it is
relying on pixie dust that (1) they admit they do not understand and (2) is
only available in a special case and (3) probably not then.


There is no padlock icon in SIP, SMTP, Web Services or any other Internet
Service that does not have a primary user interface. If we are going to
propose a useful protocol it cannot rely on pixie dust.



On Tue, Apr 5, 2011 at 10:24 AM, Richard L. Barnes <[e-mail]> wrote:

> The padlock symbol is out of scope for the IETF in general.  It's a UI
> issue.  Let's move on, please.
> --Richard
>
> On Apr 5, 2011, at 10:21 AM, Olle E. Johansson wrote:
>
> >
> > 5 apr 2011 kl. 15.17 skrev Phillip Hallam-Baker:
> >
> >>
> >> - so self signed certs, move from just being useful for guaranteeing
> communication to also guaranteeing identity (they move from no padlock to
> padlock)
> >>
> >> I don't think that is justified. We should eliminate the padlock
> entirely for all classes of certificate.
> >>
> >> The user interprets the padlock icon as proof that they are safe, that
> the party they are dealing with is trustworthy.
> >>
> >
> > The padlock symbol may be out of scope for Dane. It may work for HTTP,
> but not for SIP. The TLS part is only one small part of the concept of a
> "secure call". The SIP group need to standardize the meaning of padlock for
> VoIP and IM - does it mean both secure media, identity and signalling or is
> encrypted signalling enough?
> >
> > /O
> > _______________________________________________
> > dane mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dane
>
>


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

--bcaec50163b9fe1e4c04a02d4c03
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

The manner in which the padlock icon is displayed is out of scope.<div><br>=
</div><div>But declaring an issue out of scope does not mean that it can th=
en be used as pixie dust.</div><div><br></div><div>I am calling out the pad=
lock icon proposal from Henry and others as it is relying on pixie dust tha=
t (1) they admit they do not understand and (2) is only available in a spec=
ial case and (3) probably not then.</div>
<div><br></div><div><br></div><div>There is no padlock icon in SIP, SMTP, W=
eb Services or any other Internet Service that does not have a primary user=
 interface. If we are going to propose a useful protocol it cannot rely on =
pixie dust.</div>
<div><br></div><div><br></div><div><br><div class=3D"gmail_quote">On Tue, A=
pr 5, 2011 at 10:24 AM, Richard L. Barnes <span dir=3D"ltr">&lt;<a href=3D"=
mailto:[e-mail]">[e-mail]</a>&gt;</span> wrote:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex;">
The padlock symbol is out of scope for the IETF in general. =A0It&#39;s a U=
I issue. =A0Let&#39;s move on, please.<br>
--Richard<br>
<div><div></div><div class=3D"h5"><br>
On Apr 5, 2011, at 10:21 AM, Olle E. Johansson wrote:<br>
<br>
&gt;<br>
&gt; 5 apr 2011 kl. 15.17 skrev Phillip Hallam-Baker:<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; - so self signed certs, move from just being useful for guaranteei=
ng communication to also guaranteeing identity (they move from no padlock t=
o padlock)<br>
&gt;&gt;<br>
&gt;&gt; I don&#39;t think that is justified. We should eliminate the padlo=
ck entirely for all classes of certificate.<br>
&gt;&gt;<br>
&gt;&gt; The user interprets the padlock icon as proof that they are safe, =
that the party they are dealing with is trustworthy.<br>
&gt;&gt;<br>
&gt;<br>
&gt; The padlock symbol may be out of scope for Dane. It may work for HTTP,=
 but not for SIP. The TLS part is only one small part of the concept of a &=
quot;secure call&quot;. The SIP group need to standardize the meaning of pa=
dlock for VoIP and IM - does it mean both secure media, identity and signal=
ling or is encrypted signalling enough?<br>

&gt;<br>
&gt; /O<br>
</div></div>&gt; _______________________________________________<br>
&gt; dane mailing list<br>
&gt; <a href=3D"mailto:[e-mail]">[e-mail]</a><br>
&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_blan=
k">https://www.ietf.org/mailman/listinfo/dane</a><br>
<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a href=3D"htt=
p://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--bcaec50163b9fe1e4c04a02d4c03--

From [e-mail]  Tue Apr  5 08:20:07 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1E9928C0EC for <[e-mail]>; Tue,  5 Apr 2011 08:20:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.359
X-Spam-Level: 
X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[AWL=0.239,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTcEXsoohOOV for <[e-mail]>; Tue,  5 Apr 2011 08:20:06 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 1B8DE3A693F for <[e-mail]>; Tue,  5 Apr 2011 08:20:05 -0700 (PDT)
Received: by wwa36 with SMTP id 36so410108wwa.13 for <[e-mail]>; Tue, 05 Apr 2011 08:21:48 -0700 (PDT)
Received: by 10.227.53.206 with SMTP id n14mr8330389wbg.14.1302016908771; Tue, 05 Apr 2011 08:21:48 -0700 (PDT)
Received: from bblfish.home (ALagny-751-1-3-136.w86-218.abo.wanadoo.fr [86.218.42.136]) by mx.google.com with ESMTPS id e13sm3630795wbi.40.2011.04.05.08.21.47 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Apr 2011 08:21:47 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: multipart/alternative; boundary=Apple-Mail-61--560325366
From: Henry Story <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Tue, 5 Apr 2011 17:21:45 +0200
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <BANLkTimNauWFBSvsvzfx4TUcU=[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <BANLkTik=XV3Qu=LkAEgMhKdn9=[e-mail]> <[e-mail]> <[e-mail]>
To: Phillip Hallam-Baker <[e-mail]>
X-Mailer: Apple Mail (2.1082)
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2011 15:20:07 -0000

--Apple-Mail-61--560325366
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On 5 Apr 2011, at 16:42, Phillip Hallam-Baker wrote:

> I don't think it is useful to get back into an argument of who said =
what or argued what.

You then go into arguments claiming I was talking of something first and =
using it as part of an argument, and so on, when it was just meant to be =
illustrative. Anyway, since everyone on this lists agrees that UI design =
is out of scope I'll skip the discussion that evolves around who said =
what first.


> On Tue, Apr 5, 2011 at 10:10 AM, Henry Story <[e-mail]> =
wrote:
>=20
> On 5 Apr 2011, at 15:17, Phillip Hallam-Baker wrote:
> [snip]
>> Owning a DNS name does not make you a good person.
>=20
> Owning a multi billion dollar company that can afford a EV cert does =
not do that either. I think we have seen plenty of examples of that =
recently. Certification does not guarantee moral behavior, just =
identity. With DNS & Dane it is domain-name identity. CA's can then add =
extra information and certify additional properties.
>=20
> But having been vetted through EV does at least establish a reasonable =
probability that they are accountable in law and it is rather likely =
that the user already has an idea of the extent to which that is useful.
>=20
> If someone has an EV cert telling me that they are incorporated in =
Lagos, Nigeria that extent may not be very high. If the company is =
incorporated in Germany or the UK I have rather more confidence.

If I click from a page that I trust and I trust I arrived on the page it =
linked to then I don't care where the people live: Nigeria, Lagos or =
Germany.  The web functions with so little security because the network =
effect is so powerful. Increasing the lowest common denominator security =
will benefit from the network effect and create a huge increase in =
security.

> [snip]
> Ok, I don't see why allowing Dane to publish self signed certs affects =
this at all? Does it not make things easier? In the HTTPS case it =
clearly does.
>=20
> Nobody is arguing against publishing self-signed certs.

Ok. That's all I really care about. I want self signed certs support in =
Dane.

>=20
> I am arguing that=20
> 1) We should allow publication of self signed certs to improve =
security.
> 2) Security is only in fact improved if it is known that TLS is =
offered.=20
> 3) It is necessary to support both in order to address the use case.

We mostly agree here.

I would put (2) differently. If most pages linking to other page were =
behind TLS (even if unencrypted) and so if those would link to other =
page behind tls (even if unencrypted) then the web would be a much much =
more secure place. Because we could use the web of linked pages much =
more strongly to determine trust.=20

>=20
> People are using self-signed certs for SMTP with STARTTLS perfectly =
well today.

Perfectly?

> What means of attack does DANE provide a control for? Is there any =
attacker that is going to be thwarted?

With Dane more pages on the web will be able to point to resources with =
https URIs. As people click from one resource to another, they will at =
least be able to have a warning if a man in the middle attack is taking =
place. How that warning is presented to the user is a UI issue - and I =
am sure a lot of work can still be done in that space.


> =20
> There will be a lot less warning screens in his day to day experience, =
and so it will be possible to teach the user to take  failures more =
seriously. Currently there are many cases where users are taught to =
click through the warning screen, by knowledgeable people. This can =
become a habit. Allowing self signed certs to be published in Dane will =
make it easy to tell people: why don't you just publish your self signed =
cert in DNS? If you can't even bother to do that, then why should I take =
your site/service seriously.
>=20
> Again you step into UI while claiming it is out of scope. The UI =
implications have to be in scope or the process is nonsense.

I said UI is VERY important. I just don't want to get into a debate on =
what UI elements are the best here and what the semantics of each =
element are!

Ok. I'll stop here. The point of this thread is not to work through one =
issue but to get use cases together. Perhaps that is what we are doing, =
but if feels a bit more like an argument.


Henry

> [snip]=20


--Apple-Mail-61--560325366
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><br><div><div>On 5 Apr 2011, at 16:42, Phillip Hallam-Baker =
wrote:</div><div><br></div><blockquote type=3D"cite">I don't think it is =
useful to get back into an argument of who said what or argued =
what.</blockquote><div><br></div><div>You then go into arguments =
claiming I was talking of something first and using it as part of an =
argument, and&nbsp;so on, when it was just meant to be illustrative. =
Anyway, since everyone on this lists agrees that UI design is out of =
scope I'll skip the discussion that evolves around who said what =
first.</div><div><br></div><br><blockquote type=3D"cite">On Tue, Apr 5, =
2011 at 10:10 AM, Henry Story <span dir=3D"ltr">&lt;<a =
href=3D"mailto:[e-mail]">[e-mail]</a>&gt;</s=
pan> wrote:<br><div class=3D"gmail_quote"><blockquote =
class=3D"gmail_quote" style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; =
border-left-color: rgb(204, 204, 204); border-left-style: solid; =
padding-left: 1ex; position: static; z-index: auto; ">
<div style=3D"word-wrap:break-word"><br><div><div class=3D"im"><div>On 5 =
Apr 2011, at 15:17, Phillip Hallam-Baker =
wrote:</div></div></div></div></blockquote><div>[snip]</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex;">
<div style=3D"word-wrap:break-word"><div><div class=3D"im"><blockquote =
type=3D"cite"><div class=3D"gmail_quote"><div>Owning a DNS name does not =
make you a good person. =
</div></div></blockquote><div><br></div></div><div>Owning a multi =
billion dollar company that can afford a EV cert does not do that =
either. I think we have seen plenty of examples of that recently. =
Certification does not guarantee moral behavior, just identity. With DNS =
&amp; Dane it is domain-name identity. CA's can then add extra =
information and certify additional properties.</div>
</div></div></blockquote><div><br></div><div>But having been vetted =
through EV does at least establish a reasonable probability that they =
are accountable in law and it is rather likely that the user already has =
an idea of the extent to which that is useful.</div>
<div><br></div><div>If someone has an EV cert telling me that they are =
incorporated in Lagos, Nigeria that extent may not be very high. If the =
company is incorporated in Germany or the UK I have rather more =
confidence.</div></div></blockquote><div><br></div><div>If I click from =
a page that I trust and I trust I arrived on the page it linked to then =
I don't care where the people live: Nigeria, Lagos or Germany. &nbsp;The =
web functions with so little security because the network effect is so =
powerful. Increasing the lowest common denominator security will benefit =
from the network effect and create a huge increase in =
security.</div><div><br></div><blockquote type=3D"cite"><div =
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, =
204, 204); border-left-style: solid; padding-left: 1ex; position: =
static; z-index: auto; "><div style=3D"word-wrap:break-word"><div><div =
class=3D"im"><div><font class=3D"Apple-style-span" =
color=3D"#000000">[snip]</font></div></div><div>Ok, I don't see why =
allowing Dane to publish self signed certs affects this at all? Does it =
not make things easier? In the HTTPS case it clearly does.</div>
</div></div></blockquote><div><br></div><div>Nobody is arguing against =
publishing self-signed =
certs.</div></div></blockquote><div><br></div><div>Ok. That's all I =
really care about. I want self signed certs support in =
Dane.</div><br><blockquote type=3D"cite"><div =
class=3D"gmail_quote"><div><br></div><div>I am arguing =
that&nbsp;</div><div>1) We should allow publication of self signed certs =
to improve security.</div>
<div>2) Security is only in fact improved if it is known that TLS is =
offered.&nbsp;</div><div>3) It is necessary to support both in order to =
address the use case.</div></div></blockquote><div><br></div>We mostly =
agree here.<br><div><br></div><div>I would put (2) differently. If most =
pages linking to other page were behind TLS (even if unencrypted) and so =
if those would link to other page behind tls (even if unencrypted) then =
the web would be a much much more secure place. Because we could use the =
web of linked pages much more strongly to determine =
trust.&nbsp;</div><br><blockquote type=3D"cite"><div =
class=3D"gmail_quote"><div><br></div><div>People are using self-signed =
certs for SMTP with STARTTLS perfectly well =
today.</div></div></blockquote><div><br></div>Perfectly?<br><div><br></div=
><blockquote type=3D"cite"><div class=3D"gmail_quote"><div> What means =
of attack does DANE provide a control for? Is there any attacker that is =
going to be thwarted?</div></div></blockquote><div><br></div><div>With =
Dane more pages on the web will be able to point to resources with https =
URIs. As people click from one resource to another, they will at least =
be able to have a warning if a man in the middle attack is taking place. =
How that warning is presented to the user is a UI issue - and I am sure =
a lot of work can still be done in that =
space.</div><div><br></div><div><br></div><blockquote type=3D"cite"><div =
class=3D"gmail_quote">
<div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; =
border-left-width: 1px; border-left-color: rgb(204, 204, 204); =
border-left-style: solid; padding-left: 1ex; position: static; z-index: =
auto; "><div style=3D"word-wrap:break-word"><div><div>There will be a =
lot less warning screens in his day to day experience, and so it will be =
possible to teach the user to take &nbsp;failures more seriously. =
Currently there are many cases where users are taught to click through =
the warning screen, by knowledgeable people. This can become a habit. =
Allowing self signed certs to be published in Dane will make it easy to =
tell people: why don't you just publish your self signed cert in DNS? If =
you can't even bother to do that, then why should I take your =
site/service seriously.</div>
</div></div></blockquote><div><br></div><div>Again you step into UI =
while claiming it is out of scope. The UI implications have to be in =
scope or the process is =
nonsense.</div></div></blockquote><div><br></div><div>I said UI is VERY =
important. I just don't want to get into a debate on what UI elements =
are the best here and what the semantics of each element =
are!</div><div><br></div><div>Ok. I'll stop here. The point of this =
thread is not to work through one issue but to get use cases together. =
Perhaps that is what we are doing, but if feels a bit more like an =
argument.</div><div><br></div><div><br></div><div>Henry</div><div><br></di=
v></div><blockquote type=3D"cite"><div =
class=3D"gmail_quote"><div>[snip]&nbsp;</div><blockquote =
class=3D"gmail_quote" style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; =
border-left-color: rgb(204, 204, 204); border-left-style: solid; =
padding-left: 1ex; "><div style=3D"word-wrap: break-word; =
"><div></div></div></blockquote></div></blockquote><div><div =
class=3D"gmail_quote"><div><br></div></div></div></body></html>=

--Apple-Mail-61--560325366--

From [e-mail]  Tue Apr  5 08:24:17 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 388203A694F for <[e-mail]>; Tue,  5 Apr 2011 08:24:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.563
X-Spam-Level: 
X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id We01X3vaOtSK for <[e-mail]>; Tue,  5 Apr 2011 08:24:16 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id B07863A68E8 for <[e-mail]>; Tue,  5 Apr 2011 08:24:16 -0700 (PDT)
Received: from dhcp89-089-213.bbn.com ([128.89.89.213]:49227) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <[e-mail]>) id 1Q788l-000Pv4-Eq; Tue, 05 Apr 2011 11:25:59 -0400
Mime-Version: 1.0
Message-Id: <p06240809c9c0e2754429@[128.89.89.213]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <BANLkTimNauWFBSvsvzfx4TUcU=[e-mail]> <[e-mail]>
Date: Tue, 5 Apr 2011 11:17:54 -0400
To: Paul Hoffman <[e-mail]>
From: Stephen Kent <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2011 15:24:17 -0000

Paul,

I have to agree with one aspects of what PHB has suggested, i.e., 
that we need more than statements of requirements. We need one 
(preferably more) motivations for each requirement, to justify why it 
is a requirement.

Steve

From [e-mail]  Tue Apr  5 08:24:17 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4854D3A68E8 for <[e-mail]>; Tue,  5 Apr 2011 08:24:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.564
X-Spam-Level: 
X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ME0BJzHpHOMy for <[e-mail]>; Tue,  5 Apr 2011 08:24:16 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id B0A313A6949 for <[e-mail]>; Tue,  5 Apr 2011 08:24:16 -0700 (PDT)
Received: from dhcp89-089-213.bbn.com ([128.89.89.213]:49227) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <[e-mail]>) id 1Q788k-000Pv4-Qy; Tue, 05 Apr 2011 11:25:59 -0400
Mime-Version: 1.0
Message-Id: <p06240808c9c0e1bd192f@[128.89.89.213]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 5 Apr 2011 11:13:13 -0400
To: Ben Laurie <[e-mail]>
From: Stephen Kent <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Cc: Paul Hoffman <[e-mail]>, [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2011 15:24:17 -0000

At 11:22 AM +0100 4/5/11, Ben Laurie wrote:
>...
>
>OTOH, I think 4 is vital - otherwise self-signed certs cannot be first
>class citizens.

A self-signed cert can be used as a TA, and is covered under #3.

Steve

From [e-mail]  Tue Apr  5 08:35:12 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2CA33A6819 for <[e-mail]>; Tue,  5 Apr 2011 08:35:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.373
X-Spam-Level: 
X-Spam-Status: No, score=-3.373 tagged_above=-999 required=5 tests=[AWL=0.226,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tkLEzEHVzwW for <[e-mail]>; Tue,  5 Apr 2011 08:35:11 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id C093B3A67F5 for <[e-mail]>; Tue,  5 Apr 2011 08:35:10 -0700 (PDT)
Received: by wwa36 with SMTP id 36so423123wwa.13 for <[e-mail]>; Tue, 05 Apr 2011 08:36:53 -0700 (PDT)
Received: by 10.227.147.194 with SMTP id m2mr8865699wbv.145.1302017812390; Tue, 05 Apr 2011 08:36:52 -0700 (PDT)
Received: from bblfish.home (ALagny-751-1-3-136.w86-218.abo.wanadoo.fr [86.218.42.136]) by mx.google.com with ESMTPS id p5sm3643583wbg.11.2011.04.05.08.36.50 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Apr 2011 08:36:51 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: Henry Story <[e-mail]>
In-Reply-To: <p06240808c9c0e1bd192f@[128.89.89.213]>
Date: Tue, 5 Apr 2011 17:36:49 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <p06240808c9c0e1bd192f@[128.89.89.213]>
To: Stephen Kent <[e-mail]>
X-Mailer: Apple Mail (2.1082)
Cc: Paul Hoffman <[e-mail]>, [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2011 15:35:13 -0000

On 5 Apr 2011, at 17:13, Stephen Kent wrote:

> At 11:22 AM +0100 4/5/11, Ben Laurie wrote:
>> ...
>>=20
>> OTOH, I think 4 is vital - otherwise self-signed certs cannot be =
first
>> class citizens.
>=20
> A self-signed cert can be used as a TA, and is covered under #3.

It may be technically covered under #3 but the point was to create use =
cases and requirements.
#3 does not make the importance of self signed certs clear.

Henry

>=20
> Steve
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane

Social Web Architect
http://bblfish.net/


From [e-mail]  Tue Apr  5 08:44:57 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEB833A67AF for <[e-mail]>; Tue,  5 Apr 2011 08:44:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.901
X-Spam-Level: 
X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=0.699,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-cHye0XSAiH for <[e-mail]>; Tue,  5 Apr 2011 08:44:57 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 3E6B23A67CF for <[e-mail]>; Tue,  5 Apr 2011 08:44:56 -0700 (PDT)
Received: by qwc23 with SMTP id 23so395395qwc.31 for <[e-mail]>; Tue, 05 Apr 2011 08:46:40 -0700 (PDT)
Received: by 10.224.205.132 with SMTP id fq4mr6545583qab.242.1302018399475; Tue, 05 Apr 2011 08:46:39 -0700 (PDT)
Received: from [192.168.1.4] (pool-173-79-111-27.washdc.fios.verizon.net [173.79.111.27]) by mx.google.com with ESMTPS id g26sm4277766qco.42.2011.04.05.08.46.37 (version=SSLv3 cipher=OTHER); Tue, 05 Apr 2011 08:46:38 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.2.0.101115
Date: Tue, 05 Apr 2011 11:46:31 -0400
From: Carl Wallace <[e-mail]>
To: Henry Story <[e-mail]>, Stephen Kent <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: [dane] [keyassure] Use cases document.
In-Reply-To: <[e-mail]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: Paul Hoffman <[e-mail]>, [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2011 15:44:58 -0000

On 4/5/11 11:36 AM, "Henry Story" <[e-mail]> wrote:

>
>On 5 Apr 2011, at 17:13, Stephen Kent wrote:
>
>> At 11:22 AM +0100 4/5/11, Ben Laurie wrote:
>>> ...
>>> 
>>> OTOH, I think 4 is vital - otherwise self-signed certs cannot be first
>>> class citizens.
>> 
>> A self-signed cert can be used as a TA, and is covered under #3.
>
>It may be technically covered under #3 but the point was to create use
>cases and requirements.
>#3 does not make the importance of self signed certs clear.
>
>Henry

It could be technically covered under any of these options, of which there
are really only two: cert lock and CA lock.  The other two options are
just instances of the first two where the client elected not to perform
further processing.  If the intent is to allow the server operator to
preclude further client action that should be stated in the use case, but
it does not seem necessary.  



From [e-mail]  Tue Apr  5 08:46:36 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38C723A6957 for <[e-mail]>; Tue,  5 Apr 2011 08:46:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.533
X-Spam-Level: 
X-Spam-Status: No, score=-3.533 tagged_above=-999 required=5 tests=[AWL=0.065,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DL1scgjgZk2Z for <[e-mail]>; Tue,  5 Apr 2011 08:46:29 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id ADB403A68E8 for <[e-mail]>; Tue,  5 Apr 2011 08:46:29 -0700 (PDT)
Received: by vws12 with SMTP id 12so470935vws.31 for <[e-mail]>; Tue, 05 Apr 2011 08:48:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vAwAAHlxgtm9ibemyNyWwTSVFYe5kdeBmZryT0OfTHQ=; b=MTSWxi28MMPTE94KvHmmMHp9GZxFY7gyI768KnjMcN9Z46nd1NRgcMWcbT5NnPkKDV jx+gwXfVhC5/octMf5w9Fnlgt0QEl09VA9MlC0Z4IN9r0s1hV0dUTrGrl3lBA1rPvP3n 0/zXia8RWQdZa+jiPCAimaM5TUGrgnFQvSau8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=qo/kfaAUzTFo/tloYq56MJAw2s95XqxSymRX0hkPMI4onhHm8sgkjJJPztdXASaKMN omKeq5SnQ+maJo6MnhZhQlKXkHgvz7vXdMV5E+fYBpIwJMbpgIuDEVzXzm1zeq2m7xJm afiGrxH4NFcK4+RPBhO6aHWFaeb5mFw/m3mAI=
MIME-Version: 1.0
Received: by 10.52.100.39 with SMTP id ev7mr1865136vdb.218.1302018492728; Tue, 05 Apr 2011 08:48:12 -0700 (PDT)
Received: by 10.52.161.42 with HTTP; Tue, 5 Apr 2011 08:48:12 -0700 (PDT)
In-Reply-To: <p06240808c9c0e1bd192f@128.89.89.213>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <p06240808c9c0e1bd192f@128.89.89.213>
Date: Tue, 5 Apr 2011 11:48:12 -0400
Message-ID: <BANLkTi=7K-Pvgy+Z+Z18fhid=[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: Stephen Kent <[e-mail]>
Content-Type: multipart/alternative; boundary=bcaec50163b9c0077404a02dcd15
Cc: Paul Hoffman <[e-mail]>, [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2011 15:46:36 -0000

--bcaec50163b9c0077404a02dcd15
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Apr 5, 2011 at 11:13 AM, Stephen Kent <[e-mail]> wrote:

> At 11:22 AM +0100 4/5/11, Ben Laurie wrote:
>
>> ...
>>
>>
>> OTOH, I think 4 is vital - otherwise self-signed certs cannot be first
>> class citizens.
>>
>
> A self-signed cert can be used as a TA, and is covered under #3.
>

I see this particular issue, whether a cert is encoded directly or the user
is required to insert a trust anchor to be a matter of implementation detail
and not a requirements question at all.

Amongst the requirements I have text for are:

[R-C-KEYPUB] Allow relying party to access the value of the key
material which may or may not be valid for the domain for which it
is published.

[R-C-DV] Assert that a key is valid for use with a specific domain

[R-P-LOCAL] Support deployment by local network administration without
reference to any other party.

[R-P-LOCALD] Support deployment by local network administration without
reference to any other party except for enrollment of DNSSEC KSK.


Note that it is quite likely going to be the case that it is not possible to
meet every requirement simultaneously. So attempting to usefully protect
against Mallet (who can perform a man in the middle attack) without DNSSEC
does not look possible to me, but protecting against EVE who can only
evesdrop (but cannot perform an integrity attack) may well be feasible.

And so I expect that at the end we are going to have proposals that state

'Use of DNSSEC is optional, thus [R-P-LOCAL] is satisfied. However in the
case DNSSEC is not used, the connection is vulnerable to an attack by
[A-SPOOF] or [A-MALLET], protection is only provided against [A-EVE]'

With DNSSEC deployment, protection is given against [A-SPOOF] and [A-MALLET]

With DNSSEC deployment and use of a third party issued certificate...

And so on.


There are going to be options and they are going to mean that there is a
tradeoff between security and convenience. That is OK, if there was no
tradeoff there would be no point in offering an option.

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

--bcaec50163b9c0077404a02dcd15
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Tue, Apr 5, 2011 at 11:13 AM, Stephen=
 Kent <span dir=3D"ltr">&lt;<a href=3D"mailto:[e-mail]">[e-mail]</a=
>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
At 11:22 AM +0100 4/5/11, Ben Laurie wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
...<div class=3D"im"><br>
<br>
OTOH, I think 4 is vital - otherwise self-signed certs cannot be first<br>
class citizens.<br>
</div></blockquote>
<br>
A self-signed cert can be used as a TA, and is covered under #3.<br></block=
quote><div><br></div><div>I see this particular issue, whether a cert is en=
coded directly or the user is required to insert a trust anchor to be a mat=
ter of implementation detail and not a requirements question at all.</div>
<div><br></div><div>Amongst the requirements I have text for are:</div><div=
><br></div><div><div>[R-C-KEYPUB] Allow relying party to access the value o=
f the key material=A0which may or may not be valid for the domain for which=
 it is=A0published.</div>
</div></div><br clear=3D"all"><div>[R-C-DV] Assert that a key is valid for =
use with a specific=A0domain</div><div><br></div><div>[R-P-LOCAL] Support d=
eployment by local network administration without reference to any other pa=
rty.</div>
<div><br></div><div>[R-P-LOCALD] Support deployment by local network admini=
stration without reference to any other party except for enrollment of DNSS=
EC KSK.</div><div><br></div><div><br></div><div>Note that it is quite likel=
y going to be the case that it is not possible to meet every requirement si=
multaneously. So attempting to usefully protect against Mallet (who can per=
form a man in the middle attack) without DNSSEC does not look possible to m=
e, but protecting against EVE who can only evesdrop (but cannot perform an =
integrity attack) may well be feasible.</div>
<div><br></div><div>And so I expect that at the end we are going to have pr=
oposals that state</div><div><br></div><div>&#39;Use of DNSSEC is optional,=
 thus [R-P-LOCAL] is satisfied. However in the case DNSSEC is not used, the=
 connection is vulnerable to an attack by [A-SPOOF] or [A-MALLET], protecti=
on is only provided against [A-EVE]&#39;</div>
<div><br></div><div>With DNSSEC deployment, protection is given against [A-=
SPOOF] and [A-MALLET]</div><div><br></div><div>With DNSSEC deployment and u=
se of a third party issued certificate...</div><div><br></div><div>And so o=
n.</div>
<div><br></div><div><br></div><div>There are going to be options and they a=
re going to mean that there is a tradeoff between security and convenience.=
 That is OK, if there was no tradeoff there would be no point in offering a=
n option.</div>
<div><br></div><div>-- <br>Website: <a href=3D"http://hallambaker.com/">htt=
p://hallambaker.com/</a><br><br>
</div>

--bcaec50163b9c0077404a02dcd15--

From [e-mail]  Tue Apr  5 09:08:58 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A90DA28C107 for <[e-mail]>; Tue,  5 Apr 2011 09:08:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.565
X-Spam-Level: 
X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CqDCMkvaAn1L for <[e-mail]>; Tue,  5 Apr 2011 09:08:52 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 1A21A28C0DE for <[e-mail]>; Tue,  5 Apr 2011 09:08:52 -0700 (PDT)
Received: from dhcp89-089-213.bbn.com ([128.89.89.213]:49231) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <[e-mail]>) id 1Q78pv-0000xr-5G; Tue, 05 Apr 2011 12:10:35 -0400
Mime-Version: 1.0
Message-Id: <p0624080cc9c0ed14c191@[128.89.89.213]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <p06240808c9c0e1bd192f@[128.89.89.213]> <[e-mail]>
Date: Tue, 5 Apr 2011 12:03:15 -0400
To: Henry Story <[e-mail]>
From: Stephen Kent <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2011 16:08:58 -0000

At 5:36 PM +0200 4/5/11, Henry Story wrote:
>On 5 Apr 2011, at 17:13, Stephen Kent wrote:
>
>>  At 11:22 AM +0100 4/5/11, Ben Laurie wrote:
>>>  ...
>>>
>>>  OTOH, I think 4 is vital - otherwise self-signed certs cannot be first
>>>  class citizens.
>>
>>  A self-signed cert can be used as a TA, and is covered under #3.
>
>It may be technically covered under #3 but the point was to create 
>use cases and requirements.
>#3 does not make the importance of self signed certs clear.
>
>Henry

I agree that self-signed certs are an important way for web sites to
become 1st class citizens w/o paying a TTP CA.  But, #4 is not a
requirement relative to that goal; it is just one way to achieve that
goal, and it is redundant relative to #3. Since having fewer ways to
accomplish a set of goals is generally viewed as desirable ...

Steve

From [e-mail]  Tue Apr  5 09:40:41 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 586E23A6960 for <[e-mail]>; Tue,  5 Apr 2011 09:40:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.593
X-Spam-Level: 
X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.006,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bveX93g9vWnu for <[e-mail]>; Tue,  5 Apr 2011 09:40:40 -0700 (PDT)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 3A65C3A695F for <[e-mail]>; Tue,  5 Apr 2011 09:40:40 -0700 (PDT)
Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id D91BEC5E8 for <[e-mail]>; Tue,  5 Apr 2011 12:42:20 -0400 (EDT)
Date: Tue, 5 Apr 2011 12:42:20 -0400 (EDT)
From: Paul Wouters <[e-mail]>
To: [e-mail]
In-Reply-To: <1302012455.3356.7.camel@localhost>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <1302012455.3356.7.camel@localhost>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [dane] browser UI out of scope, was Re:  Objective: Restrictive versus Supplementary Models
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2011 16:40:41 -0000

On Tue, 5 Apr 2011, Matt McCutchen wrote:

> On Tue, 2011-04-05 at 11:13 +0000, Florian Weimer wrote:
> > If you switch HTTPS transparently (meaning: no UI indicators, secure
> > cookies are not sent, SOP checks run against :80 instead of :443),
> > then you don't need DNSSEC.
> 
> Indeed, this could be done, but I want server-authenticated connections.
> 
> > I'm pretty sure it's politically and technically infeasible to
> > introduce DNSSEC-driven UI changes on a larger scale, so I doubt that
> > any non-transparent approach will fly.
> 
> Technically, the existing Firefox blue badge works with my modified NSS
> (https://mattmccutchen.net/cryptid/#nss-dane) if you ignore the
> unvalidated certificate details.  Politically, I don't know, but I would
> use such a browser.

This working group is designing a protocol, not a web browser UI. I suggest we focus on
the protocol design, and not get lost in padlocks, green bars, blue badges or what not.

Similarly, our use cases or requirements are not "create some art in the browser window"

I'm sure the browser people can deal with their gui representation in the new world of
TLS information that came from non-PKIX sources, DANE or otherwise.

Paul

From [e-mail]  Tue Apr  5 10:09:30 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B90793A6969 for <[e-mail]>; Tue,  5 Apr 2011 10:09:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.534
X-Spam-Level: 
X-Spam-Status: No, score=-3.534 tagged_above=-999 required=5 tests=[AWL=0.064,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQiUbf70Jooj for <[e-mail]>; Tue,  5 Apr 2011 10:09:28 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 9F86B3A6965 for <[e-mail]>; Tue,  5 Apr 2011 10:09:28 -0700 (PDT)
Received: by vws12 with SMTP id 12so559728vws.31 for <[e-mail]>; Tue, 05 Apr 2011 10:11:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Vq7z9Bn/sLelO+mv6/9WwBHOlbha31+zrxEwsTiCU1k=; b=hrPUIVkanrm56DAKEqdZ8w2SRX4+JBgMAH/2GN7oUSqLHoAcatQWqbjv/nKqB0Qy4i IGkqLmmeWk/a2WUr0cdVuRMzzp9AH1TatNC4/5XS2m4Z/tPSpum2Xi3INC00D14X2Gel MLsxOfaB1elcNc8CUmv5CGYEqljFOU8vI6zf0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=WsA0miHv7jjuSh0ZyP9E2KRHLWp97uhEoJJ7Hs0eoMMf+JtC4RaYn1JU1Yf2FNZoa3 0j4VKJ6I1wJ6pySkMw2tXSatRDZ894cNrqTH+YLqPTQG0Ox3tGF5iD36KUn5SRojVhJD i/Ho6ZZwkxWyFPwbLJlly5Gm3qB1Rn+9+PRYw=
MIME-Version: 1.0
Received: by 10.52.0.74 with SMTP id 10mr6566788vdc.18.1302023471700; Tue, 05 Apr 2011 10:11:11 -0700 (PDT)
Received: by 10.52.161.42 with HTTP; Tue, 5 Apr 2011 10:11:11 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <1302012455.3356.7.camel@localhost> <[e-mail]>
Date: Tue, 5 Apr 2011 13:11:11 -0400
Message-ID: <[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: Paul Wouters <[e-mail]>
Content-Type: multipart/alternative; boundary=20cf3054a133851c8604a02ef697
Cc: [e-mail]
Subject: Re: [dane] browser UI out of scope, was Re: Objective: Restrictive versus Supplementary Models
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2011 17:09:30 -0000

--20cf3054a133851c8604a02ef697
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Apr 5, 2011 at 12:42 PM, Paul Wouters <[e-mail]> wrote:

>
> This working group is designing a protocol, not a web browser UI. I suggest
> we focus on
> the protocol design, and not get lost in padlocks, green bars, blue badges
> or what not.
>
> Similarly, our use cases or requirements are not "create some art in the
> browser window"
>

Agree



> I'm sure the browser people can deal with their gui representation in the
> new world of
> TLS information that came from non-PKIX sources, DANE or otherwise.


Strongly disagree.

All the evidence from the usability 'experts' tells us that users (1) do not
notice the existence or otherwise of the low assurance security signal and
(2) do not understand what it means.

If people want to propose relying on a feature then they have to provide
evidence that it works. There is quite a lot of evidence to show that the EV
high assurance security signal is effective (shopping cart completion
rates).


I don't accept the argument that we can rely on a mechanism that we know to
be broken by ruling it out of scope. Better not to rely on that mechanism at
all.

We have the opportunity here to propose a scheme that does not require any
UI presentation that is no more complex to implement and has identical
performance characteristics to one that does.


All we need to do here is to design the mechanism in such a way that when a
DNS domain advertises a key/cert for protocol foo, that the relying party is
required to infer that this means that the genuine service will always offer
the corresponding security enhancement for protocol foo.

It does not mean having to make the protocol any more complex.

It does however require that we be very clear about our requirements and
what the precise semantics of the records are.

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

--20cf3054a133851c8604a02ef697
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Tue, Apr 5, 2011 at 12:42 PM, Paul Wo=
uters <span dir=3D"ltr">&lt;<a href=3D"mailto:[e-mail]">paul@xele=
rance.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
This working group is designing a protocol, not a web browser UI. I suggest=
 we focus on<br>
the protocol design, and not get lost in padlocks, green bars, blue badges =
or what not.<br>
<br>
Similarly, our use cases or requirements are not &quot;create some art in t=
he browser window&quot;<br></blockquote><div><br></div><div>Agree</div><div=
><br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

I&#39;m sure the browser people can deal with their gui representation in t=
he new world of<br>
TLS information that came from non-PKIX sources, DANE or otherwise.</blockq=
uote><div><br></div><div>Strongly disagree.</div><div><br></div><div>All th=
e evidence from the usability &#39;experts&#39; tells us that users (1) do =
not notice the existence or otherwise of the low assurance security signal =
and (2) do not understand what it means.</div>
<div><br></div><div>If people want to propose relying on a feature then the=
y have to provide evidence that it works. There is quite a lot of evidence =
to show that the EV high assurance security signal is effective (shopping c=
art completion rates).</div>
<div><br></div><div><br></div><div>I don&#39;t accept the argument that we =
can rely on a mechanism that we know to be broken by ruling it out of scope=
. Better not to rely on that mechanism at all.</div><div><br></div><div>
We have the opportunity here to propose a scheme that does not require any =
UI presentation that is no more complex to implement and has identical perf=
ormance characteristics to one that does.=A0</div><div><br></div><div><br>
</div><div>All we need to do here is to design the mechanism in such a way =
that when a DNS domain advertises a key/cert for protocol foo, that the rel=
ying party is required to infer that this means that the genuine service wi=
ll always offer the corresponding security enhancement for protocol foo.</d=
iv>
<div><br></div><div>It does not mean having to make the protocol any more c=
omplex.=A0</div><div><br></div><div>It does however require that we be very=
 clear about our requirements and what the precise semantics of the records=
 are.</div>
<div><br></div></div>-- <br>Website: <a href=3D"http://hallambaker.com/">ht=
tp://hallambaker.com/</a><br><br>

--20cf3054a133851c8604a02ef697--

From [e-mail]  Tue Apr  5 10:15:51 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3283428C120 for <[e-mail]>; Tue,  5 Apr 2011 10:15:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.578
X-Spam-Level: 
X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6OtLaFw9UFr8 for <[e-mail]>; Tue,  5 Apr 2011 10:15:50 -0700 (PDT)
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id A6E7028C11F for <[e-mail]>; Tue,  5 Apr 2011 10:15:50 -0700 (PDT)
Received: from shinkuro.com (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 82E6D1ECB422 for <[e-mail]>; Tue,  5 Apr 2011 17:17:33 +0000 (UTC)
Date: Tue, 5 Apr 2011 13:17:31 -0400
From: Andrew Sullivan <[e-mail]>
To: [e-mail]
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <1302012455.3356.7.camel@localhost> <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [dane] browser UI out of scope, was Re: Objective: Restrictive versus Supplementary Models
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2011 17:15:51 -0000

On Tue, Apr 05, 2011 at 01:11:11PM -0400, Phillip Hallam-Baker wrote:

> All we need to do here is to design the mechanism in such a way that when a
> DNS domain advertises a key/cert for protocol foo, that the relying party is
> required to infer that this means that the genuine service will always offer
> the corresponding security enhancement for protocol foo.

I thought the important thing to remember on the Internet was that you
are so not in charge, for every value of "you".  If that's right, then
I fail completely to understand how a level as low as the DNS is going
to "require" any inference on the part of the application layer.  This
entire thread seems to me to be a massive distraction.  Clients can do
what they want with information published in the DNS, and we're not
going to be the boss of them no matter how much we'd like to be.

A

-- 
Andrew Sullivan
[e-mail]
Shinkuro, Inc.

From [e-mail]  Tue Apr  5 10:30:35 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC4CA28C127 for <[e-mail]>; Tue,  5 Apr 2011 10:30:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.034
X-Spam-Level: 
X-Spam-Status: No, score=-3.034 tagged_above=-999 required=5 tests=[AWL=-0.436, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ewkAebQd+Fhp for <[e-mail]>; Tue,  5 Apr 2011 10:30:33 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 8C7213A6941 for <[e-mail]>; Tue,  5 Apr 2011 10:30:33 -0700 (PDT)
Received: by vxg33 with SMTP id 33so574165vxg.31 for <[e-mail]>; Tue, 05 Apr 2011 10:32:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=7E28/JDgyk8g/mgJbd88SRP5SGoTUjj7Fo9a0d6TvDQ=; b=H/z/b147J86FLCUefVBlFMhiB79cHxmjGxf0rN74FQVcv96etPP5ccZ5a3MYms2COk oVai8xScQfgAEFRLddAEdUud9VQ9SbzXyAQxtecnmQlCBWmSevo6S5WX1tYCyrkFaSio ZwppyXXZBEC2XZDe94xDEUux7TWD+1voF+mPI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=JD3REwFC1KMkduO9zByYsG6LCfKxTzUvIhZscmWgZkuQRrrjCTiKBg6l3ExwHO9qUq 2mauVB0dMq+LYNkbZtmebRwRHMRVgkWZKjlfgUSCYBVHAJ/HX6wd4iuRlMNGxTfekeZZ 2TqVj2908kc7V/7tpA0Bkr/HDT8DDok5heklk=
MIME-Version: 1.0
Received: by 10.52.70.174 with SMTP id n14mr11215292vdu.258.1302024736714; Tue, 05 Apr 2011 10:32:16 -0700 (PDT)
Received: by 10.52.161.42 with HTTP; Tue, 5 Apr 2011 10:32:16 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <1302012455.3356.7.camel@localhost> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 5 Apr 2011 19:32:16 +0200
Message-ID: <BANLkTi=[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: Andrew Sullivan <[e-mail]>
Content-Type: multipart/alternative; boundary=20cf3071c9d0ebb30b04a02f4140
Cc: [e-mail]
Subject: Re: [dane] browser UI out of scope, was Re: Objective: Restrictive versus Supplementary Models
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2011 17:30:35 -0000

--20cf3071c9d0ebb30b04a02f4140
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Apr 5, 2011 at 7:17 PM, Andrew Sullivan <[e-mail]> wrote:

> On Tue, Apr 05, 2011 at 01:11:11PM -0400, Phillip Hallam-Baker wrote:
>
> > All we need to do here is to design the mechanism in such a way that when
> a
> > DNS domain advertises a key/cert for protocol foo, that the relying party
> is
> > required to infer that this means that the genuine service will always
> offer
> > the corresponding security enhancement for protocol foo.
>
> I thought the important thing to remember on the Internet was that you
> are so not in charge, for every value of "you".  If that's right, then
> I fail completely to understand how a level as low as the DNS is going
> to "require" any inference on the part of the application layer.  This
> entire thread seems to me to be a massive distraction.  Clients can do
> what they want with information published in the DNS, and we're not
> going to be the boss of them no matter how much we'd like to be.
>

There is a big difference between

1) Trust me when F(x) = True
2) Do not trust me when F(x) = False

The DNS would have to be very different for it to be used for case (1). It
is borderline sufficient for case (2) without DNSSEC and quite satisfactory
as one factor for case (2) with DNSSEC.


DANE is not about telling people which certificates or keys to trust, it is
all about what certificates, keys, security properties clients should NOT
trust.


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

--20cf3071c9d0ebb30b04a02f4140
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Tue, Apr 5, 2011 at 7:17 PM, Andrew S=
ullivan <span dir=3D"ltr">&lt;<a href=3D"mailto:[e-mail]">ajs@shink=
uro.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">On Tue, Apr 05, 2011 at 01:11:11PM -0400, Phillip Hallam-=
Baker wrote:<br>
<br>
&gt; All we need to do here is to design the mechanism in such a way that w=
hen a<br>
&gt; DNS domain advertises a key/cert for protocol foo, that the relying pa=
rty is<br>
&gt; required to infer that this means that the genuine service will always=
 offer<br>
&gt; the corresponding security enhancement for protocol foo.<br>
<br>
</div>I thought the important thing to remember on the Internet was that yo=
u<br>
are so not in charge, for every value of &quot;you&quot;. =A0If that&#39;s =
right, then<br>
I fail completely to understand how a level as low as the DNS is going<br>
to &quot;require&quot; any inference on the part of the application layer. =
=A0This<br>
entire thread seems to me to be a massive distraction. =A0Clients can do<br=
>
what they want with information published in the DNS, and we&#39;re not<br>
going to be the boss of them no matter how much we&#39;d like to be.<br></b=
lockquote><div><br></div><div>There is a big difference between</div><div><=
br></div><div>1) Trust me when F(x) =3D True</div><div>2) Do not trust me w=
hen F(x) =3D False</div>
<div><br></div><div>The DNS would have to be very different for it to be us=
ed for case (1). It is borderline sufficient for case (2) without DNSSEC an=
d quite satisfactory as one factor for case (2) with DNSSEC.</div><div>
<br></div><div><br></div><div>DANE is not about telling people which certif=
icates or keys to trust, it is all about what certificates, keys, security =
properties clients should NOT trust.</div><div><br></div><div>=A0</div></di=
v>
-- <br>Website: <a href=3D"http://hallambaker.com/">http://hallambaker.com/=
</a><br><br>

--20cf3071c9d0ebb30b04a02f4140--

From [e-mail]  Tue Apr  5 10:45:56 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF78B3A696C for <[e-mail]>; Tue,  5 Apr 2011 10:45:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.072
X-Spam-Level: 
X-Spam-Status: No, score=-102.072 tagged_above=-999 required=5 tests=[AWL=0.527, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SD9JqMAEjEST for <[e-mail]>; Tue,  5 Apr 2011 10:45:56 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by core3.amsl.com (Postfix) with ESMTP id F0BF73A6969 for <[e-mail]>; Tue,  5 Apr 2011 10:45:55 -0700 (PDT)
Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p35HlZAZ061367 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Apr 2011 10:47:36 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Paul Hoffman <[e-mail]>
In-Reply-To: <BANLkTi=[e-mail]>
Date: Tue, 5 Apr 2011 10:47:35 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <1302012455.3356.7.camel@localhost> <[e-mail]> <[e-mail]> <[e-mail]> <BANLkTi=[e-mail]>
To: Phillip Hallam-Baker <[e-mail]>
X-Mailer: Apple Mail (2.1084)
Cc: [e-mail]
Subject: Re: [dane] browser UI out of scope, was Re: Objective: Restrictive versus Supplementary Models
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2011 17:45:56 -0000

On Apr 5, 2011, at 10:32 AM, Phillip Hallam-Baker wrote:

> DANE is not about telling people which certificates or keys to trust, =
it is all about what certificates, keys, security properties clients =
should NOT trust.

That sounds like a requirement (not a use case) on which there has not =
been agreement here before. If the use cases you will be sending are not =
all predicated on that statement, when you send them, definitely please =
label which you think are and are not.

--Paul Hoffman


From [e-mail]  Tue Apr  5 10:46:41 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8357D3A696E for <[e-mail]>; Tue,  5 Apr 2011 10:46:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.485
X-Spam-Level: 
X-Spam-Status: No, score=-102.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ln5OMS1Zg-2H for <[e-mail]>; Tue,  5 Apr 2011 10:46:41 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 04B0C3A6969 for <[e-mail]>; Tue,  5 Apr 2011 10:46:41 -0700 (PDT)
Received: from ros-dhcp192-1-51-86.bbn.com ([192.1.51.86]:59906) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from <[e-mail]>) id 1Q7AMZ-0002nW-FZ; Tue, 05 Apr 2011 13:48:23 -0400
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: "Richard L. Barnes" <[e-mail]>
In-Reply-To: <BANLkTi=[e-mail]>
Date: Tue, 5 Apr 2011 13:48:21 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <1302012455.3356.7.camel@localhost> <[e-mail]> <[e-mail]> <[e-mail]> <BANLkTi=[e-mail]>
To: Phillip Hallam-Baker <[e-mail]>
X-Mailer: Apple Mail (2.1082)
Cc: [e-mail]
Subject: Re: [dane] browser UI out of scope, was Re: Objective: Restrictive versus Supplementary Models
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2011 17:46:41 -0000

> DANE is not about telling people which certificates or keys to trust, =
it is all about what certificates, keys, security properties clients =
should NOT trust.

That seems directly contrary to all the people who expressed interest in =
Use Cases 3 and 4 in my taxonomy, both of which specify certificates =
that clients SHOULD trust.

--Richard=

From [e-mail]  Tue Apr  5 10:54:26 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 802AD28C136 for <[e-mail]>; Tue,  5 Apr 2011 10:54:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.026
X-Spam-Level: 
X-Spam-Status: No, score=-3.026 tagged_above=-999 required=5 tests=[AWL=-0.428, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vtAywP64nure for <[e-mail]>; Tue,  5 Apr 2011 10:54:25 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 1F4AD28C13B for <[e-mail]>; Tue,  5 Apr 2011 10:54:21 -0700 (PDT)
Received: by vxg33 with SMTP id 33so596931vxg.31 for <[e-mail]>; Tue, 05 Apr 2011 10:56:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Rtay21TtN6E/NRa8SDFLwUxvpydjJ/sIuunfcgkSf1U=; b=qFKGrleVAe7XjZ6AIsyxZxDJNPByKUVCIzdEQnEIDaFNVsIuqQMn3Wc0p2dPQ5M9Gz H6hT0kI6zvM/CqKFruSHmNGgmPwjH0U4NVUYkItjFqK5cuZqCL/BxQDOTBQ6fvAj7OpJ RuV0HVbUhd9ZsnjL8FD7ivJzNA6cilZs4WU+M=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=U1okOP3+0A9MHa+Ms99tLF5SFvRjMMqRolzRpFmn6BZq8QI+SktrwaNi+zCGCz3XUA GgDUP5WlK3UKOWy/uDT/sprK4wD4aOLXiZLjxr7AUhf2wQ8FZSerPVFM38h4DhZ/9GoH hd3o4Q6UsMsfPFjFq5q8jMU4QgPi8+MEXubSc=
MIME-Version: 1.0
Received: by 10.52.67.103 with SMTP id m7mr4001956vdt.178.1302026163806; Tue, 05 Apr 2011 10:56:03 -0700 (PDT)
Received: by 10.52.161.42 with HTTP; Tue, 5 Apr 2011 10:56:03 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <1302012455.3356.7.camel@localhost> <[e-mail]> <[e-mail]> <[e-mail]> <BANLkTi=[e-mail]> <[e-mail]>
Date: Tue, 5 Apr 2011 19:56:03 +0200
Message-ID: <[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: "Richard L. Barnes" <[e-mail]>
Content-Type: multipart/alternative; boundary=20cf307abea7fb633304a02f96a7
Cc: [e-mail]
Subject: Re: [dane] browser UI out of scope, was Re: Objective: Restrictive versus Supplementary Models
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2011 17:54:26 -0000

--20cf307abea7fb633304a02f96a7
Content-Type: text/plain; charset=ISO-8859-1

The TLS protocol already allows the server to say to the client 'here is my
certificate, trust it'.

What DANE adds is the ability to say 'don't trust a certificate unless it
meets criteria X'


Which is how I read your two use cases.

OK, so maybe the statement is a little on the categorical side. But my point
is that we do not need to worry about the limitations of the DNS or DNSSEC
to do something that is useful.


On Tue, Apr 5, 2011 at 7:48 PM, Richard L. Barnes <[e-mail]> wrote:

> > DANE is not about telling people which certificates or keys to trust, it
> is all about what certificates, keys, security properties clients should NOT
> trust.
>
> That seems directly contrary to all the people who expressed interest in
> Use Cases 3 and 4 in my taxonomy, both of which specify certificates that
> clients SHOULD trust.
>
> --Richard




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

--20cf307abea7fb633304a02f96a7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

The TLS protocol already allows the server to say to the client &#39;here i=
s my certificate, trust it&#39;.<div><br></div><div>What DANE adds is the a=
bility to say &#39;don&#39;t trust a certificate unless it meets criteria X=
&#39;</div>
<div><br></div><div><br></div><div>Which is how I read your two use cases.=
=A0</div><div><br></div><div>OK, so maybe the statement is a little on the =
categorical side. But my point is that we do not need to worry about the li=
mitations of the DNS or DNSSEC to do something that is useful.=A0</div>
<div><br><br><div class=3D"gmail_quote">On Tue, Apr 5, 2011 at 7:48 PM, Ric=
hard L. Barnes <span dir=3D"ltr">&lt;<a href=3D"mailto:[e-mail]">rba=
[e-mail]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">&gt; DANE is not about telling people which certificates =
or keys to trust, it is all about what certificates, keys, security propert=
ies clients should NOT trust.<br>
<br>
</div>That seems directly contrary to all the people who expressed interest=
 in Use Cases 3 and 4 in my taxonomy, both of which specify certificates th=
at clients SHOULD trust.<br>
<font color=3D"#888888"><br>
--Richard</font></blockquote></div><br><br clear=3D"all"><br>-- <br>Website=
: <a href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--20cf307abea7fb633304a02f96a7--

From [e-mail]  Tue Apr  5 11:31:49 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E9873A68DF for <[e-mail]>; Tue,  5 Apr 2011 11:31:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.176
X-Spam-Level: 
X-Spam-Status: No, score=0.176 tagged_above=-999 required=5 tests=[AWL=0.079,  BAYES_00=-2.599, RCVD_IN_NJABL_RELAY=2.696]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5T3O6reKhHzX for <[e-mail]>; Tue,  5 Apr 2011 11:31:49 -0700 (PDT)
Received: from new.toad.com (new.toad.com [209.237.225.253]) by core3.amsl.com (Postfix) with ESMTP id 256563A6853 for <[e-mail]>; Tue,  5 Apr 2011 11:31:49 -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 p35IXM3W025071; Tue, 5 Apr 2011 11:33:23 -0700
Message-Id: <[e-mail]>
To: Phillip Hallam-Baker <[e-mail]>
In-reply-to: <[e-mail]> 
References: <[e-mail]> <[e-mail]> <[e-mail]>
Comments: In-reply-to Phillip Hallam-Baker <[e-mail]> message dated "Tue, 05 Apr 2011 15:32:32 +0200."
Date: Tue, 05 Apr 2011 11:33:22 -0700
From: John Gilmore <[e-mail]>
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Objective: Restrictive versus Supplementary Models
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2011 18:31:50 -0000

Phillip Hallam-Baker asked:
> Anyone care to argue that mere possession of a DNS domain makes you
> trustworthy?

Anyone care to argue that mere possession of an EV certifying
authority trust anchor's private key makes you trustworthy?

Cryptography cannot enforce trustworthiness.  It can only, at best,
automate the validation of it.  DNSSEC and DANE will not guarantee
that the party you're communicating with won't screw you.  What it
will, in theory, guarantee is that your TCP connection hasn't been
tampered with and that you are actually connecting privately to the
party who registered the domain name you used.  Or to a henchman of
the corrupted domain registar or registry that that name was
registered in.

	John

From [e-mail]  Tue Apr  5 12:08:05 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45FE93A6980 for <[e-mail]>; Tue,  5 Apr 2011 12:08:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.183
X-Spam-Level: 
X-Spam-Status: No, score=-3.183 tagged_above=-999 required=5 tests=[AWL=-0.266, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_MONEYTERMS=0.681]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMAr5bKGd7rK for <[e-mail]>; Tue,  5 Apr 2011 12:08:03 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 58F9E3A6974 for <[e-mail]>; Tue,  5 Apr 2011 12:08:03 -0700 (PDT)
Received: by vws12 with SMTP id 12so681203vws.31 for <[e-mail]>; Tue, 05 Apr 2011 12:09:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+ggDiFuCI3QQa4xvB9pCzTVTQwD3CoFiW4LiVkdvong=; b=RW2sRcDNw40j4kHUKCBKpgvrzW/GpTfwERC4g2V9QI16ITdQPr2OKoZmLPlXmcdHgY 8it/en4vb9yujJ2r2OnYYyzq0wnTtSNZqHUcHiQJSxkfXuGqyUCFRQGK3yaYdpB3NOzr pSamvfQ7BUPug8ijs0tyssjo8J0U9qYfZM5Vo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=a9tgUxw+YLlC2lOulV8M+eJ50f4bBNRZIJBa53NxQKkhMyS11BQpu1E+DyifKRWNLl KwvIabBVsD2bSWjY2kL1g2nM2+F3CWUcd0J6XENTAqwJK2zt8nnV432bD3YROFVqY271 az+wPM+qVNKsppJ9HIjnf1qX7UdoZY5FeEBIc=
MIME-Version: 1.0
Received: by 10.52.65.34 with SMTP id u2mr68767vds.189.1302030586399; Tue, 05 Apr 2011 12:09:46 -0700 (PDT)
Received: by 10.52.166.230 with HTTP; Tue, 5 Apr 2011 12:09:46 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 5 Apr 2011 15:09:46 -0400
Message-ID: <BANLkTikVT0BPGKaC=[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: John Gilmore <[e-mail]>
Content-Type: multipart/alternative; boundary=bcaec501641396cc5304a0309e59
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Objective: Restrictive versus Supplementary Models
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2011 19:08:05 -0000

--bcaec501641396cc5304a0309e59
Content-Type: text/plain; charset=ISO-8859-1

I think you are mistaken here, it depends on what your definition of
'trustworthy' is going to be. These are the definitions I use

Risk = The potential for harm

We quantify Risk through the equation Risk = cost-of-harm *
probability-of-harm
Ideally this should be performed as a summation across all the separate
types of risk or treat cost and probability as continuous variables.


Trust = confidence that risk has been adequately mitigated.

Since our possible actions are often limited, we typically end up treating
trust as a binary quantity, we either trust or do not. But in the general
case there may be degrees of trust.

I put my money in the bank because I see the FDIC sticker and conclude that
the risk of loss through bankruptcy is quite low.


Trusted = Something that is relied on

Trusted computing misses the point because almost all computers are trusted
to a far greater degree than they deserve.


Trustworthy = Something that is relied on because it meets the relying
party's criteria for trust.


Thus if I know that the DNS name of my bank is anybank.com, a DNS only
assurance may be sufficient to consider it trustworthy. Verifying my bank is
quite easy, verifying a random bank that I do not have a prior relationship
with is rather harder for me. So I want them to do rather more to prove that
they are trustworthy.


On Tue, Apr 5, 2011 at 2:33 PM, John Gilmore <[e-mail]> wrote:

> Phillip Hallam-Baker asked:
> > Anyone care to argue that mere possession of a DNS domain makes you
> > trustworthy?
>
> Anyone care to argue that mere possession of an EV certifying
> authority trust anchor's private key makes you trustworthy?
>
> Cryptography cannot enforce trustworthiness.  It can only, at best,
> automate the validation of it.  DNSSEC and DANE will not guarantee
> that the party you're communicating with won't screw you.  What it
> will, in theory, guarantee is that your TCP connection hasn't been
> tampered with and that you are actually connecting privately to the
> party who registered the domain name you used.  Or to a henchman of
> the corrupted domain registar or registry that that name was
> registered in.
>
>        John
>



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

--bcaec501641396cc5304a0309e59
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I think you are mistaken here, it depends on what your definition of &#39;t=
rustworthy&#39; is going to be. These are the definitions I use<div><br></d=
iv><div>Risk =3D The potential for harm</div><div><br></div><div>We quantif=
y Risk through the equation Risk =3D cost-of-harm * probability-of-harm</di=
v>
<div>Ideally this should be performed as a summation across all the separat=
e types of risk or treat cost and probability as continuous variables.</div=
><div><br></div><div><br></div><div>Trust =3D confidence that risk has been=
 adequately mitigated.</div>
<div><br></div><div>Since our possible actions are often limited, we typica=
lly end up treating trust as a binary quantity, we either trust or do not. =
But in the general case there may be degrees of trust.=A0</div><div><br></d=
iv>
<div>I put my money in the bank because I see the FDIC sticker and conclude=
 that the risk of loss through bankruptcy is quite low.</div><div><br></div=
><div><br></div><div>Trusted =3D Something that is relied on</div><div><br>
</div><div>Trusted computing misses the point because almost all computers =
are trusted to a far greater degree than they deserve.</div><div><br></div>=
<div><br></div><div>Trustworthy =3D Something that is relied on because it =
meets the relying party&#39;s criteria for trust.</div>
<div><br></div><div><br></div><div>Thus if I know that the DNS name of my b=
ank is <a href=3D"http://anybank.com">anybank.com</a>, a DNS only assurance=
 may be sufficient to consider it trustworthy. Verifying my bank is quite e=
asy, verifying a random bank that I do not have a prior relationship with i=
s rather harder for me. So I want them to do rather more to prove that they=
 are trustworthy.</div>
<div><br><div><br><div class=3D"gmail_quote">On Tue, Apr 5, 2011 at 2:33 PM=
, John Gilmore <span dir=3D"ltr">&lt;<a href=3D"mailto:[e-mail]">gnu@to=
ad.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Phillip Hallam-Baker asked:<br>
<div class=3D"im">&gt; Anyone care to argue that mere possession of a DNS d=
omain makes you<br>
&gt; trustworthy?<br>
<br>
</div>Anyone care to argue that mere possession of an EV certifying<br>
authority trust anchor&#39;s private key makes you trustworthy?<br>
<br>
Cryptography cannot enforce trustworthiness. =A0It can only, at best,<br>
automate the validation of it. =A0DNSSEC and DANE will not guarantee<br>
that the party you&#39;re communicating with won&#39;t screw you. =A0What i=
t<br>
will, in theory, guarantee is that your TCP connection hasn&#39;t been<br>
tampered with and that you are actually connecting privately to the<br>
party who registered the domain name you used. =A0Or to a henchman of<br>
the corrupted domain registar or registry that that name was<br>
registered in.<br>
<font color=3D"#888888"><br>
 =A0 =A0 =A0 =A0John<br>
</font></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a href=
=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div></div>

--bcaec501641396cc5304a0309e59--

From [e-mail]  Tue Apr  5 15:26:03 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A25263A67F3 for <[e-mail]>; Tue,  5 Apr 2011 15:26:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.007
X-Spam-Level: 
X-Spam-Status: No, score=-2.007 tagged_above=-999 required=5 tests=[AWL=0.593,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scsoRuVocfn7 for <[e-mail]>; Tue,  5 Apr 2011 15:26:02 -0700 (PDT)
Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by core3.amsl.com (Postfix) with ESMTP id 18C493A66B4 for <[e-mail]>; Tue,  5 Apr 2011 15:26:02 -0700 (PDT)
Received: by eagle.jhcloos.com (Postfix, from userid 10) id 5FE2540120; Tue,  5 Apr 2011 22:27:20 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1302042464; bh=+9CXS653/sNr1TrpdsDyNZEvkr4JXB0nf9qmTV8Thy0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=IPbFfNMx8P1qapYp/3o4p2xmB9Fis1RIB4CfIqRBNe71bT8F/JtwUkVxDIN/nbVH9 xyijA9beU1bTz9OiDFUMhBKRKUMfn5+gvELhvoO1I5EIBFutIUTsepyaL1kdu/oMMn HYMj1HSVbMpSHrFdBWSnryUiuNoXHEgifCS81BtA=
Received: by carbon.jhcloos.org (Postfix, from userid 500) id 1602B260042; Tue,  5 Apr 2011 22:22:18 +0000 (UTC)
From: James Cloos <[e-mail]>
To: [e-mail]
In-Reply-To: <[e-mail]> (Paul Hoffman's message of "Tue, 5 Apr 2011 05:19:33 -0700")
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Gnus/5.110016 (No Gnus v0.16) Emacs/24.0.50 (gnu/linux)
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC
Copyright: Copyright 2011 James Cloos
OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc
OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6
Date: Tue, 05 Apr 2011 18:22:18 -0400
Message-ID: <[e-mail]>
Lines: 21
MIME-Version: 1.0
Content-Type: text/plain
X-Hashcash: 1:30:110405:[e-mail]::eCYVHyKOFh5+3acF:000B70/Q
X-Hashcash: 1:30:110405:[e-mail]::1NKQn4bPxzVECMk8:000000000000000000000000000000000000000DEsXU
X-Hashcash: 1:30:110405:[e-mail]::8QcPq4HAQcJxisu2:0XEgPW
Cc: Paul Hoffman <[e-mail]>
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2011 22:26:03 -0000

>>>>> "PH" == Paul Hoffman <[e-mail]> writes:

PH> That's not a "technical point", it is a fundamental feature. With #3,
PH> #4 becomes pretty irrelevant and implementers have fewer different
PH> semantics to deal with.

Case 4 still has the advantages that it is easier, has fewer nodes in the
graph and therefore fewer place to fail, etc.

It is simply more likely that end users will grok it and, therefore, use it.

Correctly, even.

For those of us who understand how it works and for those who employ
someone who understands how it works, case 3 has some benefits.

But more most people case 4 is better.

-JimC
-- 
James Cloos <[e-mail]>         OpenPGP: 1024D/ED7DAEA6

From [e-mail]  Tue Apr  5 16:13:31 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99F1A28C165 for <[e-mail]>; Tue,  5 Apr 2011 16:13:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.076
X-Spam-Level: 
X-Spam-Status: No, score=-102.076 tagged_above=-999 required=5 tests=[AWL=0.523, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6SjrjgMuGNH for <[e-mail]>; Tue,  5 Apr 2011 16:13:31 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by core3.amsl.com (Postfix) with ESMTP id 332BD28C15C for <[e-mail]>; Tue,  5 Apr 2011 16:13:24 -0700 (PDT)
Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p35NElSf073305 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Apr 2011 16:14:48 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Paul Hoffman <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Tue, 5 Apr 2011 16:14:47 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
To: James Cloos <[e-mail]>
X-Mailer: Apple Mail (2.1084)
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2011 23:13:31 -0000

On Apr 5, 2011, at 3:22 PM, James Cloos wrote:

>>>>>> "PH" =3D=3D Paul Hoffman <[e-mail]> writes:
>=20
> PH> That's not a "technical point", it is a fundamental feature. With =
#3,
> PH> #4 becomes pretty irrelevant and implementers have fewer different
> PH> semantics to deal with.
>=20
> Case 4 still has the advantages that it is easier, has fewer nodes in =
the
> graph and therefore fewer place to fail, etc.
>=20
> It is simply more likely that end users will grok it and, therefore, =
use it.
>=20
> Correctly, even.
>=20
> For those of us who understand how it works and for those who employ
> someone who understands how it works, case 3 has some benefits.
>=20
> But more most people case 4 is better.


Given that we are trying to capture use cases and requirements, can you =
cast your message as one or both of those?

--Paul Hoffman


From [e-mail]  Tue Apr  5 16:32:02 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A63893A69A1 for <[e-mail]>; Tue,  5 Apr 2011 16:32:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.521
X-Spam-Level: 
X-Spam-Status: No, score=-3.521 tagged_above=-999 required=5 tests=[AWL=0.077,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YbyQ7ZHJUYm1 for <[e-mail]>; Tue,  5 Apr 2011 16:32:01 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id AB2463A698E for <[e-mail]>; Tue,  5 Apr 2011 16:32:01 -0700 (PDT)
Received: by vws12 with SMTP id 12so881303vws.31 for <[e-mail]>; Tue, 05 Apr 2011 16:33:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=2ukyVFDGSyKYq1MDPSynyu+8i5S+26Tsumszq4Yv//Y=; b=CG2GUzZ+i+Ax69podBlCDOJyh+vTuamsFbpwdCxaXqBgbMlE2V+xR8TZFtfAmw5Lij 1UhIwbP/0L/Elztl59Z1Z0z9fDCMXpsyYPbLGrZ/jS5AU1XbdS+eCh9ZE+7C63oaZtBs 4t6zTw9+t4q3M7ucXpWr/nHi/HtQSZk63/VcE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=IUZGK7MYpsRJJFiJv4aVDHoxPqQNYtVpoyS0I5fPzMG4bg9IKRcC96937Kgww88w2x iK2YNpfpWe7LiO6KfEcNwV59HBgmYbMuX8etqYBTGvif2VdUGtayhzb8x3JWI9aG/nUC /pw5WhCR8yWt/9seUnWTIxqed7S6E7bJMVO4A=
MIME-Version: 1.0
Received: by 10.52.65.52 with SMTP id u20mr375991vds.309.1302046424903; Tue, 05 Apr 2011 16:33:44 -0700 (PDT)
Received: by 10.52.166.230 with HTTP; Tue, 5 Apr 2011 16:33:44 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 5 Apr 2011 23:33:44 +0000
Message-ID: <BANLkTi=[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: [e-mail]
Content-Type: multipart/alternative; boundary=bcaec50166a5a32f1a04a0344e7c
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2011 23:32:02 -0000

--bcaec50166a5a32f1a04a0344e7c
Content-Type: text/plain; charset=ISO-8859-1

OK, as promised at the WG meeting, here is a first cut at a requirements
document based on the use cases and requirements analysis that I have done
to support my earlier proposals in this area.

I have cut down the original documents to make this more manageable. What I
have not done (yet) is to draw up the correspondance matrices that link the
use cases to the requirements and so on. Nor have I got the links in
hypertext form.

The idea is that each use case should list the requirements it motivates and
vice versa. Every requirement should be driven by at least one use case.

What I have not quite worked out at this point is how to make use of the
attacker model to derive requirements from the use cases. Part of the point
of specifying the attacker profiles is that a proposal should not get credit
for blocking an attack A1 that allows attacker X to have effect Y if the
same attacker can realize Y through attack A2 that is also in their
capabilities.

http://www.ietf.org/id/draft-hallambaker-dane-requirements-00.txt


I have put this in as a personal submission so as not to pre-empt the WG
decision. But am quite happy if the WG wants to adopt it.

Its also missing an acknowledgements section, many of these use cases were
captured during our earlier arguments on the list.

Phill

--bcaec50166a5a32f1a04a0344e7c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>OK, as promised at the WG meeting, here is a first cut at a requiremen=
ts document based on the use cases and requirements analysis that I have do=
ne to support my earlier proposals in this area.</div><div><br></div><div>
I have cut down the original documents to make this more manageable. What I=
 have not done (yet) is to draw up the correspondance matrices that link th=
e use cases to the requirements and so on. Nor have I got the links in hype=
rtext form.</div>
<div><br></div><div>The idea is that each use case should list the requirem=
ents it motivates and vice versa. Every requirement should be driven by at =
least one use case.</div><div><br></div><div>What I have not quite worked o=
ut at this point is how to make use of the attacker model to derive require=
ments from the use cases. Part of the point of specifying the attacker prof=
iles is that a proposal should not get credit for blocking an attack A1 tha=
t allows attacker X to have effect Y if the same attacker can realize Y thr=
ough attack A2 that is also in their capabilities.=A0</div>
<div><br></div><a href=3D"http://www.ietf.org/id/draft-hallambaker-dane-req=
uirements-00.txt">http://www.ietf.org/id/draft-hallambaker-dane-requirement=
s-00.txt</a>
<div><br></div><div><br></div><div>I have put this in as a personal submiss=
ion so as not to pre-empt the WG decision. But am quite happy if the WG wan=
ts to adopt it.<br><br></div><div>Its also missing an acknowledgements sect=
ion, many of these use cases were captured during our earlier arguments on =
the list.</div>
<div><br></div><div>Phill</div>

--bcaec50166a5a32f1a04a0344e7c--

From [e-mail]  Wed Apr  6 04:54:53 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39F0C3A691F for <[e-mail]>; Wed,  6 Apr 2011 04:54:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.142
X-Spam-Level: 
X-Spam-Status: No, score=-2.142 tagged_above=-999 required=5 tests=[AWL=0.107,  BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3CGw6DEwuHQ for <[e-mail]>; Wed,  6 Apr 2011 04:54:52 -0700 (PDT)
Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id 329353A690F for <[e-mail]>; Wed,  6 Apr 2011 04:54:50 -0700 (PDT)
Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1Q7RLc-00078M-Kt; Wed, 06 Apr 2011 11:56:32 +0000
Received: by bfk.de with local id 1Q7RLc-0007vj-I3; Wed, 06 Apr 2011 11:56:32 +0000
To: Paul Wouters <[e-mail]>
References: <[e-mail]> <[e-mail]> <1302012455.3356.7.camel@localhost> <[e-mail]>
From: Florian Weimer <[e-mail]>
Date: Wed, 06 Apr 2011 11:56:32 +0000
In-Reply-To: <[e-mail]> (Paul Wouters's message of "Tue\, 5 Apr 2011 12\:42\:20 -0400 \(EDT\)")
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: [e-mail]
Subject: Re: [dane] browser UI out of scope
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 06 Apr 2011 11:54:53 -0000

* Paul Wouters:

> This working group is designing a protocol, not a web browser UI. I
> suggest we focus on the protocol design, and not get lost in
> padlocks, green bars, blue badges or what not.

Oh, could you please clarify what you mean by this: Do you want to
design a protocol, without consideration for the UI side?  Or do you
want to design a protocol which does not require UI changes?  Or
something else entirely?

--=20
Florian Weimer                <[e-mail]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstra=DFe 100              tel: [phone]
D-76133 Karlsruhe             fax: [phone]

From [e-mail]  Wed Apr  6 05:03:34 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 693AE3A691F for <[e-mail]>; Wed,  6 Apr 2011 05:03:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.579
X-Spam-Level: 
X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Cg8TPvCn4Th for <[e-mail]>; Wed,  6 Apr 2011 05:03:33 -0700 (PDT)
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id C0E4F3A690F for <[e-mail]>; Wed,  6 Apr 2011 05:03:33 -0700 (PDT)
Received: from shinkuro.com (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 2F81E1ECB41D for <[e-mail]>; Wed,  6 Apr 2011 12:05:17 +0000 (UTC)
Date: Wed, 6 Apr 2011 08:05:15 -0400
From: Andrew Sullivan <[e-mail]>
To: [e-mail]
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <1302012455.3356.7.camel@localhost> <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [dane] browser UI out of scope
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 06 Apr 2011 12:03:34 -0000

On Wed, Apr 06, 2011 at 11:56:32AM +0000, Florian Weimer wrote:
> Oh, could you please clarify what you mean by this: Do you want to
> design a protocol, without consideration for the UI side?  Or do you
> want to design a protocol which does not require UI changes?  Or
> something else entirely?

What UI side?

I agree, wholeheartedly, that there is a UI problem here, that it
needs attention, and that just about anything would be better than the
miserable UIs that marked most of the history of SSL/TLS.  I don't
believe anyone is contesting that.

But the problem we are engaged in solving is how to communicate the
availability of certain facilities (and maybe the preferability of
thos facilities) via the DNS.  If the same communication came by
carrier pigeon, smoke signal, telegraph, or slips of paper handed
around by neighbours, there would be a UI problem.  That UI problem is
entirely separable from the problem of the underlying messages.

So, I say that those who think there is a special UI problem that
needs to be solved here, and by this group of people (a group not, as
nearly as I can tell, instantiating a great load of special UI
expertise), need to present an argument about what is special for the
UI in this case and what particular details need to be available from
the underlying layer.  Otherwise, I claim the talk of UI issues is
just hand waving, and I ask the chairs to declare it out of scope.

A

-- 
Andrew Sullivan
[e-mail]
Shinkuro, Inc.

From [e-mail]  Wed Apr  6 05:24:26 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06BFC3A6925 for <[e-mail]>; Wed,  6 Apr 2011 05:24:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.086
X-Spam-Level: 
X-Spam-Status: No, score=-102.086 tagged_above=-999 required=5 tests=[AWL=0.513, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IzLnLfhFpoqj for <[e-mail]>; Wed,  6 Apr 2011 05:24:25 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by core3.amsl.com (Postfix) with ESMTP id E00BF3A6921 for <[e-mail]>; Wed,  6 Apr 2011 05:24:24 -0700 (PDT)
Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p36CQ2cX006500 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 6 Apr 2011 05:26:03 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Paul Hoffman <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Wed, 6 Apr 2011 05:26:02 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <1302012455.3356.7.camel@localhost> <[e-mail]> <[e-mail]>
To: Florian Weimer <[e-mail]>
X-Mailer: Apple Mail (2.1084)
Cc: [e-mail]
Subject: Re: [dane] browser UI out of scope
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 06 Apr 2011 12:24:26 -0000

On Apr 6, 2011, at 4:56 AM, Florian Weimer wrote:

> * Paul Wouters:
>=20
>> This working group is designing a protocol, not a web browser UI. I
>> suggest we focus on the protocol design, and not get lost in
>> padlocks, green bars, blue badges or what not.
>=20
> Oh, could you please clarify what you mean by this: Do you want to
> design a protocol, without consideration for the UI side?  Or do you
> want to design a protocol which does not require UI changes?  Or
> something else entirely?

Speaking for myself: the first. TLSA applies to TLS, not "TLS but only =
in a web browser". This is completely clear in the document. There is no =
equivalent of a "lock icon" when a mail program downloads mail using =
IMAP or POP using TLS, and this is the wrong place to say that there =
should be (more than a decade later...). Similarly, many TLS-using =
scenarios involve clients and servers with no humans watching.

--Paul Hoffman


From [e-mail]  Wed Apr  6 05:57:15 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45A523A694D for <[e-mail]>; Wed,  6 Apr 2011 05:57:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.522
X-Spam-Level: 
X-Spam-Status: No, score=-3.522 tagged_above=-999 required=5 tests=[AWL=0.076,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jEmwNnOJDTAA for <[e-mail]>; Wed,  6 Apr 2011 05:57:13 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 683923A6938 for <[e-mail]>; Wed,  6 Apr 2011 05:57:13 -0700 (PDT)
Received: by vws12 with SMTP id 12so1317953vws.31 for <[e-mail]>; Wed, 06 Apr 2011 05:58:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=DXNhNWf1K/XRttQtjApe3/eO+JszGt/Kr/f92vXKHPw=; b=v+tueZ5GhXzFREbpfVoqFO9RjAiUL+WIB9Bry6ziepOXWyl7pS233GMmZMnNGc+FZm rfmJdzj9QOi8eXNKVIfR8QAaXPHafCZ1+7xzNtBEfdO+fXsc11RkboE5RWbMqexnBFhp hvE+WQ9BA3FJp00hXKZcBxehzsMirZSG7LsDo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=TkltryuC+Gu+nQLW40lPxaG2/XrRBmfTbY3XgFmSiy0YuqcIJ4dD5n7DlupkBYTmZB uDSIsI7stLDio7fUX2fYVJRAb0yrcEZJ5iovHXjPfipCWNiNXQcjWli9mV3/QtkHOG3f sUGighW5W7ycURpIwTfy17UdT+usuv05S5xO4=
MIME-Version: 1.0
Received: by 10.52.98.135 with SMTP id ei7mr1328317vdb.229.1302094735651; Wed, 06 Apr 2011 05:58:55 -0700 (PDT)
Received: by 10.52.166.230 with HTTP; Wed, 6 Apr 2011 05:58:55 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <1302012455.3356.7.camel@localhost> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 6 Apr 2011 12:58:55 +0000
Message-ID: <BANLkTimf51GUou17atuLkA9Z8t=kk=[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: Andrew Sullivan <[e-mail]>
Content-Type: multipart/alternative; boundary=20cf307cfc682eb2a004a03f8e53
Cc: [e-mail]
Subject: Re: [dane] browser UI out of scope
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 06 Apr 2011 12:57:15 -0000

--20cf307cfc682eb2a004a03f8e53
Content-Type: text/plain; charset=ISO-8859-1

I am quite happy to rule UI issues out of scope, PROVIDED that we also ban
any proposal that depends on UI.

If people are going to propose schemes that depend on UI, then they have to
demonstrate that they understand the UI issues involved. Ruling an issue
area out of scope does not mean that it can be regarded as magic pixie dust.

Not understanding an issue is not a reason to rule it out of scope. the
people who want to design protocols that depend on what they admit do not
understand are what we should rule out of scope.


There is indeed quite a bit of literature on the topic. In my view this
means that people who want to design security protocols must read it. At a
minimum people who want to design protocols with UI implications need to
talk to the people involved.

For years security people complained that nobody bothered to consider their
issues, security was an optional extra that was thrown in at the end of the
design process. Now we have security people arguing for the same approach to
UI.

In fact security UI design turns out to be really easy. The user is not
going to respond to UI cues unless (1) they are really intrusive, (2) they
are protecting an asset that the user considers important and (3) are
comprehensible to the user.

The green bar works because those criteria are met. The padlock icon does
not.

The other aspect of security usability is that the people who are
responsible for browser security have very little leverage when it comes to
UI issues. The priority in browser UI design has always been ease of use. If
people want to find out about these issues it is quite easy, they just need
to talk to the people involved.


The padlock icon only exists in current generation browsers because it is
grandfathered. Domain Validated keys should be ubiquitous and should
therefore require no security signal.

It is quite easy to design a DANE scheme that does not depend on the padlock
icon. Just design the protocol so that a client can determine that TLS is
offered. This allows the client to take over the job of checking for channel
security from the user. The user is only involved then when there is a
requirement to verify accountability.


On Wed, Apr 6, 2011 at 12:05 PM, Andrew Sullivan <[e-mail]> wrote:

> On Wed, Apr 06, 2011 at 11:56:32AM +0000, Florian Weimer wrote:
> > Oh, could you please clarify what you mean by this: Do you want to
> > design a protocol, without consideration for the UI side?  Or do you
> > want to design a protocol which does not require UI changes?  Or
> > something else entirely?
>
> What UI side?
>
> I agree, wholeheartedly, that there is a UI problem here, that it
> needs attention, and that just about anything would be better than the
> miserable UIs that marked most of the history of SSL/TLS.  I don't
> believe anyone is contesting that.
>
> But the problem we are engaged in solving is how to communicate the
> availability of certain facilities (and maybe the preferability of
> thos facilities) via the DNS.  If the same communication came by
> carrier pigeon, smoke signal, telegraph, or slips of paper handed
> around by neighbours, there would be a UI problem.  That UI problem is
> entirely separable from the problem of the underlying messages.
>
> So, I say that those who think there is a special UI problem that
> needs to be solved here, and by this group of people (a group not, as
> nearly as I can tell, instantiating a great load of special UI
> expertise), need to present an argument about what is special for the
> UI in this case and what particular details need to be available from
> the underlying layer.  Otherwise, I claim the talk of UI issues is
> just hand waving, and I ask the chairs to declare it out of scope.
>
> A
>
> --
> Andrew Sullivan
> [e-mail]
> Shinkuro, Inc.
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane
>



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

--20cf307cfc682eb2a004a03f8e53
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I am quite happy to rule UI issues out of scope, PROVIDED that we also ban =
any proposal that depends on UI.<div><br></div><div>If people are going to =
propose schemes that depend on UI, then they have to demonstrate that they =
understand the UI issues involved. Ruling an issue area out of scope does n=
ot mean that it can be regarded as magic pixie dust.</div>
<div><br></div><div>Not understanding an issue is not a reason to rule it o=
ut of scope. the people who want to design protocols that depend on what th=
ey admit do not understand are what we should rule out of scope.</div><div>
<br></div><div><br></div><div>There is indeed quite a bit of literature on =
the topic. In my view this means that people who want to design security pr=
otocols must read it. At a minimum people who want to design protocols with=
 UI implications need to talk to the people involved.</div>
<div><br></div><div>For years security people complained that nobody bother=
ed to consider their issues, security was an optional extra that was thrown=
 in at the end of the design process. Now we have security people arguing f=
or the same approach to UI.=A0</div>
<div><br></div><div>In fact security UI design turns out to be really easy.=
 The user is not going to respond to UI cues unless (1) they are really int=
rusive, (2) they are protecting an asset that the user considers important =
and (3) are comprehensible to the user.</div>
<div><br></div><div>The green bar works because those criteria are met. The=
 padlock icon does not.</div><div><br></div><div>The other aspect of securi=
ty usability is that the people who are responsible for browser security ha=
ve very little leverage when it comes to UI issues. The priority in browser=
 UI design has always been ease of use. If people want to find out about th=
ese issues it is quite easy, they just need to talk to the people involved.=
</div>
<div><br></div><div><div><br></div><div>The padlock icon only exists in cur=
rent generation browsers because it is grandfathered. Domain Validated keys=
 should be ubiquitous and should therefore require no security signal.</div=
>
<div><br></div><div>It is quite easy to design a DANE scheme that does not =
depend on the padlock icon. Just design the protocol so that a client can d=
etermine that TLS is offered. This allows the client to take over the job o=
f checking for channel security from the user. The user is only involved th=
en when there is a requirement to verify accountability.</div>
<div><br></div><div><br><div class=3D"gmail_quote">On Wed, Apr 6, 2011 at 1=
2:05 PM, Andrew Sullivan <span dir=3D"ltr">&lt;<a href=3D"mailto:ajs@shinku=
ro.com">[e-mail]</a>&gt;</span> wrote:<br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex;">
<div class=3D"im">On Wed, Apr 06, 2011 at 11:56:32AM +0000, Florian Weimer =
wrote:<br>
&gt; Oh, could you please clarify what you mean by this: Do you want to<br>
&gt; design a protocol, without consideration for the UI side? =A0Or do you=
<br>
&gt; want to design a protocol which does not require UI changes? =A0Or<br>
&gt; something else entirely?<br>
<br>
</div>What UI side?<br>
<br>
I agree, wholeheartedly, that there is a UI problem here, that it<br>
needs attention, and that just about anything would be better than the<br>
miserable UIs that marked most of the history of SSL/TLS. =A0I don&#39;t<br=
>
believe anyone is contesting that.<br>
<br>
But the problem we are engaged in solving is how to communicate the<br>
availability of certain facilities (and maybe the preferability of<br>
thos facilities) via the DNS. =A0If the same communication came by<br>
carrier pigeon, smoke signal, telegraph, or slips of paper handed<br>
around by neighbours, there would be a UI problem. =A0That UI problem is<br=
>
entirely separable from the problem of the underlying messages.<br>
<br>
So, I say that those who think there is a special UI problem that<br>
needs to be solved here, and by this group of people (a group not, as<br>
nearly as I can tell, instantiating a great load of special UI<br>
expertise), need to present an argument about what is special for the<br>
UI in this case and what particular details need to be available from<br>
the underlying layer. =A0Otherwise, I claim the talk of UI issues is<br>
just hand waving, and I ask the chairs to declare it out of scope.<br>
<br>
A<br>
<font color=3D"#888888"><br>
--<br>
Andrew Sullivan<br>
<a href=3D"mailto:[e-mail]">[e-mail]</a><br>
Shinkuro, Inc.<br>
</font><div><div></div><div class=3D"h5">__________________________________=
_____________<br>
dane mailing list<br>
<a href=3D"mailto:[e-mail]">[e-mail]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/dane</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a=
 href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div></div>

--20cf307cfc682eb2a004a03f8e53--

From [e-mail]  Wed Apr  6 06:06:24 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21C1828C0EA for <[e-mail]>; Wed,  6 Apr 2011 06:06:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.523
X-Spam-Level: 
X-Spam-Status: No, score=-3.523 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-uvxE3FDMb2 for <[e-mail]>; Wed,  6 Apr 2011 06:06:23 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id BBE6D28C0DD for <[e-mail]>; Wed,  6 Apr 2011 06:06:22 -0700 (PDT)
Received: by vws12 with SMTP id 12so1327296vws.31 for <[e-mail]>; Wed, 06 Apr 2011 06:08:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9Iw55zf5Xh6XSBpWSsKbWjIT54wZ0SBZ288RJLP0854=; b=iLEtPug6BKTzsL2dxHlOOJ3FAy3Nruu/czAfZB+LKHPUs7fb1LlG2+dEE28tLrl0Ib n+901tds1gozNzi8sqpHQ1fTuMySKYlaSdvpXsdz79bJk1RVJmWEZ7AmchsKtx/ZMA/0 ChNyoFCgGQkrrL/dnutTUH3QbOvmo0MbWg6ZQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=EXTdFLENSq/LBSt94yp37PgUh//GvenYJHLuL4nsWRZiRpwfA3ozz302VClVigTGFz 57+ac0Hvix+9uG/3XtNZZ7Kc1ub7X+gSSGIdrNT+A1sCQTEu/7FN0XZFQ65IFzmDPrOT FPd894aJoeMnqpZf8eVtlyYiJvhnTvmvexksE=
MIME-Version: 1.0
Received: by 10.52.18.11 with SMTP id s11mr30529vdd.269.1302095286330; Wed, 06 Apr 2011 06:08:06 -0700 (PDT)
Received: by 10.52.166.230 with HTTP; Wed, 6 Apr 2011 06:08:06 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <1302012455.3356.7.camel@localhost> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 6 Apr 2011 13:08:06 +0000
Message-ID: <BANLkTi=[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: Paul Hoffman <[e-mail]>
Content-Type: multipart/alternative; boundary=20cf3054a1130165ba04a03faf61
Cc: [e-mail]
Subject: Re: [dane] browser UI out of scope
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 06 Apr 2011 13:06:24 -0000

--20cf3054a1130165ba04a03faf61
Content-Type: text/plain; charset=ISO-8859-1

Paul is exactly right here.

We have to cover cases where there is no UI at all. Including cases where
there is no Human Interaction (HI) because there is no human in the loop.

STARTTLS is a very good example. The mailing list software that supports
this list has to work without any human intervention whatsoever. No human,
no human interaction.


We can approach the problem in stages. For example, we could decide to
design a RR that is extensible so that we can first address the requirement
for Domain Validated keys and after that is done address the requirement for
verifying that TLS is used to secure the connection.


On Wed, Apr 6, 2011 at 12:26 PM, Paul Hoffman <[e-mail]> wrote:

> On Apr 6, 2011, at 4:56 AM, Florian Weimer wrote:
>
> > * Paul Wouters:
> >
> >> This working group is designing a protocol, not a web browser UI. I
> >> suggest we focus on the protocol design, and not get lost in
> >> padlocks, green bars, blue badges or what not.
> >
> > Oh, could you please clarify what you mean by this: Do you want to
> > design a protocol, without consideration for the UI side?  Or do you
> > want to design a protocol which does not require UI changes?  Or
> > something else entirely?
>
> Speaking for myself: the first. TLSA applies to TLS, not "TLS but only in a
> web browser". This is completely clear in the document. There is no
> equivalent of a "lock icon" when a mail program downloads mail using IMAP or
> POP using TLS, and this is the wrong place to say that there should be (more
> than a decade later...). Similarly, many TLS-using scenarios involve clients
> and servers with no humans watching.
>
> --Paul Hoffman
>
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane
>



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

--20cf3054a1130165ba04a03faf61
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Paul is exactly right here.<div><br></div><div>We have to cover cases where=
 there is no UI at all. Including cases where there is no Human Interaction=
 (HI) because there is no human in the loop.</div><div><br></div><div>START=
TLS is a very good example. The mailing list software that supports this li=
st has to work without any human intervention whatsoever. No human, no huma=
n interaction.</div>
<div><br></div><div><br></div><div>We can approach the problem in stages. F=
or example, we could decide to design a RR that is extensible so that we ca=
n first address the requirement for Domain Validated keys and after that is=
 done address the requirement for verifying that TLS is used to secure the =
connection.</div>
<div><br></div><div><br><div class=3D"gmail_quote">On Wed, Apr 6, 2011 at 1=
2:26 PM, Paul Hoffman <span dir=3D"ltr">&lt;<a href=3D"mailto:paul.hoffman@=
vpnc.org">[e-mail]</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex;">
<div class=3D"im">On Apr 6, 2011, at 4:56 AM, Florian Weimer wrote:<br>
<br>
&gt; * Paul Wouters:<br>
&gt;<br>
&gt;&gt; This working group is designing a protocol, not a web browser UI. =
I<br>
&gt;&gt; suggest we focus on the protocol design, and not get lost in<br>
&gt;&gt; padlocks, green bars, blue badges or what not.<br>
&gt;<br>
&gt; Oh, could you please clarify what you mean by this: Do you want to<br>
&gt; design a protocol, without consideration for the UI side? =A0Or do you=
<br>
&gt; want to design a protocol which does not require UI changes? =A0Or<br>
&gt; something else entirely?<br>
<br>
</div>Speaking for myself: the first. TLSA applies to TLS, not &quot;TLS bu=
t only in a web browser&quot;. This is completely clear in the document. Th=
ere is no equivalent of a &quot;lock icon&quot; when a mail program downloa=
ds mail using IMAP or POP using TLS, and this is the wrong place to say tha=
t there should be (more than a decade later...). Similarly, many TLS-using =
scenarios involve clients and servers with no humans watching.<br>

<font color=3D"#888888"><br>
--Paul Hoffman<br>
</font><div><div></div><div class=3D"h5"><br>
_______________________________________________<br>
dane mailing list<br>
<a href=3D"mailto:[e-mail]">[e-mail]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/dane</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a=
 href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--20cf3054a1130165ba04a03faf61--

From [e-mail]  Wed Apr  6 06:42:57 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF1B03A6937 for <[e-mail]>; Wed,  6 Apr 2011 06:42:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.79
X-Spam-Level: 
X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[AWL=-0.731,  BAYES_00=-2.599, SARE_LWHUGE=1.54]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HG0Pq0ETaVIo for <[e-mail]>; Wed,  6 Apr 2011 06:42:56 -0700 (PDT)
Received: from homiemail-a62.g.dreamhost.com (mx1.spunky.mail.dreamhost.com [208.97.132.47]) by core3.amsl.com (Postfix) with ESMTP id 8DB893A67B2 for <[e-mail]>; Wed,  6 Apr 2011 06:42:56 -0700 (PDT)
Received: from homiemail-a62.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTP id 7E28163407D for <[e-mail]>; Wed,  6 Apr 2011 06:44:40 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:content-type:date:message-id:mime-version: content-transfer-encoding; q=dns; s=mattmccutchen.net; b=hAJwer9 8d1reBgW9ikjCtmXYEJ+pACHPO1xhLo9XnzMmBkUTObTJz3efUzr0B4tFzPRxk7A kQ5YXiTVp8ClkuzBsuhkt5T1H14REPRy/a6tDlfgR7YWR1lBK5hCMqJZBLYmc6Lh GDDJGgUvbqarufCShMaehyrDlRLNam2I++54=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:content-type:date:message-id:mime-version: content-transfer-encoding; s=mattmccutchen.net; bh=YZD3siS+1oaIR Ebz4mIE+16S7W0=; b=BiShRrLYtlR38Msra6EA4Tfu8E8jTkKbKV8Kd5WDxvoJY /tNT1/jLpboNLInr5U7MI6tb9DOi7b8vUmwpHUxavm2zF8owb0eJcs/b2iw+kXMl rl0zyDIpwySUDTVJfagUafvfBThz1vVlk5ETe3rp19L3BAAKDeCRpXvm5hha6g=
Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: [e-mail]) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTPA id 2E362634079 for <[e-mail]>; Wed,  6 Apr 2011 06:44:40 -0700 (PDT)
From: Matt McCutchen <[e-mail]>
To: [e-mail]
Content-Type: text/plain; charset="UTF-8"
Date: Wed, 06 Apr 2011 09:44:38 -0400
Message-ID: <1302097478.3981.8.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.3 
Content-Transfer-Encoding: 7bit
Subject: [dane] Of interest: Mozilla server authentication meeting today, 16-18 UTC
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 06 Apr 2011 13:42:57 -0000

FYI: Mozilla is having a public meeting 16:00-18:00 UTC today to discuss
the future of server authentication for its products:

https://groups.google.com/group/mozilla.dev.security.policy/browse_thread/thread/de464e2c6157f896/4a47f72729953dad#4a47f72729953dad

As you are probably aware, the open-source world tends to follow
Mozilla's lead.  So this could be a huge opportunity to promote better
schemes.  I will most likely join for the second hour.

-- 
Matt


From [e-mail]  Wed Apr  6 07:51:55 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 319FF28C0D8 for <[e-mail]>; Wed,  6 Apr 2011 07:51:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.044
X-Spam-Level: 
X-Spam-Status: No, score=-2.044 tagged_above=-999 required=5 tests=[AWL=0.556,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Tr2CEaNg2in for <[e-mail]>; Wed,  6 Apr 2011 07:51:54 -0700 (PDT)
Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by core3.amsl.com (Postfix) with ESMTP id 1C6083A693D for <[e-mail]>; Wed,  6 Apr 2011 07:51:54 -0700 (PDT)
Received: by eagle.jhcloos.com (Postfix, from userid 10) id 3D10C400B4; Wed,  6 Apr 2011 14:53:13 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1302101617; bh=6lhoEnYQy3yK5J8146OmflLbkniP7pqC0o/KCQ6DCTo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=ECh6gi0b4LZ6gA8An0rmB8K9LSZVlNTQbN7XHWdo3/TEj4DuskPgfhpWts8ZVT3Ey U23upsn5QE0Gb5GAtiWgENTK7aJuenULwzXexWdusEsr64TTQvJ137tFQxLag7Ubzr U9fpEnriU4t0FpWtQUPNpSBpKsas0iZt3eV4sL7w=
Received: by carbon.jhcloos.org (Postfix, from userid 500) id 269B7260047; Wed,  6 Apr 2011 14:38:05 +0000 (UTC)
From: James Cloos <[e-mail]>
To: Paul Hoffman <[e-mail]>
In-Reply-To: <[e-mail]> (Paul Hoffman's message of "Tue, 5 Apr 2011 16:14:47 -0700")
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Gnus/5.110016 (No Gnus v0.16) Emacs/24.0.50 (gnu/linux)
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC
Copyright: Copyright 2011 James Cloos
OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc
OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6
Date: Wed, 06 Apr 2011 10:38:05 -0400
Message-ID: <[e-mail]>
Lines: 37
MIME-Version: 1.0
Content-Type: text/plain
X-Hashcash: 1:30:110406:[e-mail]::23IPghxehyLriIvn:000000000000000000000000000000000000000bAUiz
X-Hashcash: 1:30:110406:[e-mail]::I0CjLCbJUWKEF+Bw:000H5tAv
X-Hashcash: 1:30:110406:[e-mail]::amkneR9Zfh0nIiHa:08c0BW
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 06 Apr 2011 14:51:55 -0000

>>>>> "PH" == Paul Hoffman <[e-mail]> writes:

PH> Given that we are trying to capture use cases and requirements,
PH> can you cast your message as one or both of those?

What exactly do you want?

The point is that, even though specifying a CA cert in the RR /can/
cover the fourth case, the fact that doing so requires that the users:

create a ca
create a private key for each server
create a csr for each server
sign each csr with their ca
append the ca cert to the resulting signed cert
provide the above to said server(s)
specify the ca cert in each dtls rr

rather than the simpler:

create a private key for each server
create a self-signed cert for each server
provide the above to said server(s)
specify said cert in each dtls rr

means that those who don't really understand it all likely will be
put off by the complexity.  And will therefor avoid it.

The simpler version is not only easier, but can be automated
server-by-server (ie, at package install time), doesn't require
securely saving as much state (ie the ca).  Et cetera.

The simpler version is just more likely to happen.

-JimC
-- 
James Cloos <[e-mail]>         OpenPGP: 1024D/ED7DAEA6

From [e-mail]  Wed Apr  6 08:16:39 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A53828C103 for <[e-mail]>; Wed,  6 Apr 2011 08:16:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.097
X-Spam-Level: 
X-Spam-Status: No, score=-102.097 tagged_above=-999 required=5 tests=[AWL=0.502, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YtzRidUkK6kc for <[e-mail]>; Wed,  6 Apr 2011 08:16:38 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by core3.amsl.com (Postfix) with ESMTP id 4B49028C102 for <[e-mail]>; Wed,  6 Apr 2011 08:16:38 -0700 (PDT)
Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p36FIKgd014429 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 6 Apr 2011 08:18:21 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Paul Hoffman <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Wed, 6 Apr 2011 08:18:20 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
To: James Cloos <[e-mail]>
X-Mailer: Apple Mail (2.1084)
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 06 Apr 2011 15:16:39 -0000

On Apr 6, 2011, at 7:38 AM, James Cloos wrote:

>>>>>> "PH" =3D=3D Paul Hoffman <[e-mail]> writes:
>=20
> PH> Given that we are trying to capture use cases and requirements,
> PH> can you cast your message as one or both of those?
>=20
> What exactly do you want?

A list of requirements or use cases that are relevant to you. That's the =
purpose of this thread.

> The point is that, even though specifying a CA cert in the RR /can/
> cover the fourth case, the fact that doing so requires that the users:
>=20
> create a ca
> create a private key for each server
> create a csr for each server
> sign each csr with their ca
> append the ca cert to the resulting signed cert
> provide the above to said server(s)
> specify the ca cert in each dtls rr
>=20
> rather than the simpler:
>=20
> create a private key for each server
> create a self-signed cert for each server
> provide the above to said server(s)
> specify said cert in each dtls rr
>=20
> means that those who don't really understand it all likely will be
> put off by the complexity.  And will therefor avoid it.

That's certainly possible, but given how easy it would be for someone to =
write a very short script that generates both that says at the end =
"here's the text to paste into your BIND file and here's the cert to be =
pointed to in TLS", it is likely that some "who don't really understand =
it all" will still use DANE.=20

> The simpler version is not only easier, but can be automated
> server-by-server (ie, at package install time), doesn't require
> securely saving as much state (ie the ca).  Et cetera.

The CA does not need to be saved securely. In fact, you can delete the =
private key after issuing the end-entity key.

> The simpler version is just more likely to happen.


Not unless someone writes up use cases and/or requirements for it...

--Paul Hoffman


From [e-mail]  Wed Apr  6 08:29:37 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EF6D28C143 for <[e-mail]>; Wed,  6 Apr 2011 08:29:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.566
X-Spam-Level: 
X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PsPWOopdtDyI for <[e-mail]>; Wed,  6 Apr 2011 08:29:36 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 55F0A28C13E for <[e-mail]>; Wed,  6 Apr 2011 08:29:36 -0700 (PDT)
Received: from dhcp89-089-213.bbn.com ([128.89.89.213]:49168) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <[e-mail]>) id 1Q7UhT-000IZ5-2F; Wed, 06 Apr 2011 11:31:19 -0400
Mime-Version: 1.0
Message-Id: <p06240806c9c233991f50@[128.89.89.213]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <1302012455.3356.7.camel@localhost> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 6 Apr 2011 11:13:37 -0400
To: Paul Hoffman <[e-mail]>
From: Stephen Kent <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Cc: [e-mail]
Subject: Re: [dane] browser UI out of scope
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 06 Apr 2011 15:29:37 -0000

At 5:26 AM -0700 4/6/11, Paul Hoffman wrote:
>On Apr 6, 2011, at 4:56 AM, Florian Weimer wrote:
>
>>  * Paul Wouters:
>>
>>>  This working group is designing a protocol, not a web browser UI. I
>>>  suggest we focus on the protocol design, and not get lost in
>>>  padlocks, green bars, blue badges or what not.
>>
>>  Oh, could you please clarify what you mean by this: Do you want to
>>  design a protocol, without consideration for the UI side?  Or do you
>>  want to design a protocol which does not require UI changes?  Or
>>  something else entirely?
>
>Speaking for myself: the first. TLSA applies to TLS, not "TLS but 
>only in a web browser". This is completely clear in the document. 
>There is no equivalent of a "lock icon" when a mail program 
>downloads mail using IMAP or POP using TLS, and this is the wrong 
>place to say that there should be (more than a decade later...). 
>Similarly, many TLS-using scenarios involve clients and servers with 
>no humans watching.
>
>--Paul Hoffman

+1

Steve

From [e-mail]  Wed Apr  6 09:49:13 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F4893A69D8 for <[e-mail]>; Wed,  6 Apr 2011 09:49:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXmXWGtCx-D0 for <[e-mail]>; Wed,  6 Apr 2011 09:48:48 -0700 (PDT)
Received: from fionn.es.net (fionn.es.net [198.128.1.30]) by core3.amsl.com (Postfix) with ESMTP id 2930D28C144 for <[e-mail]>; Wed,  6 Apr 2011 09:48:27 -0700 (PDT)
Received: from fionn.es.net (localhost [127.0.0.1]) by fionn.es.net (8.13.7+Sun/8.13.7) with ESMTP id p36GmCEb003203; Wed, 6 Apr 2011 09:48:12 -0700 (PDT)
Message-Id: <[e-mail]>
To: Phillip Hallam-Baker <[e-mail]>
In-reply-to: Your message of "Wed, 06 Apr 2011 13:08:06 -0000." <BANLkTi=[e-mail]> 
Date: Wed, 06 Apr 2011 09:48:12 -0700
From: Mike Helm <[e-mail]>
Cc: Paul Hoffman <[e-mail]>, [e-mail]
Subject: Re: [dane] browser UI out of scope
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: [e-mail]
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 06 Apr 2011 16:49:13 -0000

Phillip Hallam-Baker writes:
> We have to cover cases where there is no UI at all. Including cases where
> there is no Human Interaction (HI) because there is no human in the loop.

> We can approach the problem in stages. For example, we could decide to
> design a RR that is extensible so that we can first address the requirement
> for Domain Validated keys and after that is done address the requirement for
> verifying that TLS is used to secure the connection.

> On Wed, Apr 6, 2011 at 12:26 PM, Paul Hoffman <[e-mail]> wrote:
> > Speaking for myself: the first. TLSA applies to TLS, not "TLS but only in a
> > web browser". This is completely clear in the document. There is no

There are many usage scenarios that could benefit from broader non-web browser
support and the staged approach sounds like a good direction.  Newer
identity services like SAML-based infrastructure or newer openid and oauth
are highly leveraged on tls and digital signature for security and some
of that traffic is outside browsers.  Grid computing is highly dependent
on messages secured by a tls-like protocol between servers.  Authentication
to wireless providers especially when done over WAN (like Eduroam) is
dependent on TLS and sometimes on specialized credential issuers that
need DANE for other reasons.

Thanks, ==mwh
Michael Helm
ESnet/LBNL

From [e-mail]  Wed Apr  6 11:23:41 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACA0428C10E for <[e-mail]>; Wed,  6 Apr 2011 11:23:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.569
X-Spam-Level: 
X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5SETBhC3O5L for <[e-mail]>; Wed,  6 Apr 2011 11:23:41 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id EE67C28C10D for <[e-mail]>; Wed,  6 Apr 2011 11:23:40 -0700 (PDT)
Received: from dhcp89-089-213.bbn.com ([128.89.89.213]:49178) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <[e-mail]>) id 1Q7XPw-000GpS-QP; Wed, 06 Apr 2011 14:25:25 -0400
Mime-Version: 1.0
Message-Id: <p06240805c9c25b23464a@[128.89.89.213]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 6 Apr 2011 14:24:49 -0400
To: James Cloos <[e-mail]>
From: Stephen Kent <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 06 Apr 2011 18:23:41 -0000

Jim,

I think the steps you cite, while mostly accurate, are not a good
basis of comparison.  let me explain.

When one issues a cert one needs to provide the public key
and the other parameters that go into the cert, and one specifies
a private key that is used to sign the cert. If one uses crypto
primitives (vs. a CA implementation), this procedure should be
the same whether the cert is self-signed or not. The only differences
are the private key used, and some of the bits in the cert contents.

 From that perspective, what one does for a CA-based scenario is:

A. generate a key pair
B. issue a CA cert with the public key from that pair,
	signed by the private key from that pair
C. generate a key pair
D. issue an EE cert for the server using the public key from
	that key pair, signed under the CA's private key
E. put the CA cert in the RR
F. transport the EE cert in the TLS server hello message

For a self-signed cert used as an EE cert (contrary to 5280 specs)
steps C-F are the same. Only steps A+B are additional for the CA
model, and they are the same as steps C+D, modulo the cert contents
and the private key used.

If one has multiple servers, steps A+B are executed just once, so
the CA cert generation overhead is amortized over repetition of steps C+D.

Steve

P.S. I didn't understand your step "append the ca cert to the 
resulting signed cert"

From [e-mail]  Thu Apr  7 01:12:55 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1610028C108 for <[e-mail]>; Thu,  7 Apr 2011 01:12:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.149
X-Spam-Level: 
X-Spam-Status: No, score=0.149 tagged_above=-999 required=5 tests=[AWL=0.052,  BAYES_00=-2.599, RCVD_IN_NJABL_RELAY=2.696]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWjixJsitK2d for <[e-mail]>; Thu,  7 Apr 2011 01:12:54 -0700 (PDT)
Received: from new.toad.com (new.toad.com [209.237.225.253]) by core3.amsl.com (Postfix) with ESMTP id 6DCCF28C105 for <[e-mail]>; Thu,  7 Apr 2011 01:12: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 p378EZ3W007842; Thu, 7 Apr 2011 01:14:35 -0700
Message-Id: <[e-mail]>
To: [e-mail]
In-reply-to: <BANLkTi=[e-mail]> 
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <BANLkTi=[e-mail]>
Comments: In-reply-to Phillip Hallam-Baker <[e-mail]> message dated "Tue, 05 Apr 2011 23:33:44 -0000."
Date: Thu, 07 Apr 2011 01:14:35 -0700
From: John Gilmore <[e-mail]>
Subject: Re: [dane] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 07 Apr 2011 08:12:55 -0000

Thank you, Phillip, for making a first cut at a use-case draft.  However...

One part I don't understand is that this draft comes with a copyright
notice in the very first paragraph, stating that neither modifications
nor derived works may be created.  I.e. nobody can edit this draft
except Phillip.  That appears to mean, according to BCP 78 and the
IETF Trust License Policy (TLP), that we have to start over from
scratch if he declines to "let us" revise it in ways that the
committee chooses.

Given his stance, I recommend that the working group ignore his text
and start over immediately with text written by someone else, rather
than wasting time discussing a useless draft (and perhaps
unconsciously absorbing copyrighted material that, if it appeared in a
later Working Group draft, would give Phillip a copyright claim
against the IETF).  The TLP v4 section 6c (from whence he drew his "no
modifications" text) makes it clear that "an IETF contribution with
such a notice cannot become a Standards Track document or, in most
cases, a working group document."

He said:
> I have put this in as a personal submission so as not to pre-empt the WG
> decision. But am quite happy if the WG wants to adopt it.

The WG *cannot* adopt it - and should not, for reasons beyond the copyright.

One thing I noticed before delving into the copyright and then
abandoning the document is that Phillip wouldn't be very predictable
if he hadn't jiggered the draft so that it's all about the
Certificates.  X.509 certificates.  It's buried right into the
definitions in pages 3 and 4; a "Relying Application" or "Relying
Party" isn't relying on public-key crypto; no, they're relying on a
"Certificate", which is defined as "An X.509 Certificate".

It's all a bit too transparent.

	John



From [e-mail]  Thu Apr  7 01:21:12 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 399C23A68DB for <[e-mail]>; Thu,  7 Apr 2011 01:21:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.147
X-Spam-Level: 
X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[AWL=0.102,  BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36coJXWMdVv8 for <[e-mail]>; Thu,  7 Apr 2011 01:21:10 -0700 (PDT)
Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id 331A93A68C6 for <[e-mail]>; Thu,  7 Apr 2011 01:21:08 -0700 (PDT)
Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1Q7kUN-0008Va-DL; Thu, 07 Apr 2011 08:22:51 +0000
Received: by bfk.de with local id 1Q7kUN-0006lq-8y; Thu, 07 Apr 2011 08:22:51 +0000
To: Paul Hoffman <[e-mail]>
References: <[e-mail]> <[e-mail]> <1302012455.3356.7.camel@localhost> <[e-mail]> <[e-mail]> <[e-mail]>
From: Florian Weimer <[e-mail]>
Date: Thu, 07 Apr 2011 08:22:51 +0000
In-Reply-To: <[e-mail]> (Paul Hoffman's message of "Wed\, 6 Apr 2011 05\:26\:02 -0700")
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: [e-mail]
Subject: Re: [dane] browser UI out of scope
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 07 Apr 2011 08:21:12 -0000

* Paul Hoffman:

>> Oh, could you please clarify what you mean by this: Do you want to
>> design a protocol, without consideration for the UI side?  Or do you
>> want to design a protocol which does not require UI changes?  Or
>> something else entirely?
>
> Speaking for myself: the first. TLSA applies to TLS, not "TLS but
> only in a web browser". This is completely clear in the
> document. There is no equivalent of a "lock icon" when a mail
> program downloads mail using IMAP or POP using TLS,

But mail clients usually have an option "require secure connection".
At some point, someone has to decide whether TLSA provides a secure
connection in the sense of the option.

In a similar fashion, someone needs to determine how TLSA and RFC 2109
interact.  At least this is entirely a protocol question, so you can't
escape it by saying that you don't do UI.  But the answer to this
question indirectly determines the UI aspect, too.

--=20
Florian Weimer                <[e-mail]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstra=DFe 100              tel: [phone]
D-76133 Karlsruhe             fax: [phone]

From [e-mail]  Thu Apr  7 02:00:40 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 505FF3A69DD for <[e-mail]>; Thu,  7 Apr 2011 02:00:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.386
X-Spam-Level: 
X-Spam-Status: No, score=-3.386 tagged_above=-999 required=5 tests=[AWL=0.213,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 410RnB2wS+Oa for <[e-mail]>; Thu,  7 Apr 2011 02:00:36 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 378403A68DF for <[e-mail]>; Thu,  7 Apr 2011 02:00:36 -0700 (PDT)
Received: by bwz13 with SMTP id 13so2073422bwz.31 for <[e-mail]>; Thu, 07 Apr 2011 02:02:20 -0700 (PDT)
Received: by 10.204.25.194 with SMTP id a2mr525056bkc.197.1302166939956; Thu, 07 Apr 2011 02:02:19 -0700 (PDT)
Received: from bblfish.home (ALagny-751-1-3-136.w86-218.abo.wanadoo.fr [86.218.42.136]) by mx.google.com with ESMTPS id x6sm924622bkv.0.2011.04.07.02.02.17 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Apr 2011 02:02:18 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=iso-8859-1
From: Henry Story <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Thu, 7 Apr 2011 11:02:16 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <1302012455.3356.7.camel@localhost> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
To: Florian Weimer <[e-mail]>
X-Mailer: Apple Mail (2.1082)
Cc: Paul Hoffman <[e-mail]>, [e-mail]
Subject: Re: [dane] browser UI out of scope
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 07 Apr 2011 09:00:40 -0000

On 7 Apr 2011, at 10:22, Florian Weimer wrote:

> * Paul Hoffman:
>=20
>>> Oh, could you please clarify what you mean by this: Do you want to
>>> design a protocol, without consideration for the UI side?  Or do you
>>> want to design a protocol which does not require UI changes?  Or
>>> something else entirely?
>>=20
>> Speaking for myself: the first. TLSA applies to TLS, not "TLS but
>> only in a web browser". This is completely clear in the
>> document. There is no equivalent of a "lock icon" when a mail
>> program downloads mail using IMAP or POP using TLS,
>=20
> But mail clients usually have an option "require secure connection".
> At some point, someone has to decide whether TLSA provides a secure
> connection in the sense of the option.
>=20
> In a similar fashion, someone needs to determine how TLSA and RFC 2109
> interact.  At least this is entirely a protocol question, so you can't
> escape it by saying that you don't do UI.  But the answer to this
> question indirectly determines the UI aspect, too.

Sending a message is a UI element - a machine readable UI element if you =
want. Those can then be translate into a number of other formats, or =
languages, such as visual ones with browsers, sound for telephones,... =
The information in the end goes into a database be it a wetware one like =
a brain, or software based one. In any case the hope is that it then =
affects subsequent behavior, though how it will do so will depend on =
policies set.

The bahavior can be completely situation specific. This is what =
behaviorists discovered when they tried  unsuccessfully to reduce mental =
processes to behavior in the middle part of the 20th century. A "warning =
fire" will tell most people to get out of the way, except of course for =
the fireman who will rush in that direction. A "warning lower security" =
will get most people to abort what they are doing, but others will just =
provide false information - a tactic I imagine must have been very =
prevalent in the Soviet Union.

So there is a message, or a number of security messages that can be =
sent, and it is up to apps to later make use of that. How they make use =
of it, is as pointed out above impossible to define in advance without =
taking the precise situation into account.=20

What Dane can provide is a new security message, that is simple to =
implement, that can be widely deployed and that can do a lot to improve =
the previous message.


Henry


>=20
> --=20
> Florian Weimer                <[e-mail]>
> BFK edv-consulting GmbH       http://www.bfk.de/
> Kriegsstra=DFe 100              tel: [phone]
> D-76133 Karlsruhe             fax: [phone]
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane

Social Web Architect
http://bblfish.net/


From [e-mail]  Thu Apr  7 05:04:26 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BCE13A68C1 for <[e-mail]>; Thu,  7 Apr 2011 05:04:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.012
X-Spam-Level: 
X-Spam-Status: No, score=-3.012 tagged_above=-999 required=5 tests=[AWL=-0.414, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TgeX1o9KnGOW for <[e-mail]>; Thu,  7 Apr 2011 05:04:24 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 2037E3A68AC for <[e-mail]>; Thu,  7 Apr 2011 05:04:24 -0700 (PDT)
Received: by vxg33 with SMTP id 33so2250545vxg.31 for <[e-mail]>; Thu, 07 Apr 2011 05:06:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=bbhZDjUE4urOuZnlRQ6VLKUrhlEtxRj6Dq1AfonYRAU=; b=p76XtFi8E1sB8ebi1rThqDY2C2mkWaaoO0gxmqZFDLEMiihHACDMzCGZIyWZWKgGQH hKRcYKvFvp/DNXsaZ+KdgqDqPuQcDqYBey+Xo85yLNLUxTXwSJ5E9ryvH7h4u/bYwvW6 yz5jf41+8hm3cSOpbnnQYMi/hLjBB3EfXhR4k=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=aY3aGL34zI7rQXkm+EqZTZ2p3V1m72rjGv1H/Sv7WpOUejDqficAjnQtRW0KP/VGIV lvu7pblJs3cmifOH9T4ecNFC6Cl7sl1KAT5bFc3Gvppkwi/bqg0WAzGgqAcdUYgtEruw wqEJ396Smx+VppnJPVVrVRN2BZCuvFH2C1sGc=
MIME-Version: 1.0
Received: by 10.52.176.36 with SMTP id cf4mr1157543vdc.29.1302177968316; Thu, 07 Apr 2011 05:06:08 -0700 (PDT)
Received: by 10.52.166.230 with HTTP; Thu, 7 Apr 2011 05:06:08 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <BANLkTi=[e-mail]> <[e-mail]>
Date: Thu, 7 Apr 2011 12:06:08 +0000
Message-ID: <BANLkTi=gy_X+Tkcy-UNKUz=[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: John Gilmore <[e-mail]>
Content-Type: multipart/alternative; boundary=bcaec5171ea73c638a04a052ef7a
Cc: [e-mail]
Subject: Re: [dane] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 07 Apr 2011 12:04:26 -0000

--bcaec5171ea73c638a04a052ef7a
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Apr 7, 2011 at 8:14 AM, John Gilmore <[e-mail]> wrote:

> Thank you, Phillip, for making a first cut at a use-case draft.  However...
>
> One part I don't understand is that this draft comes with a copyright
> notice in the very first paragraph, stating that neither modifications
> nor derived works may be created.  I.e. nobody can edit this draft
> except Phillip.  That appears to mean, according to BCP 78 and the
> IETF Trust License Policy (TLP), that we have to start over from
> scratch if he declines to "let us" revise it in ways that the
> committee chooses.
>

Nah, that is just an oversight.

The reason that I use it on individual submissions is that once in the past
we did the same with the code and specifications for HTTP and HTML. NCSA
then released a new browser where 70% of the code came from CERN but did not
mention CERN, the use of the code or the 'World Wide Web' in any way
whatsoever. As a direct result, CERN management stopped supporting the Web
and I had to move to MIT.

I also had the same thing happen to me on the OCSP draft.


So my default is to use the XML for the non-modifiable license. I can change
that if folk actually care. To be honest, I don't actually read the
boilerplate.

The WG *cannot* adopt it - and should not, for reasons beyond the copyright.
>
> One thing I noticed before delving into the copyright and then
> abandoning the document is that Phillip wouldn't be very predictable
> if he hadn't jiggered the draft so that it's all about the
> Certificates.  X.509 certificates.  It's buried right into the
> definitions in pages 3 and 4; a "Relying Application" or "Relying
> Party" isn't relying on public-key crypto; no, they're relying on a
> "Certificate", which is defined as "An X.509 Certificate".
>

That is because the text for the definitions was copied over from the CAA
draft which is intentionally limited to X.509 because we don't want CAA
properties intended to restrict issue of certs from public CAs to muck up
SAML and/or PGP without actually thinking about it. That does not really
apply here.

I will fix these later on today.

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

--bcaec5171ea73c638a04a052ef7a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Thu, Apr 7, 2011 at 8:14 AM, John Gil=
more <span dir=3D"ltr">&lt;<a href=3D"mailto:[e-mail]">[e-mail]</a>=
&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Thank you, Phillip, for making a first cut at a use-case draft. =A0However.=
..<br>
<br>
One part I don&#39;t understand is that this draft comes with a copyright<b=
r>
notice in the very first paragraph, stating that neither modifications<br>
nor derived works may be created. =A0I.e. nobody can edit this draft<br>
except Phillip. =A0That appears to mean, according to BCP 78 and the<br>
IETF Trust License Policy (TLP), that we have to start over from<br>
scratch if he declines to &quot;let us&quot; revise it in ways that the<br>
committee chooses.<br></blockquote><div><br></div><div>Nah, that is just an=
 oversight.</div><div><br></div><div>The reason that I use it on individual=
 submissions is that once in the past we did the same with the code and spe=
cifications for HTTP and HTML. NCSA then released a new browser where 70% o=
f the code came from CERN but did not mention CERN, the use of the code or =
the &#39;World Wide Web&#39; in any way whatsoever.=A0As a direct result, C=
ERN management stopped supporting the Web and I had to move to MIT.</div>
<div><br></div><div>I also had the same thing happen to me on the OCSP draf=
t.=A0</div><div><br></div><div><br></div><div>So my default is to use the X=
ML for the non-modifiable license. I can change that if folk actually care.=
 To be honest, I don&#39;t actually read the boilerplate.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex;"><div class=3D"im">The WG *ca=
nnot* adopt it - and should not, for reasons beyond the copyright.</div>
<br>
One thing I noticed before delving into the copyright and then<br>
abandoning the document is that Phillip wouldn&#39;t be very predictable<br=
>
if he hadn&#39;t jiggered the draft so that it&#39;s all about the<br>
Certificates. =A0X.509 certificates. =A0It&#39;s buried right into the<br>
definitions in pages 3 and 4; a &quot;Relying Application&quot; or &quot;Re=
lying<br>
Party&quot; isn&#39;t relying on public-key crypto; no, they&#39;re relying=
 on a<br>
&quot;Certificate&quot;, which is defined as &quot;An X.509 Certificate&quo=
t;.<br></blockquote></div><br clear=3D"all">That is because the text for th=
e definitions was copied over from the CAA draft which is intentionally lim=
ited to X.509 because we don&#39;t want CAA properties intended to restrict=
 issue of certs from public CAs to muck up SAML and/or PGP without actually=
 thinking about it. That does not really apply here.<div>
<br></div><div>I will fix these later on today.<br><div><br>-- <br>Website:=
 <a href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div></div>

--bcaec5171ea73c638a04a052ef7a--

From [e-mail]  Thu Apr  7 09:19:08 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 447E528C151 for <[e-mail]>; Thu,  7 Apr 2011 09:19:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.077
X-Spam-Level: 
X-Spam-Status: No, score=-2.077 tagged_above=-999 required=5 tests=[AWL=0.523,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gzc1Rn8JEt0m for <[e-mail]>; Thu,  7 Apr 2011 09:19:07 -0700 (PDT)
Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by core3.amsl.com (Postfix) with ESMTP id 1854728C159 for <[e-mail]>; Thu,  7 Apr 2011 09:19:07 -0700 (PDT)
Received: by eagle.jhcloos.com (Postfix, from userid 10) id 5CE78400F7; Thu,  7 Apr 2011 16:20:26 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1302193250; bh=DxYPFdNaWTfPGh87B3v8YebqqopuOotA3QZ6Ps1coIo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=oYgUVS/QYcZBl0ZMi47yQiYO04KGX09C6S+bZwHXeFWmOavfOl9BZKyVZiCLKvD6m Iv21SMB0O+u+W7jbdzALdSoIDtn6py2fTDmLI/8m2mqVLS+rVu1BtGPygPw0czJjH+ 6dlbmb1OyNsHc4MC582cCzfVyFdg96cmrBOV2i2U=
Received: by carbon.jhcloos.org (Postfix, from userid 500) id F2969260042; Thu,  7 Apr 2011 16:19:16 +0000 (UTC)
From: James Cloos <[e-mail]>
To: Stephen Kent <[e-mail]>
In-Reply-To: <p06240805c9c25b23464a@[128.89.89.213]> (Stephen Kent's message of "Wed\, 6 Apr 2011 14\:24\:49 -0400")
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <p06240805c9c25b23464a@[128.89.89.213]>
User-Agent: Gnus/5.110016 (No Gnus v0.16) Emacs/24.0.50 (gnu/linux)
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC
Copyright: Copyright 2011 James Cloos
OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc
OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6
Date: Thu, 07 Apr 2011 12:19:16 -0400
Message-ID: <[e-mail]>
Lines: 27
MIME-Version: 1.0
Content-Type: text/plain
X-Hashcash: 1:30:110407:[e-mail]::HMRFYJn/yCU1CvFR:0000B/bLa
X-Hashcash: 1:30:110407:[e-mail]::joh64fU9aJNK+W0S:000CVucp
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 07 Apr 2011 16:19:08 -0000

>>>>> "SK" == Stephen Kent <[e-mail]> writes:

SK> I think the steps you cite, while mostly accurate, are not a good
SK> basis of comparison.  let me explain.

I presume that everyone here has done the csr dance enough that a
summary was enough...

SK> P.S. I didn't understand your step "append the ca cert to the
SK> resulting signed cert"

Since the ca cert is only trusted by way of the rr, the server will need
to send the full chain on each new connection.  So the users have to
remember the append the certs together whereever the server expects to
find its cert.

Failure to append was the most common error I encountered with chained certs.

EE certs in the rr is in all of the drafts, was the original target, is
easy to understand and explain, and I've read more consensus for than
against on the list.

Why the sudden backlash against?

-JimC
-- 
James Cloos <[e-mail]>         OpenPGP: 1024D/ED7DAEA6

From [e-mail]  Thu Apr  7 09:49:08 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C69828C15B for <[e-mail]>; Thu,  7 Apr 2011 09:49:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.505
X-Spam-Level: 
X-Spam-Status: No, score=-3.505 tagged_above=-999 required=5 tests=[AWL=0.093,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAFrwkE7BLar for <[e-mail]>; Thu,  7 Apr 2011 09:49:06 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 9AC0128C157 for <[e-mail]>; Thu,  7 Apr 2011 09:49:06 -0700 (PDT)
Received: by vws12 with SMTP id 12so2544973vws.31 for <[e-mail]>; Thu, 07 Apr 2011 09:50:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gRdiFK58zVenvdOtSHyS2+4ze/4yKq3X9nMwL7hc3L0=; b=qnnEIeJLM5WD+Xf8edIr5IpXxqD2jfkoPZj960bFHbIa3ZlJB+D3iH/nWRG5YcgHpk XS8g2E8c5JUDpmHcs58Hd4kWLQi2E5d9cyblA1Fjdx20+EDg+ZusOivcR4hNTmwZElTt keZtKjIXzNPOmfXy7qaghGij0LXi+TkHjfgo0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Ur5QckXt+EY4flkbjzsX3ko0zeEbal9DXf9qBlQ+/lUADAl1VMHM+MZFtipyCVjp64 Lh1CggEfwIX4/m6dfcwF2VvhrAM4R+evXsmW2hYkCY4AUhoxwNHPomoyzZ+c8Obh1i/Y t75bcYbLF8scuVowD6d6TR0DWaym/6fBTEXeg=
MIME-Version: 1.0
Received: by 10.52.176.36 with SMTP id cf4mr1604584vdc.29.1302195050998; Thu, 07 Apr 2011 09:50:50 -0700 (PDT)
Received: by 10.52.166.230 with HTTP; Thu, 7 Apr 2011 09:50:50 -0700 (PDT)
In-Reply-To: <BANLkTi=gy_X+Tkcy-UNKUz=[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <BANLkTi=[e-mail]> <[e-mail]> <BANLkTi=gy_X+Tkcy-UNKUz=[e-mail]>
Date: Thu, 7 Apr 2011 12:50:50 -0400
Message-ID: <BANLkTi==[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: John Gilmore <[e-mail]>
Content-Type: multipart/alternative; boundary=bcaec5171ea7716adc04a056e92d
Cc: [e-mail]
Subject: Re: [dane] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 07 Apr 2011 16:49:08 -0000

--bcaec5171ea7716adc04a056e92d
Content-Type: text/plain; charset=ISO-8859-1

The IPR has been changed to trust200902 and the definition of relying party
expanded to include any person relying on a cryptographic key. This is still
not quite correct since nobody should ever rely on a key itself, they are
always relying on on a key binding, but this will require more wordsmithing.

http://www.ietf.org/id/draft-hallambaker-dane-requirements-01.txt
<http://www.ietf.org/id/draft-hallambaker-dane-requirements-01.txt>

On Thu, Apr 7, 2011 at 8:06 AM, Phillip Hallam-Baker <[e-mail]>wrote:

>
>
> On Thu, Apr 7, 2011 at 8:14 AM, John Gilmore <[e-mail]> wrote:
>
>> Thank you, Phillip, for making a first cut at a use-case draft.
>>  However...
>>
>> One part I don't understand is that this draft comes with a copyright
>> notice in the very first paragraph, stating that neither modifications
>> nor derived works may be created.  I.e. nobody can edit this draft
>> except Phillip.  That appears to mean, according to BCP 78 and the
>> IETF Trust License Policy (TLP), that we have to start over from
>> scratch if he declines to "let us" revise it in ways that the
>> committee chooses.
>>
>
> Nah, that is just an oversight.
>
> The reason that I use it on individual submissions is that once in the past
> we did the same with the code and specifications for HTTP and HTML. NCSA
> then released a new browser where 70% of the code came from CERN but did not
> mention CERN, the use of the code or the 'World Wide Web' in any way
> whatsoever. As a direct result, CERN management stopped supporting the Web
> and I had to move to MIT.
>
> I also had the same thing happen to me on the OCSP draft.
>
>
> So my default is to use the XML for the non-modifiable license. I can
> change that if folk actually care. To be honest, I don't actually read the
> boilerplate.
>
> The WG *cannot* adopt it - and should not, for reasons beyond the
>> copyright.
>>
>> One thing I noticed before delving into the copyright and then
>> abandoning the document is that Phillip wouldn't be very predictable
>> if he hadn't jiggered the draft so that it's all about the
>> Certificates.  X.509 certificates.  It's buried right into the
>> definitions in pages 3 and 4; a "Relying Application" or "Relying
>> Party" isn't relying on public-key crypto; no, they're relying on a
>> "Certificate", which is defined as "An X.509 Certificate".
>>
>
> That is because the text for the definitions was copied over from the CAA
> draft which is intentionally limited to X.509 because we don't want CAA
> properties intended to restrict issue of certs from public CAs to muck up
> SAML and/or PGP without actually thinking about it. That does not really
> apply here.
>
> I will fix these later on today.
>
> --
> Website: http://hallambaker.com/
>
>


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

--bcaec5171ea7716adc04a056e92d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>The IPR has been changed to=A0trust200902 and the definition of relyin=
g party expanded to include any person relying on a cryptographic key. This=
 is still not quite correct since nobody should ever rely on a key itself, =
they are always relying on on a key binding, but this will require more wor=
dsmithing.</div>
<div><br></div><a href=3D"http://www.ietf.org/id/draft-hallambaker-dane-req=
uirements-01.txt">http://www.ietf.org/id/draft-hallambaker-dane-requirement=
s-01.txt</a><div><a href=3D"http://www.ietf.org/id/draft-hallambaker-dane-r=
equirements-01.txt"></a><br>
<br><div class=3D"gmail_quote">On Thu, Apr 7, 2011 at 8:06 AM, Phillip Hall=
am-Baker <span dir=3D"ltr">&lt;<a href=3D"mailto:[e-mail]">hallam@g=
mail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br><br><div class=3D"gmail_quote"><div class=3D"im">On Thu, Apr 7, 2011 at=
 8:14 AM, John Gilmore <span dir=3D"ltr">&lt;<a href=3D"mailto:[e-mail]=
" target=3D"_blank">[e-mail]</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">

Thank you, Phillip, for making a first cut at a use-case draft. =A0However.=
..<br>
<br>
One part I don&#39;t understand is that this draft comes with a copyright<b=
r>
notice in the very first paragraph, stating that neither modifications<br>
nor derived works may be created. =A0I.e. nobody can edit this draft<br>
except Phillip. =A0That appears to mean, according to BCP 78 and the<br>
IETF Trust License Policy (TLP), that we have to start over from<br>
scratch if he declines to &quot;let us&quot; revise it in ways that the<br>
committee chooses.<br></blockquote><div><br></div></div><div>Nah, that is j=
ust an oversight.</div><div><br></div><div>The reason that I use it on indi=
vidual submissions is that once in the past we did the same with the code a=
nd specifications for HTTP and HTML. NCSA then released a new browser where=
 70% of the code came from CERN but did not mention CERN, the use of the co=
de or the &#39;World Wide Web&#39; in any way whatsoever.=A0As a direct res=
ult, CERN management stopped supporting the Web and I had to move to MIT.</=
div>

<div><br></div><div>I also had the same thing happen to me on the OCSP draf=
t.=A0</div><div><br></div><div><br></div><div>So my default is to use the X=
ML for the non-modifiable license. I can change that if folk actually care.=
 To be honest, I don&#39;t actually read the boilerplate.</div>
<div class=3D"im">
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div>The WG *cannot* adopt it=
 - and should not, for reasons beyond the copyright.</div>
<br>
One thing I noticed before delving into the copyright and then<br>
abandoning the document is that Phillip wouldn&#39;t be very predictable<br=
>
if he hadn&#39;t jiggered the draft so that it&#39;s all about the<br>
Certificates. =A0X.509 certificates. =A0It&#39;s buried right into the<br>
definitions in pages 3 and 4; a &quot;Relying Application&quot; or &quot;Re=
lying<br>
Party&quot; isn&#39;t relying on public-key crypto; no, they&#39;re relying=
 on a<br>
&quot;Certificate&quot;, which is defined as &quot;An X.509 Certificate&quo=
t;.<br></blockquote></div></div><br clear=3D"all">That is because the text =
for the definitions was copied over from the CAA draft which is intentional=
ly limited to X.509 because we don&#39;t want CAA properties intended to re=
strict issue of certs from public CAs to muck up SAML and/or PGP without ac=
tually thinking about it. That does not really apply here.<div>

<br></div><div>I will fix these later on today.<br><div><br>-- <br>Website:=
 <a href=3D"http://hallambaker.com/" target=3D"_blank">http://hallambaker.c=
om/</a><br><br>
</div></div>
</blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a href=3D"htt=
p://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--bcaec5171ea7716adc04a056e92d--

From [e-mail]  Thu Apr  7 10:07:51 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E0B028C173 for <[e-mail]>; Thu,  7 Apr 2011 10:07:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.112
X-Spam-Level: 
X-Spam-Status: No, score=-102.112 tagged_above=-999 required=5 tests=[AWL=0.487, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ard58qrRHgEs for <[e-mail]>; Thu,  7 Apr 2011 10:07:50 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by core3.amsl.com (Postfix) with ESMTP id 8312728C161 for <[e-mail]>; Thu,  7 Apr 2011 10:07:50 -0700 (PDT)
Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p37H8RNt078993 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Apr 2011 10:08:27 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Paul Hoffman <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Thu, 7 Apr 2011 10:08:26 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <p06240805c9c25b23464a@[128.89.89.213]> <[e-mail]>
To: James Cloos <[e-mail]>
X-Mailer: Apple Mail (2.1084)
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 07 Apr 2011 17:07:51 -0000

On Apr 7, 2011, at 9:19 AM, James Cloos wrote:

>>>>>> "SK" =3D=3D Stephen Kent <[e-mail]> writes:
>=20
> SK> I think the steps you cite, while mostly accurate, are not a good
> SK> basis of comparison.  let me explain.
>=20
> I presume that everyone here has done the csr dance enough that a
> summary was enough...

Are you saying that there a use case where CSRs are impossible? Or a =
requirement that CSRs must not be generated for some reason?

You still have not stated what you want in terms of a use case and/or =
requirement.

> SK> P.S. I didn't understand your step "append the ca cert to the
> SK> resulting signed cert"
>=20
> Since the ca cert is only trusted by way of the rr, the server will =
need
> to send the full chain on each new connection. =20

The "full chain" is just the new CA cert.

> So the users have to
> remember the append the certs together whereever the server expects to
> find its cert.

But there is just one cert to append.

> Failure to append was the most common error I encountered with chained =
certs.

That may be true, but is irrelevant to what Steve said.

> EE certs in the rr is in all of the drafts, was the original target, =
is
> easy to understand and explain, and I've read more consensus for than
> against on the list.
>=20
> Why the sudden backlash against?

It is not "backlash": it is a discussion of what is really needed, and =
an engineering discussion of how to deliver what is needed. That doesn't =
seem like a bad thing...

--Paul Hoffman


From [e-mail]  Thu Apr  7 14:59:33 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3936128C11A for <[e-mail]>; Thu,  7 Apr 2011 14:59:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.57
X-Spam-Level: 
X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7sGdYxN9ddVk for <[e-mail]>; Thu,  7 Apr 2011 14:59:32 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 6286A28C0D8 for <[e-mail]>; Thu,  7 Apr 2011 14:59:32 -0700 (PDT)
Received: from dhcp89-089-213.bbn.com ([128.89.89.213]:49208) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <[e-mail]>) id 1Q7xGO-000I4o-Sw; Thu, 07 Apr 2011 18:01:16 -0400
Mime-Version: 1.0
Message-Id: <p06240800c9c3e03a9624@[128.89.89.213]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <p06240805c9c25b23464a@[128.89.89.213]> <[e-mail]>
Date: Thu, 7 Apr 2011 17:47:41 -0400
To: James Cloos <[e-mail]>
From: Stephen Kent <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 07 Apr 2011 21:59:33 -0000

At 12:19 PM -0400 4/7/11, James Cloos wrote:
>  >>>>> "SK" == Stephen Kent <[e-mail]> writes:
>
>SK> I think the steps you cite, while mostly accurate, are not a good
>SK> basis of comparison.  let me explain.
>
>I presume that everyone here has done the csr dance enough that a
>summary was enough...
>
>SK> P.S. I didn't understand your step "append the ca cert to the
>SK> resulting signed cert"
>
>Since the ca cert is only trusted by way of the rr, the server will need
>to send the full chain on each new connection.  So the users have to
>remember the append the certs together whereever the server expects to
>find its cert.

I believe that we have text that calls for a self-signed cert to be 
accepted as a TA for the duration of the session for which the RR was 
retrieved. In that
case there would be no need to send the SS cert in the TLS handshake.

>Failure to append was the most common error I encountered with chained certs.
>
>EE certs in the rr is in all of the drafts, was the original target, is
>easy to understand and explain, and I've read more consensus for than
>against on the list.
>
>Why the sudden backlash against?

It's not sudden :-). A self-signed cert is a CA cert, by definition (see
the cites to RFC 5280 in Paul's I-D. The TLS spec talks in terms of an
"end entity's cert" as representing a a server (or client). From a PKI
perspective, the cert that represents a server or client MUST be an
EE cert, an thus cannot be self-signed.  The fact that many implementations
violate IETF PKI standards in this regard, is unfortunate, but it is not
a basis for issuing a new IETF stanbdard that codifies this behavior.

Steve

From [e-mail]  Thu Apr  7 19:57:05 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2C3F3A69E5 for <[e-mail]>; Thu,  7 Apr 2011 19:57:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.223
X-Spam-Level: 
X-Spam-Status: No, score=-10.223 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ihV5tK0vKhr5 for <[e-mail]>; Thu,  7 Apr 2011 19:56:59 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id A110C3A69EA for <[e-mail]>; Thu,  7 Apr 2011 19:56:58 -0700 (PDT)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p382wY4q017943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Apr 2011 04:58:35 +0200 (MEST)
From: Martin Rex <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail] (Stephen Kent)
Date: Fri, 8 Apr 2011 04:58:34 +0200 (MEST)
In-Reply-To: <p06240800c9c3e03a9624@[128.89.89.213]> from "Stephen Kent" at Apr 7, 11 05:47:41 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: [e-mail]
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2011 02:57:06 -0000

Stephen Kent wrote:
> 
> James Cloos wrote:
> >
> >EE certs in the rr is in all of the drafts, was the original target, is
> >easy to understand and explain, and I've read more consensus for than
> >against on the list.
> >
> >Why the sudden backlash against?
> 
> It's not sudden :-). A self-signed cert is a CA cert, by definition (see
> the cites to RFC 5280 in Paul's I-D.

RFC 5280 is about X.509v3 certs _ONLY_.

There is NO problem creating X.509v1 End-Entity certs that are self-signed.
And there is no problem using any of these with implementations of
SSLv3 and TLSv1.0.

SSLv3 predates IETF PKIX standards, and TLSv1.0 is related to
rfc-2459 rather than rfc-5280 -- but implementations of TLSv1.0
were often shipped before publication of TLSv1.0 (rfc-2246) and
the original PKIX certificate profile (rfc-2459).


For safety, it would be sensible to ALWAYS treat X.509v1 certs as
EndEntity certs (i.e. never accept them as signer of other certs).
Our TLS implementation had done this initially, but we had a customer
that had obtained server certs issued under a VeriSign X.509v1 CA cert
(as late as 2006!), so I had to make our OEM implementation tolerate this.



>
> The TLS spec talks in terms of an "end entity's cert" as representing
> a a server (or client). From a PKI perspective, the cert that represents
> a server or client MUST be an EE cert,

Like an X.509v1 self-signed EE cert.  Works perfectly fine with all
TLS implementations that I've met.

Keep in mind that TLS is not limited to X.509v3 certs.

  TLSv1.0:    http://tools.ietf.org/html/rfc2246#section-7.4.2
  TLSv1.1:    http://tools.ietf.org/html/rfc4346#section-7.4.2

   7.4.2. Server certificate

      [...]

   Meaning of this message:
       The certificate type must be appropriate for the selected cipher
       suite's key exchange algorithm, and is generally an X.509v3
       certificate. It must contain a key which matches the key exchange
       method, as follows.


>
> an thus cannot be self-signed.

TLSv1.0 and TLSv1.1 have neither a problem with X.509v1 nor
with a self-signed X.509v1 End-Entity cert. 


> The fact that many implementations
> violate IETF PKI standards in this regard, is unfortunate, but it is not
> a basis for issuing a new IETF standard that codifies this behavior.

I know that there are lots of commercial CAs that still have CA certs
in every browser that are not valid CA certs according to PKIX / RFC 5280.

But having TLSv1.0&TLSv1.1 (i.e. 99% of the installed base)
accept X.509v1 self-signed EE certs is perfectly fine.

X.509v1 is fairly close to a bare key, supported by all TLS implementations
in the installed base, as well as tools in the installed base, such as
the openssl.exe shell and for transfering keypairs within PKCS#12/PFX.


-Martin

From [e-mail]  Thu Apr  7 20:34:44 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34F2F3A69CF for <[e-mail]>; Thu,  7 Apr 2011 20:34:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.003
X-Spam-Level: 
X-Spam-Status: No, score=-3.003 tagged_above=-999 required=5 tests=[AWL=-0.405, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N9IXCWwpE-gb for <[e-mail]>; Thu,  7 Apr 2011 20:34:42 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 0222D3A681C for <[e-mail]>; Thu,  7 Apr 2011 20:34:41 -0700 (PDT)
Received: by vxg33 with SMTP id 33so2938926vxg.31 for <[e-mail]>; Thu, 07 Apr 2011 20:36:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=mE5oPgz+GLRuCRtZOW6AK02xARLPtdkQAT9A1HBz4N4=; b=dqrsq4LMjQu9KPjdN+NtUHDSn2tDT/A97py0lhs2DCF24+oHf2Vrepw7b1Qll3wvdQ FzSmho4usO2DjO04toSWGYRqli1LKfGvJ5po9Ui5mICykiPmqrBBLrGLw+FwPXtRDlfA I9M1gPOjQ/DeQUQHXKTNeW4Jx4KQF82YU+Zkw=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=qoMVy1DC5nG76UEtrkM0yvPATitov0pxPzCqbrj4dERFlb5C/enR99AyJsL2BHnUV2 vjv5KArTzh7AOW+d1RCPugUVieSaMlZWisuuCMV/E+zwm5a35Y29BJxKjhNeLkEXuKV/ NUZqfrbBL9OusFBlkTJZPj4qdovuE5FWMxHNw=
MIME-Version: 1.0
Received: by 10.52.176.36 with SMTP id cf4mr2403482vdc.29.1302233786689; Thu, 07 Apr 2011 20:36:26 -0700 (PDT)
Received: by 10.52.166.230 with HTTP; Thu, 7 Apr 2011 20:36:26 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <p06240800c9c3e03a9624@128.89.89.213> <[e-mail]>
Date: Fri, 8 Apr 2011 03:36:26 +0000
Message-ID: <[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: [e-mail]
Content-Type: multipart/alternative; boundary=bcaec5171ea7452bc704a05feef1
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2011 03:34:44 -0000

--bcaec5171ea7452bc704a05feef1
Content-Type: text/plain; charset=ISO-8859-1

Seems to me to be a poor choice of a standards strategy.

X509v1 is obsolete. Implementations may choose to support v1 certs but I am
pretty sure that an IETF standards WG can't build anything new on top of
them.

And I am certain that going to an earlier version to avoid the PKIX
restriction is not going to fly.


This is meant to be a standards WG. One of the things about standards is
that on occasion you end up having to accept something you don't like
because that is the existing standard.

PKIX is the keying infrastructure of TLS. So this WG has to support it
properly. I know that there are alternatives in theory, but in practice they
are used about as often as DSA certs (25 servers worldwide).


I can't see the point of having this debate. Compliance with strict PKIX
does not prevent anyone from doing what they want to do. It is good crypto
hygiene to separate CA certs and EE certs.

If TLS was a simple, implement in an afternoon affair, I could see the point
in arguing for simplification of the cert scheme. But really, simplifying
the cert management its like trying to simplify one clause in the US federal
budget.



On Fri, Apr 8, 2011 at 2:58 AM, Martin Rex <[e-mail]> wrote:

> Stephen Kent wrote:
> >
> > James Cloos wrote:
> > >
> > >EE certs in the rr is in all of the drafts, was the original target, is
> > >easy to understand and explain, and I've read more consensus for than
> > >against on the list.
> > >
> > >Why the sudden backlash against?
> >
> > It's not sudden :-). A self-signed cert is a CA cert, by definition (see
> > the cites to RFC 5280 in Paul's I-D.
>
> RFC 5280 is about X.509v3 certs _ONLY_.
>
> There is NO problem creating X.509v1 End-Entity certs that are self-signed.
> And there is no problem using any of these with implementations of
> SSLv3 and TLSv1.0.
>
> SSLv3 predates IETF PKIX standards, and TLSv1.0 is related to
> rfc-2459 rather than rfc-5280 -- but implementations of TLSv1.0
> were often shipped before publication of TLSv1.0 (rfc-2246) and
> the original PKIX certificate profile (rfc-2459).
>
>
> For safety, it would be sensible to ALWAYS treat X.509v1 certs as
> EndEntity certs (i.e. never accept them as signer of other certs).
> Our TLS implementation had done this initially, but we had a customer
> that had obtained server certs issued under a VeriSign X.509v1 CA cert
> (as late as 2006!), so I had to make our OEM implementation tolerate this.
>
>
>
> >
> > The TLS spec talks in terms of an "end entity's cert" as representing
> > a a server (or client). From a PKI perspective, the cert that represents
> > a server or client MUST be an EE cert,
>
> Like an X.509v1 self-signed EE cert.  Works perfectly fine with all
> TLS implementations that I've met.
>
> Keep in mind that TLS is not limited to X.509v3 certs.
>
>  TLSv1.0:    http://tools.ietf.org/html/rfc2246#section-7.4.2
>  TLSv1.1:    http://tools.ietf.org/html/rfc4346#section-7.4.2
>
>   7.4.2. Server certificate
>
>      [...]
>
>   Meaning of this message:
>       The certificate type must be appropriate for the selected cipher
>       suite's key exchange algorithm, and is generally an X.509v3
>       certificate. It must contain a key which matches the key exchange
>       method, as follows.
>
>
> >
> > an thus cannot be self-signed.
>
> TLSv1.0 and TLSv1.1 have neither a problem with X.509v1 nor
> with a self-signed X.509v1 End-Entity cert.
>
>
> > The fact that many implementations
> > violate IETF PKI standards in this regard, is unfortunate, but it is not
> > a basis for issuing a new IETF standard that codifies this behavior.
>
> I know that there are lots of commercial CAs that still have CA certs
> in every browser that are not valid CA certs according to PKIX / RFC 5280.
>
> But having TLSv1.0&TLSv1.1 (i.e. 99% of the installed base)
> accept X.509v1 self-signed EE certs is perfectly fine.
>
> X.509v1 is fairly close to a bare key, supported by all TLS implementations
> in the installed base, as well as tools in the installed base, such as
> the openssl.exe shell and for transfering keypairs within PKCS#12/PFX.
>
>
> -Martin
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane
>



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

--bcaec5171ea7452bc704a05feef1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Seems to me to be a poor choice of a standards strategy.<div><br></div><div=
>X509v1 is obsolete. Implementations may choose to support v1 certs but I a=
m pretty sure that an IETF standards WG can&#39;t build anything new on top=
 of them.</div>
<div><br></div><div>And I am certain that going to an earlier version to av=
oid the PKIX restriction is not going to fly.=A0</div><div><br></div><div><=
br></div><div>This is meant to be a standards WG. One of the things about s=
tandards is that on occasion you end up having to accept something you don&=
#39;t like because that is the existing standard.</div>
<div><br></div><div>PKIX is the keying infrastructure of TLS. So this WG ha=
s to support it properly. I know that there are alternatives in theory, but=
 in practice they are used about as often as DSA certs (25 servers worldwid=
e).</div>
<div><br></div><div><br></div><div>I can&#39;t see the point of having this=
 debate. Compliance with strict PKIX does not prevent anyone from doing wha=
t they want to do. It is good crypto hygiene to separate CA certs and EE ce=
rts.</div>
<div><br></div><div>If TLS was a simple, implement in an afternoon affair, =
I could see the point in arguing for simplification of the cert scheme. But=
 really, simplifying the cert management its like trying to simplify one cl=
ause in the US federal budget.</div>
<div><br></div><div><br></div><div><br><div class=3D"gmail_quote">On Fri, A=
pr 8, 2011 at 2:58 AM, Martin Rex <span dir=3D"ltr">&lt;<a href=3D"mailto:m=
[e-mail]">[e-mail]</a>&gt;</span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex;">
Stephen Kent wrote:<br>
<div class=3D"im">&gt;<br>
&gt; James Cloos wrote:<br>
&gt; &gt;<br>
&gt; &gt;EE certs in the rr is in all of the drafts, was the original targe=
t, is<br>
&gt; &gt;easy to understand and explain, and I&#39;ve read more consensus f=
or than<br>
&gt; &gt;against on the list.<br>
&gt; &gt;<br>
&gt; &gt;Why the sudden backlash against?<br>
&gt;<br>
&gt; It&#39;s not sudden :-). A self-signed cert is a CA cert, by definitio=
n (see<br>
&gt; the cites to RFC 5280 in Paul&#39;s I-D.<br>
<br>
</div>RFC 5280 is about X.509v3 certs _ONLY_.<br>
<br>
There is NO problem creating X.509v1 End-Entity certs that are self-signed.=
<br>
And there is no problem using any of these with implementations of<br>
SSLv3 and TLSv1.0.<br>
<br>
SSLv3 predates IETF PKIX standards, and TLSv1.0 is related to<br>
rfc-2459 rather than rfc-5280 -- but implementations of TLSv1.0<br>
were often shipped before publication of TLSv1.0 (rfc-2246) and<br>
the original PKIX certificate profile (rfc-2459).<br>
<br>
<br>
For safety, it would be sensible to ALWAYS treat X.509v1 certs as<br>
EndEntity certs (i.e. never accept them as signer of other certs).<br>
Our TLS implementation had done this initially, but we had a customer<br>
that had obtained server certs issued under a VeriSign X.509v1 CA cert<br>
(as late as 2006!), so I had to make our OEM implementation tolerate this.<=
br>
<div class=3D"im"><br>
<br>
<br>
&gt;<br>
&gt; The TLS spec talks in terms of an &quot;end entity&#39;s cert&quot; as=
 representing<br>
&gt; a a server (or client). From a PKI perspective, the cert that represen=
ts<br>
&gt; a server or client MUST be an EE cert,<br>
<br>
</div>Like an X.509v1 self-signed EE cert. =A0Works perfectly fine with all=
<br>
TLS implementations that I&#39;ve met.<br>
<br>
Keep in mind that TLS is not limited to X.509v3 certs.<br>
<br>
 =A0TLSv1.0: =A0 =A0<a href=3D"http://tools.ietf.org/html/rfc2246#section-7=
.4.2" target=3D"_blank">http://tools.ietf.org/html/rfc2246#section-7.4.2</a=
><br>
 =A0TLSv1.1: =A0 =A0<a href=3D"http://tools.ietf.org/html/rfc4346#section-7=
.4.2" target=3D"_blank">http://tools.ietf.org/html/rfc4346#section-7.4.2</a=
><br>
<br>
 =A0 7.4.2. Server certificate<br>
<br>
 =A0 =A0 =A0[...]<br>
<br>
 =A0 Meaning of this message:<br>
 =A0 =A0 =A0 The certificate type must be appropriate for the selected ciph=
er<br>
 =A0 =A0 =A0 suite&#39;s key exchange algorithm, and is generally an X.509v=
3<br>
 =A0 =A0 =A0 certificate. It must contain a key which matches the key excha=
nge<br>
 =A0 =A0 =A0 method, as follows.<br>
<div class=3D"im"><br>
<br>
&gt;<br>
&gt; an thus cannot be self-signed.<br>
<br>
</div>TLSv1.0 and TLSv1.1 have neither a problem with X.509v1 nor<br>
with a self-signed X.509v1 End-Entity cert.<br>
<div class=3D"im"><br>
<br>
&gt; The fact that many implementations<br>
&gt; violate IETF PKI standards in this regard, is unfortunate, but it is n=
ot<br>
</div>&gt; a basis for issuing a new IETF standard that codifies this behav=
ior.<br>
<br>
I know that there are lots of commercial CAs that still have CA certs<br>
in every browser that are not valid CA certs according to PKIX / RFC 5280.<=
br>
<br>
But having TLSv1.0&amp;TLSv1.1 (i.e. 99% of the installed base)<br>
accept X.509v1 self-signed EE certs is perfectly fine.<br>
<br>
X.509v1 is fairly close to a bare key, supported by all TLS implementations=
<br>
in the installed base, as well as tools in the installed base, such as<br>
the openssl.exe shell and for transfering keypairs within PKCS#12/PFX.<br>
<font color=3D"#888888"><br>
<br>
-Martin<br>
</font><div><div></div><div class=3D"h5">__________________________________=
_____________<br>
dane mailing list<br>
<a href=3D"mailto:[e-mail]">[e-mail]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/dane</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a=
 href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--bcaec5171ea7452bc704a05feef1--

From [e-mail]  Thu Apr  7 21:37:28 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 858B128C0D0 for <[e-mail]>; Thu,  7 Apr 2011 21:37:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.223
X-Spam-Level: 
X-Spam-Status: No, score=-10.223 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSmCRo7MFUPP for <[e-mail]>; Thu,  7 Apr 2011 21:37:27 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 6E5FC3A6784 for <[e-mail]>; Thu,  7 Apr 2011 21:37:27 -0700 (PDT)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p384d8WU028056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Apr 2011 06:39:08 +0200 (MEST)
From: Martin Rex <[e-mail]>
Message-Id: <[e-mail]>
Orig-To: [e-mail] (Phillip Hallam-Baker)
To: [e-mail], [e-mail]
Date: Fri, 8 Apr 2011 06:33:46 +0200 (MEST)
In-Reply-To: <[e-mail]> from "Phillip Hallam-Baker" at Apr 8, 11 03:36:26 am
Sender: [e-mail]
X-SAP: out
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: [e-mail]
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2011 04:37:28 -0000

Phillip Hallam-Baker wrote:
> 
> Seems to me to be a poor choice of a standards strategy.
> 
> X509v1 is obsolete. Implementations may choose to support v1 certs but I am
> pretty sure that an IETF standards WG can't build anything new on top of
> them.

X.509v1 is obsolete for PKI(X), but it is a perfect fit as a bare
key format for many existing tools (for the management and creation
of keypairs), protocols (including TLS) and container formats for
exchange (e.g. PKCS12/PFX).

Why should we artificially invent a bare key format to cover the
most common format for TLS Server credentials on the internet,
when there is a format that works just fine with all existing
implementation and has been completely abandonned by PKIX,
such as X.509v1?


> 
> And I am certain that going to an earlier version to avoid the PKIX
> restriction is not going to fly.

Just because you personally do not find it aesthetically pleasing?


> 
> 
> This is meant to be a standards WG. One of the things about standards is
> that on occasion you end up having to accept something you don't like
> because that is the existing standard.

The existing standard is what the "unwashed self-signed masses"
out there on the internet need, and they really want it to work
with as much of the installed base as possible.

Rather than making convolutions to define X.509v3 self-signed EndEntity
certs, simply use the otherwise abandonned X.509v1 format for exactly
this purpose.


> 
> PKIX is the keying infrastructure of TLS.

That is plain wrong. 
PKIX is the keying infrastructure of the Internet PKI.

Bare keys represented by self-signed X.509v1 certs are obviously _NO_ PKI,
therefore PKIX rules do not apply.


You seem to be mostly worried about the business model of your employer.

-Martin


From [e-mail]  Fri Apr  8 03:12:56 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC98728C101 for <[e-mail]>; Fri,  8 Apr 2011 03:12:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.977
X-Spam-Level: 
X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMIu6plLds-F for <[e-mail]>; Fri,  8 Apr 2011 03:12:56 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id E0F7928C0E7 for <[e-mail]>; Fri,  8 Apr 2011 03:12:55 -0700 (PDT)
Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [172.25.149.14]) by smtp-out.google.com with ESMTP id p38AEe4F005568 for <[e-mail]>; Fri, 8 Apr 2011 03:14:40 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1302257680; bh=MCNWRKO+Lqs5cqKLjKSjUCCUtJc=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=Q3TxrLsViGwGofQE9Lb5kcqisFYP59a5dpkKNVfdQftiHBofailqbd/hkaAkqkxYr UjJprBRDv7j+i+iabYmAA==
Received: from vws2 (vws2.prod.google.com [10.241.21.130]) by hpaq14.eem.corp.google.com with ESMTP id p38AEcfP011070 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <[e-mail]>; Fri, 8 Apr 2011 03:14:38 -0700
Received: by vws2 with SMTP id 2so2927920vws.6 for <[e-mail]>; Fri, 08 Apr 2011 03:14:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=tanbcW3CXqv5zWxLdjMiLEhoICMxVXunVuGJUJHr0Lo=; b=m/M7s1OrGI9KoLr4bEnLdhmOm8iz0PZvZEh4IYbCYsV5wIzU5DpvVv1urdjgJNaUcF CPEJUa+N1hHgPd+CDzAA==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=hTfSEiHU7v7pFc8FjEBw7dn25Vzh3XyHYiNTKlt6Bjj2ogcWcw2VxxV+koa53Xp4L/ MZBnjwCaDpYxbBD5wZEg==
MIME-Version: 1.0
Received: by 10.220.182.9 with SMTP id ca9mr554223vcb.155.1302257677744; Fri, 08 Apr 2011 03:14:37 -0700 (PDT)
Received: by 10.220.117.12 with HTTP; Fri, 8 Apr 2011 03:14:37 -0700 (PDT)
In-Reply-To: <p06240800c9c3e03a9624@128.89.89.213>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <p06240805c9c25b23464a@128.89.89.213> <[e-mail]> <p06240800c9c3e03a9624@128.89.89.213>
Date: Fri, 8 Apr 2011 11:14:37 +0100
Message-ID: <BANLkTin=[e-mail]>
From: Ben Laurie <[e-mail]>
To: Stephen Kent <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2011 10:12:57 -0000

On 7 April 2011 22:47, Stephen Kent <[e-mail]> wrote:
> At 12:19 PM -0400 4/7/11, James Cloos wrote:
>>
>> =A0>>>>> "SK" =3D=3D Stephen Kent <[e-mail]> writes:
>>
>> SK> I think the steps you cite, while mostly accurate, are not a good
>> SK> basis of comparison. =A0let me explain.
>>
>> I presume that everyone here has done the csr dance enough that a
>> summary was enough...
>>
>> SK> P.S. I didn't understand your step "append the ca cert to the
>> SK> resulting signed cert"
>>
>> Since the ca cert is only trusted by way of the rr, the server will need
>> to send the full chain on each new connection. =A0So the users have to
>> remember the append the certs together whereever the server expects to
>> find its cert.
>
> I believe that we have text that calls for a self-signed cert to be accep=
ted
> as a TA for the duration of the session for which the RR was retrieved. I=
n
> that
> case there would be no need to send the SS cert in the TLS handshake.
>
>> Failure to append was the most common error I encountered with chained
>> certs.
>>
>> EE certs in the rr is in all of the drafts, was the original target, is
>> easy to understand and explain, and I've read more consensus for than
>> against on the list.
>>
>> Why the sudden backlash against?
>
> It's not sudden :-). A self-signed cert is a CA cert, by definition (see
> the cites to RFC 5280 in Paul's I-D. The TLS spec talks in terms of an
> "end entity's cert" as representing a a server (or client). From a PKI
> perspective, the cert that represents a server or client MUST be an
> EE cert, an thus cannot be self-signed. =A0The fact that many implementat=
ions
> violate IETF PKI standards in this regard, is unfortunate, but it is not
> a basis for issuing a new IETF stanbdard that codifies this behavior.

Isn't it? What is the argument against allowing a self-signed EE cert,
other than spec lawyering?

>
> Steve
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane
>

From [e-mail]  Fri Apr  8 04:58:45 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CC5F3A6908 for <[e-mail]>; Fri,  8 Apr 2011 04:58:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.499
X-Spam-Level: 
X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.099,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U7thMdY0TZ-N for <[e-mail]>; Fri,  8 Apr 2011 04:58:43 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id D419A3A6902 for <[e-mail]>; Fri,  8 Apr 2011 04:58:42 -0700 (PDT)
Received: by vws12 with SMTP id 12so3242634vws.31 for <[e-mail]>; Fri, 08 Apr 2011 05:00:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=97JNYFQXVjwWVMDr5Kx+drXkjsKsLOLZKTzno9jcBgg=; b=Qe/B9QHT3iZNTgWdJCRj/CLetwtLG4WueIu6tp8uLqoeG+ws/6KarAQNFZlnXfBdOE nQbxwhlmdToThmF4WF//Uh23iYBY3HmJ8dBQaCcz4KlsPuHtegyzBhFzTidVF7RZhVYz MHOHxcXcPjQHfM0BsAZsnu6y5MWD6WFFYtad0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=aGTFFqQ/lmOyRquhVzRKDAkIo9rE8BI7w2xwVpAQdDeVT28uRt8zEwXrUP23pC70Th SEUY5pm9wBJ6UFP7calaHXCHimN1TksCOsxEZUc7013Cr2yOmrd/+ZoouQO10pi8El7H RAw2v5kyMnWXHdWkpeqIhsyUR33efY3WxZhFs=
MIME-Version: 1.0
Received: by 10.52.98.230 with SMTP id el6mr3099094vdb.149.1302264027883; Fri, 08 Apr 2011 05:00:27 -0700 (PDT)
Received: by 10.52.166.230 with HTTP; Fri, 8 Apr 2011 05:00:27 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Fri, 8 Apr 2011 12:00:27 +0000
Message-ID: <[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: [e-mail]
Content-Type: multipart/alternative; boundary=20cf307cfcbcc9298e04a066f8f8
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2011 11:58:45 -0000

--20cf307cfcbcc9298e04a066f8f8
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Apr 8, 2011 at 4:33 AM, Martin Rex <[e-mail]> wrote:

>
> > And I am certain that going to an earlier version to avoid the PKIX
> > restriction is not going to fly.
>
> Just because you personally do not find it aesthetically pleasing?
>

You are projecting here.

Personally, I really could not care less one way or the other on this
particular issue. You are the one who is raising a minor technical issue in
a use cases and requirements thread.

Had I actually cared about the self signed certs issue I would have raised
it before Steve did. However, he has raised it and irritatingly enough, he
happens to be right as far as the X.509v3 standard is concerned.


Proposing use of X.509v1 or a non-standard use of PKIX would require a huge
amount of political effort and introduce a great deal of delay. I can't see
it as being very likely that Steve does not get his way in the end as far as
the standard is concerned.

The actual code is a completely different matter.


If people want to move quickly, this is the type of argument to rule out of
scope and move on over because it really is inconsequential and the issue in
question is in scope of a different working group.


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

--20cf307cfcbcc9298e04a066f8f8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Fri, Apr 8, 2011 at 4:33 AM, Martin Rex <span dir=3D"ltr">&lt;<a href=3D=
"mailto:[e-mail]">[e-mail]</a>&gt;</span> wrote:<br><div class=3D"g=
mail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im"><br></div><div class=3D"im">&gt; And I am certain that go=
ing to an earlier version to avoid the PKIX<br>
&gt; restriction is not going to fly.<br>
<br>
</div><div class=3D"im">Just because you personally do not find it aestheti=
cally pleasing?<br></div></blockquote><div><br></div><div>You are projectin=
g here.=A0</div><div><br></div><div>Personally, I really could not care les=
s one way or the other on this particular issue. You are the one who is rai=
sing a minor technical issue in a use cases and requirements thread.</div>
<div><br></div><div>Had I actually cared about the self signed certs issue =
I would have raised it before Steve did. However, he has raised it and irri=
tatingly enough, he happens to be right as far as the X.509v3 standard is c=
oncerned.</div>
<div><br></div><div><br></div><div>Proposing use of X.509v1 or a non-standa=
rd use of PKIX would require a huge amount of political effort and introduc=
e a great deal of delay. I can&#39;t see it as being very likely that Steve=
 does not get his way in the end as far as the standard is concerned.</div>
<div><br></div><div>The actual code is a completely different matter.</div>=
<div><br></div><div><br></div><div>If people want to move quickly, this is =
the type of argument to rule out of scope and move on over because it reall=
y is inconsequential and the issue in question is in scope of a different w=
orking group.</div>
<div><br></div><div><br></div></div>-- <br>Website: <a href=3D"http://halla=
mbaker.com/">http://hallambaker.com/</a><br><br>

--20cf307cfcbcc9298e04a066f8f8--

From [e-mail]  Fri Apr  8 05:32:32 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C39C3A68C1 for <[e-mail]>; Fri,  8 Apr 2011 05:32:32 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eitp9bxFimZW for <[e-mail]>; Fri,  8 Apr 2011 05:32:31 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by core3.amsl.com (Postfix) with ESMTP id CDB6E3A68C0 for <[e-mail]>; Fri,  8 Apr 2011 05:32:30 -0700 (PDT)
Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p38CXSx2023372 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 8 Apr 2011 05:33:29 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Paul Hoffman <[e-mail]>
In-Reply-To: <BANLkTin=[e-mail]>
Date: Fri, 8 Apr 2011 05:33:28 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <p06240805c9c25b23464a@128.89.89.213> <[e-mail]> <p06240800c9c3e03a9624@128.89.89.213> <BANLkTin=[e-mail]>
To: Ben Laurie <[e-mail]>
X-Mailer: Apple Mail (2.1084)
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2011 12:32:32 -0000

I note, again, that this has *nothing* to do with use cases or =
requirements. Having said that...

On Apr 8, 2011, at 3:14 AM, Ben Laurie wrote:

> Isn't it? What is the argument against allowing a self-signed EE cert,
> other than spec lawyering?


A PKIX-compliant implementation must make some changes to handle them, =
as described in the current draft. If the use cases and requirements =
chosen by the WG lead to giving end entity certs, the WG can decide =
those changes are fine. If the use cases and requirements chosen by the =
WG lead to not giving end entity certs, we have an easy way to handle =
that.

--Paul Hoffman


From [e-mail]  Fri Apr  8 05:35:14 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FED23A68C0 for <[e-mail]>; Fri,  8 Apr 2011 05:35:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.3
X-Spam-Level: 
X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7CwgvJlJVws for <[e-mail]>; Fri,  8 Apr 2011 05:35:10 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id A59C128C0D8 for <[e-mail]>; Fri,  8 Apr 2011 05:35:09 -0700 (PDT)
Received: from dhcp-205.office.nic.cz (unknown [IPv6:2001:1488:ac14:1400:226:bbff:fe17:a705]) by mail.nic.cz (Postfix) with ESMTPSA id C2A652A0DD3 for <[e-mail]>; Fri,  8 Apr 2011 14:36:53 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Fri, 08 Apr 2011 14:36:52 +0200
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[e-mail]>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: [e-mail]
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.96.5 at mail
X-Virus-Status: Clean
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2011 12:35:15 -0000

My question to the list is if we can avoid specifying which X.509 
version the client/server has to use and leave it to the client policy.

Martin's approach seems like a reasonable one, but the question is if we 
can fit it into our draft without advice to break any existing standard.

I know that we are standards group (to reply to PHB later in this 
thread), but we also cannot afford to ignore what's happening in the 
real world otherwise the world is going to ignore us.

I think that usage of self-signed EE cert is a reasonable use case 
(which may or may not make it to the protocol) and it shouldn't be left 
out.  So please everybody let's think harder how to make things for 
non-protocol-geeks out there simpler, so the fruit of our work is a 
tasty one and not bittersweet.

O.

On 4/8/11 4:58 AM, Martin Rex wrote:
> Stephen Kent wrote:
>>
>> James Cloos wrote:
>>>
>>> EE certs in the rr is in all of the drafts, was the original target, is
>>> easy to understand and explain, and I've read more consensus for than
>>> against on the list.
>>>
>>> Why the sudden backlash against?
>>
>> It's not sudden :-). A self-signed cert is a CA cert, by definition (see
>> the cites to RFC 5280 in Paul's I-D.
>
> RFC 5280 is about X.509v3 certs _ONLY_.
>
> There is NO problem creating X.509v1 End-Entity certs that are self-signed.
> And there is no problem using any of these with implementations of
> SSLv3 and TLSv1.0.
>
> SSLv3 predates IETF PKIX standards, and TLSv1.0 is related to
> rfc-2459 rather than rfc-5280 -- but implementations of TLSv1.0
> were often shipped before publication of TLSv1.0 (rfc-2246) and
> the original PKIX certificate profile (rfc-2459).
>
>
> For safety, it would be sensible to ALWAYS treat X.509v1 certs as
> EndEntity certs (i.e. never accept them as signer of other certs).
> Our TLS implementation had done this initially, but we had a customer
> that had obtained server certs issued under a VeriSign X.509v1 CA cert
> (as late as 2006!), so I had to make our OEM implementation tolerate this.
>
>
>
>>
>> The TLS spec talks in terms of an "end entity's cert" as representing
>> a a server (or client). From a PKI perspective, the cert that represents
>> a server or client MUST be an EE cert,
>
> Like an X.509v1 self-signed EE cert.  Works perfectly fine with all
> TLS implementations that I've met.
>
> Keep in mind that TLS is not limited to X.509v3 certs.
>
>    TLSv1.0:    http://tools.ietf.org/html/rfc2246#section-7.4.2
>    TLSv1.1:    http://tools.ietf.org/html/rfc4346#section-7.4.2
>
>     7.4.2. Server certificate
>
>        [...]
>
>     Meaning of this message:
>         The certificate type must be appropriate for the selected cipher
>         suite's key exchange algorithm, and is generally an X.509v3
>         certificate. It must contain a key which matches the key exchange
>         method, as follows.
>
>
>>
>> an thus cannot be self-signed.
>
> TLSv1.0 and TLSv1.1 have neither a problem with X.509v1 nor
> with a self-signed X.509v1 End-Entity cert.
>
>
>> The fact that many implementations
>> violate IETF PKI standards in this regard, is unfortunate, but it is not
>> a basis for issuing a new IETF standard that codifies this behavior.
>
> I know that there are lots of commercial CAs that still have CA certs
> in every browser that are not valid CA certs according to PKIX / RFC 5280.
>
> But having TLSv1.0&TLSv1.1 (i.e. 99% of the installed base)
> accept X.509v1 self-signed EE certs is perfectly fine.
>
> X.509v1 is fairly close to a bare key, supported by all TLS implementations
> in the installed base, as well as tools in the installed base, such as
> the openssl.exe shell and for transfering keypairs within PKCS#12/PFX.


From [e-mail]  Fri Apr  8 05:44:32 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 013D33A6A03 for <[e-mail]>; Fri,  8 Apr 2011 05:44:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.3
X-Spam-Level: 
X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUBNT4Rl2EIX for <[e-mail]>; Fri,  8 Apr 2011 05:44:31 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id 093A23A6911 for <[e-mail]>; Fri,  8 Apr 2011 05:44:31 -0700 (PDT)
Received: from dhcp-205.office.nic.cz (unknown [IPv6:2001:1488:ac14:1400:226:bbff:fe17:a705]) by mail.nic.cz (Postfix) with ESMTPSA id 88DFA2A0DD3 for <[e-mail]>; Fri,  8 Apr 2011 14:46:15 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Fri, 08 Apr 2011 14:46:15 +0200
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[e-mail]>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: [e-mail]
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]> <BANLkTi=[e-mail]>
In-Reply-To: <BANLkTi=[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.96.5 at mail
X-Virus-Status: Clean
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2011 12:44:32 -0000

Phillip,

the chairs have already asked Richard Barnes to be the editor of the 
use-cases document for the working group and he agreed.  We are sorry 
that we didn't announce it sooner.

However I don't think that this poses a big problem, since you also 
agreed that you would send a list of your use cases to the list and the 
format (email or I-D) doesn't make a real difference. So I think the WG 
would be happy to accept your submission as an input document for the 
discussion on the working group use case document.

O.

On 4/6/11 1:33 AM, Phillip Hallam-Baker wrote:
> OK, as promised at the WG meeting, here is a first cut at a requirements
> document based on the use cases and requirements analysis that I have
> done to support my earlier proposals in this area.
>
> I have cut down the original documents to make this more manageable.
> What I have not done (yet) is to draw up the correspondance matrices
> that link the use cases to the requirements and so on. Nor have I got
> the links in hypertext form.
>
> The idea is that each use case should list the requirements it motivates
> and vice versa. Every requirement should be driven by at least one use case.
>
> What I have not quite worked out at this point is how to make use of the
> attacker model to derive requirements from the use cases. Part of the
> point of specifying the attacker profiles is that a proposal should not
> get credit for blocking an attack A1 that allows attacker X to have
> effect Y if the same attacker can realize Y through attack A2 that is
> also in their capabilities.
>
> http://www.ietf.org/id/draft-hallambaker-dane-requirements-00.txt
>
>
> I have put this in as a personal submission so as not to pre-empt the WG
> decision. But am quite happy if the WG wants to adopt it.
>
> Its also missing an acknowledgements section, many of these use cases
> were captured during our earlier arguments on the list.
>
> Phill
>
>
>
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane


From [e-mail]  Fri Apr  8 05:44:58 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F6623A69FB for <[e-mail]>; Fri,  8 Apr 2011 05:44:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.977
X-Spam-Level: 
X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQ6rM-AON1xp for <[e-mail]>; Fri,  8 Apr 2011 05:44:56 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 8FF043A6911 for <[e-mail]>; Fri,  8 Apr 2011 05:44:56 -0700 (PDT)
Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id p38CkeuX025277 for <[e-mail]>; Fri, 8 Apr 2011 05:46:40 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1302266801; bh=vS8Tt3hapVnvTJQ1EXpBnJPcQz0=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=axzmCbkIGinBgZNd/XPjmHAPDXHUT8mBmyB/7HXLHv5mBk5UpmYOHrJe4wd8vfW6Z N+7fvCIvhbo/i2dGiD3ww==
Received: from vxa37 (vxa37.prod.google.com [10.241.33.37]) by wpaz29.hot.corp.google.com with ESMTP id p38CkcuY009856 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <[e-mail]>; Fri, 8 Apr 2011 05:46:39 -0700
Received: by vxa37 with SMTP id 37so3946210vxa.21 for <[e-mail]>; Fri, 08 Apr 2011 05:46:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=h001hWEFT739E1aDHlCW2dNxCkY4ZA9cuKwvRM35k90=; b=iExeErK6Ksh5iine4R6sqYpPXjMIU/Bveodnq0A9efohpLJ4KeB4i+v4bpShSH7M5b qhSx+TjaZ4KlYyJ/9MOw==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Wn1Bca9Jjt2pZp49dqYy8bqaQWfF5abEGjh9kCHVNh5W/VUkc0CaSvvMCmKgoXgj03 hQmIOYHiWT5fhtd8OBmw==
MIME-Version: 1.0
Received: by 10.220.175.199 with SMTP id bb7mr608512vcb.225.1302266798586; Fri, 08 Apr 2011 05:46:38 -0700 (PDT)
Received: by 10.220.117.12 with HTTP; Fri, 8 Apr 2011 05:46:38 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <p06240805c9c25b23464a@128.89.89.213> <[e-mail]> <p06240800c9c3e03a9624@128.89.89.213> <BANLkTin=[e-mail]> <[e-mail]>
Date: Fri, 8 Apr 2011 13:46:38 +0100
Message-ID: <BANLkTi=mLJ4Ohr-=[e-mail]>
From: Ben Laurie <[e-mail]>
To: Paul Hoffman <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2011 12:44:58 -0000

On 8 April 2011 13:33, Paul Hoffman <[e-mail]> wrote:
> I note, again, that this has *nothing* to do with use cases or requiremen=
ts. Having said that...

I've already stated my requirement (that self-signed certs should be usable=
).

>
> On Apr 8, 2011, at 3:14 AM, Ben Laurie wrote:
>
>> Isn't it? What is the argument against allowing a self-signed EE cert,
>> other than spec lawyering?
>
>
> A PKIX-compliant implementation must make some changes to handle them, as=
 described in the current draft. If the use cases and requirements chosen b=
y the WG lead to giving end entity certs, the WG can decide those changes a=
re fine. If the use cases and requirements chosen by the WG lead to not giv=
ing end entity certs, we have an easy way to handle that.
>
> --Paul Hoffman
>
>

From [e-mail]  Fri Apr  8 05:45:05 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EF483A6A09 for <[e-mail]>; Fri,  8 Apr 2011 05:45:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.411
X-Spam-Level: 
X-Spam-Status: No, score=-102.411 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2klouBzMg6nv for <[e-mail]>; Fri,  8 Apr 2011 05:45:03 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 391FD3A6A0B for <[e-mail]>; Fri,  8 Apr 2011 05:45:03 -0700 (PDT)
Received: from [128.89.252.180] (port=61695 helo=[192.168.1.10]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from <[e-mail]>) id 1Q8B5L-000Pjx-Tm; Fri, 08 Apr 2011 08:46:48 -0400
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=utf-8
From: "Richard L. Barnes" <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Fri, 8 Apr 2011 08:46:46 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= <[e-mail]>
X-Mailer: Apple Mail (2.1082)
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2011 12:45:05 -0000

To note again: The phrase "self-signed EE cert" does not make sense.  =
=46rom RFC 5280:
"
Self-issued certificates are generated to support changes in policy or =
operations.  Self-signed certificates are self-issued certificates where =
the digital signature may be verified by the public key bound into the =
certificate.
"
Since a self-signed cert has a cert issued under it (itself), it has to =
be a CA cert.

A self-signed cert *without* the CA bits set is therefore malformed, and =
will not pass PKIX validation. =20

Which brings us back to the point that if you want certs that really =
aren't signed by anybody, you might as well be using bare keys, or some =
new data structure that only carries what you're interested in, e.g., =
key parameters but not key usage, names, issuer, etc.

--Richard




On Apr 8, 2011, at 8:36 AM, Ond=C5=99ej Sur=C3=BD wrote:

> My question to the list is if we can avoid specifying which X.509 =
version the client/server has to use and leave it to the client policy.
>=20
> Martin's approach seems like a reasonable one, but the question is if =
we can fit it into our draft without advice to break any existing =
standard.
>=20
> I know that we are standards group (to reply to PHB later in this =
thread), but we also cannot afford to ignore what's happening in the =
real world otherwise the world is going to ignore us.
>=20
> I think that usage of self-signed EE cert is a reasonable use case =
(which may or may not make it to the protocol) and it shouldn't be left =
out.  So please everybody let's think harder how to make things for =
non-protocol-geeks out there simpler, so the fruit of our work is a =
tasty one and not bittersweet.
>=20
> O.
>=20
> On 4/8/11 4:58 AM, Martin Rex wrote:
>> Stephen Kent wrote:
>>>=20
>>> James Cloos wrote:
>>>>=20
>>>> EE certs in the rr is in all of the drafts, was the original =
target, is
>>>> easy to understand and explain, and I've read more consensus for =
than
>>>> against on the list.
>>>>=20
>>>> Why the sudden backlash against?
>>>=20
>>> It's not sudden :-). A self-signed cert is a CA cert, by definition =
(see
>>> the cites to RFC 5280 in Paul's I-D.
>>=20
>> RFC 5280 is about X.509v3 certs _ONLY_.
>>=20
>> There is NO problem creating X.509v1 End-Entity certs that are =
self-signed.
>> And there is no problem using any of these with implementations of
>> SSLv3 and TLSv1.0.
>>=20
>> SSLv3 predates IETF PKIX standards, and TLSv1.0 is related to
>> rfc-2459 rather than rfc-5280 -- but implementations of TLSv1.0
>> were often shipped before publication of TLSv1.0 (rfc-2246) and
>> the original PKIX certificate profile (rfc-2459).
>>=20
>>=20
>> For safety, it would be sensible to ALWAYS treat X.509v1 certs as
>> EndEntity certs (i.e. never accept them as signer of other certs).
>> Our TLS implementation had done this initially, but we had a customer
>> that had obtained server certs issued under a VeriSign X.509v1 CA =
cert
>> (as late as 2006!), so I had to make our OEM implementation tolerate =
this.
>>=20
>>=20
>>=20
>>>=20
>>> The TLS spec talks in terms of an "end entity's cert" as =
representing
>>> a a server (or client). =46rom a PKI perspective, the cert that =
represents
>>> a server or client MUST be an EE cert,
>>=20
>> Like an X.509v1 self-signed EE cert.  Works perfectly fine with all
>> TLS implementations that I've met.
>>=20
>> Keep in mind that TLS is not limited to X.509v3 certs.
>>=20
>>   TLSv1.0:    http://tools.ietf.org/html/rfc2246#section-7.4.2
>>   TLSv1.1:    http://tools.ietf.org/html/rfc4346#section-7.4.2
>>=20
>>    7.4.2. Server certificate
>>=20
>>       [...]
>>=20
>>    Meaning of this message:
>>        The certificate type must be appropriate for the selected =
cipher
>>        suite's key exchange algorithm, and is generally an X.509v3
>>        certificate. It must contain a key which matches the key =
exchange
>>        method, as follows.
>>=20
>>=20
>>>=20
>>> an thus cannot be self-signed.
>>=20
>> TLSv1.0 and TLSv1.1 have neither a problem with X.509v1 nor
>> with a self-signed X.509v1 End-Entity cert.
>>=20
>>=20
>>> The fact that many implementations
>>> violate IETF PKI standards in this regard, is unfortunate, but it is =
not
>>> a basis for issuing a new IETF standard that codifies this behavior.
>>=20
>> I know that there are lots of commercial CAs that still have CA certs
>> in every browser that are not valid CA certs according to PKIX / RFC =
5280.
>>=20
>> But having TLSv1.0&TLSv1.1 (i.e. 99% of the installed base)
>> accept X.509v1 self-signed EE certs is perfectly fine.
>>=20
>> X.509v1 is fairly close to a bare key, supported by all TLS =
implementations
>> in the installed base, as well as tools in the installed base, such =
as
>> the openssl.exe shell and for transfering keypairs within =
PKCS#12/PFX.
>=20
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane


From [e-mail]  Fri Apr  8 05:53:46 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B526628C0E7 for <[e-mail]>; Fri,  8 Apr 2011 05:53:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.3
X-Spam-Level: 
X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.000,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVLCxEu4rJ2V for <[e-mail]>; Fri,  8 Apr 2011 05:53:44 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id 2B7D328C0DF for <[e-mail]>; Fri,  8 Apr 2011 05:53:44 -0700 (PDT)
Received: from dhcp-205.office.nic.cz (unknown [IPv6:2001:1488:ac14:1400:226:bbff:fe17:a705]) by mail.nic.cz (Postfix) with ESMTPSA id 7D05B2A0208; Fri,  8 Apr 2011 14:55:28 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Fri, 08 Apr 2011 14:55:28 +0200
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[e-mail]>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: "Richard L. Barnes" <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.96.5 at mail
X-Virus-Status: Clean
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2011 12:53:46 -0000

Richard,

to rephrase my request:  I want to make life easier for people deploying 
the TLS on their sites.  I think that's the whole reason for the 
existence of this working group.  If the self-signed cert without the CA 
bits is malformed then we need some solution for this.

And we cannot simply ignore the fact that the people are using 
"malformed" certificates in the wild.  At least it needs to go to the 
use cases document, because it is a real use case (which is really used 
by people out there).

Ondrej

On 4/8/11 2:46 PM, Richard L. Barnes wrote:
> To note again: The phrase "self-signed EE cert" does not make sense.  From RFC 5280:
> "
> Self-issued certificates are generated to support changes in policy or operations.  Self-signed certificates are self-issued certificates where the digital signature may be verified by the public key bound into the certificate.
> "
> Since a self-signed cert has a cert issued under it (itself), it has to be a CA cert.
>
> A self-signed cert *without* the CA bits set is therefore malformed, and will not pass PKIX validation.
>
> Which brings us back to the point that if you want certs that really aren't signed by anybody, you might as well be using bare keys, or some new data structure that only carries what you're interested in, e.g., key parameters but not key usage, names, issuer, etc.
>
> --Richard
>
>
>
>
> On Apr 8, 2011, at 8:36 AM, Ondřej Surý wrote:
>
>> My question to the list is if we can avoid specifying which X.509 version the client/server has to use and leave it to the client policy.
>>
>> Martin's approach seems like a reasonable one, but the question is if we can fit it into our draft without advice to break any existing standard.
>>
>> I know that we are standards group (to reply to PHB later in this thread), but we also cannot afford to ignore what's happening in the real world otherwise the world is going to ignore us.
>>
>> I think that usage of self-signed EE cert is a reasonable use case (which may or may not make it to the protocol) and it shouldn't be left out.  So please everybody let's think harder how to make things for non-protocol-geeks out there simpler, so the fruit of our work is a tasty one and not bittersweet.
>>
>> O.
>>
>> On 4/8/11 4:58 AM, Martin Rex wrote:
>>> Stephen Kent wrote:
>>>>
>>>> James Cloos wrote:
>>>>>
>>>>> EE certs in the rr is in all of the drafts, was the original target, is
>>>>> easy to understand and explain, and I've read more consensus for than
>>>>> against on the list.
>>>>>
>>>>> Why the sudden backlash against?
>>>>
>>>> It's not sudden :-). A self-signed cert is a CA cert, by definition (see
>>>> the cites to RFC 5280 in Paul's I-D.
>>>
>>> RFC 5280 is about X.509v3 certs _ONLY_.
>>>
>>> There is NO problem creating X.509v1 End-Entity certs that are self-signed.
>>> And there is no problem using any of these with implementations of
>>> SSLv3 and TLSv1.0.
>>>
>>> SSLv3 predates IETF PKIX standards, and TLSv1.0 is related to
>>> rfc-2459 rather than rfc-5280 -- but implementations of TLSv1.0
>>> were often shipped before publication of TLSv1.0 (rfc-2246) and
>>> the original PKIX certificate profile (rfc-2459).
>>>
>>>
>>> For safety, it would be sensible to ALWAYS treat X.509v1 certs as
>>> EndEntity certs (i.e. never accept them as signer of other certs).
>>> Our TLS implementation had done this initially, but we had a customer
>>> that had obtained server certs issued under a VeriSign X.509v1 CA cert
>>> (as late as 2006!), so I had to make our OEM implementation tolerate this.
>>>
>>>
>>>
>>>>
>>>> The TLS spec talks in terms of an "end entity's cert" as representing
>>>> a a server (or client). From a PKI perspective, the cert that represents
>>>> a server or client MUST be an EE cert,
>>>
>>> Like an X.509v1 self-signed EE cert.  Works perfectly fine with all
>>> TLS implementations that I've met.
>>>
>>> Keep in mind that TLS is not limited to X.509v3 certs.
>>>
>>>    TLSv1.0:    http://tools.ietf.org/html/rfc2246#section-7.4.2
>>>    TLSv1.1:    http://tools.ietf.org/html/rfc4346#section-7.4.2
>>>
>>>     7.4.2. Server certificate
>>>
>>>        [...]
>>>
>>>     Meaning of this message:
>>>         The certificate type must be appropriate for the selected cipher
>>>         suite's key exchange algorithm, and is generally an X.509v3
>>>         certificate. It must contain a key which matches the key exchange
>>>         method, as follows.
>>>
>>>
>>>>
>>>> an thus cannot be self-signed.
>>>
>>> TLSv1.0 and TLSv1.1 have neither a problem with X.509v1 nor
>>> with a self-signed X.509v1 End-Entity cert.
>>>
>>>
>>>> The fact that many implementations
>>>> violate IETF PKI standards in this regard, is unfortunate, but it is not
>>>> a basis for issuing a new IETF standard that codifies this behavior.
>>>
>>> I know that there are lots of commercial CAs that still have CA certs
>>> in every browser that are not valid CA certs according to PKIX / RFC 5280.
>>>
>>> But having TLSv1.0&TLSv1.1 (i.e. 99% of the installed base)
>>> accept X.509v1 self-signed EE certs is perfectly fine.
>>>
>>> X.509v1 is fairly close to a bare key, supported by all TLS implementations
>>> in the installed base, as well as tools in the installed base, such as
>>> the openssl.exe shell and for transfering keypairs within PKCS#12/PFX.
>>
>> _______________________________________________
>> dane mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dane
>


From [e-mail]  Fri Apr  8 06:07:58 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 947143A6925 for <[e-mail]>; Fri,  8 Apr 2011 06:07:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.123
X-Spam-Level: 
X-Spam-Status: No, score=-102.123 tagged_above=-999 required=5 tests=[AWL=0.476, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ObgiVzHPwJ1S for <[e-mail]>; Fri,  8 Apr 2011 06:07:57 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by core3.amsl.com (Postfix) with ESMTP id DF1323A6920 for <[e-mail]>; Fri,  8 Apr 2011 06:07:56 -0700 (PDT)
Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p38D9bBG024560 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 8 Apr 2011 06:09:38 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Paul Hoffman <[e-mail]>
In-Reply-To: <BANLkTi=mLJ4Ohr-=[e-mail]>
Date: Fri, 8 Apr 2011 06:09:37 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <p06240805c9c25b23464a@128.89.89.213> <[e-mail]> <p06240800c9c3e03a9624@128.89.89.213> <BANLkTin=[e-mail]> <[e-mail]> <BANLkTi=mLJ4Ohr-=[e-mail]>
To: Ben Laurie <[e-mail]>
X-Mailer: Apple Mail (2.1084)
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2011 13:07:58 -0000

On Apr 8, 2011, at 5:46 AM, Ben Laurie wrote:

> On 8 April 2011 13:33, Paul Hoffman <[e-mail]> wrote:
>> I note, again, that this has *nothing* to do with use cases or =
requirements. Having said that...
>=20
> I've already stated my requirement (that self-signed certs should be =
usable).

Sorry, you're right, you did. (Well, you said that they must be =
"first-class citizens", which is even more specific than "usable").

--Paul Hoffman


From [e-mail]  Fri Apr  8 06:15:19 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66DE33A6925 for <[e-mail]>; Fri,  8 Apr 2011 06:15:19 -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.323, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9SC9NHpj+Tc for <[e-mail]>; Fri,  8 Apr 2011 06:15:19 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by core3.amsl.com (Postfix) with ESMTP id 6A27128C114 for <[e-mail]>; Fri,  8 Apr 2011 06:15:18 -0700 (PDT)
Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p38DGwKS024968 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 8 Apr 2011 06:16:59 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=utf-8
From: Paul Hoffman <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Fri, 8 Apr 2011 06:16:58 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= <[e-mail]>
X-Mailer: Apple Mail (2.1084)
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2011 13:15:19 -0000

On Apr 8, 2011, at 5:55 AM, Ond=C5=99ej Sur=C3=BD wrote:

> Richard,
>=20
> to rephrase my request:  I want to make life easier for people =
deploying the TLS on their sites.  I think that's the whole reason for =
the existence of this working group.  If the self-signed cert without =
the CA bits is malformed then we need some solution for this.

If the requirement is to allow a particular kind of malformed PKIX cert, =
then the solution would be "allow this particular kind of malformation". =
That is what Jakob and I proposed in the current draft.

Note that the WG can specify anything it wants about this type of =
malformed PKIX cert. For example, we might require that the Issuer name =
and the Subject name must be identical, or we might not.

--Paul Hoffman


From [e-mail]  Fri Apr  8 06:16:45 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A39FF28C0F2 for <[e-mail]>; Fri,  8 Apr 2011 06:16:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.1
X-Spam-Level: 
X-Spam-Status: No, score=-3.1 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfkOIdk7B-sm for <[e-mail]>; Fri,  8 Apr 2011 06:16:45 -0700 (PDT)
Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id EAE8E3A691F for <[e-mail]>; Fri,  8 Apr 2011 06:16:44 -0700 (PDT)
Received: by qyk7 with SMTP id 7so2308393qyk.10 for <[e-mail]>; Fri, 08 Apr 2011 06:18:30 -0700 (PDT)
Received: by 10.229.64.84 with SMTP id d20mr1744332qci.206.1302268709922; Fri, 08 Apr 2011 06:18:29 -0700 (PDT)
Received: from [192.168.1.4] (pool-173-79-111-27.washdc.fios.verizon.net [173.79.111.27]) by mx.google.com with ESMTPS id m3sm1912177qck.26.2011.04.08.06.18.27 (version=SSLv3 cipher=OTHER); Fri, 08 Apr 2011 06:18:28 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.2.0.101115
Date: Fri, 08 Apr 2011 09:18:25 -0400
From: Carl Wallace <[e-mail]>
To: "Richard L. Barnes" <[e-mail]>, =?ISO-8859-2?B?T25k+GVq?= =?ISO-8859-2?B?IFN1cv0=?= <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: [dane] [keyassure] Use cases document.
In-Reply-To: <[e-mail]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2011 13:16:45 -0000

On 4/8/11 8:46 AM, "Richard L. Barnes" <[e-mail]> wrote:

>To note again: The phrase "self-signed EE cert" does not make sense.
>From RFC 5280:
>"
>Self-issued certificates are generated to support changes in policy or
>operations.  Self-signed certificates are self-issued certificates where
>the digital signature may be verified by the public key bound into the
>certificate.
>"
>Since a self-signed cert has a cert issued under it (itself), it has to
>be a CA cert.
>
>A self-signed cert *without* the CA bits set is therefore malformed, and
>will not pass PKIX validation.

Why would you build a chain with the same certificate twice?  A
self-signed certificate needs to be explicitly trusted (i.e., it needs to
be a TA).  5280 does not mandate any content for a trust anchor other than
name and key so the extensions are not needed.  You would have to put
together a chain that repeated the self-signed certificate three times to
grow requirements for extensions.  Since one can opt to trust any name/key
one pleases, a self-signed EE certificate makes perfect sense, assuming
there's a means to establish trust and constrain its usage.


>Which brings us back to the point that if you want certs that really
>aren't signed by anybody, you might as well be using bare keys, or some
>new data structure that only carries what you're interested in, e.g., key
>parameters but not key usage, names, issuer, etc.
>--Richard



From [e-mail]  Fri Apr  8 06:18:07 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7643928C117 for <[e-mail]>; Fri,  8 Apr 2011 06:18:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.977
X-Spam-Level: 
X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9HmOm01PaMJ for <[e-mail]>; Fri,  8 Apr 2011 06:18:06 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 4E6C528C106 for <[e-mail]>; Fri,  8 Apr 2011 06:18:06 -0700 (PDT)
Received: from kpbe12.cbf.corp.google.com (kpbe12.cbf.corp.google.com [172.25.105.76]) by smtp-out.google.com with ESMTP id p38DJo0C014358 for <[e-mail]>; Fri, 8 Apr 2011 06:19:51 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1302268791; bh=DifTa4g3C7vCGI1Jr18NL6qgwFU=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=QDOU6UtalKXv7Dd/uxocWh5USDcMSiDnOUKUXRcx20HUdSp/z9t8Xu7CDQ3XuYNaX mEElZ0oS7RmFeL2s0XFKQ==
Received: from vws18 (vws18.prod.google.com [10.241.21.146]) by kpbe12.cbf.corp.google.com with ESMTP id p38DJnxj001910 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <[e-mail]>; Fri, 8 Apr 2011 06:19:49 -0700
Received: by vws18 with SMTP id 18so3812020vws.41 for <[e-mail]>; Fri, 08 Apr 2011 06:19:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=KxLkFzxslqka5/iGyaqC6LeJuQEBnJOKTm+jcG+mJmg=; b=mafR4jAs8xRyvqCoCBNDT3Kg1TU9ZTnFPKmZZqBE0hGYF62VUsIE8VZL4fXd1sYbId 6STs92aBfRnFhs8aIspA==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=IcvJszUQaGN3PWF0o2C1wvBKvCP5qb0p8p3TYzAu5xcsj+dniQv/p5zASQZGyPnZ4I 3jdKOYi62r3rYmkrmeMg==
MIME-Version: 1.0
Received: by 10.220.172.144 with SMTP id l16mr609545vcz.190.1302268789084; Fri, 08 Apr 2011 06:19:49 -0700 (PDT)
Received: by 10.220.117.12 with HTTP; Fri, 8 Apr 2011 06:19:46 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 8 Apr 2011 14:19:46 +0100
Message-ID: <BANLkTinOTTWSbHcGCTFN=[e-mail]>
From: Ben Laurie <[e-mail]>
To: "Richard L. Barnes" <[e-mail]>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2011 13:18:07 -0000

On 8 April 2011 13:46, Richard L. Barnes <[e-mail]> wrote:
> To note again: The phrase "self-signed EE cert" does not make sense. =C2=
=A0From RFC 5280:
> "
> Self-issued certificates are generated to support changes in policy or op=
erations. =C2=A0Self-signed certificates are self-issued certificates where=
 the digital signature may be verified by the public key bound into the cer=
tificate.
> "
> Since a self-signed cert has a cert issued under it (itself), it has to b=
e a CA cert.
>
> A self-signed cert *without* the CA bits set is therefore malformed, and =
will not pass PKIX validation.

This may be true in theory, but is far from true in practice - in
practice, I can put a self-signed cert on my website and it works just
fine (in the sense that it is not considered malformed, just rather
untrustworthy).

So, this is just spec lawyering.

>
> Which brings us back to the point that if you want certs that really aren=
't signed by anybody, you might as well be using bare keys, or some new dat=
a structure that only carries what you're interested in, e.g., key paramete=
rs but not key usage, names, issuer, etc.
>
> --Richard
>
>
>
>
> On Apr 8, 2011, at 8:36 AM, Ond=C5=99ej Sur=C3=BD wrote:
>
>> My question to the list is if we can avoid specifying which X.509 versio=
n the client/server has to use and leave it to the client policy.
>>
>> Martin's approach seems like a reasonable one, but the question is if we=
 can fit it into our draft without advice to break any existing standard.
>>
>> I know that we are standards group (to reply to PHB later in this thread=
), but we also cannot afford to ignore what's happening in the real world o=
therwise the world is going to ignore us.
>>
>> I think that usage of self-signed EE cert is a reasonable use case (whic=
h may or may not make it to the protocol) and it shouldn't be left out. =C2=
=A0So please everybody let's think harder how to make things for non-protoc=
ol-geeks out there simpler, so the fruit of our work is a tasty one and not=
 bittersweet.
>>
>> O.
>>
>> On 4/8/11 4:58 AM, Martin Rex wrote:
>>> Stephen Kent wrote:
>>>>
>>>> James Cloos wrote:
>>>>>
>>>>> EE certs in the rr is in all of the drafts, was the original target, =
is
>>>>> easy to understand and explain, and I've read more consensus for than
>>>>> against on the list.
>>>>>
>>>>> Why the sudden backlash against?
>>>>
>>>> It's not sudden :-). A self-signed cert is a CA cert, by definition (s=
ee
>>>> the cites to RFC 5280 in Paul's I-D.
>>>
>>> RFC 5280 is about X.509v3 certs _ONLY_.
>>>
>>> There is NO problem creating X.509v1 End-Entity certs that are self-sig=
ned.
>>> And there is no problem using any of these with implementations of
>>> SSLv3 and TLSv1.0.
>>>
>>> SSLv3 predates IETF PKIX standards, and TLSv1.0 is related to
>>> rfc-2459 rather than rfc-5280 -- but implementations of TLSv1.0
>>> were often shipped before publication of TLSv1.0 (rfc-2246) and
>>> the original PKIX certificate profile (rfc-2459).
>>>
>>>
>>> For safety, it would be sensible to ALWAYS treat X.509v1 certs as
>>> EndEntity certs (i.e. never accept them as signer of other certs).
>>> Our TLS implementation had done this initially, but we had a customer
>>> that had obtained server certs issued under a VeriSign X.509v1 CA cert
>>> (as late as 2006!), so I had to make our OEM implementation tolerate th=
is.
>>>
>>>
>>>
>>>>
>>>> The TLS spec talks in terms of an "end entity's cert" as representing
>>>> a a server (or client). From a PKI perspective, the cert that represen=
ts
>>>> a server or client MUST be an EE cert,
>>>
>>> Like an X.509v1 self-signed EE cert. =C2=A0Works perfectly fine with al=
l
>>> TLS implementations that I've met.
>>>
>>> Keep in mind that TLS is not limited to X.509v3 certs.
>>>
>>> =C2=A0 TLSv1.0: =C2=A0 =C2=A0http://tools.ietf.org/html/rfc2246#section=
-7.4.2
>>> =C2=A0 TLSv1.1: =C2=A0 =C2=A0http://tools.ietf.org/html/rfc4346#section=
-7.4.2
>>>
>>> =C2=A0 =C2=A07.4.2. Server certificate
>>>
>>> =C2=A0 =C2=A0 =C2=A0 [...]
>>>
>>> =C2=A0 =C2=A0Meaning of this message:
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0The certificate type must be appropriate for=
 the selected cipher
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0suite's key exchange algorithm, and is gener=
ally an X.509v3
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0certificate. It must contain a key which mat=
ches the key exchange
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0method, as follows.
>>>
>>>
>>>>
>>>> an thus cannot be self-signed.
>>>
>>> TLSv1.0 and TLSv1.1 have neither a problem with X.509v1 nor
>>> with a self-signed X.509v1 End-Entity cert.
>>>
>>>
>>>> The fact that many implementations
>>>> violate IETF PKI standards in this regard, is unfortunate, but it is n=
ot
>>>> a basis for issuing a new IETF standard that codifies this behavior.
>>>
>>> I know that there are lots of commercial CAs that still have CA certs
>>> in every browser that are not valid CA certs according to PKIX / RFC 52=
80.
>>>
>>> But having TLSv1.0&TLSv1.1 (i.e. 99% of the installed base)
>>> accept X.509v1 self-signed EE certs is perfectly fine.
>>>
>>> X.509v1 is fairly close to a bare key, supported by all TLS implementat=
ions
>>> in the installed base, as well as tools in the installed base, such as
>>> the openssl.exe shell and for transfering keypairs within PKCS#12/PFX.
>>
>> _______________________________________________
>> dane mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dane
>
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane
>

From [e-mail]  Fri Apr  8 06:30:52 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8BDA28C11C for <[e-mail]>; Fri,  8 Apr 2011 06:30:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3
X-Spam-Level: 
X-Spam-Status: No, score=-3 tagged_above=-999 required=5 tests=[AWL=-0.402, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nL7xhQBm30Pb for <[e-mail]>; Fri,  8 Apr 2011 06:30:50 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 6408428C106 for <[e-mail]>; Fri,  8 Apr 2011 06:30:50 -0700 (PDT)
Received: by vxg33 with SMTP id 33so3290994vxg.31 for <[e-mail]>; Fri, 08 Apr 2011 06:32:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9P0wAY/eoQQB2PQf2jUufVfI85DWZHTNusHo1+lchEU=; b=N3ah/JXSWFMJkWj29KDNGlRe0FsHKkbKGn6YyIe/MbQxkG7K68UqQht6Hh2/6sF4Zi WydCWQvFuW4B20vdCt6Zjvd08+BbKbM5iRaDt1gqOQ48ypfCVgd7WPSppjsRp9W+K845 PdELTR75q7Xb/3eDMjmYIsg/3+iYQI/cIrZ7U=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=uqKJ7erKyuUl7xXzH5oFCWH4gDXJyNchoR6Sn7r2h0wRek/J3x9FXWr20J686Ta7O0 T2oj4gScWA5q6Z+r4rTk5LB24l2DuLSQmiw7SlBV2vEj1PPWQvO50CQ7qLrnyha+Atum gIu7UMiG7j1W8xS5g/30QW5P2+EEI4OtQ/IRI=
MIME-Version: 1.0
Received: by 10.52.98.135 with SMTP id ei7mr1538602vdb.229.1302269555409; Fri, 08 Apr 2011 06:32:35 -0700 (PDT)
Received: by 10.52.166.230 with HTTP; Fri, 8 Apr 2011 06:32:35 -0700 (PDT)
In-Reply-To: <BANLkTinOTTWSbHcGCTFN=[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <BANLkTinOTTWSbHcGCTFN=[e-mail]>
Date: Fri, 8 Apr 2011 13:32:35 +0000
Message-ID: <BANLkTi=pYha_Ne1a4qGOgAUK_9c=[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: Ben Laurie <[e-mail]>
Content-Type: multipart/alternative; boundary=20cf307cfc6840850204a0684200
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2011 13:30:52 -0000

--20cf307cfc6840850204a0684200
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

The solution to standards lawyering is more standards lawyering.


Strictly speaking a self-signed certificate that does not have the CA bit
set is a valid X.509v3/PKIX certificate with an invalid signature.

Since the signature is invalid, it must be rejected when it is verified.

This is of no consequence because there is no point in checking the
signature on a self signed cert.

So just (1) write the spec accordingly and (2) drop a defect report into th=
e
ITU process proposing to allow self-signed certs in order to align the
standards documentation with actual practice.


On Fri, Apr 8, 2011 at 1:19 PM, Ben Laurie <[e-mail]> wrote:

> On 8 April 2011 13:46, Richard L. Barnes <[e-mail]> wrote:
> > To note again: The phrase "self-signed EE cert" does not make sense.
>  From RFC 5280:
> > "
> > Self-issued certificates are generated to support changes in policy or
> operations.  Self-signed certificates are self-issued certificates where =
the
> digital signature may be verified by the public key bound into the
> certificate.
> > "
> > Since a self-signed cert has a cert issued under it (itself), it has to
> be a CA cert.
> >
> > A self-signed cert *without* the CA bits set is therefore malformed, an=
d
> will not pass PKIX validation.
>
> This may be true in theory, but is far from true in practice - in
> practice, I can put a self-signed cert on my website and it works just
> fine (in the sense that it is not considered malformed, just rather
> untrustworthy).
>
> So, this is just spec lawyering.
>
> >
> > Which brings us back to the point that if you want certs that really
> aren't signed by anybody, you might as well be using bare keys, or some n=
ew
> data structure that only carries what you're interested in, e.g., key
> parameters but not key usage, names, issuer, etc.
> >
> > --Richard
> >
> >
> >
> >
> > On Apr 8, 2011, at 8:36 AM, Ond=C5=99ej Sur=C3=BD wrote:
> >
> >> My question to the list is if we can avoid specifying which X.509
> version the client/server has to use and leave it to the client policy.
> >>
> >> Martin's approach seems like a reasonable one, but the question is if =
we
> can fit it into our draft without advice to break any existing standard.
> >>
> >> I know that we are standards group (to reply to PHB later in this
> thread), but we also cannot afford to ignore what's happening in the real
> world otherwise the world is going to ignore us.
> >>
> >> I think that usage of self-signed EE cert is a reasonable use case
> (which may or may not make it to the protocol) and it shouldn't be left o=
ut.
>  So please everybody let's think harder how to make things for
> non-protocol-geeks out there simpler, so the fruit of our work is a tasty
> one and not bittersweet.
> >>
> >> O.
> >>
> >> On 4/8/11 4:58 AM, Martin Rex wrote:
> >>> Stephen Kent wrote:
> >>>>
> >>>> James Cloos wrote:
> >>>>>
> >>>>> EE certs in the rr is in all of the drafts, was the original target=
,
> is
> >>>>> easy to understand and explain, and I've read more consensus for th=
an
> >>>>> against on the list.
> >>>>>
> >>>>> Why the sudden backlash against?
> >>>>
> >>>> It's not sudden :-). A self-signed cert is a CA cert, by definition
> (see
> >>>> the cites to RFC 5280 in Paul's I-D.
> >>>
> >>> RFC 5280 is about X.509v3 certs _ONLY_.
> >>>
> >>> There is NO problem creating X.509v1 End-Entity certs that are
> self-signed.
> >>> And there is no problem using any of these with implementations of
> >>> SSLv3 and TLSv1.0.
> >>>
> >>> SSLv3 predates IETF PKIX standards, and TLSv1.0 is related to
> >>> rfc-2459 rather than rfc-5280 -- but implementations of TLSv1.0
> >>> were often shipped before publication of TLSv1.0 (rfc-2246) and
> >>> the original PKIX certificate profile (rfc-2459).
> >>>
> >>>
> >>> For safety, it would be sensible to ALWAYS treat X.509v1 certs as
> >>> EndEntity certs (i.e. never accept them as signer of other certs).
> >>> Our TLS implementation had done this initially, but we had a customer
> >>> that had obtained server certs issued under a VeriSign X.509v1 CA cer=
t
> >>> (as late as 2006!), so I had to make our OEM implementation tolerate
> this.
> >>>
> >>>
> >>>
> >>>>
> >>>> The TLS spec talks in terms of an "end entity's cert" as representin=
g
> >>>> a a server (or client). From a PKI perspective, the cert that
> represents
> >>>> a server or client MUST be an EE cert,
> >>>
> >>> Like an X.509v1 self-signed EE cert.  Works perfectly fine with all
> >>> TLS implementations that I've met.
> >>>
> >>> Keep in mind that TLS is not limited to X.509v3 certs.
> >>>
> >>>   TLSv1.0:    http://tools.ietf.org/html/rfc2246#section-7.4.2
> >>>   TLSv1.1:    http://tools.ietf.org/html/rfc4346#section-7.4.2
> >>>
> >>>    7.4.2. Server certificate
> >>>
> >>>       [...]
> >>>
> >>>    Meaning of this message:
> >>>        The certificate type must be appropriate for the selected ciph=
er
> >>>        suite's key exchange algorithm, and is generally an X.509v3
> >>>        certificate. It must contain a key which matches the key
> exchange
> >>>        method, as follows.
> >>>
> >>>
> >>>>
> >>>> an thus cannot be self-signed.
> >>>
> >>> TLSv1.0 and TLSv1.1 have neither a problem with X.509v1 nor
> >>> with a self-signed X.509v1 End-Entity cert.
> >>>
> >>>
> >>>> The fact that many implementations
> >>>> violate IETF PKI standards in this regard, is unfortunate, but it is
> not
> >>>> a basis for issuing a new IETF standard that codifies this behavior.
> >>>
> >>> I know that there are lots of commercial CAs that still have CA certs
> >>> in every browser that are not valid CA certs according to PKIX / RFC
> 5280.
> >>>
> >>> But having TLSv1.0&TLSv1.1 (i.e. 99% of the installed base)
> >>> accept X.509v1 self-signed EE certs is perfectly fine.
> >>>
> >>> X.509v1 is fairly close to a bare key, supported by all TLS
> implementations
> >>> in the installed base, as well as tools in the installed base, such a=
s
> >>> the openssl.exe shell and for transfering keypairs within PKCS#12/PFX=
.
> >>
> >> _______________________________________________
> >> dane mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/dane
> >
> > _______________________________________________
> > dane mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dane
> >
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane
>



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

--20cf307cfc6840850204a0684200
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div>The solution to standards lawyering is more standards lawyering.</div>=
<div><br></div><div><br></div><div>Strictly speaking a self-signed certific=
ate that does not have the CA bit set is a valid X.509v3/PKIX certificate w=
ith an invalid signature.</div>
<div><br></div><div>Since the signature is invalid, it must be rejected whe=
n it is verified.</div><div><br></div><div>This is of no consequence becaus=
e there is no point in checking the signature on a self signed cert.</div>
<div><br></div><div>So just (1) write the spec accordingly and (2) drop a d=
efect report into the ITU process proposing to allow self-signed certs in o=
rder to align the standards documentation with actual practice.</div><div>
<br></div><div><br></div>On Fri, Apr 8, 2011 at 1:19 PM, Ben Laurie <span d=
ir=3D"ltr">&lt;<a href=3D"mailto:[e-mail]">[e-mail]</a>&gt;</=
span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">On 8 April 2011 13:46, Richard L. Barnes &lt;<a href=3D"m=
ailto:[e-mail]">[e-mail]</a>&gt; wrote:<br>
&gt; To note again: The phrase &quot;self-signed EE cert&quot; does not mak=
e sense. =C2=A0From RFC 5280:<br>
&gt; &quot;<br>
&gt; Self-issued certificates are generated to support changes in policy or=
 operations. =C2=A0Self-signed certificates are self-issued certificates wh=
ere the digital signature may be verified by the public key bound into the =
certificate.<br>

&gt; &quot;<br>
&gt; Since a self-signed cert has a cert issued under it (itself), it has t=
o be a CA cert.<br>
&gt;<br>
&gt; A self-signed cert *without* the CA bits set is therefore malformed, a=
nd will not pass PKIX validation.<br>
<br>
</div>This may be true in theory, but is far from true in practice - in<br>
practice, I can put a self-signed cert on my website and it works just<br>
fine (in the sense that it is not considered malformed, just rather<br>
untrustworthy).<br>
<br>
So, this is just spec lawyering.<br>
<div><div></div><div class=3D"h5"><br>
&gt;<br>
&gt; Which brings us back to the point that if you want certs that really a=
ren&#39;t signed by anybody, you might as well be using bare keys, or some =
new data structure that only carries what you&#39;re interested in, e.g., k=
ey parameters but not key usage, names, issuer, etc.<br>

&gt;<br>
&gt; --Richard<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Apr 8, 2011, at 8:36 AM, Ond=C5=99ej Sur=C3=BD wrote:<br>
&gt;<br>
&gt;&gt; My question to the list is if we can avoid specifying which X.509 =
version the client/server has to use and leave it to the client policy.<br>
&gt;&gt;<br>
&gt;&gt; Martin&#39;s approach seems like a reasonable one, but the questio=
n is if we can fit it into our draft without advice to break any existing s=
tandard.<br>
&gt;&gt;<br>
&gt;&gt; I know that we are standards group (to reply to PHB later in this =
thread), but we also cannot afford to ignore what&#39;s happening in the re=
al world otherwise the world is going to ignore us.<br>
&gt;&gt;<br>
&gt;&gt; I think that usage of self-signed EE cert is a reasonable use case=
 (which may or may not make it to the protocol) and it shouldn&#39;t be lef=
t out. =C2=A0So please everybody let&#39;s think harder how to make things =
for non-protocol-geeks out there simpler, so the fruit of our work is a tas=
ty one and not bittersweet.<br>

&gt;&gt;<br>
&gt;&gt; O.<br>
&gt;&gt;<br>
&gt;&gt; On 4/8/11 4:58 AM, Martin Rex wrote:<br>
&gt;&gt;&gt; Stephen Kent wrote:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; James Cloos wrote:<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; EE certs in the rr is in all of the drafts, was the or=
iginal target, is<br>
&gt;&gt;&gt;&gt;&gt; easy to understand and explain, and I&#39;ve read more=
 consensus for than<br>
&gt;&gt;&gt;&gt;&gt; against on the list.<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; Why the sudden backlash against?<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; It&#39;s not sudden :-). A self-signed cert is a CA cert, =
by definition (see<br>
&gt;&gt;&gt;&gt; the cites to RFC 5280 in Paul&#39;s I-D.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; RFC 5280 is about X.509v3 certs _ONLY_.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; There is NO problem creating X.509v1 End-Entity certs that are=
 self-signed.<br>
&gt;&gt;&gt; And there is no problem using any of these with implementation=
s of<br>
&gt;&gt;&gt; SSLv3 and TLSv1.0.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; SSLv3 predates IETF PKIX standards, and TLSv1.0 is related to<=
br>
&gt;&gt;&gt; rfc-2459 rather than rfc-5280 -- but implementations of TLSv1.=
0<br>
&gt;&gt;&gt; were often shipped before publication of TLSv1.0 (rfc-2246) an=
d<br>
&gt;&gt;&gt; the original PKIX certificate profile (rfc-2459).<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; For safety, it would be sensible to ALWAYS treat X.509v1 certs=
 as<br>
&gt;&gt;&gt; EndEntity certs (i.e. never accept them as signer of other cer=
ts).<br>
&gt;&gt;&gt; Our TLS implementation had done this initially, but we had a c=
ustomer<br>
&gt;&gt;&gt; that had obtained server certs issued under a VeriSign X.509v1=
 CA cert<br>
&gt;&gt;&gt; (as late as 2006!), so I had to make our OEM implementation to=
lerate this.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; The TLS spec talks in terms of an &quot;end entity&#39;s c=
ert&quot; as representing<br>
&gt;&gt;&gt;&gt; a a server (or client). From a PKI perspective, the cert t=
hat represents<br>
&gt;&gt;&gt;&gt; a server or client MUST be an EE cert,<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Like an X.509v1 self-signed EE cert. =C2=A0Works perfectly fin=
e with all<br>
&gt;&gt;&gt; TLS implementations that I&#39;ve met.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Keep in mind that TLS is not limited to X.509v3 certs.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; =C2=A0 TLSv1.0: =C2=A0 =C2=A0<a href=3D"http://tools.ietf.org/=
html/rfc2246#section-7.4.2" target=3D"_blank">http://tools.ietf.org/html/rf=
c2246#section-7.4.2</a><br>
&gt;&gt;&gt; =C2=A0 TLSv1.1: =C2=A0 =C2=A0<a href=3D"http://tools.ietf.org/=
html/rfc4346#section-7.4.2" target=3D"_blank">http://tools.ietf.org/html/rf=
c4346#section-7.4.2</a><br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; =C2=A0 =C2=A07.4.2. Server certificate<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; =C2=A0 =C2=A0 =C2=A0 [...]<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; =C2=A0 =C2=A0Meaning of this message:<br>
&gt;&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0The certificate type must be approp=
riate for the selected cipher<br>
&gt;&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0suite&#39;s key exchange algorithm,=
 and is generally an X.509v3<br>
&gt;&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0certificate. It must contain a key =
which matches the key exchange<br>
&gt;&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0method, as follows.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; an thus cannot be self-signed.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; TLSv1.0 and TLSv1.1 have neither a problem with X.509v1 nor<br=
>
&gt;&gt;&gt; with a self-signed X.509v1 End-Entity cert.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; The fact that many implementations<br>
&gt;&gt;&gt;&gt; violate IETF PKI standards in this regard, is unfortunate,=
 but it is not<br>
&gt;&gt;&gt;&gt; a basis for issuing a new IETF standard that codifies this=
 behavior.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; I know that there are lots of commercial CAs that still have C=
A certs<br>
&gt;&gt;&gt; in every browser that are not valid CA certs according to PKIX=
 / RFC 5280.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; But having TLSv1.0&amp;TLSv1.1 (i.e. 99% of the installed base=
)<br>
&gt;&gt;&gt; accept X.509v1 self-signed EE certs is perfectly fine.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; X.509v1 is fairly close to a bare key, supported by all TLS im=
plementations<br>
&gt;&gt;&gt; in the installed base, as well as tools in the installed base,=
 such as<br>
&gt;&gt;&gt; the openssl.exe shell and for transfering keypairs within PKCS=
#12/PFX.<br>
&gt;&gt;<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; dane mailing list<br>
&gt;&gt; <a href=3D"mailto:[e-mail]">[e-mail]</a><br>
&gt;&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_=
blank">https://www.ietf.org/mailman/listinfo/dane</a><br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; dane mailing list<br>
&gt; <a href=3D"mailto:[e-mail]">[e-mail]</a><br>
&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_blan=
k">https://www.ietf.org/mailman/listinfo/dane</a><br>
&gt;<br>
_______________________________________________<br>
dane mailing list<br>
<a href=3D"mailto:[e-mail]">[e-mail]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/dane</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a=
 href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>

--20cf307cfc6840850204a0684200--

From [e-mail]  Fri Apr  8 06:36:31 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE07B3A691F for <[e-mail]>; Fri,  8 Apr 2011 06:36:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.594
X-Spam-Level: 
X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=0.005,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vF3t635aguQy for <[e-mail]>; Fri,  8 Apr 2011 06:36:30 -0700 (PDT)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 3BE163A6912 for <[e-mail]>; Fri,  8 Apr 2011 06:36:30 -0700 (PDT)
Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 554E0C52B; Fri,  8 Apr 2011 09:38:13 -0400 (EDT)
Date: Fri, 8 Apr 2011 09:38:11 -0400 (EDT)
From: Paul Wouters <[e-mail]>
To: "Richard L. Barnes" <[e-mail]>
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: [e-mail]
Subject: [dane] elephant use case, was Re:  [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2011 13:36:31 -0000

On Fri, 8 Apr 2011, Richard L. Barnes wrote:

> Which brings us back to the point that if you want certs that really aren't signed by anybody, you might as well be using bare keys, or some new data structure that only carries what you're interested in, e.g., key parameters but not key usage, names, issuer, etc.

Which I have been advocating for before this working group formed. And
for which I've started a TLS extension draft and got some good feedback
to at the IETF in Prague. Expect the draft submission in the next week
or two. I'll notify the TLS and DANE working group when we have submitted
the draft.

Back on the use case document issue, as long as we are ignoring the
elephant in the room, this discussion will get no where. CA based PKIX
has failed. The EFF SSL Observatory data, along with the recent Comodo
disaster clearly shows this.

If you want a use case, look at this: https://www.eff.org/files/colour_map_of_CAs.pdf

650+ organisations world wide can sign a certificate for any website. How
many of these have been hacked? How many more unqualified or RFC1918 space
signed certificates do we need to show? While OCSP on an IPsec gateway is
good to have, putting it in a browser results in a huge privacy problem.
On top of that, the OCSP revoked certificate lists are secret. Knowing
a serial number is revoked does not tell anyone if that misissued
certificate was for one of their domains.  Not only is the trust model
of commercial CA's broken, its execution is too much of a secret for us
to even be able to classify and identify the risks and the attacks on it.

TLS clearly needs an alternative trust model. DANE is about providing
one using DNSSEC. There will be others.

This working group, along with the TLS working group, should ensure that
moving forward, people no longer have to rely on a single failed trust
model, but can have their own client policy pick from a variety of trust
models they believe in. It is up to us to provide them with that. 

A good solution to start with is certificates in DNSSEC. A logical
continuation of that is a TLS mechanism for out of bound trust.

These things were very much happening in the working group, even before the
school principal was sent into the working group meeting to check up on
the teachers and their students. Please let them continue to do their work.

Paul

From [e-mail]  Fri Apr  8 06:48:05 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A14328C118 for <[e-mail]>; Fri,  8 Apr 2011 06:48:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3ggsZHdqUTr for <[e-mail]>; Fri,  8 Apr 2011 06:48:04 -0700 (PDT)
Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by core3.amsl.com (Postfix) with ESMTP id 3D48D28C120 for <[e-mail]>; Fri,  8 Apr 2011 06:48:03 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 1949C3E409B; Fri,  8 Apr 2011 14:49:48 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1302270587; bh=TMU6odx6pqwm6M gJvfhRLJIZAgOxM/J5+2eGuwfv1Kk=; b=F9XWCepJJcpyGaWWwlIMYqdyJA2ELB 77aDS/z4WpJ1ehfDH/T7HKeWebADWOn94NPI39ajbr8MTza209CJQqNU/cyzjqn7 izKD7HRJIL/lr9ee84L6cJpYj/V8sjOdpjBCFbgpvq+SuJXrbO9oM/EF8WvyNjfW xvqYDcOnycR6J54yV1jH25i7rYbOyl26HRrGaMWqXnZ16hRRHr2j3kfl8UQYc0a+ M0LClLNGJRKjl2LdZeXJ2z1WM/2g3mKB8v9WLoj/3TlITA0feSGL5W6/+3Ukc9Dc ALSoHP6Ethu7YzAz+9NgLjcdRZfkrd3EFCD5rL25hd/98xw6kO5IV6Jw==
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id U9FyLwEN6W63; Fri,  8 Apr 2011 14:49:47 +0100 (IST)
Received: from [134.226.36.137] (stephen-samy.dsg.cs.tcd.ie [134.226.36.137]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 68A003E4092; Fri,  8 Apr 2011 14:49:47 +0100 (IST)
Message-ID: <[e-mail]>
Date: Fri, 08 Apr 2011 14:49:41 +0100
From: Stephen Farrell <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8
MIME-Version: 1.0
To: Ben Laurie <[e-mail]>
References: <[e-mail]>	<[e-mail]>	<[e-mail]> <BANLkTinOTTWSbHcGCTFN=[e-mail]>
In-Reply-To: <BANLkTinOTTWSbHcGCTFN=[e-mail]>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2011 13:48:05 -0000

On 08/04/11 14:19, Ben Laurie wrote:
> On 8 April 2011 13:46, Richard L. Barnes <[e-mail]> wrote:
>> To note again: The phrase "self-signed EE cert" does not make sense.  From RFC 5280:
>> "
>> Self-issued certificates are generated to support changes in policy or operations.  Self-signed certificates are self-issued certificates where the digital signature may be verified by the public key bound into the certificate.
>> "
>> Since a self-signed cert has a cert issued under it (itself), it has to be a CA cert.
>>
>> A self-signed cert *without* the CA bits set is therefore malformed, and will not pass PKIX validation.

I think you're wrong there. RFC 5280, end of 6.2 says:

   Implementations that use self-signed certificates to specify trust
   anchor information are free to process or ignore such information.

The "such information" being certificate extensions. I don't see
anywhere where it says that the basic constraints extension is
any different.

I also think the quoted text above is a tad misleading since its
from a paragraph that discusses how CA's might use self-signed
certs.

5280 is IMO properly silent on how EEs might use self-signed
certs. (Or if not, I've forgotten what it says on that;-)

> This may be true in theory, but is far from true in practice - in
> practice, I can put a self-signed cert on my website and it works just
> fine (in the sense that it is not considered malformed, just rather
> untrustworthy).
> 
> So, this is just spec lawyering.

Some data: both SIP (rfc3261) and S/MIME (rfc5750) explicitly
allow self-signed certs. SDP/TLS (rfc4572) seems to have an
entire section about them. And of course TLS (rfc5246) says
you MAY include them.

So it looks to me like there's nothing whatsoever preventing
this WG from choosing to use EE self-signed certs if you want
to do that.

S.


From [e-mail]  Fri Apr  8 07:01:26 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2EFB3A690F for <[e-mail]>; Fri,  8 Apr 2011 07:01:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.223
X-Spam-Level: 
X-Spam-Status: No, score=-10.223 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDJm-GbyyZb6 for <[e-mail]>; Fri,  8 Apr 2011 07:01:25 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 6F1B13A690C for <[e-mail]>; Fri,  8 Apr 2011 07:01:25 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p38E1ruJ001990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Apr 2011 16:01:53 +0200 (MEST)
From: Martin Rex <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail] (Richard L. Barnes)
Date: Fri, 8 Apr 2011 16:01:53 +0200 (MEST)
In-Reply-To: <[e-mail]> from "Richard L. Barnes" at Apr 8, 11 08:46:46 am
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: [e-mail]
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2011 14:01:26 -0000

Richard L. Barnes wrote:
> 
> To note again: The phrase "self-signed EE cert" does not make sense.
> From RFC 5280:
> "
> Self-issued certificates are generated to support changes in policy
> or operations.  Self-signed certificates are self-issued certificates
> where the digital signature may be verified by the public key bound
> into the certificate.
> "
> Since a self-signed cert has a cert issued under it (itself), it has
> to be a CA cert.
> 
> A self-signed cert *without* the CA bits set is therefore malformed,
> and will not pass PKIX validation.  


You seem to have entirely missed the most important of PKIX

  http://tools.ietf.org/html/rfc5280

   Abstract

   This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use
   in the Internet.


PKIX rules, by their own definition, do not apply to X.509v1 self-signed
EE certs.  And SSLv3, TLSv1.0 and TLSv1.1 are perfectly usable with X.509v1
self-signed EE certs.

 

It would be interesting to know from the SSLiverse database how many
TLS server certs on the internet are self-signed EE certs vs. CA-signed,
and how many of the self-signed TLS server certs are X.509v1.


-Martin

From [e-mail]  Fri Apr  8 07:44:17 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B18423A68DC for <[e-mail]>; Fri,  8 Apr 2011 07:44:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.997
X-Spam-Level: 
X-Spam-Status: No, score=-2.997 tagged_above=-999 required=5 tests=[AWL=-0.399, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id udT+aAW0e8Lm for <[e-mail]>; Fri,  8 Apr 2011 07:44:16 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 172963A683C for <[e-mail]>; Fri,  8 Apr 2011 07:44:16 -0700 (PDT)
Received: by vxg33 with SMTP id 33so3360316vxg.31 for <[e-mail]>; Fri, 08 Apr 2011 07:46:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+gEe00yMDJhgd1KGaEixHvNStvC07iWL/kt5RF0BKjI=; b=lqpJF88+CexG99UlnvTRC1cpZGB3VxUiI9trsETFI17m3DEsWhT2VHbSorJ9QJidCZ 6c6QEjpiu0TDukOwZdOsCOaUwjX/fNqnfg7SvFRJFCgQOudt70diBt2LWZJm/OEHe1K4 zlNQFVO++863StYllRnpnBM1pV9Twbb/a0tpM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=oRG889XB0S8dpaHPxB1wAaCLpSRAd/v0/GK+UkddjCdyt/8H27bG/xu+F8s+DEjLNJ VdW6gDp3celL/WlpIcMkWIqy+/hcxskuqOjF6WPObPe6xPKXbCk6EQ01zScDoYQOUdVq VDg0wkezJsWuoh32dkcsRSyY6lcadtgd2edq8=
MIME-Version: 1.0
Received: by 10.52.65.52 with SMTP id u20mr3345019vds.309.1302273961097; Fri, 08 Apr 2011 07:46:01 -0700 (PDT)
Received: by 10.52.166.230 with HTTP; Fri, 8 Apr 2011 07:46:01 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 8 Apr 2011 14:46:01 +0000
Message-ID: <[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: Paul Wouters <[e-mail]>
Content-Type: multipart/alternative; boundary=bcaec50166a5d9f9c004a06948dd
Cc: [e-mail]
Subject: Re: [dane] elephant use case, was Re: [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2011 14:44:17 -0000

--bcaec50166a5d9f9c004a06948dd
Content-Type: text/plain; charset=ISO-8859-1

Could people actually take some time to learn about what the EFF data means
before engaging in this hyperbole?

There are not and have never been 600 RA certs. The EFF people do not
understand what the data means or why the certs are configured the way they
are. In fact the pressure that we have had from Mozilla and other sources is
to increase the number of intermediate certs.

The main reason for not doing so is that there are people out there who
appear determined to misrepresent the implications.


An intermediate certificate does not imply an RA capability.
Nor does an RA capability require an intermediate certificate.


The two issues are completely separate. It is like measuring the number of
lawyers in Washington by counting the number of Mercedes on the streets.
There is almost no correlation.


The majority of the intermediate certs turn out to have been issued by one
CA (DFN-Verein) which has adopted the strategy as a means of keeping their
CRL sizes manageably small and/or as a means of locking each customer to a
single intermediate key. Calling the intermediate certs 'RA' certs is
deceptive and wrong.

What is significant is the number of key signing units in service. And that
is impossible to measure from the EFF observatory. There is no way that you
can find out from observing the cert paths whether the intermediate certs
off the DFN-Verein roots are under control of a different party or not.

Contrawise, until a few weeks ago there were Comodo resellers that had RA
capability but did not have an intermediate root at all. As of today there
are precisely 0 Comodo resellers that have RA capability.


This has been explained to you multiple times but you still keep trotting
out this canard time and again.

The fact that someone can put together a very pretty graph does not mean
that it actually means anything. Here the EFF is damaging its credibility by
allowing this group to misrepresent the implications of its work.


We should be encouraging people to deploy intermediate roots. Doing so
improves the robustness of the system. Grandstanding the issue and claiming
that it indicates a weakness is a dis-service to the community.


On Fri, Apr 8, 2011 at 1:38 PM, Paul Wouters <[e-mail]> wrote:

> On Fri, 8 Apr 2011, Richard L. Barnes wrote:
>
> > Which brings us back to the point that if you want certs that really
> aren't signed by anybody, you might as well be using bare keys, or some new
> data structure that only carries what you're interested in, e.g., key
> parameters but not key usage, names, issuer, etc.
>
> Which I have been advocating for before this working group formed. And
> for which I've started a TLS extension draft and got some good feedback
> to at the IETF in Prague. Expect the draft submission in the next week
> or two. I'll notify the TLS and DANE working group when we have submitted
> the draft.
>
> Back on the use case document issue, as long as we are ignoring the
> elephant in the room, this discussion will get no where. CA based PKIX
> has failed. The EFF SSL Observatory data, along with the recent Comodo
> disaster clearly shows this.
>
> If you want a use case, look at this:
> https://www.eff.org/files/colour_map_of_CAs.pdf
>
> 650+ organisations world wide can sign a certificate for any website. How
> many of these have been hacked? How many more unqualified or RFC1918 space
> signed certificates do we need to show? While OCSP on an IPsec gateway is
> good to have, putting it in a browser results in a huge privacy problem.
> On top of that, the OCSP revoked certificate lists are secret. Knowing
> a serial number is revoked does not tell anyone if that misissued
> certificate was for one of their domains.  Not only is the trust model
> of commercial CA's broken, its execution is too much of a secret for us
> to even be able to classify and identify the risks and the attacks on it.
>
> TLS clearly needs an alternative trust model. DANE is about providing
> one using DNSSEC. There will be others.
>
> This working group, along with the TLS working group, should ensure that
> moving forward, people no longer have to rely on a single failed trust
> model, but can have their own client policy pick from a variety of trust
> models they believe in. It is up to us to provide them with that.
>
> A good solution to start with is certificates in DNSSEC. A logical
> continuation of that is a TLS mechanism for out of bound trust.
>
> These things were very much happening in the working group, even before the
> school principal was sent into the working group meeting to check up on
> the teachers and their students. Please let them continue to do their work.
>
> Paul
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane
>



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

--bcaec50166a5d9f9c004a06948dd
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Could people actually take some time to learn about what the EFF data means=
 before engaging in this hyperbole?<div><br></div><div>There are not and ha=
ve never been 600 RA certs. The EFF people do not understand what the data =
means or why the certs are configured the way they are. In fact the pressur=
e that we have had from Mozilla and other sources is to increase the number=
 of intermediate certs.</div>
<div><br></div><div>The main reason for not doing so is that there are peop=
le out there who appear determined to misrepresent the implications.</div><=
div><br></div><div><br></div><div>An intermediate certificate does not impl=
y an RA capability.</div>
<div>Nor does an RA capability require an intermediate certificate.</div><d=
iv><br></div><div><br></div><div>The two issues are completely separate. It=
 is like measuring the number of lawyers in Washington by counting the numb=
er of Mercedes on the streets. There is almost no correlation.</div>
<div><br></div><div><br></div><div>The majority of the intermediate certs t=
urn out to have been issued by one CA (DFN-Verein) which has adopted the st=
rategy as a means of keeping their CRL sizes manageably small and/or as a m=
eans of locking each customer to a single intermediate key. Calling the int=
ermediate certs &#39;RA&#39; certs is deceptive and wrong.</div>
<div><br></div><div>What is significant is the number of key signing units =
in service. And that is impossible to measure from the EFF observatory. The=
re is no way that you can find out from observing the cert paths whether th=
e intermediate certs off the DFN-Verein roots are under control of a differ=
ent party or not.</div>
<div><br></div><div>Contrawise, until a few weeks ago there were Comodo res=
ellers that had RA capability but did not have an intermediate root at all.=
 As of today there are precisely 0 Comodo resellers that have RA capability=
.</div>
<div><br></div><div><br></div><div>This has been explained to you multiple =
times but you still keep trotting out this canard time and again.</div><div=
><br></div><div>The fact that someone can put together a very pretty graph =
does not mean that it actually means anything. Here the EFF is damaging its=
 credibility by allowing this group to misrepresent the implications of its=
 work.</div>
<div><br></div><div><br></div><div>We should be encouraging people to deplo=
y intermediate roots. Doing so improves the robustness of the system. Grand=
standing the issue and claiming that it indicates a weakness is a dis-servi=
ce to the community.</div>
<div><br><br><div class=3D"gmail_quote">On Fri, Apr 8, 2011 at 1:38 PM, Pau=
l Wouters <span dir=3D"ltr">&lt;<a href=3D"mailto:[e-mail]">paul@=
xelerance.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
On Fri, 8 Apr 2011, Richard L. Barnes wrote:<br>
<br>
&gt; Which brings us back to the point that if you want certs that really a=
ren&#39;t signed by anybody, you might as well be using bare keys, or some =
new data structure that only carries what you&#39;re interested in, e.g., k=
ey parameters but not key usage, names, issuer, etc.<br>

<br>
Which I have been advocating for before this working group formed. And<br>
for which I&#39;ve started a TLS extension draft and got some good feedback=
<br>
to at the IETF in Prague. Expect the draft submission in the next week<br>
or two. I&#39;ll notify the TLS and DANE working group when we have submitt=
ed<br>
the draft.<br>
<br>
Back on the use case document issue, as long as we are ignoring the<br>
elephant in the room, this discussion will get no where. CA based PKIX<br>
has failed. The EFF SSL Observatory data, along with the recent Comodo<br>
disaster clearly shows this.<br>
<br>
If you want a use case, look at this: <a href=3D"https://www.eff.org/files/=
colour_map_of_CAs.pdf" target=3D"_blank">https://www.eff.org/files/colour_m=
ap_of_CAs.pdf</a><br>
<br>
650+ organisations world wide can sign a certificate for any website. How<b=
r>
many of these have been hacked? How many more unqualified or RFC1918 space<=
br>
signed certificates do we need to show? While OCSP on an IPsec gateway is<b=
r>
good to have, putting it in a browser results in a huge privacy problem.<br=
>
On top of that, the OCSP revoked certificate lists are secret. Knowing<br>
a serial number is revoked does not tell anyone if that misissued<br>
certificate was for one of their domains. =A0Not only is the trust model<br=
>
of commercial CA&#39;s broken, its execution is too much of a secret for us=
<br>
to even be able to classify and identify the risks and the attacks on it.<b=
r>
<br>
TLS clearly needs an alternative trust model. DANE is about providing<br>
one using DNSSEC. There will be others.<br>
<br>
This working group, along with the TLS working group, should ensure that<br=
>
moving forward, people no longer have to rely on a single failed trust<br>
model, but can have their own client policy pick from a variety of trust<br=
>
models they believe in. It is up to us to provide them with that.<br>
<br>
A good solution to start with is certificates in DNSSEC. A logical<br>
continuation of that is a TLS mechanism for out of bound trust.<br>
<br>
These things were very much happening in the working group, even before the=
<br>
school principal was sent into the working group meeting to check up on<br>
the teachers and their students. Please let them continue to do their work.=
<br>
<br>
Paul<br>
_______________________________________________<br>
dane mailing list<br>
<a href=3D"mailto:[e-mail]">[e-mail]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/dane</a><br>
</blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a href=3D"htt=
p://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--bcaec50166a5d9f9c004a06948dd--

From [e-mail]  Fri Apr  8 07:48:41 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 044E53A6835 for <[e-mail]>; Fri,  8 Apr 2011 07:48:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.3
X-Spam-Level: 
X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kReQh92OUBtw for <[e-mail]>; Fri,  8 Apr 2011 07:48:40 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id CE7843A67CF for <[e-mail]>; Fri,  8 Apr 2011 07:48:39 -0700 (PDT)
Received: from dhcp-205.office.nic.cz (unknown [IPv6:2001:1488:ac14:1400:226:bbff:fe17:a705]) by mail.nic.cz (Postfix) with ESMTPSA id 368AE2A0B5B; Fri,  8 Apr 2011 16:50:24 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Fri, 08 Apr 2011 16:50:23 +0200
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[e-mail]>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: [e-mail]
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.96.5 at mail
X-Virus-Status: Clean
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2011 14:48:41 -0000

On 4/8/11 4:01 PM, Martin Rex wrote:
> Richard L. Barnes wrote:
>>
>> To note again: The phrase "self-signed EE cert" does not make sense.
>>  From RFC 5280:
>> "
>> Self-issued certificates are generated to support changes in policy
>> or operations.  Self-signed certificates are self-issued certificates
>> where the digital signature may be verified by the public key bound
>> into the certificate.
>> "
>> Since a self-signed cert has a cert issued under it (itself), it has
>> to be a CA cert.
>>
>> A self-signed cert *without* the CA bits set is therefore malformed,
>> and will not pass PKIX validation.
>
> You seem to have entirely missed the most important of PKIX
>
>    http://tools.ietf.org/html/rfc5280
>
>     Abstract
>
>     This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use
>     in the Internet.
>
> PKIX rules, by their own definition, do not apply to X.509v1 self-signed
> EE certs.  And SSLv3, TLSv1.0 and TLSv1.1 are perfectly usable with X.509v1
> self-signed EE certs.

So, is this something we can agree on?  I am inclined to open a ticket, 
so we can document this in more compact form with pros and cons, but 
still it seems to be a good approach to not break any standard and 
allowing us to do what we want to.

> It would be interesting to know from the SSLiverse database how many
> TLS server certs on the internet are self-signed EE certs vs. CA-signed,
> and how many of the self-signed TLS server certs are X.509v1.

I wrote to Peter Eckersley@EFF with exactly this question.  Let's see if 
he responds.

Ondrej

From [e-mail]  Fri Apr  8 08:26:50 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAB063A6934 for <[e-mail]>; Fri,  8 Apr 2011 08:26:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.205
X-Spam-Level: 
X-Spam-Status: No, score=-102.205 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APVuxLqQlWUg for <[e-mail]>; Fri,  8 Apr 2011 08:26:49 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id AC99D3A6819 for <[e-mail]>; Fri,  8 Apr 2011 08:26:49 -0700 (PDT)
Received: from [192.1.255.182] (port=61949 helo=col-dhcp-192-1-255-182.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from <[e-mail]>) id 1Q8Dbu-000FR7-F3; Fri, 08 Apr 2011 11:28:34 -0400
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=utf-8
From: "Richard L. Barnes" <[e-mail]>
In-Reply-To: <BANLkTinOTTWSbHcGCTFN=[e-mail]>
Date: Fri, 8 Apr 2011 11:28:33 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <BANLkTinOTTWSbHcGCTFN=[e-mail]>
To: Ben Laurie <[e-mail]>
X-Mailer: Apple Mail (2.1082)
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2011 15:26:51 -0000

To turn the question around, why would we not try to get it right this =
time?  Servers are going to have to do some re-provisioning anyway to =
enable DANE, and it's just not that much extra work to get it right.  I =
just did this myself as an experiment:

To generate a self-signed (CA!) cert:
openssl genrsa -out dane.key 1024
openssl req -new -key dane.key -out dane-ca.csr
openssl x509 -req -days 365 -in dane-ca.csr \
             -signkey dane.key -out dane-ca-cert.pem

To generate an EE cert under that:
# Generate an EE cert under that certificate
openssl req -new -key dane.key -out dane-server.csr
openssl x509 -req -days 365 -in dane-server.csr \
             -CA dane-ca-cert.pem -CAkey dane.key \
             -CAcreateserial -out dane-server-cert.pem

If you want to verify that it worked:
openssl verify -CAfile dane-ca-cert.pem -purpose sslserver =
dane-server-cert.pem

That's it!  You provision the CA cert to DANE, and you use the EE cert =
on the server just like a cert from any other CA.  The effort is once =
per cert expiry, which you as the CA can make as long as you want. =20

--Richard



On Apr 8, 2011, at 9:19 AM, Ben Laurie wrote:

> On 8 April 2011 13:46, Richard L. Barnes <[e-mail]> wrote:
>> To note again: The phrase "self-signed EE cert" does not make sense.  =
=46rom RFC 5280:
>> "
>> Self-issued certificates are generated to support changes in policy =
or operations.  Self-signed certificates are self-issued certificates =
where the digital signature may be verified by the public key bound into =
the certificate.
>> "
>> Since a self-signed cert has a cert issued under it (itself), it has =
to be a CA cert.
>>=20
>> A self-signed cert *without* the CA bits set is therefore malformed, =
and will not pass PKIX validation.
>=20
> This may be true in theory, but is far from true in practice - in
> practice, I can put a self-signed cert on my website and it works just
> fine (in the sense that it is not considered malformed, just rather
> untrustworthy).
>=20
> So, this is just spec lawyering.
>=20
>>=20
>> Which brings us back to the point that if you want certs that really =
aren't signed by anybody, you might as well be using bare keys, or some =
new data structure that only carries what you're interested in, e.g., =
key parameters but not key usage, names, issuer, etc.
>>=20
>> --Richard
>>=20
>>=20
>>=20
>>=20
>> On Apr 8, 2011, at 8:36 AM, Ond=C5=99ej Sur=C3=BD wrote:
>>=20
>>> My question to the list is if we can avoid specifying which X.509 =
version the client/server has to use and leave it to the client policy.
>>>=20
>>> Martin's approach seems like a reasonable one, but the question is =
if we can fit it into our draft without advice to break any existing =
standard.
>>>=20
>>> I know that we are standards group (to reply to PHB later in this =
thread), but we also cannot afford to ignore what's happening in the =
real world otherwise the world is going to ignore us.
>>>=20
>>> I think that usage of self-signed EE cert is a reasonable use case =
(which may or may not make it to the protocol) and it shouldn't be left =
out.  So please everybody let's think harder how to make things for =
non-protocol-geeks out there simpler, so the fruit of our work is a =
tasty one and not bittersweet.
>>>=20
>>> O.
>>>=20
>>> On 4/8/11 4:58 AM, Martin Rex wrote:
>>>> Stephen Kent wrote:
>>>>>=20
>>>>> James Cloos wrote:
>>>>>>=20
>>>>>> EE certs in the rr is in all of the drafts, was the original =
target, is
>>>>>> easy to understand and explain, and I've read more consensus for =
than
>>>>>> against on the list.
>>>>>>=20
>>>>>> Why the sudden backlash against?
>>>>>=20
>>>>> It's not sudden :-). A self-signed cert is a CA cert, by =
definition (see
>>>>> the cites to RFC 5280 in Paul's I-D.
>>>>=20
>>>> RFC 5280 is about X.509v3 certs _ONLY_.
>>>>=20
>>>> There is NO problem creating X.509v1 End-Entity certs that are =
self-signed.
>>>> And there is no problem using any of these with implementations of
>>>> SSLv3 and TLSv1.0.
>>>>=20
>>>> SSLv3 predates IETF PKIX standards, and TLSv1.0 is related to
>>>> rfc-2459 rather than rfc-5280 -- but implementations of TLSv1.0
>>>> were often shipped before publication of TLSv1.0 (rfc-2246) and
>>>> the original PKIX certificate profile (rfc-2459).
>>>>=20
>>>>=20
>>>> For safety, it would be sensible to ALWAYS treat X.509v1 certs as
>>>> EndEntity certs (i.e. never accept them as signer of other certs).
>>>> Our TLS implementation had done this initially, but we had a =
customer
>>>> that had obtained server certs issued under a VeriSign X.509v1 CA =
cert
>>>> (as late as 2006!), so I had to make our OEM implementation =
tolerate this.
>>>>=20
>>>>=20
>>>>=20
>>>>>=20
>>>>> The TLS spec talks in terms of an "end entity's cert" as =
representing
>>>>> a a server (or client). =46rom a PKI perspective, the cert that =
represents
>>>>> a server or client MUST be an EE cert,
>>>>=20
>>>> Like an X.509v1 self-signed EE cert.  Works perfectly fine with all
>>>> TLS implementations that I've met.
>>>>=20
>>>> Keep in mind that TLS is not limited to X.509v3 certs.
>>>>=20
>>>>   TLSv1.0:    http://tools.ietf.org/html/rfc2246#section-7.4.2
>>>>   TLSv1.1:    http://tools.ietf.org/html/rfc4346#section-7.4.2
>>>>=20
>>>>    7.4.2. Server certificate
>>>>=20
>>>>       [...]
>>>>=20
>>>>    Meaning of this message:
>>>>        The certificate type must be appropriate for the selected =
cipher
>>>>        suite's key exchange algorithm, and is generally an X.509v3
>>>>        certificate. It must contain a key which matches the key =
exchange
>>>>        method, as follows.
>>>>=20
>>>>=20
>>>>>=20
>>>>> an thus cannot be self-signed.
>>>>=20
>>>> TLSv1.0 and TLSv1.1 have neither a problem with X.509v1 nor
>>>> with a self-signed X.509v1 End-Entity cert.
>>>>=20
>>>>=20
>>>>> The fact that many implementations
>>>>> violate IETF PKI standards in this regard, is unfortunate, but it =
is not
>>>>> a basis for issuing a new IETF standard that codifies this =
behavior.
>>>>=20
>>>> I know that there are lots of commercial CAs that still have CA =
certs
>>>> in every browser that are not valid CA certs according to PKIX / =
RFC 5280.
>>>>=20
>>>> But having TLSv1.0&TLSv1.1 (i.e. 99% of the installed base)
>>>> accept X.509v1 self-signed EE certs is perfectly fine.
>>>>=20
>>>> X.509v1 is fairly close to a bare key, supported by all TLS =
implementations
>>>> in the installed base, as well as tools in the installed base, such =
as
>>>> the openssl.exe shell and for transfering keypairs within =
PKCS#12/PFX.
>>>=20
>>> _______________________________________________
>>> dane mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dane
>>=20
>> _______________________________________________
>> dane mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dane
>>=20


From [e-mail]  Fri Apr  8 09:03:13 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EECD3A6946 for <[e-mail]>; Fri,  8 Apr 2011 09:03:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.844
X-Spam-Level: 
X-Spam-Status: No, score=-2.844 tagged_above=-999 required=5 tests=[AWL=-0.546, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id er1pmeRZEXEO for <[e-mail]>; Fri,  8 Apr 2011 09:03:11 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 83D593A693B for <[e-mail]>; Fri,  8 Apr 2011 09:03:11 -0700 (PDT)
Received: by vxg33 with SMTP id 33so3432470vxg.31 for <[e-mail]>; Fri, 08 Apr 2011 09:04:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=d1iVkN1T3Y94TnF11L8WDOh9mUo1oD15rzbMRTzeBZg=; b=JQqB/2weuAU0hMF1ynn//SlT+CLsKtlIA7E866Y/ZBYj3Uo8/0Smhf7pIsqwkKGAr8 AJ9k/U02FmPxvuAEcTjW3DFQ0FXXpcKjWKKKmmZxymyUGQjtwJkkTFHLYfzOH5EaXZ4H XktklLdeAt06hX0XLckFoaUy2SWToCnE30MAA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Brt5CRga1AvDFlHQjrdF3dmM4yDUdq3X3r8JIdmeiuPfJffQXEonFX8BfZrYrLtQFK qI+sFssD6KeIp8Vp02gCopvlVDXu/qjx64tQlWEAgBDg/dq5xtN9bniZY4Uuo+7w5ZTI 91XN1YUAodqZRDVsneLP7aqHGvvcw65PRe1jY=
MIME-Version: 1.0
Received: by 10.52.0.109 with SMTP id 13mr3522991vdd.109.1302278696459; Fri, 08 Apr 2011 09:04:56 -0700 (PDT)
Received: by 10.52.166.230 with HTTP; Fri, 8 Apr 2011 09:04:56 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Fri, 8 Apr 2011 16:04:56 +0000
Message-ID: <[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[e-mail]>
Content-Type: multipart/alternative; boundary=20cf3054aabf19e0ee04a06a6327
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2011 16:03:13 -0000

--20cf3054aabf19e0ee04a06a6327
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

No avoiding Kent's issue by using v1 is not something we can agree on. I
think we can get to consensus on using self-signed v3 as EE certs though.


Trying to use X.509v1 certs is a bad idea and it is unnecessary. It would
then mean that DANE had a downref to a spec that the ITU has superseded.

As Stephen Farrell points out, Steve Kent is wrong on this point. And he wa=
s
the editor of the spec. Farrell is the editor of the spec in question and
has pointed out that there is precedence from other working groups.


At this point I suggest a consensus call on the following proposal:

1) Note the objection raised by Kent

2) Note the rebuttal by Farrell

3) Leave the spec unchanged - self signed X.509v3 EE certs allowed.


If Kent continues to disagree he can take his objection up with the securit=
y
AD for DANE or raise the issue in WG or IETF last call.

But in my view the whole discussion is moot since I don't see any need for
DANE to say anything more about the certificate type other than it be PKIX
compliant.


On Fri, Apr 8, 2011 at 2:50 PM, Ond=C5=99ej Sur=C3=BD <[e-mail]> =
wrote:

> On 4/8/11 4:01 PM, Martin Rex wrote:
>
>> Richard L. Barnes wrote:
>>
>>>
>>> To note again: The phrase "self-signed EE cert" does not make sense.
>>>  From RFC 5280:
>>> "
>>> Self-issued certificates are generated to support changes in policy
>>> or operations.  Self-signed certificates are self-issued certificates
>>> where the digital signature may be verified by the public key bound
>>> into the certificate.
>>> "
>>> Since a self-signed cert has a cert issued under it (itself), it has
>>> to be a CA cert.
>>>
>>> A self-signed cert *without* the CA bits set is therefore malformed,
>>> and will not pass PKIX validation.
>>>
>>
>> You seem to have entirely missed the most important of PKIX
>>
>>   http://tools.ietf.org/html/rfc5280
>>
>>    Abstract
>>
>>    This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use
>>    in the Internet.
>>
>> PKIX rules, by their own definition, do not apply to X.509v1 self-signed
>> EE certs.  And SSLv3, TLSv1.0 and TLSv1.1 are perfectly usable with
>> X.509v1
>> self-signed EE certs.
>>
>
> So, is this something we can agree on?  I am inclined to open a ticket, s=
o
> we can document this in more compact form with pros and cons, but still i=
t
> seems to be a good approach to not break any standard and allowing us to =
do
> what we want to.
>
>
>  It would be interesting to know from the SSLiverse database how many
>> TLS server certs on the internet are self-signed EE certs vs. CA-signed,
>> and how many of the self-signed TLS server certs are X.509v1.
>>
>
> I wrote to Peter Eckersley@EFF with exactly this question.  Let's see if
> he responds.
>
> Ondrej
>
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane
>



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

--20cf3054aabf19e0ee04a06a6327
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

No avoiding Kent&#39;s issue by using v1 is not something we can agree on. =
I think we can get to consensus on using self-signed v3 as EE certs though.=
<div><br></div><div><br></div><div>Trying to use X.509v1 certs is a bad ide=
a and it is unnecessary. It would then mean that DANE had a downref to a sp=
ec that the ITU has=A0superseded.=A0</div>
<div><br></div><div>As Stephen Farrell points out, Steve Kent is wrong on t=
his point. And he was the editor of the spec. Farrell is the editor of the =
spec in question and has pointed out that there is precedence from other wo=
rking groups.</div>
<div><br></div><div><br></div><div>At this point I suggest a consensus call=
 on the following proposal:</div><div><br></div><div>1) Note the objection =
raised by Kent</div><div><br></div><div>2) Note the rebuttal by Farrell</di=
v>
<div><br></div><div>3) Leave the spec unchanged - self signed X.509v3 EE ce=
rts allowed.</div><div><br></div><div><br></div><div>If Kent continues to d=
isagree he can take his objection up with the security AD for DANE or raise=
 the issue in WG or IETF last call.</div>
<div><br></div><div>But in my view the whole discussion is moot since I don=
&#39;t see any need for DANE to say anything more about the certificate typ=
e other than it be PKIX compliant.</div><div><br></div><div><br><div class=
=3D"gmail_quote">
On Fri, Apr 8, 2011 at 2:50 PM, Ond=F8ej Sur=FD <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:[e-mail]">[e-mail]</a>&gt;</span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex;">
<div class=3D"im">On 4/8/11 4:01 PM, Martin Rex wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Richard L. Barnes wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<br>
To note again: The phrase &quot;self-signed EE cert&quot; does not make sen=
se.<br>
=A0From RFC 5280:<br>
&quot;<br>
Self-issued certificates are generated to support changes in policy<br>
or operations. =A0Self-signed certificates are self-issued certificates<br>
where the digital signature may be verified by the public key bound<br>
into the certificate.<br>
&quot;<br>
Since a self-signed cert has a cert issued under it (itself), it has<br>
to be a CA cert.<br>
<br>
A self-signed cert *without* the CA bits set is therefore malformed,<br>
and will not pass PKIX validation.<br>
</blockquote>
<br>
You seem to have entirely missed the most important of PKIX<br>
<br>
 =A0 <a href=3D"http://tools.ietf.org/html/rfc5280" target=3D"_blank">http:=
//tools.ietf.org/html/rfc5280</a><br>
<br>
 =A0 =A0Abstract<br>
<br>
 =A0 =A0This memo profiles the X.509 v3 certificate and X.509 v2 CRL for us=
e<br>
 =A0 =A0in the Internet.<br>
<br>
PKIX rules, by their own definition, do not apply to X.509v1 self-signed<br=
>
EE certs. =A0And SSLv3, TLSv1.0 and TLSv1.1 are perfectly usable with X.509=
v1<br>
self-signed EE certs.<br>
</blockquote>
<br></div>
So, is this something we can agree on? =A0I am inclined to open a ticket, s=
o we can document this in more compact form with pros and cons, but still i=
t seems to be a good approach to not break any standard and allowing us to =
do what we want to.<div class=3D"im">
<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
It would be interesting to know from the SSLiverse database how many<br>
TLS server certs on the internet are self-signed EE certs vs. CA-signed,<br=
>
and how many of the self-signed TLS server certs are X.509v1.<br>
</blockquote>
<br></div>
I wrote to Peter Eckersley@EFF with exactly this question. =A0Let&#39;s see=
 if he responds.<br>
<br>
Ondrej<div><div></div><div class=3D"h5"><br>
_______________________________________________<br>
dane mailing list<br>
<a href=3D"mailto:[e-mail]" target=3D"_blank">[e-mail]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/dane</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a=
 href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--20cf3054aabf19e0ee04a06a6327--

From [e-mail]  Fri Apr  8 09:10:14 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D5153A69A0 for <[e-mail]>; Fri,  8 Apr 2011 09:10:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.923
X-Spam-Level: 
X-Spam-Status: No, score=-9.923 tagged_above=-999 required=5 tests=[AWL=-0.274, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vqej+5u2w4S for <[e-mail]>; Fri,  8 Apr 2011 09:10:13 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 385773A6945 for <[e-mail]>; Fri,  8 Apr 2011 09:10:13 -0700 (PDT)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p38GBsPW000201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Apr 2011 18:11:54 +0200 (MEST)
From: Martin Rex <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail] (Richard L. Barnes)
Date: Fri, 8 Apr 2011 18:11:53 +0200 (MEST)
In-Reply-To: <[e-mail]> from "Richard L. Barnes" at Apr 8, 11 11:28:33 am
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: [e-mail]
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2011 16:10:14 -0000

Richard L. Barnes wrote:
>
> To turn the question around, why would we not try to get it right
> this time?  Servers are going to have to do some re-provisioning
> anyway to enable DANE, and it's just not that much extra work to
> get it right.

Nothing needs to be done to the servers to enable DANE.
Just insert the self-signed EE cert that your server is currently
using as a TLSA record into the DNSSEC signed zone and you're done.


Creation of new self-signed cert for servers that do not already have one:

openssl genrsa -out myserver.key 2048
openssl req -new -x509 -key myserver.key -out myserver.pem -days 7300 -extensions new_oids


That's it!

There might be a bug in the OpenSSL 0.9.8h on the SLES-11 that I used,
it creates an extension-less X.509 certificate and seems to tag it 
as v3, algthough it ought to be tagged as v1 when it is extension-less.

The distributed openssl.cnf seems to lack an section for X.509v1 certs,
but there was a sufficiently empty section "new_oids" that did the job.



-Martin

From [e-mail]  Fri Apr  8 09:14:44 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 064A93A69C0 for <[e-mail]>; Fri,  8 Apr 2011 09:14:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.677
X-Spam-Level: 
X-Spam-Status: No, score=-105.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGqXQ3p9bJef for <[e-mail]>; Fri,  8 Apr 2011 09:14:42 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id A85193A6970 for <[e-mail]>; Fri,  8 Apr 2011 09:14:42 -0700 (PDT)
Received: from kpbe19.cbf.corp.google.com (kpbe19.cbf.corp.google.com [172.25.105.83]) by smtp-out.google.com with ESMTP id p38GGMRV030789 for <[e-mail]>; Fri, 8 Apr 2011 09:16:22 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1302279382; bh=ZxHebazcgi9juS2eKGRKLfnsnas=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=ofArDMNKWcV0/CqqeCLIJSqEoCedBA4aQTcTVmOAM5FilRktZh1buKMY9hN2narcJ YacPf+jKEvQ/8oeauTL1A==
Received: from vws18 (vws18.prod.google.com [10.241.21.146]) by kpbe19.cbf.corp.google.com with ESMTP id p38GGKQP003043 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <[e-mail]>; Fri, 8 Apr 2011 09:16:21 -0700
Received: by vws18 with SMTP id 18so4014745vws.41 for <[e-mail]>; Fri, 08 Apr 2011 09:16:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=OOU/OCFf45SDjQcSCzW2EqXEjj+CztddJlSUjoKDRxU=; b=OwkjNdzGuNCfgMLcDXyrkWeaIkZSF2YoHaYx9F5DBHkd2TimovOfpkbw2XM6j1LYBH GLV07670GpGYW/iAqjSg==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=NFpfRpeuP7voNJ1KU2hx5a+DncgNlJem5VrwTc8w5xURnexiNjo4s8sfwL7AJxPdfG 9tgqM6tSbYhReLpf6ctw==
MIME-Version: 1.0
Received: by 10.52.88.233 with SMTP id bj9mr1107447vdb.131.1302279380620; Fri, 08 Apr 2011 09:16:20 -0700 (PDT)
Received: by 10.220.117.12 with HTTP; Fri, 8 Apr 2011 09:16:20 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <BANLkTinOTTWSbHcGCTFN=[e-mail]> <[e-mail]>
Date: Fri, 8 Apr 2011 17:16:20 +0100
Message-ID: <BANLkTi=[e-mail]>
From: Ben Laurie <[e-mail]>
To: "Richard L. Barnes" <[e-mail]>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2011 16:14:44 -0000

On 8 April 2011 16:28, Richard L. Barnes <[e-mail]> wrote:
> To turn the question around, why would we not try to get it right this ti=
me? =C2=A0Servers are going to have to do some re-provisioning anyway to en=
able DANE, and it's just not that much extra work to get it right. =C2=A0I =
just did this myself as an experiment:
>
> To generate a self-signed (CA!) cert:
> openssl genrsa -out dane.key 1024
> openssl req -new -key dane.key -out dane-ca.csr
> openssl x509 -req -days 365 -in dane-ca.csr \
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -signkey dane.key -out dane-ca-=
cert.pem
>
> To generate an EE cert under that:
> # Generate an EE cert under that certificate
> openssl req -new -key dane.key -out dane-server.csr
> openssl x509 -req -days 365 -in dane-server.csr \
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -CA dane-ca-cert.pem -CAkey dan=
e.key \
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -CAcreateserial -out dane-serve=
r-cert.pem
>
> If you want to verify that it worked:
> openssl verify -CAfile dane-ca-cert.pem -purpose sslserver dane-server-ce=
rt.pem
>
> That's it! =C2=A0You provision the CA cert to DANE, and you use the EE ce=
rt on the server just like a cert from any other CA. =C2=A0The effort is on=
ce per cert expiry, which you as the CA can make as long as you want.

That's not it - now you have to provision and configure the server(s)
to serve the chain.

>
> --Richard
>
>
>
> On Apr 8, 2011, at 9:19 AM, Ben Laurie wrote:
>
>> On 8 April 2011 13:46, Richard L. Barnes <[e-mail]> wrote:
>>> To note again: The phrase "self-signed EE cert" does not make sense. =
=C2=A0From RFC 5280:
>>> "
>>> Self-issued certificates are generated to support changes in policy or =
operations. =C2=A0Self-signed certificates are self-issued certificates whe=
re the digital signature may be verified by the public key bound into the c=
ertificate.
>>> "
>>> Since a self-signed cert has a cert issued under it (itself), it has to=
 be a CA cert.
>>>
>>> A self-signed cert *without* the CA bits set is therefore malformed, an=
d will not pass PKIX validation.
>>
>> This may be true in theory, but is far from true in practice - in
>> practice, I can put a self-signed cert on my website and it works just
>> fine (in the sense that it is not considered malformed, just rather
>> untrustworthy).
>>
>> So, this is just spec lawyering.
>>
>>>
>>> Which brings us back to the point that if you want certs that really ar=
en't signed by anybody, you might as well be using bare keys, or some new d=
ata structure that only carries what you're interested in, e.g., key parame=
ters but not key usage, names, issuer, etc.
>>>
>>> --Richard
>>>
>>>
>>>
>>>
>>> On Apr 8, 2011, at 8:36 AM, Ond=C5=99ej Sur=C3=BD wrote:
>>>
>>>> My question to the list is if we can avoid specifying which X.509 vers=
ion the client/server has to use and leave it to the client policy.
>>>>
>>>> Martin's approach seems like a reasonable one, but the question is if =
we can fit it into our draft without advice to break any existing standard.
>>>>
>>>> I know that we are standards group (to reply to PHB later in this thre=
ad), but we also cannot afford to ignore what's happening in the real world=
 otherwise the world is going to ignore us.
>>>>
>>>> I think that usage of self-signed EE cert is a reasonable use case (wh=
ich may or may not make it to the protocol) and it shouldn't be left out. =
=C2=A0So please everybody let's think harder how to make things for non-pro=
tocol-geeks out there simpler, so the fruit of our work is a tasty one and =
not bittersweet.
>>>>
>>>> O.
>>>>
>>>> On 4/8/11 4:58 AM, Martin Rex wrote:
>>>>> Stephen Kent wrote:
>>>>>>
>>>>>> James Cloos wrote:
>>>>>>>
>>>>>>> EE certs in the rr is in all of the drafts, was the original target=
, is
>>>>>>> easy to understand and explain, and I've read more consensus for th=
an
>>>>>>> against on the list.
>>>>>>>
>>>>>>> Why the sudden backlash against?
>>>>>>
>>>>>> It's not sudden :-). A self-signed cert is a CA cert, by definition =
(see
>>>>>> the cites to RFC 5280 in Paul's I-D.
>>>>>
>>>>> RFC 5280 is about X.509v3 certs _ONLY_.
>>>>>
>>>>> There is NO problem creating X.509v1 End-Entity certs that are self-s=
igned.
>>>>> And there is no problem using any of these with implementations of
>>>>> SSLv3 and TLSv1.0.
>>>>>
>>>>> SSLv3 predates IETF PKIX standards, and TLSv1.0 is related to
>>>>> rfc-2459 rather than rfc-5280 -- but implementations of TLSv1.0
>>>>> were often shipped before publication of TLSv1.0 (rfc-2246) and
>>>>> the original PKIX certificate profile (rfc-2459).
>>>>>
>>>>>
>>>>> For safety, it would be sensible to ALWAYS treat X.509v1 certs as
>>>>> EndEntity certs (i.e. never accept them as signer of other certs).
>>>>> Our TLS implementation had done this initially, but we had a customer
>>>>> that had obtained server certs issued under a VeriSign X.509v1 CA cer=
t
>>>>> (as late as 2006!), so I had to make our OEM implementation tolerate =
this.
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> The TLS spec talks in terms of an "end entity's cert" as representin=
g
>>>>>> a a server (or client). From a PKI perspective, the cert that repres=
ents
>>>>>> a server or client MUST be an EE cert,
>>>>>
>>>>> Like an X.509v1 self-signed EE cert. =C2=A0Works perfectly fine with =
all
>>>>> TLS implementations that I've met.
>>>>>
>>>>> Keep in mind that TLS is not limited to X.509v3 certs.
>>>>>
>>>>> =C2=A0 TLSv1.0: =C2=A0 =C2=A0http://tools.ietf.org/html/rfc2246#secti=
on-7.4.2
>>>>> =C2=A0 TLSv1.1: =C2=A0 =C2=A0http://tools.ietf.org/html/rfc4346#secti=
on-7.4.2
>>>>>
>>>>> =C2=A0 =C2=A07.4.2. Server certificate
>>>>>
>>>>> =C2=A0 =C2=A0 =C2=A0 [...]
>>>>>
>>>>> =C2=A0 =C2=A0Meaning of this message:
>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0The certificate type must be appropriate f=
or the selected cipher
>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0suite's key exchange algorithm, and is gen=
erally an X.509v3
>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0certificate. It must contain a key which m=
atches the key exchange
>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0method, as follows.
>>>>>
>>>>>
>>>>>>
>>>>>> an thus cannot be self-signed.
>>>>>
>>>>> TLSv1.0 and TLSv1.1 have neither a problem with X.509v1 nor
>>>>> with a self-signed X.509v1 End-Entity cert.
>>>>>
>>>>>
>>>>>> The fact that many implementations
>>>>>> violate IETF PKI standards in this regard, is unfortunate, but it is=
 not
>>>>>> a basis for issuing a new IETF standard that codifies this behavior.
>>>>>
>>>>> I know that there are lots of commercial CAs that still have CA certs
>>>>> in every browser that are not valid CA certs according to PKIX / RFC =
5280.
>>>>>
>>>>> But having TLSv1.0&TLSv1.1 (i.e. 99% of the installed base)
>>>>> accept X.509v1 self-signed EE certs is perfectly fine.
>>>>>
>>>>> X.509v1 is fairly close to a bare key, supported by all TLS implement=
ations
>>>>> in the installed base, as well as tools in the installed base, such a=
s
>>>>> the openssl.exe shell and for transfering keypairs within PKCS#12/PFX=
.
>>>>
>>>> _______________________________________________
>>>> dane mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/dane
>>>
>>> _______________________________________________
>>> dane mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dane
>>>
>
>

From [e-mail]  Fri Apr  8 09:16:36 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72F2B3A69C0 for <[e-mail]>; Fri,  8 Apr 2011 09:16:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.194
X-Spam-Level: 
X-Spam-Status: No, score=-102.194 tagged_above=-999 required=5 tests=[AWL=-0.195, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fS0DkA1EAY6p for <[e-mail]>; Fri,  8 Apr 2011 09:16:35 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 498A53A694F for <[e-mail]>; Fri,  8 Apr 2011 09:16:35 -0700 (PDT)
Received: from [192.1.255.182] (port=62210 helo=col-dhcp-192-1-255-182.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from <[e-mail]>) id 1Q8EO3-000GOH-7R; Fri, 08 Apr 2011 12:18:20 -0400
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=utf-8
From: "Richard L. Barnes" <[e-mail]>
In-Reply-To: <BANLkTi=[e-mail]>
Date: Fri, 8 Apr 2011 12:18:13 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <BANLkTinOTTWSbHcGCTFN=[e-mail]> <[e-mail]> <BANLkTi=[e-mail]>
To: Ben Laurie <[e-mail]>
X-Mailer: Apple Mail (2.1082)
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2011 16:16:36 -0000

Ok, but that's just switching out a chain, if the server is already =
using TLS, or provisioning a new chain, which you would have to do =
anyway to use DANE.=20

Either way, it's a relatively small one-time cost.

--Richard


On Apr 8, 2011, at 12:16 PM, Ben Laurie wrote:

> On 8 April 2011 16:28, Richard L. Barnes <[e-mail]> wrote:
>> To turn the question around, why would we not try to get it right =
this time?  Servers are going to have to do some re-provisioning anyway =
to enable DANE, and it's just not that much extra work to get it right.  =
I just did this myself as an experiment:
>>=20
>> To generate a self-signed (CA!) cert:
>> openssl genrsa -out dane.key 1024
>> openssl req -new -key dane.key -out dane-ca.csr
>> openssl x509 -req -days 365 -in dane-ca.csr \
>>             -signkey dane.key -out dane-ca-cert.pem
>>=20
>> To generate an EE cert under that:
>> # Generate an EE cert under that certificate
>> openssl req -new -key dane.key -out dane-server.csr
>> openssl x509 -req -days 365 -in dane-server.csr \
>>             -CA dane-ca-cert.pem -CAkey dane.key \
>>             -CAcreateserial -out dane-server-cert.pem
>>=20
>> If you want to verify that it worked:
>> openssl verify -CAfile dane-ca-cert.pem -purpose sslserver =
dane-server-cert.pem
>>=20
>> That's it!  You provision the CA cert to DANE, and you use the EE =
cert on the server just like a cert from any other CA.  The effort is =
once per cert expiry, which you as the CA can make as long as you want.
>=20
> That's not it - now you have to provision and configure the server(s)
> to serve the chain.
>=20
>>=20
>> --Richard
>>=20
>>=20
>>=20
>> On Apr 8, 2011, at 9:19 AM, Ben Laurie wrote:
>>=20
>>> On 8 April 2011 13:46, Richard L. Barnes <[e-mail]> wrote:
>>>> To note again: The phrase "self-signed EE cert" does not make =
sense.  =46rom RFC 5280:
>>>> "
>>>> Self-issued certificates are generated to support changes in policy =
or operations.  Self-signed certificates are self-issued certificates =
where the digital signature may be verified by the public key bound into =
the certificate.
>>>> "
>>>> Since a self-signed cert has a cert issued under it (itself), it =
has to be a CA cert.
>>>>=20
>>>> A self-signed cert *without* the CA bits set is therefore =
malformed, and will not pass PKIX validation.
>>>=20
>>> This may be true in theory, but is far from true in practice - in
>>> practice, I can put a self-signed cert on my website and it works =
just
>>> fine (in the sense that it is not considered malformed, just rather
>>> untrustworthy).
>>>=20
>>> So, this is just spec lawyering.
>>>=20
>>>>=20
>>>> Which brings us back to the point that if you want certs that =
really aren't signed by anybody, you might as well be using bare keys, =
or some new data structure that only carries what you're interested in, =
e.g., key parameters but not key usage, names, issuer, etc.
>>>>=20
>>>> --Richard
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> On Apr 8, 2011, at 8:36 AM, Ond=C5=99ej Sur=C3=BD wrote:
>>>>=20
>>>>> My question to the list is if we can avoid specifying which X.509 =
version the client/server has to use and leave it to the client policy.
>>>>>=20
>>>>> Martin's approach seems like a reasonable one, but the question is =
if we can fit it into our draft without advice to break any existing =
standard.
>>>>>=20
>>>>> I know that we are standards group (to reply to PHB later in this =
thread), but we also cannot afford to ignore what's happening in the =
real world otherwise the world is going to ignore us.
>>>>>=20
>>>>> I think that usage of self-signed EE cert is a reasonable use case =
(which may or may not make it to the protocol) and it shouldn't be left =
out.  So please everybody let's think harder how to make things for =
non-protocol-geeks out there simpler, so the fruit of our work is a =
tasty one and not bittersweet.
>>>>>=20
>>>>> O.
>>>>>=20
>>>>> On 4/8/11 4:58 AM, Martin Rex wrote:
>>>>>> Stephen Kent wrote:
>>>>>>>=20
>>>>>>> James Cloos wrote:
>>>>>>>>=20
>>>>>>>> EE certs in the rr is in all of the drafts, was the original =
target, is
>>>>>>>> easy to understand and explain, and I've read more consensus =
for than
>>>>>>>> against on the list.
>>>>>>>>=20
>>>>>>>> Why the sudden backlash against?
>>>>>>>=20
>>>>>>> It's not sudden :-). A self-signed cert is a CA cert, by =
definition (see
>>>>>>> the cites to RFC 5280 in Paul's I-D.
>>>>>>=20
>>>>>> RFC 5280 is about X.509v3 certs _ONLY_.
>>>>>>=20
>>>>>> There is NO problem creating X.509v1 End-Entity certs that are =
self-signed.
>>>>>> And there is no problem using any of these with implementations =
of
>>>>>> SSLv3 and TLSv1.0.
>>>>>>=20
>>>>>> SSLv3 predates IETF PKIX standards, and TLSv1.0 is related to
>>>>>> rfc-2459 rather than rfc-5280 -- but implementations of TLSv1.0
>>>>>> were often shipped before publication of TLSv1.0 (rfc-2246) and
>>>>>> the original PKIX certificate profile (rfc-2459).
>>>>>>=20
>>>>>>=20
>>>>>> For safety, it would be sensible to ALWAYS treat X.509v1 certs as
>>>>>> EndEntity certs (i.e. never accept them as signer of other =
certs).
>>>>>> Our TLS implementation had done this initially, but we had a =
customer
>>>>>> that had obtained server certs issued under a VeriSign X.509v1 CA =
cert
>>>>>> (as late as 2006!), so I had to make our OEM implementation =
tolerate this.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>>=20
>>>>>>> The TLS spec talks in terms of an "end entity's cert" as =
representing
>>>>>>> a a server (or client). =46rom a PKI perspective, the cert that =
represents
>>>>>>> a server or client MUST be an EE cert,
>>>>>>=20
>>>>>> Like an X.509v1 self-signed EE cert.  Works perfectly fine with =
all
>>>>>> TLS implementations that I've met.
>>>>>>=20
>>>>>> Keep in mind that TLS is not limited to X.509v3 certs.
>>>>>>=20
>>>>>>   TLSv1.0:    http://tools.ietf.org/html/rfc2246#section-7.4.2
>>>>>>   TLSv1.1:    http://tools.ietf.org/html/rfc4346#section-7.4.2
>>>>>>=20
>>>>>>    7.4.2. Server certificate
>>>>>>=20
>>>>>>       [...]
>>>>>>=20
>>>>>>    Meaning of this message:
>>>>>>        The certificate type must be appropriate for the selected =
cipher
>>>>>>        suite's key exchange algorithm, and is generally an =
X.509v3
>>>>>>        certificate. It must contain a key which matches the key =
exchange
>>>>>>        method, as follows.
>>>>>>=20
>>>>>>=20
>>>>>>>=20
>>>>>>> an thus cannot be self-signed.
>>>>>>=20
>>>>>> TLSv1.0 and TLSv1.1 have neither a problem with X.509v1 nor
>>>>>> with a self-signed X.509v1 End-Entity cert.
>>>>>>=20
>>>>>>=20
>>>>>>> The fact that many implementations
>>>>>>> violate IETF PKI standards in this regard, is unfortunate, but =
it is not
>>>>>>> a basis for issuing a new IETF standard that codifies this =
behavior.
>>>>>>=20
>>>>>> I know that there are lots of commercial CAs that still have CA =
certs
>>>>>> in every browser that are not valid CA certs according to PKIX / =
RFC 5280.
>>>>>>=20
>>>>>> But having TLSv1.0&TLSv1.1 (i.e. 99% of the installed base)
>>>>>> accept X.509v1 self-signed EE certs is perfectly fine.
>>>>>>=20
>>>>>> X.509v1 is fairly close to a bare key, supported by all TLS =
implementations
>>>>>> in the installed base, as well as tools in the installed base, =
such as
>>>>>> the openssl.exe shell and for transfering keypairs within =
PKCS#12/PFX.
>>>>>=20
>>>>> _______________________________________________
>>>>> dane mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/dane
>>>>=20
>>>> _______________________________________________
>>>> dane mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/dane
>>>>=20
>>=20
>>=20


From [e-mail]  Fri Apr  8 09:40:25 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3332C3A6889 for <[e-mail]>; Fri,  8 Apr 2011 09:40:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.221
X-Spam-Level: 
X-Spam-Status: No, score=-10.221 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lg2X-B6DJbXR for <[e-mail]>; Fri,  8 Apr 2011 09:40:21 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 725B43A685D for <[e-mail]>; Fri,  8 Apr 2011 09:40:21 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p38Gg40A022999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Apr 2011 18:42:04 +0200 (MEST)
From: Martin Rex <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail] (Phillip Hallam-Baker)
Date: Fri, 8 Apr 2011 18:42:03 +0200 (MEST)
In-Reply-To: <[e-mail]> from "Phillip Hallam-Baker" at Apr 8, 11 02:46:01 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: [e-mail]
Subject: Re: [dane] elephant use case,
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: [e-mail]
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2011 16:40:25 -0000

Phillip Hallam-Baker wrote:
> 
> Could people actually take some time to learn about what the EFF data means
> before engaging in this hyperbole?
> 
> There are not and have never been 600 RA certs. The EFF people do not
> understand what the data means or why the certs are configured the way they
> are. In fact the pressure that we have had from Mozilla and other sources is
> to increase the number of intermediate certs.

RA "registration authorities"
   http://en.wikipedia.org/wiki/Registration_authority

do NOT have certificates themselves.  The organizations that have
the certificate with cert signing capabilities are called CAs.

What EFF likely did was that they counted the distinct CA(!!) certificates
that are valid under the trusted roots certs in Browsers as indicated
under "organization name" in those CA certificates.

I would at least expect that CAs that have trust anchors in browsers
check the organization names of CA-certs they issue, otherwise we
really should get rid of all of them.


> 
> An intermediate certificate does not imply an RA capability.
> Nor does an RA capability require an intermediate certificate.

A CA certificate indicates certificate issuing authority and capability,
there is no doubt about it.

The purpose (and definition) of an RA is, that it can get certs
automatically issued from its associated CA without any further
validation on the part of the CA.

I thought this is what happen in the "Commodogate" case.
The RA credentials were abused to get a number of
certs issued by a Commodo (Sub)CA.


> 
> Contrawise, until a few weeks ago there were Comodo resellers that had RA
> capability but did not have an intermediate root at all. As of today there
> are precisely 0 Comodo resellers that have RA capability.

An RA that gets its own CA certificate, turns into a CA.


-Martin

From [e-mail]  Fri Apr  8 09:47:09 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A9E83A6955 for <[e-mail]>; Fri,  8 Apr 2011 09:47:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.183
X-Spam-Level: 
X-Spam-Status: No, score=-102.183 tagged_above=-999 required=5 tests=[AWL=-0.184, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bR3CvD3mzkzI for <[e-mail]>; Fri,  8 Apr 2011 09:47:08 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id C7ED13A690B for <[e-mail]>; Fri,  8 Apr 2011 09:47:07 -0700 (PDT)
Received: from [192.1.255.182] (port=62259 helo=col-dhcp-192-1-255-182.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from <[e-mail]>) id 1Q8Erb-000Gmx-J6; Fri, 08 Apr 2011 12:48:51 -0400
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=utf-8
From: "Richard L. Barnes" <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Fri, 8 Apr 2011 12:48:47 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <BANLkTinOTTWSbHcGCTFN=[e-mail]> <[e-mail]> <BANLkTi=[e-mail]> <[e-mail]>
To: "Richard L. Barnes" <[e-mail]>
X-Mailer: Apple Mail (2.1082)
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2011 16:47:09 -0000

Clarification:
You only really have to provision the EE cert in the TLS server.  The =
client can get the TA from DANE.

So the alternatives are:
1. Only EE cert in TLS, CA in DANE
2. EE + CA in TLS, hash of CA in DANE

Only on the second case do you have to provision a "chain" in TLS.  In =
the first case, it's just an EE cert.



On Apr 8, 2011, at 12:18 PM, Richard L. Barnes wrote:

> Ok, but that's just switching out a chain, if the server is already =
using TLS, or provisioning a new chain, which you would have to do =
anyway to use DANE.=20
>=20
> Either way, it's a relatively small one-time cost.
>=20
> --Richard
>=20
>=20
> On Apr 8, 2011, at 12:16 PM, Ben Laurie wrote:
>=20
>> On 8 April 2011 16:28, Richard L. Barnes <[e-mail]> wrote:
>>> To turn the question around, why would we not try to get it right =
this time?  Servers are going to have to do some re-provisioning anyway =
to enable DANE, and it's just not that much extra work to get it right.  =
I just did this myself as an experiment:
>>>=20
>>> To generate a self-signed (CA!) cert:
>>> openssl genrsa -out dane.key 1024
>>> openssl req -new -key dane.key -out dane-ca.csr
>>> openssl x509 -req -days 365 -in dane-ca.csr \
>>>            -signkey dane.key -out dane-ca-cert.pem
>>>=20
>>> To generate an EE cert under that:
>>> # Generate an EE cert under that certificate
>>> openssl req -new -key dane.key -out dane-server.csr
>>> openssl x509 -req -days 365 -in dane-server.csr \
>>>            -CA dane-ca-cert.pem -CAkey dane.key \
>>>            -CAcreateserial -out dane-server-cert.pem
>>>=20
>>> If you want to verify that it worked:
>>> openssl verify -CAfile dane-ca-cert.pem -purpose sslserver =
dane-server-cert.pem
>>>=20
>>> That's it!  You provision the CA cert to DANE, and you use the EE =
cert on the server just like a cert from any other CA.  The effort is =
once per cert expiry, which you as the CA can make as long as you want.
>>=20
>> That's not it - now you have to provision and configure the server(s)
>> to serve the chain.
>>=20
>>>=20
>>> --Richard
>>>=20
>>>=20
>>>=20
>>> On Apr 8, 2011, at 9:19 AM, Ben Laurie wrote:
>>>=20
>>>> On 8 April 2011 13:46, Richard L. Barnes <[e-mail]> wrote:
>>>>> To note again: The phrase "self-signed EE cert" does not make =
sense.  =46rom RFC 5280:
>>>>> "
>>>>> Self-issued certificates are generated to support changes in =
policy or operations.  Self-signed certificates are self-issued =
certificates where the digital signature may be verified by the public =
key bound into the certificate.
>>>>> "
>>>>> Since a self-signed cert has a cert issued under it (itself), it =
has to be a CA cert.
>>>>>=20
>>>>> A self-signed cert *without* the CA bits set is therefore =
malformed, and will not pass PKIX validation.
>>>>=20
>>>> This may be true in theory, but is far from true in practice - in
>>>> practice, I can put a self-signed cert on my website and it works =
just
>>>> fine (in the sense that it is not considered malformed, just rather
>>>> untrustworthy).
>>>>=20
>>>> So, this is just spec lawyering.
>>>>=20
>>>>>=20
>>>>> Which brings us back to the point that if you want certs that =
really aren't signed by anybody, you might as well be using bare keys, =
or some new data structure that only carries what you're interested in, =
e.g., key parameters but not key usage, names, issuer, etc.
>>>>>=20
>>>>> --Richard
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> On Apr 8, 2011, at 8:36 AM, Ond=C5=99ej Sur=C3=BD wrote:
>>>>>=20
>>>>>> My question to the list is if we can avoid specifying which X.509 =
version the client/server has to use and leave it to the client policy.
>>>>>>=20
>>>>>> Martin's approach seems like a reasonable one, but the question =
is if we can fit it into our draft without advice to break any existing =
standard.
>>>>>>=20
>>>>>> I know that we are standards group (to reply to PHB later in this =
thread), but we also cannot afford to ignore what's happening in the =
real world otherwise the world is going to ignore us.
>>>>>>=20
>>>>>> I think that usage of self-signed EE cert is a reasonable use =
case (which may or may not make it to the protocol) and it shouldn't be =
left out.  So please everybody let's think harder how to make things for =
non-protocol-geeks out there simpler, so the fruit of our work is a =
tasty one and not bittersweet.
>>>>>>=20
>>>>>> O.
>>>>>>=20
>>>>>> On 4/8/11 4:58 AM, Martin Rex wrote:
>>>>>>> Stephen Kent wrote:
>>>>>>>>=20
>>>>>>>> James Cloos wrote:
>>>>>>>>>=20
>>>>>>>>> EE certs in the rr is in all of the drafts, was the original =
target, is
>>>>>>>>> easy to understand and explain, and I've read more consensus =
for than
>>>>>>>>> against on the list.
>>>>>>>>>=20
>>>>>>>>> Why the sudden backlash against?
>>>>>>>>=20
>>>>>>>> It's not sudden :-). A self-signed cert is a CA cert, by =
definition (see
>>>>>>>> the cites to RFC 5280 in Paul's I-D.
>>>>>>>=20
>>>>>>> RFC 5280 is about X.509v3 certs _ONLY_.
>>>>>>>=20
>>>>>>> There is NO problem creating X.509v1 End-Entity certs that are =
self-signed.
>>>>>>> And there is no problem using any of these with implementations =
of
>>>>>>> SSLv3 and TLSv1.0.
>>>>>>>=20
>>>>>>> SSLv3 predates IETF PKIX standards, and TLSv1.0 is related to
>>>>>>> rfc-2459 rather than rfc-5280 -- but implementations of TLSv1.0
>>>>>>> were often shipped before publication of TLSv1.0 (rfc-2246) and
>>>>>>> the original PKIX certificate profile (rfc-2459).
>>>>>>>=20
>>>>>>>=20
>>>>>>> For safety, it would be sensible to ALWAYS treat X.509v1 certs =
as
>>>>>>> EndEntity certs (i.e. never accept them as signer of other =
certs).
>>>>>>> Our TLS implementation had done this initially, but we had a =
customer
>>>>>>> that had obtained server certs issued under a VeriSign X.509v1 =
CA cert
>>>>>>> (as late as 2006!), so I had to make our OEM implementation =
tolerate this.
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>>=20
>>>>>>>> The TLS spec talks in terms of an "end entity's cert" as =
representing
>>>>>>>> a a server (or client). =46rom a PKI perspective, the cert that =
represents
>>>>>>>> a server or client MUST be an EE cert,
>>>>>>>=20
>>>>>>> Like an X.509v1 self-signed EE cert.  Works perfectly fine with =
all
>>>>>>> TLS implementations that I've met.
>>>>>>>=20
>>>>>>> Keep in mind that TLS is not limited to X.509v3 certs.
>>>>>>>=20
>>>>>>>  TLSv1.0:    http://tools.ietf.org/html/rfc2246#section-7.4.2
>>>>>>>  TLSv1.1:    http://tools.ietf.org/html/rfc4346#section-7.4.2
>>>>>>>=20
>>>>>>>   7.4.2. Server certificate
>>>>>>>=20
>>>>>>>      [...]
>>>>>>>=20
>>>>>>>   Meaning of this message:
>>>>>>>       The certificate type must be appropriate for the selected =
cipher
>>>>>>>       suite's key exchange algorithm, and is generally an =
X.509v3
>>>>>>>       certificate. It must contain a key which matches the key =
exchange
>>>>>>>       method, as follows.
>>>>>>>=20
>>>>>>>=20
>>>>>>>>=20
>>>>>>>> an thus cannot be self-signed.
>>>>>>>=20
>>>>>>> TLSv1.0 and TLSv1.1 have neither a problem with X.509v1 nor
>>>>>>> with a self-signed X.509v1 End-Entity cert.
>>>>>>>=20
>>>>>>>=20
>>>>>>>> The fact that many implementations
>>>>>>>> violate IETF PKI standards in this regard, is unfortunate, but =
it is not
>>>>>>>> a basis for issuing a new IETF standard that codifies this =
behavior.
>>>>>>>=20
>>>>>>> I know that there are lots of commercial CAs that still have CA =
certs
>>>>>>> in every browser that are not valid CA certs according to PKIX / =
RFC 5280.
>>>>>>>=20
>>>>>>> But having TLSv1.0&TLSv1.1 (i.e. 99% of the installed base)
>>>>>>> accept X.509v1 self-signed EE certs is perfectly fine.
>>>>>>>=20
>>>>>>> X.509v1 is fairly close to a bare key, supported by all TLS =
implementations
>>>>>>> in the installed base, as well as tools in the installed base, =
such as
>>>>>>> the openssl.exe shell and for transfering keypairs within =
PKCS#12/PFX.
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> dane mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/dane
>>>>>=20
>>>>> _______________________________________________
>>>>> dane mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/dane
>>>>>=20
>>>=20
>>>=20
>=20
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane


From [e-mail]  Fri Apr  8 09:57:26 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02DA23A6953 for <[e-mail]>; Fri,  8 Apr 2011 09:57:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.221
X-Spam-Level: 
X-Spam-Status: No, score=-10.221 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sue4JZStz2xq for <[e-mail]>; Fri,  8 Apr 2011 09:57:24 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 52FE53A6943 for <[e-mail]>; Fri,  8 Apr 2011 09:57:24 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p38Gwog3024444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Apr 2011 18:58:55 +0200 (MEST)
From: Martin Rex <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail] (Richard L. Barnes)
Date: Fri, 8 Apr 2011 18:58:49 +0200 (MEST)
In-Reply-To: <[e-mail]> from "Richard L. Barnes" at Apr 8, 11 12:48:47 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: [e-mail]
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2011 16:57:26 -0000

Richard L. Barnes wrote:
> 
> Clarification:
> You only really have to provision the EE cert in the TLS server.
> The client can get the TA from DANE.
> 
> So the alternatives are:
> 1. Only EE cert in TLS, CA in DANE
> 2. EE + CA in TLS, hash of CA in DANE
> 
> Only on the second case do you have to provision a "chain" in TLS.
> In the first case, it's just an EE cert.

I'm sorry, this assertion is wrong.

I know that there are defective TLS implementations that let you get
away with this, but the procotol spec is clear.

A TLS server must send his _entire_ certificate chain  in the Server
Certificate handshake message.  It may optionally omit the self-signed rootCA
cert at the end of the chain.  But in order to know that _only_ the
self-signed rootCA cert at the end of the chain is missing, a TLS
implementation MUST have that self-signed rootCA cert.

Our TLS implementation will refuse to work with a defective PKI credential
where the End-Entity cert is CA-signed and the certification path is
incomplete.  And as you can see in the EFF SSL observatory -- it would
be extremely useful if other TLS implementations would adopt the same
plausibility checks on PKI credentials.  There currently are
a lot of misconfigured servers on the internet causing all kinds
of weird interop problems by sending incomplete cert chains (chains
that lack more than the self-signed rootCA cert at the end),
and also TLS servers that send garbled cert chains (which is also
prohibited by the TLS spec), because of TLS implementations being
overly sloppy with PKI credentials management and with production
of the TLS Server Certificate handshake message.


-Martin

From [e-mail]  Fri Apr  8 10:01:11 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA0E43A690B for <[e-mail]>; Fri,  8 Apr 2011 10:01:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.474
X-Spam-Level: 
X-Spam-Status: No, score=-102.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjyPgE+dzfw5 for <[e-mail]>; Fri,  8 Apr 2011 10:01:10 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 323593A68D4 for <[e-mail]>; Fri,  8 Apr 2011 10:01:10 -0700 (PDT)
Received: from [192.1.255.182] (port=62468 helo=col-dhcp-192-1-255-182.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from <[e-mail]>) id 1Q8F5D-000H02-J1; Fri, 08 Apr 2011 13:02:55 -0400
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: "Richard L. Barnes" <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Fri, 8 Apr 2011 13:02:51 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]>
To: [e-mail]
X-Mailer: Apple Mail (2.1082)
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2011 17:01:11 -0000

>> Clarification:
>> You only really have to provision the EE cert in the TLS server.
>> The client can get the TA from DANE.
>>=20
>> So the alternatives are:
>> 1. Only EE cert in TLS, CA in DANE
>> 2. EE + CA in TLS, hash of CA in DANE
>>=20
>> Only on the second case do you have to provision a "chain" in TLS.
>> In the first case, it's just an EE cert.
>=20
> I'm sorry, this assertion is wrong.
>=20
> I know that there are defective TLS implementations that let you get
> away with this, but the procotol spec is clear.
>=20
> A TLS server must send his _entire_ certificate chain  in the Server
> Certificate handshake message.  It may optionally omit the self-signed =
rootCA
> cert at the end of the chain.  But in order to know that _only_ the
> self-signed rootCA cert at the end of the chain is missing, a TLS
> implementation MUST have that self-signed rootCA cert.

... and it gets that cert from DANE.  The CA that's provisioned in DANE =
in this case *is* the root CA.  It's a two-hop chain (root CA, EE), so =
you're saying exactly the same thing that I said: That the server can =
send either the chain (CA+EE) or the EE cert alone. =20

--Richard=

From [e-mail]  Fri Apr  8 10:14:18 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B41603A6943 for <[e-mail]>; Fri,  8 Apr 2011 10:14:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.221
X-Spam-Level: 
X-Spam-Status: No, score=-10.221 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ll0pnyZB97AN for <[e-mail]>; Fri,  8 Apr 2011 10:14:18 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id C36E13A68EC for <[e-mail]>; Fri,  8 Apr 2011 10:14:17 -0700 (PDT)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p38HFjls005151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Apr 2011 19:15:50 +0200 (MEST)
From: Martin Rex <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail] (Richard L. Barnes)
Date: Fri, 8 Apr 2011 19:15:44 +0200 (MEST)
In-Reply-To: <[e-mail]> from "Richard L. Barnes" at Apr 8, 11 01:02:51 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: [e-mail]
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2011 17:14:18 -0000

Richard L. Barnes wrote:
> 
> >> Clarification:
> >> You only really have to provision the EE cert in the TLS server.
> >> The client can get the TA from DANE.
> >> 
> >> So the alternatives are:
> >> 1. Only EE cert in TLS, CA in DANE
> >> 2. EE + CA in TLS, hash of CA in DANE
> >> 
> >> Only on the second case do you have to provision a "chain" in TLS.
> >> In the first case, it's just an EE cert.
> > 
> > I'm sorry, this assertion is wrong.
> > 
> > I know that there are defective TLS implementations that let you get
> > away with this, but the procotol spec is clear.
> > 
> > A TLS server must send his _entire_ certificate chain  in the Server
> > Certificate handshake message.  It may optionally omit the self-signed rootCA
> > cert at the end of the chain.  But in order to know that _only_ the
> > self-signed rootCA cert at the end of the chain is missing, a TLS
> > implementation MUST have that self-signed rootCA cert.
> 
> ... and it gets that cert from DANE.  The CA that's provisioned in DANE in this case *is* the root CA.  It's a two-hop chain (root CA, EE), so you're saying exactly the same thing that I said: That the server can send either the chain (CA+EE) or the EE cert alone.  


You're missing the point.

Due to its complete lack of a PKI credentials concept, the configuration of
the TLS server with OpenSSL is quite error prone.  And due to the
lack of plausibility checks in the OpenSSL TLS implementation, all
configuration errors of the admin will result in TLS protocol violations
that the TLS communication peer has to deal with (which it often can not),
rather than a local error message to the admin that the configuration
is defective or incomplete and will have to be fixed before it can
be used.

Most, if not all, commercial CAs are using intermediate CA certs these
days when issuing TLS server certificates, so that a correct TLS server
configuration of an OpenSSL-based Web-Server (like Apache) requires
the use of a seperate "SSLCertificateChainFile" (I assume that is the
parameter) in addition to the "SSLCertificateFile".

And if there is more than one intermediate CA cert involved, all of the
intermediate CA certs must be added to SSLCertificateChainFile.
Unfortunately, OpenSSL neither sorts nor weeds out the contents passed
through the Apache SSLCertificateChainFile parameter when composing
the Server Certificate handshake message, which can, and often does
result in TLS protocol violations and interop problems


-Martin

From [e-mail]  Fri Apr  8 10:28:03 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3124E3A6959 for <[e-mail]>; Fri,  8 Apr 2011 10:28:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.48
X-Spam-Level: 
X-Spam-Status: No, score=-102.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4oghrE+prCoD for <[e-mail]>; Fri,  8 Apr 2011 10:28:02 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 81CA63A68D4 for <[e-mail]>; Fri,  8 Apr 2011 10:28:02 -0700 (PDT)
Received: from [192.1.255.182] (port=62519 helo=col-dhcp-192-1-255-182.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from <[e-mail]>) id 1Q8FVD-000HLM-GB; Fri, 08 Apr 2011 13:29:47 -0400
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: "Richard L. Barnes" <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Fri, 8 Apr 2011 13:29:45 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]>
To: [e-mail]
X-Mailer: Apple Mail (2.1082)
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2011 17:28:03 -0000

Martin,

We're not talking about commercial CAs.  We're talking about when a TLS =
server operator wants to act as his own TA.  So I don't see how your =
last to paragraphs relate to anything.

As for the first paragraph, it's perfectly feasible for admin tools to =
verify the correctness of a self-generated cert chain; see the "openssl =
verify" step in my earlier email.

--Richard




On Apr 8, 2011, at 1:15 PM, Martin Rex wrote:

> Richard L. Barnes wrote:
>>=20
>>>> Clarification:
>>>> You only really have to provision the EE cert in the TLS server.
>>>> The client can get the TA from DANE.
>>>>=20
>>>> So the alternatives are:
>>>> 1. Only EE cert in TLS, CA in DANE
>>>> 2. EE + CA in TLS, hash of CA in DANE
>>>>=20
>>>> Only on the second case do you have to provision a "chain" in TLS.
>>>> In the first case, it's just an EE cert.
>>>=20
>>> I'm sorry, this assertion is wrong.
>>>=20
>>> I know that there are defective TLS implementations that let you get
>>> away with this, but the procotol spec is clear.
>>>=20
>>> A TLS server must send his _entire_ certificate chain  in the Server
>>> Certificate handshake message.  It may optionally omit the =
self-signed rootCA
>>> cert at the end of the chain.  But in order to know that _only_ the
>>> self-signed rootCA cert at the end of the chain is missing, a TLS
>>> implementation MUST have that self-signed rootCA cert.
>>=20
>> ... and it gets that cert from DANE.  The CA that's provisioned in =
DANE in this case *is* the root CA.  It's a two-hop chain (root CA, EE), =
so you're saying exactly the same thing that I said: That the server can =
send either the chain (CA+EE) or the EE cert alone. =20
>=20
>=20
> You're missing the point.
>=20
> Due to its complete lack of a PKI credentials concept, the =
configuration of
> the TLS server with OpenSSL is quite error prone.  And due to the
> lack of plausibility checks in the OpenSSL TLS implementation, all
> configuration errors of the admin will result in TLS protocol =
violations
> that the TLS communication peer has to deal with (which it often can =
not),
> rather than a local error message to the admin that the configuration
> is defective or incomplete and will have to be fixed before it can
> be used.
>=20
> Most, if not all, commercial CAs are using intermediate CA certs these
> days when issuing TLS server certificates, so that a correct TLS =
server
> configuration of an OpenSSL-based Web-Server (like Apache) requires
> the use of a seperate "SSLCertificateChainFile" (I assume that is the
> parameter) in addition to the "SSLCertificateFile".
>=20
> And if there is more than one intermediate CA cert involved, all of =
the
> intermediate CA certs must be added to SSLCertificateChainFile.
> Unfortunately, OpenSSL neither sorts nor weeds out the contents passed
> through the Apache SSLCertificateChainFile parameter when composing
> the Server Certificate handshake message, which can, and often does
> result in TLS protocol violations and interop problems
>=20
>=20
> -Martin


From [e-mail]  Fri Apr  8 10:35:02 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC9C63A697E for <[e-mail]>; Fri,  8 Apr 2011 10:35:01 -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=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJQ9CWCVK3nY for <[e-mail]>; Fri,  8 Apr 2011 10:35:00 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id EE5853A68D5 for <[e-mail]>; Fri,  8 Apr 2011 10:34:59 -0700 (PDT)
Received: by iwn39 with SMTP id 39so4543567iwn.31 for <[e-mail]>; Fri, 08 Apr 2011 10:36:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.42.213.202 with SMTP id gx10mr3511437icb.498.1302284205009; Fri, 08 Apr 2011 10:36:45 -0700 (PDT)
Received: by 10.231.194.87 with HTTP; Fri, 8 Apr 2011 10:36:44 -0700 (PDT)
X-Originating-IP: [67.51.72.122]
Date: Fri, 8 Apr 2011 10:36:44 -0700
Message-ID: <[e-mail]>
From: Kirk Hall <[e-mail]>
To: [e-mail]
Content-Type: multipart/alternative; boundary=20cf30549f456faa7704a06babd3
Subject: [dane] Use Cases Document
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: [e-mail]
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2011 17:35:02 -0000

--20cf30549f456faa7704a06babd3
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

I=92ve been reading the DANE discussion for many weeks, but this is my firs=
t
posting.  My background is with CAs, first as head of authentication
services at GeoTrust and now as COO with AffirmTrust.

The basic concept of DANE =96 binding a public key (either self-signed or f=
rom
a CA) to a domain at the DNS operator level =96 is intriguing and could be =
a
useful function, particularly for machine-to-machine communications.  But I
have some concerns.

I recognize that this is not the place to work out the details concerning
how this function would be implemented, including UI issues, but I notice
from the previous postings that a major DANE goal for some people is to
allow domain owners to authenticate their own servers through self-signed
certs, specifically without using a CA.  In fact, the Abstract for the DANE
proposal states in part =93Instead of trusting a certification authority to
have made this association correctly, the user might instead trust the
authoritative DNS server for the domain name to make that association.=94  =
So
the question of =93trust=94 and how DANE would be used in a practical way h=
as
already been introduced in the Abstract itself.  In addition, some postings
have also explicitly proposed that under DANE, a self-signed cert associate=
d
with the domain at the DNS level should be treated as the equivalent of a
Domain Validated (DV) cert for the same domain.

I=92m concerned that there is a misconception of what CAs do before issuing=
 DV
certificates.  In fact, CAs employ significant anti-fraud safeguards before
issuing DV certs, and it=92s not clear to me whether or not these safeguard=
s
would also apply to self-signed certs under

DANE.ANTI-FRAUD SAFEGUARDS USED BY CAs IN ISSUING DV CERTS

Here are some of the anti-fraud safeguards used by CAs when issuing DV cert=
s
to a domain.

(1) CAs review DV cert requests for =93high risk=94 organization and domain
names that are most commonly targeted in phishing and other fraudulent
schemes, and reject those cert requests.  These lists include (a) internal
databases maintained by the CA that include previously revoked certificates
as well as requests that were previously rejected because of suspected
phishing or other fraudulent usage, and (b) potential phishing targets as
published by the Anti-Phishing Work Group (APWG) and similar groups.

In addition, CAs also review all DV certificate requests against =93denied
lists=94, including government denied lists, lists of prohibited persons, o=
r
other lists that prohibit doing business with an organization or person
under the laws of the country of the CA=92s jurisdiction of operation.

This is not an idle or hypothetical threat to consumers.  For example, *ALL=
*
of the following domain names are available *TODAY* for anyone to register:

your-account-bankofamerica.com

my-email-live.com

google-accounts.com

my-paypal-account.com

After checking these proposed domain names against their high risk and
denied lists, a good CA would not issue a DV cert for the domains, even if
the domain owners prove domain ownership and control.

Does DANE contemplate that the DNS operators would also reject domain
filings based on high risk/blacklist/spam lists, APWG lists, etc.?  Do the
DNS operators want to take that on?

(2) CAs also employ other anti-fraud algorithms of their own against bad DV
cert applications, and are constantly improving the algorithms.  In
addition, many CAs offer warranties and carry E&O/professional malpractice
insurance to cover potential losses from DV cert authentication mistakes =
=96
and these requirements will likely become mandatory for all CAs in the new
Baseline Requirements that the CA-Browser Forum is drafting to apply to all
certificates.

Do you contemplate that DNS operators would do anything similar for
self-signed certs?

(3) DV certs have a clear chain of liability back to the issuing CA. The CA=
s
today do a pretty good job in preventing high risk similar-named domains,
like =93paypall.com=94,  from getting certs for fraud and phishing purposes=
.

Under DANE, if a self-signed certificate issued in the name of =93paypall.c=
om=94
is accepted by a DNS operator and is used in phishing attacks, who would be
responsible for any resulting consumer spoofing - the browsers, the DNS
operators, and/or the registrar/registry that registered the domain name?

(4) CAs must comply with all the security and vetting infrastructure that
Mozilla, Microsoft, Opera and the CA-Browser Forum have imposed over the
years to minimize mistakes and misuse of certificates (e.g., annual WebTrus=
t
audits, insurance minimums, liability and warranty provisions, naming rules=
,
etc.). These processes have generally helped CAs do a good job in regulatin=
g
themselves to prevent rogue certificate requests.

Will similar requirements be imposed on the DNS operators before they can
accept self-signed DANE certificates?

(5) Bad certs can be revoked, and the industry is working very hard right
now on improving the revocation process.

If there is a =93bad=94 self-signed cert associated with a domain by a DNS
operator and/or a DNS operator receives a report of fraud or phishing
associated with a domain, will DANE have a way to remove, revoke, or
otherwise flag the cert as =93bad=94?

Again, I think these questions are relevant to the =93trust=94 issues alrea=
dy
cited in the Abstract for DANE, and will also be very helpful in
establishing relevant use cases for the DANE specifications.

Thanks for your consideration.

--20cf30549f456faa7704a06babd3
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div>I=92ve been reading the DANE discussion for many weeks, but this is my=
 first posting.=A0 My background is with CAs, first as head of authenticati=
on services at GeoTrust and now as COO with AffirmTrust.<br>=A0<br>The basi=
c concept of DANE =96 binding a public key (either self-signed or from a CA=
) to a domain at the DNS operator level =96 is intriguing and could be a us=
eful function, particularly for machine-to-machine communications.=A0 But I=
 have some concerns.</div>

<div><br>I recognize that this is not the place to work out the details con=
cerning how this function would be implemented, including UI issues, but I =
notice from the previous postings that a major DANE goal for some people is=
 to allow domain owners to authenticate their own servers through self-sign=
ed certs, specifically without using a CA.=A0 In fact, the Abstract for the=
 DANE proposal states in part =93Instead of trusting a certification author=
ity to have made this association correctly, the user might instead trust t=
he authoritative DNS server for the domain name to make that association.=
=94=A0 So the question of =93trust=94 and how DANE would be used in a pract=
ical way has already been introduced in the Abstract itself.=A0 In addition=
, some postings have also explicitly proposed that under DANE, a self-signe=
d cert associated with the domain at the DNS level should be treated as the=
 equivalent of a Domain Validated (DV) cert for the same domain.</div>

<div>=A0</div>
<div>I=92m concerned that there is a misconception of what CAs do before is=
suing DV certificates.=A0 In fact, CAs employ significant anti-fraud safegu=
ards before issuing DV certs, and it=92s not clear to me whether or not the=
se safeguards would also apply to self-signed certs under </div>

<div>=A0</div>
<div>DANE.ANTI-FRAUD SAFEGUARDS USED BY CAs IN ISSUING DV CERTS</div>
<div>=A0</div>
<div>Here are some of the anti-fraud safeguards used by CAs when issuing DV=
 certs to a domain.=A0 </div>
<div>=A0</div>
<div>(1) CAs review DV cert requests for =93high risk=94 organization and d=
omain names that are most commonly targeted in phishing and other fraudulen=
t schemes, and reject those cert requests.=A0 These lists include (a) inter=
nal databases maintained by the CA that include previously revoked certific=
ates as well as requests that were previously rejected because of suspected=
 phishing or other fraudulent usage, and (b) potential phishing targets as =
published by the Anti-Phishing Work Group (APWG) and similar groups.=A0 <br=
>
=A0<br>In addition, CAs also review all DV certificate requests against =93=
denied lists=94, including government denied lists, lists of prohibited per=
sons, or other lists that prohibit doing business with an organization or p=
erson under the laws of the country of the CA=92s jurisdiction of operation=
.<br>
=A0<br>This is not an idle or hypothetical threat to consumers.=A0 For exam=
ple, *ALL* of the following domain names are available *TODAY* for anyone t=
o register:<br>=A0<br><a href=3D"http://your-account-bankofamerica.com">you=
r-account-bankofamerica.com</a><br>
=A0<br><a href=3D"http://my-email-live.com">my-email-live.com</a><br>=A0<br=
><a href=3D"http://google-accounts.com">google-accounts.com</a><br>=A0<br><=
a href=3D"http://my-paypal-account.com">my-paypal-account.com</a><br>=A0<br=
>After checking these proposed domain names against their high risk and den=
ied lists, a good CA would not issue a DV cert for the domains, even if the=
 domain owners prove domain ownership and control.=A0 <br>
=A0<br>Does DANE contemplate that the DNS operators would also reject domai=
n filings based on high risk/blacklist/spam lists, APWG lists, etc.?=A0 Do =
the DNS operators want to take that on?<br>=A0<br>(2) CAs also employ other=
 anti-fraud algorithms of their own against bad DV cert applications, and a=
re constantly improving the algorithms.=A0 In addition, many CAs offer warr=
anties and carry E&amp;O/professional malpractice insurance to cover potent=
ial losses from DV cert authentication mistakes =96 and these requirements =
will likely become mandatory for all CAs in the new Baseline Requirements t=
hat the CA-Browser Forum is drafting to apply to all certificates.=A0 <br>
=A0<br>Do you contemplate that DNS operators would do anything similar for =
self-signed certs?=A0 <br>=A0<br>(3) DV certs have a clear chain of liabili=
ty back to the issuing CA. The CAs today do a pretty good job in preventing=
 high risk similar-named domains, like =93<a href=3D"http://paypall.com">pa=
ypall.com</a>=94,=A0 from getting certs for fraud and phishing purposes.<br=
>
=A0<br>Under DANE, if a self-signed certificate issued in the name of =93<a=
 href=3D"http://paypall.com">paypall.com</a>=94 is accepted by a DNS operat=
or and is used in phishing attacks, who would be responsible for any result=
ing consumer spoofing - the browsers, the DNS operators, and/or the registr=
ar/registry that registered the domain name?<br>
=A0<br>(4) CAs must comply with all the security and vetting infrastructure=
 that Mozilla, Microsoft, Opera and the CA-Browser Forum have imposed over =
the years to minimize mistakes and misuse of certificates (e.g., annual Web=
Trust audits, insurance minimums, liability and warranty provisions, naming=
 rules, etc.). These processes have generally helped CAs do a good job in r=
egulating themselves to prevent rogue certificate requests. <br>
=A0<br>Will similar requirements be imposed on the DNS operators before the=
y can accept self-signed DANE certificates? <br>=A0<br>(5) Bad certs can be=
 revoked, and the industry is working very hard right now on improving the =
revocation process.=A0 <br>
=A0<br>If there is a =93bad=94 self-signed cert associated with a domain by=
 a DNS operator and/or a DNS operator receives a report of fraud or phishin=
g associated with a domain, will DANE have a way to remove, revoke, or othe=
rwise flag the cert as =93bad=94?<br>
=A0<br>Again, I think these questions are relevant to the =93trust=94 issue=
s already cited in the Abstract for DANE, and will also be very helpful in =
establishing relevant use cases for the DANE specifications.<br>=A0<br>Than=
ks for your consideration.</div>

--20cf30549f456faa7704a06babd3--

From [e-mail]  Fri Apr  8 10:45:42 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CF253A69EE for <[e-mail]>; Fri,  8 Apr 2011 10:45:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.222
X-Spam-Level: 
X-Spam-Status: No, score=-10.222 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zP+BdIPRgG5 for <[e-mail]>; Fri,  8 Apr 2011 10:45:41 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 4F43E3A69EB for <[e-mail]>; Fri,  8 Apr 2011 10:45:41 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p38HlNPO029696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Apr 2011 19:47:23 +0200 (MEST)
From: Martin Rex <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail] (Richard L. Barnes)
Date: Fri, 8 Apr 2011 19:47:22 +0200 (MEST)
In-Reply-To: <[e-mail]> from "Richard L. Barnes" at Apr 8, 11 01:29:45 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: [e-mail]
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2011 17:45:42 -0000

Richard L. Barnes wrote:
> 
> We're not talking about commercial CAs.  We're talking about when
> a TLS server operator wants to act as his own TA.  So I don't see
> how your last to paragraphs relate to anything.

The TLS server implementation does not know or care whether your
CA cert is from a commercial CA or a do-it-yourself CA.

A TLS Server configuration with a CA-signed server cert is harder to create
and harder to configure that a simple self-signed EE server cert.


> 
> As for the first paragraph, it's perfectly feasible for admin tools
> to verify the correctness of a self-generated cert chain; see the
> "openssl verify" step in my earlier email.

Looks like a very unnecessary usability problem to me.

The code for checking a cert chain already exists in OpenSSL, and
it is used whenever a peer's cert chain is received.  There is really
no excuse for the TLS server side implementation to not check its
own cert chain for _obvious_ inconsistencies, such as missing
intermediate CA certs and garbled cert order, at some point before
composing and sending a Server Certificate TLS handshake message.

A server that serves more than a single connect could perform
this check once on the initial call where the server cert and
cert chain certificates are provided.

-Martin


From [e-mail]  Fri Apr  8 10:49:59 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 012F03A6954 for <[e-mail]>; Fri,  8 Apr 2011 10:49:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.485
X-Spam-Level: 
X-Spam-Status: No, score=-102.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bs4y2v5wwMj for <[e-mail]>; Fri,  8 Apr 2011 10:49:58 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 74BB03A68BD for <[e-mail]>; Fri,  8 Apr 2011 10:49:58 -0700 (PDT)
Received: from [192.1.255.182] (port=62536 helo=col-dhcp-192-1-255-182.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from <[e-mail]>) id 1Q8FqR-000Hco-P8; Fri, 08 Apr 2011 13:51:43 -0400
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: "Richard L. Barnes" <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Fri, 8 Apr 2011 13:51:40 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]>
To: [e-mail]
X-Mailer: Apple Mail (2.1082)
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2011 17:49:59 -0000

> The TLS server implementation does not know or care whether your
> CA cert is from a commercial CA or a do-it-yourself CA.

Agreed.


> A TLS Server configuration with a CA-signed server cert is harder to =
create
> and harder to configure that a simple self-signed EE server cert.

Disagree.  If the EE cert is signed by a trusted CA cert (acquired from =
DANE), then there is no need to configure the TLS server with anything =
more than the EE cert.  The client can retrieve the CA cert from the DNS =
with DANE.

--Richard=

From [e-mail]  Fri Apr  8 11:04:59 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 692D43A6A09 for <[e-mail]>; Fri,  8 Apr 2011 11:04:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.184
X-Spam-Level: 
X-Spam-Status: No, score=-106.184 tagged_above=-999 required=5 tests=[AWL=0.415, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLFpglJi--4x for <[e-mail]>; Fri,  8 Apr 2011 11:04:58 -0700 (PDT)
Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by core3.amsl.com (Postfix) with ESMTP id 14F163A6A03 for <[e-mail]>; Fri,  8 Apr 2011 11:04:57 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id B007D3E4099; Fri,  8 Apr 2011 19:06:37 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1302285997; bh=A9QNH6/IjfBYaK xWeilzl+JyLMyD5bwL1angRcGzBg4=; b=ox+vqM+GHrghuH+ATcS9SMirWBOjyn wlxlsbbcAoknfNknxc+KJnDOQKoR4uaAeXP51WiTRj9h78zkRz0WnKe2MqWnVsL0 3gpCcf12r2eyKS/rA9OVYqwum7W8CjjfoMxu2EXcaUk34MUl8rdFU5ok8tG2QzJ4 xZ9FJo/Vylo302wI0zuUsoWV2wJrLibWTMd5rqdZA9SzMzxoo/aXkkeEtWQBZWqd fq+AgNpKlRsj0/eg6vrm7exKgOV3y+xEbUcIFMZXnbfmSzyWESVeT90OULjOdkBE Ct87bxmMGdh0v05B/t58W51vYf5lWyw4WtUzM5meDnu3d2rpOjxPZw0A==
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id zW9t1oIbXbaB; Fri,  8 Apr 2011 19:06:37 +0100 (IST)
Received: from [10.87.48.3] (unknown [86.45.62.72]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 14AF93E4092; Fri,  8 Apr 2011 19:06:37 +0100 (IST)
Message-ID: <[e-mail]>
Date: Fri, 08 Apr 2011 19:06:36 +0100
From: Stephen Farrell <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8
MIME-Version: 1.0
To: Phillip Hallam-Baker <[e-mail]>
References: <[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2011 18:04:59 -0000

A couple of clarifications...

On 08/04/11 17:04, Phillip Hallam-Baker wrote:
> As Stephen Farrell points out, Steve Kent is wrong on this point. 

Wrong. I've said nothing either way about anything Steve has
said here on this topic.

I disagreed with Richard's interpretation of 5280 and with his
claim that that means that this group can't use EE self-signed
certs (if that's what he was saying).

> And he
> was the editor of the spec. 

One of them. Dave Cooper really did most of the work, and 5280
is just the latest rfc going back to 2459 so there are lots of
folks with just as much or more heritage. The point is not who
said something, but what the rfc says.

S.

From [e-mail]  Fri Apr  8 11:26:15 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C833F3A69E9 for <[e-mail]>; Fri,  8 Apr 2011 11:26:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.99
X-Spam-Level: 
X-Spam-Status: No, score=-2.99 tagged_above=-999 required=5 tests=[AWL=-0.392,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2Ce-S0iK3a0 for <[e-mail]>; Fri,  8 Apr 2011 11:26:14 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 8F2763A699C for <[e-mail]>; Fri,  8 Apr 2011 11:26:14 -0700 (PDT)
Received: by vxg33 with SMTP id 33so3545612vxg.31 for <[e-mail]>; Fri, 08 Apr 2011 11:27:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=2O5oAuu0te5/+iq7YxRm5ND8kNWHZw0z2IjswLpQoNw=; b=R+r4AMWGIqH6U0924CTb7uOaHfJMpZ+/SvY6Dbw4AhytpHxWzZ4avkBPSgrIDDWY1D 4DkimaI68uWq5iUMdPh6akhPBEg5xKp3tsejJdDwYJZiOxVTd3+Fx7GfA0DFYDDd9hRu GSk+0yZvZAQCCN08m0iEr6+VG4Me31eGtLlXA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=suFCEWcyTsEfMvKDwxUFqezv56dlBSfzDcNVs6RarbQ6wK2SVwseoyMIf27CylyIEw Vu7AUQewpz+yYPEzdeB1NhPCifioL7N/xCGxDFl8n22160QJ6nPvpB1I52Z8kO93KoXH IrO10l22MKZ+YS8M8ASiBinHe+f+L3D9hxNGg=
MIME-Version: 1.0
Received: by 10.52.65.34 with SMTP id u2mr1138819vds.189.1302287279706; Fri, 08 Apr 2011 11:27:59 -0700 (PDT)
Received: by 10.52.166.230 with HTTP; Fri, 8 Apr 2011 11:27:59 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 8 Apr 2011 18:27:59 +0000
Message-ID: <BANLkTinT+=[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: Stephen Farrell <[e-mail]>
Content-Type: multipart/alternative; boundary=bcaec5016413b3d1d904a06c625a
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2011 18:26:15 -0000

--bcaec5016413b3d1d904a06c625a
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Apr 8, 2011 at 6:06 PM, Stephen Farrell
<[e-mail]>wrote:

>
> A couple of clarifications...
>
> On 08/04/11 17:04, Phillip Hallam-Baker wrote:
> > As Stephen Farrell points out, Steve Kent is wrong on this point.
>
> Wrong. I've said nothing either way about anything Steve has
> said here on this topic.
>
> I disagreed with Richard's interpretation of 5280 and with his
> claim that that means that this group can't use EE self-signed
> certs (if that's what he was saying).


Oh, in that case appols to Steve K. The thread has metastacized to the point
where attribution is confused.


> And he
> > was the editor of the spec.
>
> One of them. Dave Cooper really did most of the work, and 5280
> is just the latest rfc going back to 2459 so there are lots of
> folks with just as much or more heritage. The point is not who
> said something, but what the rfc says.
>

Well yes and no. What really matters is the running code and how long the
discussion goes on for. We all know that DANE code is going to accept self
signed EE certs regardless of what the WG says on the matter.

Is there any reason why the DANE spec needs to say anything more than 'go
read the PKIX and TLS specs'?

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

--bcaec5016413b3d1d904a06c625a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Fri, Apr 8, 2011 at 6:06 PM, Stephen =
Farrell <span dir=3D"ltr">&lt;<a href=3D"mailto:[e-mail]">=
[e-mail]</a>&gt;</span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex;">
<br>
A couple of clarifications...<br>
<div class=3D"im"><br>
On 08/04/11 17:04, Phillip Hallam-Baker wrote:<br>
&gt; As Stephen Farrell points out, Steve Kent is wrong on this point.<br>
<br>
</div>Wrong. I&#39;ve said nothing either way about anything Steve has<br>
said here on this topic.<br>
<br>
I disagreed with Richard&#39;s interpretation of 5280 and with his<br>
claim that that means that this group can&#39;t use EE self-signed<br>
certs (if that&#39;s what he was saying).</blockquote><div><br></div><div>O=
h, in that case appols to Steve K. The thread has metastacized to the point=
 where attribution is confused.</div><div><br></div><div><br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex;">
<div class=3D"im">
&gt; And he<br>
&gt; was the editor of the spec.<br>
<br>
</div>One of them. Dave Cooper really did most of the work, and 5280<br>
is just the latest rfc going back to 2459 so there are lots of<br>
folks with just as much or more heritage. The point is not who<br>
said something, but what the rfc says.<font class=3D"Apple-style-span" colo=
r=3D"#888888"><br></font></blockquote></div><br clear=3D"all">Well yes and =
no. What really matters is the running code and how long the discussion goe=
s on for. We all know that DANE code is going to accept self signed EE cert=
s regardless of what the WG says on the matter.<div>
<br></div><div>Is there any reason why the DANE spec needs to say anything =
more than &#39;go read the PKIX and TLS specs&#39;?</div><div><br>-- <br>We=
bsite: <a href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br>
<br>
</div>

--bcaec5016413b3d1d904a06c625a--

From [e-mail]  Fri Apr  8 11:27:11 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33C3E3A6A13 for <[e-mail]>; Fri,  8 Apr 2011 11:27:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.523
X-Spam-Level: 
X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ne3gSItR8288 for <[e-mail]>; Fri,  8 Apr 2011 11:27:10 -0700 (PDT)
Received: from homiemail-a10.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by core3.amsl.com (Postfix) with ESMTP id 47CD13A69E2 for <[e-mail]>; Fri,  8 Apr 2011 11:27:10 -0700 (PDT)
Received: from homiemail-a10.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a10.g.dreamhost.com (Postfix) with ESMTP id BE3D7280073; Fri,  8 Apr 2011 11:28:55 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=Xwsd80XihH4lV85zF9DTMUw4AEk7mmPVacNCNNogJ64 H2F+sRHFC+lSRSrVOjN8xDVbtZ7dGBzl3jfNJ2VvuujR3jsTzSwgiC/WekN7LRfb ChwY4dehNJUpE/14ROdwyk3Jzk7zFJyL9JACD3Lt9uQ4232j7gw7uCdD7f/dMl7o =
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=rPzs8KudgLKlttPp3GhAvWhSPTs=; b=SsGJ6ZCFcC 5vL2FSCVaKCHMaYnVD7wyPd1mUR3kx3MvhvLnZR403WhHfavvr7wT/gbT1gXVGep bGZVmceHCSp55RsdiM2f2p/Mpa6HjQLx4L96hUUDZB9uSKiyg8RIvR4+Nl5qyOdT PC8KP6gnl/vct+xvaSFuAn0Y/uFH9KMsY=
Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: [e-mail]) by homiemail-a10.g.dreamhost.com (Postfix) with ESMTPA id 78D16280075;  Fri,  8 Apr 2011 11:28:54 -0700 (PDT)
From: Matt McCutchen <[e-mail]>
To: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain; charset="UTF-8"
Date: Fri, 08 Apr 2011 14:28:53 -0400
Message-ID: <1302287333.10367.10.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.3 
Content-Transfer-Encoding: quoted-printable
Cc: [e-mail]
Subject: [dane] CA DV checks other than domain control
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2011 18:27:11 -0000

On Fri, 2011-04-08 at 10:36 -0700, Kirk Hall wrote:
> I=E2=80=99m concerned that there is a misconception of what CAs do befo=
re
> issuing DV certificates.  In fact, CAs employ significant anti-fraud
> safeguards before issuing DV certs, and it=E2=80=99s not clear to me wh=
ether
> or not these safeguards would also apply to self-signed certs under=20
> DANE.

Thank you so much for providing this list!  This is indeed something we
need to discuss.  In previous discussion in mozilla.dev.security.policy,
Eddy Nigg stated the existence of such measures but declined to work
through them with me in detail
(https://groups.google.com/group/mozilla.dev.security.policy/browse_threa=
d/thread/c52b6de458ad54be/d21853d40b17b870).  I would urge anyone who kno=
ws of more such measures to add them here.

I'll respond to the actual points later.

--=20
Matt


From [e-mail]  Fri Apr  8 11:28:35 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33BD53A6A15 for <[e-mail]>; Fri,  8 Apr 2011 11:28:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.486
X-Spam-Level: 
X-Spam-Status: No, score=-3.486 tagged_above=-999 required=5 tests=[AWL=0.112,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HkBsA784DNu4 for <[e-mail]>; Fri,  8 Apr 2011 11:28:34 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 4431B3A6A18 for <[e-mail]>; Fri,  8 Apr 2011 11:28:34 -0700 (PDT)
Received: by vws12 with SMTP id 12so3574333vws.31 for <[e-mail]>; Fri, 08 Apr 2011 11:30:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ref6RLzbbBnoq0yPKF64Z6Oi2P5QO9bW5J8Dv7s3nnY=; b=r14EqyW3rsSwibD+EqN1Pq+/iC+n12kEZw3twT7lga8ty9fIr0F/CQk+OhoDomi296 1oFtu/XFLlvB1hsk3GkNDWA3Ip0n8bDiPFhDLHu/NUC0YJ7GRbEoKx9/zLgH6W//Y6tr TmGBgbFHhpvmhNU98VNrBzA+sONP6CfhxSjzc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=NfYT6jmhgh0fnVJ5FGoovvugP5JkiDImdfEvtJiGh77C2d2ZHC++h03T6gBE6vjl2A ZIj1qxDF8BrEHk9wF1Kpu4xVwZ/Z+4rvQ/9GNI7C7uC6/LYOtIln5APxfkvjcljcAbdb NY4qS58VxDbWKGS36Ahr4OjHAa3nUxxgGWee8=
MIME-Version: 1.0
Received: by 10.52.65.52 with SMTP id u20mr3703776vds.309.1302287419562; Fri, 08 Apr 2011 11:30:19 -0700 (PDT)
Received: by 10.52.166.230 with HTTP; Fri, 8 Apr 2011 11:30:19 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Fri, 8 Apr 2011 18:30:19 +0000
Message-ID: <[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: "Richard L. Barnes" <[e-mail]>
Content-Type: multipart/alternative; boundary=bcaec50166a509d91b04a06c6b20
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2011 18:28:35 -0000

--bcaec50166a509d91b04a06c6b20
Content-Type: text/plain; charset=ISO-8859-1

Could we start a new thread for the EE certs thing?

It is not a use case.

EG: Alice the administrator wants to configure servers with minimal hassle


It is not a requirement

EG: Allow use of existing certificates installed and used with TLS servers


We have even determined that there isn't even a constraint here!

This is at best a technical detail for a proposal. Since we haven't got past
use cases yet, it would be premature in any case.

--bcaec50166a509d91b04a06c6b20
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Could we start a new thread for the EE certs thing?
<div><br></div><div>It is not a use case.</div><div><br></div><div>EG: Alic=
e the administrator wants to configure servers with minimal hassle</div><di=
v><br></div><div><br></div><div>It is not a requirement</div><div><br>
</div><div>EG: Allow use of existing certificates installed and used with T=
LS servers</div><div><br></div><div><br></div><div>We have even determined =
that there isn&#39;t even a constraint here!</div><div><br></div><div>This =
is at best a technical detail for a proposal. Since we haven&#39;t got past=
 use cases yet, it would be premature in any case.</div>
<div><br></div>

--bcaec50166a509d91b04a06c6b20--

From [e-mail]  Fri Apr  8 11:58:03 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1340C3A6962 for <[e-mail]>; Fri,  8 Apr 2011 11:58:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.806
X-Spam-Level: 
X-Spam-Status: No, score=-1.806 tagged_above=-999 required=5 tests=[AWL=0.194,  BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wodmawqLuVD6 for <[e-mail]>; Fri,  8 Apr 2011 11:58:02 -0700 (PDT)
Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by core3.amsl.com (Postfix) with ESMTP id F02EA3A6989 for <[e-mail]>; Fri,  8 Apr 2011 11:58:01 -0700 (PDT)
Received: by eagle.jhcloos.com (Postfix, from userid 10) id 450DE400B4; Fri,  8 Apr 2011 18:59:22 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1302289186; bh=rvqFFwem06ExWoXEj0H7Lw0q/WkBzweUBpiwVryIQXE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=hYuVxwJunCZOMg9Ry9cIlCdQnXChKgzdyaWJqnpqacdRun4b4j6FSDFNkI4N3/4nl LyXpkMDfe+8Ddpo3jeJhF64L82b/Qe61a9xHkUPCUmJghJ9BEk3g95bKUicXJhmKxr QRziId3poVvieiTVxPGVBZlVxA7JsxuZrq43eXmk=
Received: by carbon.jhcloos.org (Postfix, from userid 500) id 16D65260042; Fri,  8 Apr 2011 18:14:56 +0000 (UTC)
From: James Cloos <[e-mail]>
To: [e-mail]
In-Reply-To: <[e-mail]> (Richard L. Barnes's message of "Fri, 8 Apr 2011 13:02:51 -0400")
References: <[e-mail]> <[e-mail]>
User-Agent: Gnus/5.110016 (No Gnus v0.16) Emacs/24.0.50 (gnu/linux)
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC
Copyright: Copyright 2011 James Cloos
OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc
OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6
Date: Fri, 08 Apr 2011 14:14:56 -0400
Message-ID: <[e-mail]>
Lines: 17
MIME-Version: 1.0
Content-Type: text/plain
X-Hashcash: 1:30:110408:[e-mail]::mDOTFHAXTy8amHUR:000WqXTj
X-Hashcash: 1:30:110408:[e-mail]::o45V+AV0fmvjMeKs:0AZ5od
X-Hashcash: 1:30:110408:[e-mail]::XuGg5AvKYpPLyGay:00009MoSD
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2011 18:58:03 -0000

>>>>> "RLB" == Richard L Barnes <[e-mail]> writes:

RLB> ... and it gets that cert from DANE.  The CA that's provisioned in
RLB> DANE in this case *is* the root CA.  It's a two-hop chain (root CA,
RLB> EE), so you're saying exactly the same thing that I said: That the
RLB> server can send either the chain (CA+EE) or the EE cert alone.

The existing discussions here went in the direction that the dane trust
path verifies *only* if the cert specified in the RR exactly matches one
the of certs in the chain provided by the d?tls server.

-JimC
-- 
James Cloos <[e-mail]>         OpenPGP: 1024D/ED7DAEA6




From [e-mail]  Fri Apr  8 12:02:06 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A2993A6A07 for <[e-mail]>; Fri,  8 Apr 2011 12:02:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.828
X-Spam-Level: 
X-Spam-Status: No, score=-101.828 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41tvdX1LfNek for <[e-mail]>; Fri,  8 Apr 2011 12:02:06 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by core3.amsl.com (Postfix) with ESMTP id CDAF03A69E2 for <[e-mail]>; Fri,  8 Apr 2011 12:02:05 -0700 (PDT)
Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p38J3nZ9037032 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 8 Apr 2011 12:03:50 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Paul Hoffman <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Fri, 8 Apr 2011 12:03:49 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
To: James Cloos <[e-mail]>
X-Mailer: Apple Mail (2.1084)
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2011 19:02:06 -0000

On Apr 8, 2011, at 11:14 AM, James Cloos wrote:

>>>>>> "RLB" =3D=3D Richard L Barnes <[e-mail]> writes:
>=20
> RLB> ... and it gets that cert from DANE.  The CA that's provisioned =
in
> RLB> DANE in this case *is* the root CA.  It's a two-hop chain (root =
CA,
> RLB> EE), so you're saying exactly the same thing that I said: That =
the
> RLB> server can send either the chain (CA+EE) or the EE cert alone.
>=20
> The existing discussions here went in the direction that the dane =
trust
> path verifies *only* if the cert specified in the RR exactly matches =
one
> the of certs in the chain provided by the d?tls server.


That is not true at all. For months, we have talked about allowing the =
cert from the TLSA record represent a CA that would validate the EE cert =
from TLS. Please see the last few revs of the draft, for example.

--Paul Hoffman


From [e-mail]  Fri Apr  8 13:01:57 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F31F3A6A18 for <[e-mail]>; Fri,  8 Apr 2011 13:01:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.594
X-Spam-Level: 
X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=0.005,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4s-k7pPOnDlA for <[e-mail]>; Fri,  8 Apr 2011 13:01:56 -0700 (PDT)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 747E43A6A0B for <[e-mail]>; Fri,  8 Apr 2011 13:01:56 -0700 (PDT)
Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 88A5BC5E2; Fri,  8 Apr 2011 16:03:39 -0400 (EDT)
Date: Fri, 8 Apr 2011 16:03:39 -0400 (EDT)
From: Paul Wouters <[e-mail]>
To: "Richard L. Barnes" <[e-mail]>
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2011 20:01:57 -0000

On Fri, 8 Apr 2011, Richard L. Barnes wrote:

> > A TLS Server configuration with a CA-signed server cert is harder to create
> > and harder to configure that a simple self-signed EE server cert.
> 
> Disagree.  If the EE cert is signed by a trusted CA cert (acquired from DANE), then there is no need to configure the TLS server with anything more than the EE cert.  The client can retrieve the CA cert from the DNS with DANE.

Unfortunately, we would be going through a migration phase, where you have to support
both dane and non-dane clients. So I do forsee the need to have the information in
dane and also provide it in the TLS Server Certificate message.

Paul

From [e-mail]  Fri Apr  8 13:17:06 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8118C3A694F for <[e-mail]>; Fri,  8 Apr 2011 13:17:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.356
X-Spam-Level: 
X-Spam-Status: No, score=-1.356 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_NJABL_PROXY=1.643]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PAWzTGcKhkVv for <[e-mail]>; Fri,  8 Apr 2011 13:16:59 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 92ACA3A68CB for <[e-mail]>; Fri,  8 Apr 2011 13:16:58 -0700 (PDT)
Received: by wwa36 with SMTP id 36so3285949wwa.13 for <[e-mail]>; Fri, 08 Apr 2011 13:18:43 -0700 (PDT)
Received: by 10.216.241.136 with SMTP id g8mr2354984wer.59.1302293921808; Fri, 08 Apr 2011 13:18:41 -0700 (PDT)
Received: from bblfish.home (ALagny-751-1-20-251.w81-48.abo.wanadoo.fr [81.48.27.251]) by mx.google.com with ESMTPS id t72sm1524440wei.20.2011.04.08.13.18.39 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Apr 2011 13:18:40 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=utf-8
From: Henry Story <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Fri, 8 Apr 2011 22:18:36 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <BANLkTinOTTWSbHcGCTFN=[e-mail]> <[e-mail]> <BANLkTi=[e-mail]> <[e-mail]>
To: "Richard L. Barnes" <[e-mail]>
X-Mailer: Apple Mail (2.1082)
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2011 20:17:06 -0000

On 8 Apr 2011, at 18:18, Richard L. Barnes wrote:

> Ok, but that's just switching out a chain, if the server is already =
using TLS, or provisioning a new chain, which you would have to do =
anyway to use DANE.=20
>=20
> Either way, it's a relatively small one-time cost.

I think it is worth remembering here that most TLS servers out there are =
running self signed certificts according to the EFF Observatory. (If I =
remember correctly, there are three times more such servers then there =
are TLS servers with functionaing CA certs).=20

One can imagine a DNSsec based dns provider offering the following =
service to users switching over
 1. test the TLS ports and fetch the certs=20
 2. if those are self signed ask the admin if these are indeed the =
certificates legally present on his site
 3. Add those to DNSsec using DANE

This could not be done if one is forced to use a chain, meaning that =
bootstrapping DANE will not be as easy. Imagine the difference in =
browser support if you can tell them that in a year, 10 million sites =
will be DANE enabled.

I see that having a chain is also useful, but those seem useful for =
companies with a relation with a CA.


>=20
> --Richard
>=20
>=20
> On Apr 8, 2011, at 12:16 PM, Ben Laurie wrote:
>=20
>> On 8 April 2011 16:28, Richard L. Barnes <[e-mail]> wrote:
>>> To turn the question around, why would we not try to get it right =
this time?  Servers are going to have to do some re-provisioning anyway =
to enable DANE, and it's just not that much extra work to get it right.  =
I just did this myself as an experiment:
>>>=20
>>> To generate a self-signed (CA!) cert:
>>> openssl genrsa -out dane.key 1024
>>> openssl req -new -key dane.key -out dane-ca.csr
>>> openssl x509 -req -days 365 -in dane-ca.csr \
>>>            -signkey dane.key -out dane-ca-cert.pem
>>>=20
>>> To generate an EE cert under that:
>>> # Generate an EE cert under that certificate
>>> openssl req -new -key dane.key -out dane-server.csr
>>> openssl x509 -req -days 365 -in dane-server.csr \
>>>            -CA dane-ca-cert.pem -CAkey dane.key \
>>>            -CAcreateserial -out dane-server-cert.pem
>>>=20
>>> If you want to verify that it worked:
>>> openssl verify -CAfile dane-ca-cert.pem -purpose sslserver =
dane-server-cert.pem
>>>=20
>>> That's it!  You provision the CA cert to DANE, and you use the EE =
cert on the server just like a cert from any other CA.  The effort is =
once per cert expiry, which you as the CA can make as long as you want.
>>=20
>> That's not it - now you have to provision and configure the server(s)
>> to serve the chain.
>>=20
>>>=20
>>> --Richard
>>>=20
>>>=20
>>>=20
>>> On Apr 8, 2011, at 9:19 AM, Ben Laurie wrote:
>>>=20
>>>> On 8 April 2011 13:46, Richard L. Barnes <[e-mail]> wrote:
>>>>> To note again: The phrase "self-signed EE cert" does not make =
sense.  =46rom RFC 5280:
>>>>> "
>>>>> Self-issued certificates are generated to support changes in =
policy or operations.  Self-signed certificates are self-issued =
certificates where the digital signature may be verified by the public =
key bound into the certificate.
>>>>> "
>>>>> Since a self-signed cert has a cert issued under it (itself), it =
has to be a CA cert.
>>>>>=20
>>>>> A self-signed cert *without* the CA bits set is therefore =
malformed, and will not pass PKIX validation.
>>>>=20
>>>> This may be true in theory, but is far from true in practice - in
>>>> practice, I can put a self-signed cert on my website and it works =
just
>>>> fine (in the sense that it is not considered malformed, just rather
>>>> untrustworthy).
>>>>=20
>>>> So, this is just spec lawyering.
>>>>=20
>>>>>=20
>>>>> Which brings us back to the point that if you want certs that =
really aren't signed by anybody, you might as well be using bare keys, =
or some new data structure that only carries what you're interested in, =
e.g., key parameters but not key usage, names, issuer, etc.
>>>>>=20
>>>>> --Richard
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> On Apr 8, 2011, at 8:36 AM, Ond=C5=99ej Sur=C3=BD wrote:
>>>>>=20
>>>>>> My question to the list is if we can avoid specifying which X.509 =
version the client/server has to use and leave it to the client policy.
>>>>>>=20
>>>>>> Martin's approach seems like a reasonable one, but the question =
is if we can fit it into our draft without advice to break any existing =
standard.
>>>>>>=20
>>>>>> I know that we are standards group (to reply to PHB later in this =
thread), but we also cannot afford to ignore what's happening in the =
real world otherwise the world is going to ignore us.
>>>>>>=20
>>>>>> I think that usage of self-signed EE cert is a reasonable use =
case (which may or may not make it to the protocol) and it shouldn't be =
left out.  So please everybody let's think harder how to make things for =
non-protocol-geeks out there simpler, so the fruit of our work is a =
tasty one and not bittersweet.
>>>>>>=20
>>>>>> O.
>>>>>>=20
>>>>>> On 4/8/11 4:58 AM, Martin Rex wrote:
>>>>>>> Stephen Kent wrote:
>>>>>>>>=20
>>>>>>>> James Cloos wrote:
>>>>>>>>>=20
>>>>>>>>> EE certs in the rr is in all of the drafts, was the original =
target, is
>>>>>>>>> easy to understand and explain, and I've read more consensus =
for than
>>>>>>>>> against on the list.
>>>>>>>>>=20
>>>>>>>>> Why the sudden backlash against?
>>>>>>>>=20
>>>>>>>> It's not sudden :-). A self-signed cert is a CA cert, by =
definition (see
>>>>>>>> the cites to RFC 5280 in Paul's I-D.
>>>>>>>=20
>>>>>>> RFC 5280 is about X.509v3 certs _ONLY_.
>>>>>>>=20
>>>>>>> There is NO problem creating X.509v1 End-Entity certs that are =
self-signed.
>>>>>>> And there is no problem using any of these with implementations =
of
>>>>>>> SSLv3 and TLSv1.0.
>>>>>>>=20
>>>>>>> SSLv3 predates IETF PKIX standards, and TLSv1.0 is related to
>>>>>>> rfc-2459 rather than rfc-5280 -- but implementations of TLSv1.0
>>>>>>> were often shipped before publication of TLSv1.0 (rfc-2246) and
>>>>>>> the original PKIX certificate profile (rfc-2459).
>>>>>>>=20
>>>>>>>=20
>>>>>>> For safety, it would be sensible to ALWAYS treat X.509v1 certs =
as
>>>>>>> EndEntity certs (i.e. never accept them as signer of other =
certs).
>>>>>>> Our TLS implementation had done this initially, but we had a =
customer
>>>>>>> that had obtained server certs issued under a VeriSign X.509v1 =
CA cert
>>>>>>> (as late as 2006!), so I had to make our OEM implementation =
tolerate this.
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>>=20
>>>>>>>> The TLS spec talks in terms of an "end entity's cert" as =
representing
>>>>>>>> a a server (or client). =46rom a PKI perspective, the cert that =
represents
>>>>>>>> a server or client MUST be an EE cert,
>>>>>>>=20
>>>>>>> Like an X.509v1 self-signed EE cert.  Works perfectly fine with =
all
>>>>>>> TLS implementations that I've met.
>>>>>>>=20
>>>>>>> Keep in mind that TLS is not limited to X.509v3 certs.
>>>>>>>=20
>>>>>>>  TLSv1.0:    http://tools.ietf.org/html/rfc2246#section-7.4.2
>>>>>>>  TLSv1.1:    http://tools.ietf.org/html/rfc4346#section-7.4.2
>>>>>>>=20
>>>>>>>   7.4.2. Server certificate
>>>>>>>=20
>>>>>>>      [...]
>>>>>>>=20
>>>>>>>   Meaning of this message:
>>>>>>>       The certificate type must be appropriate for the selected =
cipher
>>>>>>>       suite's key exchange algorithm, and is generally an =
X.509v3
>>>>>>>       certificate. It must contain a key which matches the key =
exchange
>>>>>>>       method, as follows.
>>>>>>>=20
>>>>>>>=20
>>>>>>>>=20
>>>>>>>> an thus cannot be self-signed.
>>>>>>>=20
>>>>>>> TLSv1.0 and TLSv1.1 have neither a problem with X.509v1 nor
>>>>>>> with a self-signed X.509v1 End-Entity cert.
>>>>>>>=20
>>>>>>>=20
>>>>>>>> The fact that many implementations
>>>>>>>> violate IETF PKI standards in this regard, is unfortunate, but =
it is not
>>>>>>>> a basis for issuing a new IETF standard that codifies this =
behavior.
>>>>>>>=20
>>>>>>> I know that there are lots of commercial CAs that still have CA =
certs
>>>>>>> in every browser that are not valid CA certs according to PKIX / =
RFC 5280.
>>>>>>>=20
>>>>>>> But having TLSv1.0&TLSv1.1 (i.e. 99% of the installed base)
>>>>>>> accept X.509v1 self-signed EE certs is perfectly fine.
>>>>>>>=20
>>>>>>> X.509v1 is fairly close to a bare key, supported by all TLS =
implementations
>>>>>>> in the installed base, as well as tools in the installed base, =
such as
>>>>>>> the openssl.exe shell and for transfering keypairs within =
PKCS#12/PFX.
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> dane mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/dane
>>>>>=20
>>>>> _______________________________________________
>>>>> dane mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/dane
>>>>>=20
>>>=20
>>>=20
>=20
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane

Social Web Architect
http://bblfish.net/


From [e-mail]  Fri Apr  8 13:34:25 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D3063A6976 for <[e-mail]>; Fri,  8 Apr 2011 13:34:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.816
X-Spam-Level: 
X-Spam-Status: No, score=-1.816 tagged_above=-999 required=5 tests=[AWL=0.184,  BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ayOyh-t9n0U9 for <[e-mail]>; Fri,  8 Apr 2011 13:34:23 -0700 (PDT)
Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by core3.amsl.com (Postfix) with ESMTP id 076AF3A68CB for <[e-mail]>; Fri,  8 Apr 2011 13:34:22 -0700 (PDT)
Received: by eagle.jhcloos.com (Postfix, from userid 10) id 9550340202; Fri,  8 Apr 2011 20:35:42 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1302294966; bh=2TIIoextVjbzkJY8JtU3nDEQ8uxJXQMOQK/HIB3hv/Q=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=FqJMECpTCKPXX0NgUMnIe8YGPLIPj8dAu6jmxRTaShg8R41DQlb8jGcSLpZm+p4gV Dto4rJoKWPPjlBDfYlpahy3S4TtLFjASoDE8FxNTMiBQkS8V/5NPbB1c/AiTsVvkxd M/cqqiB+dbDH9ij1X3icZ81lGJ3Me5k+X/Ol0UO0=
Received: by carbon.jhcloos.org (Postfix, from userid 500) id 25545260042; Fri,  8 Apr 2011 20:25:18 +0000 (UTC)
From: James Cloos <[e-mail]>
To: Paul Hoffman <[e-mail]>
In-Reply-To: <[e-mail]> (Paul Hoffman's message of "Fri, 8 Apr 2011 12:03:49 -0700")
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Gnus/5.110016 (No Gnus v0.16) Emacs/24.0.50 (gnu/linux)
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC
Copyright: Copyright 2011 James Cloos
OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc
OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6
Date: Fri, 08 Apr 2011 16:25:18 -0400
Message-ID: <[e-mail]>
Lines: 18
MIME-Version: 1.0
Content-Type: text/plain
X-Hashcash: 1:30:110408:[e-mail]::v9sJV86VE0ExTpE9:000000000000000000000000000000000000000cNHaz
X-Hashcash: 1:30:110408:[e-mail]::G5qwwxe2ofCrTyEi:000Sbc0f
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2011 20:34:25 -0000

>>>>> "PH" == Paul Hoffman <[e-mail]> writes:

JC>> The existing discussions here went in the direction that the dane trust
JC>> path verifies *only* if the cert specified in the RR exactly matches one
JC>> the of certs in the chain provided by the d?tls server.

PH> That is not true at all. For months, we have talked about allowing the
PH> cert from the TLSA record represent a CA that would validate the EE
PH> cert from TLS. Please see the last few revs of the draft, for example.

I didn't see any contras to the discussions which concluded that the
dane rr should be ignored unless it exactly matched one the certs in the
chain presented by the tls server.  (Either by reference in the digest
case or bit-for-bit in the explicit case.)

-JimC
-- 
James Cloos <[e-mail]>         OpenPGP: 1024D/ED7DAEA6

From [e-mail]  Fri Apr  8 14:20:45 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B320F3A6993 for <[e-mail]>; Fri,  8 Apr 2011 14:20:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.727
X-Spam-Level: 
X-Spam-Status: No, score=-2.727 tagged_above=-999 required=5 tests=[AWL=0.250,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emt8dSpjzo2H for <[e-mail]>; Fri,  8 Apr 2011 14:20:45 -0700 (PDT)
Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id 190203A696F for <[e-mail]>; Fri,  8 Apr 2011 14:20:45 -0700 (PDT)
Received: by pzk30 with SMTP id 30so1703573pzk.31 for <[e-mail]>; Fri, 08 Apr 2011 14:22:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:date:x-google-sender-auth :message-id:subject:from:to:content-type; bh=FAfLdF2r3VXI7m00TRKwHd7SjFZf+x7nzVlv2ABRgII=; b=DWjytsA748Z/QwqrS/WlkAZPN4tJLkWM0clmAPwoRxBRO1LZ+i2S+D5dQlfufgmWIl 6YuXZG6dHdXAKR+DYwiFD6FF1dXI5q2eh7p/+4/joN1e0A4INJtC9B2cm6Of5psv3zWk 0xKrV1XK+qPxMRkjBdQixVWSm6jS9sl7WxzGI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=L1+Sx72FB+JzNEgvx7uNsa8Yc5klBrVgOiY+Em+8usjfwAvrrMgzfiVY4yT1P5XT+8 a/ulct4XXnGR9CwoIcPPFktKa4wQQhrH09+ANgDr2TjOI1lzcQl6WriLt1q8M5Uu9oR+ Y2A+hvOK35zR3asxyL5IhdYap1vcGVVPyCJXA=
MIME-Version: 1.0
Received: by 10.143.27.39 with SMTP id e39mr2237219wfj.155.1302297750604; Fri, 08 Apr 2011 14:22:30 -0700 (PDT)
Sender: [e-mail]
Received: by 10.68.49.73 with HTTP; Fri, 8 Apr 2011 14:22:30 -0700 (PDT)
Date: Fri, 8 Apr 2011 14:22:30 -0700
X-Google-Sender-Auth: DAzoxYyqfqdV3jmusknLLYY4jqU
Message-ID: <[e-mail]>
From: Zack Weinberg <[e-mail]>
To: [e-mail]
Content-Type: text/plain; charset=UTF-8
Subject: [dane] Requirements - HTTPS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2011 21:20:45 -0000

I'd like to lay out a short list of requirements on DANE from a web
browser implementor's perspective.  This probably overlaps quite a bit
with other people's requirement lists, but I haven't seen the web use
case pulled together in a neat package.

1) Critical requirements:  If DANE does not provide these things, web
browsers are unlikely to bother adopting it *at all*.

[Exclusion] DANE must allow a site administrator to indicate that
their server(s) will use *only* a particular finite set of keys.

[Hard failure] Clients must be required to refuse to proceed with a
connection to a site if DANE indicates a security error.

[Site compatibility] A client that implements DANE must, when
interacting with a site that has not deployed DANE, behave exactly as
a client that does not implement DANE would behave (except for making
additional DNS lookups).

[Client compatibility] A site must be able to deploy DANE without
rendering itself unavailable to clients that do not implement DANE.

[Encapsulation] If there is a DANE record at a.b.c.example, it must
*only* affect services hosted at a.b.c.example.  (I am reliably
informed that the "trust anchor" language in some revisions of this
spec breaks this requirement.)

[Predictability] Client behavior in response to DANE records must be
spelled out in the DANE specification with as little wiggle room as
possible.

2) Non-critical requirements: These would be nice to have, but their
absence would not render the spec useless to us.

[Inclusion] DANE should provide a way for sites that use self-signed
certificates (for whatever reason) to make their servers trustable
without user intervention.

[Minimal dependencies] It should be possible for a site to deploy DANE
without also deploying anything else, except DNSSEC.

[Minimal knobs] Ideally, DANE should have only one operating mode.
Practically, DANE should have as few operating modes as possible.

zw

From [e-mail]  Fri Apr  8 14:50:23 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAC4B3A69C8 for <[e-mail]>; Fri,  8 Apr 2011 14:50:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.825
X-Spam-Level: 
X-Spam-Status: No, score=-1.825 tagged_above=-999 required=5 tests=[AWL=0.175,  BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7QKumE7uqmR3 for <[e-mail]>; Fri,  8 Apr 2011 14:50:22 -0700 (PDT)
Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by core3.amsl.com (Postfix) with ESMTP id 8D0753A6905 for <[e-mail]>; Fri,  8 Apr 2011 14:50:21 -0700 (PDT)
Received: by eagle.jhcloos.com (Postfix, from userid 10) id 465A740100; Fri,  8 Apr 2011 21:51:42 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1302299526; bh=MRerOTppC3aeEAwm1/AChOw5gfJs6HvhOJWdcklnKDc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=Si7WbDcJR0dCQ5dZgr46GLjdKR/8BGCSv75eE5afDqq3Vqg0ia3jtwhJguoXoNLLn c+PuJf8XMdjnpIFHBt86CtowtJSSkrQFz/zl9C5qnf7R3z5xkdk9ZQOvb/Pif0lkDw uF+WCCxZw+ErgdUWFZJKcGm3SosfEyfO2QTM9QY8=
Received: by carbon.jhcloos.org (Postfix, from userid 500) id 66C68260042; Fri,  8 Apr 2011 21:46:16 +0000 (UTC)
From: James Cloos <[e-mail]>
To: [e-mail]
In-Reply-To: <[e-mail]> (James Cloos's message of "Fri, 08 Apr 2011 16:25:18 -0400")
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Gnus/5.110016 (No Gnus v0.16) Emacs/24.0.50 (gnu/linux)
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC
Copyright: Copyright 2011 James Cloos
OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc
OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6
Date: Fri, 08 Apr 2011 17:46:16 -0400
Message-ID: <[e-mail]>
Lines: 27
MIME-Version: 1.0
Content-Type: text/plain
X-Hashcash: 1:30:110408:[e-mail]::NvE6EjGI6ApZZhPB:0002NEwA
X-Hashcash: 1:30:110408:[e-mail]::nMrivGKeu5ysJEny:000000000000000000000000000000000000000/qlOw
Cc: Paul Hoffman <[e-mail]>
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2011 21:50:23 -0000

>>>>> "JC" == James Cloos <[e-mail]> writes:

JC> I didn't see any contras to the discussions which concluded that the
JC> dane rr should be ignored unless it exactly matched one the certs in the
JC> chain presented by the tls server.  (Either by reference in the digest
JC> case or bit-for-bit in the explicit case.)

I should add that I have no objection to supporting a setup where a CA
cert is in the RR and the chain provided by the d?tls server contains
everything up to its CA's cert rather than everything including its CA's
cert.  I just got the impression that the consensus was against that.

But I still want to see a simple scenario where the d?tls server
provides a cert whose sig is in the rr.  The fact that that cert
comes from a remote which is found via an A/AAAA lookup on the
same data as is used to look up the dane rr is sufficient trust
for the majority of d?tls use.  (Provided, of course, that the
dnssec verified.)

(Although I have to ask:  is that the hash of the text as stored in
the pem file or is that the hash of the base64-decoded binary data?
I presume the latter, but have to ask.)

-JimC
-- 
James Cloos <[e-mail]>         OpenPGP: 1024D/ED7DAEA6
  

From [e-mail]  Fri Apr  8 14:55:29 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2738A3A6905 for <[e-mail]>; Fri,  8 Apr 2011 14:55:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.987
X-Spam-Level: 
X-Spam-Status: No, score=-2.987 tagged_above=-999 required=5 tests=[AWL=-0.389, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0Bj5fWhVLck for <[e-mail]>; Fri,  8 Apr 2011 14:55:27 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id C1C103A688A for <[e-mail]>; Fri,  8 Apr 2011 14:55:27 -0700 (PDT)
Received: by vxg33 with SMTP id 33so3685530vxg.31 for <[e-mail]>; Fri, 08 Apr 2011 14:57:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=d1IMTGMEgQXIJaG1w4GcibHjRLrxcNFNt/ymBWAuaPE=; b=MRzFox3JOgCKk4oBudSprOT2lj0fmc51QlGqmyRfXDQJxU01ggioI6jwFeGg2IYW6a xd5n1turfkxfR0F8IUs2uzDpy+abpIJhyoTQTQqDxuTJv/YJ+GYskce/eDHqnIM96/X4 uDNwhFiw0eFTvRkpFTjQy2V5Jb6YueK43XKao=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=W/jeueqjXqZsKtS3IKuGn4g3S8H3vMyrf4WRrNt318oRcs7Qa0pleLmSn7+jC6CYnL vzmR+iSlMKWDP/8XtqB4QDgS7Kke3Wv4p/ndTzfGnbvE3UuWJuzfIpP/U2f34kQGopF/ 0fL+dagugOFgGILlFkRxFWeFY+OjU1qlkqf7I=
MIME-Version: 1.0
Received: by 10.52.95.175 with SMTP id dl15mr4034968vdb.69.1302299833030; Fri, 08 Apr 2011 14:57:13 -0700 (PDT)
Received: by 10.52.166.230 with HTTP; Fri, 8 Apr 2011 14:57:12 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Fri, 8 Apr 2011 21:57:12 +0000
Message-ID: <BANLkTik-dMio6So4VW=[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: [e-mail]
Content-Type: multipart/alternative; boundary=20cf307f307cf058b104a06f4eee
Cc: [e-mail]
Subject: Re: [dane] elephant use case,
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2011 21:55:29 -0000

--20cf307f307cf058b104a06f4eee
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Apr 8, 2011 at 4:42 PM, Martin Rex <[e-mail]> wrote:

> Phillip Hallam-Baker wrote:
> >
> > Could people actually take some time to learn about what the EFF data
> means
> > before engaging in this hyperbole?
> >
> > There are not and have never been 600 RA certs. The EFF people do not
> > understand what the data means or why the certs are configured the way
> they
> > are. In fact the pressure that we have had from Mozilla and other sources
> is
> > to increase the number of intermediate certs.
>
> RA "registration authorities"
>   http://en.wikipedia.org/wiki/Registration_authority
>
> do NOT have certificates themselves.  The organizations that have
> the certificate with cert signing capabilities are called CAs.
>
> What EFF likely did was that they counted the distinct CA(!!) certificates
> that are valid under the trusted roots certs in Browsers as indicated
> under "organization name" in those CA certificates.
>

We don't need to speculate as to what EFF did, they describe what they did
which was to assert that every intermediate cert in a chain with a different
subject name was an independent CA.

That was and entirely mistaken as a methodology and for them to continue to
make these claims is ignorant and dishonest.


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

--20cf307f307cf058b104a06f4eee
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Fri, Apr 8, 2011 at 4:42 PM, Martin R=
ex <span dir=3D"ltr">&lt;<a href=3D"mailto:[e-mail]">[e-mail]</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Phillip Hallam-Baker wrote:<br>
&gt;<br>
&gt; Could people actually take some time to learn about what the EFF data =
means<br>
&gt; before engaging in this hyperbole?<br>
&gt;<br>
&gt; There are not and have never been 600 RA certs. The EFF people do not<=
br>
&gt; understand what the data means or why the certs are configured the way=
 they<br>
&gt; are. In fact the pressure that we have had from Mozilla and other sour=
ces is<br>
&gt; to increase the number of intermediate certs.<br>
<br>
RA &quot;registration authorities&quot;<br>
 =A0 <a href=3D"http://en.wikipedia.org/wiki/Registration_authority" target=
=3D"_blank">http://en.wikipedia.org/wiki/Registration_authority</a><br>
<br>
do NOT have certificates themselves. =A0The organizations that have<br>
the certificate with cert signing capabilities are called CAs.<br>
<br>
What EFF likely did was that they counted the distinct CA(!!) certificates<=
br>
that are valid under the trusted roots certs in Browsers as indicated<br>
under &quot;organization name&quot; in those CA certificates.<br></blockquo=
te><div><br></div><div>We don&#39;t need to speculate as to what EFF did, t=
hey describe what they did which was to assert that every intermediate cert=
 in a chain with a different subject name was an independent CA.</div>
<div><br></div><div>That was and entirely mistaken as a methodology and for=
 them to continue to make these claims is ignorant and dishonest.</div><div=
><br></div><div>=A0</div></div>-- <br>Website: <a href=3D"http://hallambake=
r.com/">http://hallambaker.com/</a><br>
<br>

--20cf307f307cf058b104a06f4eee--

From [e-mail]  Fri Apr  8 14:59:38 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17ACD3A6A14 for <[e-mail]>; Fri,  8 Apr 2011 14:59:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.134
X-Spam-Level: 
X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.466,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kRYf5iKdu9wf for <[e-mail]>; Fri,  8 Apr 2011 14:59:36 -0700 (PDT)
Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by core3.amsl.com (Postfix) with ESMTP id EAD013A697A for <[e-mail]>; Fri,  8 Apr 2011 14:59:35 -0700 (PDT)
Received: by eagle.jhcloos.com (Postfix, from userid 10) id E471F400B4; Fri,  8 Apr 2011 22:00:56 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1302300080; bh=jx19PSWxo/11Bb2hMgN3hale58PFKfP48FNSI7Z1HTo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=xLQ49aGgQ9x8vSiQ+yMb/HIZv7/lwTp34u02gVrxbO2zxsX1cL/UG0/z/n0HIJdnP UriQQ5OtUE4Uml0ffuClmXRAB+bkEbxzNGeVYPX/kDRB4wwe4qOytZlxKwG3O24jpD U2lhKxFOEVuontaFxQUfeHXc97Od84VjLdElh0VE=
Received: by carbon.jhcloos.org (Postfix, from userid 500) id AD137260042; Fri,  8 Apr 2011 21:56:16 +0000 (UTC)
From: James Cloos <[e-mail]>
To: Zack Weinberg <[e-mail]>
In-Reply-To: <[e-mail]> (Zack Weinberg's message of "Fri, 8 Apr 2011 14:22:30 -0700")
References: <[e-mail]>
User-Agent: Gnus/5.110016 (No Gnus v0.16) Emacs/24.0.50 (gnu/linux)
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC
Copyright: Copyright 2011 James Cloos
OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc
OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6
Date: Fri, 08 Apr 2011 17:56:16 -0400
Message-ID: <[e-mail]>
Lines: 17
MIME-Version: 1.0
Content-Type: text/plain
X-Hashcash: 1:30:110408:[e-mail]::1oAXgyIKn1o0qVvk:0000000000000000000000000000000000000Q7/g
X-Hashcash: 1:30:110408:[e-mail]::9HMZuAjgZ655w0O6:000VKKwT
Cc: [e-mail]
Subject: Re: [dane] Requirements - HTTPS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2011 21:59:38 -0000

>>>>> "ZW" == Zack Weinberg <[e-mail]> writes:

ZW> [Hard failure] Clients must be required to refuse to proceed with a
ZW> connection to a site if DANE indicates a security error.

For this porpose, do you agree that a dane-indicated cecurity error can
only occur if the dnssec verified (or, perhaps, if it is provably corrupted)?

Ie, if there is no dnssec at all then fallback to existing still works
notwithstanding a dane rr?  

And when dnssec and dane both exist but the dnssec sigs do not verify,
do you envision hard failure or fallback?

-JimC
-- 
James Cloos <[e-mail]>         OpenPGP: 1024D/ED7DAEA6

From [e-mail]  Fri Apr  8 15:27:37 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 856F93A6A1C for <[e-mail]>; Fri,  8 Apr 2011 15:27:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.763
X-Spam-Level: 
X-Spam-Status: No, score=-2.763 tagged_above=-999 required=5 tests=[AWL=0.214,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Feyl8lPGHtV for <[e-mail]>; Fri,  8 Apr 2011 15:27:35 -0700 (PDT)
Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by core3.amsl.com (Postfix) with ESMTP id 7B38A3A6A0E for <[e-mail]>; Fri,  8 Apr 2011 15:27:35 -0700 (PDT)
Received: by pxi20 with SMTP id 20so2258418pxi.27 for <[e-mail]>; Fri, 08 Apr 2011 15:29:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=gXLqkmFrSz1FcLGNPDX3wN+72lqOHvMIhORkKQCIxUA=; b=ZgSzsuWr7Era5qNf9N4cEt91Nl3I6yLMl65fYN6m6Ufwm9C5rdwR8iJvqv314aeaJc ceeLRw/dI6HRd9Duek24aWg56nq7p7tqI3gU0V6Q1iN1y8YGd0nlN/N1oV0ZfecK4Kpi okyvSM0IeWBzAmmJ/cTqnCZv0wARdwCmZYipA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=pRRFbn18SK83TjloNwhybli4+ybkzP1BABx5FMYW4m6Cdy6U5uWX2dK7Ywf2P9uIga 5h6jZn/YTiGCtl4O/PcAoN+h9DlC6lcGDt7VYf/8nob722RoeW4wXuSCotVVPeh2Tew1 GCtphBD/BpRhp4buZMtHbjCNoe0RrmZf5A+Ak=
MIME-Version: 1.0
Received: by 10.142.237.17 with SMTP id k17mr2201759wfh.41.1302301760803; Fri, 08 Apr 2011 15:29:20 -0700 (PDT)
Sender: [e-mail]
Received: by 10.68.49.73 with HTTP; Fri, 8 Apr 2011 15:29:20 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Fri, 8 Apr 2011 15:29:20 -0700
X-Google-Sender-Auth: N8J6rI85b3PZEzQtYJCV_TlJsxw
Message-ID: <[e-mail]>
From: Zack Weinberg <[e-mail]>
To: James Cloos <[e-mail]>
Content-Type: text/plain; charset=UTF-8
Cc: [e-mail]
Subject: Re: [dane] Requirements - HTTPS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2011 22:27:37 -0000

On Fri, Apr 8, 2011 at 2:56 PM, James Cloos <[e-mail]> wrote:
>>>>>> "ZW" == Zack Weinberg <[e-mail]> writes:
>
> ZW> [Hard failure] Clients must be required to refuse to proceed with a
> ZW> connection to a site if DANE indicates a security error.
>
> For this porpose, do you agree that a dane-indicated cecurity error can
> only occur if the dnssec verified (or, perhaps, if it is provably corrupted)?
>
> Ie, if there is no dnssec at all then fallback to existing still works
> notwithstanding a dane rr?

Yes.  (It's too specific for a "requirements" document, but I want
words to the effect of "TLSA records whose DNSSEC validation status is
'insecure' or 'indeterminate' MUST be ignored" in the final spec.)

> And when dnssec and dane both exist but the dnssec sigs do not verify,
> do you envision hard failure or fallback?

IMO that (specifically, DNSSEC validation status "bogus" on *any*
record returned, TLSA or not) should also be a hard failure.

zw

From [e-mail]  Fri Apr  8 16:03:29 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8499F3A697A for <[e-mail]>; Fri,  8 Apr 2011 16:03:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.912
X-Spam-Level: 
X-Spam-Status: No, score=-102.912 tagged_above=-999 required=5 tests=[AWL=0.065, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ky-3iy26EIlo for <[e-mail]>; Fri,  8 Apr 2011 16:03:29 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id D66003A67E5 for <[e-mail]>; Fri,  8 Apr 2011 16:03:28 -0700 (PDT)
Received: by gyf3 with SMTP id 3so1920749gyf.31 for <[e-mail]>; Fri, 08 Apr 2011 16:05:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.91.41.14 with SMTP id t14mr2677581agj.27.1302303913908; Fri, 08 Apr 2011 16:05:13 -0700 (PDT)
Received: by 10.90.34.15 with HTTP; Fri, 8 Apr 2011 16:05:13 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Fri, 8 Apr 2011 16:05:13 -0700
Message-ID: <BANLkTinD=[e-mail]>
From: Eric Rescorla <[e-mail]>
To: Zack Weinberg <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: [e-mail]
Subject: Re: [dane] Requirements - HTTPS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2011 23:03:29 -0000

On Fri, Apr 8, 2011 at 2:22 PM, Zack Weinberg <[e-mail]> wr=
ote:
> I'd like to lay out a short list of requirements on DANE from a web
> browser implementor's perspective. =A0This probably overlaps quite a bit
> with other people's requirement lists, but I haven't seen the web use
> case pulled together in a neat package.
>
> 1) Critical requirements: =A0If DANE does not provide these things, web
> browsers are unlikely to bother adopting it *at all*.
>
> [Exclusion] DANE must allow a site administrator to indicate that
> their server(s) will use *only* a particular finite set of keys.
>
> [Hard failure] Clients must be required to refuse to proceed with a
> connection to a site if DANE indicates a security error.

I think this requires some elaboration. The browser can either:

(a) throw an overrideable error like the existing chrome/firefox errors for
CN mismatch or unknown CA.
(b) throw a non-overrideable error like what happens if it gets an NXDOMAIN=
.

I haven't formed an opinion on which of these is desireable, but surely you=
're
not saying that browser manufacturers won't adopt this without an RFC 2119
MUST for (b). After all, if the manufacturer wants to do so, nothing is sto=
pping
them from refusing the let the user override.

-Ekr

From [e-mail]  Fri Apr  8 16:26:13 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D2E63A67E5 for <[e-mail]>; Fri,  8 Apr 2011 16:26:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.79
X-Spam-Level: 
X-Spam-Status: No, score=-2.79 tagged_above=-999 required=5 tests=[AWL=0.188,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URAdGYRA7fTX for <[e-mail]>; Fri,  8 Apr 2011 16:26:11 -0700 (PDT)
Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by core3.amsl.com (Postfix) with ESMTP id EA1773A67CC for <[e-mail]>; Fri,  8 Apr 2011 16:26:10 -0700 (PDT)
Received: by pxi20 with SMTP id 20so2278018pxi.27 for <[e-mail]>; Fri, 08 Apr 2011 16:27:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=zA7JLqlZC71HeyYJeAECCzrGkx+ImrwXQC+ukv355vE=; b=L+HGGdc5ruhqE3y+lHmT/hhHTZBB8UGFeijTebq5VeYOCM+S0ufCQK/S9/kTzoCrxL GuYZPlwKzFBCGq9Y1omj4duFum64LEKBqdTVT98AG/7H3LTDBmMpvpr+jv//fEzSegg4 X90l3t5A0UTkb66kDo8o9LWXRQMRtBWBZ2I7g=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=MGPkqIK3iUgKkp1XKJHX47/0i8U2+7lU9YTZr5Nu3eYtIG/8cd+fgGNLdTd6A/zz40 2vTFRG812+mO5vfn4t4J5HxBe4wTeknAq0cuVgGuyiXojyfGAlr2Mkn10nuMbzSrIwG/ r3BPV4wdkwyIlGcsUgbDoKM6wo+rvlk7T16j4=
MIME-Version: 1.0
Received: by 10.142.250.5 with SMTP id x5mr2396842wfh.440.1302305276386; Fri, 08 Apr 2011 16:27:56 -0700 (PDT)
Sender: [e-mail]
Received: by 10.68.49.73 with HTTP; Fri, 8 Apr 2011 16:27:56 -0700 (PDT)
In-Reply-To: <BANLkTinD=[e-mail]>
References: <[e-mail]> <BANLkTinD=[e-mail]>
Date: Fri, 8 Apr 2011 16:27:56 -0700
X-Google-Sender-Auth: OLHl5L0OtfLGJ1Mf8HtoeCdymhc
Message-ID: <BANLkTimy9Gy4ip=[e-mail]>
From: Zack Weinberg <[e-mail]>
To: Eric Rescorla <[e-mail]>
Content-Type: text/plain; charset=UTF-8
Cc: [e-mail]
Subject: Re: [dane] Requirements - HTTPS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2011 23:26:13 -0000

On Fri, Apr 8, 2011 at 4:05 PM, Eric Rescorla <[e-mail]> wrote:
>>
>> [Exclusion] DANE must allow a site administrator to indicate that
>> their server(s) will use *only* a particular finite set of keys.
>>
>> [Hard failure] Clients must be required to refuse to proceed with a
>> connection to a site if DANE indicates a security error.
>
> I think this requires some elaboration. The browser can either:
>
> (a) throw an overrideable error like the existing chrome/firefox errors for
> CN mismatch or unknown CA.
> (b) throw a non-overrideable error like what happens if it gets an NXDOMAIN.
>
> I haven't formed an opinion on which of these is desireable, but surely you're
> not saying that browser manufacturers won't adopt this without an RFC 2119
> MUST for (b). After all, if the manufacturer wants to do so, nothing is stopping
> them from refusing the let the user override.

I meant the [hard failure] requirement to be at a lower level.
Suppose DANE tells you that example.com serves HTTPS with certificate
A.  Unbeknownst to you, your traffic to example.com is being
redirected to a malicious server, which presents certificate X.  The
attacker tricked a CA in your trust pool into signing that
certificate; in the absence of DANE information you would trust it.  I
want DANE to say that you MUST NOT trust that certificate.  *That's*
the text whose absence would be a deal-breaker for browsers.

(Why is it a deal-breaker?  Can't we just unilaterally decide that we
WILL NOT trust that certificate under those conditions?  In principle,
yes, but without a hard requirement in a spec to point at, there's
going to be tremendous pushback against doing anything that risks
reducing availability, and there's going to be a headache getting
*all* the browser vendors to agree on the details.)

At the application level, I would like DANE to include text saying
that the error thrown SHOULD be non-overrideable (that is, your (b),
not (a)), but as advice rather than requirement.

zw

From [e-mail]  Fri Apr  8 18:02:32 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2C0C3A6988 for <[e-mail]>; Fri,  8 Apr 2011 18:02:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.228
X-Spam-Level: 
X-Spam-Status: No, score=-102.228 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXU-3c+nZNdY for <[e-mail]>; Fri,  8 Apr 2011 18:02:32 -0700 (PDT)
Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id DC2083A6973 for <[e-mail]>; Fri,  8 Apr 2011 18:02:31 -0700 (PDT)
Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta03.westchester.pa.mail.comcast.net with comcast id VD2X1g0020Fqzac53D4JLv; Sat, 09 Apr 2011 01:04:18 +0000
Received: from odin.ulthar.us ([68.33.77.0]) by omta08.westchester.pa.mail.comcast.net with comcast id VD4H1g00g00PQ6U3UD4Hmk; Sat, 09 Apr 2011 01:04:17 +0000
Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.4/8.14.3) with ESMTP id p3914Fm5022232 for <[e-mail]>; Fri, 8 Apr 2011 21:04:15 -0400
Received: (from draco@localhost) by odin.ulthar.us (8.14.4/8.14.4/Submit) id p3914F9J022230 for [e-mail]; Fri, 8 Apr 2011 21:04:15 -0400
Date: Fri, 8 Apr 2011 21:04:15 -0400
From: Scott Schmit <[e-mail]>
To: [e-mail]
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [dane] Requirements - HTTPS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 09 Apr 2011 01:02:32 -0000

On Fri, Apr 08, 2011 at 02:22:30PM -0700, Zack Weinberg wrote dane:

I like your list, I just have a few things to add to it.

> 1) Critical requirements:  If DANE does not provide these things, web
> browsers are unlikely to bother adopting it *at all*.
> 
[Implementable] DANE must be as easy to implement or add to existing
software as possible.

The spec is useless if it takes more effort than anyone is willing to
expend to implement it, or makes it difficult to continue to support
existing use cases.

> 2) Non-critical requirements: These would be nice to have, but their
> absence would not render the spec useless to us.
> 
> [Inclusion] DANE should provide a way for sites that use self-signed
> certificates (for whatever reason) to make their servers trustable
> without user intervention.

Maybe this isn't critical to browser acceptance, but I think that this
is important to site acceptance. A lot of people use self-signed 
certificates, and I seriously doubt that DANE will suddenly inspire them
to buy a certificate from a CA. But if they can put their cert (or a 
hash of it) into the DNS, signed by DNSSEC, and make the browser 
warnings go away, I can see that happening.

-- 
Scott Schmit

From [e-mail]  Fri Apr  8 18:10:13 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A8843A6A4F for <[e-mail]>; Fri,  8 Apr 2011 18:10:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.984
X-Spam-Level: 
X-Spam-Status: No, score=-2.984 tagged_above=-999 required=5 tests=[AWL=-0.386, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXsgZ8QuVGwZ for <[e-mail]>; Fri,  8 Apr 2011 18:10:12 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id C6BAF3A6A40 for <[e-mail]>; Fri,  8 Apr 2011 18:10:11 -0700 (PDT)
Received: by vxg33 with SMTP id 33so3768474vxg.31 for <[e-mail]>; Fri, 08 Apr 2011 18:11:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HRNBG/WKj3Y6RvHy+kEw4+yb0UoOXkae2ticc9+Ou5c=; b=ckeFIujVvrelc3Lq2huRxz3MedXsZ2DJca097RPFfJq1UhKsUBH9SGDA41DDcBl7yK EOwgHYo9ZRbqZmnKu/qeqNRPl2dsh4nQqsYcptWDnQFPrzUcRyp8qngtn5dnR4F76cCU 2YTjNBg7XQ3bGtDTV3qeAhk0t4/Nb9iM8pOwc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=u6CWN5c9uwvdoKow5piW7Gx0XHbxHb/ptS7xKabH0NOqKBI2NNah+cJCob4Tz2RSOx ak2mVHjHVI0rvCUtZXMZXyfW9tNt0VjDDU2JANqrtlEOfXqiGZBcHWip9GY63NdMHpQC ZT+E/ighu23acm2v3Z7o35QmNHTYutf5HDGek=
MIME-Version: 1.0
Received: by 10.52.98.135 with SMTP id ei7mr891394vdb.229.1302311510287; Fri, 08 Apr 2011 18:11:50 -0700 (PDT)
Received: by 10.52.166.230 with HTTP; Fri, 8 Apr 2011 18:11:50 -0700 (PDT)
In-Reply-To: <BANLkTinD=[e-mail]>
References: <[e-mail]> <BANLkTinD=[e-mail]>
Date: Fri, 8 Apr 2011 21:11:50 -0400
Message-ID: <BANLkTi=5rCGVPPiBVUd0oVm9F-big4R=[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: Eric Rescorla <[e-mail]>
Content-Type: multipart/alternative; boundary=20cf307cfc68f524ef04a0720654
Cc: [e-mail]
Subject: Re: [dane] Requirements - HTTPS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 09 Apr 2011 01:10:13 -0000

--20cf307cfc68f524ef04a0720654
Content-Type: text/plain; charset=ISO-8859-1

?? As a reality check here, the browser providers have taken ten years to
get round to doing hard fail on OCSP.

So how likely is it that browser providers are going to refuse to implement
a new and untested spec unless it mandates hard fail behavior?


Has anyone actually asked a browser provider what their opinion is? I rather
suspect not.



On Fri, Apr 8, 2011 at 7:05 PM, Eric Rescorla <[e-mail]> wrote:

> On Fri, Apr 8, 2011 at 2:22 PM, Zack Weinberg <[e-mail]>
> wrote:
> > I'd like to lay out a short list of requirements on DANE from a web
> > browser implementor's perspective.  This probably overlaps quite a bit
> > with other people's requirement lists, but I haven't seen the web use
> > case pulled together in a neat package.
> >
> > 1) Critical requirements:  If DANE does not provide these things, web
> > browsers are unlikely to bother adopting it *at all*.
> >
> > [Exclusion] DANE must allow a site administrator to indicate that
> > their server(s) will use *only* a particular finite set of keys.
> >
> > [Hard failure] Clients must be required to refuse to proceed with a
> > connection to a site if DANE indicates a security error.
>
> I think this requires some elaboration. The browser can either:
>
> (a) throw an overrideable error like the existing chrome/firefox errors for
> CN mismatch or unknown CA.
> (b) throw a non-overrideable error like what happens if it gets an
> NXDOMAIN.
>
> I haven't formed an opinion on which of these is desireable, but surely
> you're
> not saying that browser manufacturers won't adopt this without an RFC 2119
> MUST for (b). After all, if the manufacturer wants to do so, nothing is
> stopping
> them from refusing the let the user override.
>
> -Ekr
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane
>



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

--20cf307cfc68f524ef04a0720654
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

?? As a reality check here, the browser providers have taken ten years to g=
et round to doing hard fail on OCSP.<div><br></div><div>So how likely is it=
 that browser providers are going to refuse to implement a new and untested=
 spec unless it mandates hard fail behavior?</div>
<div><br></div><div><br></div><div>Has anyone actually asked a browser prov=
ider what their opinion is? I rather suspect not.</div><div><br></div><div>=
<br><br><div class=3D"gmail_quote">On Fri, Apr 8, 2011 at 7:05 PM, Eric Res=
corla <span dir=3D"ltr">&lt;<a href=3D"mailto:[e-mail]">[e-mail]</a=
>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;"><div class=3D"im">On Fri, Apr 8, 2011 at 2:=
22 PM, Zack Weinberg &lt;<a href=3D"mailto:[e-mail]">zack.w=
[e-mail]</a>&gt; wrote:<br>

&gt; I&#39;d like to lay out a short list of requirements on DANE from a we=
b<br>
&gt; browser implementor&#39;s perspective. =A0This probably overlaps quite=
 a bit<br>
&gt; with other people&#39;s requirement lists, but I haven&#39;t seen the =
web use<br>
&gt; case pulled together in a neat package.<br>
&gt;<br>
&gt; 1) Critical requirements: =A0If DANE does not provide these things, we=
b<br>
&gt; browsers are unlikely to bother adopting it *at all*.<br>
&gt;<br>
&gt; [Exclusion] DANE must allow a site administrator to indicate that<br>
&gt; their server(s) will use *only* a particular finite set of keys.<br>
&gt;<br>
&gt; [Hard failure] Clients must be required to refuse to proceed with a<br=
>
&gt; connection to a site if DANE indicates a security error.<br>
<br>
</div>I think this requires some elaboration. The browser can either:<br>
<br>
(a) throw an overrideable error like the existing chrome/firefox errors for=
<br>
CN mismatch or unknown CA.<br>
(b) throw a non-overrideable error like what happens if it gets an NXDOMAIN=
.<br>
<br>
I haven&#39;t formed an opinion on which of these is desireable, but surely=
 you&#39;re<br>
not saying that browser manufacturers won&#39;t adopt this without an RFC 2=
119<br>
MUST for (b). After all, if the manufacturer wants to do so, nothing is sto=
pping<br>
them from refusing the let the user override.<br>
<br>
-Ekr<br>
<div><div></div><div class=3D"h5">_________________________________________=
______<br>
dane mailing list<br>
<a href=3D"mailto:[e-mail]">[e-mail]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/dane</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a=
 href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--20cf307cfc68f524ef04a0720654--

From [e-mail]  Fri Apr  8 18:46:38 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 175873A6A63 for <[e-mail]>; Fri,  8 Apr 2011 18:46:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.81
X-Spam-Level: 
X-Spam-Status: No, score=-2.81 tagged_above=-999 required=5 tests=[AWL=0.167,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PgRgUOUzDmVJ for <[e-mail]>; Fri,  8 Apr 2011 18:46:22 -0700 (PDT)
Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 0C7AD3A6A62 for <[e-mail]>; Fri,  8 Apr 2011 18:46:22 -0700 (PDT)
Received: by pwi5 with SMTP id 5so1800951pwi.31 for <[e-mail]>; Fri, 08 Apr 2011 18:48:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=lK7Jeae0PUpmjbt9Dk27dlaAtBd9i2xpR1t5BwVHQiI=; b=nuVbxkNnqCqMXpSnFuCga59SumfuLw6/q4tkRTCbFF9XnFovTakmS5Mf2yd9qPzKR0 2gZQHst1oKHDWRM3yM5V5n0tYgev+09fLzQJQjEKDwJfwmwfQ2ysqsj1tFne8MsotRRm R0+1gYgoLavHAsPoymoxVysFNQdqCilJgVO4U=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=rxGR8NxwphQ/raCg0vlZBcolKbxQ6Oh8Xw28SaGpbI4SZ8Hkf93mYXkI0fhUFgvwn0 sZxFdBGum+a3IpifPoVoU2vgwhPmo+4Z8hk8/udibTeH+Xfz78LJCuvnWlixNWNcwRl7 IfzfQQdvNejwE4fRc+aBKxdQYXOVnrCAS3Eco=
MIME-Version: 1.0
Received: by 10.142.250.5 with SMTP id x5mr2526974wfh.440.1302313681036; Fri, 08 Apr 2011 18:48:01 -0700 (PDT)
Sender: [e-mail]
Received: by 10.68.49.73 with HTTP; Fri, 8 Apr 2011 18:48:00 -0700 (PDT)
In-Reply-To: <BANLkTi=5rCGVPPiBVUd0oVm9F-big4R=[e-mail]>
References: <[e-mail]> <BANLkTinD=[e-mail]> <BANLkTi=5rCGVPPiBVUd0oVm9F-big4R=[e-mail]>
Date: Fri, 8 Apr 2011 18:48:00 -0700
X-Google-Sender-Auth: do9OOF-e-ZDI7IZldTb8HEd7t7c
Message-ID: <BANLkTi=[e-mail]>
From: Zack Weinberg <[e-mail]>
To: Phillip Hallam-Baker <[e-mail]>
Content-Type: text/plain; charset=UTF-8
Cc: [e-mail]
Subject: Re: [dane] Requirements - HTTPS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 09 Apr 2011 01:46:39 -0000

On Fri, Apr 8, 2011 at 6:11 PM, Phillip Hallam-Baker <[e-mail]> wrote:
> ?? As a reality check here, the browser providers have taken ten years to
> get round to doing hard fail on OCSP.
> So how likely is it that browser providers are going to refuse to implement
> a new and untested spec unless it mandates hard fail behavior?
>
> Has anyone actually asked a browser provider what their opinion is? I rather
> suspect not.

I *am* a browser implementor, and my organization had this
conversation at some length this week (and I thought you were one of
the people dialed in!)  I refer you to
http://www.owlfolio.org/research/securing-the-future-net/ -- but to be
brief, there are major differences between DANE and OCSP that make the
case for hard-fail for DANE enormously easier to make -- provided the
standards back us up.
First, sites opt-in to DANE, whereas OCSP (or more precisely,
revocation checking) is something sites have no control over.  Second,
revocation checking ties a site's availability to the reliability of a
service they have no control over, whereas DANE is entirely under the
control of the site (assuming it's big enough to run its own DNS
servers).  And finally, DANE is new, so there is no ten-year history
of browsers *not* failing on security errors with it.

zw

From [e-mail]  Fri Apr  8 23:16:33 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 466333A6860 for <[e-mail]>; Fri,  8 Apr 2011 23:16:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level: 
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PGX4pEhES7OM for <[e-mail]>; Fri,  8 Apr 2011 23:16:30 -0700 (PDT)
Received: from mail1.eff.org (mail1.eff.org [64.147.188.4]) by core3.amsl.com (Postfix) with ESMTP id 7A83E3A6A83 for <[e-mail]>; Fri,  8 Apr 2011 23:16:30 -0700 (PDT)
Received: from xylophonic (27-32-234-34.static.tpgi.com.au [27.32.234.34]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: pde) by mail1.eff.org (Postfix) with ESMTPSA id 92AEDBDEBA; Fri,  8 Apr 2011 23:18:19 -0700 (PDT)
Date: Sat, 9 Apr 2011 16:18:12 +1000
From: Peter Eckersley <[e-mail]>
To: =?utf-8?B?T25kxZllaiBTdXLDvQ==?= <[e-mail]>
Message-ID: <20110409061812.GA2443@xylophonic>
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <[e-mail]>
Sender: [e-mail]
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Mailman-Approved-At: Fri, 08 Apr 2011 23:41:02 -0700
Cc: [e-mail]
Subject: Re: [dane] Question about SSLiverse data (Was: Re: [keyassure] Use cases document)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 09 Apr 2011 06:16:33 -0000

Hi Ondřej,

In the August 2010 dataset there were about 500,000 self-signed X.509v1
certificates, and 56,000 X.509v3 certs which are self-signed but not CAs.

SELECT count(*) 
FROM all_certs 
WHERE subject=issuer 
  AND NOT LOCATE("TRUE",`X509v3 extensions:X509v3 Basic Constraints:CA`)
  AND version != " 1 (0x0)";
+----------+
| count(*) |
+----------+
|    56195 |
+----------+

SELECT count(*) 
FROM all_certs 
WHERE subject=issuer 
  AND NOT LOCATE("Certificate Sign", `X509v3 extensions:X509v3 Key Usage`)
  AND version != " 1 (0x0)";
+----------+
| count(*) |
+----------+
|   132931 |
+----------+

SELECT count(*) FROM acerts 
WHERE subject=issuer AND version=" 1 (0x0)";
+----------+
| count(*) |
+----------+
|   494022 |
+----------+


On Fri, Apr 08, 2011 at 04:46:49PM +0200, Ondřej Surý wrote:
> Hi Peter,
> 
> there was an interesting question on the DANE WG list - which you
> might have an answer for:
> 
> > It would be interesting to know from the SSLiverse database how many
> > TLS server certs on the internet are self-signed EE certs vs.
> > CA-signed, and how many of the self-signed TLS server certs are
> > X.509v1.
> 
> Kind regards,
> Ondrej, DANE WG co-chair
> 

From: Martin Rex <[e-mail]>
Subject: Re: [dane] [keyassure] Use cases document.
To: [e-mail] (Richard L. Barnes)
Date: Fri, 8 Apr 2011 16:01:53 +0200 (MEST)
Cc: [e-mail], [e-mail]
> 
> Richard L. Barnes wrote:
> > 
> > To note again: The phrase "self-signed EE cert" does not make sense.
> > From RFC 5280:
> > "
> > Self-issued certificates are generated to support changes in policy
> > or operations.  Self-signed certificates are self-issued certificates
> > where the digital signature may be verified by the public key bound
> > into the certificate.
> > "
> > Since a self-signed cert has a cert issued under it (itself), it has
> > to be a CA cert.
> > 
> > A self-signed cert *without* the CA bits set is therefore malformed,
> > and will not pass PKIX validation.  
> 
> 
> You seem to have entirely missed the most important of PKIX
> 
>   http://tools.ietf.org/html/rfc5280
> 
>    Abstract
> 
>    This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use
>    in the Internet.
> 
> 
> PKIX rules, by their own definition, do not apply to X.509v1 self-signed
> EE certs.  And SSLv3, TLSv1.0 and TLSv1.1 are perfectly usable with X.509v1
> self-signed EE certs.
> 
>  
> 
> It would be interesting to know from the SSLiverse database how many
> TLS server certs on the internet are self-signed EE certs vs. CA-signed,
> and how many of the self-signed TLS server certs are X.509v1.
> 
> 
> -Martin


-- 
Peter Eckersley                            [e-mail]
Senior Staff Technologist         Tel  [phone] x131
Electronic Frontier Foundation    Fax  [phone]
-- 
Peter Eckersley                            [e-mail]
Senior Staff Technologist         Tel  [phone] x131
Electronic Frontier Foundation    Fax  [phone]

From [e-mail]  Sat Apr  9 09:04:19 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35E7C3A695F for <[e-mail]>; Sat,  9 Apr 2011 09:04:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.149
X-Spam-Level: 
X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599, HELO_EQ_SE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7gt3hcckxWL for <[e-mail]>; Sat,  9 Apr 2011 09:04:18 -0700 (PDT)
Received: from smtp6.webway.se (smtp2.webway.se [87.96.134.128]) by core3.amsl.com (Postfix) with ESMTP id 2261A3A6876 for <[e-mail]>; Sat,  9 Apr 2011 09:04:16 -0700 (PDT)
Received: from [192.168.40.12] (ns.webway.se [87.96.134.125]) by smtp6.webway.se (Postfix) with ESMTPA id 14DD8552C41; Sat,  9 Apr 2011 16:06:01 +0000 (UTC)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: "Olle E. Johansson" <[e-mail]>
In-Reply-To: <BANLkTi=[e-mail]>
Date: Sat, 9 Apr 2011 18:06:00 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]> <BANLkTinD=[e-mail]> <BANLkTi=5rCGVPPiBVUd0oVm9F-big4R=[e-mail]> <BANLkTi=[e-mail]>
To: Zack Weinberg <[e-mail]>
X-Mailer: Apple Mail (2.1084)
Cc: [e-mail]
Subject: Re: [dane] Requirements - HTTPS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 09 Apr 2011 16:04:19 -0000

9 apr 2011 kl. 03.48 skrev Zack Weinberg:

> On Fri, Apr 8, 2011 at 6:11 PM, Phillip Hallam-Baker =
<[e-mail]> wrote:
>> ?? As a reality check here, the browser providers have taken ten =
years to
>> get round to doing hard fail on OCSP.
>> So how likely is it that browser providers are going to refuse to =
implement
>> a new and untested spec unless it mandates hard fail behavior?
>>=20
>> Has anyone actually asked a browser provider what their opinion is? I =
rather
>> suspect not.
>=20
> I *am* a browser implementor, and my organization had this
> conversation at some length this week (and I thought you were one of
> the people dialed in!)  I refer you to
> http://www.owlfolio.org/research/securing-the-future-net/ -- but to be
> brief, there are major differences between DANE and OCSP that make the
> case for hard-fail for DANE enormously easier to make -- provided the
> standards back us up.
> First, sites opt-in to DANE, whereas OCSP (or more precisely,
> revocation checking) is something sites have no control over.  Second,
> revocation checking ties a site's availability to the reliability of a
> service they have no control over, whereas DANE is entirely under the
> control of the site (assuming it's big enough to run its own DNS
> servers).  And finally, DANE is new, so there is no ten-year history
> of browsers *not* failing on security errors with it.
>=20
I keep coming back to making the point that we're not creating a =
solution for a single protocol or application.
I don't think that how web browser will implement DANE is a blocking =
issue for this work.=20
I personally need it for other protocols that haven't got a huge =
implementation base that will be blocking progress.

/O=

From [e-mail]  Sat Apr  9 10:03:37 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E5843A6876 for <[e-mail]>; Sat,  9 Apr 2011 10:03:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.827
X-Spam-Level: 
X-Spam-Status: No, score=-2.827 tagged_above=-999 required=5 tests=[AWL=0.150,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cj+07RIulPTk for <[e-mail]>; Sat,  9 Apr 2011 10:03:36 -0700 (PDT)
Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by core3.amsl.com (Postfix) with ESMTP id A0C0B3A680A for <[e-mail]>; Sat,  9 Apr 2011 10:03:36 -0700 (PDT)
Received: by pxi20 with SMTP id 20so2516541pxi.27 for <[e-mail]>; Sat, 09 Apr 2011 10:05:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=2+uYwjsAjzylaky/MFhbc1Lo86nAbHXrO466dC4ezW4=; b=XflbNRNk5Gms+zM5H9Z4LoM+3aU722+3OuZkszFDB0bAO+wK9+LD8OaDS/bwVSt+eT UfD+bPyae/5RAYO5et2kZGStpYSgQVn0czoqFkLvNZHk+BTDXdLODxFzdgDZxhewQNEW j8pNoUHn52qNNvmbjf3IAW33wGlVTzGFYELEY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=e0rObYdvJGUkxBPYsbBKQUIoOp7xzTevzvBw5aO0AtYWJB++nXJHMB8E5DsdrZau+Y 63u5taS53i9trj4Vi6gXwjumMU0RulS7Q1J16ClyQKt/i0aJXIdmvwW8iLeHPg5kKXkk C+GqRnB5qE36YCD09DaR1Oedq739yMCCLIBpw=
MIME-Version: 1.0
Received: by 10.143.169.10 with SMTP id w10mr3032681wfo.177.1302368722755; Sat, 09 Apr 2011 10:05:22 -0700 (PDT)
Sender: [e-mail]
Received: by 10.68.51.5 with HTTP; Sat, 9 Apr 2011 10:05:22 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <BANLkTinD=[e-mail]> <BANLkTi=5rCGVPPiBVUd0oVm9F-big4R=[e-mail]> <BANLkTi=[e-mail]> <[e-mail]>
Date: Sat, 9 Apr 2011 10:05:22 -0700
X-Google-Sender-Auth: LFgpw1msgR545u8K379nfzJyNKY
Message-ID: <[e-mail]>
From: Zack Weinberg <[e-mail]>
To: "Olle E. Johansson" <[e-mail]>
Content-Type: text/plain; charset=UTF-8
Cc: [e-mail]
Subject: Re: [dane] Requirements - HTTPS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 09 Apr 2011 17:03:37 -0000

> I keep coming back to making the point that we're not creating a solution for a single protocol or application.
> I don't think that how web browser will implement DANE is a blocking issue for this work.
> I personally need it for other protocols that haven't got a huge implementation base that will be blocking progress.

How do your requirements differ from my requirements?  Please be specific.

zw

From [e-mail]  Sat Apr  9 10:14:11 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B69A3A693B for <[e-mail]>; Sat,  9 Apr 2011 10:14:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-ogrhHuXs-i for <[e-mail]>; Sat,  9 Apr 2011 10:14:09 -0700 (PDT)
Received: from ppa02.Princeton.EDU (ppa02.Princeton.EDU [128.112.128.216]) by core3.amsl.com (Postfix) with ESMTP id 9966B3A6876 for <[e-mail]>; Sat,  9 Apr 2011 10:14:09 -0700 (PDT)
Received: from csgsmtp201l.Princeton.EDU (csgsmtp201l.Princeton.EDU [128.112.134.60]) by ppa02.Princeton.EDU (8.14.3/8.14.3) with ESMTP id p39HFtQf031146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Sat, 9 Apr 2011 13:15:55 -0400
Received: from new-host-4.home (pool-173-71-106-53.cmdnnj.fios.verizon.net [173.71.106.53]) (authenticated bits=0) by csgsmtp201l.Princeton.EDU (8.13.8/8.12.9) with ESMTP id p39HFsSS001370 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for <[e-mail]>; Sat, 9 Apr 2011 13:15:55 -0400
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1082)
From: Steve Schultze <[e-mail]>
In-Reply-To: <BANLkTik-dMio6So4VW=[e-mail]>
Date: Sat, 9 Apr 2011 13:15:54 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <BANLkTik-dMio6So4VW=[e-mail]>
To: [e-mail]
X-Mailer: Apple Mail (2.1082)
X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6310 signatures=657355
X-Proofpoint-Spam-Details: rule=quarantine_outbound_notspam policy=quarantine score=0 spamscore=0 ipscore=0 suspectscore=4 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1012030000 definitions=main-1104090066
Subject: Re: [dane] elephant use case,
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 09 Apr 2011 17:14:11 -0000

On Apr 8, 2011, at 5:57 PM, Phillip Hallam-Baker wrote:
>> On Fri, Apr 8, 2011 at 4:42 PM, Martin Rex <[e-mail]> wrote:
>> Phillip Hallam-Baker wrote:
>> >
>> > Could people actually take some time to learn about what the EFF =
data means
>> > before engaging in this hyperbole?
>> >
>> > There are not and have never been 600 RA certs. The EFF people do =
not
>> > understand what the data means or why the certs are configured the =
way they
>> > are. In fact the pressure that we have had from Mozilla and other =
sources is
>> > to increase the number of intermediate certs.
>>=20
>> RA "registration authorities"
>>   http://en.wikipedia.org/wiki/Registration_authority
>>=20
>> do NOT have certificates themselves.  The organizations that have
>> the certificate with cert signing capabilities are called CAs.
>>=20
>> What EFF likely did was that they counted the distinct CA(!!) =
certificates
>> that are valid under the trusted roots certs in Browsers as indicated
>> under "organization name" in those CA certificates.
>=20
> We don't need to speculate as to what EFF did, they describe what they =
did which was to assert that every intermediate cert in a chain with a =
different subject name was an independent CA.
>=20
> That was and entirely mistaken as a methodology and for them to =
continue to make these claims is ignorant and dishonest.

I don't understand why this OT conversation has to be perpetuated on =
this list, but EFF clearly stated:
"651 organizations, but ownerships & jurisdictions overlap"

Their work was the most comprehensive and helpful to date, and they =
released all of the raw data.

Continuing to engage in trash talk here is pointless and distracting.  =
If you want to do some analysis of the data and give your own numbers, =
do so and post it on the Comodo blog or somewhere that it isn't =
off-topic.  You might even consider approving some of the comments on =
that post so that people can have a reasonable back-and-forth.=

From [e-mail]  Sat Apr  9 12:58:35 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6822E3A699C for <[e-mail]>; Sat,  9 Apr 2011 12:58:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.203
X-Spam-Level: 
X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJHyEiiBBxZz for <[e-mail]>; Sat,  9 Apr 2011 12:58:34 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 2B8563A6972 for <[e-mail]>; Sat,  9 Apr 2011 12:58:34 -0700 (PDT)
Received: by iye19 with SMTP id 19so5466186iye.31 for <[e-mail]>; Sat, 09 Apr 2011 13:00:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=O0pWJ37itAULZmifDHcv3S95CSclibbIRPXE2Qn8IW8=; b=LjFrXOa7VdAuVBhCkQ/0vkRcPFvedySc0V+fdpxqr74UGavOR/e14oRTYuGzH2824M eWUBamtMR54GXZhnnk/jKAEDK1lF7lk4sCW9yk42COgiw9EmLBNgPBA4RUQgLN3INQOP zwalZH4QObfv/XuTt23q9rtqfNYtLRxGdhEXM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=XOp7ejUvcV3aEyKwYkXWQASo5TNKF2Ao5NcyU9y/X3lQJU5iueIuthaa0b7jgvtS4t aLcJPcDVp+9Mj52YLw74kj3hTy7g4D9c1Z92EDS/lzTWAqCrD4ql8hUfVSjXqndIIC0P izMoKQ0G+kKOyjDFQdj06Hpq3a2CD/CrPIopA=
Received: by 10.231.3.134 with SMTP id 6mr3628443ibn.98.1302379219924; Sat, 09 Apr 2011 13:00:19 -0700 (PDT)
Received: from [10.36.74.224] (mobile-166-137-137-160.mycingular.net [166.137.137.160]) by mx.google.com with ESMTPS id i26sm1760633iby.24.2011.04.09.13.00.18 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 09 Apr 2011 13:00:18 -0700 (PDT)
References: <[e-mail]> <[e-mail]> <BANLkTik-dMio6So4VW=[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0 (iPhone Mail 8C148)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=us-ascii
Message-Id: <[e-mail]>
X-Mailer: iPhone Mail (8C148)
From: Phillip Hallam-Baker <[e-mail]>
Date: Sat, 9 Apr 2011 16:00:09 -0400
To: Steve Schultze <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [dane] elephant use case,
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 09 Apr 2011 19:58:35 -0000

I make no apologies for correcting incorrect claims made by others to this l=
ist.=20

I did not raise the claim here. And I get rather fed up of people who claim t=
hat their problem is that something is off topic when their real problem is t=
hat they don't like their facts being challenged


As far as the eff presentation goes, they fail to make the distinction you p=
oint out in their web page sumarising their results or when they draw conclu=
sions=20

Thus I do not feel that I am misrepresenting their claims.=20


Sent from my iPhone

On 9 Apr 2011, at 13:15, Steve Schultze <[e-mail]> wrote:

> On Apr 8, 2011, at 5:57 PM, Phillip Hallam-Baker wrote:
>>> On Fri, Apr 8, 2011 at 4:42 PM, Martin Rex <[e-mail]> wrote:
>>> Phillip Hallam-Baker wrote:
>>>>=20
>>>> Could people actually take some time to learn about what the EFF data m=
eans
>>>> before engaging in this hyperbole?
>>>>=20
>>>> There are not and have never been 600 RA certs. The EFF people do not
>>>> understand what the data means or why the certs are configured the way t=
hey
>>>> are. In fact the pressure that we have had from Mozilla and other sourc=
es is
>>>> to increase the number of intermediate certs.
>>>=20
>>> RA "registration authorities"
>>>  http://en.wikipedia.org/wiki/Registration_authority
>>>=20
>>> do NOT have certificates themselves.  The organizations that have
>>> the certificate with cert signing capabilities are called CAs.
>>>=20
>>> What EFF likely did was that they counted the distinct CA(!!) certificat=
es
>>> that are valid under the trusted roots certs in Browsers as indicated
>>> under "organization name" in those CA certificates.
>>=20
>> We don't need to speculate as to what EFF did, they describe what they di=
d which was to assert that every intermediate cert in a chain with a differe=
nt subject name was an independent CA.
>>=20
>> That was and entirely mistaken as a methodology and for them to continue t=
o make these claims is ignorant and dishonest.
>=20
> I don't understand why this OT conversation has to be perpetuated on this l=
ist, but EFF clearly stated:
> "651 organizations, but ownerships & jurisdictions overlap"
>=20
> Their work was the most comprehensive and helpful to date, and they releas=
ed all of the raw data.
>=20
> Continuing to engage in trash talk here is pointless and distracting.  If y=
ou want to do some analysis of the data and give your own numbers, do so and=
 post it on the Comodo blog or somewhere that it isn't off-topic.  You might=
 even consider approving some of the comments on that post so that people ca=
n have a reasonable back-and-forth.
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane

From [e-mail]  Sat Apr  9 13:19:42 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEDA83A69A3 for <[e-mail]>; Sat,  9 Apr 2011 13:19:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.255
X-Spam-Level: 
X-Spam-Status: No, score=-102.255 tagged_above=-999 required=5 tests=[AWL=0.344, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghGi0ItoZM89 for <[e-mail]>; Sat,  9 Apr 2011 13:19:42 -0700 (PDT)
Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by core3.amsl.com (Postfix) with ESMTP id ED16B3A699C for <[e-mail]>; Sat,  9 Apr 2011 13:19:41 -0700 (PDT)
Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA11.westchester.pa.mail.comcast.net with comcast id VYLX1g0061HzFnQ5BYMUn6; Sat, 09 Apr 2011 20:21:28 +0000
Received: from odin.ulthar.us ([68.33.77.0]) by omta14.westchester.pa.mail.comcast.net with comcast id VYMU1g00900PQ6U3aYMU0m; Sat, 09 Apr 2011 20:21:28 +0000
Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.4/8.14.3) with ESMTP id p39KLQII024627 for <[e-mail]>; Sat, 9 Apr 2011 16:21:26 -0400
Received: (from draco@localhost) by odin.ulthar.us (8.14.4/8.14.4/Submit) id p39KLQmu024625 for [e-mail]; Sat, 9 Apr 2011 16:21:26 -0400
Date: Sat, 9 Apr 2011 16:21:26 -0400
From: Scott Schmit <[e-mail]>
To: [e-mail]
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
References: <[e-mail]> <BANLkTinD=[e-mail]> <BANLkTi=5rCGVPPiBVUd0oVm9F-big4R=[e-mail]> <BANLkTi=[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [dane] Requirements - HTTPS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 09 Apr 2011 20:19:43 -0000

On Sat, Apr 09, 2011 at 06:06:00PM +0200, Olle E. Johansson wrote dane:
> I keep coming back to making the point that we're not creating a
> solution for a single protocol or application.  I don't think that how
> web browser will implement DANE is a blocking issue for this work.  I
> personally need it for other protocols that haven't got a huge
> implementation base that will be blocking progress.

For what it's worth, when I looked over Zack's requirement set, I tried
to think about how things would be different for non-HTTPS cases, and I
couldn't come up with any different or new requirements. Honestly, I'm
not sure why the subject line talks about HTTPS (other than as an
admission of perspective), as it doesn't seem relevant.

Do you have any new/different requirements?

-- 
Scott Schmit

From [e-mail]  Sat Apr  9 14:10:17 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 315EA3A696D for <[e-mail]>; Sat,  9 Apr 2011 14:10:17 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c27LmOJivdBy for <[e-mail]>; Sat,  9 Apr 2011 14:10:15 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 8397F3A681B for <[e-mail]>; Sat,  9 Apr 2011 14:10:15 -0700 (PDT)
Received: by iye19 with SMTP id 19so5502120iye.31 for <[e-mail]>; Sat, 09 Apr 2011 14:12:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:date:x-google-sender-auth :message-id:subject:from:to:content-type; bh=l6e7gwq5GbGF7aFfR2Hb9fIWUigl6vujArioKayvMe4=; b=iyarUITTGTKG7p7zVwzxWFk6ol/ZqnKV/fY8UQss7IpyjJD1titR/dKvPSxIYYKn/B PxVcIwxCUIXpKicKbKWIpMqiF/yTmYckdb94Zk6+wUgalLAZysv8TeGEYWSmxoykcd5Q aZJKlTCRvjy+65smY98G33oBO3T6AWkeWA5eU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=OYA9+jvkKEZDPlpzsdwVQaJmYLHFXl3AC5x1sVxex1jh1ydPibxPj7qIYehHbt50Po AATectD7ZuSPPruG/snM22oF76Rg52hgp6zrsxAWL1BaNf4Qdbkoi1/L4mkr/e7EqbXx M7gZFqnnsoKJNiEFYybNXOTOkriYe0s+zcTd4=
MIME-Version: 1.0
Received: by 10.42.135.193 with SMTP id q1mr3285987ict.41.1302383521500; Sat, 09 Apr 2011 14:12:01 -0700 (PDT)
Sender: [e-mail]
Received: by 10.42.228.66 with HTTP; Sat, 9 Apr 2011 14:12:01 -0700 (PDT)
Date: Sat, 9 Apr 2011 17:12:01 -0400
X-Google-Sender-Auth: _8vp4jSttdmC3a5i7XDC7VGqATY
Message-ID: <BANLkTin-E=[e-mail]>
From: Adam Langley <[e-mail]>
To: [e-mail]
Content-Type: text/plain; charset=UTF-8
Subject: [dane] A browser's myopic view
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 09 Apr 2011 21:10:17 -0000

(I hope that the subject makes it esp clear that I feel that browsers
are only part of the TLS ecosystem and a troubled part at that,
burdened, as they are, with a huge legacy base and an obsession with
speed. None the less, a couple of people have asked me to comment on
this list. It's nothing that I haven't said before, but the mailing
list has grown and even changed names in the mean time.)

The proximal trigger for this was PHB:
> So how likely is it that browser providers are going to refuse to implement a new and untested spec unless it mandates hard fail behavior?

So I'll start with exclusion:

The problem with a hard failure on exclusion is that it means that we
*have* to get the DNS information before sending application data on a
TLS connection, or we have to have it cached.

In the event that we don't have it cached, getting the information
from DNS is a problem. I ran an experiment in Chrome doing lookups for
an odd DNS RRTYPE (13172) concurrently with the A lookup for HTTPS
URLs. 2.5% of the time, the result came in over 100ms after we had
completed the A lookup, TCP connection, TLS handshake and certificate
verification! Somewhere between 0.5-1% of the time, we didn't get an
answer within 10s (the limit of the histogram), which suggests that
networks were filtering these requests.

Needless to say, slowing things down to such an extent, and breaking
that many people is a hard sell.

Also, unless the information is DNSSEC authenticated, an attacker can
spoof and DoS a site, and DNSSEC resolvers on the client are rare.
(Or, rather, they would trigger hard failures for random sites until
the user flushed their local browser state. Then the attacker can MITM
the connection that they really wanted.)

But exclusion could be very valuable! However, it seems that HSTS
would be a better channel for this information. We only parse HSTS
headers over HTTPS (so no DoS) and it don't have any of the above
problems. Also, Firefox and we (Chrome) have both shown that we're
happy to make HSTS failures hard errors.

DNS solutions have the advantage of protecting the first connection,
it's true. We have the preloaded list[1] to address that to some
extent but it might have to be something that we trade off. (None of
this is an official statement of what we will or wont do in future
Chrome versions. I'm still writing the code for exclusion at the
moment.)

Switching tacks for a second to the specifics of DANE:

For exclusion we expect that some sites will wish to `pin' to a CA
rather than to their leaf certificate. In this case, you have to hash
public keys (or, rather, SubjectPublicKeyInfos), not certificates.
Certificate chains are built from a pool and the intermediate
certificates that a site presents are simply inserted into the pool.
Intermediate certificates exist in different versions (same public
key, but different expiry times, brands etc) and the constructed chain
might find a path through different versions of the intermediates.
Only the public keys have to match.

Even if you're pinning to a leaf certificate, hashing the public key
means that you can renew the certificate or add extra SANs without
performing an exclusion rollover.


Next, Authentication (or `inclusion'):

The DNS has several nice properties as a PKI: scoped delegation and
short lived signatures rather than problematic revocation systems. I
can see why some sites would like to have a DNSSEC signed HTTPS
connection. They're not going to be major sites though. It will be
hard to justify breaking even a tiny number of users when CA
certificates can be had for free[2].

The issue here is that the DNS protocol isn't a great transport for
DNSSEC information! As noted above, it looks like some networks filter
out odd RRTYPES. Also, DNSSEC resolvers on the client are rare and I
don't really want to drop one into a browser (although Dan Kaminsky is
doing good work here). I'd be much happier if the server did the work
and sent a DNSSEC chain in its certificate. DNSSEC information doesn't
have to be carried via the DNS protocol and carrying it in the
certificate chain works nicely. The code is already in Chrome (Dan
demoed it at Blackhat last year), although it's currently expecting
something like an early draft of CAA I think and it's off by default.


[1] http://dev.chromium.org/sts
[2] https://github.com/ioerror/duraconf/blob/master/startssl/README.markdown


Cheers

AGL

-- 
Adam Langley [e-mail] http://www.imperialviolet.org

From [e-mail]  Sat Apr  9 17:30:40 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACACF3A6918 for <[e-mail]>; Sat,  9 Apr 2011 17:30:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.594
X-Spam-Level: 
X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=0.005,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syEYMHAiGvFL for <[e-mail]>; Sat,  9 Apr 2011 17:30:40 -0700 (PDT)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id EAF303A6819 for <[e-mail]>; Sat,  9 Apr 2011 17:30:39 -0700 (PDT)
Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 2986EC5ED; Sat,  9 Apr 2011 20:32:23 -0400 (EDT)
Date: Sat, 9 Apr 2011 20:32:22 -0400 (EDT)
From: Paul Wouters <[e-mail]>
To: Adam Langley <[e-mail]>
In-Reply-To: <BANLkTin-E=[e-mail]>
Message-ID: <[e-mail]>
References: <BANLkTin-E=[e-mail]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: [e-mail]
Subject: Re: [dane] A browser's myopic view
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 10 Apr 2011 00:30:40 -0000

On Sat, 9 Apr 2011, Adam Langley wrote:

> In the event that we don't have it cached, getting the information
> from DNS is a problem. I ran an experiment in Chrome doing lookups for
> an odd DNS RRTYPE (13172) concurrently with the A lookup for HTTPS
> URLs. 2.5% of the time, the result came in over 100ms after we had
> completed the A lookup, TCP connection, TLS handshake and certificate
> verification! Somewhere between 0.5-1% of the time, we didn't get an
> answer within 10s (the limit of the histogram), which suggests that
> networks were filtering these requests.
>
> Needless to say, slowing things down to such an extent, and breaking
> that many people is a hard sell.

Note that if you first query for HASTLS, and it is not there, then you would
not need to wait for the TLSA record query.

The HASTLS record is very small and does not have the TCP 53 misconfiguration
problem.

Paul

From [e-mail]  Sat Apr  9 18:11:25 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27D763A6988 for <[e-mail]>; Sat,  9 Apr 2011 18:11:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.981
X-Spam-Level: 
X-Spam-Status: No, score=-2.981 tagged_above=-999 required=5 tests=[AWL=-0.383, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ThYkJkqt16nb for <[e-mail]>; Sat,  9 Apr 2011 18:11:23 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 6BE5D3A694D for <[e-mail]>; Sat,  9 Apr 2011 18:11:23 -0700 (PDT)
Received: by vxg33 with SMTP id 33so4266631vxg.31 for <[e-mail]>; Sat, 09 Apr 2011 18:13:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=myXqE5RAWiD6HCqD6P/MWa74Ic3gboYdDp6W9jwj9Bk=; b=Lc3UH426b3xBbl9jOuYQ9wXka0EeQwynxUlj9UP+u5a84648Z0Z4fNnXhRpMK7clOV erwaqSao1wNASTWuwzAR5mpQfz6PW0B9+g9t6KOS5NaxpowaqTU0xILdBlXwdH+7y9ou STa7Ij8I495VIfAf2FDlCAcnAdHkGNqFRLUZ4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Bww0815EcLMGEL5Oi3Zgp3eioYG/4+Xhf9sGXSxGsdAFUne+8s+uOsF4Y1D+1crYmj QT6RlwLrzbH6+oWZo4spvNK4dr7stDtNLT/anB0yAFLoqXJjouhkxsvzmz1GiCJstxRW aDiTKRwlWxEAIEtLfS9ZH5NsEchPVgFKICDXo=
MIME-Version: 1.0
Received: by 10.52.18.11 with SMTP id s11mr398997vdd.269.1302397989580; Sat, 09 Apr 2011 18:13:09 -0700 (PDT)
Received: by 10.52.166.230 with HTTP; Sat, 9 Apr 2011 18:13:09 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <BANLkTin-E=[e-mail]> <[e-mail]>
Date: Sat, 9 Apr 2011 21:13:09 -0400
Message-ID: <BANLkTimQ4ApwjwyxFgnsf1gM1Kyh=[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: Paul Wouters <[e-mail]>
Content-Type: multipart/alternative; boundary=20cf3054a11386716904a086293a
Cc: Adam Langley <[e-mail]>, [e-mail]
Subject: Re: [dane] A browser's myopic view
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 10 Apr 2011 01:11:25 -0000

--20cf3054a11386716904a086293a
Content-Type: text/plain; charset=ISO-8859-1

As currently specified HASTLS has the following issues:

* It uses prefix records but does not have a strategy to avoid the
limitations of using prefixes with wildcards and/or aliases.

* The question of interoperation with use of SRV and URI records is not
addressed.

* It is limited to TLS and does not allow for other security properties to
be described in the same transaction.

I have a very similar approach that allows these limitations to be avoided.
It is relevant to DANE because it is a framework that allows a client to
obtain all the relevant information for establishing a connection through a
single mechanism rather than having one record per property type.

Basically the discovery strategy needs to look for an unprefixed record
first. At the end of the first discovery phase the client has a canonical
name and can apply prefixes to it without problems.


We could combine our proposals. It would serve the community better if we
did.


On Sat, Apr 9, 2011 at 8:32 PM, Paul Wouters <[e-mail]> wrote:

> On Sat, 9 Apr 2011, Adam Langley wrote:
>
>  In the event that we don't have it cached, getting the information
>> from DNS is a problem. I ran an experiment in Chrome doing lookups for
>> an odd DNS RRTYPE (13172) concurrently with the A lookup for HTTPS
>> URLs. 2.5% of the time, the result came in over 100ms after we had
>> completed the A lookup, TCP connection, TLS handshake and certificate
>> verification! Somewhere between 0.5-1% of the time, we didn't get an
>> answer within 10s (the limit of the histogram), which suggests that
>> networks were filtering these requests.
>>
>> Needless to say, slowing things down to such an extent, and breaking
>> that many people is a hard sell.
>>
>
> Note that if you first query for HASTLS, and it is not there, then you
> would
> not need to wait for the TLSA record query.
>
> The HASTLS record is very small and does not have the TCP 53
> misconfiguration
> problem.
>
> Paul
>
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane
>



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

--20cf3054a11386716904a086293a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

As currently specified HASTLS has the following issues:<div><br></div><div>=
* It uses prefix records but does not have a strategy to avoid the limitati=
ons of using prefixes with wildcards and/or aliases.</div><div><br></div>
<div>* The question of interoperation with use of SRV and URI records is no=
t addressed.</div><div><br></div><div>* It is limited to TLS and does not a=
llow for other security properties to be described in the same transaction.=
</div>
<div><br></div><div>I have a very similar approach that allows these limita=
tions to be avoided. It is relevant to DANE because it is a framework that =
allows a client to obtain all the relevant information for establishing a c=
onnection through a single mechanism rather than having one record per prop=
erty type.</div>
<div><br></div><div>Basically the discovery strategy needs to look for an u=
nprefixed record first. At the end of the first discovery phase the client =
has a canonical name and can apply prefixes to it without problems.</div>
<div><br></div><div><br></div><div>We could combine our proposals. It would=
 serve the community better if we did.</div><div><br><br><div class=3D"gmai=
l_quote">On Sat, Apr 9, 2011 at 8:32 PM, Paul Wouters <span dir=3D"ltr">&lt=
;<a href=3D"mailto:[e-mail]">[e-mail]</a>&gt;</span> wr=
ote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;"><div class=3D"im">On Sat, 9 Apr 2011, Adam =
Langley wrote:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
In the event that we don&#39;t have it cached, getting the information<br>
from DNS is a problem. I ran an experiment in Chrome doing lookups for<br>
an odd DNS RRTYPE (13172) concurrently with the A lookup for HTTPS<br>
URLs. 2.5% of the time, the result came in over 100ms after we had<br>
completed the A lookup, TCP connection, TLS handshake and certificate<br>
verification! Somewhere between 0.5-1% of the time, we didn&#39;t get an<br=
>
answer within 10s (the limit of the histogram), which suggests that<br>
networks were filtering these requests.<br>
<br>
Needless to say, slowing things down to such an extent, and breaking<br>
that many people is a hard sell.<br>
</blockquote>
<br></div>
Note that if you first query for HASTLS, and it is not there, then you woul=
d<br>
not need to wait for the TLSA record query.<br>
<br>
The HASTLS record is very small and does not have the TCP 53 misconfigurati=
on<br>
problem.<br><font color=3D"#888888">
<br>
Paul</font><div><div></div><div class=3D"h5"><br>
_______________________________________________<br>
dane mailing list<br>
<a href=3D"mailto:[e-mail]" target=3D"_blank">[e-mail]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/dane</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a=
 href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--20cf3054a11386716904a086293a--

From [e-mail]  Sat Apr  9 18:42:23 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3B493A694D for <[e-mail]>; Sat,  9 Apr 2011 18:42:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.479
X-Spam-Level: 
X-Spam-Status: No, score=-3.479 tagged_above=-999 required=5 tests=[AWL=0.119,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Wy0CS8KwSFG for <[e-mail]>; Sat,  9 Apr 2011 18:42:20 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id EB88C3A6905 for <[e-mail]>; Sat,  9 Apr 2011 18:42:18 -0700 (PDT)
Received: by vws12 with SMTP id 12so4308341vws.31 for <[e-mail]>; Sat, 09 Apr 2011 18:44:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=OcJ2o8DwI1Ukump34uTK8sSDpuhCfEBmbI4iC+q0LVY=; b=jpYMOaDQWGB4svAu/wfAz/GbYBniZJiM8dY4l+1qex9rNItzvF0LP7+SQ6PhQ4ZaiY IaPmIlWJujj8UV94oQeNWzpB4fnxsrXuDP+mvjpUbB8spsepcFQgQ6D+x0IpcKci3aG0 4GlUpfvlv/09eEB/QMvTU+0oqvY61bTCE2qmE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Byfd/wdCi0DVV2jNsgO2Jx5DckO0LdTwIilHXBuqriFmBYK7nLqDXH6n4FT051thob hVpOijLb4imbn8Z8DSwZlzs0v7zSIQHinT3qTSkAxLk0L28HPexhSHAgd/sIZ+Qn/PqO y6vFMzxBO7IN/rGb4QsCEzUV/husE05svLpok=
MIME-Version: 1.0
Received: by 10.52.18.11 with SMTP id s11mr420054vdd.269.1302399844866; Sat, 09 Apr 2011 18:44:04 -0700 (PDT)
Received: by 10.52.166.230 with HTTP; Sat, 9 Apr 2011 18:44:04 -0700 (PDT)
In-Reply-To: <BANLkTin-E=[e-mail]>
References: <BANLkTin-E=[e-mail]>
Date: Sat, 9 Apr 2011 21:44:04 -0400
Message-ID: <[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: Adam Langley <[e-mail]>
Content-Type: multipart/alternative; boundary=20cf3054a1131bdae804a086985b
Cc: [e-mail]
Subject: Re: [dane] A browser's myopic view
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 10 Apr 2011 01:42:24 -0000

--20cf3054a1131bdae804a086985b
Content-Type: text/plain; charset=ISO-8859-1

I agree that performance is an issue, quite possible a threshold issue for
deployment. However I don't think we can necessarily hope to meet your
performance goals in every circumstance using the work that is in scope for
DANE on its own.

The deployed DNS is a bit of a mess performance wise - as your figures show.

But we don't necessarily have to limit ourselves to the deployed DNS when
considering performance. If browsers on 2.5% of net connections end up going
slower, well maybe we end up having to propose some sort of work around
strategy to get them plugged into a DNS that offers better performance.

I don't want to discuss the details of that type of proposal here. But it is
something we should bear in mind when negotiating with the browser
providers. And in particular when we are looking to give you the facts that
allow you to go and make the case for these proposals inside your
organization.



On Sat, Apr 9, 2011 at 5:12 PM, Adam Langley <[e-mail]> wrote:

> (I hope that the subject makes it esp clear that I feel that browsers
> are only part of the TLS ecosystem and a troubled part at that,
> burdened, as they are, with a huge legacy base and an obsession with
> speed. None the less, a couple of people have asked me to comment on
> this list. It's nothing that I haven't said before, but the mailing
> list has grown and even changed names in the mean time.)
>
> The proximal trigger for this was PHB:
> > So how likely is it that browser providers are going to refuse to
> implement a new and untested spec unless it mandates hard fail behavior?
>
> So I'll start with exclusion:
>
> The problem with a hard failure on exclusion is that it means that we
> *have* to get the DNS information before sending application data on a
> TLS connection, or we have to have it cached.
>
> In the event that we don't have it cached, getting the information
> from DNS is a problem. I ran an experiment in Chrome doing lookups for
> an odd DNS RRTYPE (13172) concurrently with the A lookup for HTTPS
> URLs. 2.5% of the time, the result came in over 100ms after we had
> completed the A lookup, TCP connection, TLS handshake and certificate
> verification! Somewhere between 0.5-1% of the time, we didn't get an
> answer within 10s (the limit of the histogram), which suggests that
> networks were filtering these requests.
>
> Needless to say, slowing things down to such an extent, and breaking
> that many people is a hard sell.
>
> Also, unless the information is DNSSEC authenticated, an attacker can
> spoof and DoS a site, and DNSSEC resolvers on the client are rare.
> (Or, rather, they would trigger hard failures for random sites until
> the user flushed their local browser state. Then the attacker can MITM
> the connection that they really wanted.)
>
> But exclusion could be very valuable! However, it seems that HSTS
> would be a better channel for this information. We only parse HSTS
> headers over HTTPS (so no DoS) and it don't have any of the above
> problems. Also, Firefox and we (Chrome) have both shown that we're
> happy to make HSTS failures hard errors.
>
> DNS solutions have the advantage of protecting the first connection,
> it's true. We have the preloaded list[1] to address that to some
> extent but it might have to be something that we trade off. (None of
> this is an official statement of what we will or wont do in future
> Chrome versions. I'm still writing the code for exclusion at the
> moment.)
>
> Switching tacks for a second to the specifics of DANE:
>
> For exclusion we expect that some sites will wish to `pin' to a CA
> rather than to their leaf certificate. In this case, you have to hash
> public keys (or, rather, SubjectPublicKeyInfos), not certificates.
> Certificate chains are built from a pool and the intermediate
> certificates that a site presents are simply inserted into the pool.
> Intermediate certificates exist in different versions (same public
> key, but different expiry times, brands etc) and the constructed chain
> might find a path through different versions of the intermediates.
> Only the public keys have to match.
>
> Even if you're pinning to a leaf certificate, hashing the public key
> means that you can renew the certificate or add extra SANs without
> performing an exclusion rollover.
>
>
> Next, Authentication (or `inclusion'):
>
> The DNS has several nice properties as a PKI: scoped delegation and
> short lived signatures rather than problematic revocation systems. I
> can see why some sites would like to have a DNSSEC signed HTTPS
> connection. They're not going to be major sites though. It will be
> hard to justify breaking even a tiny number of users when CA
> certificates can be had for free[2].
>
> The issue here is that the DNS protocol isn't a great transport for
> DNSSEC information! As noted above, it looks like some networks filter
> out odd RRTYPES. Also, DNSSEC resolvers on the client are rare and I
> don't really want to drop one into a browser (although Dan Kaminsky is
> doing good work here). I'd be much happier if the server did the work
> and sent a DNSSEC chain in its certificate. DNSSEC information doesn't
> have to be carried via the DNS protocol and carrying it in the
> certificate chain works nicely. The code is already in Chrome (Dan
> demoed it at Blackhat last year), although it's currently expecting
> something like an early draft of CAA I think and it's off by default.
>
>
> [1] http://dev.chromium.org/sts
> [2]
> https://github.com/ioerror/duraconf/blob/master/startssl/README.markdown
>
>
> Cheers
>
> AGL
>
> --
> Adam Langley [e-mail] http://www.imperialviolet.org
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane
>



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

--20cf3054a1131bdae804a086985b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I agree that performance is an issue, quite possible a threshold issue for =
deployment. However I don&#39;t think we can necessarily hope to meet your =
performance goals in every circumstance using the work that is in scope for=
 DANE on its own.<div>
<br></div><div>The deployed DNS is a bit of a mess performance wise - as yo=
ur figures show.</div><div><br></div><div>But we don&#39;t necessarily have=
 to limit ourselves to the deployed DNS when considering performance. If br=
owsers on 2.5% of net connections end up going slower, well maybe we end up=
 having to propose some sort of work around strategy to get them plugged in=
to a DNS that offers better performance.</div>
<div><br></div><div>I don&#39;t want to discuss the details of that type of=
 proposal here. But it is something we should bear in mind when negotiating=
 with the browser providers. And in particular when we are looking to give =
you the facts that allow you to go and make the case for these proposals in=
side your organization.</div>
<div><br></div><div><br><br><div class=3D"gmail_quote">On Sat, Apr 9, 2011 =
at 5:12 PM, Adam Langley <span dir=3D"ltr">&lt;<a href=3D"mailto:agl@imperi=
alviolet.org">[e-mail]</a>&gt;</span> wrote:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex;">
(I hope that the subject makes it esp clear that I feel that browsers<br>
are only part of the TLS ecosystem and a troubled part at that,<br>
burdened, as they are, with a huge legacy base and an obsession with<br>
speed. None the less, a couple of people have asked me to comment on<br>
this list. It&#39;s nothing that I haven&#39;t said before, but the mailing=
<br>
list has grown and even changed names in the mean time.)<br>
<br>
The proximal trigger for this was PHB:<br>
&gt; So how likely is it that browser providers are going to refuse to impl=
ement a new and untested spec unless it mandates hard fail behavior?<br>
<br>
So I&#39;ll start with exclusion:<br>
<br>
The problem with a hard failure on exclusion is that it means that we<br>
*have* to get the DNS information before sending application data on a<br>
TLS connection, or we have to have it cached.<br>
<br>
In the event that we don&#39;t have it cached, getting the information<br>
from DNS is a problem. I ran an experiment in Chrome doing lookups for<br>
an odd DNS RRTYPE (13172) concurrently with the A lookup for HTTPS<br>
URLs. 2.5% of the time, the result came in over 100ms after we had<br>
completed the A lookup, TCP connection, TLS handshake and certificate<br>
verification! Somewhere between 0.5-1% of the time, we didn&#39;t get an<br=
>
answer within 10s (the limit of the histogram), which suggests that<br>
networks were filtering these requests.<br>
<br>
Needless to say, slowing things down to such an extent, and breaking<br>
that many people is a hard sell.<br>
<br>
Also, unless the information is DNSSEC authenticated, an attacker can<br>
spoof and DoS a site, and DNSSEC resolvers on the client are rare.<br>
(Or, rather, they would trigger hard failures for random sites until<br>
the user flushed their local browser state. Then the attacker can MITM<br>
the connection that they really wanted.)<br>
<br>
But exclusion could be very valuable! However, it seems that HSTS<br>
would be a better channel for this information. We only parse HSTS<br>
headers over HTTPS (so no DoS) and it don&#39;t have any of the above<br>
problems. Also, Firefox and we (Chrome) have both shown that we&#39;re<br>
happy to make HSTS failures hard errors.<br>
<br>
DNS solutions have the advantage of protecting the first connection,<br>
it&#39;s true. We have the preloaded list[1] to address that to some<br>
extent but it might have to be something that we trade off. (None of<br>
this is an official statement of what we will or wont do in future<br>
Chrome versions. I&#39;m still writing the code for exclusion at the<br>
moment.)<br>
<br>
Switching tacks for a second to the specifics of DANE:<br>
<br>
For exclusion we expect that some sites will wish to `pin&#39; to a CA<br>
rather than to their leaf certificate. In this case, you have to hash<br>
public keys (or, rather, SubjectPublicKeyInfos), not certificates.<br>
Certificate chains are built from a pool and the intermediate<br>
certificates that a site presents are simply inserted into the pool.<br>
Intermediate certificates exist in different versions (same public<br>
key, but different expiry times, brands etc) and the constructed chain<br>
might find a path through different versions of the intermediates.<br>
Only the public keys have to match.<br>
<br>
Even if you&#39;re pinning to a leaf certificate, hashing the public key<br=
>
means that you can renew the certificate or add extra SANs without<br>
performing an exclusion rollover.<br>
<br>
<br>
Next, Authentication (or `inclusion&#39;):<br>
<br>
The DNS has several nice properties as a PKI: scoped delegation and<br>
short lived signatures rather than problematic revocation systems. I<br>
can see why some sites would like to have a DNSSEC signed HTTPS<br>
connection. They&#39;re not going to be major sites though. It will be<br>
hard to justify breaking even a tiny number of users when CA<br>
certificates can be had for free[2].<br>
<br>
The issue here is that the DNS protocol isn&#39;t a great transport for<br>
DNSSEC information! As noted above, it looks like some networks filter<br>
out odd RRTYPES. Also, DNSSEC resolvers on the client are rare and I<br>
don&#39;t really want to drop one into a browser (although Dan Kaminsky is<=
br>
doing good work here). I&#39;d be much happier if the server did the work<b=
r>
and sent a DNSSEC chain in its certificate. DNSSEC information doesn&#39;t<=
br>
have to be carried via the DNS protocol and carrying it in the<br>
certificate chain works nicely. The code is already in Chrome (Dan<br>
demoed it at Blackhat last year), although it&#39;s currently expecting<br>
something like an early draft of CAA I think and it&#39;s off by default.<b=
r>
<br>
<br>
[1] <a href=3D"http://dev.chromium.org/sts" target=3D"_blank">http://dev.ch=
romium.org/sts</a><br>
[2] <a href=3D"https://github.com/ioerror/duraconf/blob/master/startssl/REA=
DME.markdown" target=3D"_blank">https://github.com/ioerror/duraconf/blob/ma=
ster/startssl/README.markdown</a><br>
<br>
<br>
Cheers<br>
<br>
AGL<br>
<font color=3D"#888888"><br>
--<br>
Adam Langley <a href=3D"mailto:[e-mail]">agl@imperialviolet.o=
rg</a> <a href=3D"http://www.imperialviolet.org" target=3D"_blank">http://w=
ww.imperialviolet.org</a><br>
_______________________________________________<br>
dane mailing list<br>
<a href=3D"mailto:[e-mail]">[e-mail]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/dane</a><br>
</font></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a href=
=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--20cf3054a1131bdae804a086985b--

From [e-mail]  Sat Apr  9 18:59:48 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFD693A6905 for <[e-mail]>; Sat,  9 Apr 2011 18:59:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.979
X-Spam-Level: 
X-Spam-Status: No, score=-2.979 tagged_above=-999 required=5 tests=[AWL=-0.381, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKilDz6yv77I for <[e-mail]>; Sat,  9 Apr 2011 18:59:45 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 7172F3A6819 for <[e-mail]>; Sat,  9 Apr 2011 18:59:45 -0700 (PDT)
Received: by vxg33 with SMTP id 33so4279610vxg.31 for <[e-mail]>; Sat, 09 Apr 2011 19:01:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=cP70YsFvJzYgMV1zAbojEry5FzK/3fjUtFxYM1bNwjg=; b=aK1bHpb+2XdEzKwulJSYPoj2YB20mivqQ0Vrycvb7ZKLFJ3A2zdNBXhBUpYzt6M/Jv 0s9xMPuuxTpTokNjJBHXNOfJw/jV80DjxbicciJrh1xEZqbtFHG35bbylrMN16veVtft VtSVF7A4RrSJh5AndI1qDS6N5ggBOtIL6JWZo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Lpe+pjXiFpVyxYUJCIC53b9XN7kIZJtIOGEwmPeKhwBRRI/EIfDlOebcRADNtPBeqi sFNFkYdvd2ITPy0ZWoo89K2g9JyMqkuponqyv7pdOE7g8aeIGbYoRMFlhNHGp5wAb/9t MXC42fq5FnAMNny5v65ptH9FDkJnzEKgAAf14=
MIME-Version: 1.0
Received: by 10.52.175.5 with SMTP id bw5mr44966vdc.69.1302400822989; Sat, 09 Apr 2011 19:00:22 -0700 (PDT)
Received: by 10.52.166.230 with HTTP; Sat, 9 Apr 2011 19:00:22 -0700 (PDT)
In-Reply-To: <BANLkTi=[e-mail]>
References: <[e-mail]> <BANLkTinD=[e-mail]> <BANLkTi=5rCGVPPiBVUd0oVm9F-big4R=[e-mail]> <BANLkTi=[e-mail]>
Date: Sat, 9 Apr 2011 22:00:22 -0400
Message-ID: <BANLkTi=[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: Zack Weinberg <[e-mail]>
Content-Type: multipart/alternative; boundary=20cf3071cebc68d57604a086d2fc
Cc: [e-mail]
Subject: Re: [dane] Requirements - HTTPS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 10 Apr 2011 01:59:48 -0000

--20cf3071cebc68d57604a086d2fc
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Apr 8, 2011 at 9:48 PM, Zack Weinberg <[e-mail]>wrote:

> On Fri, Apr 8, 2011 at 6:11 PM, Phillip Hallam-Baker <[e-mail]>
> wrote:
> > ?? As a reality check here, the browser providers have taken ten years to
> > get round to doing hard fail on OCSP.
> > So how likely is it that browser providers are going to refuse to
> implement
> > a new and untested spec unless it mandates hard fail behavior?
> >
> > Has anyone actually asked a browser provider what their opinion is? I
> rather
> > suspect not.
>
> I *am* a browser implementor, and my organization had this
> conversation at some length this week (and I thought you were one of
> the people dialed in!)  I refer you to
> http://www.owlfolio.org/research/securing-the-future-net/ -- but to be
> brief, there are major differences between DANE and OCSP that make the
> case for hard-fail for DANE enormously easier to make -- provided the
> standards back us up.
> First, sites opt-in to DANE, whereas OCSP (or more precisely,
> revocation checking) is something sites have no control over.  Second,
> revocation checking ties a site's availability to the reliability of a
> service they have no control over, whereas DANE is entirely under the
> control of the site (assuming it's big enough to run its own DNS
> servers).  And finally, DANE is new, so there is no ten-year history
> of browsers *not* failing on security errors with it.
>

Well I made the same arguments when OCSP was brand new as well :-)

I thought I was on a call with the Mozilla security people. I have never
found convincing security people to do security to be a problem.

OPT-in does seem to be the strongest argument for DANE being different.


The area where I am somewhat skeptical is in the response to cases where the
DNSSEC information is stripped out. I don't think we can expect to get hard
fail for that case. And it is a case that I expect to increase rather than
decrease.


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

--20cf3071cebc68d57604a086d2fc
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Fri, Apr 8, 2011 at 9:48 PM, Zack Weinberg <span dir=3D"ltr">&lt;<a href=
=3D"mailto:[e-mail]">[e-mail]</a>&gt;</span=
> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">On Fri, Apr 8, 2011 at 6:11 PM, Phillip Hallam-Baker &lt;=
<a href=3D"mailto:[e-mail]">[e-mail]</a>&gt; wrote:<br>
&gt; ?? As a reality check here, the browser providers have taken ten years=
 to<br>
&gt; get round to doing hard fail on OCSP.<br>
&gt; So how likely is it that browser providers are going to refuse to impl=
ement<br>
&gt; a new and untested spec unless it mandates hard fail behavior?<br>
&gt;<br>
&gt; Has anyone actually asked a browser provider what their opinion is? I =
rather<br>
&gt; suspect not.<br>
<br>
</div>I *am* a browser implementor, and my organization had this<br>
conversation at some length this week (and I thought you were one of<br>
the people dialed in!) =A0I refer you to<br>
<a href=3D"http://www.owlfolio.org/research/securing-the-future-net/" targe=
t=3D"_blank">http://www.owlfolio.org/research/securing-the-future-net/</a> =
-- but to be<br>
brief, there are major differences between DANE and OCSP that make the<br>
case for hard-fail for DANE enormously easier to make -- provided the<br>
standards back us up.<br>
First, sites opt-in to DANE, whereas OCSP (or more precisely,<br>
revocation checking) is something sites have no control over. =A0Second,<br=
>
revocation checking ties a site&#39;s availability to the reliability of a<=
br>
service they have no control over, whereas DANE is entirely under the<br>
control of the site (assuming it&#39;s big enough to run its own DNS<br>
servers). =A0And finally, DANE is new, so there is no ten-year history<br>
of browsers *not* failing on security errors with it.<font class=3D"Apple-s=
tyle-span" color=3D"#888888"><br></font></blockquote></div><div><br></div><=
div>Well I made the same arguments when OCSP was brand new as well :-)</div=
>
<div><br></div><div>I thought I was on a call with the Mozilla security peo=
ple. I have never found convincing security people to do security to be a p=
roblem.=A0</div><br clear=3D"all">OPT-in does seem to be the strongest argu=
ment for DANE being different. =A0<br>
<div><br></div><div><br></div><div>The area where I am somewhat skeptical i=
s in the response to cases where the DNSSEC information is stripped out. I =
don&#39;t think we can expect to get hard fail for that case. And it is a c=
ase that I expect to increase rather than decrease.</div>
<div><br></div><div><br></div><div>-- <br>Website: <a href=3D"http://hallam=
baker.com/">http://hallambaker.com/</a><br><br>
</div>

--20cf3071cebc68d57604a086d2fc--

From [e-mail]  Sat Apr  9 19:13:47 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 168DB3A694D for <[e-mail]>; Sat,  9 Apr 2011 19:13:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6uPduajzyFMa for <[e-mail]>; Sat,  9 Apr 2011 19:13:46 -0700 (PDT)
Received: from ppa02.Princeton.EDU (ppa02.Princeton.EDU [128.112.128.216]) by core3.amsl.com (Postfix) with ESMTP id 676A23A6905 for <[e-mail]>; Sat,  9 Apr 2011 19:13:46 -0700 (PDT)
Received: from csgsmtp201l.Princeton.EDU (csgsmtp201l.Princeton.EDU [128.112.134.60]) by ppa02.Princeton.EDU (8.14.3/8.14.3) with ESMTP id p3A2FWPI025944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Sat, 9 Apr 2011 22:15:32 -0400
Received: from new-host-4.home (pool-173-71-106-53.cmdnnj.fios.verizon.net [173.71.106.53]) (authenticated bits=0) by csgsmtp201l.Princeton.EDU (8.13.8/8.12.9) with ESMTP id p3A2FVM8003029 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for <[e-mail]>; Sat, 9 Apr 2011 22:15:32 -0400
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1082)
From: Steve Schultze <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Sat, 9 Apr 2011 22:15:31 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <BANLkTik-dMio6So4VW=[e-mail]> <[e-mail]> <[e-mail]>
To: [e-mail]
X-Mailer: Apple Mail (2.1082)
X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6311 signatures=657366
X-Proofpoint-Spam-Details: rule=quarantine_outbound_notspam policy=quarantine score=0 spamscore=0 ipscore=0 suspectscore=4 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1012030000 definitions=main-1104090132
Subject: Re: [dane] elephant use case,
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 10 Apr 2011 02:13:47 -0000

On Apr 9, 2011, at 4:00 PM, Phillip Hallam-Baker wrote:
> I make no apologies for correcting incorrect claims made by others to =
this list.=20

This will be my last response on the topic because I don't want to =
contribute to the ongoing sense of DDOS-via-posts that has been long =
felt on this list.  I am simply suggesting that you exercise a bit of =
Postel's Law on yourself and take your issues with EFF or others to the =
appropriate forum.=

From [e-mail]  Sat Apr  9 19:14:59 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96ECD3A69BC for <[e-mail]>; Sat,  9 Apr 2011 19:14:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.524
X-Spam-Level: 
X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NrW3E68I0Cji for <[e-mail]>; Sat,  9 Apr 2011 19:14:58 -0700 (PDT)
Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by core3.amsl.com (Postfix) with ESMTP id 63DD13A6905 for <[e-mail]>; Sat,  9 Apr 2011 19:14:58 -0700 (PDT)
Received: from [192.168.0.203] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 0ED8B1B41028; Sat,  9 Apr 2011 22:16:42 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Warren Kumari <[e-mail]>
In-Reply-To: <BANLkTi=[e-mail]>
Date: Sat, 9 Apr 2011 22:16:40 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]> <BANLkTinD=[e-mail]> <BANLkTi=5rCGVPPiBVUd0oVm9F-big4R=[e-mail]> <BANLkTi=[e-mail]> <BANLkTi=[e-mail]>
To: Phillip Hallam-Baker <[e-mail]>
X-Mailer: Apple Mail (2.1084)
Cc: [e-mail]
Subject: Re: [dane] Requirements - HTTPS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 10 Apr 2011 02:14:59 -0000

On Apr 9, 2011, at 10:00 PM, Phillip Hallam-Baker wrote:

> On Fri, Apr 8, 2011 at 9:48 PM, Zack Weinberg =
<[e-mail]> wrote:
> On Fri, Apr 8, 2011 at 6:11 PM, Phillip Hallam-Baker =
<[e-mail]> wrote:
> > ?? As a reality check here, the browser providers have taken ten =
years to
> > get round to doing hard fail on OCSP.
> > So how likely is it that browser providers are going to refuse to =
implement
> > a new and untested spec unless it mandates hard fail behavior?
> >
> > Has anyone actually asked a browser provider what their opinion is? =
I rather
> > suspect not.
>=20
> I *am* a browser implementor, and my organization had this
> conversation at some length this week (and I thought you were one of
> the people dialed in!)  I refer you to
> http://www.owlfolio.org/research/securing-the-future-net/ -- but to be
> brief, there are major differences between DANE and OCSP that make the
> case for hard-fail for DANE enormously easier to make -- provided the
> standards back us up.
> First, sites opt-in to DANE, whereas OCSP (or more precisely,
> revocation checking) is something sites have no control over.  Second,
> revocation checking ties a site's availability to the reliability of a
> service they have no control over, whereas DANE is entirely under the
> control of the site (assuming it's big enough to run its own DNS
> servers).  And finally, DANE is new, so there is no ten-year history
> of browsers *not* failing on security errors with it.
>=20
> Well I made the same arguments when OCSP was brand new as well :-)
>=20
> I thought I was on a call with the Mozilla security people. I have =
never found convincing security people to do security to be a problem.=20=

>=20
> OPT-in does seem to be the strongest argument for DANE being =
different. =20
>=20
>=20
> The area where I am somewhat skeptical is in the response to cases =
where the DNSSEC information is stripped out.

Um, haven't we gone through this a few times already? Stripping DNSSEC =
causes resolution to fail...

W

> I don't think we can expect to get hard fail for that case. And it is =
a case that I expect to increase rather than decrease.
>=20
>=20
> --=20
> Website: http://hallambaker.com/
>=20
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane


From [e-mail]  Sat Apr  9 19:32:10 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9769A3A69D8 for <[e-mail]>; Sat,  9 Apr 2011 19:32:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.278
X-Spam-Level: 
X-Spam-Status: No, score=-102.278 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxR78g5xo1Ux for <[e-mail]>; Sat,  9 Apr 2011 19:32:09 -0700 (PDT)
Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by core3.amsl.com (Postfix) with ESMTP id BDE6F3A69D1 for <[e-mail]>; Sat,  9 Apr 2011 19:32:09 -0700 (PDT)
Received: from omta19.emeryville.ca.mail.comcast.net ([76.96.30.76]) by qmta09.emeryville.ca.mail.comcast.net with comcast id VeGl1g0021eYJf8A9eZwHf; Sun, 10 Apr 2011 02:33:56 +0000
Received: from odin.ulthar.us ([68.33.77.0]) by omta19.emeryville.ca.mail.comcast.net with comcast id VeZu1g00D00PQ6U01eZv0c; Sun, 10 Apr 2011 02:33:56 +0000
Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.4/8.14.3) with ESMTP id p3A2XrKW025847 for <[e-mail]>; Sat, 9 Apr 2011 22:33:53 -0400
Received: (from draco@localhost) by odin.ulthar.us (8.14.4/8.14.4/Submit) id p3A2XrTI025845 for [e-mail]; Sat, 9 Apr 2011 22:33:53 -0400
Date: Sat, 9 Apr 2011 22:33:53 -0400
From: Scott Schmit <[e-mail]>
To: [e-mail]
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
References: <[e-mail]> <BANLkTinD=[e-mail]> <BANLkTi=5rCGVPPiBVUd0oVm9F-big4R=[e-mail]> <BANLkTi=[e-mail]> <BANLkTi=[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [dane] Requirements - HTTPS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 10 Apr 2011 02:32:10 -0000

On Sat, Apr 09, 2011 at 10:16:40PM -0400, Warren Kumari wrote:
> On Apr 9, 2011, at 10:00 PM, Phillip Hallam-Baker wrote:
> > Well I made the same arguments when OCSP was brand new as well :-)
> > 
> > I thought I was on a call with the Mozilla security people. I have
> > never found convincing security people to do security to be a
> > problem. 
> > 
> > OPT-in does seem to be the strongest argument for DANE being different.  
> > 
> > 
> > The area where I am somewhat skeptical is in the response to cases
> > where the DNSSEC information is stripped out.
> 
> Um, haven't we gone through this a few times already? Stripping DNSSEC
> causes resolution to fail...

Sure, but what's the browser going to do when the A/AAAA record comes
through fine, signatures and all, but the TLSA record results get
blocked? The client might treat it as a network problem instead of a
security problem.

I think that's what Phillip is concerned about.

-- 
Scott Schmit

From [e-mail]  Sat Apr  9 19:52:24 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADC363A694D for <[e-mail]>; Sat,  9 Apr 2011 19:52:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.529
X-Spam-Level: 
X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RdYxLJ3Ck+0q for <[e-mail]>; Sat,  9 Apr 2011 19:52:23 -0700 (PDT)
Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by core3.amsl.com (Postfix) with ESMTP id 8A1B03A6828 for <[e-mail]>; Sat,  9 Apr 2011 19:52:23 -0700 (PDT)
Received: from [192.168.0.203] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id BA9421B41028; Sat,  9 Apr 2011 22:53:45 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Warren Kumari <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Sat, 9 Apr 2011 22:53:22 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]> <BANLkTinD=[e-mail]> <BANLkTi=5rCGVPPiBVUd0oVm9F-big4R=[e-mail]> <BANLkTi=[e-mail]> <BANLkTi=[e-mail]> <[e-mail]> <[e-mail]>
To: Scott Schmit <[e-mail]>
X-Mailer: Apple Mail (2.1084)
Cc: [e-mail]
Subject: Re: [dane] Requirements - HTTPS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 10 Apr 2011 02:52:25 -0000

On Apr 9, 2011, at 10:33 PM, Scott Schmit wrote:

> On Sat, Apr 09, 2011 at 10:16:40PM -0400, Warren Kumari wrote:
>> On Apr 9, 2011, at 10:00 PM, Phillip Hallam-Baker wrote:
>>> Well I made the same arguments when OCSP was brand new as well :-)
>>>=20
>>> I thought I was on a call with the Mozilla security people. I have
>>> never found convincing security people to do security to be a
>>> problem.=20
>>>=20
>>> OPT-in does seem to be the strongest argument for DANE being =
different. =20
>>>=20
>>>=20
>>> The area where I am somewhat skeptical is in the response to cases
>>> where the DNSSEC information is stripped out.
>>=20
>> Um, haven't we gone through this a few times already? Stripping =
DNSSEC
>> causes resolution to fail...
>=20
> Sure, but what's the browser going to do when the A/AAAA record comes
> through fine, signatures and all, but the TLSA record results get
> blocked? The client might treat it as a network problem instead of a
> security problem.
>=20
> I think that's what Phillip is concerned about.

Ok, thanks for clarifying. If TLSA records are being stripped the client =
has evidence that someone is playing shenanigans and should panic, =
shouldn't it?

I thought that the current version of the draft had some text that =
covers this (I'm out and don't have it in front of me at the moment) =
somewhere in section 3 (near the "gets zero or more" text), or (AFAIR) =
issue #7. If not, we might need to address this more clearly...

W

>=20
> --=20
> Scott Schmit
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane
>=20


From [e-mail]  Sun Apr 10 01:43:23 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DE333A69A9 for <[e-mail]>; Sun, 10 Apr 2011 01:43:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.818
X-Spam-Level: 
X-Spam-Status: No, score=-105.818 tagged_above=-999 required=5 tests=[AWL=-0.616, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2+EVmPg0f7km for <[e-mail]>; Sun, 10 Apr 2011 01:43:21 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id F1DB53A684D for <[e-mail]>; Sun, 10 Apr 2011 01:43:20 -0700 (PDT)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p3A8j3wp017388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 10 Apr 2011 10:45:03 +0200
Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p3A8j23N002386; Sun, 10 Apr 2011 10:45:03 +0200
Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675);  Sun, 10 Apr 2011 10:44:34 +0200
Received: from 10.144.233.83 ([10.144.233.83]) by FIESEXC035.nsn-intra.net ([10.159.0.182]) via Exchange Front-End Server webmail.nsn-intra.net ([10.150.128.35]) with Microsoft Exchange Server HTTP-DAV ; Sun, 10 Apr 2011 08:44:33 +0000
User-Agent: Microsoft-Entourage/12.28.0.101117
Date: Wed, 06 Apr 2011 15:28:44 +0200
From: Hannes Tschofenig <[e-mail]>
To: Phillip Hallam-Baker <[e-mail]>, Paul Hoffman <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: [dane] browser UI out of scope
Thread-Index: Acv0Xo0BnGi/66FVN0qKhASaNpwykQ==
In-Reply-To: <BANLkTi=[e-mail]>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3385280668_15531631"
X-OriginalArrivalTime: 10 Apr 2011 08:44:34.0383 (UTC) FILETIME=[844BB5F0:01CBF75B]
Cc: [e-mail]
Subject: Re: [dane] browser UI out of scope
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 10 Apr 2011 08:43:23 -0000

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3385280668_15531631
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

A few minor notes:=20

Out of scope may mean that you are not going to standardize the UI in IETF
documents. That's perfectly fine.

However, as we have learned with many security protocols there often is use=
r
interaction and in order to have the entire system being useful you also
have to **think** about the UI design.

So, think about it without mandating a specific UI design.

Ciao
Hannes

PS: A similar case from a different area: Quality of Service. While we do
not mandate a specific business model in the IETF it is useful to think
about the business incentives of the solutions we are working on.

On 4/6/11 3:08 PM, "Phillip Hallam-Baker" <[e-mail]> wrote:

> Paul is exactly right here.
>=20
> We have to cover cases where there is no UI at all. Including cases where
> there is no Human Interaction (HI) because there is no human in the loop.
>=20
> STARTTLS is a very good example. The mailing list software that supports =
this
> list has to work without any human intervention whatsoever. No human, no =
human
> interaction.
>=20
>=20
> We can approach the problem in stages. For example, we could decide to de=
sign
> a RR that is extensible so that we can first address the requirement for
> Domain Validated keys and after that is done address the requirement for
> verifying that TLS is used to secure the connection.
>=20
>=20
> On Wed, Apr 6, 2011 at 12:26 PM, Paul Hoffman <[e-mail]> wro=
te:
>> On Apr 6, 2011, at 4:56 AM, Florian Weimer wrote:
>>=20
>>> > * Paul Wouters:
>>> >
>>>> >> This working group is designing a protocol, not a web browser UI. I
>>>> >> suggest we focus on the protocol design, and not get lost in
>>>> >> padlocks, green bars, blue badges or what not.
>>> >
>>> > Oh, could you please clarify what you mean by this: Do you want to
>>> > design a protocol, without consideration for the UI side? =A0Or do you
>>> > want to design a protocol which does not require UI changes? =A0Or
>>> > something else entirely?
>>=20
>> Speaking for myself: the first. TLSA applies to TLS, not "TLS but only i=
n a
>> web browser". This is completely clear in the document. There is no
>> equivalent of a "lock icon" when a mail program downloads mail using IMA=
P or
>> POP using TLS, and this is the wrong place to say that there should be (=
more
>> than a decade later...). Similarly, many TLS-using scenarios involve cli=
ents
>> and servers with no humans watching.
>>=20
>> --Paul Hoffman
>>=20
>> _______________________________________________
>> dane mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dane
>=20
>=20


--B_3385280668_15531631
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [dane] browser UI out of scope</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>A few minor notes: <BR>
<BR>
Out of scope may mean that you are not going to standardize the UI in IETF =
documents. That's perfectly fine. <BR>
<BR>
However, as we have learned with many security protocols there often is use=
r interaction and in order to have the entire system being useful you also h=
ave to **think** about the UI design. <BR>
<BR>
So, think about it without mandating a specific UI design. <BR>
<BR>
Ciao<BR>
Hannes<BR>
<BR>
PS: A similar case from a different area: Quality of Service. While we do n=
ot mandate a specific business model in the IETF it is useful to think about=
 the business incentives of the solutions we are working on. <BR>
<BR>
On 4/6/11 3:08 PM, &quot;Phillip Hallam-Baker&quot; &lt;<a href=3D"hallam@gma=
il.com">[e-mail]</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'>Paul is exactly right here.<BR>
<BR>
We have to cover cases where there is no UI at all. Including cases where t=
here is no Human Interaction (HI) because there is no human in the loop.<BR>
<BR>
STARTTLS is a very good example. The mailing list software that supports th=
is list has to work without any human intervention whatsoever. No human, no =
human interaction.<BR>
<BR>
<BR>
We can approach the problem in stages. For example, we could decide to desi=
gn a RR that is extensible so that we can first address the requirement for =
Domain Validated keys and after that is done address the requirement for ver=
ifying that TLS is used to secure the connection.<BR>
<BR>
<BR>
On Wed, Apr 6, 2011 at 12:26 PM, Paul Hoffman &lt;<a href=3D"paul.hoffman@vpn=
c.org">[e-mail]</a>&gt; wrote:<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'>On Apr 6, 2011, at 4:56 AM, Florian Weimer wrote=
:<BR>
<BR>
&gt; * Paul Wouters:<BR>
&gt;<BR>
&gt;&gt; This working group is designing a protocol, not a web browser UI. =
I<BR>
&gt;&gt; suggest we focus on the protocol design, and not get lost in<BR>
&gt;&gt; padlocks, green bars, blue badges or what not.<BR>
&gt;<BR>
&gt; Oh, could you please clarify what you mean by this: Do you want to<BR>
&gt; design a protocol, without consideration for the UI side? =A0Or do you<B=
R>
&gt; want to design a protocol which does not require UI changes? =A0Or<BR>
&gt; something else entirely?<BR>
<BR>
Speaking for myself: the first. TLSA applies to TLS, not &quot;TLS but only=
 in a web browser&quot;. This is completely clear in the document. There is =
no equivalent of a &quot;lock icon&quot; when a mail program downloads mail =
using IMAP or POP using TLS, and this is the wrong place to say that there s=
hould be (more than a decade later...). Similarly, many TLS-using scenarios =
involve clients and servers with no humans watching.<BR>
<FONT COLOR=3D"#888888"><BR>
--Paul Hoffman<BR>
</FONT><BR>
_______________________________________________<BR>
dane mailing list<BR>
<a href=3D"[e-mail]">[e-mail]</a><BR>
<a href=3D"https://www.ietf.org/mailman/listinfo/dane">https://www.ietf.org/m=
ailman/listinfo/dane</a><BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">=
<SPAN STYLE=3D'font-size:11pt'><BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>


--B_3385280668_15531631--


From [e-mail]  Sun Apr 10 04:58:58 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A8A23A6986 for <[e-mail]>; Sun, 10 Apr 2011 04:58:58 -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=[AWL=-0.379, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJbHS+9T5RPK for <[e-mail]>; Sun, 10 Apr 2011 04:58:57 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id C84213A68EF for <[e-mail]>; Sun, 10 Apr 2011 04:58:56 -0700 (PDT)
Received: by vxg33 with SMTP id 33so4438740vxg.31 for <[e-mail]>; Sun, 10 Apr 2011 05:00:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=P8dHenFQVeiL0otpqLxXWcPEJvCGvOorBk9T+l/z4tw=; b=ch+ELnusrIS5VebnRPB0LBefsMyxp7RtsdwT4mrPhsyxZvUdgfARQC8Zt3UK56XRLY Gq72c8z79FpANmwmHIEYdka6YV37COG04kQN/a+4D0W3m77ydPIgNxsHFXvFAs74zIH8 eqHpEGmylRHaNZth+j5AYGfCWA0YIB9VUnJ7w=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=HxEgUZZsb5/lYWj4BSjl38CM8L0eIUbddRTafpIVpdJRp5Qf2RBb6PtNy9J1jb7kks KzAzxav3CXz4ge8CSbJ8OWXkoCe1eXM5KUeZ7bIg9X5cuoVuSD0BGKd3TuIutGvPsnOf 8fOq+yb8m/oY84ymIEqS47FxFXmcX/KjNO9Gw=
MIME-Version: 1.0
Received: by 10.52.65.52 with SMTP id u20mr6049249vds.309.1302436843082; Sun, 10 Apr 2011 05:00:43 -0700 (PDT)
Received: by 10.52.166.230 with HTTP; Sun, 10 Apr 2011 05:00:42 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <BANLkTinD=[e-mail]> <BANLkTi=5rCGVPPiBVUd0oVm9F-big4R=[e-mail]> <BANLkTi=[e-mail]> <BANLkTi=[e-mail]> <[e-mail]> <[e-mail]>
Date: Sun, 10 Apr 2011 08:00:42 -0400
Message-ID: <BANLkTinf8gFaNN7eGvex6+Ee3=[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: [e-mail]
Content-Type: multipart/alternative; boundary=bcaec50166a55fd34704a08f350d
Subject: Re: [dane] Requirements - HTTPS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 10 Apr 2011 11:58:58 -0000

--bcaec50166a55fd34704a08f350d
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Apr 9, 2011 at 10:33 PM, Scott Schmit <[e-mail]> wrote:

> On Sat, Apr 09, 2011 at 10:16:40PM -0400, Warren Kumari wrote:
> > On Apr 9, 2011, at 10:00 PM, Phillip Hallam-Baker wrote:
> > > Well I made the same arguments when OCSP was brand new as well :-)
> > >
> > > I thought I was on a call with the Mozilla security people. I have
> > > never found convincing security people to do security to be a
> > > problem.
> > >
> > > OPT-in does seem to be the strongest argument for DANE being different.
> > >
> > >
> > > The area where I am somewhat skeptical is in the response to cases
> > > where the DNSSEC information is stripped out.
> >
> > Um, haven't we gone through this a few times already? Stripping DNSSEC
> > causes resolution to fail...
>
> Sure, but what's the browser going to do when the A/AAAA record comes
> through fine, signatures and all, but the TLSA record results get
> blocked? The client might treat it as a network problem instead of a
> security problem.
>
> I think that's what Phillip is concerned about.
>

Yes, I can't see how anyone is going to hard fail that case.



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

--bcaec50166a55fd34704a08f350d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Sat, Apr 9, 2011 at 10:33 PM, Scott S=
chmit <span dir=3D"ltr">&lt;<a href=3D"mailto:[e-mail]">i.grok@co=
mcast.net</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">On Sat, Apr 09, 2011 at 10:16:40PM -0400, Warren Kumari w=
rote:<br>
&gt; On Apr 9, 2011, at 10:00 PM, Phillip Hallam-Baker wrote:<br>
</div><div class=3D"im">&gt; &gt; Well I made the same arguments when OCSP =
was brand new as well :-)<br>
&gt; &gt;<br>
&gt; &gt; I thought I was on a call with the Mozilla security people. I hav=
e<br>
&gt; &gt; never found convincing security people to do security to be a<br>
&gt; &gt; problem.<br>
&gt; &gt;<br>
&gt; &gt; OPT-in does seem to be the strongest argument for DANE being diff=
erent.<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; The area where I am somewhat skeptical is in the response to case=
s<br>
&gt; &gt; where the DNSSEC information is stripped out.<br>
&gt;<br>
&gt; Um, haven&#39;t we gone through this a few times already? Stripping DN=
SSEC<br>
&gt; causes resolution to fail...<br>
<br>
</div>Sure, but what&#39;s the browser going to do when the A/AAAA record c=
omes<br>
through fine, signatures and all, but the TLSA record results get<br>
blocked? The client might treat it as a network problem instead of a<br>
security problem.<br>
<br>
I think that&#39;s what Phillip is concerned about.<br></blockquote><div><b=
r></div><div>Yes, I can&#39;t see how anyone is going to hard fail that cas=
e.</div><div><br></div><div>=A0</div></div><br>-- <br>Website: <a href=3D"h=
ttp://hallambaker.com/">http://hallambaker.com/</a><br>
<br>

--bcaec50166a55fd34704a08f350d--

From [e-mail]  Sun Apr 10 07:52:36 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8974C3A6A21 for <[e-mail]>; Sun, 10 Apr 2011 07:52:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -93.401
X-Spam-Level: 
X-Spam-Status: No, score=-93.401 tagged_above=-999 required=5 tests=[AWL=-9.802, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, URIBL_BLACK=20, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-X+zTC58NRH for <[e-mail]>; Sun, 10 Apr 2011 07:52:35 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 154553A6A1D for <[e-mail]>; Sun, 10 Apr 2011 07:52:34 -0700 (PDT)
Received: by wyb29 with SMTP id 29so4605606wyb.31 for <[e-mail]>; Sun, 10 Apr 2011 07:54:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=pruRpc83vjorTQqwQ8LDW37lHc9X7BUPHf00c9ydPgU=; b=W3kakLszEMxKJSi9PRZg5T0i4oxCveBNvK4aYjYWOw+i0V0KXWSs0Wt3s0Bql0TsRg 5Tt0Kqcqb3f5P/gu1UfG0QyKV4Td9p54tL6eJvbNxxXDWRTN7gDyKXiDtAUDqt1b619x HxuWr4dCcRBuuF42OFbXxKQmBri+L+8p9yNS0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Y09dHWtWwmm5+ePGkofylyziLhuaJRRonal8JsG8z55Fe0KdM5n8bBmqkv1GOSTzlT YI7YySpsy//vcxh6bNoMC4EwQSqiavgyj2sKPIDPwEa3D5E7seLEXuNO9FxvaUjX4bpn 2xXvC6K1j6KgO9/1f0nDehKXmqXkPG2fCXtJw=
MIME-Version: 1.0
Received: by 10.216.145.134 with SMTP id p6mr783535wej.112.1302447261053; Sun, 10 Apr 2011 07:54:21 -0700 (PDT)
Sender: [e-mail]
Received: by 10.216.50.211 with HTTP; Sun, 10 Apr 2011 07:54:20 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Sun, 10 Apr 2011 16:54:20 +0200
X-Google-Sender-Auth: o-EcZ8Am8w4QBdJM5JWCkDraP-k
Message-ID: <BANLkTimGmtOS0=KbaChb=5F=K=[e-mail]>
From: Christopher Morrow <[e-mail]>
To: [e-mail]
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: [e-mail]
Subject: Re: [dane] Use Cases Document
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 10 Apr 2011 14:52:36 -0000

On Fri, Apr 8, 2011 at 7:36 PM, Kirk Hall <[e-mail]> wrote:
>
> (1) CAs review DV cert requests for =93high risk=94 organization and doma=
in
> names that are most commonly targeted in phishing and other fraudulent
> schemes, and reject those cert requests.=A0 These lists include (a) inter=
nal

<insert comodogate here>

> Does DANE contemplate that the DNS operators would also reject domain

I think, from my brief reading, the 'dns operator' here is ... the
owner of the domain. So, 'stolen-bank-of-america-credentials.com' if
owned by 'evil person' could certainly publish a cert record for the
self-signed cert on their website stealing credentials from naive
users.

how many folks really get phished/etc over ssl connections today? (not
many, if any, ssl isn't a factor in this problem space)

>
> (2) CAs also employ other anti-fraud algorithms of their own against bad =
DV

<insert comodogate here>

> Do you contemplate that DNS operators would do anything similar for
> self-signed certs?

why would they? they are putting records into their own zone... if
somone they don't know/trust can make changes to their DNSSEC signed
DNS data... they are sunk anyway.

> (3) DV certs have a clear chain of liability back to the issuing CA. The =
CAs
> today do a pretty good job in preventing high risk similar-named domains,
> like =93paypall.com=94,=A0 from getting certs for fraud and phishing purp=
oses.

<insert comodogate here>

> Under DANE, if a self-signed certificate issued in the name of =93paypall=
.com=94
> is accepted by a DNS operator and is used in phishing attacks, who would =
be

the person that owns paypall.com can certainly make a self-signed
cert... and put the appropriate record into the dns zone they own, and
sign it with the key they have... this isn't significantly different
than where we are today.

> (5) Bad certs can be revoked, and the industry is working very hard right
> now on improving the revocation process.

by completely sidestepping it? (let's hardcode certs into binaries,
because .. oscp is an admitted failure)

> If there is a =93bad=94 self-signed cert associated with a domain by a DN=
S
> operator and/or a DNS operator receives a report of fraud or phishing
> associated with a domain, will DANE have a way to remove, revoke, or
> otherwise flag the cert as =93bad=94?

sure, remove the record from dns (in the zone that publishes it)

-chris

From [e-mail]  Sun Apr 10 10:11:02 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B46953A6999 for <[e-mail]>; Sun, 10 Apr 2011 10:11:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.155
X-Spam-Level: 
X-Spam-Status: No, score=-2.155 tagged_above=-999 required=5 tests=[AWL=0.445,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JdMXKux1x+UX for <[e-mail]>; Sun, 10 Apr 2011 10:10:57 -0700 (PDT)
Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by core3.amsl.com (Postfix) with ESMTP id EAA483A695F for <[e-mail]>; Sun, 10 Apr 2011 10:10:56 -0700 (PDT)
Received: by eagle.jhcloos.com (Postfix, from userid 10) id 9D26E40137; Sun, 10 Apr 2011 17:10:30 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1302455454; bh=IWWGY2USDbTrnE4mBQCnD5JsQNVaMHnJbERRC7RnX94=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=pIGHGeeHK0JPPbI9v12JcmFhvfMEGSQSoyWB/0bX2865p1x12Zq/VtSspw2sWPa7e uVusDfEWW5YIUvyHCIr9aCsHuXJIUjrdxPZ02N9hqFpaKDoa8wS3v22zfvIkpLDMnA bPm4w4/7zeOmUyEFM6RHQHB6vt0wBnAAeayasuU8=
Received: by carbon.jhcloos.org (Postfix, from userid 500) id C4582260042; Sun, 10 Apr 2011 17:09:46 +0000 (UTC)
From: James Cloos <[e-mail]>
To: Adam Langley <[e-mail]>
In-Reply-To: <BANLkTin-E=[e-mail]> (Adam Langley's message of "Sat, 9 Apr 2011 17:12:01 -0400")
References: <BANLkTin-E=[e-mail]>
User-Agent: Gnus/5.110016 (No Gnus v0.16) Emacs/24.0.50 (gnu/linux)
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC
Copyright: Copyright 2011 James Cloos
OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc
OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6
Date: Sun, 10 Apr 2011 13:09:46 -0400
Message-ID: <[e-mail]>
Lines: 18
MIME-Version: 1.0
Content-Type: text/plain
X-Hashcash: 1:30:110410:[e-mail]::Q2XY+9ejUOsvLbTA:000000000000000000000000000000000000000910a
X-Hashcash: 1:30:110410:[e-mail]::n6Rrfpsdodm7aotW:00080fi6
Cc: [e-mail]
Subject: Re: [dane] A browser's myopic view
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 10 Apr 2011 17:11:02 -0000

Apps probably SHOULD first confirm whether their dns path support dnssec
validation before even considering doing dane lookups.

I run a validating recursive dns server locally (really all dnssec users
should run their own validating recursor; at least on the local lan if
not on the box; else there is no real security) and that makes all
validatable lookups slower.

(A classic example is weather.noaa.gov.  With a cold cache that normally
takes between 90 and 120 seconds.  And you get a validated CNAME which
points to an unvalidated pair of A RRs. :-/ )

Given how long it often takes to validate the A and AAAA RRs, it really
shouldn't take significant extra time also to validate a DTLS RR.

-JimC
-- 
James Cloos <[e-mail]>         OpenPGP: 1024D/ED7DAEA6

From [e-mail]  Sun Apr 10 10:26:56 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6529B3A695F for <[e-mail]>; Sun, 10 Apr 2011 10:26:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.174
X-Spam-Level: 
X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.426,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6AvVYaod-qQ6 for <[e-mail]>; Sun, 10 Apr 2011 10:26:55 -0700 (PDT)
Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by core3.amsl.com (Postfix) with ESMTP id 2A7B03A6916 for <[e-mail]>; Sun, 10 Apr 2011 10:26:55 -0700 (PDT)
Received: by eagle.jhcloos.com (Postfix, from userid 10) id D3A9A400B4; Sun, 10 Apr 2011 17:26:29 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1302456413; bh=U1wTvdww6Z8aI1ZBm94nzuq7qSQZ7RHaeTR6DsQ9TVk=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; b=Kfs5Rc0sFtxqNQRge17hLdfElnUrTdwGulc/Sc89iPs4xabjK+M1BtQvVkXDOIyo2 usH7jEkv1N7p//rdzbxyhFAbr7Kh/7aLMdsKOD6qdcYPTP1D8w4a+Kb9KjnPzGXbDK wSEfO0AtozLiG0aH0nOSe3+T3GWCs0xV25g9Y9pQ=
Received: by carbon.jhcloos.org (Postfix, from userid 500) id 08F42260042; Sun, 10 Apr 2011 17:22:29 +0000 (UTC)
From: James Cloos <[e-mail]>
To: [e-mail]
User-Agent: Gnus/5.110016 (No Gnus v0.16) Emacs/24.0.50 (gnu/linux)
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC
Copyright: Copyright 2011 James Cloos
OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc
OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6
Date: Sun, 10 Apr 2011 13:22:29 -0400
Message-ID: <[e-mail]>
Lines: 19
MIME-Version: 1.0
Content-Type: text/plain
X-Hashcash: 1:30:110410:[e-mail]::ACEl2WH7olJ/IuSl:000Whuez
Subject: [dane] Securing by-address IRIs
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 10 Apr 2011 17:26:56 -0000

There are a number of protocols where it is common to specify the remote
side by ip address rather than by a name.  Both sides are often on the
same lan, but the is not universal.

It seems like it would be useful for us also to provide a trust anchor
mechanism for that usage pattern.

But how?

Should the lookup be, eg, _prefix.3.2.1.10.in-addr.arpa. DTLS?  (For
whatever we decide on for prefixing.)  And the like for ipv6?

Or, given that the practice at least originated with a desire to
elimiate dns-induced latency and points of failure, is that style
of addressing out of scope of dns-anchored trust?

-JimC
-- 
James Cloos <[e-mail]>         OpenPGP: 1024D/ED7DAEA6

From [e-mail]  Sun Apr 10 11:53:58 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECA8C3A6953 for <[e-mail]>; Sun, 10 Apr 2011 11:53:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.474
X-Spam-Level: 
X-Spam-Status: No, score=-1.474 tagged_above=-999 required=5 tests=[AWL=-0.775, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBK9AXCwYY9S for <[e-mail]>; Sun, 10 Apr 2011 11:53:58 -0700 (PDT)
Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by core3.amsl.com (Postfix) with ESMTP id D3A6D3A6876 for <[e-mail]>; Sun, 10 Apr 2011 11:53:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=3VdvwzWeRxl2TyM7UZLjXoyr7iOR++h/jxILJOs98pc=; b=rYZPPxSYT1G9Xlb9nTpEk52AgB30TjYFVBJBSiVC3Y/I1F4Ro2CoUMbLFaPSIghYUXRdpyaRROr7d V+AxZPVJ9GpShN2NQsPlgtTNud4PhC/FZPg25F3jeOPWAZBPjp8Mq538n1dMBKbNo2aqp7NJUz63HD ncgWHbXFYjOPczuI=
Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Sun, 10 Apr 2011 20:53:53 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Jakob Schlyter <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Sun, 10 Apr 2011 20:53:46 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]>
To: James Cloos <[e-mail]>
X-Mailer: Apple Mail (2.1084)
Cc: [e-mail]
Subject: Re: [dane] Securing by-address IRIs
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 10 Apr 2011 18:53:59 -0000

On 10 apr 2011, at 19.22, James Cloos wrote:

> Should the lookup be, eg, _prefix.3.2.1.10.in-addr.arpa. DTLS?  (For
> whatever we decide on for prefixing.)  And the like for ipv6?

sure, why not?

(btw, the prefix was issue #19 and has been closed - the format is =
_port._transport.fqdn)

	jakob

--=20
Jakob Schlyter
Kirei AB - www.kirei.se




From [e-mail]  Sun Apr 10 15:29:03 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09A123A6940 for <[e-mail]>; Sun, 10 Apr 2011 15:29:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.594
X-Spam-Level: 
X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=0.005,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ov2Q7uV4ByG for <[e-mail]>; Sun, 10 Apr 2011 15:29:02 -0700 (PDT)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 707C93A6907 for <[e-mail]>; Sun, 10 Apr 2011 15:29:02 -0700 (PDT)
Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id DE1C5C5ED; Sun, 10 Apr 2011 18:28:59 -0400 (EDT)
Date: Sun, 10 Apr 2011 18:28:59 -0400 (EDT)
From: Paul Wouters <[e-mail]>
To: Paul Hoffman <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Subject: [dane] Section 2.2 Certificate format question
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 10 Apr 2011 22:29:03 -0000

In section 2.2 it states:

 	The "certificate for association".  This is the bytes containing
 	the full certificate or the hash of the associated certificate
 	(that is, the certificate or the hash of the certificate itself,
 	not of the TLS ASN.1Cert object).

For the full certificate, am I right that this format is the base64
encoding of the DER encoded certificate?  If so, can the section be
updated to state so?

Paul

From [e-mail]  Sun Apr 10 15:50:37 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E6D73A6A03 for <[e-mail]>; Sun, 10 Apr 2011 15:50:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJispTm8sVKl for <[e-mail]>; Sun, 10 Apr 2011 15:50:35 -0700 (PDT)
Received: from ppa04.Princeton.EDU (ppa04.Princeton.EDU [128.112.128.215]) by core3.amsl.com (Postfix) with ESMTP id 2FF093A69FD for <[e-mail]>; Sun, 10 Apr 2011 15:50:35 -0700 (PDT)
Received: from csgsmtp200l.Princeton.EDU (csgsmtp200l.Princeton.EDU [128.112.130.131]) by ppa04.Princeton.EDU (8.14.3/8.14.3) with ESMTP id p3AMoYuN022156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Sun, 10 Apr 2011 18:50:34 -0400
Received: from new-host-4.home (pool-173-71-106-53.cmdnnj.fios.verizon.net [173.71.106.53]) (authenticated bits=0) by csgsmtp200l.Princeton.EDU (8.13.8/8.12.9) with ESMTP id p3AMoYIp014613 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for <[e-mail]>; Sun, 10 Apr 2011 18:50:34 -0400
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1082)
From: Steve Schultze <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Sun, 10 Apr 2011 18:50:33 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]> <BANLkTinD=[e-mail]> <BANLkTi=5rCGVPPiBVUd0oVm9F-big4R=[e-mail]> <BANLkTi=[e-mail]> <BANLkTi=[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
To: [e-mail]
X-Mailer: Apple Mail (2.1082)
X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6312 signatures=657374
X-Proofpoint-Spam-Details: rule=quarantine_outbound_notspam policy=quarantine score=0 spamscore=0 ipscore=0 suspectscore=4 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1012030000 definitions=main-1104100145
Subject: Re: [dane] Requirements - HTTPS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 10 Apr 2011 22:50:37 -0000

On Apr 9, 2011, at 10:53 PM, Warren Kumari wrote:
> On Apr 9, 2011, at 10:33 PM, Scott Schmit wrote:
>> On Sat, Apr 09, 2011 at 10:16:40PM -0400, Warren Kumari wrote:
>>> On Apr 9, 2011, at 10:00 PM, Phillip Hallam-Baker wrote:
>>>> The area where I am somewhat skeptical is in the response to cases
>>>> where the DNSSEC information is stripped out.
>>>=20
>>> Um, haven't we gone through this a few times already? Stripping =
DNSSEC
>>> causes resolution to fail...
>>=20
>> Sure, but what's the browser going to do when the A/AAAA record comes
>> through fine, signatures and all, but the TLSA record results get
>> blocked? The client might treat it as a network problem instead of a
>> security problem.
>>=20
>> I think that's what Phillip is concerned about.
>=20
> Ok, thanks for clarifying. If TLSA records are being stripped the =
client has evidence that someone is playing shenanigans and should =
panic, shouldn't it?

Yes, I think it should.  Otherwise we introduce a downgrade attack =
vector (issue #6).=20

> I thought that the current version of the draft had some text that =
covers this (I'm out and don't have it in front of me at the moment) =
somewhere in section 3 (near the "gets zero or more" text), or (AFAIR) =
issue #7. If not, we might need to address this more clearly...

Issue #7 doesn't directly address this.

The text in section 3 also does not clearly address this.  I'd like to =
suggest again that we consider a version of Matt's proposed text for =
Section 3.  It clearly outlines the different responses and results.  =
Back in January, Paul suggested that we wait on deciding this, but =
perhaps now is a good time.

http://www.ietf.org/mail-archive/web/dane/current/msg01451.html

Specifically, I believe that this sentence is Matt's proposal would =
address the case at hand:

"If any query cannot be completed or gives a "bogus" result as described
in RFC 4033 section 5, validation MUST fail and the client MUST abort
the TLS handshake (if it has been started) with a "TBD" error."

In this case, I think the described scenario is a "query that cannot be =
completed" because as described there is no positive or negative =
response for the TLSA query.=

From [e-mail]  Sun Apr 10 16:03:22 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34E743A6A03 for <[e-mail]>; Sun, 10 Apr 2011 16:03:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.133
X-Spam-Level: 
X-Spam-Status: No, score=-102.133 tagged_above=-999 required=5 tests=[AWL=0.466, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0XSszdY2xrc for <[e-mail]>; Sun, 10 Apr 2011 16:03:21 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by core3.amsl.com (Postfix) with ESMTP id E46523A69FD for <[e-mail]>; Sun, 10 Apr 2011 16:03:20 -0700 (PDT)
Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p3AN3J8p025158 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 10 Apr 2011 16:03:19 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Paul Hoffman <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Sun, 10 Apr 2011 16:03:19 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]>
To: Paul Wouters <[e-mail]>
X-Mailer: Apple Mail (2.1084)
Cc: [e-mail]
Subject: Re: [dane] Section 2.2 Certificate format question
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 10 Apr 2011 23:03:22 -0000

On Apr 10, 2011, at 3:28 PM, Paul Wouters wrote:

>=20
> In section 2.2 it states:
>=20
> 	The "certificate for association".  This is the bytes containing
> 	the full certificate or the hash of the associated certificate
> 	(that is, the certificate or the hash of the certificate itself,
> 	not of the TLS ASN.1Cert object).
>=20
> For the full certificate, am I right that this format is the base64
> encoding of the DER encoded certificate?  If so, can the section be
> updated to state so?

Let's be careful here. The bytes are not base64-encoded: the =
representation of those bytes are encoded in the record. The =
"certificate for association" is just the bytes themselves.

As for the bytes of a PKIX certificate being DER encoded, that's already =
defined in the PKIX spec. If we put that here and someone adds a =
different certificate for association, such as a bare key (cough cough), =
then that bare key would need to be DER encoded; that may not be what =
the people writing those specs want. It is probably better to let the =
format of the bytes be defined in the other specs.

--Paul Hoffman


From [e-mail]  Sun Apr 10 17:21:29 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D4023A6A21 for <[e-mail]>; Sun, 10 Apr 2011 17:21:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.559
X-Spam-Level: 
X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7M2KNoPNAzg5 for <[e-mail]>; Sun, 10 Apr 2011 17:21:28 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 5E28A3A68FD for <[e-mail]>; Sun, 10 Apr 2011 17:21:28 -0700 (PDT)
Received: from [128.89.255.224] (port=50710 helo=[192.168.1.100]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from <[e-mail]>) id 1Q94sf-0002Q3-OW; Sun, 10 Apr 2011 20:21:25 -0400
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: "Richard L. Barnes" <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Sun, 10 Apr 2011 20:21:23 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
To: Paul Hoffman <[e-mail]>
X-Mailer: Apple Mail (2.1082)
Cc: [e-mail]
Subject: Re: [dane] Section 2.2 Certificate format question
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 11 Apr 2011 00:21:29 -0000

Also, in the presentation format (Section 2.4), the place where it =
*might* make sense to Base64-encode, it says that the certificate is =
"presented in hex".  So, raw hex bytes, not Base64.
<http://tools.ietf.org/html/draft-ietf-dane-protocol-06#section-2.4>
--Richard



On Apr 10, 2011, at 7:03 PM, Paul Hoffman wrote:

> On Apr 10, 2011, at 3:28 PM, Paul Wouters wrote:
>=20
>>=20
>> In section 2.2 it states:
>>=20
>> 	The "certificate for association".  This is the bytes containing
>> 	the full certificate or the hash of the associated certificate
>> 	(that is, the certificate or the hash of the certificate itself,
>> 	not of the TLS ASN.1Cert object).
>>=20
>> For the full certificate, am I right that this format is the base64
>> encoding of the DER encoded certificate?  If so, can the section be
>> updated to state so?
>=20
> Let's be careful here. The bytes are not base64-encoded: the =
representation of those bytes are encoded in the record. The =
"certificate for association" is just the bytes themselves.
>=20
> As for the bytes of a PKIX certificate being DER encoded, that's =
already defined in the PKIX spec. If we put that here and someone adds a =
different certificate for association, such as a bare key (cough cough), =
then that bare key would need to be DER encoded; that may not be what =
the people writing those specs want. It is probably better to let the =
format of the bytes be defined in the other specs.
>=20
> --Paul Hoffman
>=20
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane


From [e-mail]  Sun Apr 10 18:10:39 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FAF33A6A30 for <[e-mail]>; Sun, 10 Apr 2011 18:10:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.139
X-Spam-Level: 
X-Spam-Status: No, score=-102.139 tagged_above=-999 required=5 tests=[AWL=0.460, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUPLu+tgmLpP for <[e-mail]>; Sun, 10 Apr 2011 18:10:35 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by core3.amsl.com (Postfix) with ESMTP id 928D73A6A29 for <[e-mail]>; Sun, 10 Apr 2011 18:10:34 -0700 (PDT)
Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p3B0w5Xp028050 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 10 Apr 2011 17:58:05 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Paul Hoffman <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Sun, 10 Apr 2011 17:58:04 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
To: "Richard L. Barnes" <[e-mail]>
X-Mailer: Apple Mail (2.1084)
Cc: [e-mail]
Subject: Re: [dane] Section 2.2 Certificate format question
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 11 Apr 2011 01:10:39 -0000

On Apr 10, 2011, at 5:21 PM, Richard L. Barnes wrote:

> Also, in the presentation format (Section 2.4), the place where it =
*might* make sense to Base64-encode, it says that the certificate is =
"presented in hex".  So, raw hex bytes, not Base64.
> <http://tools.ietf.org/html/draft-ietf-dane-protocol-06#section-2.4>
>=20

Whoops, Richard is right and my last response was wrong. There is no =
base64 encoding in the current spec. Sorry for that brain lapse.

--Paul Hoffman


From [e-mail]  Mon Apr 11 10:19:03 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57C703A6B30 for <[e-mail]>; Mon, 11 Apr 2011 10:19:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.572
X-Spam-Level: 
X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rqa94w93+Q8L for <[e-mail]>; Mon, 11 Apr 2011 10:19:02 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id CAC8F3A6B2F for <[e-mail]>; Mon, 11 Apr 2011 10:19:02 -0700 (PDT)
Received: from dhcp89-089-127.bbn.com ([128.89.89.127]:49164 helo=[128.89.89.213]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <[e-mail]>) id 1Q9KlS-000D9T-AF; Mon, 11 Apr 2011 13:19:02 -0400
Mime-Version: 1.0
Message-Id: <p06240808c9c8e5f26521@[128.89.89.213]>
In-Reply-To: <BANLkTin=[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>	<p06240805c9c25b23464a@128.89.89.213> <[e-mail]>	<p06240800c9c3e03a9624@128.89.89.213> <BANLkTin=[e-mail]>
Date: Mon, 11 Apr 2011 13:10:28 -0400
To: Ben Laurie <[e-mail]>
From: Stephen Kent <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 11 Apr 2011 17:19:03 -0000

At 11:14 AM +0100 4/8/11, Ben Laurie wrote:
>...
>  >
>>  It's not sudden :-). A self-signed cert is a CA cert, by definition (see
>>  the cites to RFC 5280 in Paul's I-D. The TLS spec talks in terms of an
>>  "end entity's cert" as representing a a server (or client). From a PKI
>>  perspective, the cert that represents a server or client MUST be an
>>  EE cert, an thus cannot be self-signed.  The fact that many implementations
>>  violate IETF PKI standards in this regard, is unfortunate, but it is not
>>  a basis for issuing a new IETF stanbdard that codifies this behavior.
>
>Isn't it? What is the argument against allowing a self-signed EE cert,
>other than spec lawyering?

You call it spec lawyering; I call it not having WG A contradict the
standards developed by WG B :-).  We've adhered to that model for a long
time. But, folks are free to ask the cognizant ADs.

Steve

From [e-mail]  Mon Apr 11 10:19:04 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 490233A6B30 for <[e-mail]>; Mon, 11 Apr 2011 10:19:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.572
X-Spam-Level: 
X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6PDaTiT+osV for <[e-mail]>; Mon, 11 Apr 2011 10:19:03 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id B755E3A6B2F for <[e-mail]>; Mon, 11 Apr 2011 10:19:03 -0700 (PDT)
Received: from dhcp89-089-127.bbn.com ([128.89.89.127]:49164 helo=[128.89.89.213]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <[e-mail]>) id 1Q9KlT-000D9T-EF; Mon, 11 Apr 2011 13:19:03 -0400
Mime-Version: 1.0
Message-Id: <p0624080ac9c8e725ad15@[128.89.89.213]>
In-Reply-To: <BANLkTi=mLJ4Ohr-=[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>	<p06240805c9c25b23464a@128.89.89.213> <[e-mail]>	<p06240800c9c3e03a9624@128.89.89.213> <BANLkTin=[e-mail]> <[e-mail]> <BANLkTi=mLJ4Ohr-=[e-mail]>
Date: Mon, 11 Apr 2011 13:13:53 -0400
To: Ben Laurie <[e-mail]>
From: Stephen Kent <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Cc: Paul Hoffman <[e-mail]>, [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 11 Apr 2011 17:19:04 -0000

At 1:46 PM +0100 4/8/11, Ben Laurie wrote:
>On 8 April 2011 13:33, Paul Hoffman <[e-mail]> wrote:
>>  I note, again, that this has *nothing* to do with use cases or 
>>requirements. Having said that...
>
>I've already stated my requirement (that self-signed certs should be usable).
>

and they are, as CA certs :-).

Steve

From [e-mail]  Mon Apr 11 10:21:58 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5B8928C152 for <[e-mail]>; Mon, 11 Apr 2011 10:21:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.573
X-Spam-Level: 
X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmBGoxLzV8LF for <[e-mail]>; Mon, 11 Apr 2011 10:21:58 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 2B00128C135 for <[e-mail]>; Mon, 11 Apr 2011 10:21:58 -0700 (PDT)
Received: from dhcp89-089-127.bbn.com ([128.89.89.127]:49165 helo=[128.89.89.213]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <[e-mail]>) id 1Q9KoG-000DBh-FW; Mon, 11 Apr 2011 13:21:56 -0400
Mime-Version: 1.0
Message-Id: <p06240807c9c8e4be1d0e@[128.89.89.213]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Mon, 11 Apr 2011 13:21:38 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 11 Apr 2011 17:21:59 -0000

At 4:58 AM +0200 4/8/11, Martin Rex wrote:
>Stephen Kent wrote:
>>
>>  James Cloos wrote:
>>  >
>>  >EE certs in the rr is in all of the drafts, was the original target, is
>>  >easy to understand and explain, and I've read more consensus for than
>>  >against on the list.
>>  >
>>  >Why the sudden backlash against?
>>
>>  It's not sudden :-). A self-signed cert is a CA cert, by definition (see
>>  the cites to RFC 5280 in Paul's I-D.
>
>RFC 5280 is about X.509v3 certs _ONLY_.

agreed.

>There is NO problem creating X.509v1 End-Entity certs that are self-signed.
>And there is no problem using any of these with implementations of
>SSLv3 and TLSv1.0.

you have provided enough examples to convince me of that :-).

>SSLv3 predates IETF PKIX standards, and TLSv1.0 is related to
>rfc-2459 rather than rfc-5280 -- but implementations of TLSv1.0
>were often shipped before publication of TLSv1.0 (rfc-2246) and
>the original PKIX certificate profile (rfc-2459).

so?

>For safety, it would be sensible to ALWAYS treat X.509v1 certs as
>EndEntity certs (i.e. never accept them as signer of other certs).
>Our TLS implementation had done this initially, but we had a customer
>that had obtained server certs issued under a VeriSign X.509v1 CA cert
>(as late as 2006!), so I had to make our OEM implementation tolerate this.

The fact that v1 certs contained no mechanism to distinguish between
an EE cert and a CA cert was a major vulnerability, one that has been
exploited in the browser context. I doubt that the IESG will approve
an RFC that calls for supporting v1 certs at this time.

Steve

From [e-mail]  Mon Apr 11 10:45:52 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13B103A6946 for <[e-mail]>; Mon, 11 Apr 2011 10:45:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.573
X-Spam-Level: 
X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ximR8cpCFmLy for <[e-mail]>; Mon, 11 Apr 2011 10:45:51 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 6F6333A6916 for <[e-mail]>; Mon, 11 Apr 2011 10:45:51 -0700 (PDT)
Received: from dhcp89-089-127.bbn.com ([128.89.89.127]:49166 helo=[128.89.89.213]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <[e-mail]>) id 1Q9LBP-000DVo-KG; Mon, 11 Apr 2011 13:45:51 -0400
Mime-Version: 1.0
Message-Id: <p06240802c9c22fe5410c@[128.89.89.213]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Mon, 11 Apr 2011 13:22:07 -0400
To: James Cloos <[e-mail]>
From: Stephen Kent <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Cc: Paul Hoffman <[e-mail]>, [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 11 Apr 2011 17:45:52 -0000

At 6:22 PM -0400 4/5/11, James Cloos wrote:
>...
>
>For those of us who understand how it works and for those who employ
>someone who understands how it works, case 3 has some benefits.
>
>But more most people case 4 is better.

If, as some have said, many (most?) folks use a simple script to 
invoke OpenSSL to generate a self-signed cert, can't we provide a new 
script to address this
issue?

Steve

From [e-mail]  Mon Apr 11 11:50:00 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 786863A6B2B for <[e-mail]>; Mon, 11 Apr 2011 11:50:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -93.104
X-Spam-Level: 
X-Spam-Status: No, score=-93.104 tagged_above=-999 required=5 tests=[AWL=-9.505, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, URIBL_BLACK=20, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNT4qn0LB5oF for <[e-mail]>; Mon, 11 Apr 2011 11:49:58 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 005053A6B08 for <[e-mail]>; Mon, 11 Apr 2011 11:49:57 -0700 (PDT)
Received: by wyb29 with SMTP id 29so5590288wyb.31 for <[e-mail]>; Mon, 11 Apr 2011 11:49:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=tTps8xfkE8C5QOzsT3d8s1gFQ994IYa2bsqVdsCQqYc=; b=Gc916bZfkO9+ux1zyYlhqqNncKBhNSWpUbpps0dpo9dtc35nOpE0JEltwZJLUp2HEj 3myGy25JpNGqZswTg+3R7JKlW4a8pWPSSmzDhNWXf80v6irwRyD4W9lWaXcXz/g5VIwv D8RUE6gz+Je4mJ/o3krz1gY6yWVDlTQaGP3GY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=VFSogKRj5Llcnk+CrqY/13BaCkmKjS7xdG4R8OILIBNk4w8sDLMWSI36Ap1CFVyZRh dA7TSQmkyVcTSyl8qaP0ka7p5C2bdxfga/ZLS89k/w9Ra3VGvNIiCI35e86S4KRHNerq N3zo0xW3hEfegUvdIXeFtySZ7RSugvz16WrG4=
MIME-Version: 1.0
Received: by 10.216.195.139 with SMTP id p11mr5136881wen.67.1302547797787; Mon, 11 Apr 2011 11:49:57 -0700 (PDT)
Sender: [e-mail]
Received: by 10.216.50.211 with HTTP; Mon, 11 Apr 2011 11:49:57 -0700 (PDT)
In-Reply-To: <BANLkTinpPyB=[e-mail]>
References: <[e-mail]> <BANLkTimGmtOS0=KbaChb=5F=K=[e-mail]> <BANLkTinpPyB=[e-mail]>
Date: Mon, 11 Apr 2011 20:49:57 +0200
X-Google-Sender-Auth: ZZNVDxr8J3wOx6Vd3sThDk5MzfA
Message-ID: <BANLkTinqS_Z0MfySDr=[e-mail]>
From: Christopher Morrow <[e-mail]>
To: [e-mail]
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: [e-mail]
Subject: Re: [dane] Use Cases Document
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 11 Apr 2011 18:50:00 -0000

On Mon, Apr 11, 2011 at 6:21 PM, Kirk Hall <[e-mail]> wrote:
> Chris =96 thanks for your response.=A0 A few comments.
>
>
>
> 1.=A0 What you call =93comodogate=94 was an extreme rarity for the CA ind=
ustry,
> and shouldn=92t have happened.=A0 If we have the correct story, someone o=
utside

absolutely it shouldn't have happened. it's probably the 3rd or fourth
thing that 'shouldn't have happened' to comodo... related to security
and the security of their downstream dependents.

> the external RA was able to gain access to the RA=92s cert issuance syste=
m
> remotely, and then was able to use the RA=92s system to access the CA=92s=
 cert
> issuance system remotely and order issuance of the fake certs.=A0 I=92m n=
ot
> aware of anything like this ever happening to a CA before, and it would h=
ave
> been easy to prevent this breach with basic systems security.

I'm not sure you'd (*or anyone would) know if this was going on
though. it only became 'known' because the alleged/admitted third
party bragged about his actions, in detail. It's interesting that
comodo was supposed (as i understand it) to be checking to be sure
that the didn't re-issue an already known cert to a third-party NOT
the owner of the trademark/domain/etc. It's fairly telling that we
find out about this via the 'hacker' making it very publicly known.
How many times did this happen before from the same RA? or the same
set of dependent RAs?

At this point, anyone depending on this being the only case of this..
is living in a fantasy land.

> In my mind it=92s a mistake to interpret the incident as demonstrating ma=
jor
> vulnerability for the CA industry as a whole.=A0 As an example, if one da=
y
> Wells Fargo Bank=92s international wire service system is breached and
> accessed remotely by an intruder, and the intruder then sends unauthorize=
d
> wire transfers to Nigerian bank accounts before being caught, that would =
be
> a fairly uninteresting case of basic data system security breach, and wou=
ld

different and not related issues above skipped.

> not imply that the entire banking system for international wire transfers
> was in jeopardy or need of overhaul.=A0 Likewise, if a DNS operator=92s s=
ystem
> is breached remotely in a similar fashion, I assume an intruder could pla=
y
> games with the self-signed certificates that have been associated with a

I don't think that's a fair assumption at all. Ideally, in any sane
dnssec secured system the 'domain owner' has the private keys required
to sign his/her/their zone data. If I host my zone on your server(s)
and you are compromised, worst case my zone goes invalid and .. .I
scramble for a provider who's less compromised.

> domain under the DANE proposal =96 but that wouldn=92t weaken DANE.=A0 So=
 in all
> cases, basic security systems are essential.

The basic problem as i see it with the in-place cert/ca system is that
my security (as a customer and a server) is reliant upon a mess of
folks with whom I have very little faith or ability-to-have-faith in.
There exist today systems that will man-in-the-middle SSL connections
making certs appear (that are valid because they are signed by an
in-browser/client ca-store) and be invisible to both sides of the
connection. (see mallory proxy, for a software-only solution). There
are folks that use systems like this to degrade the security of
clients/servers in the field, today.

I don't think we want this situation to exist, I think we want to aim
for the best possible security position for our customers (clients and
servers). This means we need another method than the current CA-store
system to verify that a certificate is valid, one not dependent upon
the CA-store/chain.

> 2.=A0 From your comments it seems you view the association of certs
> (self-signed or from a CA) with a domain under the DANE proposal as
> completely agnostic and mechanical =96 the DNS operator should accept
> literally any cert offered by the domain owner =96 so that DANE a
> technological standard with no implications for =93trust=94 as generally
> associated with digital certificates today.

My feeling is that folks do today, and will tomorrow, own their own
DNS infrastructure. In what I think your terminology is: "They are
both the DOMAIN OWNER and the DNS OPERATOR". Today some folks (domain
owners) outsource their DNS services to third-parties (dns operators),
it's not clear that they need to (or even are) giving their dnssec key
materials to the dns operator though.

Additionally, I'd bet that in many cases the dns operators have a
business relationship (ongoing, monthly recurring costs) with the
domain owners, they ought to be able to tell if the person asking for
a domain to exist own the domain. (they got the NS records pointed
from SLD -> 3rdLD afterall)

> That=92s fine if everyone understands that.=A0 However, it then raises th=
e
> question of utility of the DANE proposal once implemented.=A0 If a known
> phishing domain (see the APWG solutions list at
> http://www.antiphishing.org/solutions.html), or a likely new fraudster wh=
o
> registers an available look-alike domain such as
> your-account-bankofamerica.com or google-accounts.com can then attach a
> self-signed cert to the domain at the DNS level (including fake Organizat=
ion
> information, etc. inserted inside the self-signed cert), and if consumers
> visiting that domain are automatically put into secure encrypted mode wit=
h
> the site with no checking against an OCSP or CRL =85=A0 and if that secur=
e
> domain is given the same favorable UI or other treatment by browsers and
> applications indicating secure mode or domain confirmation as for all oth=
er
> sites =85=A0 then won=92t the public come to see the DANE solution as ins=
ecure and
> untrustworthy?

DANE is not here to help/hurt phishers. SSL doesn't factor into
phishing at all... please stop conflating phishing and SSL/TLS.

DANE is about knowing that your TLS connection to a service is to the
service it intended to connect to... www.bobs-balloons.com on port 443
sent me a cert, I can verify that the destination server's certificate
is the one bobs-balloons created/signed/installed.

> Meaning if there is no way under DANE for a consumer to distinguish betwe=
en
> legitimate sites associated with a self-signed cert and fraudulent sites
> (i.e., those domains already tagged for phishing, or look-alike domains t=
hat
> would be rejected by a CA for a DV cert), what advantage does a consumer

like the one signed by the compromised RA in the comodogate incident?
yea... that fix action worked out well there. Again, phishing isn't in
the purview of DANE, you can't solve the phishing problem... in the
last 15+ years the existing oligarchy of CA folk haven't solved it
(because the two items are not related).

> gain from DANE?=A0 Why not just use self-signed certs today, and ask the
> browsers to stop showing the =93Warning =96 cert comes from an unknown /
> untrusted root=94 display?

this doesn't show the user that the cert delivered over the wire to
the client was in fact the cert that the service-owner installed. the
current CA system doesn't do this either, DANE has a better hope of
doing this, i think.

> 3.=A0 There is a potential solution to this problem.=A0 I know some on th=
is list
> want to get away from having to use a CA, and there=92s a way to do that =
and
> keep DANE useful.

s/'get away from having a CA'/'get away from the trust dependency upon CAs'=
/

less places for risk to inject themselves.

> On some earlier draft list of DANE specifications, I think two basic DANE
> cert categories were proposed: 1=3Dself signed, and 2=3DCA issued.=A0 Why=
 not add
> a third specification: 3=3Dself signed/fraud checked.

because 'fraud checked' means nothing wrt the purpose of DANE?
True/False: "this certificate presented to me is the one the service
owner installed"

> Category =933=94 would be for self-signed certs that have been run throug=
h
> anti-fraud checking by an independent third party like what is done today
> for DV certs (e.g., compare the domain against APWG phishing lists, rejec=
t
> look-alike domains like paypall.com unless the real paypal.com proves
> ownership).=A0 The checking could be done by the DNS operators or someone=
 else
> independent of the domain owner following an industry-standard set of
> anti-fraud criteria =96 but the certs would NOT have to be chained to a C=
A.
> Once checked, the self-signed certs would get a favorable flag (=933=94) =
so that
> browsers, applications, and consumers could choose to trust them, but not
> trust self-signed certs that were not checked against fraud (Category =93=
1=94
> certs).=A0 Or, the user could choose to trust all kinds of certs if the u=
ser
> is not concerned about dealing with fraudulent domains.

it occurs to me that you ought to take this portion of the discussion
to the DNS heirarchy folks (ICANN and their downstream dependents for
DNS zone purchase) The problem you seek to solve has nothing to do
with certificates, and everything to do with DNS.

If you can't sign up for the domain: bank-of-america-auth-stealers.com
... you can't put the DANE cert into the zone.

> the padlock, etc.).=A0 Those DNS operators would no doubt be embarrassed =
to be
> giving known and reported phishing domains and look-alike domains the sam=
e
> DANE treatment as legitimate domains.

this doesn't seem to be a factor today.

> To be clear, under this proposal for DANE implementation ALL self-signed
> certs would be accepted for association with a domain, but they would be
> marked as either being checked using anti-fraud algorithms, or not being

you seem to be backdooring into the UI discussion, which isn't in
scope and isn't relevant.

> checked, so that later applications and consumers could decide if they
> wanted to trust all self-signed certs, or only a subset.=A0 Differentiati=
ng
> certs in this way would mean that DANE is actually useful, and might be

DANE is useful as soon as I can tell that the certificate I'm
presented with is in fact the certificate that the service owner
installed for their service.

> Do you view this as a feasible solution?=A0 Should we add this to the dra=
ft
> specifications?

I think walking down the discussion of fraud and phishing is entirely
the wrong path for DANE to go. DANE, nor CA's really, can not hope to
solve the fraud/phishing problem.

For grins: (http urls sent in spam today so far)
morrowc@fire:/prod/archive/2011/04$ grep http:// 11/*.txt | wc -l
392951

HTTPS
morrowc@fire:/prod/archive/2011/04$ grep https:// 11/*.txt | wc -l
65
(oddly mostly for: sears.r4sys.net which ends up bouncing properly through =
to:
Location: http://www.sears.com/shc/s/v_10153_12605_Tools?lid=3Dtool_header&=
rioptype=3DSC&sid=3DIOx20110411SRSBAUALTSA2MMS80&eml=3D52379066&ruid=3D1003=
337
[following]
   so this is incidental https in something, not a phishing attempt)

I make the ssl-use-in-phishing at a number small enough that DANE
again shouldn't target this as a goal to solve.

-Chris

(in a related qestion, why doesn't affirmtrust use SSL on their forms?
http://www.affirmtrust.com/free-ssl-sign-up.html)

> On Sun, Apr 10, 2011 at 7:54 AM, Christopher Morrow
> <[e-mail]> wrote:
>>
>> On Fri, Apr 8, 2011 at 7:36 PM, Kirk Hall <[e-mail]> wrote:
>> >
>> > (1) CAs review DV cert requests for =93high risk=94 organization and d=
omain
>> > names that are most commonly targeted in phishing and other fraudulent
>> > schemes, and reject those cert requests.=A0 These lists include (a)
>> > internal
>>
>> <insert comodogate here>
>>
>> > Does DANE contemplate that the DNS operators would also reject domain
>>
>> I think, from my brief reading, the 'dns operator' here is ... the
>> owner of the domain. So, 'stolen-bank-of-america-credentials.com' if
>> owned by 'evil person' could certainly publish a cert record for the
>> self-signed cert on their website stealing credentials from naive
>> users.
>>
>> how many folks really get phished/etc over ssl connections today? (not
>> many, if any, ssl isn't a factor in this problem space)
>>
>> >
>> > (2) CAs also employ other anti-fraud algorithms of their own against b=
ad
>> > DV
>>
>> <insert comodogate here>
>>
>> > Do you contemplate that DNS operators would do anything similar for
>> > self-signed certs?
>>
>> why would they? they are putting records into their own zone... if
>> somone they don't know/trust can make changes to their DNSSEC signed
>> DNS data... they are sunk anyway.
>>
>> > (3) DV certs have a clear chain of liability back to the issuing CA. T=
he
>> > CAs
>> > today do a pretty good job in preventing high risk similar-named
>> > domains,
>> > like =93paypall.com=94,=A0 from getting certs for fraud and phishing p=
urposes.
>>
>> <insert comodogate here>
>>
>> > Under DANE, if a self-signed certificate issued in the name of
>> > =93paypall.com=94
>> > is accepted by a DNS operator and is used in phishing attacks, who wou=
ld
>> > be
>>
>> the person that owns paypall.com can certainly make a self-signed
>> cert... and put the appropriate record into the dns zone they own, and
>> sign it with the key they have... this isn't significantly different
>> than where we are today.
>>
>> > (5) Bad certs can be revoked, and the industry is working very hard
>> > right
>> > now on improving the revocation process.
>>
>> by completely sidestepping it? (let's hardcode certs into binaries,
>> because .. oscp is an admitted failure)
>>
>> > If there is a =93bad=94 self-signed cert associated with a domain by a=
 DNS
>> > operator and/or a DNS operator receives a report of fraud or phishing
>> > associated with a domain, will DANE have a way to remove, revoke, or
>> > otherwise flag the cert as =93bad=94?
>>
>> sure, remove the record from dns (in the zone that publishes it)
>>
>> -chris
>
>

From [e-mail]  Mon Apr 11 11:55:31 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF7623A6A5C for <[e-mail]>; Mon, 11 Apr 2011 11:55:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.974
X-Spam-Level: 
X-Spam-Status: No, score=-2.974 tagged_above=-999 required=5 tests=[AWL=-0.376, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SjproyNz6SIp for <[e-mail]>; Mon, 11 Apr 2011 11:55:30 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 757A43A6A47 for <[e-mail]>; Mon, 11 Apr 2011 11:55:30 -0700 (PDT)
Received: by vxg33 with SMTP id 33so5441342vxg.31 for <[e-mail]>; Mon, 11 Apr 2011 11:55:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8SQmhFx3H3G6zZ/Ph48Wl04IJH7Fwh7fox2Rc/HRF4Y=; b=auur8m0cVt36uYKAURhyJGxf2NFFVfUeIdBKpMH3G4ApdmxoDXLm45hiYMp7LtcfZt Ffe8QdepO3LBmNAz2wbrgW5RMt70jJAKau7ThWyUdjz47ZSEHMwHnbRNT3eQbJrVmNSi PD6nKZ/3AXMISpOvK2wSVqH6GZqAnErVvlFdg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=WemrSScaNjCr9ZT9JWpOfKnMVQ2m3LpOy5wX4eYFWICCqjE7BcWfxMBgKjHMFglpc8 yFikzhNEo83JzdCHx4rrXOZlqmEwYQY12k6cHJeaMZCKV+DVyZpUnVpQ/U2D+AqIOdfB UjCzHrQ5D4LLds+DoN5Vk4GZkNmT5gv8Myl8s=
MIME-Version: 1.0
Received: by 10.52.175.5 with SMTP id bw5mr2631721vdc.69.1302548128144; Mon, 11 Apr 2011 11:55:28 -0700 (PDT)
Received: by 10.52.166.230 with HTTP; Mon, 11 Apr 2011 11:55:27 -0700 (PDT)
In-Reply-To: <p06240802c9c22fe5410c@128.89.89.213>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <p06240802c9c22fe5410c@128.89.89.213>
Date: Mon, 11 Apr 2011 14:55:27 -0400
Message-ID: <[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: Stephen Kent <[e-mail]>
Content-Type: multipart/alternative; boundary=20cf3071cebc7b1dae04a0a91ed5
Cc: Paul Hoffman <[e-mail]>, [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 11 Apr 2011 18:55:31 -0000

--20cf3071cebc7b1dae04a0a91ed5
Content-Type: text/plain; charset=ISO-8859-1

We don't seem capable of deferring discussion on the details of
implementation until after the use cases[1]. So writing a script is quite
probably too much to expect.

This problem is very easily solved: DANE needs say nothing about the issue
at all. Just cite PKIX and move on.


Everyone will get the outcome they care about. DANE will be compatible with
PKIX and the code will recognize self-signed EE certs just like every other
bit of SSL/TLS infrastructure does.


[1] No, calling a demand for a very specific implementation detail a 'use
case' does not make it one. A use case would be 'Alice wants to use the same
tool to generate her certs' or 'Alice wants to be able to credential the
certs already used on the server' or 'Alice wants the web server to work for
Bob and Carol who have old and new browsers respectively.

There are plenty of ways that this could be expressed as a use case, the
ones adopted are not use cases.

On Mon, Apr 11, 2011 at 1:22 PM, Stephen Kent <[e-mail]> wrote:

> At 6:22 PM -0400 4/5/11, James Cloos wrote:
>
>> ...
>>
>>
>> For those of us who understand how it works and for those who employ
>> someone who understands how it works, case 3 has some benefits.
>>
>> But more most people case 4 is better.
>>
>
> If, as some have said, many (most?) folks use a simple script to invoke
> OpenSSL to generate a self-signed cert, can't we provide a new script to
> address this
> issue?
>
> Steve
>
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane
>



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

--20cf3071cebc7b1dae04a0a91ed5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

We don&#39;t seem capable of deferring discussion on the details of impleme=
ntation until after the use cases[1]. So writing a script is quite probably=
 too much to expect.<div><br></div><div>This problem is very easily solved:=
 DANE needs say nothing about the issue at all. Just cite PKIX and move on.=
</div>
<div><br></div><div><br></div><div>Everyone will get the outcome they care =
about. DANE will be compatible with PKIX and the code will recognize self-s=
igned EE certs just like every other bit of SSL/TLS infrastructure does.</d=
iv>
<div><br></div><div><br></div><div>[1] No, calling a demand for a very spec=
ific implementation detail a &#39;use case&#39; does not make it one. A use=
 case would be &#39;Alice wants to use the same tool to generate her certs&=
#39; or &#39;Alice wants to be able to credential the certs already used on=
 the server&#39; or &#39;Alice wants the web server to work for Bob and Car=
ol who have old and new browsers respectively.</div>
<div><br></div><div>There are plenty of ways that this could be expressed a=
s a use case, the ones adopted are not use cases.</div><div><br><div class=
=3D"gmail_quote">On Mon, Apr 11, 2011 at 1:22 PM, Stephen Kent <span dir=3D=
"ltr">&lt;<a href=3D"mailto:[e-mail]">[e-mail]</a>&gt;</span> wrote=
:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;">At 6:22 PM -0400 4/5/11, James Cloos wrote:=
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
...<div class=3D"im"><br>
<br>
For those of us who understand how it works and for those who employ<br>
someone who understands how it works, case 3 has some benefits.<br>
<br>
But more most people case 4 is better.<br>
</div></blockquote>
<br>
If, as some have said, many (most?) folks use a simple script to invoke Ope=
nSSL to generate a self-signed cert, can&#39;t we provide a new script to a=
ddress this<br>
issue?<br>
<br>
Steve<div><div></div><div class=3D"h5"><br>
_______________________________________________<br>
dane mailing list<br>
<a href=3D"mailto:[e-mail]" target=3D"_blank">[e-mail]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/dane</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a=
 href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--20cf3071cebc7b1dae04a0a91ed5--

From [e-mail]  Mon Apr 11 12:11:49 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D1E63A69BD for <[e-mail]>; Mon, 11 Apr 2011 12:11:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.971
X-Spam-Level: 
X-Spam-Status: No, score=-2.971 tagged_above=-999 required=5 tests=[AWL=-0.373, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NP6b8o5psgUA for <[e-mail]>; Mon, 11 Apr 2011 12:11:48 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id CAF6D3A6AFE for <[e-mail]>; Mon, 11 Apr 2011 12:11:47 -0700 (PDT)
Received: by vxg33 with SMTP id 33so5457644vxg.31 for <[e-mail]>; Mon, 11 Apr 2011 12:11:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=hPmuhmOHym+Zflj5bTDQtxgNaAIrwY2dHgeibH/Ynm8=; b=D/qEnOwuItlot2aNb6nokRpot3qpDiBO8D+246+21sPCfOSV4SN0CbmxLdCbCzstWa wEnzbXoLoNRxda8VJmKi1jNgek9DcCycalXsfUyMr/yzbQy7FAvtAh0q4fiFSjhZErck Bf2OMvaNzruQq/T77oOxKhj+L65nv4wAoWq8o=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=xXkP+Lg+qRwY3G5sT0q4uXgGTiFtTdB5RJroXR8XNyBlcC2BPc6nJuvAipvqbpEt69 p/NNCNHpKXHJm3BR+5OzpKluAAKh/rd6p7ajYbS2HKLTHh8tqKcEXtamgZg7omjwUsAT o838LA2+ILVBKSjzxIMPiXsrw/Gs1sVnu5f4s=
MIME-Version: 1.0
Received: by 10.52.18.11 with SMTP id s11mr37685vdd.269.1302549108102; Mon, 11 Apr 2011 12:11:48 -0700 (PDT)
Received: by 10.52.166.230 with HTTP; Mon, 11 Apr 2011 12:11:48 -0700 (PDT)
In-Reply-To: <BANLkTinqS_Z0MfySDr=[e-mail]>
References: <[e-mail]> <BANLkTimGmtOS0=KbaChb=5F=K=[e-mail]> <BANLkTinpPyB=[e-mail]> <BANLkTinqS_Z0MfySDr=[e-mail]>
Date: Mon, 11 Apr 2011 15:11:48 -0400
Message-ID: <[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: Christopher Morrow <[e-mail]>
Content-Type: multipart/alternative; boundary=20cf3054a113e415c604a0a95832
Cc: [e-mail], [e-mail]
Subject: Re: [dane] Use Cases Document
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 11 Apr 2011 19:11:49 -0000

--20cf3054a113e415c604a0a95832
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Apr 11, 2011 at 2:49 PM, Christopher Morrow <[e-mail]
> wrote:

>
> I'm not sure you'd (*or anyone would) know if this was going on
> though. it only became 'known' because the alleged/admitted third
> party bragged about his actions, in detail.


No, this is an untrue accusation and must be withdrawn.

The notification of the RA breach incident was made through the normal
process and the timing of the release of the information to the public was
gated on the time taken to roll patches by the major browser providers.



And I am somewhat sick of this approach where one side in a dispute thinks
that it is OK to make unfounded accusations, engage in political hyperbole
(-gate) and rely on false claims while it is somehow improper for the side
they are attacking to make a rebuttal.

Either both sides of this argument are off topic, or both are.



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

--20cf3054a113e415c604a0a95832
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Mon, Apr 11, 2011 at 2:49 PM, Christo=
pher Morrow <span dir=3D"ltr">&lt;<a href=3D"mailto:[e-mail]=
">[e-mail]</a>&gt;</span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex;">
<br>
I&#39;m not sure you&#39;d (*or anyone would) know if this was going on<br>
though. it only became &#39;known&#39; because the alleged/admitted third<b=
r>
party bragged about his actions, in detail.</blockquote><div><br></div><div=
>No, this is an untrue accusation and must be withdrawn.</div><div><br></di=
v><div>The notification of the RA breach incident was made through the norm=
al process and the timing of the release of the information to the public w=
as gated on the time taken to roll patches by the major browser providers.=
=A0</div>
<div><br></div><div><br></div><div><br></div><div>And I am somewhat sick of=
 this approach where one side in a dispute thinks that it is OK to make unf=
ounded accusations, engage in political hyperbole (-gate) and rely on false=
 claims while it is somehow improper for the side they are attacking to mak=
e a rebuttal.</div>
<div><br></div><div>Either both sides of this argument are off topic, or bo=
th are.</div><div><br></div><div><br></div></div><br>-- <br>Website: <a hre=
f=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>

--20cf3054a113e415c604a0a95832--

From [e-mail]  Mon Apr 11 15:25:23 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 262AFE06B0 for <[e-mail]>; Mon, 11 Apr 2011 15:25:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level: 
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ql8EFMJEA6KN for <[e-mail]>; Mon, 11 Apr 2011 15:25:21 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfc.amsl.com (Postfix) with ESMTP id 735D2E06A3 for <[e-mail]>; Mon, 11 Apr 2011 15:25:09 -0700 (PDT)
Received: by wwa36 with SMTP id 36so5007977wwa.13 for <[e-mail]>; Mon, 11 Apr 2011 15:25:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=xHW+y+Dz8JUb2XTEY9wjrjH2fDLCSxLq/gtL+YvoU94=; b=QviOrnxfnxG2i+SxwG1z3pvJVr7DL9ieTujg/u0pU8DipYUTYTWYaHS0etXpbzL4RC oa1ioVaRHCB1fsgwBWGegmLlwUsTp+sL47tY2zPzm0I5eAyPEGvW+jpXhBoyDVm0XQCf CkNtbsIHJLTXAa1kCiCXy8YrEpo/frhzOoCWM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=MomblpvCU9qL/6XWClEmaZR9WXKERaCQQECy/oBE+SNZRDKTzFqx1d3HwoGmgQfIXJ OAXA/sxiIkrPemYOCswDfsavNK4wPqS4gPxzMi3HMJwq1m1gf40LqeBN3S4FesXzU7Ll N2q89qzcW1RxksSER/AQy7kCR7ZpedbEGgnwI=
MIME-Version: 1.0
Received: by 10.216.195.139 with SMTP id p11mr5199478wen.67.1302551373720; Mon, 11 Apr 2011 12:49:33 -0700 (PDT)
Sender: [e-mail]
Received: by 10.216.50.211 with HTTP; Mon, 11 Apr 2011 12:49:33 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <BANLkTimGmtOS0=KbaChb=5F=K=[e-mail]> <BANLkTinpPyB=[e-mail]> <BANLkTinqS_Z0MfySDr=[e-mail]> <[e-mail]>
Date: Mon, 11 Apr 2011 21:49:33 +0200
X-Google-Sender-Auth: pouPxjkOnnXn1iIT1n6FpTT7i0A
Message-ID: <[e-mail]>
From: Christopher Morrow <[e-mail]>
To: Phillip Hallam-Baker <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Cc: [e-mail], [e-mail]
Subject: Re: [dane] Use Cases Document
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 11 Apr 2011 22:25:23 -0000

On Mon, Apr 11, 2011 at 9:11 PM, Phillip Hallam-Baker <[e-mail]> wrote:
>
>
> On Mon, Apr 11, 2011 at 2:49 PM, Christopher Morrow
> <[e-mail]> wrote:
>>
>> I'm not sure you'd (*or anyone would) know if this was going on
>> though. it only became 'known' because the alleged/admitted third
>> party bragged about his actions, in detail.
>
> No, this is an untrue accusation and must be withdrawn.

pardon? the young man who put out the info did so long before the
browser patches arrived. he even had the private keys and certs, I
believe, available before patches hit for browsers.

> And I am somewhat sick of this approach where one side in a dispute thinks
> that it is OK to make unfounded accusations, engage in political hyperbole
> (-gate) and rely on false claims while it is somehow improper for the side

I could refer to verizonbusiness's method of sending downstream folks
signing certs from their root... though the meta point is that you
can't trust the CA infrastructure today, if you are a client or a
server. (comodo gave out certs signed to not-the-proper-owner(s),
verizonbusiness/cybertrust/b-trusted/baltimore-security released a
signing cert to a downstream who can now sign a cert for anyone)

it doesn't really matter, the whole kit and kaboodle is out of scope
for what we ought to be doing with DANE.

> Either both sides of this argument are off topic, or both are.

I would say that the only item on topic is how to get to the 2 parties
involved in a TLS conversation assurance that they are talking to the
right endpoints, and that their conversation is confidential.

thanks!
-chris

From [e-mail]  Mon Apr 11 15:30:42 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0CABFE0669 for <[e-mail]>; Mon, 11 Apr 2011 15:30:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.099
X-Spam-Level: 
X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=-0.501, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55XfHIfqQHdj for <[e-mail]>; Mon, 11 Apr 2011 15:30:40 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfc.amsl.com (Postfix) with ESMTP id 4B2D3E06B0 for <[e-mail]>; Mon, 11 Apr 2011 15:30:40 -0700 (PDT)
Received: from dhcp89-089-127.bbn.com ([128.89.89.127]:49171 helo=[128.89.89.213]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <[e-mail]>) id 1Q9NAJ-000FkW-3z; Mon, 11 Apr 2011 15:52:51 -0400
Mime-Version: 1.0
Message-Id: <p0624080bc9c8e967349b@[128.89.89.213]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>	<[e-mail]> <BANLkTinOTTWSbHcGCTFN=[e-mail]> <[e-mail]>
Date: Mon, 11 Apr 2011 15:47:59 -0400
To: Stephen Farrell <[e-mail]>
From: Stephen Kent <[e-mail]>
Content-Type: multipart/alternative; boundary="============_-909570926==_ma============"
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 11 Apr 2011 22:30:42 -0000

--============_-909570926==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 2:49 PM +0100 4/8/11, Stephen Farrell wrote:
>...
>
>5280 is IMO properly silent on how EEs might use self-signed
>certs. (Or if not, I've forgotten what it says on that;-)


I'll help with a few cites from 5280:

>3.2:
>
>This specification covers two classes of certificates: CA 
>certificates and end entity certificates.  CA certificates may be 
>further divided into three classes: cross-certificates, self-issued 
>certificates, and self-signed certificates.  Cross-certificates are 
>CA certificates in which the issuer and subject are different 
>entities.  Cross-certificates describe a trust relationship between 
>the two CAs.  Self-issued certificates are CA certificates in which 
>the issuer and subject are the same entity.  Self-issued 
>certificates are generated to support changes in policy or 
>operations.  Self-signed certificates are self-issued certificates 
>where the digital signature may be verified by the public key bound 
>into the certificate.  Self-signed certificates are used to convey a 
>public key for use to begin certification paths.  End entity 
>certificates are issued to subjects that are not authorized to issue 
>certificates.

This text says that a self-signed certificate is a CA certificate, 
period. The last sentence says that an EE certificate cannot be used 
to verify a signature on another certificate, and thus it is not a CA 
certificate, and thus, not self-signed.

>4.2.1.1 (AKI)
>
>The keyIdentifier field of the authorityKeyIdentifier extension MUST 
>be included in all certificates generated by conforming CAs to 
>facilitate certification path construction.  There is one exception; 
>where a CA distributes its public key in the form of a "self-signed" 
>certificate, the authority key identifier MAY be omitted.

This text says further reiterates the notion that a self-signed 
certificate is not an EE certificate. Note that in this text the 
exception discusses the context where a CA distributes its public key 
via a self-signed certificate, i.e., where the self-signed 
certificate is used as a container to distribute a trust anchor. This 
is the relevant case for DANE.

>4.2.1.3 (KU)
>
>The keyCertSign bit is asserted when the subject public key is  used 
>for verifying signatures on public key certificates.  If the 
>keyCertSign bit is asserted, then the cA bit in the basic 
>constraints extension (Section 4.2.1.9) MUST also be asserted.
>
>If the keyUsage extension is present, then the subject public key 
>MUST NOT be used to verify signatures on certificates or CRLs unless 
>the corresponding keyCertSign or cRLSign bit is set.

This text says that a valid CA certificate MUST contain the basic 
constraints extension with the CA flag set TRUE, thus 5280 requires 
CA certificates to be v3. It also establishes required values for key 
usage extension flags if the certificate is to be used to verify 
signatures on other certificates, i.e., if the certificate is to be 
used as a CA certificate.

>4.2.1.9 (Basic Constraints):
>
>The basic constraints extension identifies whether the subject of 
>the certificate is a CA and the maximum depth of valid certification 
>paths that include this certificate.
>
>Conforming CAs MUST include this extension in all CA certificates 
>that contain public keys used to validate digital signatures on 
>certificates and MUST mark the extension as critical in such 
>certificates.

Again, 5280 says that a CA certificate is a v3 certificate.

>
>>  This may be true in theory, but is far from true in practice - in
>>  practice, I can put a self-signed cert on my website and it works just
>>  fine (in the sense that it is not considered malformed, just rather
>>  untrustworthy).
>>
>>  So, this is just spec lawyering.
>
>Some data: both SIP (rfc3261) and S/MIME (rfc5750) explicitly
>allow self-signed certs. SDP/TLS (rfc4572) seems to have an
>entire section about them. And of course TLS (rfc5246) says
>you MAY include them.

I looked at the 4 cites you provided above.  Only two of them support 
your conclusion that it's OK to call for using an SS cert as an EE 
cert.

When I scan 5246 I find one reference to a self-signed cert (page 48).
That text is talking about a "root certificate [sic] authority." So that
reference is NOT talking about SS certs as EE certs.

RFC 5750 appears to contain two references to self-signed certs (page 8)
and both refer to CA certs, not to EE certs. So, again, this 
reference is NOT talking about SS certs as EE certs.

RFC 4572 makes a number of references to SS certs, and it does
envision using them as EE certs. However, the security analysis for using
SS certs here is flawed. For example it says (page 9) that it's OK to
use a SS cert to assert ANY identity in the TLS session or in an 
S/MIME-protected SDP exchange. In the name of interoperability, the 
RFC also says (page 9) that if hop-by-hop integrity is employed for 
SDP, then an SS cert is OK too, even though this allows any SDP 
entity along the path to spoof any other entity. I can't take too 
seriously an endorsement of misuse of SS certs as EE certs in this 
brief
document, given the rest of the bad security analysis.

RFC 3261 has references to SS certs that are clearly used as EE 
certs. The six references to SS certs in that doc (on pages 202-204 
and 248) equate them to "certificates signed by an obscure 
authority."  Oh well, guess nobody who cared about PKIX bothered to 
read 200+ pages into a 270 page doc to find that error :-), back in 
2002.

Steve
--============_-909570926==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: [dane] [keyassure] Use cases
document.</title></head><body>
<div>At 2:49 PM +0100 4/8/11, Stephen Farrell wrote:</div>
<blockquote type="cite" cite>...</blockquote>
<blockquote type="cite" cite><br>
5280 is IMO properly silent on how EEs might use self-signed<br>
certs. (Or if not, I've forgotten what it says on that;-)</blockquote>
<div><br>
<br>
</div>
<div>I'll help with a few cites from 5280:</div>
<div><br></div>
<blockquote type="cite" cite><font
color="#000000">3.2:</font></blockquote>
<blockquote type="cite" cite><font
color="#000000"><br></font></blockquote>
<blockquote type="cite" cite><font color="#000000">This specification
covers two classes of certificates:<u> CA&nbsp; certificates</u> and
end entity certificates.&nbsp;<u> CA certificates</u> may be&nbsp;
further divided into three classes: cross-certificates, self-issued&nbsp;
certificates, and<u> self-signed certificates</u>.&nbsp;
Cross-certificates are CA certificates in which the issuer and subject
are different entities.&nbsp; Cross-certificates describe a trust
relationship between the two CAs.&nbsp; Self-issued certificates are
CA certificates in which&nbsp; the issuer and subject are the same
entity.&nbsp; Self-issued certificates are generated to support
changes in policy or operations.&nbsp;<u> Self-signed certificates are
self-issued certificates where the digital signature may be verified
by the public key bound into the certificate.</u>&nbsp; Self-signed
certificates are used to convey a public key for use to begin
certification paths.&nbsp;<u> End entity certificates are issued to
subjects that are not authorized to issue
certificates.</u></font></blockquote>
<div><font color="#000000"><u><br></u></font></div>
<div><font color="#000000">This text says that a self-signed
certificate is a CA certificate, period. The last sentence says that
an EE certificate cannot be used to verify a signature on another
certificate, and thus it is not a CA certificate, and thus, not
self-signed.</font></div>
<div><br></div>
<blockquote type="cite" cite><font color="#000000">4.2.1.1
(AKI)</font></blockquote>
<blockquote type="cite" cite><font
color="#000000"><br></font></blockquote>
<blockquote type="cite" cite><font color="#000000">The keyIdentifier
field of the authorityKeyIdentifier extension MUST be included in all
certificates generated by conforming CAs to facilitate certification
path construction.&nbsp; There is one exception; where a CA
distributes its public key in the form of a &quot;self-signed&quot;
certificate, the authority key identifier MAY be
omitted.</font></blockquote>
<div><font color="#000000"><br></font></div>
<div><font color="#000000">This text says further reiterates the
notion that a self-signed certificate is not an EE certificate. Note
that in this text the exception discusses the context where a CA
distributes its public key via a self-signed certificate, i.e., where
the self-signed certificate is used as a container to distribute a
trust anchor.</font> This is the relevant case for DANE.</div>
<div><br></div>
<blockquote type="cite" cite><font color="#000000">4.2.1.3
(KU)</font></blockquote>
<blockquote type="cite" cite><font
color="#000000"><br></font></blockquote>
<blockquote type="cite" cite><font color="#000000">The keyCertSign bit
is asserted when the subject public key is&nbsp; used for verifying
signatures on public key certificates.&nbsp; If the keyCertSign bit is
asserted, then the cA bit in the basic constraints extension (Section
4.2.1.9) MUST also be asserted.</font></blockquote>
<blockquote type="cite" cite><font
color="#000000"><br></font></blockquote>
<blockquote type="cite" cite><font color="#000000">If the keyUsage
extension is present, then the subject public key MUST NOT be used to
verify signatures on certificates or CRLs unless the corresponding
keyCertSign or cRLSign bit is set.</font></blockquote>
<div><font color="#000000"><br></font></div>
<div><font color="#000000">This text says that a valid CA certificate
MUST contain the basic constraints extension with the CA flag set
TRUE, thus 5280 requires CA certificates to be v3. It also establishes
required values for key usage extension flags if the certificate is to
be used to verify signatures on other certificates, i.e., if the
certificate is to be used as a CA certificate.</font><br>
</div>
<blockquote type="cite" cite><font color="#000000">4.2.1.9 (Basic
Constraints):</font></blockquote>
<blockquote type="cite" cite><font
color="#000000"><br></font></blockquote>
<blockquote type="cite" cite><font color="#000000">The basic
constraints extension identifies whether the subject of the
certificate is a CA and the maximum depth of valid certification paths
that include this certificate.</font></blockquote>
<blockquote type="cite" cite><font
color="#000000"><br></font></blockquote>
<blockquote type="cite" cite><font color="#000000">Conforming CAs MUST
include this extension in all CA certificates that contain public keys
used to validate digital signatures on certificates and MUST mark the
extension as critical in such certificates.</font></blockquote>
<div><font color="#000000"><br></font></div>
<div><font color="#000000">Again, 5280 says that a CA certificate is a
v3 certificate.</font><br>
</div>
<blockquote type="cite" cite><br>
&gt; This may be true in theory, but is far from true in practice -
in<br>
&gt; practice, I can put a self-signed cert on my website and it works
just<br>
&gt; fine (in the sense that it is not considered malformed, just
rather<br>
&gt; untrustworthy).<br>
&gt;<br>
&gt; So, this is just spec lawyering.<br>
<br>
Some data: both SIP (rfc3261) and S/MIME (rfc5750) explicitly<br>
allow self-signed certs. SDP/TLS (rfc4572) seems to have an<br>
entire section about them. And of course TLS (rfc5246)
says</blockquote>
<blockquote type="cite" cite>you MAY include them.</blockquote>
<div><br></div>
<div>I looked at the 4 cites you provided above.&nbsp; Only two of
them support your conclusion that it's OK to call for using an SS cert
as an EE cert.</div>
<div><br></div>
<div>When I scan 5246 I find one reference to a self-signed cert (page
48).</div>
<div>That text is talking about a &quot;root certificate [sic]
authority.&quot; So that</div>
<div>reference is NOT talking about SS certs as EE certs.</div>
<div><br></div>
<div>RFC 5750 appears to contain two references to self-signed certs
(page 8)</div>
<div>and both refer to CA certs, not to EE certs. So, again, this
reference is NOT talking about SS certs as EE certs.</div>
<div><br></div>
<div>RFC 4572 makes a number of references to SS certs, and it
does</div>
<div>envision using them as EE certs. However, the security analysis
for using</div>
<div>SS certs here is flawed. For example it says (page 9) that it's
OK to</div>
<div>use a SS cert to assert ANY identity in the TLS session or in an
S/MIME-protected SDP exchange. In the name of interoperability, the
RFC also says (page 9) that if hop-by-hop integrity is employed for
SDP, then an SS cert is OK too, even though this allows any SDP entity
along the path to spoof any other entity. I can't take too seriously
an endorsement of misuse of SS certs as EE certs in this brief</div>
<div>document, given the rest of the bad security analysis.</div>
<div><br></div>
<div>RFC 3261 has references to SS certs that are clearly used as EE
certs. The six references to SS certs in that doc (on pages 202-204
and 248) equate them to &quot;<font color="#000000">certificates
signed by an obscure authority</font>.&quot;&nbsp; Oh well, guess
nobody who cared about PKIX bothered to read 200+ pages into a 270
page doc to find that error :-), back in 2002.</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-909570926==_ma============--

From [e-mail]  Mon Apr 11 15:41:05 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 33091E06AD for <[e-mail]>; Mon, 11 Apr 2011 15:41:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.089
X-Spam-Level: 
X-Spam-Status: No, score=-3.089 tagged_above=-999 required=5 tests=[AWL=0.509,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WhJ1l8zuXDQI for <[e-mail]>; Mon, 11 Apr 2011 15:41:04 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id 8C2DCE0670 for <[e-mail]>; Mon, 11 Apr 2011 15:41:03 -0700 (PDT)
Received: by vws12 with SMTP id 12so5695428vws.31 for <[e-mail]>; Mon, 11 Apr 2011 15:41:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=lnyeCJ03ff3j/v5QrXm9p6iTAkcLGN88cTg01+w/nsE=; b=nNsEt1ah71J0dpISgwFn8EqqOgSYWEtT36EhWnY+7jsIprY/89mAPhHX4X/mpbOqHO fVzh5irIQiu74aLrxgbJDAi8acDDguC9qUFn4n6Tv7QY4Ejuf/wP5LYSXuxY7JRWTJib QnOOK3qqtRTwp/0jCoi+SbA09jBMgTfmRDpW8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=sgsZS6uhxAkga+7EYirdFF5gQFOmUhQoYwV3dHVS738sXAHJu3aFiUc2ruWADKwezN o4+oL9w1yRvxARGBfhtpJy0Qb7Ia7x9VgYGeqPR1kNS0Nie+KjOwZHDiRu2a2YGbfuS5 kilUb8cK+JUfLQE4OcwuyBa5WLCNyOAxwwo3U=
MIME-Version: 1.0
Received: by 10.52.65.52 with SMTP id u20mr285319vds.309.1302561662917; Mon, 11 Apr 2011 15:41:02 -0700 (PDT)
Received: by 10.52.166.230 with HTTP; Mon, 11 Apr 2011 15:41:02 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <BANLkTimGmtOS0=KbaChb=5F=K=[e-mail]> <BANLkTinpPyB=[e-mail]> <BANLkTinqS_Z0MfySDr=[e-mail]> <[e-mail]> <[e-mail]>
Date: Mon, 11 Apr 2011 18:41:02 -0400
Message-ID: <BANLkTi=[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: Christopher Morrow <[e-mail]>
Content-Type: multipart/alternative; boundary=bcaec50166a5375c6d04a0ac450b
Cc: [e-mail], [e-mail]
Subject: Re: [dane] Use Cases Document
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 11 Apr 2011 22:41:05 -0000

--bcaec50166a5375c6d04a0ac450b
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Apr 11, 2011 at 3:49 PM, Christopher Morrow <[e-mail]
> wrote:

> On Mon, Apr 11, 2011 at 9:11 PM, Phillip Hallam-Baker <[e-mail]>
> wrote:
> >
> >
> > On Mon, Apr 11, 2011 at 2:49 PM, Christopher Morrow
> > <[e-mail]> wrote:
> >>
> >> I'm not sure you'd (*or anyone would) know if this was going on
> >> though. it only became 'known' because the alleged/admitted third
> >> party bragged about his actions, in detail.
> >
> > No, this is an untrue accusation and must be withdrawn.
>
> pardon? the young man who put out the info did so long before the
> browser patches arrived. he even had the private keys and certs, I
> believe, available before patches hit for browsers.


Not true. Go read the incident report.

The person who leaked the story while the patches were being prepared was
Jacob Applebaum who had absolutely nothing to do with making the attack. He
then agreed to hold off on publishing the details while one of the patches
was completed.

But the decision to publish was taken long before the attack had leaked. The
attack had already been communicated to several parties who were not under
NDA or any confidentiality agreement.


If you want to make serious accusations you should take the time to find out
the facts first. In this case the facts are very easily determined and show
that you are wrong.

It is quite true that not every detail of the attack has been made public.
This is quite usual when there is a continuing police investigation.


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

--bcaec50166a5375c6d04a0ac450b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Mon, Apr 11, 2011 at 3:49 PM, Christo=
pher Morrow <span dir=3D"ltr">&lt;<a href=3D"mailto:[e-mail]=
">[e-mail]</a>&gt;</span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex;">
<div class=3D"im">On Mon, Apr 11, 2011 at 9:11 PM, Phillip Hallam-Baker &lt=
;<a href=3D"mailto:[e-mail]">[e-mail]</a>&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt; On Mon, Apr 11, 2011 at 2:49 PM, Christopher Morrow<br>
&gt; &lt;<a href=3D"mailto:[e-mail]">[e-mail]=
</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; I&#39;m not sure you&#39;d (*or anyone would) know if this was goi=
ng on<br>
&gt;&gt; though. it only became &#39;known&#39; because the alleged/admitte=
d third<br>
&gt;&gt; party bragged about his actions, in detail.<br>
&gt;<br>
&gt; No, this is an untrue accusation and must be withdrawn.<br>
<br>
</div>pardon? the young man who put out the info did so long before the<br>
browser patches arrived. he even had the private keys and certs, I<br>
believe, available before patches hit for browsers.</blockquote><div><br></=
div><div>Not true. Go read the incident report.</div><div><br></div><div>Th=
e person who leaked the story while the patches were being prepared was Jac=
ob Applebaum who had absolutely nothing to do with making the attack. He th=
en agreed to hold off on publishing the details while one of the patches wa=
s completed.=A0</div>
<div><br></div><div>But the decision to publish was taken long before the a=
ttack had leaked. The attack had already been communicated to several parti=
es who were not under NDA or any confidentiality agreement.</div><div><br>
</div><div><br></div><div>If you want to make serious accusations you shoul=
d take the time to find out the facts first. In this case the facts are ver=
y easily determined and show that you are wrong.</div><div><br></div><div>
It is quite true that not every detail of the attack has been made public. =
This is quite usual when there is a continuing police investigation.=A0</di=
v><div><br></div></div><br>-- <br>Website: <a href=3D"http://hallambaker.co=
m/">http://hallambaker.com/</a><br>
<br>

--bcaec50166a5375c6d04a0ac450b--

From [e-mail]  Mon Apr 11 16:14:30 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C32A5E06FE for <[e-mail]>; Mon, 11 Apr 2011 16:14:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.986
X-Spam-Level: 
X-Spam-Status: No, score=-6.986 tagged_above=-999 required=5 tests=[AWL=3.612,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WFDy8htWzR+3 for <[e-mail]>; Mon, 11 Apr 2011 16:14:29 -0700 (PDT)
Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfc.amsl.com (Postfix) with ESMTP id 362BCE06CB for <[e-mail]>; Mon, 11 Apr 2011 16:14:29 -0700 (PDT)
Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p3BJvsaH019356;  Mon, 11 Apr 2011 22:57:54 +0300
X-CheckPoint: {4DA36AF9-1-1B221DC2-FFFF}
Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 11 Apr 2011 22:57:54 +0300
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Mon, 11 Apr 2011 21:57:54 +0200
From: Yoav Nir <[e-mail]>
To: Phillip Hallam-Baker <[e-mail]>
Date: Mon, 11 Apr 2011 21:57:53 +0200
Thread-Topic: [dane] Use Cases Document
Thread-Index: Acv4gr5dFh/vuvRQTIWK83VOHHgh1g==
Message-ID: <[e-mail]>
References: <[e-mail]> <BANLkTimGmtOS0=KbaChb=5F=K=[e-mail]> <BANLkTinpPyB=[e-mail]> <BANLkTinqS_Z0MfySDr=[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_A46B78714A59413F8762361DF43B94ECcheckpointcom_"
MIME-Version: 1.0
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [dane] Use Cases Document
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 11 Apr 2011 23:14:31 -0000

--_000_A46B78714A59413F8762361DF43B94ECcheckpointcom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


On Apr 11, 2011, at 10:11 PM, Phillip Hallam-Baker wrote:



On Mon, Apr 11, 2011 at 2:49 PM, Christopher Morrow <[e-mail]=
m<mailto:[e-mail]>> wrote:

I'm not sure you'd (*or anyone would) know if this was going on
though. it only became 'known' because the alleged/admitted third
party bragged about his actions, in detail.

No, this is an untrue accusation and must be withdrawn.

The notification of the RA breach incident was made through the normal proc=
ess and the timing of the release of the information to the public was gate=
d on the time taken to roll patches by the major browser providers.

I think these kind of rumors thrive because we haven't heard how the breach=
 was found. Common wisdom is that few breaches get discovered. If Comodo ha=
s found it by its own means, that puts it way ahead of the curve.

Anyway, the most worrying part about the incident is not that there was a b=
reach. Sites get defaced, houses get broken into, and banks get robbed all =
the time. Information gets stolen. It's part of the risk of doing business =
and of living in houses. The problem is what needed to be done to fix it. G=
oing forward, is this what we're going to have to do?  Is the response to a=
ny future mis-issue going to be a patch to all browsers with hard-coded CRL=
s?

I hope the commercial CAs can find a better way to do revocation.

As for DANE, while not actually a use-case, the incident highlights two req=
uirements:
- Revocation should be possible (if I pinned or pointed out the wrong certi=
ficate, I should be able to rectify it)
- We need resistance against an attacker who controls the DNS (such as a na=
tional government or a hotspot administrator)

I guess DNSSEC can protect against the malicious hotspots. Not so sure if i=
t's effective against a national government.





--_000_A46B78714A59413F8762361DF43B94ECcheckpointcom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html><head></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode:=
 space; -webkit-line-break: after-white-space; "><br><div><div>On Apr 11, 2=
011, at 10:11 PM, Phillip Hallam-Baker wrote:</div><br class=3D"Apple-inter=
change-newline"><blockquote type=3D"cite"><br><br><div class=3D"gmail_quote=
">On Mon, Apr 11, 2011 at 2:49 PM, Christopher Morrow <span dir=3D"ltr">&lt=
;<a href=3D"mailto:[e-mail]">[e-mail]</a>&gt;=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
I'm not sure you'd (*or anyone would) know if this was going on<br>
though. it only became 'known' because the alleged/admitted third<br>
party bragged about his actions, in detail.</blockquote><div><br></div><div=
>No, this is an untrue accusation and must be withdrawn.</div><div><br></di=
v><div>The notification of the RA breach incident was made through the norm=
al process and the timing of the release of the information to the public w=
as gated on the time taken to roll patches by the major browser providers.&=
nbsp;</div>
</div></blockquote><br></div><div>I think these kind of rumors thrive becau=
se we haven't heard how the breach was found. Common wisdom is that few bre=
aches get discovered. If Comodo has found it by its own means, that puts it=
 way ahead of the curve.</div><div><br></div><div>Anyway, the most worrying=
 part about the incident is not that there was a breach. Sites get defaced,=
 houses get broken into, and banks get robbed all the time. Information get=
s stolen. It's part of the risk of doing business and of living in houses. =
The problem is what needed to be done to fix it. Going forward, is this wha=
t we're going to have to do? &nbsp;Is the response to any future mis-issue =
going to be a patch to all browsers with hard-coded CRLs? &nbsp;</div><div>=
<br></div><div>I hope the commercial CAs can find a better way to do revoca=
tion.</div><div><br></div><div>As for DANE, while not actually a use-case, =
the incident highlights two requirements:</div><div>- Revocation should be =
possible (if I pinned or pointed out the wrong certificate, I should be abl=
e to rectify it)</div><div>- We need resistance against an attacker who con=
trols the DNS (such as a national government or a hotspot administrator)</d=
iv><div><br></div><div>I guess DNSSEC can protect against the malicious hot=
spots. Not so sure if it's effective against a national government.</div><d=
iv><br></div><div><br></div><div><br></div><br></body></html>=

--_000_A46B78714A59413F8762361DF43B94ECcheckpointcom_--

From [e-mail]  Mon Apr 11 17:54:20 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2D4DAE0664 for <[e-mail]>; Mon, 11 Apr 2011 17:54:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.449
X-Spam-Level: 
X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYoycN9oWh-X for <[e-mail]>; Mon, 11 Apr 2011 17:54:17 -0700 (PDT)
Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfc.amsl.com (Postfix) with ESMTP id 979FCE0613 for <[e-mail]>; Mon, 11 Apr 2011 17:54:17 -0700 (PDT)
Received: from [192.168.0.203] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 318261B40982; Mon, 11 Apr 2011 20:54:15 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Warren Kumari <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Mon, 11 Apr 2011 20:54:10 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]> <BANLkTimGmtOS0=KbaChb=5F=K=[e-mail]> <BANLkTinpPyB=[e-mail]> <BANLkTinqS_Z0MfySDr=[e-mail]> <[e-mail]> <[e-mail]>
To: Yoav Nir <[e-mail]>
X-Mailer: Apple Mail (2.1084)
Cc: [e-mail]
Subject: Re: [dane] Use Cases Document
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 12 Apr 2011 00:54:20 -0000

On Apr 11, 2011, at 3:57 PM, Yoav Nir wrote:

>=20
> On Apr 11, 2011, at 10:11 PM, Phillip Hallam-Baker wrote:
>=20
>>=20
>>=20
>> On Mon, Apr 11, 2011 at 2:49 PM, Christopher Morrow =
<[e-mail]> wrote:
>>=20
>> I'm not sure you'd (*or anyone would) know if this was going on
>> though. it only became 'known' because the alleged/admitted third
>> party bragged about his actions, in detail.
>>=20
>> No, this is an untrue accusation and must be withdrawn.
>>=20
>> The notification of the RA breach incident was made through the =
normal process and the timing of the release of the information to the =
public was gated on the time taken to roll patches by the major browser =
providers.=20
>=20
> I think these kind of rumors thrive because we haven't heard how the =
breach was found. Common wisdom is that few breaches get discovered. If =
Comodo has found it by its own means, that puts it way ahead of the =
curve.
>=20
> Anyway, the most worrying part about the incident is not that there =
was a breach. Sites get defaced, houses get broken into, and banks get =
robbed all the time. Information gets stolen. It's part of the risk of =
doing business and of living in houses. The problem is what needed to be =
done to fix it. Going forward, is this what we're going to have to do?  =
Is the response to any future mis-issue going to be a patch to all =
browsers with hard-coded CRLs? =20
>=20
> I hope the commercial CAs can find a better way to do revocation.
>=20
> As for DANE, while not actually a use-case, the incident highlights =
two requirements:
> - Revocation should be possible (if I pinned or pointed out the wrong =
certificate, I should be able to rectify it)
> - We need resistance against an attacker who controls the DNS (such as =
a national government or a hotspot administrator)
>=20
> I guess DNSSEC can protect against the malicious hotspots. Not so sure =
if it's effective against a national government.

Well, it depends upon what all you think a national government can / is =
willing to do...

If you believe that they can break the crypto, then no, DNSSEC (and by =
extension DANE) is not effective against a NG but then neither is =
anything that relies upon crypto stuff (like TLS).

If you believe that they are willing to seize the domain and replace the =
records at the registry / parent then no, DNSSEC isn't effective -- but, =
if they are willing to seize the domain you have lost in any case (and =
they need to be in county to do this).

If they are willing to force all of their citizens / resolver operators =
to install a root key that they control, and then clone / mirror the DNS =
tree (and block access to the "real" DNS and sign on the fly and all =
sorts of other tricks) then they can forge DNSSEC responses... In this =
case you have lost anyway (they could (and probably would) also force =
installation of their own TA as well).

Other than that (oh, and rubber-hose cryptanalysis) AFAIK the best that =
a gvmnt can do is the same that any other attacker can do -- block / =
corrupt DNSSEC resolution, making responses bogus. Under these =
conditions the client cannot get a valid TLSA record and so cannot =
continue. So, the best that an attacker can manage under these =
conditions is a DoS (which they can cause regardless of the existence of =
DANE.


W


>=20
>=20
>=20
>=20
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane


From [e-mail]  Mon Apr 11 18:42:51 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4FBD5E066A for <[e-mail]>; Mon, 11 Apr 2011 18:42:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.474
X-Spam-Level: 
X-Spam-Status: No, score=-1.474 tagged_above=-999 required=5 tests=[AWL=-0.776, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cKdegaOUDqK for <[e-mail]>; Mon, 11 Apr 2011 18:42:49 -0700 (PDT)
Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfc.amsl.com (Postfix) with ESMTP id 0F09EE0664 for <[e-mail]>; Mon, 11 Apr 2011 18:42:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=IEX4gdK82rqoHAKl4w4Cc8I78vGWo/PkCGAASxpmXQ4=; b=P1f/8NN/hPHh5V3rY7eUQT06c36wxPJrD9r+3Z7Sn6GWtMsVk90GZuABS7YfdhYTHQ7RhFxjLH6uC HrpiE1G+SVwmCryqrzS804uZ7CWrZIwBIo7lm5SAK/L/enVW+wxf7g4rT+uIo1AnaGAs0FZYQ2CgNr 7GgUwKgB1ovVCTQ8=
Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Mon, 11 Apr 2011 21:57:38 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Jakob Schlyter <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Mon, 11 Apr 2011 21:57:34 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <p06240802c9c22fe5410c@128.89.89.213> <[e-mail]>
To: Phillip Hallam-Baker <[e-mail]>
X-Mailer: Apple Mail (2.1084)
Cc: [e-mail], Paul Hoffman <[e-mail]>
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 12 Apr 2011 01:42:51 -0000

On 11 apr 2011, at 20.55, Phillip Hallam-Baker wrote:

> This problem is very easily solved: DANE needs say nothing about the =
issue at all. Just cite PKIX and move on.

I agree, and I see no point in spending the WG's time trying to move =
(this part of) the PKIX mountain.

	jakob


From [e-mail]  Mon Apr 11 19:36:31 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 59916E0696 for <[e-mail]>; Mon, 11 Apr 2011 19:36:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.118
X-Spam-Level: 
X-Spam-Status: No, score=-3.118 tagged_above=-999 required=5 tests=[AWL=0.480,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xv5EekdIb70E for <[e-mail]>; Mon, 11 Apr 2011 19:36:30 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id 288FAE0676 for <[e-mail]>; Mon, 11 Apr 2011 19:36:30 -0700 (PDT)
Received: by vws12 with SMTP id 12so5878178vws.31 for <[e-mail]>; Mon, 11 Apr 2011 19:36:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=sGoD3vaKGp2vcOe3/wqMN5Tk3NZJAoze++2dzQK3lN0=; b=ismg3IKATy1xyEM4PsYUuyJKPzSSeMHUzq8GymKH3nNGhCZNGkCDf1VVR/ym/TTaBk +tKwpPBrRXcUGyZjGTGCl7XzbJWWEZjYjNigVnndBdDHnpLSvdRJ1arJFeagoXqJxIMu zXiehxVqv55gc3KyEjNl5gWFc697MXaJLXgA4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=AxEXCo5ogeOoOZFA461mH3wUxmD9tXbbI5mNDJ3icfanzs3yMubu0h00eHwVqUVW1G Dva8+VBW7yxPNXO5jgxXA10MtHx9k6Q7pcpF6Rcwb2sJFD8sw5Yc5XzOqV4LMi9PUfG6 qIU4Ir+f5LrerEHsyMPKfgC9b7Zq0uDncR9TQ=
MIME-Version: 1.0
Received: by 10.52.18.11 with SMTP id s11mr495245vdd.269.1302575789500; Mon, 11 Apr 2011 19:36:29 -0700 (PDT)
Received: by 10.52.166.230 with HTTP; Mon, 11 Apr 2011 19:36:29 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <BANLkTimGmtOS0=KbaChb=5F=K=[e-mail]> <BANLkTinpPyB=[e-mail]> <BANLkTinqS_Z0MfySDr=[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Mon, 11 Apr 2011 22:36:29 -0400
Message-ID: <BANLkTi=_=grvg0U1u6dtGqHv+mdqE=[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: Warren Kumari <[e-mail]>
Content-Type: multipart/alternative; boundary=20cf3054a11339e9ac04a0af8f38
Cc: [e-mail]
Subject: Re: [dane] Use Cases Document
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 12 Apr 2011 02:36:31 -0000

--20cf3054a11339e9ac04a0af8f38
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Apr 11, 2011 at 8:54 PM, Warren Kumari <[e-mail]> wrote:

>
> > I think these kind of rumors thrive because we haven't heard how the
> breach was found. Common wisdom is that few breaches get discovered. If
> Comodo has found it by its own means, that puts it way ahead of the curve.
>

It is in the incident report.

The CA has a mechanism that notifies the RA every time a certificate is
issued. The RA knew it had not requested the certs and that they must
therefore have been a breach.

This is not an isolated incident either. VeriSign detected the codesigning
breach ten years ago and self-reported that as well.



> Well, it depends upon what all you think a national government can / is
> willing to do...
>
> If you believe that they can break the crypto, then no, DNSSEC (and by
> extension DANE) is not effective against a NG but then neither is anything
> that relies upon crypto stuff (like TLS).
>

I don't think anyone who can break the crypto would want the fact to be
known. So I would exclude this attack.



> If you believe that they are willing to seize the domain and replace the
> records at the registry / parent then no, DNSSEC isn't effective -- but, if
> they are willing to seize the domain you have lost in any case (and they
> need to be in county to do this).
>

We have seen this attack several times.



> If they are willing to force all of their citizens / resolver operators to
> install a root key that they control, and then clone / mirror the DNS tree
> (and block access to the "real" DNS and sign on the fly and all sorts of
> other tricks) then they can forge DNSSEC responses... In this case you have
> lost anyway (they could (and probably would) also force installation of
> their own TA as well).
>

That is the 'attack' that I expect and it is not even really an 'attack'
from certain points of view. If the Russian government decides that it
disagrees that the US has the right to appoint the general custodian of root
DNS, then that is a diplomatic dispute rather than a technical attack.

In fact there was the time back in the mists of time when Jon Postel and the
root operators did the same sort of thing of their own accord.

Given that Russia and China have signed a treaty on this subject I really
don't doubt their intention to follow through on it.

This is why I think we are going to need DPLS and some other stuff in the
loop. I do not raise these issues because of some hidden agenda, my reason
for raising them is that I want to protect against them.



Other than that (oh, and rubber-hose cryptanalysis) AFAIK the best that a
> gvmnt can do is the same that any other attacker can do -- block / corrupt
> DNSSEC resolution, making responses bogus. Under these conditions the client
> cannot get a valid TLSA record and so cannot continue. So, the best that an
> attacker can manage under these conditions is a DoS (which they can cause
> regardless of the existence of DANE.


It all comes down to what your fallback mechanism is.

If you are going to fall back to 'site unavailable' then you lose.

If you fall back to 'route DNS over alternative mechanism to trusted source'
then you can win even when you have a government level DoS.


There is other stuff that can be done as well. I do not accept that this
particular attack model is hopeless.

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

--20cf3054a11339e9ac04a0af8f38
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Mon, Apr 11, 2011 at 8:54 PM, Warren =
Kumari <span dir=3D"ltr">&lt;<a href=3D"mailto:[e-mail]">warren@ku=
mari.net</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class=3D"h5"><br>
&gt; I think these kind of rumors thrive because we haven&#39;t heard how t=
he breach was found. Common wisdom is that few breaches get discovered. If =
Comodo has found it by its own means, that puts it way ahead of the curve.<=
br>

</div></div></blockquote><div><br></div><div>It is in the incident report.<=
/div><div><br></div><div>The CA has a mechanism that notifies the RA every =
time a certificate is issued. The RA knew it had not requested the certs an=
d that they must therefore have been a breach.</div>
<div><br></div><div>This is not an isolated incident either. VeriSign detec=
ted the codesigning breach ten years ago and self-reported that as well.</d=
iv><div><br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Well, it depends upon what all you think a national government can / is wil=
ling to do...<br>
<br>
If you believe that they can break the crypto, then no, DNSSEC (and by exte=
nsion DANE) is not effective against a NG but then neither is anything that=
 relies upon crypto stuff (like TLS).<br></blockquote><div><br></div><div>
I don&#39;t think anyone who can break the crypto would want the fact to be=
 known. So I would exclude this attack.</div><div><br></div><div>=A0</div><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex;">

If you believe that they are willing to seize the domain and replace the re=
cords at the registry / parent then no, DNSSEC isn&#39;t effective -- but, =
if they are willing to seize the domain you have lost in any case (and they=
 need to be in county to do this).<br>
</blockquote><div><br></div><div>We have seen this attack several times.</d=
iv><div><br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
If they are willing to force all of their citizens / resolver operators to =
install a root key that they control, and then clone / mirror the DNS tree =
(and block access to the &quot;real&quot; DNS and sign on the fly and all s=
orts of other tricks) then they can forge DNSSEC responses... In this case =
you have lost anyway (they could (and probably would) also force installati=
on of their own TA as well).<br>
</blockquote><div><br></div><div>That is the &#39;attack&#39; that I expect=
 and it is not even really an &#39;attack&#39; from certain points of view.=
 If the Russian government decides that it disagrees that the US has the ri=
ght to appoint the general custodian of root DNS, then that is a diplomatic=
 dispute rather than a technical attack.</div>
<div><br></div><div>In fact there was the time back in the mists of time wh=
en Jon Postel and the root operators did the same sort of thing of their ow=
n accord.</div><div><br></div><div>Given that Russia and China have signed =
a treaty on this subject I really don&#39;t doubt their intention to follow=
 through on it.</div>
<div><br></div><div>This is why I think we are going to need DPLS and some =
other stuff in the loop. I do not raise these issues because of some hidden=
 agenda, my reason for raising them is that I want to protect against them.=
</div>
<div><br></div><div>=A0</div><div><br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"=
>
Other than that (oh, and rubber-hose cryptanalysis) AFAIK the best that a g=
vmnt can do is the same that any other attacker can do -- block / corrupt D=
NSSEC resolution, making responses bogus. Under these conditions the client=
 cannot get a valid TLSA record and so cannot continue. So, the best that a=
n attacker can manage under these conditions is a DoS (which they can cause=
 regardless of the existence of DANE.</blockquote>
<div><br></div><div>It all comes down to what your fallback mechanism is.</=
div><div><br></div><div>If you are going to fall back to &#39;site unavaila=
ble&#39; then you lose.</div><div><br></div><div>If you fall back to &#39;r=
oute DNS over alternative mechanism to trusted source&#39; then you can win=
 even when you have a government level DoS.</div>
<div><br></div><div><br></div><div>There is other stuff that can be done as=
 well. I do not accept that this particular attack model is hopeless.</div>=
<div>=A0</div></div>-- <br>Website: <a href=3D"http://hallambaker.com/">htt=
p://hallambaker.com/</a><br>
<br>

--20cf3054a11339e9ac04a0af8f38--

From [e-mail]  Mon Apr 11 20:13:17 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 30DF8E0674 for <[e-mail]>; Mon, 11 Apr 2011 20:13:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.027
X-Spam-Level: 
X-Spam-Status: No, score=-10.027 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2Ysi5PMAQc7 for <[e-mail]>; Mon, 11 Apr 2011 20:13:16 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfc.amsl.com (Postfix) with ESMTP id 4B8F4E0663 for <[e-mail]>; Mon, 11 Apr 2011 20:13:16 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p3C3DD1A012106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Apr 2011 05:13:14 +0200 (MEST)
From: Martin Rex <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail] (Phillip Hallam-Baker)
Date: Tue, 12 Apr 2011 05:13:13 +0200 (MEST)
In-Reply-To: <BANLkTi=_=grvg0U1u6dtGqHv+mdqE=[e-mail]> from "Phillip Hallam-Baker" at Apr 11, 11 10:36:29 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: [e-mail]
Subject: Re: [dane] Use Cases Document
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: [e-mail]
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 12 Apr 2011 03:13:17 -0000

Phillip Hallam-Baker wrote:
> 
> On Mon, Apr 11, 2011 at 8:54 PM, Warren Kumari <[e-mail]> wrote:
> >
> > > I think these kind of rumors thrive because we haven't heard how the
> > breach was found. Common wisdom is that few breaches get discovered. If
> > Comodo has found it by its own means, that puts it way ahead of the curve.
> >
> 
> It is in the incident report.
> 
> The CA has a mechanism that notifies the RA every time a certificate is
> issued. The RA knew it had not requested the certs and that they must
> therefore have been a breach.

So they did not detect the break-in, only the abuse.

> 
> This is not an isolated incident either. VeriSign detected the codesigning
> breach ten years ago and self-reported that as well.

You mean the two ActiveX codesign/Authenticode certificates that are still
in every MSIE Browser in the "Untrusted Publishers" section today?

IIRC it took VeriSign 5 weeks after issue to notice their mistake.

And both VeriSign and Microsoft realized that they had not thought
about certificate revocation at all and Microsoft resorted to explicitly
blacklisting the certificate in all of their MSIE browsers.

Looking at the rush of browser patches after the Commodo breach 10 years
later, there hasn't been much progress with respect to "certificate
revocation does not work", it seems.  And this time around, it affected
many other browser vendors/suppliers as well, not just Microsoft...


-Martin

From [e-mail]  Mon Apr 11 20:26:31 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 68A00E069F for <[e-mail]>; Mon, 11 Apr 2011 20:26:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.284
X-Spam-Level: 
X-Spam-Status: No, score=-103.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6h7R8YiiQ2U for <[e-mail]>; Mon, 11 Apr 2011 20:26:30 -0700 (PDT)
Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfc.amsl.com (Postfix) with ESMTP id 3AE6EE0663 for <[e-mail]>; Mon, 11 Apr 2011 20:26:30 -0700 (PDT)
Received: by ewy19 with SMTP id 19so2274458ewy.31 for <[e-mail]>; Mon, 11 Apr 2011 20:26:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=fAege+hI2/nh38w7DVQvLHIsNA38/FRZoka5EBm/+GM=; b=Dzp633IKj8acroFiiZll0qUSYcZBkRN388JiwJIecy+eeO+CzvArWMYTlHp55+MACe L5ejlWM2JYLfZPkCfw5cr64rh8JRnr87MOnv+5qjTmlSXK1sAsOm2tKcmChviWPFEJhN bO2AYP7NagysQjW7W142z3uTe9RWVvj7lBfm4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=DL9Vj00AHEj3pI+6qoyqQUlvDrHcQkwvemfg8ixKMvw1JmqmJYFHFyL9F824WotaUA bXW8bumcZ39BC2P7TjcogEVipNV9AbmfcU7IHF9Cr/iRH82G8YPW+XMhwM4cN0g0UBFg zUprWjJoSoh7ukRMRw0jwGE5VRh0aS3qQQzEE=
MIME-Version: 1.0
Received: by 10.213.109.209 with SMTP id k17mr2604928ebp.101.1302578789087; Mon, 11 Apr 2011 20:26:29 -0700 (PDT)
Sender: [e-mail]
Received: by 10.213.33.81 with HTTP; Mon, 11 Apr 2011 20:26:28 -0700 (PDT)
In-Reply-To: <BANLkTi=[e-mail]>
References: <[e-mail]> <BANLkTimGmtOS0=KbaChb=5F=K=[e-mail]> <BANLkTinpPyB=[e-mail]> <BANLkTinqS_Z0MfySDr=[e-mail]> <[e-mail]> <[e-mail]> <BANLkTi=[e-mail]>
Date: Tue, 12 Apr 2011 05:26:28 +0200
X-Google-Sender-Auth: kmFQbUkkaNodBq30PHr0Uqn3XMs
Message-ID: <[e-mail]>
From: Christopher Morrow <[e-mail]>
To: Phillip Hallam-Baker <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Cc: [e-mail], [e-mail]
Subject: Re: [dane] Use Cases Document
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 12 Apr 2011 03:26:31 -0000

On Tue, Apr 12, 2011 at 12:41 AM, Phillip Hallam-Baker <[e-mail]> wrote:
>
>
> On Mon, Apr 11, 2011 at 3:49 PM, Christopher Morrow
> <[e-mail]> wrote:
>>
>> On Mon, Apr 11, 2011 at 9:11 PM, Phillip Hallam-Baker <[e-mail]>
>> wrote:
>> >
>> >
>> > On Mon, Apr 11, 2011 at 2:49 PM, Christopher Morrow
>> > <[e-mail]> wrote:
>> >>
>> >> I'm not sure you'd (*or anyone would) know if this was going on
>> >> though. it only became 'known' because the alleged/admitted third
>> >> party bragged about his actions, in detail.
>> >
>> > No, this is an untrue accusation and must be withdrawn.
>>
>> pardon? the young man who put out the info did so long before the
>> browser patches arrived. he even had the private keys and certs, I
>> believe, available before patches hit for browsers.
>
> Not true. Go read the incident report.

for the record:
3/21/2011 marks when the cert blacklist hit chrome (easy to find this
info, for me):
<http://googlechromereleases.blogspot.com/2011/03/stable-and-beta-channel-updates_17.html>

and this is the young man releasing some/most of the relevant details:
<http://pastebin.com/74KXCaEZ>
(also 3/21/2011)

this is the comodo blog entry:
<http://blogs.comodo.com/it-security/data-security/the-recent-ra-compromise/>
3/23/2011

so... 21 is before 23. So at least the public finds out about the
incident before a fix is available. In the end the real point here
isn't one CA is causing problems, it's the the entire system is a
house of cards. That millions of folks depend upon (as service owners
or as customers of services) a set of third parties to attest that the
connection the customer/service-owner create is 'secure' (that the
'customer' is conencted to the 'service').

We can do better, DANE potentially does much better from a risk
perspective, it removes one layer of abstraction, the service owner
can put in a public place a checksum for the ssl certificate she/he/it
installed for the service in question. A customer of that service can
validate that data in an open and simple/standards-based manner.

-chris

From [e-mail]  Mon Apr 11 21:17:46 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8C26FE06CC for <[e-mail]>; Mon, 11 Apr 2011 21:17:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -92.141
X-Spam-Level: 
X-Spam-Status: No, score=-92.141 tagged_above=-999 required=5 tests=[AWL=-11.143, BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1, URIBL_BLACK=20, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbCBqYedYi84 for <[e-mail]>; Mon, 11 Apr 2011 21:17:44 -0700 (PDT)
Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfc.amsl.com (Postfix) with ESMTP id 09BF6E0676 for <[e-mail]>; Mon, 11 Apr 2011 21:17:43 -0700 (PDT)
Received: by ewy19 with SMTP id 19so2283116ewy.31 for <[e-mail]>; Mon, 11 Apr 2011 21:17:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=t+ogoMlvrcnnWCVr8fDQVSKkvFD/VBU2pJIN6SMqKMc=; b=r8NFY5EZ+1kqJlohWC7fs0q1pthsaUH+niJEOb5lo3fEtEHQY7MZr8EPCNyfLqrCyB sGwstKStpE06ui/Y+X5eF9RhApIxR0QDiT5zL9+/VkjsGPW7oT6grDGjSjbR7zMSSvOe YZMJax5QdVpsd0qVfgsLOpn+z9GD51A/2wCCg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=eX0gxF9iU+Rfngx6X/jzbKuT0uQsL3kVPApqMJaYSIqNo54Emf9S1ZBddKMwXMsjPt Eg17aAAg6YvlvHDeceeUfiN/9rDwbYxABei8VSPj4NSiTbCsCB2GqgIYeQmadNt5onXe wIpYVlXub542it+lj1amtH6h1Yvghq+bG5clY=
MIME-Version: 1.0
Received: by 10.213.109.209 with SMTP id k17mr2618357ebp.101.1302581862623; Mon, 11 Apr 2011 21:17:42 -0700 (PDT)
Sender: [e-mail]
Received: by 10.213.33.81 with HTTP; Mon, 11 Apr 2011 21:17:42 -0700 (PDT)
In-Reply-To: <BANLkTinOqKB4vy0AcPMkimj=UtJpv=[e-mail]>
References: <[e-mail]> <BANLkTimGmtOS0=KbaChb=5F=K=[e-mail]> <BANLkTinpPyB=[e-mail]> <BANLkTinqS_Z0MfySDr=[e-mail]> <BANLkTinOqKB4vy0AcPMkimj=UtJpv=[e-mail]>
Date: Tue, 12 Apr 2011 06:17:42 +0200
X-Google-Sender-Auth: fg8RHuY9c7iVk2I6_mU8Logxlto
Message-ID: <[e-mail]>
From: Christopher Morrow <[e-mail]>
To: [e-mail]
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: [e-mail]
Subject: Re: [dane] Use Cases Document
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 12 Apr 2011 04:17:46 -0000

On Tue, Apr 12, 2011 at 1:40 AM, Kirk Hall <[e-mail]> wrote:
> Chris, thanks for your response.
>
>
>
> I agree there=92s no point in trying to define UI specs in this DANE prop=
osal
> =96 but the Abstract for DANE does say =93Instead of trusting a certifica=
tion
> authority to have made this association correctly, the user might instead
> trust the authoritative DNS server for the domain name to make that
> association.=94=A0 So the question of trust and even user reaction under =
DANE
> (trust a self-signed cert instead of a CA cert) has been introduced.=A0 A=
nd
> some people have already posted that they want browsers and other
> applications to treat a self-signed cert as equal to a DV cert under DANE=
,
> so the question of desired UI result has been introduced to the discussio=
n.

ok. perhaps they mean 'the service owner installed the cert hash in
dns'  which is a short-hand for 'a dv cert' (the owner of the domain
that the cert is being issueed for did in fact install the cert hash
into the dns).

> If the ONLY thing you want DANE to do is allow an automatic TLS connectio=
n
> at the DNS level using any cert =96 then I can see why you would think

hrm, to be careful/clear, I really want a way for a client to validate
that the serivce they connect to (https on www.you.com for example)
is:
  1) the server the service owner expected (and the cusotmer expects)
  2) the service is what the service owner setup (and the customer expects)

I think this could happen with the service-owner installs a hash of
their cert (for example) into the DNS in a DNSSEC secured zone, the
client connects to the service, receives the certificate and checks
the hash against the DNSSEC secured record.

If things check out, success. if the dnssec verification and hash
verification fails, there is a clear message that monkey-business is
afoot.

> requiring what I called an anti-fraud check is irrelevant.=A0 However, I =
fear

I don't think it's effective so it's not worth doing, and the message
to the user isn't helpful. (they don't understand anyway, generally)

> You=92re correct that phishing and fraud haven=92t used SSL much in the p=
ast =96
> I=92d argue that=92s partly because CAs generally filter out cert request=
s from
> those guys.=A0 Every day at GeoTrust we received numerous requests from

or because the bad folk know that they don't have to do this, they get
their money without the added work of getting a cert. much simpler.
much less work.

> to get the trust indicators.=A0 That=92s why I think the browsers won=92t=
 grant
> any trust indicator to DANE self-signed certs unless you provide a flag o=
r
> some other means of identification for self-signed certs that have been
> fraud-checked so they can be distinguished from other self-signed certs.

it doesn't seem helpful to me, but if it's not hurting progress of
DANE, I guess I don't care either.

> One question to you:=A0 what practical, actual, real world problem is DAN=
E
> trying to solve?=A0 Is there, in fact, a real security need today for som=
eone
> to =93know=94 that they have reached the domain they intended to reach?=
=A0 (Today,
> browsers tell you if there is a mismatch between a domain name and a
> CA-issued cert on that domain=92s servers, so to some degree that potenti=
al

they can't tell me that the cert is the cert installed by the service
owner. If the cert isn't the one the service owner installed, the
client really shouldn't connect to it, I think.

> security issue is already resolved.)=A0 Do you have examples today of act=
ual
> problems where people are unsure if they have connected with the domains
> they wanted, and there is a bad result?=A0 (And if your example depends o=
n
> =93assume there has been a compromise of the DNS=94 =96 aren=92t all bets=
 off in
> that situation, where no solution is reliable?)=A0 I=92m not trying to be

green revolution folk in iran + facebook compromises
egyptian gov't actions (monitoring of dissidents/etc)
chinese gov't actions (gfw)

all COULD monkey with dns, all more than likely were monkeying with ssl cer=
ts.

> provocative =96 I really want to know what problem that actually exists t=
oday
> would be solved with DANE.

fair enough. we can do better than today, we really should.

-Chris

>
> Thanks.
>
> On Mon, Apr 11, 2011 at 11:49 AM, Christopher Morrow
> <[e-mail]> wrote:
>>
>> On Mon, Apr 11, 2011 at 6:21 PM, Kirk Hall <[e-mail]> wrote=
:
>> > Chris =96 thanks for your response.=A0 A few comments.
>> >
>> >
>> >
>> > 1.=A0 What you call =93comodogate=94 was an extreme rarity for the CA
>> > industry,
>> > and shouldn=92t have happened.=A0 If we have the correct story, someon=
e
>> > outside
>>
>> absolutely it shouldn't have happened. it's probably the 3rd or fourth
>> thing that 'shouldn't have happened' to comodo... related to security
>> and the security of their downstream dependents.
>>
>> > the external RA was able to gain access to the RA=92s cert issuance sy=
stem
>> > remotely, and then was able to use the RA=92s system to access the CA=
=92s
>> > cert
>> > issuance system remotely and order issuance of the fake certs.=A0 I=92=
m not
>> > aware of anything like this ever happening to a CA before, and it woul=
d
>> > have
>> > been easy to prevent this breach with basic systems security.
>>
>> I'm not sure you'd (*or anyone would) know if this was going on
>> though. it only became 'known' because the alleged/admitted third
>> party bragged about his actions, in detail. It's interesting that
>> comodo was supposed (as i understand it) to be checking to be sure
>> that the didn't re-issue an already known cert to a third-party NOT
>> the owner of the trademark/domain/etc. It's fairly telling that we
>> find out about this via the 'hacker' making it very publicly known.
>> How many times did this happen before from the same RA? or the same
>> set of dependent RAs?
>>
>> At this point, anyone depending on this being the only case of this..
>> is living in a fantasy land.
>>
>> > In my mind it=92s a mistake to interpret the incident as demonstrating
>> > major
>> > vulnerability for the CA industry as a whole.=A0 As an example, if one=
 day
>> > Wells Fargo Bank=92s international wire service system is breached and
>> > accessed remotely by an intruder, and the intruder then sends
>> > unauthorized
>> > wire transfers to Nigerian bank accounts before being caught, that wou=
ld
>> > be
>> > a fairly uninteresting case of basic data system security breach, and
>> > would
>>
>> different and not related issues above skipped.
>>
>> > not imply that the entire banking system for international wire
>> > transfers
>> > was in jeopardy or need of overhaul.=A0 Likewise, if a DNS operator=92=
s
>> > system
>> > is breached remotely in a similar fashion, I assume an intruder could
>> > play
>> > games with the self-signed certificates that have been associated with=
 a
>>
>> I don't think that's a fair assumption at all. Ideally, in any sane
>> dnssec secured system the 'domain owner' has the private keys required
>> to sign his/her/their zone data. If I host my zone on your server(s)
>> and you are compromised, worst case my zone goes invalid and .. .I
>> scramble for a provider who's less compromised.
>>
>> > domain under the DANE proposal =96 but that wouldn=92t weaken DANE.=A0=
 So in
>> > all
>> > cases, basic security systems are essential.
>>
>> The basic problem as i see it with the in-place cert/ca system is that
>> my security (as a customer and a server) is reliant upon a mess of
>> folks with whom I have very little faith or ability-to-have-faith in.
>> There exist today systems that will man-in-the-middle SSL connections
>> making certs appear (that are valid because they are signed by an
>> in-browser/client ca-store) and be invisible to both sides of the
>> connection. (see mallory proxy, for a software-only solution). There
>> are folks that use systems like this to degrade the security of
>> clients/servers in the field, today.
>>
>> I don't think we want this situation to exist, I think we want to aim
>> for the best possible security position for our customers (clients and
>> servers). This means we need another method than the current CA-store
>> system to verify that a certificate is valid, one not dependent upon
>> the CA-store/chain.
>>
>> > 2.=A0 From your comments it seems you view the association of certs
>> > (self-signed or from a CA) with a domain under the DANE proposal as
>> > completely agnostic and mechanical =96 the DNS operator should accept
>> > literally any cert offered by the domain owner =96 so that DANE a
>> > technological standard with no implications for =93trust=94 as general=
ly
>> > associated with digital certificates today.
>>
>> My feeling is that folks do today, and will tomorrow, own their own
>> DNS infrastructure. In what I think your terminology is: "They are
>> both the DOMAIN OWNER and the DNS OPERATOR". Today some folks (domain
>> owners) outsource their DNS services to third-parties (dns operators),
>> it's not clear that they need to (or even are) giving their dnssec key
>> materials to the dns operator though.
>>
>> Additionally, I'd bet that in many cases the dns operators have a
>> business relationship (ongoing, monthly recurring costs) with the
>> domain owners, they ought to be able to tell if the person asking for
>> a domain to exist own the domain. (they got the NS records pointed
>> from SLD -> 3rdLD afterall)
>>
>> > That=92s fine if everyone understands that.=A0 However, it then raises=
 the
>> > question of utility of the DANE proposal once implemented.=A0 If a kno=
wn
>> > phishing domain (see the APWG solutions list at
>> > http://www.antiphishing.org/solutions.html), or a likely new fraudster
>> > who
>> > registers an available look-alike domain such as
>> > your-account-bankofamerica.com or google-accounts.com can then attach =
a
>> > self-signed cert to the domain at the DNS level (including fake
>> > Organization
>> > information, etc. inserted inside the self-signed cert), and if
>> > consumers
>> > visiting that domain are automatically put into secure encrypted mode
>> > with
>> > the site with no checking against an OCSP or CRL =85=A0 and if that se=
cure
>> > domain is given the same favorable UI or other treatment by browsers a=
nd
>> > applications indicating secure mode or domain confirmation as for all
>> > other
>> > sites =85=A0 then won=92t the public come to see the DANE solution as =
insecure
>> > and
>> > untrustworthy?
>>
>> DANE is not here to help/hurt phishers. SSL doesn't factor into
>> phishing at all... please stop conflating phishing and SSL/TLS.
>>
>> DANE is about knowing that your TLS connection to a service is to the
>> service it intended to connect to... www.bobs-balloons.com on port 443
>> sent me a cert, I can verify that the destination server's certificate
>> is the one bobs-balloons created/signed/installed.
>>
>> > Meaning if there is no way under DANE for a consumer to distinguish
>> > between
>> > legitimate sites associated with a self-signed cert and fraudulent sit=
es
>> > (i.e., those domains already tagged for phishing, or look-alike domain=
s
>> > that
>> > would be rejected by a CA for a DV cert), what advantage does a consum=
er
>>
>> like the one signed by the compromised RA in the comodogate incident?
>> yea... that fix action worked out well there. Again, phishing isn't in
>> the purview of DANE, you can't solve the phishing problem... in the
>> last 15+ years the existing oligarchy of CA folk haven't solved it
>> (because the two items are not related).
>>
>> > gain from DANE?=A0 Why not just use self-signed certs today, and ask t=
he
>> > browsers to stop showing the =93Warning =96 cert comes from an unknown=
 /
>> > untrusted root=94 display?
>>
>> this doesn't show the user that the cert delivered over the wire to
>> the client was in fact the cert that the service-owner installed. the
>> current CA system doesn't do this either, DANE has a better hope of
>> doing this, i think.
>>
>> > 3.=A0 There is a potential solution to this problem.=A0 I know some on=
 this
>> > list
>> > want to get away from having to use a CA, and there=92s a way to do th=
at
>> > and
>> > keep DANE useful.
>>
>> s/'get away from having a CA'/'get away from the trust dependency upon
>> CAs'/
>>
>> less places for risk to inject themselves.
>>
>> > On some earlier draft list of DANE specifications, I think two basic
>> > DANE
>> > cert categories were proposed: 1=3Dself signed, and 2=3DCA issued.=A0 =
Why not
>> > add
>> > a third specification: 3=3Dself signed/fraud checked.
>>
>> because 'fraud checked' means nothing wrt the purpose of DANE?
>> True/False: "this certificate presented to me is the one the service
>> owner installed"
>>
>> > Category =933=94 would be for self-signed certs that have been run thr=
ough
>> > anti-fraud checking by an independent third party like what is done
>> > today
>> > for DV certs (e.g., compare the domain against APWG phishing lists,
>> > reject
>> > look-alike domains like paypall.com unless the real paypal.com proves
>> > ownership).=A0 The checking could be done by the DNS operators or some=
one
>> > else
>> > independent of the domain owner following an industry-standard set of
>> > anti-fraud criteria =96 but the certs would NOT have to be chained to =
a
>> > CA.
>> > Once checked, the self-signed certs would get a favorable flag (=933=
=94) so
>> > that
>> > browsers, applications, and consumers could choose to trust them, but
>> > not
>> > trust self-signed certs that were not checked against fraud (Category
>> > =931=94
>> > certs).=A0 Or, the user could choose to trust all kinds of certs if th=
e
>> > user
>> > is not concerned about dealing with fraudulent domains.
>>
>> it occurs to me that you ought to take this portion of the discussion
>> to the DNS heirarchy folks (ICANN and their downstream dependents for
>> DNS zone purchase) The problem you seek to solve has nothing to do
>> with certificates, and everything to do with DNS.
>>
>> If you can't sign up for the domain: bank-of-america-auth-stealers.com
>> ... you can't put the DANE cert into the zone.
>>
>> > the padlock, etc.).=A0 Those DNS operators would no doubt be embarrass=
ed
>> > to be
>> > giving known and reported phishing domains and look-alike domains the
>> > same
>> > DANE treatment as legitimate domains.
>>
>> this doesn't seem to be a factor today.
>>
>> > To be clear, under this proposal for DANE implementation ALL self-sign=
ed
>> > certs would be accepted for association with a domain, but they would =
be
>> > marked as either being checked using anti-fraud algorithms, or not bei=
ng
>>
>> you seem to be backdooring into the UI discussion, which isn't in
>> scope and isn't relevant.
>>
>> > checked, so that later applications and consumers could decide if they
>> > wanted to trust all self-signed certs, or only a subset.
>> > Differentiating
>> > certs in this way would mean that DANE is actually useful, and might b=
e
>>
>> DANE is useful as soon as I can tell that the certificate I'm
>> presented with is in fact the certificate that the service owner
>> installed for their service.
>>
>> > Do you view this as a feasible solution?=A0 Should we add this to the
>> > draft
>> > specifications?
>>
>> I think walking down the discussion of fraud and phishing is entirely
>> the wrong path for DANE to go. DANE, nor CA's really, can not hope to
>> solve the fraud/phishing problem.
>>
>> For grins: (http urls sent in spam today so far)
>> morrowc@fire:/prod/archive/2011/04$ grep http:// 11/*.txt | wc -l
>> 392951
>>
>> HTTPS
>> morrowc@fire:/prod/archive/2011/04$ grep https:// 11/*.txt | wc -l
>> 65
>> (oddly mostly for: sears.r4sys.net which ends up bouncing properly throu=
gh
>> to:
>> Location:
>> http://www.sears.com/shc/s/v_10153_12605_Tools?lid=3Dtool_header&rioptyp=
e=3DSC&sid=3DIOx20110411SRSBAUALTSA2MMS80&eml=3D52379066&ruid=3D1003337
>> [following]
>> =A0 so this is incidental https in something, not a phishing attempt)
>>
>> I make the ssl-use-in-phishing at a number small enough that DANE
>> again shouldn't target this as a goal to solve.
>>
>> -Chris
>>
>> (in a related qestion, why doesn't affirmtrust use SSL on their forms?
>> http://www.affirmtrust.com/free-ssl-sign-up.html)
>>
>> > On Sun, Apr 10, 2011 at 7:54 AM, Christopher Morrow
>> > <[e-mail]> wrote:
>> >>
>> >> On Fri, Apr 8, 2011 at 7:36 PM, Kirk Hall <[e-mail]>
>> >> wrote:
>> >> >
>> >> > (1) CAs review DV cert requests for =93high risk=94 organization an=
d
>> >> > domain
>> >> > names that are most commonly targeted in phishing and other
>> >> > fraudulent
>> >> > schemes, and reject those cert requests.=A0 These lists include (a)
>> >> > internal
>> >>
>> >> <insert comodogate here>
>> >>
>> >> > Does DANE contemplate that the DNS operators would also reject doma=
in
>> >>
>> >> I think, from my brief reading, the 'dns operator' here is ... the
>> >> owner of the domain. So, 'stolen-bank-of-america-credentials.com' if
>> >> owned by 'evil person' could certainly publish a cert record for the
>> >> self-signed cert on their website stealing credentials from naive
>> >> users.
>> >>
>> >> how many folks really get phished/etc over ssl connections today? (no=
t
>> >> many, if any, ssl isn't a factor in this problem space)
>> >>
>> >> >
>> >> > (2) CAs also employ other anti-fraud algorithms of their own agains=
t
>> >> > bad
>> >> > DV
>> >>
>> >> <insert comodogate here>
>> >>
>> >> > Do you contemplate that DNS operators would do anything similar for
>> >> > self-signed certs?
>> >>
>> >> why would they? they are putting records into their own zone... if
>> >> somone they don't know/trust can make changes to their DNSSEC signed
>> >> DNS data... they are sunk anyway.
>> >>
>> >> > (3) DV certs have a clear chain of liability back to the issuing CA=
.
>> >> > The
>> >> > CAs
>> >> > today do a pretty good job in preventing high risk similar-named
>> >> > domains,
>> >> > like =93paypall.com=94,=A0 from getting certs for fraud and phishin=
g
>> >> > purposes.
>> >>
>> >> <insert comodogate here>
>> >>
>> >> > Under DANE, if a self-signed certificate issued in the name of
>> >> > =93paypall.com=94
>> >> > is accepted by a DNS operator and is used in phishing attacks, who
>> >> > would
>> >> > be
>> >>
>> >> the person that owns paypall.com can certainly make a self-signed
>> >> cert... and put the appropriate record into the dns zone they own, an=
d
>> >> sign it with the key they have... this isn't significantly different
>> >> than where we are today.
>> >>
>> >> > (5) Bad certs can be revoked, and the industry is working very hard
>> >> > right
>> >> > now on improving the revocation process.
>> >>
>> >> by completely sidestepping it? (let's hardcode certs into binaries,
>> >> because .. oscp is an admitted failure)
>> >>
>> >> > If there is a =93bad=94 self-signed cert associated with a domain b=
y a
>> >> > DNS
>> >> > operator and/or a DNS operator receives a report of fraud or phishi=
ng
>> >> > associated with a domain, will DANE have a way to remove, revoke, o=
r
>> >> > otherwise flag the cert as =93bad=94?
>> >>
>> >> sure, remove the record from dns (in the zone that publishes it)
>> >>
>> >> -chris
>> >
>> >
>
>

From [e-mail]  Mon Apr 11 21:19:02 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CEE4CE06CC for <[e-mail]>; Mon, 11 Apr 2011 21:19:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -97.87
X-Spam-Level: 
X-Spam-Status: No, score=-97.87 tagged_above=-999 required=5 tests=[AWL=5.729,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DsiFRTwl0E+8 for <[e-mail]>; Mon, 11 Apr 2011 21:19:02 -0700 (PDT)
Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfc.amsl.com (Postfix) with ESMTP id E8556E0676 for <[e-mail]>; Mon, 11 Apr 2011 21:19:01 -0700 (PDT)
Received: by ewy19 with SMTP id 19so2283338ewy.31 for <[e-mail]>; Mon, 11 Apr 2011 21:19:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=z7URpYrs6a5sA7cK/WXQD4ADTbNT73I3onDwK/A28BI=; b=Gz3KqUh+o+RAdHWBDRGIAdRYQ7csSEGE6JhwdQgtAtg1MxJzFbbAc9h+wzVuC3DF0C 8LbJLJ4JNwIu7aVHgIYpx9oo+sgM6KYyyuFKs6zUE7EIOd5PmTSXd1K6r+mCSFPUYbnq IlRG+zVEE/qh3LUXchMhhCT+Vx/jlYfYEAGro=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=Ko54kxYMRohI0N2eIAOTt3WEqjr6L3PGlgr4CJvlKbx9dwrpEZA5pJy1jTCJPUptMA xP5EVO2PyrEbVdeMFKt1kGa5hj/CoWHOermKJTQxGjCCy05Wwlb141pdoJqHbJPx2zBP yjp2F5IvrhrBoA82EwoSK8EFykv64hLa9FIsQ=
MIME-Version: 1.0
Received: by 10.213.109.209 with SMTP id k17mr2618682ebp.101.1302581941297; Mon, 11 Apr 2011 21:19:01 -0700 (PDT)
Sender: [e-mail]
Received: by 10.213.33.81 with HTTP; Mon, 11 Apr 2011 21:19:01 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <BANLkTimGmtOS0=KbaChb=5F=K=[e-mail]> <BANLkTinpPyB=[e-mail]> <BANLkTinqS_Z0MfySDr=[e-mail]> <[e-mail]> <[e-mail]> <BANLkTi=[e-mail]> <[e-mail]>
Date: Tue, 12 Apr 2011 06:19:01 +0200
X-Google-Sender-Auth: pW0z7HIrT1Lo1bcUJ-ox-F81XJ8
Message-ID: <[e-mail]>
From: Christopher Morrow <[e-mail]>
To: Phillip Hallam-Baker <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Cc: [e-mail], [e-mail]
Subject: Re: [dane] Use Cases Document
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 12 Apr 2011 04:19:03 -0000

On Tue, Apr 12, 2011 at 5:26 AM, Christopher Morrow
<[e-mail]> wrote:
> On Tue, Apr 12, 2011 at 12:41 AM, Phillip Hallam-Baker <[e-mail]> wrote:
>>
>>
>> On Mon, Apr 11, 2011 at 3:49 PM, Christopher Morrow
>> <[e-mail]> wrote:
>>>
>>> On Mon, Apr 11, 2011 at 9:11 PM, Phillip Hallam-Baker <[e-mail]>
>>> wrote:
>>> >
>>> >
>>> > On Mon, Apr 11, 2011 at 2:49 PM, Christopher Morrow
>>> > <[e-mail]> wrote:
>>> >>
>>> >> I'm not sure you'd (*or anyone would) know if this was going on
>>> >> though. it only became 'known' because the alleged/admitted third
>>> >> party bragged about his actions, in detail.
>>> >
>>> > No, this is an untrue accusation and must be withdrawn.
>>>
>>> pardon? the young man who put out the info did so long before the
>>> browser patches arrived. he even had the private keys and certs, I
>>> believe, available before patches hit for browsers.
>>
>> Not true. Go read the incident report.
>
> for the record:
> 3/21/2011 marks when the cert blacklist hit chrome (easy to find this
> info, for me):
> <http://googlechromereleases.blogspot.com/2011/03/stable-and-beta-channel-updates_17.html>
>
> and this is the young man releasing some/most of the relevant details:
> <http://pastebin.com/74KXCaEZ>
> (also 3/21/2011)

this is dated 3/26 actually, i read the wrong date and I've deleted
the mail I had on this at the time of the cert blacklist checkin +
discussion.

-chris

From [e-mail]  Tue Apr 12 06:42:59 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4B7EDE073D for <[e-mail]>; Tue, 12 Apr 2011 06:42:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.143
X-Spam-Level: 
X-Spam-Status: No, score=-3.143 tagged_above=-999 required=5 tests=[AWL=0.455,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JclxZDst+a+N for <[e-mail]>; Tue, 12 Apr 2011 06:42:58 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id 8BABFE07A7 for <[e-mail]>; Tue, 12 Apr 2011 06:42:58 -0700 (PDT)
Received: by vws12 with SMTP id 12so6296738vws.31 for <[e-mail]>; Tue, 12 Apr 2011 06:42:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=nlmQRipGED+ozXulddnxw6c7/nIX1pYJjK0TEFIcbmM=; b=UMg8UAQq4rQslLcEgMVh0nU5dfmRNTakz1hzZA0tKfJRPRrB82czv27F5dI5mE+bwg cMTs1fbX+c/U/ZnOqk006FCPnZRQi5okndp+0U7iNVe3TfXU/6XZrC9wJtXqy455CRxn KsVW2gbHH+AUcKVFcaQNtPjodeOiTGFakOY/4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=oM7XFl7ul/cO14pJhdh8iEUgqhGKWBwhpw+CWZhbmIBsVdR6zsAecQ2jb4qoJrXE4/ KhoeH5HszEHG56fDWXmbpti5nFbwyx7GLYKj95NuG6BkE+T4Y+xFbvyyxKQyJF1PswwV 2Ec+xpFCCt78G1zw55EZCDvEatZkKt0f+JuUQ=
MIME-Version: 1.0
Received: by 10.52.159.132 with SMTP id xc4mr1132040vdb.229.1302615778170; Tue, 12 Apr 2011 06:42:58 -0700 (PDT)
Received: by 10.52.166.230 with HTTP; Tue, 12 Apr 2011 06:42:58 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <BANLkTimGmtOS0=KbaChb=5F=K=[e-mail]> <BANLkTinpPyB=[e-mail]> <BANLkTinqS_Z0MfySDr=[e-mail]> <[e-mail]> <[e-mail]> <BANLkTi=[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 12 Apr 2011 09:42:58 -0400
Message-ID: <BANLkTi=KdE+=[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: Christopher Morrow <[e-mail]>
Content-Type: multipart/alternative; boundary=bcaec53f920bbc9aa704a0b8de7a
Cc: [e-mail], [e-mail]
Subject: Re: [dane] Use Cases Document
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 12 Apr 2011 13:42:59 -0000

--bcaec53f920bbc9aa704a0b8de7a
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Apr 12, 2011 at 12:19 AM, Christopher Morrow <
[e-mail]> wrote:
>
> > and this is the young man releasing some/most of the relevant details:
> > <http://pastebin.com/74KXCaEZ>
> > (also 3/21/2011)
>
> this is dated 3/26 actually, i read the wrong date and I've deleted
> the mail I had on this at the time of the cert blacklist checkin +
> discussion.
>
> -chris
>

So you are withdrawing your accusation?

The one thing that is known with absolute certainty about the attacker is
that they are a liar and manipulator.

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

--bcaec53f920bbc9aa704a0b8de7a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Tue, Apr 12, 2011 at 12:19 AM, Christ=
opher Morrow <span dir=3D"ltr">&lt;<a href=3D"mailto:[e-mail]=
m">[e-mail]</a>&gt;</span> wrote:<blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex;">
<div class=3D"im">
&gt; and this is the young man releasing some/most of the relevant details:=
<br>
&gt; &lt;<a href=3D"http://pastebin.com/74KXCaEZ" target=3D"_blank">http://=
pastebin.com/74KXCaEZ</a>&gt;<br>
&gt; (also 3/21/2011)<br>
<br>
</div>this is dated 3/26 actually, i read the wrong date and I&#39;ve delet=
ed<br>
the mail I had on this at the time of the cert blacklist checkin +<br>
discussion.<br>
<br>
-chris<br>
</blockquote></div><br>So you are withdrawing your accusation?<br clear=3D"=
all"><br><div>The one thing that is known with absolute certainty about the=
 attacker is that they are a liar and manipulator.</div><div><br>-- <br>
Website: <a href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br=
><br>
</div>

--bcaec53f920bbc9aa704a0b8de7a--

From [e-mail]  Tue Apr 12 06:57:25 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 79E5BE07A3 for <[e-mail]>; Tue, 12 Apr 2011 06:57:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.463
X-Spam-Level: 
X-Spam-Status: No, score=-3.463 tagged_above=-999 required=5 tests=[AWL=0.136,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPymDbSC6URe for <[e-mail]>; Tue, 12 Apr 2011 06:57:24 -0700 (PDT)
Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfc.amsl.com (Postfix) with ESMTP id 63898E0697 for <[e-mail]>; Tue, 12 Apr 2011 06:57:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=[e-mail]; q=dns/txt; s=uoa; t=1302616645; x=1334152645; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20<[e-mail]> |To:=[e-mail],=[e-mail]|Subject:=20R e:=20[dane]=20Use=20Cases=20Document|Cc:=[e-mail] |In-Reply-To:=20<BANLkTi=3D_=3Dgrvg0U1u6dtGqHv+mdqE=3DPBw [e-mail]>|Message-Id:=20<E1Q9e5r-0000yP-Cf@login0 1.fos.auckland.ac.nz>|Date:=20Wed,=2013=20Apr=202011=2001 :57:23=20+1200; bh=6bUt0DngOzhGGh720t1tqFYJw4q4EfJR9nfF8Nd1O3w=; b=nVazWFZDzuDhZ8h+gCFes7JHtg4JYSr1Xuz1R/mj2tvMSgFpp8IS877q dKYRLSYhY3eysQt3zIi8PZ3id4lruxj72tu1aU9Z7krTkJg4xP8QOQO4t bqdgMMAXMZRJ7KMxWuyq92wNe1Qaqn2tPGBXt2S4ga/7DvkFIKIrW4zHb Y=;
X-IronPort-AV: E=Sophos;i="4.64,195,1301832000"; d="scan'208";a="56451868"
X-Ironport-HAT: APP-SERVERS - $RELAYED
X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing
Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 13 Apr 2011 01:57:23 +1200
Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <[e-mail]>) id 1Q9e5r-0005MJ-HY; Wed, 13 Apr 2011 01:57:23 +1200
Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from <[e-mail]>) id 1Q9e5r-0000yP-Cf; Wed, 13 Apr 2011 01:57:23 +1200
From: Peter Gutmann <[e-mail]>
To: [e-mail], [e-mail]
In-Reply-To: <BANLkTi=_=grvg0U1u6dtGqHv+mdqE=[e-mail]>
Message-Id: <[e-mail]>
Date: Wed, 13 Apr 2011 01:57:23 +1200
Cc: [e-mail]
Subject: Re: [dane] Use Cases Document
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 12 Apr 2011 13:57:25 -0000

Phillip Hallam-Baker <[e-mail]> writes:

>The CA has a mechanism that notifies the RA every time a certificate is
>issued. The RA knew it had not requested the certs and that they must
>therefore have been a breach.

This statement, while technically correct, is right up there with "Our CA key
was never compromised, therefore everything's OK".  According to ComodoHacker,
the number of certs this RA processes is practically nonexistent (one every
four or five days).  So what caused the RA to become suspicious isn't any
careful checking of the details of the certs that were issued but surprise at
the fact that any certs had been issued at all.  In addition ComodoHacker
pretty comprehensively owned the RA, their machines, email accounts, the lot.
If this had been a real attack rather than a kid having some fun then the
notification to the attacker-controlled RA would have had no effect.

Finally, looking at the claim that the CA didn't know about the compromise
until the attacker told them about it:

  the Comodo Partner Account that suffered the security breach has (totally,
  utterly and definitely) *not* mis-issued any further certificates, and we
  are not aware that any other Accounts have been breached
  - Rod Stradling, Comodo, 18 March 2011

  I hacked so much Comodo reseller account, but all of them was not able to
  use ApplySSL API. [...] From listed resellers of Comodo, I owned 3 of them,
  not only Italian one
  -- ComodoHacker, 29 March 2011

Still, detecting one out of three isn't so bad.  Somewhat worse than flipping
a coin, but not quite as bad as a broken clock.

So far from being a case of "our audit mechanisms were working as intended" it
was "man, was that ever a string of lucky breaks for us".

Peter.

From [e-mail]  Tue Apr 12 07:04:06 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D6010E07AF for <[e-mail]>; Tue, 12 Apr 2011 07:04:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.654
X-Spam-Level: 
X-Spam-Status: No, score=-102.654 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9nt9sY0+tafE for <[e-mail]>; Tue, 12 Apr 2011 07:04:06 -0700 (PDT)
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfc.amsl.com (Postfix) with ESMTP id 36000E079E for <[e-mail]>; Tue, 12 Apr 2011 07:04:06 -0700 (PDT)
Received: from shinkuro.com (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 6C9821ECB41D for <[e-mail]>; Tue, 12 Apr 2011 14:04:05 +0000 (UTC)
Date: Tue, 12 Apr 2011 10:04:03 -0400
From: Andrew Sullivan <[e-mail]>
To: [e-mail]
Message-ID: <[e-mail]>
References: <[e-mail]> <BANLkTimGmtOS0=KbaChb=5F=K=[e-mail]> <BANLkTinpPyB=[e-mail]> <BANLkTinqS_Z0MfySDr=[e-mail]> <[e-mail]> <[e-mail]> <BANLkTi=[e-mail]> <[e-mail]> <[e-mail]> <BANLkTi=KdE+=[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <BANLkTi=KdE+=[e-mail]>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: [dane] Concentrating on document? (was:  Use Cases Document)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 12 Apr 2011 14:04:07 -0000

Dear colleagues,

This is not to pick on Phill, but to suggest that this thread is not
going to yield results.  I would like to suggest that we stop debating
this sub-topic and focus on those areas where we can produce useful
results, such as the actual statement of things we are positively
going to be able to do.

Best regards,

A


-- 
Andrew Sullivan
[e-mail]
Shinkuro, Inc.

From [e-mail]  Tue Apr 12 07:06:21 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CA890E07AF for <[e-mail]>; Tue, 12 Apr 2011 07:06:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.651
X-Spam-Level: 
X-Spam-Status: No, score=-102.651 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43+aGID-MLPp for <[e-mail]>; Tue, 12 Apr 2011 07:06:21 -0700 (PDT)
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfc.amsl.com (Postfix) with ESMTP id 6092BE0761 for <[e-mail]>; Tue, 12 Apr 2011 07:06:21 -0700 (PDT)
Received: from shinkuro.com (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id F40EE1ECB41D for <[e-mail]>; Tue, 12 Apr 2011 14:06:20 +0000 (UTC)
Date: Tue, 12 Apr 2011 10:06:19 -0400
From: Andrew Sullivan <[e-mail]>
To: [e-mail]
Message-ID: <[e-mail]>
References: <BANLkTi=_=grvg0U1u6dtGqHv+mdqE=[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [dane] Use Cases Document
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 12 Apr 2011 14:06:21 -0000

On Wed, Apr 13, 2011 at 01:57:23AM +1200, Peter Gutmann wrote:
> 
> This statement, while technically correct, is right up there with "Our CA key
> was never compromised, therefore everything's OK".  

Ok, I just asked vaguely, but now I will ask more pointedly: what in
the world does that have to do with advancing the problem statement?
If you have text that should go in a problem statement draft, then
propose it.  But fighting about someone's operational practices --
regardless of how anyone feels about it -- is completely irrelevant
here to what we are trying to do.  We will never make any progress at
all if we sink ourselves in this debate.

A

-- 
Andrew Sullivan
[e-mail]
Shinkuro, Inc.

From [e-mail]  Tue Apr 12 07:42:50 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1FE2FE0798 for <[e-mail]>; Tue, 12 Apr 2011 07:42:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.487
X-Spam-Level: 
X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QufOyxgeZm2H for <[e-mail]>; Tue, 12 Apr 2011 07:42:49 -0700 (PDT)
Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfc.amsl.com (Postfix) with ESMTP id 306A5E07BB for <[e-mail]>; Tue, 12 Apr 2011 07:42:49 -0700 (PDT)
Received: from [172.19.118.183] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 3C0661B40CBF; Tue, 12 Apr 2011 10:42:48 -0400 (EDT)
Message-Id: <[e-mail]>
From: Warren Kumari <[e-mail]>
To: Andrew Sullivan <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Tue, 12 Apr 2011 10:42:46 -0400
References: <BANLkTi=_=grvg0U1u6dtGqHv+mdqE=[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.936)
Cc: [e-mail]
Subject: Re: [dane] Use Cases Document
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 12 Apr 2011 14:42:50 -0000

Yup, Andrew is 100% correct -- on my todo list for this morning was to  
rein (reign?!) in this discussion, both because it has gotten  
completely off-topic and because it is becoming needlessly personal...  
I should have done this a few days ago, but to be entirely honest I  
got sucked in and wanted to see where the rabbit-hole led...

I think that we can safely say (as our doc currently does) that "Some  
people want a different way to authenticate the association of the  
server's certificate with the intended domain name without trusting a  
CA.", further exploration of why is only going to lead to tears...

Thanks again to Andrew for helping keep us on-topic. Those of you who  
know me personally know how easily distracted (and prone to ratholing)  
I am...

W


On Apr 12, 2011, at 10:06 AM, Andrew Sullivan wrote:

> On Wed, Apr 13, 2011 at 01:57:23AM +1200, Peter Gutmann wrote:
>>
>> This statement, while technically correct, is right up there with  
>> "Our CA key
>> was never compromised, therefore everything's OK".
>
> Ok, I just asked vaguely, but now I will ask more pointedly: what in
> the world does that have to do with advancing the problem statement?
> If you have text that should go in a problem statement draft, then
> propose it.  But fighting about someone's operational practices --
> regardless of how anyone feels about it -- is completely irrelevant
> here to what we are trying to do.  We will never make any progress at
> all if we sink ourselves in this debate.
>
> A
>
> -- 
> Andrew Sullivan
> [e-mail]
> Shinkuro, Inc.
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane
>


From [e-mail]  Tue Apr 12 08:23:58 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BBE0BE07C0 for <[e-mail]>; Tue, 12 Apr 2011 08:23:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.162
X-Spam-Level: 
X-Spam-Status: No, score=-3.162 tagged_above=-999 required=5 tests=[AWL=0.436,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xqnz1YgYd8DY for <[e-mail]>; Tue, 12 Apr 2011 08:23:58 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id E5BBCE07A0 for <[e-mail]>; Tue, 12 Apr 2011 08:23:57 -0700 (PDT)
Received: by vws12 with SMTP id 12so6405039vws.31 for <[e-mail]>; Tue, 12 Apr 2011 08:23:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9ThF9kL5AlrP2Lb6dGRjDDO70BQSmmYZ3SBvwHiOjKQ=; b=skMjAOKQIK3zY/z+a/ddqRjbFkggDdRzElSEpBgVDJeKH75ihH7E7aCcnlClP0O0Y9 RlPX5uh486ht4+saRoGcbvGxAvrRjDILtK/NxcyhuTB5h8FXji9CpXi0IugqEIbTk2lY 6PvH6rZEh9NphLymuh7t704ZwM88v3JaTPwkY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=nZfuY/WYDDmoZcGbngcqcwvO7/AxpK4mdIGrKm2Q5ytBl6Uffb/cH8nfLzWG29mOgQ nv1toVSfJTedw8+fH0RAe1e5y+Xv+Zo8yaIssh+2FDzwnD7grGftX4QrG+mvxF9CndQC wfX4hfDwoBNWtWwvkj5GFPEL99kW6dMDxQ4MU=
MIME-Version: 1.0
Received: by 10.52.18.11 with SMTP id s11mr1498632vdd.269.1302621837597; Tue, 12 Apr 2011 08:23:57 -0700 (PDT)
Received: by 10.52.166.230 with HTTP; Tue, 12 Apr 2011 08:23:57 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <BANLkTimGmtOS0=KbaChb=5F=K=[e-mail]> <BANLkTinpPyB=[e-mail]> <BANLkTinqS_Z0MfySDr=[e-mail]> <[e-mail]> <[e-mail]> <BANLkTi=[e-mail]> <[e-mail]> <[e-mail]> <BANLkTi=KdE+=[e-mail]> <[e-mail]>
Date: Tue, 12 Apr 2011 11:23:57 -0400
Message-ID: <BANLkTinMK7OGvv_Oy7504=[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: Andrew Sullivan <[e-mail]>
Content-Type: multipart/alternative; boundary=20cf3054a113e8257804a0ba472e
Cc: [e-mail]
Subject: Re: [dane] Concentrating on document? (was: Use Cases Document)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 12 Apr 2011 15:23:58 -0000

--20cf3054a113e8257804a0ba472e
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Apr 12, 2011 at 10:04 AM, Andrew Sullivan <[e-mail]> wrote:

> Dear colleagues,
>
> This is not to pick on Phill, but to suggest that this thread is not
> going to yield results.  I would like to suggest that we stop debating
> this sub-topic and focus on those areas where we can produce useful
> results, such as the actual statement of things we are positively
> going to be able to do.
>

I don't think we have yet got people to an understanding of what a use case
is. The point of use case analysis is to consider requirements at a higher
level of abstraction. Most of the 'use cases' being proposed are of the form
'Alice wants to use technology X'.

A use case should only relate to issues that the typical user is going to be
faced with. In the case of DANE it would be at the level of the instructions
that a typical client would give their network administration contractor to
implement.


Technical issues are introduced into a use case analysis by means of
constraints.

So a use case for email would be 'Alice wants to send a message to Bob', the
requirement to support SMTP would come from the constraint 'SMTP is the only
email protocol supported by 100% of Internet email servers'.


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

--20cf3054a113e8257804a0ba472e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Tue, Apr 12, 2011 at 10:04 AM, Andrew=
 Sullivan <span dir=3D"ltr">&lt;<a href=3D"mailto:[e-mail]">ajs@shi=
nkuro.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Dear colleagues,<br>
<br>
This is not to pick on Phill, but to suggest that this thread is not<br>
going to yield results. =A0I would like to suggest that we stop debating<br=
>
this sub-topic and focus on those areas where we can produce useful<br>
results, such as the actual statement of things we are positively<br>
going to be able to do.<br></blockquote><div><br></div><div>I don&#39;t thi=
nk we have yet got people to an understanding of what a use case is. The po=
int of use case analysis is to consider requirements at a higher level of a=
bstraction. Most of the &#39;use cases&#39; being proposed are of the form =
&#39;Alice wants to use technology X&#39;.=A0</div>
<div><br></div><div>A use case should only relate to issues that the typica=
l user is going to be faced with. In the case of DANE it would be at the le=
vel of the instructions that a typical client would give their network admi=
nistration contractor to implement.</div>
<div><br></div><div><br></div><div>Technical issues are introduced into a u=
se case analysis by means of constraints.</div><div><br></div><div>So a use=
 case for email would be &#39;Alice wants to send a message to Bob&#39;, th=
e requirement to support SMTP would come from the constraint &#39;SMTP is t=
he only email protocol supported by 100% of Internet email servers&#39;.</d=
iv>
<div>=A0</div></div><br>-- <br>Website: <a href=3D"http://hallambaker.com/"=
>http://hallambaker.com/</a><br><br>

--20cf3054a113e8257804a0ba472e--

From [e-mail]  Tue Apr 12 09:46:17 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9AD7DE0857 for <[e-mail]>; Tue, 12 Apr 2011 09:46:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.943
X-Spam-Level: 
X-Spam-Status: No, score=-9.943 tagged_above=-999 required=5 tests=[AWL=0.306,  BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MzUTNWLAGNVx for <[e-mail]>; Tue, 12 Apr 2011 09:46:17 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfc.amsl.com (Postfix) with ESMTP id D1EFFE0854 for <[e-mail]>; Tue, 12 Apr 2011 09:46:16 -0700 (PDT)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p3CGjado019233 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Apr 2011 18:45:36 +0200 (MEST)
From: Martin Rex <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail] (Stephen Kent)
Date: Tue, 12 Apr 2011 18:45:30 +0200 (MEST)
In-Reply-To: <p06240807c9c8e4be1d0e@[128.89.89.213]> from "Stephen Kent" at Apr 11, 11 01:21:38 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: [e-mail]
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 12 Apr 2011 16:46:17 -0000

Stephen Kent wrote:
> 
> >For safety, it would be sensible to ALWAYS treat X.509v1 certs as
> >EndEntity certs (i.e. never accept them as signer of other certs).
> >Our TLS implementation had done this initially, but we had a customer
> >that had obtained server certs issued under a VeriSign X.509v1 CA cert
> >(as late as 2006!), so I had to make our OEM implementation tolerate this.
> 
> The fact that v1 certs contained no mechanism to distinguish between
> an EE cert and a CA cert was a major vulnerability, one that has been
> exploited in the browser context. I doubt that the IESG will approve
> an RFC that calls for supporting v1 certs at this time.

Leaving the status of X.509v1 certs in limbo is a really bad idea.

>From the SSLiverse data, it seems that there most of the self-signed
certs out there (500.000) are X.509v1.

Since DANE is a new protocol requiring new implementations, it seems
like a pretty bad idea to entirely ignore the installed base or to
leave the behaviour unspecified.

It does not seem sensibe to require 500.000 server admins to recreate
their self-signed server cert either as an X.509v3 CA cert used by
an End-Entity or as a self-signed X.509v3 End-Entity cert that is invalid
according to rfc-5280.

It would be much more sensible to require (a) support for X.509v1
self-signed end-entity certs and require (b) that X.509v1 certs
must NEVER be accepted as signers of other certs in certificate
path validations.

-Martin

From [e-mail]  Tue Apr 12 15:04:53 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 40F9BE07E3 for <[e-mail]>; Tue, 12 Apr 2011 15:04:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.95
X-Spam-Level: 
X-Spam-Status: No, score=-9.95 tagged_above=-999 required=5 tests=[AWL=0.299,  BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDsNc5Lt6J-Z for <[e-mail]>; Tue, 12 Apr 2011 15:04:51 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfc.amsl.com (Postfix) with ESMTP id 9BF72E079B for <[e-mail]>; Tue, 12 Apr 2011 15:04:51 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p3CM4c5b024898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 13 Apr 2011 00:04:38 +0200 (MEST)
From: Martin Rex <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail] (Stephen Kent)
Date: Wed, 13 Apr 2011 00:04:38 +0200 (MEST)
In-Reply-To: <p0624080bc9c8e967349b@[128.89.89.213]> from "Stephen Kent" at Apr 11, 11 03:47:59 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: [e-mail]
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 12 Apr 2011 22:04:53 -0000

Stephen Kent wrote:
> 
> At 2:49 PM +0100 4/8/11, Stephen Farrell wrote:
> >...
> >
> >5280 is IMO properly silent on how EEs might use self-signed
> >certs. (Or if not, I've forgotten what it says on that;-)

I agree with Stephen!

> 
> I'll help with a few cites from 5280:
> 
> >3.2:
> >
> >This specification covers two classes of certificates: CA 
> >certificates and end entity certificates.  CA certificates may be 
> >further divided into three classes: cross-certificates, self-issued 
> >certificates, and self-signed certificates.  Cross-certificates are 
> >CA certificates in which the issuer and subject are different 
> >entities.  Cross-certificates describe a trust relationship between 
> >the two CAs.  Self-issued certificates are CA certificates in which 
> >the issuer and subject are the same entity.  Self-issued 
> >certificates are generated to support changes in policy or 
> >operations.  Self-signed certificates are self-issued certificates 
> >where the digital signature may be verified by the public key bound 
> >into the certificate.  Self-signed certificates are used to convey a 
> >public key for use to begin certification paths.  End entity 
> >certificates are issued to subjects that are not authorized to issue 
> >certificates.
> 
> This text says that a self-signed certificate is a CA certificate, 
> period. The last sentence says that an EE certificate cannot be used 
> to verify a signature on another certificate, and thus it is not a CA 
> certificate, and thus, not self-signed.

That is not what rfc5280 says here.  It is really silent on
self-asserted or self-issued End Entity certs.

The quoted paragraph specifies, that rfc5280 profiles _only_ the following
subset of X.509v3 certs:

  1.) CA certs of class "cross-certificates"
  2.) CA certs of class "self-issued certificates"
  3.) CA certs of class "self-signed certificates"
  4.) CA-issued End entity certificates

And what you misread is the definiton:

  CA certificates of class self-issued certificates are certificates
  in which the isser and subject are the same entity.

So with a pedantic reading rfc-5280, the Internet Certificate and CRL
Profile, does not currently define a self-issued X.509v3 End Entity cert.


I'm somwhat puzzled about the description of (1) in 5280 section 3.2
and the lack of description of a regular intermediate CA cert.

My familiarity with X.509 and PKI is limited, so I may be wrong,
but wasn't cross-certificates originally used for CAs that mutually
sign each others public key in order to cross over between independent
CA hierarchies?


> 
> >4.2.1.1 (AKI)
> >
> >The keyIdentifier field of the authorityKeyIdentifier extension MUST 
> >be included in all certificates generated by conforming CAs to 
> >facilitate certification path construction.  There is one exception; 
> >where a CA distributes its public key in the form of a "self-signed" 
> >certificate, the authority key identifier MAY be omitted.
> 
> This text says further reiterates the notion that a self-signed 
> certificate is not an EE certificate. Note that in this text the 
> exception discusses the context where a CA distributes its public key 
> via a self-signed certificate, i.e., where the self-signed 
> certificate is used as a container to distribute a trust anchor. This 
> is the relevant case for DANE.

Any rules in rfc-5280 apply only to the subset of X.509v3 certs
listed in section 3.2 -- so it can, by definition, not apply to
self-issued X.509v3 End-entity certs.


> 
> >4.2.1.3 (KU)
> >
> >The keyCertSign bit is asserted when the subject public key is  used 
> >for verifying signatures on public key certificates.  If the 
> >keyCertSign bit is asserted, then the cA bit in the basic 
> >constraints extension (Section 4.2.1.9) MUST also be asserted.
> >
> >If the keyUsage extension is present, then the subject public key 
> >MUST NOT be used to verify signatures on certificates or CRLs unless 
> >the corresponding keyCertSign or cRLSign bit is set.
> 
> This text says that a valid CA certificate MUST contain the basic 
> constraints extension with the CA flag set TRUE, thus 5280 requires 
> CA certificates to be v3.

Correct.  I'm just fine with this requirement.

I am more than willing to disable the hack that was needed for this
legacy VeriSign X.509v1 TLS SErver CA in 2006!  But those VeriSign
X.509v1 certs are still distributed with all browsers with a
validity until 2026 -- (and a 1024-bit RSA keypair for which
an MD2withRsaEncryption signature was published...).


>
> It also establishes required values for key 
> usage extension flags if the certificate is to be used to verify 
> signatures on other certificates, i.e., if the certificate is to be 
> used as a CA certificate.

"verify signatures on other certificates".  With the exception of
split personalities, this is not the same as verifying the signature
on one's own certificates.


> 
> >4.2.1.9 (Basic Constraints):
> >
> >The basic constraints extension identifies whether the subject of 
> >the certificate is a CA and the maximum depth of valid certification 
> >paths that include this certificate.
> >
> >Conforming CAs MUST include this extension in all CA certificates 
> >that contain public keys used to validate digital signatures on 
> >certificates and MUST mark the extension as critical in such 
> >certificates.
> 
> Again, 5280 says that a CA certificate is a v3 certificate.

It says that conforming CAs must use X.509v3 certs exclusively that
contain the Basic Constraints extension "cA=TRUE" marked critical.

It seems that entirely omitting the KeyUsage extension is fine
with 5280 (to avoid any confusion around keyCertSign for self-issued
end entity certs).

 
> 
> >
> >>  This may be true in theory, but is far from true in practice - in
> >>  practice, I can put a self-signed cert on my website and it works just
> >>  fine (in the sense that it is not considered malformed, just rather
> >>  untrustworthy).
> >>
> >>  So, this is just spec lawyering.
> >
> >Some data: both SIP (rfc3261) and S/MIME (rfc5750) explicitly
> >allow self-signed certs. SDP/TLS (rfc4572) seems to have an
> >entire section about them. And of course TLS (rfc5246) says
> >you MAY include them.
> 
> I looked at the 4 cites you provided above.  Only two of them support 
> your conclusion that it's OK to call for using an SS cert as an EE 
> cert.
> 
> When I scan 5246 I find one reference to a self-signed cert (page 48).
> That text is talking about a "root certificate [sic] authority." So that
> reference is NOT talking about SS certs as EE certs.

You are looking in the wrong place:

  TLSv1.0:    http://tools.ietf.org/html/rfc2246#section-7.4.2
  TLSv1.1:    http://tools.ietf.org/html/rfc4346#section-7.4.2

   7.4.2. Server certificate

      [...]

   Meaning of this message:
       The certificate type must be appropriate for the selected cipher
       suite's key exchange algorithm, and is generally an X.509v3
       certificate. It must contain a key which matches the key exchange
       method, as follows.

rfc5246 did not supersede nor obsolete any prior TLS specifications,
it describes _only_ TLSv1.2,  The marker on the document is obviously wrong.
IPv6 did not obsolete IPv4,  HTTPv1.1 did no obsolete HTTP1.0.

Btw. OpenSSL does not support TLSv1.2 yet, and Windows 6.1
(aka Windows 7 and Windows Server 2008R2) ships with TLSv1.2 disabled
on the server end (potentially for similiar reasons -- the TLSv1.2 breakage
of the handshake message hash design through SignatureAndHashAlgorithms),
so you hardly find TLSv1.2 being used on the internet.

> 
> RFC 5750 appears to contain two references to self-signed certs (page 8)
> and both refer to CA certs, not to EE certs. So, again, this 
> reference is NOT talking about SS certs as EE certs.

But it says this:

http://tools.ietf.org/html/rfc5750#section-2.2

2.2.  Certificate Choices

   Receiving agents MUST support v1 X.509 and v3 X.509 certificates as
   profiled in [KEYM].  End-entity certificates MAY include an Internet
   mail address, as described in Section 3.

So rfc5750 (issued January 2010) has a "MUST support X.509v1" certs.
And there is _no_ limit in rfc5750 to support X.509v1 self-signed
end entity certs or X.509v3 self-signed end entity certs beyond rfc5280.


> 
> RFC 4572 makes a number of references to SS certs, and it does
> envision using them as EE certs. However, the security analysis for using
> SS certs here is flawed. For example it says (page 9) that it's OK to
> use a SS cert to assert ANY identity in the TLS session or in an 
> S/MIME-protected SDP exchange.

Where is your problem.  It is completely irrelevant which identity
self-signed end entity certificates assert, because these name
must be ignored anyway.  The only thing that really counts in the
public key -- and the public key represents the end entity.
the name in there is only a self-asserted tag within the
X.509 public key container

> 
> In the name of interoperability, the 
> RFC also says (page 9) that if hop-by-hop integrity is employed for 
> SDP, then an SS cert is OK too, even though this allows any SDP 
> entity along the path to spoof any other entity.

Authentication of self-signed entity certs is solely based on the public key,
the identities are completely irrelevant.


> 
> RFC 3261 has references to SS certs that are clearly used as EE 
> certs. The six references to SS certs in that doc (on pages 202-204 
> and 248) equate them to "certificates signed by an obscure 
> authority."  Oh well, guess nobody who cared about PKIX bothered to 
> read 200+ pages into a 270 page doc to find that error :-), back in 
> 2002.


http://tools.ietf.org/html/rfc3261#page-202

                             As an alternative, users MAY create self-
   signed certificates.  The implications of self-signed certificates
   are explored further in Section 26.4.2.  Implementations may also use
   pre-configured certificates in deployments in which a previous trust
   relationship exists between all SIP entities.

http://tools.ietf.org/html/rfc3261#section-26.4.2

The text in section 26.4.2 is pretty clear on the use of self-signed
certificate an it is far from being obscure.  It compares the key
distribution problem for the initial encounter to SSH -- which is
the classical and a quite popular and successful trust management
scheme for bare public keys.  Self-issued X.509 certs are conceptually
the same as bare public keys, just with extra, integrity-protected,
self-asserted stuffing.


-Martin

From [e-mail]  Tue Apr 12 15:34:31 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 45F81E093F for <[e-mail]>; Tue, 12 Apr 2011 15:34:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.957
X-Spam-Level: 
X-Spam-Status: No, score=-9.957 tagged_above=-999 required=5 tests=[AWL=0.292,  BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69QaV7NjoDXg for <[e-mail]>; Tue, 12 Apr 2011 15:34:30 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfc.amsl.com (Postfix) with ESMTP id 8179EE0936 for <[e-mail]>; Tue, 12 Apr 2011 15:34:30 -0700 (PDT)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p3CMYSpM021576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 13 Apr 2011 00:34:28 +0200 (MEST)
From: Martin Rex <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail] (Phillip Hallam-Baker)
Date: Wed, 13 Apr 2011 00:34:27 +0200 (MEST)
In-Reply-To: <BANLkTi=5rCGVPPiBVUd0oVm9F-big4R=[e-mail]> from "Phillip Hallam-Baker" at Apr 8, 11 09:11:50 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: [e-mail]
Subject: Re: [dane] Requirements - HTTPS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: [e-mail]
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 12 Apr 2011 22:34:31 -0000

Phillip Hallam-Baker wrote:
> 
> ?? As a reality check here, the browser providers have taken ten years to
> get round to doing hard fail on OCSP.

I think that the original concept behind OCSP for online communication
is extremely broken.

The only online communication/authentication architecture in which OCSP
would make sense is when the certificate holder is required to include
fresh (a few hours) copies of all OCSP response to verify all certs
in that entities certificate chain.  Maybe provide an option to each
peer how "fresh" these proof should be.

In such a scenario, the caching of OCSP responses works, there is no
privacy problem because only the holder of the certificate is requesting
OCSP responses from his issuing CA(s) on a regular basis, and the
holder of the certificate is in the best position to make these
communication links available, robust and low-latency (even out-of-band
updating of cached OCSP responses works just fine).


The original design, where the browser has to poll revocation info
from various places doesn't scale at all, in horribly unreliable
and a serious privacy problem.


-Martin

From [e-mail]  Tue Apr 12 19:14:49 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 71334E071F for <[e-mail]>; Tue, 12 Apr 2011 19:14:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.472
X-Spam-Level: 
X-Spam-Status: No, score=-3.472 tagged_above=-999 required=5 tests=[AWL=0.127,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wV38pO4Sg4HP for <[e-mail]>; Tue, 12 Apr 2011 19:14:48 -0700 (PDT)
Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfc.amsl.com (Postfix) with ESMTP id 6A57DE066C for <[e-mail]>; Tue, 12 Apr 2011 19:14:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=[e-mail]; q=dns/txt; s=uoa; t=1302660889; x=1334196889; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20<[e-mail]> |To:=[e-mail],=[e-mail]|Subject:=20R e:=20[dane]=20Use=20Cases=20Document|Cc:=[e-mail] |In-Reply-To:=20<9030B359-ECBE-4C94-8799-9403483E3FE9@kum ari.net>|Message-Id:=20<[e-mail] kland.ac.nz>|Date:=20Wed,=2013=20Apr=202011=2014:14:44=20 +1200; bh=i0mbqOvfA6T10oiE09+h63BrL8QlG/4Kd+6EcUgvlDA=; b=GfmwOu0HJSI36smTSpE6kU0FDsg/Y6nbKwz0fchebnSeiCee/dRpdiQ/ t5TrVG18ZGjknjT9YUK8fsvd5f0Z1q3JR69T5BFqhpE99DWrbbUWNqcBr OmkIHC4CbCSlT8i1Cu/V9848erw71ClQF/qnKMP2RRravifyfl0g1PA3h M=;
X-IronPort-AV: E=Sophos;i="4.64,201,1301832000"; d="scan'208";a="56554498"
X-Ironport-HAT: APP-SERVERS - $RELAYED
X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing
Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 13 Apr 2011 14:14:44 +1200
Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <[e-mail]>) id 1Q9pbQ-0005lJ-H4; Wed, 13 Apr 2011 14:14:44 +1200
Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from <[e-mail]>) id 1Q9pbQ-0001q8-7d; Wed, 13 Apr 2011 14:14:44 +1200
From: Peter Gutmann <[e-mail]>
To: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Date: Wed, 13 Apr 2011 14:14:44 +1200
Cc: [e-mail]
Subject: Re: [dane] Use Cases Document
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 13 Apr 2011 02:14:49 -0000

Warren Kumari <[e-mail]> writes:

>Yup, Andrew is 100% correct -- on my todo list for this morning was to rein 
>(reign?!) in this discussion, both because it has gotten completely off-topic

The point in continuing it was to try to get more insight into current failure 
modes.  Theorising over usage cases (real or imagined) didn't seem too useful
unless we could first understand how things are failing today.  So rather than
being a flamewar I saw it as laying useful groundwork for things that needed
fixing.

Peter.

From [e-mail]  Tue Apr 12 20:09:13 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 53536E0691 for <[e-mail]>; Tue, 12 Apr 2011 20:09:13 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KM7TqZdHIijF for <[e-mail]>; Tue, 12 Apr 2011 20:09:11 -0700 (PDT)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfc.amsl.com (Postfix) with ESMTP id 8E7F4E0687 for <[e-mail]>; Tue, 12 Apr 2011 20:09:11 -0700 (PDT)
Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id A53C4C52B for <[e-mail]>; Tue, 12 Apr 2011 23:09:09 -0400 (EDT)
Date: Tue, 12 Apr 2011 23:09:09 -0400 (EDT)
From: Paul Wouters <[e-mail]>
To: [e-mail]
Message-ID: <[e-mail]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Subject: [dane] dane DNS record generator (service and software)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 13 Apr 2011 03:09:13 -0000

Hi,

I wrote a new tool to help people deploy and test DANE style DNS records.

You can use the following service to generate DANE records for your HTTPS
server:

https://dane.xelerance.com/

It currently supports only EE-certs with reference type 0,1 and 2. It
uses the same private RRTYPE number (65468) as Matt's nss-dane patch at:

https://mattmccutchen.net/cryptid/#nss-dane

The website is a small wrapper around the "dane" command, which I added to the
sshfp software package at ftp://ftp.xelerance.com/sshfp/sshfp-1.2.0.tar.gz
(I will probably soon rename the package 'sshfp' to something more appropriate)

Note that Matt's nss dane patch at still uses SHA1 for reference type 1,
and not SHA256 as per current dane 06 specification, so DNS records generated
with the "dane" command do not yet work with the patch at Matt's site.

The software version also supports an AXFR mode to deploy dane records
for all your A/AAAA records. If multple A/AAAA records use different SSL certs,
all are included.

Example use of the dane command:

[paul@thinkpad sshfp]$ ./dane --help
usage: dane [-h] [-n nameserver] [--axfr] [--draft] [--rfc] [--tlsa]
             [--eecert] [--cacert] [--pubkey] [--txt] [--sha256] [--sha512]
             [--full] [--insecure] [-4] [-6] [-q]
             hostname [hostname ...]

Create TLS related DNS records for hosts or an entire zone.

positional arguments:
   hostname

optional arguments:
   -h, --help            show this help message and exit
   -n nameserver, --nameserver nameserver
                         nameserver to query
   --axfr                use AXFR (all A/AAAA records will be scanned)
   --draft               output in draft private rrtype (65468/65469) format
                         (default)
   --rfc                 output in rfc (TLSA/HASTLS) rrtype format
   --tlsa                generate TLSA record (default:yes)
   --eecert              use EEcert for TLSA record (default)
   --cacert              use CAcert for TLSA record
   --pubkey              use pubkey for TLSA record (not supported yet)
   --txt                 generate Kaminsky style TXT record (not supported yet)
   --sha256              use SHA256 for the TLSA cert type
   --sha512              use SHA512 for the TLSA cert type
   --full                use full certificate for the TLSA cert type
   --insecure            allow use of non-dnssec answers to find SSL hosts
   -4                    use ipv4 networking only
   -6                    use ipv6 networking only
   -q, --quiet           suppress warnings and errors

[paul@thinkpad ~]$ dane www.xelerance.com
_443._tcp.www.xelerance.com. IN TYPE65468 \# 34 010130102FA54AE5CD5852D0CFAF1FE5F467C547D766A13410079BB2B01319B702B9

[paul@thinkpad ~]$ dane www.xelerance.com --sha512
_443._tcp.www.xelerance.com. IN TYPE65468 \# 66 01025FFE99D2E9488963FCFB36139BBE2A64B4AB2EBF845C5BEB8FE666BE0490328E6D625A3D6AC522377A4997B0141357A340C1A9771D3AA9A9F72DC102F306974C

[paul@thinkpad ~]$ dane www.eff.org
Aborted: dnssec required but DNS lookup was insecure (use --insecure to override)

[paul@thinkpad ~]$ dane www.eff.org --insecure
_443._tcp.www.eff.org. IN TYPE65468 \# 34 01017E408A6A3B2E9C3A6D21579CCD5C78F300881878AEBD0252974160CB892BD82D

[paul@thinkpad ~]$ dane www.xelerance.com --rfc --full
_443._tcp.www.xelerance.com. IN TLSA 1 0 308207AE30820596A003020102020107300D06092A864886F70D01010505003081C3310B30090603550406130243413110300E060355040813074F6E746172696F310F300D060355040713064F7474617761311E301C060355040A131558656C6572616E636520436F72706F726174696F6E31293027060355040B13204F70656E20536F75726365205365637572697479205370656369616C69737473311C301A0603550403131358656C6572616E63652[...]

[paul@thinkpad ~]$ dane --quiet xelerance.com @vault.xelerance.com
_443._tcp.xelerance.com. IN TYPE65468 \# 34 0101C71024963D065F4F5CFADCDD0CB72BAE0CBF92671F859A0AB1F24D2682E39F2B
_443._tcp.admin.xelerance.com. IN TYPE65468 \# 34 0101C71024963D065F4F5CFADCDD0CB72BAE0CBF92671F859A0AB1F24D2682E39F2B
_443._tcp.bugs.xelerance.com. IN TYPE65468 \# 34 0101354D89598CB94AB59AD5D6781EA49F34BF964548EB4480831EDA0EA47A97A333
_443._tcp.calendar.xelerance.com. IN TYPE65468 \# 34 0101C71024963D065F4F5CFADCDD0CB72BAE0CBF92671F859A0AB1F24D2682E39F2B
_443._tcp.calender.xelerance.com. IN TYPE65468 \# 34 0101C71024963D065F4F5CFADCDD0CB72BAE0CBF92671F859A0AB1F24D2682E39F2B
_443._tcp.certs.xelerance.com. IN TYPE65468 \# 34 01014BE08D87673F3B2FE4981E03ED2871A6ED9C7A6B55C38574FFDBCE482722B1FC
_443._tcp.csis2.xelerance.com. IN TYPE65468 \# 34 010127438F9C4860F788220A3008AAA696A10A6102ABD11378192471173E5337DE6B
_443._tcp.dane.xelerance.com. IN TYPE65468 \# 34 0101E8F192E559F94CA9DD1D16E900DF24D7733BDF76E8497C9E658EAE57E05836F6
_443._tcp.badsig.dane.xelerance.com. IN TYPE65468 \# 34 0101E8F192E559F94CA9DD1D16E900DF24D7733BDF76E8497C9E658EAE57E05836F6
_443._tcp.full.dane.xelerance.com. IN TYPE65468 \# 34 0101E8F192E559F94CA9DD1D16E900DF24D7733BDF76E8497C9E658EAE57E05836F6
_443._tcp.sha256.dane.xelerance.com. IN TYPE65468 \# 34 0101E8F192E559F94CA9DD1D16E900DF24D7733BDF76E8497C9E658EAE57E05836F6
_443._tcp.sha512.dane.xelerance.com. IN TYPE65468 \# 34 0101E8F192E559F94CA9DD1D16E900DF24D7733BDF76E8497C9E658EAE57E05836F6
_443._tcp.demo2.xelerance.com. IN TYPE65468 \# 34 010187FFFC5D8686B396FDB6A833F1FCD1253C5967457D3AF74EC23C495C8164FCED
_443._tcp.demo3.xelerance.com. IN TYPE65468 \# 34 010187FFFC5D8686B396FDB6A833F1FCD1253C5967457D3AF74EC23C495C8164FCED
[...]

For those people testing code, the DANE record for badsig.dane.xelerance.com has been broken on purpose:

_443._tcp.badsig.dane.xelerance.com. 3595 IN TYPE65468 \# 34 ( 01010000000000000000000000000000000000000000
 				000000000000000000000000 )

Paul

From [e-mail]  Tue Apr 12 23:42:08 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8C5ECE06D1 for <[e-mail]>; Tue, 12 Apr 2011 23:42:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.423
X-Spam-Level: 
X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[AWL=1.176,  BAYES_00=-2.599]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8MTx2KTo1ilf for <[e-mail]>; Tue, 12 Apr 2011 23:42:07 -0700 (PDT)
Received: from homiemail-a10.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfc.amsl.com (Postfix) with ESMTP id 725C1E06E9 for <[e-mail]>; Tue, 12 Apr 2011 23:42:07 -0700 (PDT)
Received: from homiemail-a10.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a10.g.dreamhost.com (Postfix) with ESMTP id 2DADC280075 for <[e-mail]>; Tue, 12 Apr 2011 23:42:06 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=efutLrdC61RDdrY52uzP6sqrzDQ/A3uCmAa+9kMvbn7 lnD7xR0mZVzN3v9bBensIsoEB+97knL4t4YP7Qj0WewmfDxCRz0VVW8QGE0zs+Bk 0v+rkUGl0B/3swF3NumwIr6/QIxHZ1B//V9g39o3dcHhxwTMKI4TMqGFlmOwdn+A =
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=wRxWVwEAh76h2ekn2leV92Ev2Ug=; b=cUocqlNDoE YFefb5vkEsIdxHCAMeAACUja6BdJB6xgCc5Q+21hFjAze/v6NZ/7iT8bIIiVv1v4 lEompOjU7PS1eGIwky+8yjaoh1uuGDINIT74vSH93i/GHsMpg8fCNfmrvPvxs+F+ x+e5KTx7fgtnl8IEHNmNgXjgx1o73CaB0=
Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: [e-mail]) by homiemail-a10.g.dreamhost.com (Postfix) with ESMTPA id D1090280073 for <[e-mail]>; Tue, 12 Apr 2011 23:42:05 -0700 (PDT)
From: Matt McCutchen <[e-mail]>
To: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain; charset="UTF-8"
Date: Wed, 13 Apr 2011 02:42:04 -0400
Message-ID: <1302676924.2108.12.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.3 
Content-Transfer-Encoding: 7bit
Subject: Re: [dane] Proof-of-concept implementation for NSS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 13 Apr 2011 06:42:08 -0000

On Wed, 2011-02-16 at 00:21 -0500, Matt McCutchen wrote:
> [...] https://mattmccutchen.net/cryptid/#nss-dane

Paul Wouters's work
(https://www.ietf.org/mail-archive/web/dane/current/msg02402.html) has
finally enticed me to update the hash types.  I have posted a new
version that supports the current types 0 (full), 1 (SHA-256), and 2
(SHA-512), and it is easy to add other algorithms supported by NSS.

I have updated the data for https://mattmccutchen.net correspondingly.
The client seems to work with
https://{sha256,sha512,full}.dane.xelerance.com as well.

-- 
Matt


From [e-mail]  Wed Apr 13 08:50:05 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E5E9AE07CE for <[e-mail]>; Wed, 13 Apr 2011 08:50:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.636
X-Spam-Level: 
X-Spam-Status: No, score=-102.636 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zz1PEfMAZdx0 for <[e-mail]>; Wed, 13 Apr 2011 08:50:05 -0700 (PDT)
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfc.amsl.com (Postfix) with ESMTP id 76678E079C for <[e-mail]>; Wed, 13 Apr 2011 08:50:05 -0700 (PDT)
Received: from shinkuro.com (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 61D951ECB420 for <[e-mail]>; Wed, 13 Apr 2011 15:50:01 +0000 (UTC)
Date: Wed, 13 Apr 2011 11:49:59 -0400
From: Andrew Sullivan <[e-mail]>
To: [e-mail]
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [dane] Use Cases Document
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 13 Apr 2011 15:50:06 -0000

On Wed, Apr 13, 2011 at 02:14:44PM +1200, Peter Gutmann wrote:
> modes.  Theorising over usage cases (real or imagined) didn't seem too useful
> unless we could first understand how things are failing today.  So rather than

Why?  Who cares what fails now?  The question is, "What are things you
want to do?"  The reason you might want to do them (like, for
instance, you think the other way to achieve a similar result is
broken) is not relevant until someone says, "You can already do that."

At such a time, I could see an argument for why we have to debate the
merits of the existing system.  Otherwise, I think it's a distraction.

A

-- 
Andrew Sullivan
[e-mail]
Shinkuro, Inc.

From [e-mail]  Wed Apr 13 14:11:56 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BE371E088D for <[e-mail]>; Wed, 13 Apr 2011 14:11:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -82.155
X-Spam-Level: 
X-Spam-Status: No, score=-82.155 tagged_above=-999 required=5 tests=[AWL=0.821, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, URIBL_BLACK=20, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ue-L19zCMlfR for <[e-mail]>; Wed, 13 Apr 2011 14:11:55 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfc.amsl.com (Postfix) with ESMTP id 6F959E06EA for <[e-mail]>; Wed, 13 Apr 2011 14:11:55 -0700 (PDT)
Received: by iwn39 with SMTP id 39so1159988iwn.31 for <[e-mail]>; Wed, 13 Apr 2011 14:11:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.43.56.197 with SMTP id wd5mr4220715icb.479.1302729114879; Wed, 13 Apr 2011 14:11:54 -0700 (PDT)
Received: by 10.231.111.28 with HTTP; Wed, 13 Apr 2011 14:11:54 -0700 (PDT)
X-Originating-IP: [67.51.72.122]
Date: Wed, 13 Apr 2011 14:11:54 -0700
Message-ID: <BANLkTi=[e-mail]>
From: Kirk Hall <[e-mail]>
To: [e-mail], Christopher Morrow <[e-mail]>
Content-Type: multipart/alternative; boundary=bcaec51b1aab21850f04a0d342b7
Subject: [dane] Expectations for Self-Signed Cert Trust Indicators under DANE
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: [e-mail]
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 13 Apr 2011 21:11:56 -0000

--bcaec51b1aab21850f04a0d342b7
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

I tried to post this message earlier, but it wasn=92t sent out by the
list-serv.  So I=92ll try again in a new thread.

This conversation started with my first posting,
http://www.ietf.org/mail-archive/web/dane/current/msg02326.html, and the
most recent response was from Chris Morrow at
http://www.ietf.org/mail-archive/web/dane/current/msg02378.html

* * * * *
Chris, thanks for your response.

I agree there=92s no point in trying to define UI specs in this DANE propos=
al
=96 but the Abstract for DANE does say =93Instead of trusting a certificati=
on
authority to have made this association correctly, the user might instead
trust the authoritative DNS server for the domain name to make that
association.=94  So the question of trust and even user reaction under DANE
(trust a self-signed cert instead of a CA cert) has been introduced.  And
some people have already posted that they want browsers and other
applications to treat a self-signed cert as equal to a DV cert under DANE,
so the question of desired UI result has been introduced to the discussion.

If the ONLY thing you want DANE to do is allow an automatic TLS connection
at the DNS level using any cert =96 then I can see why you would think
requiring what I called an anti-fraud check is irrelevant.  However, I fear
that DANE will be leaving consumers / browsers / applications with no way t=
o
distinguish between a self-signed cert that has been checked for fraud
versus a self-signed cert that has not.

That may mean DANE doesn=92t get widespread adoption =96 because browsers a=
nd
applications won=92t give it any recognition.  The browsers have been very
wary in the past of accepting self-signed certs for any purpose connected
with trust indicators, and may not even want to give consumers the basic
trust indicator =93you are in TLS session=94 in DANE with a self-signed cer=
t.
Why?  Because for years the browsers have been telling consumers =93you are
safer if you are encrypted=94 =96 which may or may not be true in DANE with=
 a
self-signed cert from an unknown source.

You=92re correct that phishing and fraud haven=92t used SSL much in the pas=
t =96
I=92d argue that=92s partly because CAs generally filter out cert requests =
from
those guys.  Every day at GeoTrust we received numerous requests from
phishers trying to get look-alike domains (e.g., paypall.com) certified, an=
d
we turned them down. If we had let these request go through simply because
the phishers had control over the domain (which they did), I believe there
would have been many more convincing phishing attacks targeted at consumers
using SSL, and losses would have been substantial.

CAs are already a huge target for phishers, and the phishers will quickly
exploit DANE if they can provide trusted SSL connections to consumers using
a self-signed cert.  For example, if DANE allows a phisher or look-alike
domain to use a self-signed cert at the DNS level, and if the browsers and
applications give that domain the same TLS trust indicators as they do for,
say, DV certs, the phishers will likely move to self-signed certs in order
to get the trust indicators.  That=92s why I think the browsers won=92t gra=
nt
any trust indicator to DANE self-signed certs unless you provide a flag or
some other means of identification for self-signed certs that have been
fraud-checked so they can be distinguished from other self-signed certs.

If you have no expectation of receiving any trust indicators for DANE from
the browsers and other applications =96 fine, you won=92t be disappointed.
Otherwise, I think you will.

One question to you:  what practical, actual, real world problem is DANE
trying to solve?  Is there, in fact, a real security need today for someone
to =93know=94 that they have reached the domain they intended to reach?  (T=
oday,
browsers tell you if there is a mismatch between a domain name and a
CA-issued cert on that domain=92s servers, so to some degree that potential
security issue is already resolved.)  Do you have examples today of actual
problems where people are unsure if they have connected with the domains
they wanted, and there is a bad result?  (And if your example depends on
=93assume there has been a compromise of the DNS=94 =96 aren=92t all bets o=
ff in
that situation, where no solution is reliable?)  I=92m not trying to be
provocative =96 I really want to know what problem that actually exists tod=
ay
would be solved with DANE.

Thanks.

--bcaec51b1aab21850f04a0d342b7
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div>I tried to post this message earlier, but it wasn=92t sent out by the =
list-serv.=A0 So I=92ll try again in a new thread.=A0 </div>
<div>=A0</div>
<div>This conversation started with my first posting, <a href=3D"http://www=
.ietf.org/mail-archive/web/dane/current/msg02326.html" target=3D"_blank">ht=
tp://www.ietf.org/mail-archive/web/dane/current/msg02326.html</a>, and the =
most recent response was from Chris Morrow at <a href=3D"http://www.ietf.or=
g/mail-archive/web/dane/current/msg02378.html" target=3D"_blank">http://www=
.ietf.org/mail-archive/web/dane/current/msg02378.html</a><br>
=A0<br>* * * * *<br>Chris, thanks for your response.<br>=A0<br>I agree ther=
e=92s no point in trying to define UI specs in this DANE proposal =96 but t=
he Abstract for DANE does say =93Instead of trusting a certification author=
ity to have made this association correctly, the user might instead trust t=
he authoritative DNS server for the domain name to make that association.=
=94=A0 So the question of trust and even user reaction under DANE (trust a =
self-signed cert instead of a CA cert) has been introduced.=A0 And some peo=
ple have already posted that they want browsers and other applications to t=
reat a self-signed cert as equal to a DV cert under DANE, so the question o=
f desired UI result has been introduced to the discussion.<br>
=A0<br>If the ONLY thing you want DANE to do is allow an automatic TLS conn=
ection at the DNS level using any cert =96 then I can see why you would thi=
nk requiring what I called an anti-fraud check is irrelevant.=A0 However, I=
 fear that DANE will be leaving consumers / browsers / applications with no=
 way to distinguish between a self-signed cert that has been checked for fr=
aud versus a self-signed cert that has not.=A0 <br>
=A0<br>That may mean DANE doesn=92t get widespread adoption =96 because bro=
wsers and applications won=92t give it any recognition.=A0 The browsers hav=
e been very wary in the past of accepting self-signed certs for any purpose=
 connected with trust indicators, and may not even want to give consumers t=
he basic trust indicator =93you are in TLS session=94 in DANE with a self-s=
igned cert.=A0 Why?=A0 Because for years the browsers have been telling con=
sumers =93you are safer if you are encrypted=94 =96 which may or may not be=
 true in DANE with a self-signed cert from an unknown source.<br>
=A0<br>You=92re correct that phishing and fraud haven=92t used SSL much in =
the past =96 I=92d argue that=92s partly because CAs generally filter out c=
ert requests from those guys.=A0 Every day at GeoTrust we received numerous=
 requests from phishers trying to get look-alike domains (e.g., <a href=3D"=
http://paypall.com/" target=3D"_blank">paypall.com</a>) certified, and we t=
urned them down. If we had let these request go through simply because the =
phishers had control over the domain (which they did), I believe there woul=
d have been many more convincing phishing attacks targeted at consumers usi=
ng SSL, and losses would have been substantial. <br>
=A0<br>CAs are already a huge target for phishers, and the phishers will qu=
ickly exploit DANE if they can provide trusted SSL connections to consumers=
 using a self-signed cert.=A0 For example, if DANE allows a phisher or look=
-alike domain to use a self-signed cert at the DNS level, and if the browse=
rs and applications give that domain the same TLS trust indicators as they =
do for, say, DV certs, the phishers will likely move to self-signed certs i=
n order to get the trust indicators.=A0 That=92s why I think the browsers w=
on=92t grant any trust indicator to DANE self-signed certs unless you provi=
de a flag or some other means of identification for self-signed certs that =
have been fraud-checked so they can be distinguished from other self-signed=
 certs.<br>
=A0<br>If you have no expectation of receiving any trust indicators for DAN=
E from the browsers and other applications =96 fine, you won=92t be disappo=
inted.=A0 Otherwise, I think you will.<br>=A0<br>One question to you:=A0 wh=
at practical, actual, real world problem is DANE trying to solve?=A0 Is the=
re, in fact, a real security need today for someone to =93know=94 that they=
 have reached the domain they intended to reach?=A0 (Today, browsers tell y=
ou if there is a mismatch between a domain name and a CA-issued cert on tha=
t domain=92s servers, so to some degree that potential security issue is al=
ready resolved.)=A0 Do you have examples today of actual problems where peo=
ple are unsure if they have connected with the domains they wanted, and the=
re is a bad result?=A0 (And if your example depends on =93assume there has =
been a compromise of the DNS=94 =96 aren=92t all bets off in that situation=
, where no solution is reliable?)=A0 I=92m not trying to be provocative =96=
 I really want to know what problem that actually exists today would be sol=
ved with DANE.<br>
=A0<br>Thanks.</div>

--bcaec51b1aab21850f04a0d342b7--

From [e-mail]  Wed Apr 13 14:34:39 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D68FBE06E7 for <[e-mail]>; Wed, 13 Apr 2011 14:34:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id meDtBxYwpOeN for <[e-mail]>; Wed, 13 Apr 2011 14:34:39 -0700 (PDT)
Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by ietfc.amsl.com (Postfix) with ESMTP id 06B72E05F5 for <[e-mail]>; Wed, 13 Apr 2011 14:34:38 -0700 (PDT)
Received: from gala.icir.org (gala.ICIR.org [192.150.187.49]) (Authenticated sender: nweaver) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id DD81536A362; Wed, 13 Apr 2011 14:34:37 -0700 (PDT)
References: <BANLkTi=[e-mail]>
In-Reply-To: <BANLkTi=[e-mail]>
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=windows-1252
Message-Id: <[e-mail]>
Content-Transfer-Encoding: quoted-printable
From: Nicholas Weaver <[e-mail]>
Date: Wed, 13 Apr 2011 14:34:37 -0700
To: Kirk Hall <[e-mail]>, [e-mail]
X-Mailer: Apple Mail (2.1084)
Cc: [e-mail]
Subject: Re: [dane] Expectations for Self-Signed Cert Trust Indicators under DANE
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 13 Apr 2011 21:34:40 -0000

> One question to you:  what practical, actual, real world problem is =
DANE trying to solve?  Is there, in fact, a real security need today for =
someone to =93know=94 that they have reached the domain they intended to =
reach?  (Today, browsers tell you if there is a mismatch between a =
domain name and a CA-issued cert on that domain=92s servers, so to some =
degree that potential security issue is already resolved.)  Do you have =
examples today of actual problems where people are unsure if they have =
connected with the domains they wanted, and there is a bad result?  (And =
if your example depends on =93assume there has been a compromise of the =
DNS=94 =96 aren=92t all bets off in that situation, where no solution is =
reliable?)  I=92m not trying to be provocative =96 I really want to know =
what problem that actually exists today would be solved with DANE.

The actual, real world problem:

The CA system is irrevocably broken: There are hundreds of potential =
paths of trust, ANY of which can create a DV intercepting certificate =
for a targeted name.

There are incidents we know about happening (Comodo), and there are ones =
we've suspected have happened (governments have the ability to purchase =
"SSL interception boxes" as commercial products that just need a =
wildcard certificate.  Such products wouldn't exist if governments =
couldn't get wildcard certificates) but don't have captured certificates =
to prove.


DANE with just a self-signed certificate reduces the paths of trust to a =
SINGLE path of trust, concurrent with the DNS resolution path for the =
name.

I can NEVER hope to trust "have to trust ALL of a set of hundreds", but =
I MIGHT be able to trust "have to trust just a single path".


There's also an economic problem.  There is no logistical reason why a =
CA should charge 10x for *.mydomain.com when compared with =
www.mydomain.com.  But they do. =20

DANE with self-signed certificates gives *.mydomain.com, able to sign =
anything in .mydomain.com, 'for free'.


The economic driver is IMO, enough to accomplish the real goal: DANE =
with CA certs, which now means that two separate paths of trust (the =
'one of a hundred' CA plus the 'single-path' DNSSEC) needs to be =
compromised.


From [e-mail]  Wed Apr 13 14:50:04 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3E8D4E07E8 for <[e-mail]>; Wed, 13 Apr 2011 14:50:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.693
X-Spam-Level: 
X-Spam-Status: No, score=-1.693 tagged_above=-999 required=5 tests=[AWL=0.907,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QmRerU9O2ej for <[e-mail]>; Wed, 13 Apr 2011 14:50:03 -0700 (PDT)
Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by ietfc.amsl.com (Postfix) with ESMTP id 7A156E07D9 for <[e-mail]>; Wed, 13 Apr 2011 14:50:03 -0700 (PDT)
Received: by eagle.jhcloos.com (Postfix, from userid 10) id 1CC29400AC; Wed, 13 Apr 2011 21:49:37 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1302731402; bh=UXXBZh6yRAkA2b77NgUczQD+CsbDQbvs0eYQQWjHq84=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; b=v5cmIo0udXW0BTeOr38I7kD2KNDZzbaPo6SVDVLn2iBKkVE/iJOJn1byb5BIZn9cE XHjyBN9EBf1LjPHw5Qiyf0dAFZ2mKQQhAqgA8OJw0PxEmP0AHdpnU7AyLS2DopMpmv j8GXJBVtTe/vX6u3E97rP4NONU1QMDkdhQJ4a1N8=
Received: by carbon.jhcloos.org (Postfix, from userid 500) id 75988260042; Wed, 13 Apr 2011 21:49:23 +0000 (UTC)
From: James Cloos <[e-mail]>
To: [e-mail]
User-Agent: Gnus/5.110016 (No Gnus v0.16) Emacs/24.0.50 (gnu/linux)
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC
Copyright: Copyright 2011 James Cloos
OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc
OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6
Date: Wed, 13 Apr 2011 17:49:23 -0400
Message-ID: <[e-mail]>
Lines: 18
MIME-Version: 1.0
Content-Type: text/plain
Subject: [dane] Should we rename the "certificate type" octet
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 13 Apr 2011 21:50:04 -0000

The draft posits a one octet value specifying the kind of cert.

Perhaps it would be better to have that octet specify the chain length.

If it is 0, then the tls/dtls client should compare the reference
against the server's immediate cert.  Otherwise it should expect a
chain of n certs (or up to n certs?) and compare the reference to
the anchor of the transmitted chain.

Alternatively, we could rename cert type 2 from a "CA" cert to a
"Trust Anchor (TA)" cert.

Either way it should make the intent more explicit and, with luck,
ameliorate some of the concerns expressed in recent days.

-JimC
-- 
James Cloos <[e-mail]>         OpenPGP: 1024D/ED7DAEA6

From [e-mail]  Wed Apr 13 15:03:52 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0E20EE0665 for <[e-mail]>; Wed, 13 Apr 2011 15:03:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level: 
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77c6G4NoUmhi for <[e-mail]>; Wed, 13 Apr 2011 15:03:50 -0700 (PDT)
Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfc.amsl.com (Postfix) with ESMTP id 6A8A9E065C for <[e-mail]>; Wed, 13 Apr 2011 15:03:50 -0700 (PDT)
Received: by ewy19 with SMTP id 19so369649ewy.31 for <[e-mail]>; Wed, 13 Apr 2011 15:03:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type:content-transfer-encoding; bh=v/Vh3hdPfRXcZIoVjhG2ot36O2N1EcVN9kaxXkrdrS8=; b=fA1F/BlbVus2kr7KGoV7dkRq9LgzfbngemAQNWAgXOTou3n2mv4OXKwM0mC/BBg85d pI2FaQ3ragU4zwnSWfKcvoOpJtdlPojURjkxo/EAeBdzDgAtu5VuwItUPfLyXDrufWlw T8eC6U7M92F1OrHu8IUC3UUWcsU5H26wcpgwI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=SzkzHLOtqoUraiuzUkQwk7Ktc3iaTBOIP5ApFmh1i0PtheGAWKqom3OASEzdYPErvt KdC4xvmZM5N0+oJ6orY45sT7Xqi69YYM1oBW4sxi+74BO6r3fIMyNcZtkOStVn0hrQ0S lM5pvr4GwZT59mjSLmaH+ceDSVCN5S095eZFs=
Received: by 10.213.97.7 with SMTP id j7mr404259ebn.112.1302732229423; Wed, 13 Apr 2011 15:03:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.213.31.195 with HTTP; Wed, 13 Apr 2011 15:03:28 -0700 (PDT)
In-Reply-To: <BANLkTi=[e-mail]>
References: <BANLkTi=[e-mail]>
From: Tom Ritter <[e-mail]>
Date: Wed, 13 Apr 2011 18:03:28 -0400
Message-ID: <[e-mail]>
To: [e-mail], [e-mail]
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Subject: Re: [dane] Expectations for Self-Signed Cert Trust Indicators under DANE
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 13 Apr 2011 22:03:52 -0000

> However, I fear
> that DANE will be leaving consumers / browsers / applications with no way=
 to
> distinguish between a [cert] that has been checked for fraud
> versus a self-signed cert that has not.

That's a reasonable fear, but I consider it unlikely that the eventual
UI implementations in browsers would do that.
For other applications that don't always provide a UI, these
applications either broke or continued on in case of mismatch.  Only
the scenario of a typo and a typo-squatter would this be a concern.
And applications that provide no UI are used primarily by system
administrators *or* in embedded scenarios where the address is
hardcoded.  If it accepts interactive user input, by definition it has
a UI.


> That may mean DANE doesn=92t get widespread adoption =96 because browsers=
 and
> applications won=92t give it any recognition.=A0 The browsers have been v=
ery
> wary in the past of accepting self-signed certs for any purpose connected
> with trust indicators, and may not even want to give consumers the basic
> trust indicator =93you are in TLS session=94 in DANE with a self-signed c=
ert.
> Why?=A0 Because for years the browsers have been telling consumers =93you=
 are
> safer if you are encrypted=94 =96 which may or may not be true in DANE wi=
th a
> self-signed cert from an unknown source.

I think you're confusing widespread adoption with 'widespread
commercial adoption'.  If an organization has an incentive to
encourage its users to feel safe on their website (e.g. a bank)
they're already using SSL certificates, usually EV ones that light up
the address bar all green and happy and proudly tout that.  They'll
use whatever mechanism gets them the green address bar (the positive
UI indicator).


> CAs are already a huge target for phishers, and the phishers will quickly
> exploit DANE if they can provide trusted SSL connections to consumers usi=
ng
> a self-signed cert.=A0 For example, if DANE allows a phisher or look-alik=
e
> domain to use a self-signed cert at the DNS level, and if the browsers an=
d
> applications give that domain the same TLS trust indicators as they do fo=
r,
> say, DV certs, the phishers will likely move to self-signed certs in orde=
r
> to get the trust indicators.=A0 That=92s why I think the browsers won=92t=
 grant
> any trust indicator to DANE self-signed certs

I agree with these statements (which I cut off early, and corrected
above).  I'm confused by the phrase "self-signed cert that has been
checked for fraud".  I don't understand how such a cert could exist,
because if it was purely self-signed, I could just generate it that
way myself.  I can only imagine that the cert is signed by some
external agency that's checked for fraud - making it not-self-signed.


> If you have no expectation of receiving any trust indicators for DANE fro=
m
> the browsers and other applications =96 fine, you won=92t be disappointed=
.

I don't.  I would like to have a subtle visual indicator, and not a
warning screen.


> One question to you:=A0 what practical, actual, real world problem is DAN=
E
> trying to solve?

I can't speak to the actual mission statement of the list or Working
Group, but for me it's to lower the bar necessary for widespread
implementation of TLS across all websites and other services (mail
where it isn't,  applications that speak HTTP, and so on).  The
actual, real world problem *that* would solve would be preventing the
mass of people between me and the website I'm visiting from reading my
activity.  Sure, my bank is encrypted, but until recently facebook was
not, what articles I'm reading online, what I'm browsing in an online
shop, and so on.  Authenticating the other end is implicit in my
statements.


> Is there, in fact, a real security need today for someone
> to =93know=94 that they have reached the domain they intended to reach?=
=A0 (Today,
> browsers tell you if there is a mismatch between a domain name and a
> CA-issued cert on that domain=92s servers, so to some degree that potenti=
al
> security issue is already resolved.)

I don't think you're paranoid enough.  Yes, I consider it very
important, and a real security need, that my parents wireless router
has not been co-opted into redirecting them.  I'd like to feel
comfortable connecting to an Access Point in Starbucks or McDonalds.
As you mention, a solution exists already (CA's) - but the fact that
TLS has not been adopted universally indicates the barrier to adoption
is still too high.  You can argue that it's not CA's that push off the
adoption, it's CPUs or whatever - that's both irrelevant to this list
*and* being worked on elsewhere.


> Do you have examples today of actual
> problems where people are unsure if they have connected with the domains
> they wanted, and there is a bad result?

https://bugzilla.mozilla.org/show_bug.cgi?id=3D460374


I understand that CA's want to protect their business interests, and I
recognize that if DANE-Provided Self-Signed certs were shown in the
browser in the same manner as EV Certs there wouldn't be any need for
CAs.  But that's hyperbole - I doubt anyone is pushing for that, I
doubt further a browser would consider it.  I expect that institutions
whose image depends on making their users comfortable will *always*
employ CAs, and that the application users use to connect to those
institutions for their critical transactions will *always* provide a
mechanism to show that this institution has used the highest form of
trustworthiness, and everyone gets warm fuzzies - the user, the
institution, and the CA.



Finally, to Nicholas' email, which I mostly agree with:

> The CA system is irrevocably broken: There are hundreds of potential path=
s of trust, ANY of which can create a DV intercepting certificate for a tar=
geted name.
> DANE with just a self-signed certificate reduces the paths of trust to a =
SINGLE path of trust, concurrent with the DNS resolution path for the name.

Maybe this has been discussed, but does DANE provide recommendations
for the scenario where we have conflicting input from different trust
anchors?  A valid CA certificate *and* a valid record via DANE, both
different?  *Should* it?  It seems that for people concerned about the
high-high level problems (such as government interception and whether
you can trust ccTLDs) this would be very important.  Perhaps this
should be broken out into a seperate thread if it has not been raised.

Related to Nicholas' statements: there's been mild discussion about
things like CA-pinning and restricting what TLDs CAs could sign for to
compartmentalize a internet-wide epidemic *if* a Comodo-type attack
happened and went undetected for some time.  They're not applicable to
this list, I just wanted to mention them, anyone can contact me off
list and I'll point you in the right direction.

-tom

From [e-mail]  Wed Apr 13 15:07:43 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 60910E0696 for <[e-mail]>; Wed, 13 Apr 2011 15:07:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.172
X-Spam-Level: 
X-Spam-Status: No, score=-3.172 tagged_above=-999 required=5 tests=[AWL=0.426,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f53lV4w6Gt3N for <[e-mail]>; Wed, 13 Apr 2011 15:07:42 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id 2D10EE05F5 for <[e-mail]>; Wed, 13 Apr 2011 15:07:42 -0700 (PDT)
Received: by vws12 with SMTP id 12so1060686vws.31 for <[e-mail]>; Wed, 13 Apr 2011 15:07:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=YNQIoELlVuUDYXikCuOmxruPyB1gnAgaWFGCU8oBCIg=; b=lrvnQUgNnqanBL6sbYR2eGTvt2y68eF9f6Mpa/7G+XtLHxGxKE/bgMmaimJS5HMnhF FDQ+LbWyI/ywPLQkjrBz05x8HX4ETsa+wJmvmGJsXjB5Iu3OVZRUqPADxmcYuzegwY7R QEmBAFlZbnBLCslbY1bNZeIXp7rk9lICKJgsE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=kCVZrBs5ykl5qTBVden2l3BMyzHWYkPh8kbVQ2N5u2s5PRvnKju2KuBaSst2m/Cyck ddO8nJrvai8SuUgHZ/XdOz9DA7YJGQjiESaRAqRV/wMqJDMGhyC0FaWlhSsXpJEqzAKm GA+R9ZQDcX8V4PG48wCybe8e53rTcCGG4hKXE=
MIME-Version: 1.0
Received: by 10.52.175.5 with SMTP id bw5mr20496vdc.69.1302732461883; Wed, 13 Apr 2011 15:07:41 -0700 (PDT)
Received: by 10.52.166.230 with HTTP; Wed, 13 Apr 2011 15:07:40 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <BANLkTi=[e-mail]> <[e-mail]>
Date: Wed, 13 Apr 2011 18:07:40 -0400
Message-ID: <BANLkTik9Py_EWC+J_9LsLQ2e=[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: Nicholas Weaver <[e-mail]>
Content-Type: multipart/alternative; boundary=20cf3071cebca0bf3904a0d40914
Cc: [e-mail], [e-mail]
Subject: Re: [dane] Expectations for Self-Signed Cert Trust Indicators under DANE
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 13 Apr 2011 22:07:43 -0000

--20cf3071cebca0bf3904a0d40914
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Can we stop the hyperbole?

How many fraudulently issued CA certs in 15 years?
How many subjects lost control of their private key?

It is really easy to poke holes in an existing deployed security control.
And really easy to propose alternatives that work perfectly in theory if yo=
u
assume that they are not subject to the same issues.


There are use cases for DV certs, but not in my view use cases that involve
humans.


On Wed, Apr 13, 2011 at 5:34 PM, Nicholas Weaver
<[e-mail]>wrote:

>
>
> > One question to you:  what practical, actual, real world problem is DAN=
E
> trying to solve?  Is there, in fact, a real security need today for someo=
ne
> to =93know=94 that they have reached the domain they intended to reach?  =
(Today,
> browsers tell you if there is a mismatch between a domain name and a
> CA-issued cert on that domain=92s servers, so to some degree that potenti=
al
> security issue is already resolved.)  Do you have examples today of actua=
l
> problems where people are unsure if they have connected with the domains
> they wanted, and there is a bad result?  (And if your example depends on
> =93assume there has been a compromise of the DNS=94 =96 aren=92t all bets=
 off in
> that situation, where no solution is reliable?)  I=92m not trying to be
> provocative =96 I really want to know what problem that actually exists t=
oday
> would be solved with DANE.
>
> The actual, real world problem:
>
> The CA system is irrevocably broken: There are hundreds of potential path=
s
> of trust, ANY of which can create a DV intercepting certificate for a
> targeted name.
>
> There are incidents we know about happening (Comodo), and there are ones
> we've suspected have happened (governments have the ability to purchase "=
SSL
> interception boxes" as commercial products that just need a wildcard
> certificate.  Such products wouldn't exist if governments couldn't get
> wildcard certificates) but don't have captured certificates to prove.
>
>
> DANE with just a self-signed certificate reduces the paths of trust to a
> SINGLE path of trust, concurrent with the DNS resolution path for the nam=
e.
>
> I can NEVER hope to trust "have to trust ALL of a set of hundreds", but I
> MIGHT be able to trust "have to trust just a single path".
>
>
> There's also an economic problem.  There is no logistical reason why a CA
> should charge 10x for *.mydomain.com when compared with www.mydomain.com.
>  But they do.
>
> DANE with self-signed certificates gives *.mydomain.com, able to sign
> anything in .mydomain.com, 'for free'.
>
>
> The economic driver is IMO, enough to accomplish the real goal: DANE with
> CA certs, which now means that two separate paths of trust (the 'one of a
> hundred' CA plus the 'single-path' DNSSEC) needs to be compromised.
>
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane
>



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

--20cf3071cebca0bf3904a0d40914
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Can we stop the hyperbole?<div><br></div><div>How many fraudulently issued =
CA certs in 15 years?</div><div>How many subjects lost control of their pri=
vate key?<br><br></div><div>It is really easy to poke holes in an existing =
deployed security control. And really easy to propose alternatives that wor=
k perfectly in theory if you assume that they are not subject to the same i=
ssues.</div>
<div><br></div><div><br></div><div>There are use cases for DV certs, but no=
t in my view use cases that involve humans.=A0<br><div class=3D"gmail_quote=
"><br></div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote"=
>On Wed, Apr 13, 2011 at 5:34 PM, Nicholas Weaver <span dir=3D"ltr">&lt;<a =
href=3D"mailto:[e-mail]">[e-mail]</a>&gt;=
</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;"><div class=3D"im"><br>
<br>
&gt; One question to you: =A0what practical, actual, real world problem is =
DANE trying to solve? =A0Is there, in fact, a real security need today for =
someone to =93know=94 that they have reached the domain they intended to re=
ach? =A0(Today, browsers tell you if there is a mismatch between a domain n=
ame and a CA-issued cert on that domain=92s servers, so to some degree that=
 potential security issue is already resolved.) =A0Do you have examples tod=
ay of actual problems where people are unsure if they have connected with t=
he domains they wanted, and there is a bad result? =A0(And if your example =
depends on =93assume there has been a compromise of the DNS=94 =96 aren=92t=
 all bets off in that situation, where no solution is reliable?) =A0I=92m n=
ot trying to be provocative =96 I really want to know what problem that act=
ually exists today would be solved with DANE.<br>

<br>
</div>The actual, real world problem:<br>
<br>
The CA system is irrevocably broken: There are hundreds of potential paths =
of trust, ANY of which can create a DV intercepting certificate for a targe=
ted name.<br>
<br>
There are incidents we know about happening (Comodo), and there are ones we=
&#39;ve suspected have happened (governments have the ability to purchase &=
quot;SSL interception boxes&quot; as commercial products that just need a w=
ildcard certificate. =A0Such products wouldn&#39;t exist if governments cou=
ldn&#39;t get wildcard certificates) but don&#39;t have captured certificat=
es to prove.<br>

<br>
<br>
DANE with just a self-signed certificate reduces the paths of trust to a SI=
NGLE path of trust, concurrent with the DNS resolution path for the name.<b=
r>
<br>
I can NEVER hope to trust &quot;have to trust ALL of a set of hundreds&quot=
;, but I MIGHT be able to trust &quot;have to trust just a single path&quot=
;.<br>
<br>
<br>
There&#39;s also an economic problem. =A0There is no logistical reason why =
a CA should charge 10x for *.<a href=3D"http://mydomain.com" target=3D"_bla=
nk">mydomain.com</a> when compared with <a href=3D"http://www.mydomain.com"=
 target=3D"_blank">www.mydomain.com</a>. =A0But they do.<br>

<br>
DANE with self-signed certificates gives *.<a href=3D"http://mydomain.com" =
target=3D"_blank">mydomain.com</a>, able to sign anything in .<a href=3D"ht=
tp://mydomain.com" target=3D"_blank">mydomain.com</a>, &#39;for free&#39;.<=
br>

<br>
<br>
The economic driver is IMO, enough to accomplish the real goal: DANE with C=
A certs, which now means that two separate paths of trust (the &#39;one of =
a hundred&#39; CA plus the &#39;single-path&#39; DNSSEC) needs to be compro=
mised.<br>

<br>
_______________________________________________<br>
dane mailing list<br>
<a href=3D"mailto:[e-mail]">[e-mail]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/dane</a><br>
</blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a href=3D"htt=
p://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--20cf3071cebca0bf3904a0d40914--

From [e-mail]  Wed Apr 13 15:17:35 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0E93EE0707 for <[e-mail]>; Wed, 13 Apr 2011 15:17:35 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdDSrkmpZpOt for <[e-mail]>; Wed, 13 Apr 2011 15:17:34 -0700 (PDT)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfc.amsl.com (Postfix) with ESMTP id 35053E06FC for <[e-mail]>; Wed, 13 Apr 2011 15:17:34 -0700 (PDT)
Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 374D3C5EF; Wed, 13 Apr 2011 18:17:32 -0400 (EDT)
Date: Wed, 13 Apr 2011 18:17:32 -0400 (EDT)
From: Paul Wouters <[e-mail]>
To: James Cloos <[e-mail]>
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: [e-mail]
Subject: Re: [dane] Should we rename the "certificate type" octet
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 13 Apr 2011 22:17:35 -0000

On Wed, 13 Apr 2011, James Cloos wrote:

> The draft posits a one octet value specifying the kind of cert.
>
> Perhaps it would be better to have that octet specify the chain length.
>
> If it is 0, then the tls/dtls client should compare the reference
> against the server's immediate cert.  Otherwise it should expect a
> chain of n certs (or up to n certs?) and compare the reference to
> the anchor of the transmitted chain.
>
> Alternatively, we could rename cert type 2 from a "CA" cert to a
> "Trust Anchor (TA)" cert.
>
> Either way it should make the intent more explicit and, with luck,
> ameliorate some of the concerns expressed in recent days.

That would hinder future non-cert type based authentication, so I am
very much against ingraining more PKIX concepts. TLSA should be as
trust-model agnostic as possible.

Paul

From [e-mail]  Wed Apr 13 15:20:05 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8C743E0723 for <[e-mail]>; Wed, 13 Apr 2011 15:20:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.621
X-Spam-Level: 
X-Spam-Status: No, score=-102.621 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zf7ZseOaitav for <[e-mail]>; Wed, 13 Apr 2011 15:20:05 -0700 (PDT)
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfc.amsl.com (Postfix) with ESMTP id ED35AE0710 for <[e-mail]>; Wed, 13 Apr 2011 15:20:04 -0700 (PDT)
Received: from shinkuro.com (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 4D69B1ECB420 for <[e-mail]>; Wed, 13 Apr 2011 22:20:04 +0000 (UTC)
Date: Wed, 13 Apr 2011 18:20:02 -0400
From: Andrew Sullivan <[e-mail]>
To: [e-mail]
Message-ID: <[e-mail]>
References: <BANLkTi=[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <BANLkTi=[e-mail]>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [dane] Expectations for Self-Signed Cert Trust Indicators under DANE
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 13 Apr 2011 22:20:05 -0000

On Wed, Apr 13, 2011 at 02:11:54PM -0700, Kirk Hall wrote:
> – but the Abstract for DANE does say “Instead of trusting a certification
> authority to have made this association correctly, the user might instead
> trust the authoritative DNS server for the domain name to make that
> association.”  So the question of trust and even user reaction under DANE
> (trust a self-signed cert instead of a CA cert) has been introduced.

I would like to propose that the text be changed s/user/client/.  Then
we don't have that problem and we can move on without boiling the
ocean, mapping the known universe, and solving every UI problem in the
world.

A


-- 
Andrew Sullivan
[e-mail]
Shinkuro, Inc.

From [e-mail]  Wed Apr 13 15:42:23 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D6280E078A for <[e-mail]>; Wed, 13 Apr 2011 15:42:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6u4jG4EQ8nZ for <[e-mail]>; Wed, 13 Apr 2011 15:42:23 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfc.amsl.com (Postfix) with ESMTP id 4DF40E074E for <[e-mail]>; Wed, 13 Apr 2011 15:42:23 -0700 (PDT)
Received: by vxg33 with SMTP id 33so1070069vxg.31 for <[e-mail]>; Wed, 13 Apr 2011 15:42:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=T7X2JApBipLoaV/8v6wnW7n40xpCQCcEIKfwBdUgp7U=; b=UGmk08P6BBRo+stNYK79HQq2M+kXA+MYfO0/H895okESoCgYq2ustO9W7I0i9M8Csa zRHYQRnYOporCkeoPkeaHLGK0DHSwUUrvdbCwCbpeCsOGqVo3Uw/BbA5/iecNG5En9/Q /Wut6D/nYxv0RecN9flQBw6EH6wGsnT54DkV4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=eF/T8BlV3zerL87DwP7vU51IfYrmytxq6ol5U3oVukqQc7V8C8ADsARqE7CFyc4a+t cnbkNuH/4AHQmFfpFBvZbh7tFI9k4QjINAu900keqmYrRfK1OuMUcQ2noCaOvfXvW+cS ptH31UyL88oP/RwMOZwGt+pdLlZx8Zbus5MM8=
MIME-Version: 1.0
Received: by 10.52.176.36 with SMTP id cf4mr64862vdc.29.1302734542698; Wed, 13 Apr 2011 15:42:22 -0700 (PDT)
Sender: [e-mail]
Received: by 10.52.158.39 with HTTP; Wed, 13 Apr 2011 15:42:22 -0700 (PDT)
In-Reply-To: <BANLkTinf8gFaNN7eGvex6+Ee3=[e-mail]>
References: <[e-mail]> <BANLkTinD=[e-mail]> <BANLkTi=5rCGVPPiBVUd0oVm9F-big4R=[e-mail]> <BANLkTi=[e-mail]> <BANLkTi=[e-mail]> <[e-mail]> <[e-mail]> <BANLkTinf8gFaNN7eGvex6+Ee3=[e-mail]>
Date: Wed, 13 Apr 2011 15:42:22 -0700
X-Google-Sender-Auth: 0oEKzg1v0hNahY0oIXThZ8sfTZ0
Message-ID: <[e-mail]>
From: Zack Weinberg <[e-mail]>
To: [e-mail]
Content-Type: text/plain; charset=UTF-8
Subject: Re: [dane] Requirements - HTTPS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 13 Apr 2011 22:42:24 -0000

On Sun, Apr 10, 2011 at 5:00 AM, Phillip Hallam-Baker <[e-mail]> wrote:
> On Sat, Apr 9, 2011 at 10:33 PM, Scott Schmit <[e-mail]> wrote:
>>
>> Sure, but what's the browser going to do when the A/AAAA record comes
>> through fine, signatures and all, but the TLSA record results get
>> blocked? The client might treat it as a network problem instead of a
>> security problem.
>>
>> I think that's what Phillip is concerned about.
>
> Yes, I can't see how anyone is going to hard fail that case.

If clients don't treat that case as identical to getting back a TLSA
record with "bogus" validation state, then a downgrade attack is
trivial and TLSA provides no real security benefit.

Perhaps TLSA will end up not being adopted because its requirements
are too hard to implement in a performant way and client vendors make
the decision that performance is more important than whatever security
increment it provides.  But if the specification doesn't provide any
security increment in the first place, we may as well scrap the idea.

zw

From [e-mail]  Wed Apr 13 15:47:56 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 11A04E07A0 for <[e-mail]>; Wed, 13 Apr 2011 15:47:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.717
X-Spam-Level: 
X-Spam-Status: No, score=-1.717 tagged_above=-999 required=5 tests=[AWL=0.882,  BAYES_00=-2.599]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XssqpciXBOLj for <[e-mail]>; Wed, 13 Apr 2011 15:47:55 -0700 (PDT)
Received: from homiemail-a4.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfc.amsl.com (Postfix) with ESMTP id 13389E0775 for <[e-mail]>; Wed, 13 Apr 2011 15:47:54 -0700 (PDT)
Received: from homiemail-a4.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a4.g.dreamhost.com (Postfix) with ESMTP id 1CCC851C088; Wed, 13 Apr 2011 15:47:54 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=GCJEKcFXVuocggQy8YipC/bq75//jfz68ZqJ7K+k3o8 vDUPxBIWzfqBH8F41x4DO/UizVCzsVB/iNXGrMOExKO7jzL3nn0/UYJrSiC2rS19 4XMgO8AliMBFusyE+ux2N+k1rreP85sFHuxMl7dIAtkSqW6i1jQTgTGFo4ylRepk =
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=zNDgm3RNlfQlYD/mztCs99M3f2Y=; b=ePTihVFct2 Sp00dAI/EjjTveqNocd1/zutGFA0sBrqvH0OVbDxOFXOL4ajTExyUWAx9Ri+eVu4 SXPrp3jrl9rPwToKIQC0uIou94fVVAuCDPnKgg0pi7Z+J1DAFJLkt3rbHtAYbkES 10FF//9MAsJzHCkWnCjZL+A8Ouqb1AgIM=
Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: [e-mail]) by homiemail-a4.g.dreamhost.com (Postfix) with ESMTPA id AFB1751C085; Wed, 13 Apr 2011 15:47:53 -0700 (PDT)
From: Matt McCutchen <[e-mail]>
To: [e-mail]
In-Reply-To: <BANLkTi=[e-mail]>
References: <BANLkTi=[e-mail]>
Content-Type: text/plain; charset="UTF-8"
Date: Wed, 13 Apr 2011 18:47:52 -0400
Message-ID: <1302734872.1842.78.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.3 
Content-Transfer-Encoding: quoted-printable
Cc: [e-mail]
Subject: Re: [dane] Expectations for Self-Signed Cert Trust Indicators under DANE
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 13 Apr 2011 22:47:56 -0000

On Wed, 2011-04-13 at 14:11 -0700, Kirk Hall wrote:
> If the ONLY thing you want DANE to do is allow an automatic TLS
> connection at the DNS level using any cert =E2=80=93 then I can see why=
 you
> would think requiring what I called an anti-fraud check is irrelevant.
> However, I fear that DANE will be leaving consumers / browsers /
> applications with no way to distinguish between a self-signed cert
> that has been checked for fraud versus a self-signed cert that has
> not.

Well, applications that want to alert users to fraudulent (or harmful)
sites will need a separate mechanism to do so.  A priori, this has
nothing to do with server-authenticated TLS.  I suggest that those
interested in this functionality take a fresh look at the design space
assuming that authentication is now being provided via DANE.  The
existing DV system is one approach, but it may not be the best.

> That may mean DANE doesn=E2=80=99t get widespread adoption =E2=80=93 be=
cause browsers
> and applications won=E2=80=99t give it any recognition.  The browsers h=
ave
> been very wary in the past of accepting self-signed certs for any
> purpose connected with trust indicators,

Of course, because they provide no authentication.

> and may not even want to give consumers the basic trust indicator =E2=80=
=9Cyou
> are in TLS session=E2=80=9D in DANE with a self-signed cert.  Why?  Bec=
ause
> for years the browsers have been telling consumers =E2=80=9Cyou are saf=
er if
> you are encrypted=E2=80=9D =E2=80=93 which may or may not be true in DA=
NE with a
> self-signed cert from an unknown source.

Mozilla has been working to correct that misconception.  The DV UI in
Firefox 4 is carefully designed to indicate only authenticated TLS, so
it could be appropriately applied to a site that has only authenticated
TLS, if Mozilla so chooses.  Ultimately, we may want different
indicators for authenticated TLS without and with a fraud check, but I
definitely want to have the former and would not agree that it is
impossible to do without misleading the user.

In any event, fraud concerns apply only to the identity information
displayed on tabs.  SSL_AuthCertificate can continue to check only
authentication, and XMLHttpRequests and the like can go on their merry
way.

> You=E2=80=99re correct that phishing and fraud haven=E2=80=99t used SSL=
 much in the
> past =E2=80=93 I=E2=80=99d argue that=E2=80=99s partly because CAs gene=
rally filter out cert
> requests from those guys.

I'll buy this.

--=20
Matt


From [e-mail]  Wed Apr 13 15:48:19 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 998C7E07C1 for <[e-mail]>; Wed, 13 Apr 2011 15:48:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jg19HIMfd8uA for <[e-mail]>; Wed, 13 Apr 2011 15:48:19 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfc.amsl.com (Postfix) with ESMTP id 1FFFFE0775 for <[e-mail]>; Wed, 13 Apr 2011 15:48:19 -0700 (PDT)
Received: by vxg33 with SMTP id 33so1073071vxg.31 for <[e-mail]>; Wed, 13 Apr 2011 15:48:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=XbzA64CR+wBQV54gqQk6BdmZltzr3dw7VO/l+hzm2J4=; b=scwquUHE0HRGKhiUIJ+qFlYYgGBd8mv+YA4FAro1Nql/QABnpxjiIHn8Q2B3xy3W/M cUr3Si1+q7uo2+LygrKreth/NzCkOWT4BJHFPF96WC6dqVxuCHYPA8FEF0wBHFGhYasq aIHlawO6HVuJyWrMYm75BK17vBOTZBwqQtJFA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=oPlP9Ds2ZBQqgHkT7ft6P49THw9twh5AiC7sZPP0nvEy4zg7Nxt6x7k+ws1eehPWDc ho9B0bEsQx7/G9HTj/UWZTMiITb91XtoMzp6gcwSc9piM/D1QIUV2Ii8sOpK5qMPUVJN VRcgStcVMs5AQi8vdM8Sw93eNfGBlF8Z3jv2M=
MIME-Version: 1.0
Received: by 10.52.65.52 with SMTP id u20mr12296vds.309.1302734898681; Wed, 13 Apr 2011 15:48:18 -0700 (PDT)
Sender: [e-mail]
Received: by 10.52.158.39 with HTTP; Wed, 13 Apr 2011 15:48:18 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <BANLkTinD=[e-mail]> <BANLkTi=5rCGVPPiBVUd0oVm9F-big4R=[e-mail]> <BANLkTi=[e-mail]> <BANLkTi=[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 13 Apr 2011 15:48:18 -0700
X-Google-Sender-Auth: Jtg3IUoFxbqeClMcyRwxbZeCJq4
Message-ID: <[e-mail]>
From: Zack Weinberg <[e-mail]>
To: [e-mail]
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [dane] Requirements - HTTPS
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 13 Apr 2011 22:48:19 -0000

On Sun, Apr 10, 2011 at 3:50 PM, Steve Schultze <[e-mail]> wrote:
>>
>> Ok, thanks for clarifying. If TLSA records are being stripped the client=
 has
>> evidence that someone is playing shenanigans and should panic, shouldn't=
 it?
>
> Yes, I think it should. =C2=A0Otherwise we introduce a downgrade attack v=
ector (issue #6).

I entirely agree.

> The text in section 3 also does not clearly address this. =C2=A0I'd like =
to suggest again that
> we consider a version of Matt's proposed text for Section 3. =C2=A0It cle=
arly outlines the
> different responses and results. =C2=A0Back in January, Paul suggested th=
at we wait on
> deciding this, but perhaps now is a good time.

I also drafted revisions to section 3:
http://www.ietf.org/mail-archive/web/dane/current/msg02056.html

I'm not insisting on mine rather than Matt's, but I do think that
*some* very clearly spelled out language for how the client decides
what to do is desired.  I didn't think to mention "query cannot be
completed" as a failure case, perhaps I should have.

zw

From [e-mail]  Wed Apr 13 16:03:18 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BDB6FE07D1 for <[e-mail]>; Wed, 13 Apr 2011 16:03:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.893
X-Spam-Level: 
X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[AWL=0.706,  BAYES_00=-2.599]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0AhrQ9Eml3tP for <[e-mail]>; Wed, 13 Apr 2011 16:03:17 -0700 (PDT)
Received: from homiemail-a37.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfc.amsl.com (Postfix) with ESMTP id CF46FE0677 for <[e-mail]>; Wed, 13 Apr 2011 16:03:17 -0700 (PDT)
Received: from homiemail-a37.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTP id A71CB208070 for <[e-mail]>; Wed, 13 Apr 2011 16:03:16 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=Dwlgl0sZcqjiEKQKg6Qu6mZIT4YWSnRxLwQTSjYlNPM 2p3HO7KMVuSJAA15s3RviMRbV0NOdLNMu7CgZ4xQqGKAL5nsoPzMA3D0EPyCbZ4h g12f/u9TxnFMOFhLbXakIHs3HUtvQBPtmGAFC9m82O/BhRUn5/E/4Rk8nJyTqZrM =
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=szEBxoyYJuzlDPujxpymyjKshhg=; b=r0XtuzdBd2 PbFJds52sbpackwI96xKmED8QRAb7tos1OOlCRkIFKM0gTeHQ1qYi2dZHzVV8ght CM8A7UdFzkFy66vFaDBm6d+D/ku1xQun2hnTuJlzWKXK1eT/wkiXYCIJ5emFkVnf StzjBglqay28lVamwkVVRrFZaDVwptG8M=
Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: [e-mail]) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTPA id 695F720806F for <[e-mail]>; Wed, 13 Apr 2011 16:03:16 -0700 (PDT)
From: Matt McCutchen <[e-mail]>
To: dane <[e-mail]>
In-Reply-To: <[e-mail]>
References: <BANLkTi=[e-mail]> <[e-mail]>
Content-Type: text/plain; charset="UTF-8"
Date: Wed, 13 Apr 2011 19:03:14 -0400
Message-ID: <1302735794.1842.86.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.3 
Content-Transfer-Encoding: quoted-printable
Subject: [dane] Authentication, and everything else
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 13 Apr 2011 23:03:18 -0000

On Wed, 2011-04-13 at 18:20 -0400, Andrew Sullivan wrote:
> On Wed, Apr 13, 2011 at 02:11:54PM -0700, Kirk Hall wrote:
> > =E2=80=93 but the Abstract for DANE does say =E2=80=9CInstead of trus=
ting a certification
> > authority to have made this association correctly, the user might ins=
tead
> > trust the authoritative DNS server for the domain name to make that
> > association.=E2=80=9D  So the question of trust and even user reactio=
n under DANE
> > (trust a self-signed cert instead of a CA cert) has been introduced.
>=20
> I would like to propose that the text be changed s/user/client/.  Then
> we don't have that problem and we can move on without boiling the
> ocean, mapping the known universe, and solving every UI problem in the
> world.

I don't think we even need to do that.  The draft addresses only
authentication of a TLS service associated with a domain name.  The word
"trust" is used in reference to that association.

The fraud, UI, etc. issues are out of scope of DANE per se, but they are
critical to the goals that I and others have for the bigger picture,
hence we want to discuss them.  If the discussion is not welcome here,
we should find another venue.  You'd think it would be in scope of
mozilla.dev.security.policy, but they don't seem too interested.  I may
start my own mailing list.

--=20
Matt


From [e-mail]  Wed Apr 13 16:08:15 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 27611E07E2 for <[e-mail]>; Wed, 13 Apr 2011 16:08:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.477
X-Spam-Level: 
X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.500,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIhd1qnuxCLK for <[e-mail]>; Wed, 13 Apr 2011 16:08:14 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id 4D390E07D9 for <[e-mail]>; Wed, 13 Apr 2011 16:08:14 -0700 (PDT)
Received: by vws12 with SMTP id 12so1097601vws.31 for <[e-mail]>; Wed, 13 Apr 2011 16:08:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=+Ve4j5WBPM6w0UO2Qr5LZKzBv6ghwwCuCbunyNgLnLY=; b=FSwKt1n78tQU0IEGGdF5sFlmDopI/FxFcRFIXArInsQ6+xGjMUQaGswPywFXSN+G4m 6jVckFyU3B4zE64Ml5kSIYMSoTE7lwQOzJMY588Tgm98oNV16f7/6K0yAS4hkigwYjgv FnXGw4aE8suZIp3AckQekcDC/zC8tsFKyG5mU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=fJLormK8PwaGeF4Ze83VMIKkRyhz02ZjGNUWLCyC12i0jCUH3cUvatvqXuFAdA3TBe X04U0jbrB8j80RFiSmxxfoGKKlhS3P+tDk9p7Diby679SMA+DQjSM3fmppSzyxMPAjcL 6PKR783ZD/VuzTflsatbk/tXzye6peitFkjcI=
MIME-Version: 1.0
Received: by 10.52.92.6 with SMTP id ci6mr64752vdb.189.1302736093882; Wed, 13 Apr 2011 16:08:13 -0700 (PDT)
Sender: [e-mail]
Received: by 10.52.158.39 with HTTP; Wed, 13 Apr 2011 16:08:13 -0700 (PDT)
In-Reply-To: <BANLkTin-E=[e-mail]>
References: <BANLkTin-E=[e-mail]>
Date: Wed, 13 Apr 2011 16:08:13 -0700
X-Google-Sender-Auth: Y7XffQfU1Wclm-n8Q-Y6qbUHH2A
Message-ID: <BANLkTi=[e-mail]>
From: Zack Weinberg <[e-mail]>
To: [e-mail]
Content-Type: text/plain; charset=UTF-8
Subject: Re: [dane] A browser's myopic view
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 13 Apr 2011 23:08:15 -0000

On Sat, Apr 9, 2011 at 2:12 PM, Adam Langley <[e-mail]> wrote:
> The problem with a hard failure on exclusion is that it means that we
> *have* to get the DNS information before sending application data on a
> TLS connection, or we have to have it cached.

True.

> In the event that we don't have it cached, getting the information
> from DNS is a problem. I ran an experiment in Chrome doing lookups for
> an odd DNS RRTYPE (13172) concurrently with the A lookup for HTTPS
> URLs. 2.5% of the time, the result came in over 100ms after we had
> completed the A lookup, TCP connection, TLS handshake and certificate
> verification! Somewhere between 0.5-1% of the time, we didn't get an
> answer within 10s (the limit of the histogram), which suggests that
> networks were filtering these requests.

I wonder if this is an argument for Kaminsky's proposal to carry this
information in TXT records instead of a new RRtype.  Can you repeat
the experiment with TXT?

It may also be an argument for not putting full certificates in the
DNS, to keep the records short.  How big were these queries and their
results?

> Needless to say, slowing things down to such an extent, and breaking
> that many people is a hard sell.

My counterargument would be: due to users' general willingness to
click through security warnings without even reading them, the only
way we're going to get an actual in-practice improvement to Web
security out of DANE (for sites that have already deployed SSL) is if
it provides exclusion with hard failure.  So it doesn't matter what
the performance hit is, because without that property there's no point
deploying it at all.

> Also, unless the information is DNSSEC authenticated, an attacker can
> spoof and DoS a site, and DNSSEC resolvers on the client are rare.
> (Or, rather, they would trigger hard failures for random sites until
> the user flushed their local browser state. Then the attacker can MITM
> the connection that they really wanted.)

I have been assuming that the client grows its own DNSSEC-aware
recursive resolver (which can be done without throwing away caching at
the ISP, btw).  This is something Mozilla is definitely willing to do
for our browser, and it's really not that hard - there are BSD-license
libraries already.

... skipping over technical details, which I'd rather keep out of this
subthread ...

> The DNS has several nice properties as a PKI: scoped delegation and
> short lived signatures rather than problematic revocation systems. I
> can see why some sites would like to have a DNSSEC signed HTTPS
> connection. They're not going to be major sites though. It will be
> hard to justify breaking even a tiny number of users when CA
> certificates can be had for free[2].

How do you reconcile this statement with the SSL Observatory data
indicating that self-signed certificates outnumber CA-signed
certificates by a factor of three?  Yeah, those aren't major sites,
but I would argue that the *other* way DANE could provide a
significant increment to Web security is at the margin: if it makes it
easier for sites that *aren't* encrypted now to *become* encrypted.
And the volume of self-signed certs in the wild indicates that the CA
process is a significant burden even to the point where sites are
willing to make their users click through increasingly scary and
intentionally UX-hostile certificate failure screens.

... I'm not sure how StartSSL factors into that, though.  IIRC their
free certificate service has only been around for a year or two, which
is not long as these things go, and if you don't know they have one, I
wonder hard it would be to find out about it.

zw

From [e-mail]  Wed Apr 13 16:59:20 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 253AFE072E for <[e-mail]>; Wed, 13 Apr 2011 16:59:20 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PhOX9AnwReHL for <[e-mail]>; Wed, 13 Apr 2011 16:59:19 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfc.amsl.com (Postfix) with ESMTP id 10203E06AA for <[e-mail]>; Wed, 13 Apr 2011 16:59:19 -0700 (PDT)
Received: by iye19 with SMTP id 19so1285271iye.31 for <[e-mail]>; Wed, 13 Apr 2011 16:59:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=WyUsZRF/8i50ZHgFfRHuxa30dQ/+UGzuE2xBb3SCCyY=; b=QAKbzicT0B9aeoAZfBuZdC/Gme2elfFDhhwh1CxlnStlefJK2e7n3Y88T6kVPpKBQB flMsGcmwHsfD+6w+LFAB+QAqnpAM/3rgy87mIkYD35ixXMIsrobYXa7IWvo+rvXbTpMK 4v8DSbF7WIE25EzIcXw5jjL7XWbzpM6ZtLfEE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=rQ3yBnuVSIiQLfNBID5Lxe2wVsexPTF69+o0jESFWGpRGGWEfBC2EQQg3WQKoP0Z7u AhFuueKVz/iF8JqyS2HMvvBxwf9heNH+ejvMe4/jqcXCQgr5gHZiwEeAIrFyd1FLmpDJ uvOUuSy2fj+CuutEEnIMEY5kthKfdbac1OtaY=
MIME-Version: 1.0
Received: by 10.43.64.2 with SMTP id xg2mr141966icb.170.1302739157729; Wed, 13 Apr 2011 16:59:17 -0700 (PDT)
Sender: [e-mail]
Received: by 10.42.220.5 with HTTP; Wed, 13 Apr 2011 16:59:17 -0700 (PDT)
In-Reply-To: <BANLkTi=[e-mail]>
References: <BANLkTin-E=[e-mail]> <BANLkTi=[e-mail]>
Date: Wed, 13 Apr 2011 19:59:17 -0400
X-Google-Sender-Auth: Qx1Zbr8-W76G9bD7A24JZ4pu3PM
Message-ID: <BANLkTikw5uN6tcam5zeq8+Nsp86L=[e-mail]>
From: Adam Langley <[e-mail]>
To: Zack Weinberg <[e-mail]>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: [e-mail]
Subject: Re: [dane] A browser's myopic view
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 13 Apr 2011 23:59:20 -0000

On Wed, Apr 13, 2011 at 7:08 PM, Zack Weinberg <[e-mail]> w=
rote:
> I wonder if this is an argument for Kaminsky's proposal to carry this
> information in TXT records instead of a new RRtype. =C2=A0Can you repeat
> the experiment with TXT?

At some point, probably yes, although it takes a while.

> It may also be an argument for not putting full certificates in the
> DNS, to keep the records short. =C2=A0How big were these queries and thei=
r
> results?

The queries were for the names of the sites (i.e. "example.com" for
https://example.com). The responses would have been empty because, I
assume, no site has a DNS record of the given type. The DO bit was not
on.

> My counterargument would be: due to users' general willingness to
> click through security warnings without even reading them, the only
> way we're going to get an actual in-practice improvement to Web
> security out of DANE (for sites that have already deployed SSL) is if
> it provides exclusion with hard failure. =C2=A0So it doesn't matter what
> the performance hit is, because without that property there's no point
> deploying it at all.

But the other contender here is carrying this information via HSTS,
rather then not doing it at all. HSTS doesn't have the performance
issues, but does have a weakness in that it doesn't apply for a first
visit. Given the tradeoffs, I'm currently leaning towards HSTS for
pinning information.

> I have been assuming that the client grows its own DNSSEC-aware
> recursive resolver (which can be done without throwing away caching at
> the ISP, btw). =C2=A0This is something Mozilla is definitely willing to d=
o
> for our browser, and it's really not that hard - there are BSD-license
> libraries already.

Adding a DNSSEC resolver into the browser is possible, although I'd
still prefer not to. I also don't see a need right now. If HSTS
carries pinning data and the DNSSEC data can be more efficiently
carried in the server certificate, this complex and error prone code
doesn't have to live in the browser.

> How do you reconcile this statement with the SSL Observatory data
> indicating that self-signed certificates outnumber CA-signed
> certificates by a factor of three? =C2=A0Yeah, those aren't major sites,
> but I would argue that the *other* way DANE could provide a
> significant increment to Web security is at the margin: if it makes it
> easier for sites that *aren't* encrypted now to *become* encrypted.
> And the volume of self-signed certs in the wild indicates that the CA
> process is a significant burden even to the point where sites are
> willing to make their users click through increasingly scary and
> intentionally UX-hostile certificate failure screens.

Agreed. I suggest that none of the self-signed sites are major sites
but there is still an advantage to pushing up the lower end and making
it easier to deploy HTTPS. There are tradeoffs none the less: if
DNSSEC authenticated sites become popular then users of older browsers
will see an increase in certificate warnings and will be even more
inclined to ignore them. However, that argument implies paralysis and
so I give it little weight.

--=20
Adam Langley [e-mail] http://www.imperialviolet.org

From [e-mail]  Wed Apr 13 17:34:23 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4D06EE06DF for <[e-mail]>; Wed, 13 Apr 2011 17:34:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.144
X-Spam-Level: 
X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifVoF0FGkl3v for <[e-mail]>; Wed, 13 Apr 2011 17:34:22 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfc.amsl.com (Postfix) with ESMTP id 8EDBBE05F5 for <[e-mail]>; Wed, 13 Apr 2011 17:34:22 -0700 (PDT)
Received: by vxg33 with SMTP id 33so1133993vxg.31 for <[e-mail]>; Wed, 13 Apr 2011 17:34:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=McqRP9rVb//nEt3FmAod3dhkz27eYOrjqXnRdYrx/DI=; b=V0n2Wt1I4OrW5wU9KGBGwfU+nWk4BBaifxd0JQDSC0qbLz1nWW3DxYMZ2es4kfYsRV fxPYPB7FBlnXuhPVRSqrLcnHBqHAzUWqgtbbJEvW+nEZsNwBQQJjUGqZBUEae/6QAHFW 6CVTVR3ySQthDR3/lrKPqZBgRvwgzIZeYx4lo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=aAa+tgMIQ9jaN4gusm3IUX09N+sfCeqLxduIun56EzTMcE1LuLLtAXOUjMTf0IKKQ/ 28mIieN9JY5KvKckI2mSEu5bralyeaoIEY/g81C80SRAjn+vVxe1pYUat++mNb+SVvSm sebtmqXXeDbeUYkebqtk/TneZd8PYtYiK1vNw=
MIME-Version: 1.0
Received: by 10.52.159.132 with SMTP id xc4mr156178vdb.229.1302741262146; Wed, 13 Apr 2011 17:34:22 -0700 (PDT)
Sender: [e-mail]
Received: by 10.52.158.39 with HTTP; Wed, 13 Apr 2011 17:34:22 -0700 (PDT)
In-Reply-To: <BANLkTikw5uN6tcam5zeq8+Nsp86L=[e-mail]>
References: <BANLkTin-E=[e-mail]> <BANLkTi=[e-mail]> <BANLkTikw5uN6tcam5zeq8+Nsp86L=[e-mail]>
Date: Wed, 13 Apr 2011 17:34:22 -0700
X-Google-Sender-Auth: QBQvwga6m71gG2Re8Bz05DpzfP8
Message-ID: <[e-mail]>
From: Zack Weinberg <[e-mail]>
To: [e-mail]
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [dane] A browser's myopic view
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 14 Apr 2011 00:34:23 -0000

On Wed, Apr 13, 2011 at 4:59 PM, Adam Langley <[e-mail]> wrot=
e:
> On Wed, Apr 13, 2011 at 7:08 PM, Zack Weinberg <[e-mail]>=
 wrote:
>> It may also be an argument for not putting full certificates in the
>> DNS, to keep the records short. =C2=A0How big were these queries and the=
ir
>> results?
>
> The queries were for the names of the sites (i.e. "example.com" for
> https://example.com). The responses would have been empty because, I
> assume, no site has a DNS record of the given type. The DO bit was not
> on.

Ok, thanks for clarifying.

>> My counterargument would be: due to users' general willingness to
>> click through security warnings without even reading them, the only
>> way we're going to get an actual in-practice improvement to Web
>> security out of DANE (for sites that have already deployed SSL) is if
>> it provides exclusion with hard failure. =C2=A0So it doesn't matter what
>> the performance hit is, because without that property there's no point
>> deploying it at all.
>
> But the other contender here is carrying this information via HSTS,
> rather then not doing it at all. HSTS doesn't have the performance
> issues, but does have a weakness in that it doesn't apply for a first
> visit. Given the tradeoffs, I'm currently leaning towards HSTS for
> pinning information.

Possibly I'm being too purist about it, possibly I count the
first-visit problem as more important than it really is, possibly I've
heard too many web developers (including at "major" sites) tell me
that they *cannot* make any changes to their sites' HTTP headers (and
nobody tell me that they can't roll out DNSSEC :-) but I just can't
see HSTS as anything more than a stopgap.  Putting the information in
the DNS seems like a much more appropriate long-term solution.

> Adding a DNSSEC resolver into the browser is possible, although I'd
> still prefer not to. I also don't see a need right now. If HSTS
> carries pinning data and the DNSSEC data can be more efficiently
> carried in the server certificate, this complex and error prone code
> doesn't have to live in the browser.

I guess this is the other point of disagreement, because it seems to
me that putting a DNSSEC resolver in the browser is a valuable
near-term change in and of itself.  It kneecaps a class of canned
man-in-the-middle exploits that are a live issue right now.  (Yes,
they *could* just switch to route spoofing or on-the-fly tampering,
but AFAIK nobody's canned those exploits yet.)

zw

From [e-mail]  Wed Apr 13 17:35:25 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3F757E06DF for <[e-mail]>; Wed, 13 Apr 2011 17:35:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.188
X-Spam-Level: 
X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[AWL=0.410,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egIuKLha9p-5 for <[e-mail]>; Wed, 13 Apr 2011 17:35:23 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id D64E6E05F5 for <[e-mail]>; Wed, 13 Apr 2011 17:35:23 -0700 (PDT)
Received: by vws12 with SMTP id 12so1145767vws.31 for <[e-mail]>; Wed, 13 Apr 2011 17:35:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=eFT72sjb+NTB4zZHmRpPJn0JzoRcHwTt3tWQwOQuP9k=; b=q3/66GwiI3yg5Y/zFtJlV2kE/NTmELRVnkNp3ioWoK56tMUSqo9Zmlx6yuHmRofQ22 r8a1UYQ2NB8aA0YoB3lSjjv+an5hMvC373oMNxsziGJsNFBIzyKffk0OusknCvtsqOdt GzJVC4RgSqMi+0r7lHuVbx03Qckok5fPGcatk=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=E1GzgTqFbJQbIj+xWiRinVIARS6V4fTPA2BEVWlQ/wYolyWHd+SoYM+snY1jKnjWCq IeMgeO16m73YgRsTeMBJsYRGqr013MR3BKv8gfkRzLoxdr7ydGKIRbbMVtig9n5R/EQC XRfQmc3hM5UM0EEB/r4UQxwaG2FeGCrzx31/4=
MIME-Version: 1.0
Received: by 10.52.159.132 with SMTP id xc4mr157276vdb.229.1302741323422; Wed, 13 Apr 2011 17:35:23 -0700 (PDT)
Received: by 10.52.166.230 with HTTP; Wed, 13 Apr 2011 17:35:23 -0700 (PDT)
In-Reply-To: <BANLkTi=[e-mail]>
References: <BANLkTin-E=[e-mail]> <BANLkTi=[e-mail]>
Date: Wed, 13 Apr 2011 20:35:23 -0400
Message-ID: <BANLkTik7Gtat=[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: Zack Weinberg <[e-mail]>
Content-Type: multipart/alternative; boundary=bcaec53f920bd11b6804a0d619b0
Cc: [e-mail]
Subject: Re: [dane] A browser's myopic view
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 14 Apr 2011 00:35:25 -0000

--bcaec53f920bd11b6804a0d619b0
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Apr 13, 2011 at 7:08 PM, Zack Weinberg <[e-mail]>wrote:

> On Sat, Apr 9, 2011 at 2:12 PM, Adam Langley <[e-mail]>
> wrote:
> I wonder if this is an argument for Kaminsky's proposal to carry this
> information in TXT records instead of a new RRtype.  Can you repeat
> the experiment with TXT?
>

Possibly, but we would have to run the numbers to find out is TXT is blocked
as well. Could we do that before we go down that rat-hole.

We would also need to look at whether the DNSSEC info is getting through. My
guess is that the 0.5-1% that block new records are stripping out pretty
much everything except for A records and A record like stuff.



> > Needless to say, slowing things down to such an extent, and breaking
> > that many people is a hard sell.
>
> My counterargument would be: due to users' general willingness to
> click through security warnings without even reading them, the only
> way we're going to get an actual in-practice improvement to Web
> security out of DANE (for sites that have already deployed SSL) is if
> it provides exclusion with hard failure.  So it doesn't matter what
> the performance hit is, because without that property there's no point
> deploying it at all.


I disagree. I can see a way to beat the country level SSL proxy. That was
one of the starting points for my design two years ago. But I do not see how
to do it with DANE alone. Nor do I see a need to.

DANE by itself can provide some useful security for some use cases. But if
you want to defeat a nation state adversary you have to be prepared to think
beyond port 53. In other words use DANE to solve one part of the problem and
use something else to solve the rest.

I have been assuming that the client grows its own DNSSEC-aware
> recursive resolver (which can be done without throwing away caching at
> the ISP, btw).  This is something Mozilla is definitely willing to do
> for our browser, and it's really not that hard - there are BSD-license
> libraries already.
>

You have to get hold of the DNSSEC data at the client and you have to be
able to interpret it usefully based on the data available at the client.
That is harder than people credit it.




> How do you reconcile this statement with the SSL Observatory data
> indicating that self-signed certificates outnumber CA-signed
> certificates by a factor of three?


We don't know what those are. Its a tiny number of servers with any type of
SSL supported. If you load an SSL cert onto an IIS server with Exchange on
the same host, Exchange will start offering STARTTLS on SMTP automatically.
Anyone looked to see what IIS does if you load up a self-signed cert for
STARTTLS?

Or it could be devices that ship with embedded TLS to a self signed cert. It
could be anything.

The observatory only examines the servers. We have no idea how the clients
are configured or even if there are clients using the data.

I just discovered that two of my hosts have self-signed certs loaded. They
are test certs I made for various projects.

 Yeah, those aren't major sites,
> but I would argue that the *other* way DANE could provide a
> significant increment to Web security is at the margin: if it makes it
> easier for sites that *aren't* encrypted now to *become* encrypted.
>

Agreed, but to address that use case you also have to provide a way that a
DANE client can make things better for a new DANE aware browser without
causing inconsistent behavior or throwing error messages on legacy browsers.

The is why I have always seen the 'TLS available' signaling as essential. It
allows a new client to add value without getting pulled into the mire of
legacy browser behavior.



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

--bcaec53f920bd11b6804a0d619b0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Apr 13, 2011 at 7:08 PM, Zack Weinberg <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:[e-mail]">[e-mail]</a>&gt;</spa=
n> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">On Sat, Apr 9, 2011 at 2:12 PM, Adam Langley &lt;<a href=
=3D"mailto:[e-mail]">[e-mail]</a>&gt; wrote:<br=
></div>I wonder if this is an argument for Kaminsky&#39;s proposal to carry=
 this<br>

information in TXT records instead of a new RRtype. =A0Can you repeat<br>
the experiment with TXT?<br></blockquote><div><br></div><div>Possibly, but =
we would have to run the numbers to find out is TXT is blocked as well. Cou=
ld we do that before we go down that rat-hole.</div><div><br></div><div>
We would also need to look at whether the DNSSEC info is getting through. M=
y guess is that the 0.5-1% that block new records are stripping out pretty =
much everything except for A records and A record like stuff.=A0</div><div>
<br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class=3D"im">
&gt; Needless to say, slowing things down to such an extent, and breaking<b=
r>
&gt; that many people is a hard sell.<br>
<br>
</div>My counterargument would be: due to users&#39; general willingness to=
<br>
click through security warnings without even reading them, the only<br>
way we&#39;re going to get an actual in-practice improvement to Web<br>
security out of DANE (for sites that have already deployed SSL) is if<br>
it provides exclusion with hard failure. =A0So it doesn&#39;t matter what<b=
r>
the performance hit is, because without that property there&#39;s no point<=
br>
deploying it at all.</blockquote><div><br></div><div>I disagree. I can see =
a way to beat the country level SSL proxy. That was one of the starting poi=
nts for my design two years ago. But I do not see how to do it with DANE al=
one. Nor do I see a need to.</div>
<div><br></div><div>DANE by itself can provide some useful security for som=
e use cases. But if you want to defeat a nation state adversary you have to=
 be prepared to think beyond port 53. In other words use DANE to solve one =
part of the problem and use something else to solve the rest.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex;"><div class=3D"im">I have bee=
n assuming that the client grows its own DNSSEC-aware</div>
recursive resolver (which can be done without throwing away caching at<br>
the ISP, btw). =A0This is something Mozilla is definitely willing to do<br>
for our browser, and it&#39;s really not that hard - there are BSD-license<=
br>
libraries already.<br></blockquote><div><br></div><div>You have to get hold=
 of the DNSSEC data at the client and you have to be able to interpret it u=
sefully based on the data available at the client. That is harder than peop=
le credit it.</div>
<div><br></div><div><br></div><div>=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"=
>How do you reconcile this statement with the SSL Observatory data<br>
indicating that self-signed certificates outnumber CA-signed<br>
certificates by a factor of three? </blockquote><div><br></div><div>We don&=
#39;t know what those are. Its a tiny number of servers with any type of SS=
L supported. If you load an SSL cert onto an IIS server with Exchange on th=
e same host, Exchange will start offering STARTTLS on SMTP automatically. A=
nyone looked to see what IIS does if you load up a self-signed cert for STA=
RTTLS?</div>
<div><br></div><div>Or it could be devices that ship with embedded TLS to a=
 self signed cert. It could be anything.</div><div><br></div><div>The obser=
vatory only examines the servers. We have no idea how the clients are confi=
gured or even if there are clients using the data.</div>
<div><br></div><div>I just discovered that two of my hosts have self-signed=
 certs loaded. They are test certs I made for various projects.=A0</div><di=
v><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex;">
=A0Yeah, those aren&#39;t major sites,<br>
but I would argue that the *other* way DANE could provide a<br>
significant increment to Web security is at the margin: if it makes it<br>
easier for sites that *aren&#39;t* encrypted now to *become* encrypted.<br>=
</blockquote><div><br></div><div>Agreed, but to address that use case you a=
lso have to provide a way that a DANE client can make things better for a n=
ew DANE aware browser without causing inconsistent behavior or throwing err=
or messages on legacy browsers.</div>
<div><br></div><div>The is why I have always seen the &#39;TLS available&#3=
9; signaling as essential. It allows a new client to add value without gett=
ing pulled into the mire of legacy browser behavior.</div><div><br></div>
<div><br></div><div>=A0</div></div>-- <br>Website: <a href=3D"http://hallam=
baker.com/">http://hallambaker.com/</a><br><br>

--bcaec53f920bd11b6804a0d619b0--

From [e-mail]  Wed Apr 13 18:13:40 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E2293E07BD for <[e-mail]>; Wed, 13 Apr 2011 18:13:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crQLazy31mG5 for <[e-mail]>; Wed, 13 Apr 2011 18:13:40 -0700 (PDT)
Received: from ppa03.princeton.edu (ppa03.Princeton.EDU [128.112.128.214]) by ietfc.amsl.com (Postfix) with ESMTP id DC3A9E0761 for <[e-mail]>; Wed, 13 Apr 2011 18:13:39 -0700 (PDT)
Received: from csgsmtp201l.Princeton.EDU (csgsmtp201l.Princeton.EDU [128.112.134.60]) by ppa03.princeton.edu (8.14.3/8.14.3) with ESMTP id p3E1DdTO009067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 13 Apr 2011 21:13:39 -0400
Received: from new-host-4.home (pool-173-71-106-53.cmdnnj.fios.verizon.net [173.71.106.53]) (authenticated bits=0) by csgsmtp201l.Princeton.EDU (8.13.8/8.12.9) with ESMTP id p3E1Dbid010206 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for <[e-mail]>; Wed, 13 Apr 2011 21:13:38 -0400
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1082)
From: Steve Schultze <[e-mail]>
In-Reply-To: <BANLkTikw5uN6tcam5zeq8+Nsp86L=[e-mail]>
Date: Wed, 13 Apr 2011 21:13:36 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <BANLkTin-E=[e-mail]> <BANLkTi=[e-mail]> <BANLkTikw5uN6tcam5zeq8+Nsp86L=[e-mail]>
To: [e-mail]
X-Mailer: Apple Mail (2.1082)
X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6315 signatures=657388
X-Proofpoint-Spam-Details: rule=quarantine_outbound_notspam policy=quarantine score=0 spamscore=0 ipscore=0 suspectscore=4 phishscore=0 bulkscore=2 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1012030000 definitions=main-1104130157
Subject: Re: [dane] A browser's myopic view
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 14 Apr 2011 01:13:41 -0000

On Apr 13, 2011, at 7:59 PM, Adam Langley wrote:
>> My counterargument would be: due to users' general willingness to
>> click through security warnings without even reading them, the only
>> way we're going to get an actual in-practice improvement to Web
>> security out of DANE (for sites that have already deployed SSL) is if
>> it provides exclusion with hard failure.  So it doesn't matter what
>> the performance hit is, because without that property there's no =
point
>> deploying it at all.
>=20
> But the other contender here is carrying this information via HSTS,
> rather then not doing it at all. HSTS doesn't have the performance
> issues, but does have a weakness in that it doesn't apply for a first
> visit. Given the tradeoffs, I'm currently leaning towards HSTS for
> pinning information.

That's really putting all your TOFU eggs in one basket, no?

It seems like this is the difference between adding another layer to the =
current model versus a more fundamental fix that is admittedly more =
difficult.

I'm tired of patches.=

From [e-mail]  Wed Apr 13 18:18:06 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A6A1EE07BD for <[e-mail]>; Wed, 13 Apr 2011 18:18:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ykr0EopAo5qj for <[e-mail]>; Wed, 13 Apr 2011 18:18:05 -0700 (PDT)
Received: from ppa03.princeton.edu (ppa03.Princeton.EDU [128.112.128.214]) by ietfc.amsl.com (Postfix) with ESMTP id 44273E05F5 for <[e-mail]>; Wed, 13 Apr 2011 18:18:04 -0700 (PDT)
Received: from csgsmtp201l.Princeton.EDU (csgsmtp201l.Princeton.EDU [128.112.134.60]) by ppa03.princeton.edu (8.14.3/8.14.3) with ESMTP id p3E1I3st012824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 13 Apr 2011 21:18:03 -0400
Received: from new-host-4.home (pool-173-71-106-53.cmdnnj.fios.verizon.net [173.71.106.53]) (authenticated bits=0) by csgsmtp201l.Princeton.EDU (8.13.8/8.12.9) with ESMTP id p3E1I35v011648 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for <[e-mail]>; Wed, 13 Apr 2011 21:18:03 -0400
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1082)
From: Steve Schultze <[e-mail]>
In-Reply-To: <BANLkTik7Gtat=[e-mail]>
Date: Wed, 13 Apr 2011 21:18:03 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <BANLkTin-E=[e-mail]> <BANLkTi=[e-mail]> <BANLkTik7Gtat=[e-mail]>
To: [e-mail]
X-Mailer: Apple Mail (2.1082)
X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6315 signatures=657388
X-Proofpoint-Spam-Details: rule=quarantine_outbound_notspam policy=quarantine score=0 spamscore=0 ipscore=0 suspectscore=4 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1012030000 definitions=main-1104130157
Subject: Re: [dane] A browser's myopic view
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 14 Apr 2011 01:18:06 -0000

On Apr 13, 2011, at 8:35 PM, Phillip Hallam-Baker wrote:
>> > Needless to say, slowing things down to such an extent, and =
breaking
>> > that many people is a hard sell.
>>=20
>> My counterargument would be: due to users' general willingness to
>> click through security warnings without even reading them, the only
>> way we're going to get an actual in-practice improvement to Web
>> security out of DANE (for sites that have already deployed SSL) is if
>> it provides exclusion with hard failure.  So it doesn't matter what
>> the performance hit is, because without that property there's no =
point
>> deploying it at all.
>=20
> I disagree. I can see a way to beat the country level SSL proxy. That =
was one of the starting points for my design two years ago.

You're going to have to expand on this one.

> DANE by itself can provide some useful security for some use cases. =
But if you want to defeat a nation state adversary you have to be =
prepared to think beyond port 53. In other words use DANE to solve one =
part of the problem and use something else to solve the rest.

DANE does not require port 53.=

From [e-mail]  Wed Apr 13 18:58:19 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 54AD3E0781 for <[e-mail]>; Wed, 13 Apr 2011 18:58:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.204
X-Spam-Level: 
X-Spam-Status: No, score=-3.204 tagged_above=-999 required=5 tests=[AWL=0.394,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id My106RyAELjY for <[e-mail]>; Wed, 13 Apr 2011 18:58:18 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id 0D8DDE07C7 for <[e-mail]>; Wed, 13 Apr 2011 18:58:14 -0700 (PDT)
Received: by vws12 with SMTP id 12so1192564vws.31 for <[e-mail]>; Wed, 13 Apr 2011 18:58:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=O6m0RUD8WLhjBo7ainC/fr2xG4fellvTx/YNw9SKvnM=; b=EIB75mepxwqvkAhp9/259gHRU0IqxpbpHbN7nDg4O0JDeHva7oC9wHDTkSHnwWDPSd xg8dwNUcYAPlJZHVjOV9tGQzd+qsPriM2g/6prd2YYZo3u69N6sE4kNSnscziEQcvPAb RudotsoNFtfE/ypQvBRqwMwCuYq4Zvs03UpSc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=qKoa+t3UbeRoIVLQFIA22SYc4aNI0Sq6p0Tn97D5oK5/HJyn5l5HnjFVZff65NJ1x1 fTEYhK6wU3zhWNNFI6DG8U7MdWRSJL5MgrVjAPViB+iXAGNf9j6V34XLvhvpay3m3KGX Cieoa1dT7JBuMQxpzzkXMMAzrBXJ3HJJtP910=
MIME-Version: 1.0
Received: by 10.52.0.109 with SMTP id 13mr279541vdd.109.1302746293669; Wed, 13 Apr 2011 18:58:13 -0700 (PDT)
Received: by 10.52.166.230 with HTTP; Wed, 13 Apr 2011 18:58:13 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <BANLkTin-E=[e-mail]> <BANLkTi=[e-mail]> <BANLkTik7Gtat=[e-mail]> <[e-mail]>
Date: Wed, 13 Apr 2011 21:58:13 -0400
Message-ID: <[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: Steve Schultze <[e-mail]>
Content-Type: multipart/alternative; boundary=20cf3054aabf110fe404a0d74273
Cc: [e-mail]
Subject: Re: [dane] A browser's myopic view
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 14 Apr 2011 01:58:19 -0000

--20cf3054aabf110fe404a0d74273
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Apr 13, 2011 at 9:18 PM, Steve Schultze <[e-mail]> wrote:

>
> On Apr 13, 2011, at 8:35 PM, Phillip Hallam-Baker wrote:
> >> > Needless to say, slowing things down to such an extent, and breaking
> >> > that many people is a hard sell.
> >>
> >> My counterargument would be: due to users' general willingness to
> >> click through security warnings without even reading them, the only
> >> way we're going to get an actual in-practice improvement to Web
> >> security out of DANE (for sites that have already deployed SSL) is if
> >> it provides exclusion with hard failure.  So it doesn't matter what
> >> the performance hit is, because without that property there's no point
> >> deploying it at all.
> >
> > I disagree. I can see a way to beat the country level SSL proxy. That was
> one of the starting points for my design two years ago.
>
> You're going to have to expand on this one.


It is somewhat old but:
http://tools.ietf.org/html/draft-hallambaker-dpls-00

Its a fairly simple approach to layering DNS over a secure channel without
the need for TCP/IP fallback.



> > DANE by itself can provide some useful security for some use cases. But
> if you want to defeat a nation state adversary you have to be prepared to
> think beyond port 53. In other words use DANE to solve one part of the
> problem and use something else to solve the rest.
>
> DANE does not require port 53.


No, but it does not provide a strategy for avoiding the need to use port 53
either.

I think that what we are going to need to really solve this problem is to
consider the 'user in police state' problem as being completely separate and
accept that they are going to tollerate major delays in their user
experience to get through.

People living in police states cannot just connect up to Google or Mozilla
and download chrome. They can't get untainted AV either. There is a whole
bootstrap problem that has to be thought through.

For that use case we need to either layer over Tor or have an agile approach
that uses port 443 when necessary. It may even be necessary to perform TLS
within TLS to get round some of the attacks.


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

--20cf3054aabf110fe404a0d74273
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Wed, Apr 13, 2011 at 9:18 PM, Steve S=
chultze <span dir=3D"ltr">&lt;<a href=3D"mailto:[e-mail]">sjs@prin=
ceton.edu</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im"><br>
On Apr 13, 2011, at 8:35 PM, Phillip Hallam-Baker wrote:<br>
&gt;&gt; &gt; Needless to say, slowing things down to such an extent, and b=
reaking<br>
&gt;&gt; &gt; that many people is a hard sell.<br>
&gt;&gt;<br>
&gt;&gt; My counterargument would be: due to users&#39; general willingness=
 to<br>
&gt;&gt; click through security warnings without even reading them, the onl=
y<br>
&gt;&gt; way we&#39;re going to get an actual in-practice improvement to We=
b<br>
&gt;&gt; security out of DANE (for sites that have already deployed SSL) is=
 if<br>
&gt;&gt; it provides exclusion with hard failure. =A0So it doesn&#39;t matt=
er what<br>
&gt;&gt; the performance hit is, because without that property there&#39;s =
no point<br>
&gt;&gt; deploying it at all.<br>
&gt;<br>
&gt; I disagree. I can see a way to beat the country level SSL proxy. That =
was one of the starting points for my design two years ago.<br>
<br>
</div>You&#39;re going to have to expand on this one.</blockquote><div><br>=
</div><div>It is somewhat old but:</div><div><a href=3D"http://tools.ietf.o=
rg/html/draft-hallambaker-dpls-00">http://tools.ietf.org/html/draft-hallamb=
aker-dpls-00</a></div>
<div><br></div><div>Its a fairly simple approach to layering DNS over a sec=
ure channel without the need for TCP/IP fallback.</div><div><br></div><div>=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">
&gt; DANE by itself can provide some useful security for some use cases. Bu=
t if you want to defeat a nation state adversary you have to be prepared to=
 think beyond port 53. In other words use DANE to solve one part of the pro=
blem and use something else to solve the rest.<br>

<br>
</div>DANE does not require port 53.</blockquote><div><br></div><div>No, bu=
t it does not provide a strategy for avoiding the need to use port 53 eithe=
r.</div><div><br></div><div>I think that what we are going to need to reall=
y solve this problem is to consider the &#39;user in police state&#39; prob=
lem as being completely separate and accept that they are going to tollerat=
e major delays in their user experience to get through.</div>
<div><br></div><div>People living in police states cannot just connect up t=
o Google or Mozilla and download chrome. They can&#39;t get untainted AV ei=
ther. There is a whole bootstrap problem that has to be thought through.</d=
iv>
<div><br></div><div>For that use case we need to either layer over Tor or h=
ave an agile approach that uses port 443 when necessary. It may even be nec=
essary to perform TLS within TLS to get round some of the attacks.</div>
<div><br></div><div>=A0</div></div>-- <br>Website: <a href=3D"http://hallam=
baker.com/">http://hallambaker.com/</a><br><br>

--20cf3054aabf110fe404a0d74273--

From [e-mail]  Wed Apr 13 19:59:27 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 38E9EE07E5 for <[e-mail]>; Wed, 13 Apr 2011 19:59:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pHfPMQasWAEq for <[e-mail]>; Wed, 13 Apr 2011 19:59:26 -0700 (PDT)
Received: from ppa04.Princeton.EDU (ppa04.Princeton.EDU [128.112.128.215]) by ietfc.amsl.com (Postfix) with ESMTP id 4FAEAE07E3 for <[e-mail]>; Wed, 13 Apr 2011 19:59:26 -0700 (PDT)
Received: from csgsmtp200l.Princeton.EDU (csgsmtp200l.Princeton.EDU [128.112.130.131]) by ppa04.Princeton.EDU (8.14.3/8.14.3) with ESMTP id p3E2xEvY031458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 13 Apr 2011 22:59:25 -0400
Received: from new-host-4.home (pool-173-71-106-53.cmdnnj.fios.verizon.net [173.71.106.53]) (authenticated bits=0) by csgsmtp200l.Princeton.EDU (8.13.8/8.12.9) with ESMTP id p3E2xDvY010533 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for <[e-mail]>; Wed, 13 Apr 2011 22:59:14 -0400
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1082)
From: Steve Schultze <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Wed, 13 Apr 2011 22:59:13 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <BANLkTin-E=[e-mail]> <BANLkTi=[e-mail]> <BANLkTik7Gtat=[e-mail]> <[e-mail]> <[e-mail]>
To: [e-mail]
X-Mailer: Apple Mail (2.1082)
X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6315 signatures=657388
X-Proofpoint-Spam-Details: rule=quarantine_outbound_notspam policy=quarantine score=0 spamscore=0 ipscore=0 suspectscore=4 phishscore=0 bulkscore=1 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1012030000 definitions=main-1104130176
Subject: Re: [dane] A browser's myopic view
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 14 Apr 2011 02:59:27 -0000

On Apr 13, 2011, at 9:58 PM, Phillip Hallam-Baker wrote:
> On Wed, Apr 13, 2011 at 9:18 PM, Steve Schultze <[e-mail]> =
wrote:
>=20
>> On Apr 13, 2011, at 8:35 PM, Phillip Hallam-Baker wrote:
>> >> > Needless to say, slowing things down to such an extent, and =
breaking
>> >> > that many people is a hard sell.
>> >>
>> >> My counterargument would be: due to users' general willingness to
>> >> click through security warnings without even reading them, the =
only
>> >> way we're going to get an actual in-practice improvement to Web
>> >> security out of DANE (for sites that have already deployed SSL) is =
if
>> >> it provides exclusion with hard failure.  So it doesn't matter =
what
>> >> the performance hit is, because without that property there's no =
point
>> >> deploying it at all.
>> >
>> > I disagree. I can see a way to beat the country level SSL proxy. =
That was one of the starting points for my design two years ago.
>>=20
>> You're going to have to expand on this one.
>=20
> It is somewhat old but:
> http://tools.ietf.org/html/draft-hallambaker-dpls-00

So you envision re-creation of centralized intermediaries.  Perhaps if =
something like what you proposed had enjoyed some adoption, this would =
be an option.

> > DANE by itself can provide some useful security for some use cases. =
But if you want to defeat a nation state adversary you have to be =
prepared to think beyond port 53. In other words use DANE to solve one =
part of the problem and use something else to solve the rest.
>=20
> DANE does not require port 53.
>=20
> No, but it does not provide a strategy for avoiding the need to use =
port 53 either.

abstraction

> I think that what we are going to need to really solve this problem is =
to consider the 'user in police state' problem as being completely =
separate and accept that they are going to tollerate major delays in =
their user experience to get through.
>=20
> People living in police states cannot just connect up to Google or =
Mozilla and download chrome. They can't get untainted AV either. There =
is a whole bootstrap problem that has to be thought through.
>=20
> For that use case we need to either layer over Tor or have an agile =
approach that uses port 443 when necessary. It may even be necessary to =
perform TLS within TLS to get round some of the attacks.

The types of delays we *might* have to face in a DNSSEC-based approach =
is nothing like the major delays currently experienced by users of Tor =
and other anonymization/circumvention tools.  Of course, that's a =
different set of features than DANE's verified encrypted connections to =
an arbitrary endpoint.

I don't think we should create a two-tier system for users in hostile =
jurisdictions and those that are not... after all, one person's National =
Security Agency is the next person's Ministry of Information.

From [e-mail]  Thu Apr 14 06:21:07 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C6C52E06A7 for <[e-mail]>; Thu, 14 Apr 2011 06:21:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.844
X-Spam-Level: 
X-Spam-Status: No, score=-1.844 tagged_above=-999 required=5 tests=[AWL=0.756,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xv0F1OfLdXZX for <[e-mail]>; Thu, 14 Apr 2011 06:21:06 -0700 (PDT)
Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by ietfc.amsl.com (Postfix) with ESMTP id 4F17FE0889 for <[e-mail]>; Thu, 14 Apr 2011 06:21:06 -0700 (PDT)
Received: by eagle.jhcloos.com (Postfix, from userid 10) id 45CA4400D0; Thu, 14 Apr 2011 13:20:40 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1302787264; bh=qOTf06nqP5J0UGIkhmgadWS4yS0OabEqCAGfhbOs+ow=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=Fvx5G4+rSxUu3Tf8hyinqYF2U9cdjZ9vZzAivYiFynED3fZNJA3TFnMnxhH7YtjLw NW2G8qgHJYbzbfgSHRL6+zLcZpX1KG418abZIN8cPJlpkFECjKSGMuyYvZmFJW6it5 D5sbv7RRZ87Yafr6uH+p/8Ffo+qdRpgNH7qbKsgo=
Received: by carbon.jhcloos.org (Postfix, from userid 500) id 30E14260042; Thu, 14 Apr 2011 13:20:27 +0000 (UTC)
From: James Cloos <[e-mail]>
To: Zack Weinberg <[e-mail]>
In-Reply-To: <[e-mail]> (Zack Weinberg's message of "Wed, 13 Apr 2011 17:34:22 -0700")
References: <BANLkTin-E=[e-mail]> <BANLkTi=[e-mail]> <BANLkTikw5uN6tcam5zeq8+Nsp86L=[e-mail]> <[e-mail]>
User-Agent: Gnus/5.110016 (No Gnus v0.16) Emacs/24.0.50 (gnu/linux)
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC
Copyright: Copyright 2011 James Cloos
OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc
OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6
Date: Thu, 14 Apr 2011 09:20:27 -0400
Message-ID: <[e-mail]>
Lines: 18
MIME-Version: 1.0
Content-Type: text/plain
Cc: [e-mail]
Subject: Re: [dane] A browser's myopic view
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 14 Apr 2011 13:21:07 -0000

>>>>> "ZW" == Zack Weinberg <[e-mail]> writes:

ZW> it seems to me that putting a DNSSEC resolver in the browser
ZW> is a valuable near-term change in and of itself.

In a dnssec world both recucursers and resolvers SHOULD validate.

So, yes, validating resolver code in browsers and similar apps is
a welcome addition.

It would be best, though, to separate the resolving code out into
its own library, just as encryption, et al are in separate libs
(nss, gnutls, openssl, et cetera).  That would better facilitate
review, trust and also re-use.

-JimC
-- 
James Cloos <[e-mail]>         OpenPGP: 1024D/ED7DAEA6

From [e-mail]  Thu Apr 14 08:46:10 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1520FE07DD for <[e-mail]>; Thu, 14 Apr 2011 08:46:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.218
X-Spam-Level: 
X-Spam-Status: No, score=-3.218 tagged_above=-999 required=5 tests=[AWL=0.380,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3R5v1QR-KrA for <[e-mail]>; Thu, 14 Apr 2011 08:46:09 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id D8DADE08CC for <[e-mail]>; Thu, 14 Apr 2011 08:46:08 -0700 (PDT)
Received: by vws12 with SMTP id 12so1763364vws.31 for <[e-mail]>; Thu, 14 Apr 2011 08:46:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4nydCdt1mxB29RaOtZE/mA8/ti53IZkYWotKswkfxJ4=; b=fPl1NhnYrR8r6B+aIS5G/h3mGjRILL7KFMBC3+et+B/ftRGuHdQtJFj+hrkvsihyuU ZNam2qA1MvLM8cMyj4HlnyYTR0WixJUCqIOrictEc8jzoG9REW4gvIR8fJQEhCd2z1RJ ZnSP3QH8Mq7PWwMBJx5FC1oIB15OAtar6VxFE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=sxVzMrgA0MSWlm/y+j/67GpOhrczFgMzSwmynmd/Dg2mNBvKHFa6LpZyNrUeQyKtro D7+mjAASRWDTiy0vMxn9Pz4DdWH5paRY6Vf0JR+qFXtoQz+earS2WR41qEhAGLGupJyC V7AlKKikhH+iNFP+CBlJwP8+7QMxvUu9tQQv0=
MIME-Version: 1.0
Received: by 10.52.176.36 with SMTP id cf4mr1308811vdc.29.1302795967794; Thu, 14 Apr 2011 08:46:07 -0700 (PDT)
Received: by 10.52.166.230 with HTTP; Thu, 14 Apr 2011 08:46:07 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <BANLkTin-E=[e-mail]> <BANLkTi=[e-mail]> <BANLkTik7Gtat=[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 14 Apr 2011 11:46:07 -0400
Message-ID: <BANLkTi=[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: Steve Schultze <[e-mail]>
Content-Type: multipart/alternative; boundary=bcaec5171ea7e00e1104a0e2d280
Cc: [e-mail]
Subject: Re: [dane] A browser's myopic view
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 14 Apr 2011 15:46:10 -0000

--bcaec5171ea7e00e1104a0e2d280
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Apr 13, 2011 at 10:59 PM, Steve Schultze <[e-mail]> wrote:

>
> On Apr 13, 2011, at 9:58 PM, Phillip Hallam-Baker wrote:
> > On Wed, Apr 13, 2011 at 9:18 PM, Steve Schultze <[e-mail]>
> wrote:
> >
> >> On Apr 13, 2011, at 8:35 PM, Phillip Hallam-Baker wrote:
> >> >> > Needless to say, slowing things down to such an extent, and
> breaking
> >> >> > that many people is a hard sell.
> >> >>
> >> >> My counterargument would be: due to users' general willingness to
> >> >> click through security warnings without even reading them, the only
> >> >> way we're going to get an actual in-practice improvement to Web
> >> >> security out of DANE (for sites that have already deployed SSL) is if
> >> >> it provides exclusion with hard failure.  So it doesn't matter what
> >> >> the performance hit is, because without that property there's no
> point
> >> >> deploying it at all.
> >> >
> >> > I disagree. I can see a way to beat the country level SSL proxy. That
> was one of the starting points for my design two years ago.
> >>
> >> You're going to have to expand on this one.
> >
> > It is somewhat old but:
> > http://tools.ietf.org/html/draft-hallambaker-dpls-00
>
> So you envision re-creation of centralized intermediaries.  Perhaps if
> something like what you proposed had enjoyed some adoption, this would be an
> option.


The architecture already has several million users. They just don't know
that they are doing it, nor do they care. Currently we use a proprietary
protocol, DPLS is a proposal to create an open standard to replace it.

And since the existing model of the DNS has virtually everyone using random
resolvers as an intermediary, it is clearly not as far fetched as other
proposals.





> > > DANE by itself can provide some useful security for some use cases. But
> if you want to defeat a nation state adversary you have to be prepared to
> think beyond port 53. In other words use DANE to solve one part of the
> problem and use something else to solve the rest.
> >
> > DANE does not require port 53.
> >
> > No, but it does not provide a strategy for avoiding the need to use port
> 53 either.
>
> abstraction
>

It needs a discovery layer. How does the client work out it is being blocked
and find the right data.


> I don't think we should create a two-tier system for users in hostile
> jurisdictions and those that are not... after all, one person's National
> Security Agency is the next person's Ministry of Information.
>

I don't think we have much option. People who are risking their lives are
willing to put up with a browser that is very slow. People surfing to find
lolcats are not.

Its pretty easy to download an untainted version of Chrome or Firefox here
in the US. Very hard for someone to do that in Iran.

Most rifles are good for a single war. After that the opponents respond by
matching or exceeding the capabilities. Its the same with Internet
revolutions.



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

--bcaec5171ea7e00e1104a0e2d280
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Wed, Apr 13, 2011 at 10:59 PM, Steve =
Schultze <span dir=3D"ltr">&lt;<a href=3D"mailto:[e-mail]">sjs@pri=
nceton.edu</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im"><br>
On Apr 13, 2011, at 9:58 PM, Phillip Hallam-Baker wrote:<br>
&gt; On Wed, Apr 13, 2011 at 9:18 PM, Steve Schultze &lt;<a href=3D"mailto:=
[e-mail]">[e-mail]</a>&gt; wrote:<br>
&gt;<br>
&gt;&gt; On Apr 13, 2011, at 8:35 PM, Phillip Hallam-Baker wrote:<br>
&gt;&gt; &gt;&gt; &gt; Needless to say, slowing things down to such an exte=
nt, and breaking<br>
&gt;&gt; &gt;&gt; &gt; that many people is a hard sell.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; My counterargument would be: due to users&#39; general wi=
llingness to<br>
&gt;&gt; &gt;&gt; click through security warnings without even reading them=
, the only<br>
&gt;&gt; &gt;&gt; way we&#39;re going to get an actual in-practice improvem=
ent to Web<br>
&gt;&gt; &gt;&gt; security out of DANE (for sites that have already deploye=
d SSL) is if<br>
&gt;&gt; &gt;&gt; it provides exclusion with hard failure. =A0So it doesn&#=
39;t matter what<br>
&gt;&gt; &gt;&gt; the performance hit is, because without that property the=
re&#39;s no point<br>
&gt;&gt; &gt;&gt; deploying it at all.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; I disagree. I can see a way to beat the country level SSL pro=
xy. That was one of the starting points for my design two years ago.<br>
&gt;&gt;<br>
&gt;&gt; You&#39;re going to have to expand on this one.<br>
&gt;<br>
&gt; It is somewhat old but:<br>
&gt; <a href=3D"http://tools.ietf.org/html/draft-hallambaker-dpls-00" targe=
t=3D"_blank">http://tools.ietf.org/html/draft-hallambaker-dpls-00</a><br>
<br>
</div>So you envision re-creation of centralized intermediaries. =A0Perhaps=
 if something like what you proposed had enjoyed some adoption, this would =
be an option.</blockquote><div><br></div><div>The architecture already has =
several million users. They just don&#39;t know that they are doing it, nor=
 do they care. Currently we use a proprietary protocol, DPLS is a proposal =
to create an open standard to replace it.</div>
<div><br></div><div>And since the existing model of the DNS has virtually e=
veryone using random resolvers as an intermediary, it is clearly not as far=
 fetched as other proposals.</div><div><br></div><div><br></div><div><br>
</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class=3D"im">
&gt; &gt; DANE by itself can provide some useful security for some use case=
s. But if you want to defeat a nation state adversary you have to be prepar=
ed to think beyond port 53. In other words use DANE to solve one part of th=
e problem and use something else to solve the rest.<br>

&gt;<br>
&gt; DANE does not require port 53.<br>
&gt;<br>
&gt; No, but it does not provide a strategy for avoiding the need to use po=
rt 53 either.<br>
<br>
</div>abstraction<br></blockquote><div><br></div><div>It needs a discovery =
layer. How does the client work out it is being blocked and find the right =
data.</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class=3D"im">I don&#39;t think we should create a two-tier system for =
users in hostile jurisdictions and those that are not... after all, one per=
son&#39;s National Security Agency is the next person&#39;s Ministry of Inf=
ormation.</div>
</blockquote><div><br></div><div>I don&#39;t think we have much option. Peo=
ple who are risking their lives are willing to put up with a browser that i=
s very slow. People surfing to find lolcats are not.</div><div><br></div>
<div>Its pretty easy to download an untainted version of Chrome or Firefox =
here in the US. Very hard for someone to do that in Iran.</div><div><br></d=
iv><div>Most rifles are good for a single war. After that the opponents res=
pond by matching or exceeding the capabilities. Its the same with Internet =
revolutions.</div>
<div><br></div><div><br></div><div><br></div></div>-- <br>Website: <a href=
=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>

--bcaec5171ea7e00e1104a0e2d280--

From [e-mail]  Thu Apr 14 10:28:08 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 908CBE06CD for <[e-mail]>; Thu, 14 Apr 2011 10:28:08 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdEeO-UjgLqK for <[e-mail]>; Thu, 14 Apr 2011 10:28:07 -0700 (PDT)
Received: from ecl1mtaoutpex02.symantec.com (ecl1mtaoutpex02.symantec.com [166.98.1.210]) by ietfc.amsl.com (Postfix) with ESMTP id D2C8DE06A4 for <[e-mail]>; Thu, 14 Apr 2011 10:28:04 -0700 (PDT)
Received: from tus1opsmtapin02.ges.symantec.com (tus1opsmtapin02.ges.symantec.com [192.168.214.44]) by ecl1mtaoutpex02.symantec.com (8.14.4/8.14.4) with ESMTP id p3EHRuDE006687; Thu, 14 Apr 2011 13:27:57 -0400
Received: from [155.64.220.138] (helo=TUS1XCHHUBPIN02.SYMC.SYMANTEC.COM) by tus1opsmtapin02.ges.symantec.com with esmtp (Exim 4.72) (envelope-from <[e-mail]>) id 1QAQKi-0006kT-Px; Thu, 14 Apr 2011 10:27:56 -0700
Received: from TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM ([155.64.220.146]) by TUS1XCHHUBPIN02.SYMC.SYMANTEC.COM ([155.64.220.138]) with mapi; Thu, 14 Apr 2011 10:27:56 -0700
From: Rick Andrews <[e-mail]>
To: Steve Schultze <[e-mail]>, "[e-mail]" <[e-mail]>
Date: Thu, 14 Apr 2011 10:27:51 -0700
Thread-Topic: [dane] A browser's myopic view
Thread-Index: Acv6QTPF95ksZGlLSGuFFn90CusFKQAh0VdQ
Message-ID: <[e-mail]>
References: <BANLkTin-E=[e-mail]> <BANLkTi=[e-mail]> <BANLkTikw5uN6tcam5zeq8+Nsp86L=[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-cr-hashedpuzzle: AVLd BHcB EHhZ FL+F F5a6 F514 G8fv MM2Z OORS OdyK QCIT QS+h RKWi RTt2 UEro Va/2; 2; ZABhAG4AZQBAAGkAZQB0AGYALgBvAHIAZwA7AHMAagBzAEAAcAByAGkAbgBjAGUAdABvAG4ALgBlAGQAdQA=; Sosha1_v1; 7; {B7A60981-CBDC-4B0C-91C0-F454BB17B59C}; cgBpAGMAawBfAGEAbgBkAHIAZQB3AHMAQABzAHkAbQBhAG4AdABlAGMALgBjAG8AbQA=; Thu, 14 Apr 2011 17:27:51 GMT; UgBFADoAIABbAGQAYQBuAGUAXQAgAEEAIABiAHIAbwB3AHMAZQByACcAcwAgAG0AeQBvAHAAaQBjACAAdgBpAGUAdwA=
x-cr-puzzleid: {B7A60981-CBDC-4B0C-91C0-F454BB17B59C}
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [dane] A browser's myopic view
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 14 Apr 2011 17:28:08 -0000

On Wednesday, April 13, 2011 6:14 PM, Steve Schultze wrote:
>=20
> On Apr 13, 2011, at 7:59 PM, Adam Langley wrote:
> >> My counterargument would be: due to users' general willingness to
> >> click through security warnings without even reading them, the only
> >> way we're going to get an actual in-practice improvement to Web
> >> security out of DANE (for sites that have already deployed SSL) is
> if
> >> it provides exclusion with hard failure.  So it doesn't matter what
> >> the performance hit is, because without that property there's no
> point
> >> deploying it at all.
> >
> > But the other contender here is carrying this information via HSTS,
> > rather then not doing it at all. HSTS doesn't have the performance
> > issues, but does have a weakness in that it doesn't apply for a first
> > visit. Given the tradeoffs, I'm currently leaning towards HSTS for
> > pinning information.
>=20
> That's really putting all your TOFU eggs in one basket, no?

Chrome preloads a number of STS tokens (http://www.chromium.org/sts), so yo=
u're not really trusting on first use. Perhaps Google's SSL database (http:=
//googleonlinesecurity.blogspot.com/2011/04/improving-ssl-certificate-secur=
ity.html) could be used to preload a huge volume of STS tokens?

-Rick Andrews


From [e-mail]  Thu Apr 14 10:51:58 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 25D81E065F for <[e-mail]>; Thu, 14 Apr 2011 10:51:58 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3cskXywqda4x for <[e-mail]>; Thu, 14 Apr 2011 10:51:57 -0700 (PDT)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfc.amsl.com (Postfix) with ESMTP id 29991E06B0 for <[e-mail]>; Thu, 14 Apr 2011 10:51:56 -0700 (PDT)
Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 4CAD1C5E8; Thu, 14 Apr 2011 13:51:55 -0400 (EDT)
Date: Thu, 14 Apr 2011 13:51:55 -0400 (EDT)
From: Paul Wouters <[e-mail]>
To: Rick Andrews <[e-mail]>
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <BANLkTin-E=[e-mail]> <BANLkTi=[e-mail]> <BANLkTikw5uN6tcam5zeq8+Nsp86L=[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [dane] A browser's myopic view
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 14 Apr 2011 17:51:58 -0000

On Thu, 14 Apr 2011, Rick Andrews wrote:

> Chrome preloads a number of STS tokens (http://www.chromium.org/sts), so you're not really trusting on first use. Perhaps Google's SSL database (http://googleonlinesecurity.blogspot.com/2011/04/improving-ssl-certificate-security.html) could be used to preload a huge volume of STS tokens?

Seems like an excessive solution to save each user a one-time ever DNS lookup of 20ms for the HASTLS record.

HASTLS is distributed and controlled by the domain owner. And requires no added trusted third parties,
or repositories that need to be maintained by browser vendors.

I also see no obvious way to get my STS token in? Does this solution scale at all? It seems to mostly be
beneficial to the "too big to fail" EV carrying websites.

Paul

From [e-mail]  Thu Apr 14 11:06:19 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B164DE07C2 for <[e-mail]>; Thu, 14 Apr 2011 11:06:19 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxWjM7F7FlnO for <[e-mail]>; Thu, 14 Apr 2011 11:06:19 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfc.amsl.com (Postfix) with ESMTP id F23D7E065F for <[e-mail]>; Thu, 14 Apr 2011 11:06:18 -0700 (PDT)
Received: by yxk30 with SMTP id 30so1039974yxk.31 for <[e-mail]>; Thu, 14 Apr 2011 11:06:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=WmpXpaoBbvgxpPdVpIKwFOwt2wYLB07ILFmHZZwP5BM=; b=CNPqrTZQ7WVFBgruUbGaFKtjRpnSOsEK0wXCfDG73pSLCWqp3qn62Y3SW+gNoM6vdY W9vmY5OE0aX15IoMw76ueMocepNibhTjEVnx0t0U8ecknUveKsoI5aO7pJSX3eFnLYcA /sH+ek3/NB+f8jiPj9IkRG5kPaN8qZVvUfZzc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=AdR3ukTT7BE9e7u/UQKdPDWQLuoZ1fGUc+p4SnhwAwalxDFpvnwtdIA5eDMmXIpviv pSuQevqG8ubSy7U9n+ac8puZADjAMcVkwGx8hdrlLDrK7lnRlXvSkj0TTib3ivWFyL1B sBcsrj4c//GfLlTMHxxBWgmIrDPU2J73qvi9I=
MIME-Version: 1.0
Received: by 10.42.4.72 with SMTP id 8mr1587873icr.304.1302804378593; Thu, 14 Apr 2011 11:06:18 -0700 (PDT)
Sender: [e-mail]
Received: by 10.42.220.5 with HTTP; Thu, 14 Apr 2011 11:06:18 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <BANLkTin-E=[e-mail]> <BANLkTi=[e-mail]> <BANLkTikw5uN6tcam5zeq8+Nsp86L=[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 14 Apr 2011 14:06:18 -0400
X-Google-Sender-Auth: rB80Fb4rqd6TfK75l3d5CHg_aV8
Message-ID: <[e-mail]>
From: Adam Langley <[e-mail]>
To: Paul Wouters <[e-mail]>
Content-Type: text/plain; charset=UTF-8
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [dane] A browser's myopic view
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 14 Apr 2011 18:06:19 -0000

On Thu, Apr 14, 2011 at 1:51 PM, Paul Wouters <[e-mail]> wrote:
> I also see no obvious way to get my STS token in? Does this solution scale
> at all? It seems to mostly be
> beneficial to the "too big to fail" EV carrying websites.

>From the page:

"If you own a site that you would like to see included in the
preloaded HSTS list, contact: <my email>"

The if the overhead of maintaining the preloaded list becomes too
large, then a more automated system will be setup.

Again, HASTLS would need to be a hard fail in order to have a benefit
over HSTS, and that's not likely to work on today's Internet.

Less importantly, in order to avoid spoofing of HASTLS records, the
clients have to implement their own DNSSEC resolver.

(The arguments are just the same as with DANE based exclusion vs HSTS
exclusion.)


AGL

-- 
Adam Langley [e-mail] http://www.imperialviolet.org

From [e-mail]  Thu Apr 14 11:12:59 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 370D3E0717 for <[e-mail]>; Thu, 14 Apr 2011 11:12:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.231
X-Spam-Level: 
X-Spam-Status: No, score=-3.231 tagged_above=-999 required=5 tests=[AWL=0.367,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjl05M3JZqIw for <[e-mail]>; Thu, 14 Apr 2011 11:12:57 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id 94CA8E065F for <[e-mail]>; Thu, 14 Apr 2011 11:12:57 -0700 (PDT)
Received: by vws12 with SMTP id 12so1915742vws.31 for <[e-mail]>; Thu, 14 Apr 2011 11:12:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=hEdtlrJ+Xd3is+xNmXqoyK5yaniHm43up3ZLeaBao6Y=; b=rEZUt5ERMkmlwv/eVaEYqkfDJ8OIU3lq0nBbWp/9XRAtdykfsVb/Rm8pUBydij1Hx3 msGf6tvRf+CbfSrQIMrDzXL25v3S8iy5kTDMT+IcxzrAgt3nmKo6YUJHgqysgSUjYqMr K6rXPCgiUhTUBal+TNfstznpw3MMqIHnNyTq4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=sccX06ZSebYMo4qkrCZ0gTPS1BRSghWWSelMaHzFHCY6b+cC8d5h9u81bqZ5d3T/ta NIxQBinZj2li3bvzv5u8ZrbnKMZvCR8oImHNReHvDY0cxlI2Lko0cbqlDYFmPOrrfdzS B9LVi6qL9UeCZGAnqL5a2qszLb1mxCxfzxJaA=
MIME-Version: 1.0
Received: by 10.52.98.230 with SMTP id el6mr819422vdb.149.1302804776871; Thu, 14 Apr 2011 11:12:56 -0700 (PDT)
Received: by 10.52.166.230 with HTTP; Thu, 14 Apr 2011 11:12:56 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <BANLkTin-E=[e-mail]> <BANLkTi=[e-mail]> <BANLkTikw5uN6tcam5zeq8+Nsp86L=[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 14 Apr 2011 14:12:56 -0400
Message-ID: <[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: Paul Wouters <[e-mail]>
Content-Type: multipart/alternative; boundary=20cf307cfcbcefe69104a0e4df4b
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [dane] A browser's myopic view
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 14 Apr 2011 18:12:59 -0000

--20cf307cfcbcefe69104a0e4df4b
Content-Type: text/plain; charset=ISO-8859-1

Or the group could do it my way and combine key publication and notifying
TLS support in the same mechanism and the performance issue goes away.

These are implementation issues, not use cases. 'Secure on first connect' is
a requirement.

The way I think that the process should go is

1) People propose use cases and performance metrics by which to validate
them. Technical constraints are identified.

2) Use cases are analyzed to determine requirements that satisfy them.

3) People make proposals that satisfy as many or as few requirements (and
thus use cases) as they like.


4) People decide which solution they like and we find out if there is
consensus for a single solution or if there is to be some horse trading or
if the divisions turn out to be irreconcilable and we end up with competing
proposals.


So far the approach has been that we have been told what the solution is
going to be and that people who disagree have been accused and abused.

The performance metrics that matter are the performance metrics for the
whole system, not the metrics for one individual component.

I can meet all the requirements and constraints that I have set out in my
proposed use cases document with better performance against the specified
metrics.

So I am quite happy to accept both the use case and the metric.


On Thu, Apr 14, 2011 at 1:51 PM, Paul Wouters <[e-mail]> wrote:

> On Thu, 14 Apr 2011, Rick Andrews wrote:
>
>  Chrome preloads a number of STS tokens (http://www.chromium.org/sts), so
>> you're not really trusting on first use. Perhaps Google's SSL database (
>> http://googleonlinesecurity.blogspot.com/2011/04/improving-ssl-certificate-security.html)
>> could be used to preload a huge volume of STS tokens?
>>
>
> Seems like an excessive solution to save each user a one-time ever DNS
> lookup of 20ms for the HASTLS record.
>
> HASTLS is distributed and controlled by the domain owner. And requires no
> added trusted third parties,
> or repositories that need to be maintained by browser vendors.
>
> I also see no obvious way to get my STS token in? Does this solution scale
> at all? It seems to mostly be
> beneficial to the "too big to fail" EV carrying websites.
>
> Paul
>
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane
>



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

--20cf307cfcbcefe69104a0e4df4b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Or the group could do it my way and combine key publication and notifying T=
LS support in the same mechanism and the performance issue goes away.<div><=
br></div><div>These are implementation issues, not use cases. &#39;Secure o=
n first connect&#39; is a requirement.</div>
<div><br></div><div>The way I think that the process should go is</div><div=
><br></div><div>1) People propose use cases and performance metrics by whic=
h to validate them. Technical constraints are identified.</div><div><br>
</div><div>2) Use cases are analyzed to determine requirements that satisfy=
 them.=A0</div><div><br></div><div>3) People make proposals that satisfy as=
 many or as few requirements (and thus use cases) as they like.</div><div>
<br></div><div><br></div><div>4) People decide which solution they like and=
 we find out if there is consensus for a single solution or if there is to =
be some horse trading or if the divisions turn out to be=A0irreconcilable=
=A0and we end up with competing proposals.</div>
<div><br></div><div><br></div><div>So far the approach has been that we hav=
e been told what the solution is going to be and that people who disagree h=
ave been accused and abused.</div><div><br></div><div>The performance metri=
cs that matter are the performance metrics for the whole system, not the me=
trics for one individual component.</div>
<div><br></div><div>I can meet all the requirements and constraints that I =
have set out in my proposed use cases document with better performance agai=
nst the specified metrics.</div><div><br></div><div>So I am quite happy to =
accept both the use case and the metric.</div>
<div><br></div><div><br><div class=3D"gmail_quote">On Thu, Apr 14, 2011 at =
1:51 PM, Paul Wouters <span dir=3D"ltr">&lt;<a href=3D"mailto:paul@xeleranc=
e.com">[e-mail]</a>&gt;</span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex;">
<div class=3D"im">On Thu, 14 Apr 2011, Rick Andrews wrote:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Chrome preloads a number of STS tokens (<a href=3D"http://www.chromium.org/=
sts" target=3D"_blank">http://www.chromium.org/sts</a>), so you&#39;re not =
really trusting on first use. Perhaps Google&#39;s SSL database (<a href=3D=
"http://googleonlinesecurity.blogspot.com/2011/04/improving-ssl-certificate=
-security.html" target=3D"_blank">http://googleonlinesecurity.blogspot.com/=
2011/04/improving-ssl-certificate-security.html</a>) could be used to prelo=
ad a huge volume of STS tokens?<br>

</blockquote>
<br></div>
Seems like an excessive solution to save each user a one-time ever DNS look=
up of 20ms for the HASTLS record.<br>
<br>
HASTLS is distributed and controlled by the domain owner. And requires no a=
dded trusted third parties,<br>
or repositories that need to be maintained by browser vendors.<br>
<br>
I also see no obvious way to get my STS token in? Does this solution scale =
at all? It seems to mostly be<br>
beneficial to the &quot;too big to fail&quot; EV carrying websites.<br><fon=
t color=3D"#888888">
<br>
Paul</font><div><div></div><div class=3D"h5"><br>
_______________________________________________<br>
dane mailing list<br>
<a href=3D"mailto:[e-mail]" target=3D"_blank">[e-mail]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/dane</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a=
 href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--20cf307cfcbcefe69104a0e4df4b--

From [e-mail]  Thu Apr 14 12:01:46 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E98E5E08B2 for <[e-mail]>; Thu, 14 Apr 2011 12:01:46 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFQeuggptV34 for <[e-mail]>; Thu, 14 Apr 2011 12:01:45 -0700 (PDT)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfc.amsl.com (Postfix) with ESMTP id 23761E093E for <[e-mail]>; Thu, 14 Apr 2011 12:01:25 -0700 (PDT)
Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 0AD39C5E8; Thu, 14 Apr 2011 15:01:25 -0400 (EDT)
Date: Thu, 14 Apr 2011 15:01:24 -0400 (EDT)
From: Paul Wouters <[e-mail]>
To: Adam Langley <[e-mail]>
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <BANLkTin-E=[e-mail]> <BANLkTi=[e-mail]> <BANLkTikw5uN6tcam5zeq8+Nsp86L=[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [dane] A browser's myopic view
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 14 Apr 2011 19:01:47 -0000

On Thu, 14 Apr 2011, Adam Langley wrote:

> "If you own a site that you would like to see included in the
> preloaded HSTS list, contact: <my email>"

I totally missed that on the page. oops :) My bad.

> Again, HASTLS would need to be a hard fail in order to have a benefit
> over HSTS, and that's not likely to work on today's Internet.
>
> Less importantly, in order to avoid spoofing of HASTLS records, the
> clients have to implement their own DNSSEC resolver.
>
> (The arguments are just the same as with DANE based exclusion vs HSTS
> exclusion.)

Yes, but the protocol is secure, it just needs to be deployed, where HSTS is
not secure because of its port 80 initial dependancy (unless you bootstrap it
otherwise)

If keeping a giant list of hosts scaled, we wouldn't be usin DNS :)

Not to say HSTS has no value. It still protects against all passive attacks for
those websites that enable it. And that is very VERY useful. (Though arguably,
the could be said about HASTLS, I would not put any trust in that without dnssec,
since a DNS UDP packet is more easilly forged then a TCP connection to port 80,
knocked up to port 443 with TLS)

Paul

From [e-mail]  Thu Apr 14 19:46:00 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E1BA9E07BD for <[e-mail]>; Thu, 14 Apr 2011 19:46:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -96.426
X-Spam-Level: 
X-Spam-Status: No, score=-96.426 tagged_above=-999 required=5 tests=[AWL=6.550, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s67LV3hFMlkL for <[e-mail]>; Thu, 14 Apr 2011 19:45:59 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id 43A62E0837 for <[e-mail]>; Thu, 14 Apr 2011 19:45:56 -0700 (PDT)
Received: by vws12 with SMTP id 12so2255187vws.31 for <[e-mail]>; Thu, 14 Apr 2011 19:45:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.88.133 with SMTP id bg5mr2165296vdb.17.1302835555870; Thu, 14 Apr 2011 19:45:55 -0700 (PDT)
Received: by 10.220.202.198 with HTTP; Thu, 14 Apr 2011 19:45:55 -0700 (PDT)
X-Originating-IP: [67.169.203.25]
In-Reply-To: <1302734872.1842.78.camel@localhost>
References: <BANLkTi=[e-mail]> <1302734872.1842.78.camel@localhost>
Date: Thu, 14 Apr 2011 19:45:55 -0700
Message-ID: <BANLkTi=[e-mail]>
From: Kirk Hall <[e-mail]>
To: Matt McCutchen <[e-mail]>, [e-mail]
Content-Type: multipart/alternative; boundary=20cf307d049c82276f04a0ec0a9f
Subject: Re: [dane] Expectations for Self-Signed Cert Trust Indicators under DANE
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: [e-mail]
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 15 Apr 2011 02:46:01 -0000

--20cf307d049c82276f04a0ec0a9f
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Just a few more data points on this discussion concerning trust indicators
for self-signed certs under DANE.



1.  Here is a depiction of a typical phishing site, this one for PayPal.



http://www.csupomona.edu/~ehelp/security/security_phishing.html#PhishingExa=
mple



Notice that consumers are warned as follows:



=93The user should consider an unsecured page (no lock icon) as fraudulent.
Sites such as PayPal would process your login information via a HTTPS
session. HTTPS is the secure version of Hyper-Text Transfer Protocol or HTT=
P
that uses Secure Socket Layer (SSL) technology. HTTPS is now a de facto
standard for websites that gather sensitive information (e.g. account and
credit card information, etc.).=94



Consumers have been taught to look for the lock icon as a trust symbol, or
else the site might be dangerous.  Browsers are unlikely to undo this
consumer training.  I assume this group wants self-signed certs under DANE
to get the lock icon from browsers in order to notify consumers they are in
TLS encryption mode =96 so you will have to consider how to satisfy the
browsers=92 concerns.



2. There=92s a list of numerous phishing URLs at:
http://www.phishtank.com/phish_search.php?page=3D1&active=3Dy&verified=3Du



If you scan through them (there are many) you=92ll find that a lot of them =
are
look-alike domains. Under DANE, they could easily associate self-signed
certs with their domain at the DNS operator level.  Their domains would the=
n
receive exactly the SAME trust indicators that YOUR domains will receive
with a self-signed cert under DANE.  So any idea that DANE will create a
better or more trustworthy environment for consumers has to deal with this
fact.



3.  There are lots of look-alike domains available today.  Here=92s a small
sample:



your-account-bankofamerica.com

my-email-live.com

google-accounts.com

my-paypal-account.com



All of these domains could use self-signed certs at the DNS operator level,
and would then receive exactly the SAME trust indicators that YOUR domains
will receive with a self-signed cert.



4.  I said in my earlier posting that this group should not expect browsers
and other consumer-facing applications to give DANE any trust indicators fo=
r
self-signed certs, unless the certs are somehow flagged as having undergone
anti-fraud checking (not known phishing sites, not look-alike domains).  I
can give you a concrete example of how the browsers will likely react.



As many of you know, there are extensive discussions right now about how to
improve certificate revocation checking.  Consumers often don=92t receive a
response from the issuing CA to a revocation checking request via OCSP or
CRL =96 because of connectivity problems and other issues.  Because there a=
re
so many response failures, the browsers today generally treat this as a
=93soft default=94, let the consumer proceed to the site, and even show the
padlock or other trust indicator (e.g., green bar for EV certs).  However,
the browsers are getting tired of this, and looking for a way to make lack
of an OCSP/CRL response a =93hard=94 default.



One browser =96 Opera =96 has already moved in this direction.  If someone =
using
the Opera browser goes to a domain secured by a CA-issued cert (DV, OV, or
EV), and if there is no response to an OCSP revocation check request, Opera
will not show ANY trust indicators for the site =96 no green bar, no lock
icon, no UI to show TLS encryption.  (They don=92t block the site, so it=92=
s not
a full =93hard=94 default.)  This is true even though the cert came from a =
CA
whose roots are in Opera=92s trusted root store =96 if there=92s no OCSP re=
sponse
from a trusted CA, there will be no trust indicators in the UI.



I=92m quite certain this will be DANE=92s fate among browsers and other con=
sumer
facing applications for self-signed certs, unless DANE builds into its spec=
s
some way to distinguish self-signed certs that have gone through an
anti-fraud check from those that have not.  Browsers might give some sort o=
f
trust indicator for fraud-checked certs =96 at least to show the consumer t=
hat
he or she is in TLS encryption.  Otherwise, I=92m pretty sure the UI won=92=
t
even show encryption is happening because of the danger that phishers will
use DANE to trick people into thinking their sites are =93trustworthy=94.



There may even be issues with the browsers concerning revocation of
self-signed certs =96 if certs from CAs have to maintain CRLs and OCSP
responders, someone might have to maintain a revocation list of some sort
for self-signed certs.



How can self-signed certs get a =93designation=94 that they have undergone
anti-fraud checking?  I don=92t know =96 maybe the DNS operator flags the
fraud-tested certs at the DNS system level?  There may be other ideas on ho=
w
to do this from people on this discussion.  But in my opinion, this group
needs to figure out how to keep the =93bad guys=94 from using DANE and gett=
ing
the same trust indicators that the good guys with self-signed certs hope to
get.



Kirk

--20cf307d049c82276f04a0ec0a9f
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<font face=3D"Times New Roman" size=3D"3">
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt">Just a few more data p=
oints on this discussion concerning trust indicators for self-signed certs =
under DANE.</p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt">=A0</p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt">1.<span style=3D"mso-s=
pacerun: yes">=A0 </span>Here is a depiction of a typical phishing site, th=
is one for PayPal.<span style=3D"mso-spacerun: yes">=A0 </span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt">=A0</p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt"><a href=3D"http://www.=
csupomona.edu/~ehelp/security/security_phishing.html#PhishingExample">http:=
//www.csupomona.edu/~ehelp/security/security_phishing.html#PhishingExample<=
/a></p>

<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt">=A0</p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt">Notice that consumers =
are warned as follows:</p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt">=A0</p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt 0.5in"><span lang=3D"EN=
" style=3D"mso-ansi-language: EN">=93The user should consider an unsecured =
page (no lock icon) as fraudulent. Sites such as PayPal would process your =
login information via a HTTPS session. HTTPS is the secure version of Hyper=
-Text Transfer Protocol or HTTP that uses Secure Socket Layer (SSL) technol=
ogy. HTTPS is now a de facto standard for websites that gather sensitive in=
formation (e.g. account and credit card information, etc.).=94</span></p>

<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt"><span lang=3D"EN" styl=
e=3D"mso-ansi-language: EN">=A0</span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt"><span lang=3D"EN" styl=
e=3D"mso-ansi-language: EN">Consumers have been taught to look for the lock=
 icon as a trust symbol, or else the site might be dangerous.<span style=3D=
"mso-spacerun: yes">=A0 </span>Browsers are unlikely to undo this consumer =
training.<span style=3D"mso-spacerun: yes">=A0 </span>I assume this group w=
ants self-signed certs under DANE to get the lock icon from browsers in ord=
er to notify consumers they are in TLS encryption mode =96 so you will have=
 to consider how to satisfy the browsers=92 concerns.</span></p>

<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt"><span lang=3D"EN" styl=
e=3D"mso-ansi-language: EN">=A0</span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt"><span lang=3D"EN" styl=
e=3D"mso-ansi-language: EN">2. Th</span>ere=92s a list of numerous phishing=
 URLs at: <a title=3D"http://www.phishtank.com/phish_search.php?page=3D1&am=
p;active=3Dy&amp;verified=3Du" href=3D"http://www.phishtank.com/phish_searc=
h.php?page=3D1&amp;active=3Dy&amp;verified=3Du"><font color=3D"#800080">htt=
p://www.phishtank.com/phish_search.php?page=3D1&amp;active=3Dy&amp;verified=
=3Du</font></a> </p>

<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt">=A0</p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt">If you scan through th=
em (there are many) you=92ll find that a lot of them are look-alike domains=
. Under DANE, they could easily associate self-signed certs with their doma=
in at the DNS operator level.<span style=3D"mso-spacerun: yes">=A0 </span>T=
heir domains would then receive exactly the SAME trust indicators that YOUR=
 domains will receive with a self-signed cert under DANE.<span style=3D"mso=
-spacerun: yes">=A0 </span>So any idea that DANE will create a better or mo=
re trustworthy environment for consumers has to deal with this fact.</p>

<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt">=A0</p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt">3.<span style=3D"mso-s=
pacerun: yes">=A0 </span>There are lots of look-alike domains available tod=
ay.<span style=3D"mso-spacerun: yes">=A0 </span>Here=92s a small sample:</p=
>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt">=A0</p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt 0.5in"><a href=3D"http:=
//your-account-bankofamerica.com">your-account-bankofamerica.com</a></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt 0.5in"><a href=3D"http:=
//my-email-live.com">my-email-live.com</a></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt 0.5in"><a href=3D"http:=
//google-accounts.com">google-accounts.com</a></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt 0.5in"><a href=3D"http:=
//my-paypal-account.com">my-paypal-account.com</a></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt">=A0</p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt">All of these domains c=
ould use self-signed certs at the DNS operator level, and would then receiv=
e exactly the SAME trust indicators that YOUR domains will receive with a s=
elf-signed cert.</p>

<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt">=A0</p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt">4.<span style=3D"mso-s=
pacerun: yes">=A0 </span>I said in my earlier posting that this group shoul=
d not expect browsers and other consumer-facing applications to give DANE a=
ny trust indicators for self-signed certs, unless the certs are somehow fla=
gged as having undergone anti-fraud checking (not known phishing sites, not=
 look-alike domains).<span style=3D"mso-spacerun: yes">=A0 </span>I can giv=
e you a concrete example of how the browsers will likely react.</p>

<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt">=A0</p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt">As many of you know, t=
here are extensive discussions right now about how to improve certificate r=
evocation checking.<span style=3D"mso-spacerun: yes">=A0 </span>Consumers o=
ften don=92t receive a response from the issuing CA to a revocation checkin=
g request via OCSP or CRL =96 because of connectivity problems and other is=
sues.<span style=3D"mso-spacerun: yes">=A0 </span>Because there are so many=
 response failures, the browsers today generally treat this as a =93soft de=
fault=94, let the consumer proceed to the site, and even show the padlock o=
r other trust indicator (e.g., green bar for EV certs).<span style=3D"mso-s=
pacerun: yes">=A0 </span>However, the browsers are getting tired of this, a=
nd looking for a way to make lack of an OCSP/CRL response a =93hard=94 defa=
ult.<span style=3D"mso-spacerun: yes">=A0 </span></p>

<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt">=A0</p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt">One browser =96 Opera =
=96 has already moved in this direction.<span style=3D"mso-spacerun: yes">=
=A0 </span>If someone using the Opera browser goes to a domain secured by a=
 CA-issued cert (DV, OV, or EV), and if there is no response to an OCSP rev=
ocation check request, Opera will not show ANY trust indicators for the sit=
e =96 no green bar, no lock icon, no UI to show TLS encryption.<span style=
=3D"mso-spacerun: yes">=A0 </span>(They don=92t block the site, so it=92s n=
ot a full =93hard=94 default.)<span style=3D"mso-spacerun: yes">=A0 </span>=
This is true even though the cert came from a CA whose roots are in Opera=
=92s trusted root store =96 if there=92s no OCSP response from a trusted CA=
, there will be no trust indicators in the UI.</p>

<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt">=A0</p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt">I=92m quite certain th=
is will be DANE=92s fate among browsers and other consumer facing applicati=
ons for self-signed certs, unless DANE builds into its specs some way to di=
stinguish self-signed certs that have gone through an anti-fraud check from=
 those that have not.<span style=3D"mso-spacerun: yes">=A0 </span>Browsers =
might give some sort of trust indicator for fraud-checked certs =96 at leas=
t to show the consumer that he or she is in TLS encryption.<span style=3D"m=
so-spacerun: yes">=A0 </span>Otherwise, I=92m pretty sure the UI won=92t ev=
en show encryption is happening because of the danger that phishers will us=
e DANE to trick people into thinking their sites are =93trustworthy=94.</p>

<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt">=A0</p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt">There may even be issu=
es with the browsers concerning revocation of self-signed certs =96 if cert=
s from CAs have to maintain CRLs and OCSP responders, someone might have to=
 maintain a revocation list of some sort for self-signed certs.</p>

<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt">=A0</p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt">How can self-signed ce=
rts get a =93designation=94 that they have undergone anti-fraud checking?<s=
pan style=3D"mso-spacerun: yes">=A0 </span>I don=92t know =96 maybe the DNS=
 operator flags the fraud-tested certs at the DNS system level?<span style=
=3D"mso-spacerun: yes">=A0 </span>There may be other ideas on how to do thi=
s from people on this discussion.<span style=3D"mso-spacerun: yes">=A0 </sp=
an>But in my opinion, this group needs to figure out how to keep the =93bad=
 guys=94 from using DANE and getting the same trust indicators that the goo=
d guys with self-signed certs hope to get.</p>

<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt">=A0</p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt">Kirk</p></font>

--20cf307d049c82276f04a0ec0a9f--

From [e-mail]  Thu Apr 14 20:51:02 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DCF63E075D for <[e-mail]>; Thu, 14 Apr 2011 20:51: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=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H05904TjBgof for <[e-mail]>; Thu, 14 Apr 2011 20:51:01 -0700 (PDT)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfc.amsl.com (Postfix) with ESMTP id 7C55EE0715 for <[e-mail]>; Thu, 14 Apr 2011 20:51:00 -0700 (PDT)
Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 5BCFDC5E8; Thu, 14 Apr 2011 23:50:58 -0400 (EDT)
Date: Thu, 14 Apr 2011 23:50:57 -0400 (EDT)
From: Paul Wouters <[e-mail]>
To: [e-mail]
In-Reply-To: <BANLkTi=[e-mail]>
Message-ID: <[e-mail]>
References: <BANLkTi=[e-mail]> <1302734872.1842.78.camel@localhost> <BANLkTi=[e-mail]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8BIT
Cc: [e-mail]
Subject: Re: [dane] Expectations for Self-Signed Cert Trust Indicators under DANE
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 15 Apr 2011 03:51:03 -0000

On Thu, 14 Apr 2011, Kirk Hall wrote:

> “The user should consider an unsecured page (no lock icon) as fraudulent. S

> Consumers have been taught to look for the lock icon as a trust symbol

Note that my firefox does not give me a lock symbol if I go to https://www.paypal.com

> your-account-bankofamerica.com
> my-email-live.com
> google-accounts.com
> my-paypal-account.com
> 
> All of these domains could use self-signed certs at the DNS operator level, and would then receive exactly the SAME trust indicators that YOUR domains will receive with a
> self-signed cert.

Yes. Just like that would be the case for www.xelerence.com (vs
www.xelerance.com). It just happens to be that I'm not paypal or verisign,
so the SSL people don't do as many checks to ensure my domain isn't
typosquatted.  And they can't. With the TLDs being so full legitimate
domains appear as a typosquats for other legitimate domains.

> 4.  I said in my earlier posting that this group should not expect browsers and other consumer-facing applications to give DANE any trust indicators for self-signed certs,
> unless the certs are somehow flagged as having undergone anti-fraud checking (not known phishing sites, not look-alike domains).  I can give you a concrete example of how the
> browsers will likely react.

Anti-fraud detection does not scale. Whether via certs or dane or
otherwise. The reason is works is because some "too big to fail" sites
get special protection. Dane does not really change that from the SSL
situation.  (in fact, DV/EV shows failures too,  seeing the mis-issued
domains we know about, and the large list of serials we don't even know
the domain of, and all the unqualified DV/EVs that have been 'fraud
checked' and are still not revoked)

> I’m quite certain this will be DANE’s fate among browsers and other consumer facing applications for self-signed certs, unless DANE builds into its specs some way to
> distinguish self-signed certs that have gone through an anti-fraud check from those that have not.

fraud detection is really out of scope for dane (both the working group
and the protocol) It is indeed a real problem that needs to be solved. But
no easy solution exists that will work for every domain.

> Browsers might give some sort of trust indicator for fraud-checked certs –

But how is this going to be different from round #1 (DV certs) and round
#2 (EV certs) ?  The fundamental problem being that "fraud checked"
means "pay someome more money" with a free market that slowly destroys
that in a few years. (when an EV certs costs $100, it's a pretty good
investment for a fraud, and with a legit paperwork behind it, they can
get that EV cert without problems)

> at least to show the consumer that he or she is in TLS encryption.  Otherwise, I’m pretty sure the UI won’t even show encryption is happening because of the danger that
> phishers will use DANE to trick people into thinking their sites are “trustworthy”.

How to deal with these are hard unsolved problems. I'll refrain from
further speculation.

> There may even be issues with the browsers concerning revocation of self-signed certs – if certs from CAs have to maintain CRLs and OCSP responders, someone might have to
> maintain a revocation list of some sort for self-signed certs.

The good thing about dane is that you can remove bad/stolen certs from
DNS. As for third parties determining my domain is a "forgery" and
blacklisting my dane backed cert, that in itself is a risky business
I'm sure the brower vendors would love to not get entangled in.

> How can self-signed certs get a “designation” that they have undergone anti-fraud checking?  I don’t know – maybe the DNS operator flags the fraud-tested certs at the DNS
> system level?  There may be other ideas on how to do this from people on this discussion.  But in my opinion, this group needs to figure out how to keep the “bad guys” from
> using DANE and getting the same trust indicators that the good guys with self-signed certs hope to get.

The IETF in general does not try to prevent "bad guys" from using
technology, even if it involves security or crypto. And for good reasons.

Dane does not solve the "fraud check issue". The only partial solutions we have
are the ones that work only because they're applied to so few sites.

However, dane does greatly enhance the move of port 80 to port 443, which in itself
is a huge win for everyone, and should certainly not be slowed down because
people might be fooled by crooks because crooks can now easier use TLS as well.

Paul

From [e-mail]  Thu Apr 14 23:11:30 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 71ADCE069D for <[e-mail]>; Thu, 14 Apr 2011 23:11:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.449
X-Spam-Level: 
X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tcdUfBB7Rm1r for <[e-mail]>; Thu, 14 Apr 2011 23:11:29 -0700 (PDT)
Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by ietfc.amsl.com (Postfix) with ESMTP id 4B74EE0693 for <[e-mail]>; Thu, 14 Apr 2011 23:11:29 -0700 (PDT)
Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta14.westchester.pa.mail.comcast.net with comcast id Xi5M1g0020ldTLk5EiBVZY; Fri, 15 Apr 2011 06:11:29 +0000
Received: from odin.ulthar.us ([68.33.77.0]) by omta04.westchester.pa.mail.comcast.net with comcast id XiBV1g00J00PQ6U3QiBVlJ; Fri, 15 Apr 2011 06:11:29 +0000
Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.4/8.14.3) with ESMTP id p3F6BRTY026268 for <[e-mail]>; Fri, 15 Apr 2011 02:11:27 -0400
Received: (from draco@localhost) by odin.ulthar.us (8.14.4/8.14.4/Submit) id p3F6BRoR026266 for [e-mail]; Fri, 15 Apr 2011 02:11:27 -0400
Date: Fri, 15 Apr 2011 02:11:27 -0400
From: Scott Schmit <[e-mail]>
To: [e-mail]
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
References: <BANLkTi=[e-mail]> <1302734872.1842.78.camel@localhost> <BANLkTi=[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <BANLkTi=[e-mail]>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [dane] Expectations for Self-Signed Cert Trust Indicators under DANE
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 15 Apr 2011 06:11:30 -0000

On Thu, Apr 14, 2011 at 07:45:55PM -0700, Kirk Hall wrote:
> 4.  I said in my earlier posting that this group should not expect browsers
> and other consumer-facing applications to give DANE any trust indicators for
> self-signed certs, unless the certs are somehow flagged as having undergone
> anti-fraud checking (not known phishing sites, not look-alike domains).  I
> can give you a concrete example of how the browsers will likely react.

<snip>

> How can self-signed certs get a “designation” that they have undergone
> anti-fraud checking?  I don’t know – maybe the DNS operator flags the
> fraud-tested certs at the DNS system level?  There may be other ideas on how
> to do this from people on this discussion.  But in my opinion, this group
> needs to figure out how to keep the “bad guys” from using DANE and getting
> the same trust indicators that the good guys with self-signed certs hope to
> get.

Attackers control their own DNS (presumably) & therefore are their own
DNS operators, so whatever flag you throw in the TLSA record would be
spoofed by the attackers.

DANE proves that the key on the other end actually belongs to the name
that the client/user specified.

What it doesn't/can't prove is that the client/user specified the right
name (i.e., it doesn't authenticate the mapping between DNS name and
organization/person). That's what CAs are supposed to be doing.

The claim is that DV certs not only bind a key to a (DNS) name, but also
prove that the domain isn't typosquatting some other domain (at least if
they're big enough to "matter"). With DANE vouching for the name/cert
association, the fraud cert question just turns into a DNSSEC-secured
DNSBL/DNSWL (with the advantage that multiple whitelists/blacklists can
be used, so if one of them makes too many mistakes, you can just drop
it from your trusted list with less hesitation).

For EV certs, to get the equivalent multi-CA check, you'd need each CA
to store a copy of the site's cert (bare key wouldn't be enough, since
the CA is actually binding a subject to the key rather than just a DNS
name), e.g.,
_443._tcp.amazon.com.ev.ca.example.com IN TLSA 1 0 1235...

-- 
Scott Schmit

From [e-mail]  Fri Apr 15 02:19:17 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 31482E0694 for <[e-mail]>; Fri, 15 Apr 2011 02:19:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.977
X-Spam-Level: 
X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k85ogdTm+3jt for <[e-mail]>; Fri, 15 Apr 2011 02:19:16 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfc.amsl.com (Postfix) with ESMTP id C43EDE065A for <[e-mail]>; Fri, 15 Apr 2011 02:19:15 -0700 (PDT)
Received: from kpbe16.cbf.corp.google.com (kpbe16.cbf.corp.google.com [172.25.105.80]) by smtp-out.google.com with ESMTP id p3F9JEQp016931 for <[e-mail]>; Fri, 15 Apr 2011 02:19:14 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1302859155; bh=gOGUwyICmJI+UYGEew4IXsHI6Sg=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=x60UjQTPq4JFw/zoj2znGEeyWBsbjMKuG/aDexarWEVH8eICrvhm4tgRCVlNqT4pi uZJNVETaT5SWlvQVP5RQw==
Received: from pvf33 (pvf33.prod.google.com [10.241.210.97]) by kpbe16.cbf.corp.google.com with ESMTP id p3F9J51F003765 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <[e-mail]>; Fri, 15 Apr 2011 02:19:13 -0700
Received: by pvf33 with SMTP id 33so1271532pvf.24 for <[e-mail]>; Fri, 15 Apr 2011 02:19:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=OyV8BCEGY/Sg1QaIAuc1oj1P4sOWE0aE2LVhnaRqNZM=; b=r2a+7drrRK+9RBUSZD6w3opCGv8MkmBScPQpdk5VPKESL/WEIayFHR/9JFObSlNoYM 7K+SpIgztkCk7eeCrOBw==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=n4iB2hs3dNc0eS6YWgS58mZ6SbRL7NC4Dw9hiYAbB/7ZGY3Rjy//OJlAKpOVCha+w6 /JJgnCWCaaggk0JW3GxQ==
MIME-Version: 1.0
Received: by 10.142.63.29 with SMTP id l29mr723230wfa.86.1302859152673; Fri, 15 Apr 2011 02:19:12 -0700 (PDT)
Received: by 10.142.192.21 with HTTP; Fri, 15 Apr 2011 02:19:12 -0700 (PDT)
In-Reply-To: <BANLkTik9Py_EWC+J_9LsLQ2e=[e-mail]>
References: <BANLkTi=[e-mail]> <[e-mail]> <BANLkTik9Py_EWC+J_9LsLQ2e=[e-mail]>
Date: Fri, 15 Apr 2011 10:19:12 +0100
Message-ID: <[e-mail]>
From: Ben Laurie <[e-mail]>
To: Phillip Hallam-Baker <[e-mail]>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
Cc: [e-mail], [e-mail]
Subject: Re: [dane] Expectations for Self-Signed Cert Trust Indicators under DANE
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 15 Apr 2011 09:19:17 -0000

On 13 April 2011 23:07, Phillip Hallam-Baker <[e-mail]> wrote:
> Can we stop the hyperbole?
> How many fraudulently issued CA certs in 15 years?
> How many subjects lost control of their private key?

You're in a better position to estimate this than me. But taking a
look at Comodo's CRL: it currently has 123 entries. Presumably each
entry is a cert that was either fraudulent or lost its private key in
the last year.

So, let's say there are 100 CAs, for the sake of argument: 15 x 123 x
100 =3D 184,500.

Quite a few.

>
> It is really easy to poke holes in an existing deployed security control.
> And really easy to propose alternatives that work perfectly in theory if =
you
> assume that they are not subject to the same issues.
>
> There are use cases for DV certs, but not in my view use cases that invol=
ve
> humans.
>
>
> On Wed, Apr 13, 2011 at 5:34 PM, Nicholas Weaver <[e-mail].e=
du>
> wrote:
>>
>>
>> > One question to you: =A0what practical, actual, real world problem is =
DANE
>> > trying to solve? =A0Is there, in fact, a real security need today for =
someone
>> > to =93know=94 that they have reached the domain they intended to reach=
? =A0(Today,
>> > browsers tell you if there is a mismatch between a domain name and a
>> > CA-issued cert on that domain=92s servers, so to some degree that pote=
ntial
>> > security issue is already resolved.) =A0Do you have examples today of =
actual
>> > problems where people are unsure if they have connected with the domai=
ns
>> > they wanted, and there is a bad result? =A0(And if your example depend=
s on
>> > =93assume there has been a compromise of the DNS=94 =96 aren=92t all b=
ets off in
>> > that situation, where no solution is reliable?) =A0I=92m not trying to=
 be
>> > provocative =96 I really want to know what problem that actually exist=
s today
>> > would be solved with DANE.
>>
>> The actual, real world problem:
>>
>> The CA system is irrevocably broken: There are hundreds of potential pat=
hs
>> of trust, ANY of which can create a DV intercepting certificate for a
>> targeted name.
>>
>> There are incidents we know about happening (Comodo), and there are ones
>> we've suspected have happened (governments have the ability to purchase =
"SSL
>> interception boxes" as commercial products that just need a wildcard
>> certificate. =A0Such products wouldn't exist if governments couldn't get
>> wildcard certificates) but don't have captured certificates to prove.
>>
>>
>> DANE with just a self-signed certificate reduces the paths of trust to a
>> SINGLE path of trust, concurrent with the DNS resolution path for the na=
me.
>>
>> I can NEVER hope to trust "have to trust ALL of a set of hundreds", but =
I
>> MIGHT be able to trust "have to trust just a single path".
>>
>>
>> There's also an economic problem. =A0There is no logistical reason why a=
 CA
>> should charge 10x for *.mydomain.com when compared with www.mydomain.com=
.
>> =A0But they do.
>>
>> DANE with self-signed certificates gives *.mydomain.com, able to sign
>> anything in .mydomain.com, 'for free'.
>>
>>
>> The economic driver is IMO, enough to accomplish the real goal: DANE wit=
h
>> CA certs, which now means that two separate paths of trust (the 'one of =
a
>> hundred' CA plus the 'single-path' DNSSEC) needs to be compromised.
>>
>> _______________________________________________
>> dane mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dane
>
>
>
> --
> Website: http://hallambaker.com/
>
>
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane
>
>

From [e-mail]  Fri Apr 15 07:49:12 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 15E99E0848 for <[e-mail]>; Fri, 15 Apr 2011 07:49:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.567
X-Spam-Level: 
X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[AWL=0.733,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pcPBhB6QpHGw for <[e-mail]>; Fri, 15 Apr 2011 07:49:06 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfc.amsl.com (Postfix) with ESMTP id 3426FE0796 for <[e-mail]>; Fri, 15 Apr 2011 07:49:06 -0700 (PDT)
Received: from anna-filinova.office.nic.cz (unknown [IPv6:2001:1488:ac14:1400:66b9:e8ff:febb:c1d6]) by mail.nic.cz (Postfix) with ESMTPSA id 658F82A2B16 for <[e-mail]>; Fri, 15 Apr 2011 16:49:05 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Fri, 15 Apr 2011 16:49:03 +0200
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[e-mail]>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: [e-mail]
References: <BANLkTi=[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.96.5 at mail
X-Virus-Status: Clean
Subject: Re: [dane] Expectations for Self-Signed Cert Trust Indicators under DANE
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 15 Apr 2011 14:49:12 -0000

>> Do you have examples today of actual
>> problems where people are unsure if they have connected with the domains
>> they wanted, and there is a bad result?
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=460374
>
>
> I understand that CA's want to protect their business interests, and I
> recognize that if DANE-Provided Self-Signed certs were shown in the
> browser in the same manner as EV Certs there wouldn't be any need for
> CAs.  But that's hyperbole - I doubt anyone is pushing for that, I
> doubt further a browser would consider it.  I expect that institutions
> whose image depends on making their users comfortable will *always*
> employ CAs, and that the application users use to connect to those
> institutions for their critical transactions will *always* provide a
> mechanism to show that this institution has used the highest form of
> trustworthiness, and everyone gets warm fuzzies - the user, the
> institution, and the CA.

I think it's important to distinguish between two needs:

1) need to establish a secure connection (to the site/domain name)
2) need to check for (real) identity of the other side

In my view the DANE work is not trying to say anything about 2), but it 
will help to do more of 1), especially at places where self-signed certs 
are used now.

Also maybe the DV-certs are fraud checked for "well-known" names, but I 
would doubt that they will fraud-reject a DV-cert f.e. for surz.org - 
the very common mistake when switching from EN to CS keyboard (they have 
Z/Y keys interchanged).

The fact is that there are places where people just don't care about the 
identity of the other party, they just need to connect securely to the 
other end of the connection.

O.
--
Ondřej Surý <[e-mail]>

From [e-mail]  Fri Apr 15 08:02:10 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C3498E08AB for <[e-mail]>; Fri, 15 Apr 2011 08:02:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.671
X-Spam-Level: 
X-Spam-Status: No, score=-1.671 tagged_above=-999 required=5 tests=[AWL=0.629,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cL-Ye-nYeE+k for <[e-mail]>; Fri, 15 Apr 2011 08:02:10 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfc.amsl.com (Postfix) with ESMTP id 3D799E0840 for <[e-mail]>; Fri, 15 Apr 2011 08:02:10 -0700 (PDT)
Received: from anna-filinova.office.nic.cz (unknown [IPv6:2001:1488:ac14:1400:66b9:e8ff:febb:c1d6]) by mail.nic.cz (Postfix) with ESMTPSA id B39982A02A5 for <[e-mail]>; Fri, 15 Apr 2011 17:02:09 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Fri, 15 Apr 2011 17:02:09 +0200
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[e-mail]>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: [e-mail]
References: <BANLkTin-E=[e-mail]>	<BANLkTi=[e-mail]>	<BANLkTikw5uN6tcam5zeq8+Nsp86L=[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.96.5 at mail
X-Virus-Status: Clean
Subject: Re: [dane] A browser's myopic view
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 15 Apr 2011 15:02:10 -0000

On 4/14/11 3:20 PM, James Cloos wrote:
>>>>>> "ZW" == Zack Weinberg<[e-mail]>  writes:
>
> ZW>  it seems to me that putting a DNSSEC resolver in the browser
> ZW>  is a valuable near-term change in and of itself.
>
> In a dnssec world both recucursers and resolvers SHOULD validate.
>
> So, yes, validating resolver code in browsers and similar apps is
> a welcome addition.
>
> It would be best, though, to separate the resolving code out into
> its own library, just as encryption, et al are in separate libs
> (nss, gnutls, openssl, et cetera).  That would better facilitate
> review, trust and also re-use.

We have:

- libunbound

- DNSSEC-Tool's validator

O.

From [e-mail]  Fri Apr 15 08:23:33 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E63E1E0874 for <[e-mail]>; Fri, 15 Apr 2011 08:23:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.609
X-Spam-Level: 
X-Spam-Status: No, score=-98.609 tagged_above=-999 required=5 tests=[AWL=4.367, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jEHCJjcGfB0r for <[e-mail]>; Fri, 15 Apr 2011 08:23:33 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfc.amsl.com (Postfix) with ESMTP id 0AB7CE0865 for <[e-mail]>; Fri, 15 Apr 2011 08:23:32 -0700 (PDT)
Received: by iwn39 with SMTP id 39so2991711iwn.31 for <[e-mail]>; Fri, 15 Apr 2011 08:23:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.196.233 with SMTP id eh41mr1816996ibb.6.1302881012539; Fri, 15 Apr 2011 08:23:32 -0700 (PDT)
Received: by 10.231.171.202 with HTTP; Fri, 15 Apr 2011 08:23:32 -0700 (PDT)
X-Originating-IP: [67.169.203.25]
In-Reply-To: <[e-mail]>
References: <BANLkTi=[e-mail]> <[e-mail]> <BANLkTik9Py_EWC+J_9LsLQ2e=[e-mail]> <[e-mail]>
Date: Fri, 15 Apr 2011 08:23:32 -0700
Message-ID: <[e-mail]>
From: Kirk Hall <[e-mail]>
To: Ben Laurie <[e-mail]>, [e-mail]
Content-Type: multipart/alternative; boundary=00504502bb18efe2da04a0f69f94
Subject: Re: [dane] Expectations for Self-Signed Cert Trust Indicators under DANE
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: [e-mail]
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 15 Apr 2011 15:23:34 -0000

--00504502bb18efe2da04a0f69f94
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Ben =96 on this one point, I think you have overestimated the number of CRL
entries for fraudulently issued certs among CAs.  Different CAs follow
different practices in when they post a cert to their CRL.  Some post just
about everything =96 expired certs, certs with a month left that have alrea=
dy
been replaced for the customer, certs issued with minor errors to a custome=
r
and then reissued with corrections, certs the customer didn=92t pay for, et=
c.




Others (like my old company GeoTrust) limited their CRLs only to certs wher=
e
a party had explicitly requested revocation per our CPS, or in the rare cas=
e
where we suspected fraud or misuse.  Most GeoTrust revocations were because
of potential private key compromise, not fraud.  As I recall, the number of
certs on GeoTrust=92s CRL was never more than 20 or so at a time =96 and ag=
ain,
most of these were not for fraudulent issuance.  Most CAs do a pretty good
job of sifting through cert requests and rejecting them in advance if they
are from phishers, represent look-alike domains, can=92t produce necessary
proof of ownershipoif the domain or company name, etc. =96 so the cert isn=
=92t
issued, and there=92s no need for revocation.



Kirk

On Fri, Apr 15, 2011 at 2:19 AM, Ben Laurie <[e-mail]> wrote:

> On 13 April 2011 23:07, Phillip Hallam-Baker <[e-mail]> wrote:
> > Can we stop the hyperbole?
> > How many fraudulently issued CA certs in 15 years?
> > How many subjects lost control of their private key?
>
> You're in a better position to estimate this than me. But taking a
> look at Comodo's CRL: it currently has 123 entries. Presumably each
> entry is a cert that was either fraudulent or lost its private key in
> the last year.
>
> So, let's say there are 100 CAs, for the sake of argument: 15 x 123 x
> 100 =3D 184,500.
>
> Quite a few.
>
>
>

--00504502bb18efe2da04a0f69f94
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt"><span style=3D"FONT-SI=
ZE: 10pt; FONT-FAMILY: Arial">Ben =96 on this one point, I think you have o=
verestimated the number of CRL entries for fraudulently issued certs among =
CAs. <span style=3D"mso-spacerun: yes">=A0</span>Different CAs follow diffe=
rent practices in when they post a cert to their CRL. <span style=3D"mso-sp=
acerun: yes">=A0</span>Some post just about everything =96 expired certs, c=
erts with a month left that have already been replaced for the customer, ce=
rts issued with minor errors to a customer and then reissued with correctio=
ns, certs the customer didn=92t pay for, etc. <span style=3D"mso-spacerun: =
yes">=A0</span></span></p>

<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt"><span style=3D"FONT-SI=
ZE: 10pt; FONT-FAMILY: Arial">=A0</span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt"><span style=3D"FONT-SI=
ZE: 10pt; FONT-FAMILY: Arial">Others (like my old company GeoTrust) limited=
 their CRLs only to certs where a party had explicitly requested revocation=
 per our CPS, or in the rare case where we suspected fraud or misuse. <span=
 style=3D"mso-spacerun: yes">=A0</span>Most GeoTrust revocations were becau=
se of potential private key compromise, not fraud. <span style=3D"mso-space=
run: yes">=A0</span>As I recall, the number of certs on GeoTrust=92s CRL wa=
s never more than 20 or so at a time =96 and again, most of these were not =
for fraudulent issuance. <span style=3D"mso-spacerun: yes">=A0</span>Most C=
As do a pretty good job of sifting through cert requests and rejecting them=
 in advance if they are from phishers, represent look-alike domains, can=92=
t produce necessary proof of ownershipoif the domain or company name, etc. =
=96 so the cert isn=92t issued, and there=92s no need for revocation.</span=
></p>

<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt"><span style=3D"FONT-SI=
ZE: 10pt; FONT-FAMILY: Arial">=A0</span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt"><span style=3D"FONT-SI=
ZE: 10pt; FONT-FAMILY: Arial">Kirk</span></p>
<div class=3D"gmail_quote">=A0</div>
<div class=3D"gmail_quote">On Fri, Apr 15, 2011 at 2:19 AM, Ben Laurie <spa=
n dir=3D"ltr">&lt;<a href=3D"mailto:[e-mail]">[e-mail]</a>&gt=
;</span> wrote:<br></div>
<div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div class=3D"im">On 13 April 2011 23:07, Phillip Hallam-Baker &lt;<a href=
=3D"mailto:[e-mail]">[e-mail]</a>&gt; wrote:<br>&gt; Can we=
 stop the hyperbole?<br>&gt; How many fraudulently issued CA certs in 15 ye=
ars?<br>
&gt; How many subjects lost control of their private key?<br><br></div>You&=
#39;re in a better position to estimate this than me. But taking a<br>look =
at Comodo&#39;s CRL: it currently has 123 entries. Presumably each<br>entry=
 is a cert that was either fraudulent or lost its private key in<br>
the last year.<br><br>So, let&#39;s say there are 100 CAs, for the sake of =
argument: 15 x 123 x<br>100 =3D 184,500.<br><br>Quite a few.<br>
<div>
<div></div>
<div class=3D"h5"><br>=A0</div></div></blockquote></div>

--00504502bb18efe2da04a0f69f94--

From [e-mail]  Fri Apr 15 10:00:22 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B2DB9130077 for <[e-mail]>; Fri, 15 Apr 2011 10:00:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.716
X-Spam-Level: 
X-Spam-Status: No, score=-102.716 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULdafiJAh0YM for <[e-mail]>; Fri, 15 Apr 2011 10:00:22 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfc.amsl.com (Postfix) with ESMTP id 0D960130075 for <[e-mail]>; Fri, 15 Apr 2011 10:00:22 -0700 (PDT)
Received: from dhcp89-089-062.bbn.com ([128.89.89.62]:49208) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <[e-mail]>) id 1QAmNZ-000F7E-OD; Fri, 15 Apr 2011 13:00:21 -0400
Mime-Version: 1.0
Message-Id: <p06240806c9ca84af5f69@[10.84.131.40]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Fri, 15 Apr 2011 12:57:26 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 15 Apr 2011 17:00:22 -0000

At 6:45 PM +0200 4/12/11, Martin Rex wrote:
>Stephen Kent wrote:
>>
>>  >For safety, it would be sensible to ALWAYS treat X.509v1 certs as
>>  >EndEntity certs (i.e. never accept them as signer of other certs).
>>  >Our TLS implementation had done this initially, but we had a customer
>>  >that had obtained server certs issued under a VeriSign X.509v1 CA cert
>>  >(as late as 2006!), so I had to make our OEM implementation tolerate this.
>>
>>  The fact that v1 certs contained no mechanism to distinguish between
>>  an EE cert and a CA cert was a major vulnerability, one that has been
>>  exploited in the browser context. I doubt that the IESG will approve
>>  an RFC that calls for supporting v1 certs at this time.
>
>Leaving the status of X.509v1 certs in limbo is a really bad idea.

I don't think of v1 certs as being in limbo. If one reads the intro to RFC 5280
(and its predecessors) there is a discussion of RFC 1422. That RFC described
how to use X.509 v1 certs in the Internet, specifically for secure 
e-mail (PEM).
That RFC noted many of the deficiencies with v1 certs and CRLs, and 
introduced naming and other conventions to try to compensate for 
these v1 cert/CRL problems. The RFC was a proposed standard. Is now 
historic, because we moved to v3 certs. So, any references to v1 
certs in current Internet standards
are downrefs to an Historic RFC, which is questionable for normative refs
at this date.

PKIX published a series of RFCs profiling v3 certs, starting with 
2459 (in 1999) The title has remained constant: "Internet X.509 
Public Key Infrastructure Certificate and CRL Profile." So, the 
message has always been that if one uses X.509 certs in the Internet, 
these certs should be v3, and CRLs should be v2. V1 certs were 
deprecated, consistent with moving 1422 to Historic. The fact that 
all of the v3 cert RFCs have included a discussion of 1422 and why we 
moved to v3 certs seems to be a pretty clear indication of the status 
of v1 certs.

Steve

From [e-mail]  Fri Apr 15 10:00:31 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F25F2130070 for <[e-mail]>; Fri, 15 Apr 2011 10:00:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.699
X-Spam-Level: 
X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nN9giHnD846M for <[e-mail]>; Fri, 15 Apr 2011 10:00:26 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfc.amsl.com (Postfix) with ESMTP id AEDB613007A for <[e-mail]>; Fri, 15 Apr 2011 10:00:24 -0700 (PDT)
Received: from dhcp89-089-062.bbn.com ([128.89.89.62]:49208) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <[e-mail]>) id 1QAmNa-000F7E-Ek; Fri, 15 Apr 2011 13:00:22 -0400
Mime-Version: 1.0
Message-Id: <p06240807c9ca89306d9d@[10.84.131.40]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Fri, 15 Apr 2011 13:00:19 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 15 Apr 2011 17:00:31 -0000

Martin,

...
>
>  This text says that a self-signed certificate is a CA certificate,
>  period. The last sentence says that an EE certificate cannot be used
>  to verify a signature on another certificate, and thus it is not a CA
>  certificate, and thus, not self-signed.

>That is not what rfc5280 says here.  It is really silent on
>self-asserted or self-issued End Entity certs.

5280 is not silent on this topic.  It says that a certificate is 
either and EE certificate of a CA certificate, and that CA 
certificates are of 3 types, one of which is self-signed. This is 
pretty clearly a partition of X.509 certificates in to EE and CA, and 
a further delineation of types of CA certificates. there is no 
ambiguity here, nor did I "misread" the RFC.  I am aware of no text 
in 5280 or in X.509 that suggests a self-signed certificate is 
anything other than a CA certificate.

>I'm somwhat puzzled about the description of (1) in 5280 section 3.2
>and the lack of description of a regular intermediate CA cert.

all CA certs that are not trust anchors are intermediate CA certs. I 
don't know why you are puzzled.

>My familiarity with X.509 and PKI is limited, so I may be wrong,
>but wasn't cross-certificates originally used for CAs that mutually
>sign each others public key in order to cross over between independent
>CA hierarchies?

cross-certs need not be issued in pairs, i.e., unilateral cross 
certification is allowed. But, I'm not sure what relevance this has 
to our discussion anyway.

...
>
>  When I scan 5246 I find one reference to a self-signed cert (page 48).
>  That text is talking about a "root certificate [sic] authority." So that
>  reference is NOT talking about SS certs as EE certs.

>You are looking in the wrong place:
>
>   TLSv1.0:    http://tools.ietf.org/html/rfc2246#section-7.4.2
>   TLSv1.1:    http://tools.ietf.org/html/rfc4346#section-7.4.2

no, I was looking in the RFCs cited by Mr. Farrell :-).

Also, the only text I see in 7.4.2 wrt self-signed certs says:

"Because certificate validation requires that root keys be 
distributed independently, the self-signed certificate which 
specifies the root certificate authority may optionally be omitted 
from the chain, under the assumption that the remote end must already 
possess it in order to validate it in any case."

This cites an ss-cert as a "root certificate [sic] authority" which 
is a CA, an not an EE. So the cite you provided does not support the 
notion of an ss-certificate as an EE certificate.

...

>http://tools.ietf.org/html/rfc5750#section-2.2
>
>2.2.  Certificate Choices
>
>    Receiving agents MUST support v1 X.509 and v3 X.509 certificates as
>    profiled in [KEYM].  End-entity certificates MAY include an Internet
>    mail address, as described in Section 3.

I guess the SEC ADs (and the PKIX chairs) missed this one! Thanks for 
noting that.  At the least errata should be issued. I'll confer with 
Sean on that, and he can see what the IESG wants to do about it, 
since this appears to be a normative reference to a cert format 
described in an Historic RFC and
deprecated in PKIX specs since 1999!

>
>  RFC 4572 makes a number of references to SS certs, and it does
>  envision using them as EE certs. However, the security analysis for using
>  SS certs here is flawed. For example it says (page 9) that it's OK to
>  use a SS cert to assert ANY identity in the TLS session or in an
>  S/MIME-protected SDP exchange.

>Where is your problem.  It is completely irrelevant which identity
>self-signed end entity certificates assert, because these name
>must be ignored anyway.

The WG has not yet decided what checks will be performed, so your 
comment is premature, at best.

>   The only thing that really counts in the
>public key -- and the public key represents the end entity.
>the name in there is only a self-asserted tag within the
>X.509 public key container

You are describing one possible solution, not one that has been adopted.
It is possible to use DNSSEC to publish a CA certificate (self-signed 
or not), and pass an EE certificate (issued under that CA certificate 
or via a cert path terminating at that cert) in the TLS handshake. 
That model would work for folks who have existing certificates issued 
under TAs embedded in browsers, as a transition mechanism, so it's 
clearly advantageous. 

>  In the name of interoperability, the
>  RFC also says (page 9) that if hop-by-hop integrity is employed for
>  SDP, then an SS cert is OK too, even though this allows any SDP
>  entity along the path to spoof any other entity.

>Authentication of self-signed entity certs is solely based on the 
>public key, the identities are completely irrelevant.

One does not "authenticate" a certificate (self-signed or otherwise). 
One validates" a certificate, and 5280 describes the validation 
process. It also notes that a self-signed (vs. self-issued) 
certificate is not subject to the validation process. Such a 
certificate must be acquired via some assured mechanism; DANE is a 
good example of such a mechanism.

I'm, not going to pursue this discussion with you any further. It's a 
poor use of my time and, hopefully, yours, and I'm on vacation for 
the next two weeks!

Steve

From [e-mail]  Fri Apr 15 10:44:09 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 93C8EE0782 for <[e-mail]>; Fri, 15 Apr 2011 10:44:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.357
X-Spam-Level: 
X-Spam-Status: No, score=-102.357 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DuP2Vm5vaORn for <[e-mail]>; Fri, 15 Apr 2011 10:44:08 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfc.amsl.com (Postfix) with ESMTP id 9CB43E0663 for <[e-mail]>; Fri, 15 Apr 2011 10:44:08 -0700 (PDT)
Received: by iye19 with SMTP id 19so3104345iye.31 for <[e-mail]>; Fri, 15 Apr 2011 10:44:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.185.196 with SMTP id cp4mr1934880ibb.56.1302889448149; Fri, 15 Apr 2011 10:44:08 -0700 (PDT)
Received: by 10.231.171.202 with HTTP; Fri, 15 Apr 2011 10:44:08 -0700 (PDT)
X-Originating-IP: [67.139.65.163]
In-Reply-To: <[e-mail]>
References: <BANLkTi=[e-mail]> <[e-mail]> <BANLkTik9Py_EWC+J_9LsLQ2e=[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 15 Apr 2011 10:44:08 -0700
Message-ID: <BANLkTinGEnioZpqorrLoAEs=[e-mail]>
From: Kirk Hall <[e-mail]>
To: Ben Laurie <[e-mail]>, [e-mail]
Content-Type: multipart/alternative; boundary=0016e6d274d5bd14a904a0f89683
Subject: Re: [dane] Expectations for Self-Signed Cert Trust Indicators under DANE
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: [e-mail]
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 15 Apr 2011 17:44:09 -0000

--0016e6d274d5bd14a904a0f89683
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

By the way, the entire revocation checking problem for CAs today (client
failure to get an OCSP response, etc.) could potentially be solved (in my
opinion) if the browsers created a comprehensive browser CRL (a CRL
contained in the browser itself, updated daily or immediately for a major
breach, CAs only allowed to post certs where revocation requested or
security breach - so a very small comprehensive CRL, no need for OCSP pings=
,
etc.) and/or browsers could give a signal to all clients to flush
(refresh) their CRL/OCSP cache in the event of a major security breach.
Here are details:

http://groups.google.com/group/mozilla.dev.security.policy/browse_thread/th=
read/4e14d1282667e9c6
#

With one of these solutions, the existing CA-based PKI infrastructure would
be much more secure for all.

On Fri, Apr 15, 2011 at 8:23 AM, Kirk Hall <[e-mail]> wrote:

> Ben =96 on this one point, I think you have overestimated the number of C=
RL
> entries for fraudulently issued certs among CAs.  Different CAs follow
> different practices in when they post a cert to their CRL.  Some post jus=
t
> about everything =96 expired certs, certs with a month left that have alr=
eady
> been replaced for the customer, certs issued with minor errors to a custo=
mer
> and then reissued with corrections, certs the customer didn=92t pay for, =
etc.
>
>
>
>
> Others (like my old company GeoTrust) limited their CRLs only to certs
> where a party had explicitly requested revocation per our CPS, or in the
> rare case where we suspected fraud or misuse.  Most GeoTrust revocations
> were because of potential private key compromise, not fraud.  As I recall=
,
> the number of certs on GeoTrust=92s CRL was never more than 20 or so at a=
 time
> =96 and again, most of these were not for fraudulent issuance.  Most CAs =
do
> a pretty good job of sifting through cert requests and rejecting them in
> advance if they are from phishers, represent look-alike domains, can=92t
> produce necessary proof of ownershipoif the domain or company name, etc. =
=96
> so the cert isn=92t issued, and there=92s no need for revocation.
>
>
>
> Kirk
>
> On Fri, Apr 15, 2011 at 2:19 AM, Ben Laurie <[e-mail]> wrote:
>
>> On 13 April 2011 23:07, Phillip Hallam-Baker <[e-mail]> wrote:
>> > Can we stop the hyperbole?
>> > How many fraudulently issued CA certs in 15 years?
>> > How many subjects lost control of their private key?
>>
>> You're in a better position to estimate this than me. But taking a
>> look at Comodo's CRL: it currently has 123 entries. Presumably each
>> entry is a cert that was either fraudulent or lost its private key in
>> the last year.
>>
>> So, let's say there are 100 CAs, for the sake of argument: 15 x 123 x
>> 100 =3D 184,500.
>>
>> Quite a few.
>>
>>
>>
>

--0016e6d274d5bd14a904a0f89683
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div>By the way, the entire revocation checking problem for CAs today=A0(cl=
ient failure to get an OCSP response, etc.) could potentially be solved (in=
 my opinion) if the browsers created a comprehensive browser CRL (a CRL con=
tained in the browser itself, updated daily or immediately for a major brea=
ch, CAs only allowed to post certs where revocation requested or security=
=A0breach - so a very small comprehensive CRL, no need for OCSP pings, etc.=
) and/or browsers could give a signal to all clients to flush (refresh)=A0t=
heir CRL/OCSP cache in the event of a major security breach.=A0 Here are de=
tails:</div>

<div>=A0</div>
<div><a href=3D"http://groups.google.com/group/mozilla.dev.security.policy/=
browse_thread/thread/4e14d1282667e9c6">http://groups.google.com/group/mozil=
la.dev.security.policy/browse_thread/thread/4e14d1282667e9c6</a>#</div>
<div>=A0</div>
<div>With one of these solutions, the existing CA-based PKI infrastructure =
would be much more secure for all.<br><br></div>
<div class=3D"gmail_quote">On Fri, Apr 15, 2011 at 8:23 AM, Kirk Hall <span=
 dir=3D"ltr">&lt;<a href=3D"mailto:[e-mail]">khall@affirmtrust=
.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt"><span style=3D"FONT-SI=
ZE: 10pt; FONT-FAMILY: Arial">Ben =96 on this one point, I think you have o=
verestimated the number of CRL entries for fraudulently issued certs among =
CAs. <span>=A0</span>Different CAs follow different practices in when they =
post a cert to their CRL. <span>=A0</span>Some post just about everything =
=96 expired certs, certs with a month left that have already been replaced =
for the customer, certs issued with minor errors to a customer and then rei=
ssued with corrections, certs the customer didn=92t pay for, etc. <span>=A0=
</span></span></p>

<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt"><span style=3D"FONT-SI=
ZE: 10pt; FONT-FAMILY: Arial">=A0</span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt"><span style=3D"FONT-SI=
ZE: 10pt; FONT-FAMILY: Arial">Others (like my old company GeoTrust) limited=
 their CRLs only to certs where a party had explicitly requested revocation=
 per our CPS, or in the rare case where we suspected fraud or misuse. <span=
>=A0</span>Most GeoTrust revocations were because of potential private key =
compromise, not fraud. <span>=A0</span>As I recall, the number of certs on =
GeoTrust=92s CRL was never more than 20 or so at a time =96 and again, most=
 of these were not for fraudulent issuance. <span>=A0</span>Most CAs do a p=
retty good job of sifting through cert requests and rejecting them in advan=
ce if they are from phishers, represent look-alike domains, can=92t produce=
 necessary proof of ownershipoif the domain or company name, etc. =96 so th=
e cert isn=92t issued, and there=92s no need for revocation.</span></p>

<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt"><span style=3D"FONT-SI=
ZE: 10pt; FONT-FAMILY: Arial">=A0</span></p><font color=3D"#888888">
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt"><span style=3D"FONT-SI=
ZE: 10pt; FONT-FAMILY: Arial">Kirk</span></p></font>
<div>
<div></div>
<div class=3D"h5">
<div class=3D"gmail_quote">=A0</div>
<div class=3D"gmail_quote">On Fri, Apr 15, 2011 at 2:19 AM, Ben Laurie <spa=
n dir=3D"ltr">&lt;<a href=3D"mailto:[e-mail]" target=3D"_blank">benl=
@google.com</a>&gt;</span> wrote:<br></div>
<div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div>On 13 April 2011 23:07, Phillip Hallam-Baker &lt;<a href=3D"mailto:hal=
[e-mail]" target=3D"_blank">[e-mail]</a>&gt; wrote:<br>&gt; Ca=
n we stop the hyperbole?<br>&gt; How many fraudulently issued CA certs in 1=
5 years?<br>
&gt; How many subjects lost control of their private key?<br><br></div>You&=
#39;re in a better position to estimate this than me. But taking a<br>look =
at Comodo&#39;s CRL: it currently has 123 entries. Presumably each<br>entry=
 is a cert that was either fraudulent or lost its private key in<br>
the last year.<br><br>So, let&#39;s say there are 100 CAs, for the sake of =
argument: 15 x 123 x<br>100 =3D 184,500.<br><br>Quite a few.<br>
<div>
<div></div>
<div><br>=A0</div></div></blockquote></div></div></div></blockquote></div><=
br>

--0016e6d274d5bd14a904a0f89683--

From [e-mail]  Fri Apr 15 12:29:35 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2090FE07DA for <[e-mail]>; Fri, 15 Apr 2011 12:29:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.988
X-Spam-Level: 
X-Spam-Status: No, score=-9.988 tagged_above=-999 required=5 tests=[AWL=0.261,  BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F1RiDPeoR8gA for <[e-mail]>; Fri, 15 Apr 2011 12:29:34 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfc.amsl.com (Postfix) with ESMTP id 522AAE0682 for <[e-mail]>; Fri, 15 Apr 2011 12:29:34 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p3FJTNYF005276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 15 Apr 2011 21:29:24 +0200 (MEST)
From: Martin Rex <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail] (Stephen Kent)
Date: Fri, 15 Apr 2011 21:29:23 +0200 (MEST)
In-Reply-To: <p06240807c9ca89306d9d@[10.84.131.40]> from "Stephen Kent" at Apr 15, 11 01:00:19 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: [e-mail]
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 15 Apr 2011 19:29:35 -0000

Stephen Kent wrote:
> 
> >http://tools.ietf.org/html/rfc5750#section-2.2
> >
> >2.2.  Certificate Choices
> >
> >    Receiving agents MUST support v1 X.509 and v3 X.509 certificates as
> >    profiled in [KEYM].  End-entity certificates MAY include an Internet
> >    mail address, as described in Section 3.
> 
> I guess the SEC ADs (and the PKIX chairs) missed this one! Thanks for 
> noting that.  At the least errata should be issued.

They didn't miss that one,  It is there for a very reasonable purpose.
Btw. the next paragraph in the above RFC (and its predecessor 3850) reads:

   Receiving agents SHOULD support X.509 version 2 attribute
   certificates.  See [ACAUTH] for details about the profile for
   attribute certificates.

So it doesn't only call for X.509v1 certs, but even for X.509v2 certs!

This definitely is not an error in that document.


-Martin

From [e-mail]  Fri Apr 15 12:35:42 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E5088E0688 for <[e-mail]>; Fri, 15 Apr 2011 12:35:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.755
X-Spam-Level: 
X-Spam-Status: No, score=-2.755 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xI63GJqU-G0P for <[e-mail]>; Fri, 15 Apr 2011 12:35:38 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfc.amsl.com (Postfix) with ESMTP id C50F0E0682 for <[e-mail]>; Fri, 15 Apr 2011 12:35:38 -0700 (PDT)
Received: by vxg33 with SMTP id 33so2907745vxg.31 for <[e-mail]>; Fri, 15 Apr 2011 12:35:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wAGj0MbiSYv3ghiCJJtIzfP1Mun/6lDjKLOevbTa2rA=; b=C/bPbhqjFSjXATc2y9BBbLusCNzak6Fqd+SZa58+krVXkpaq0GqJJbuSEbU26HGKLS X72rPusOUOgpHfPmzBU7VHMpXOmyB0AC/ty4EKWpkyWtWr3FyP0QwjDayZ5RnOMNbU9t 9WoaoRUcqSfEfPeYytCyKKxQBk6q4yQTE7p3E=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=mF5kI60yrfqkG+fV+mmQ5ErAaiqfX1xnB8Tv+J8nsFZ3z/uADk5oS23ruTysiM/uYh MnUfjTwxh3zAZuxEjIjyo8aIiAM831k31DmT1ZB5V3MfUheK5GuYMCdOGMCxe+J3O3bl eV796KdZTYMeJUlw/jzdqJiqs3H2cjeOvunig=
MIME-Version: 1.0
Received: by 10.52.175.5 with SMTP id bw5mr3499824vdc.69.1302896137938; Fri, 15 Apr 2011 12:35:37 -0700 (PDT)
Received: by 10.52.166.230 with HTTP; Fri, 15 Apr 2011 12:35:37 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <p06240807c9ca89306d9d@10.84.131.40> <[e-mail]>
Date: Fri, 15 Apr 2011 15:35:37 -0400
Message-ID: <BANLkTim4kZ39DdgH=[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: [e-mail]
Content-Type: multipart/alternative; boundary=20cf3071cebc7b28ff04a0fa25d9
Cc: [e-mail]
Subject: Re: [dane] [keyassure] Use cases document.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 15 Apr 2011 19:35:43 -0000

--20cf3071cebc7b28ff04a0fa25d9
Content-Type: text/plain; charset=ISO-8859-1

Nope, there is no X.509v3.

There is X.509 which describes formats for Certificates, Attribute
Certificates and CRLs each is versioned separately.


We are up to our third format for certs but only the second format for CRLs,
I can't remember what the current version of attribute cert is, but I seem
to remember its v2 (it would cost me money to check).

X.509 Attribute certs don't work anyway so the issue is moot.


On Fri, Apr 15, 2011 at 3:29 PM, Martin Rex <[e-mail]> wrote:

> Stephen Kent wrote:
> >
> > >http://tools.ietf.org/html/rfc5750#section-2.2
> > >
> > >2.2.  Certificate Choices
> > >
> > >    Receiving agents MUST support v1 X.509 and v3 X.509 certificates as
> > >    profiled in [KEYM].  End-entity certificates MAY include an Internet
> > >    mail address, as described in Section 3.
> >
> > I guess the SEC ADs (and the PKIX chairs) missed this one! Thanks for
> > noting that.  At the least errata should be issued.
>
> They didn't miss that one,  It is there for a very reasonable purpose.
> Btw. the next paragraph in the above RFC (and its predecessor 3850) reads:
>
>   Receiving agents SHOULD support X.509 version 2 attribute
>   certificates.  See [ACAUTH] for details about the profile for
>   attribute certificates.
>
> So it doesn't only call for X.509v1 certs, but even for X.509v2 certs!
>
> This definitely is not an error in that document.
>
>
> -Martin
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane
>



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

--20cf3071cebc7b28ff04a0fa25d9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Nope, there is no X.509v3.=A0<div><br></div><div>There is X.509 which descr=
ibes formats for Certificates, Attribute Certificates and CRLs each is vers=
ioned separately.</div><div><br></div><div><br></div><div>We are up to our =
third format for certs but only the second format for CRLs, I can&#39;t rem=
ember what the current version of attribute cert is, but I seem to remember=
 its v2 (it would cost me money to check).</div>
<div><br></div><div>X.509 Attribute certs don&#39;t work anyway so the issu=
e is moot.</div><div><br></div><div><br><div class=3D"gmail_quote">On Fri, =
Apr 15, 2011 at 3:29 PM, Martin Rex <span dir=3D"ltr">&lt;<a href=3D"mailto=
:[e-mail]">[e-mail]</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;"><div class=3D"im">Stephen Kent wrote:<br>
&gt;<br>
&gt; &gt;<a href=3D"http://tools.ietf.org/html/rfc5750#section-2.2" target=
=3D"_blank">http://tools.ietf.org/html/rfc5750#section-2.2</a><br>
&gt; &gt;<br>
&gt; &gt;2.2. =A0Certificate Choices<br>
&gt; &gt;<br>
&gt; &gt; =A0 =A0Receiving agents MUST support v1 X.509 and v3 X.509 certif=
icates as<br>
&gt; &gt; =A0 =A0profiled in [KEYM]. =A0End-entity certificates MAY include=
 an Internet<br>
&gt; &gt; =A0 =A0mail address, as described in Section 3.<br>
&gt;<br>
&gt; I guess the SEC ADs (and the PKIX chairs) missed this one! Thanks for<=
br>
&gt; noting that. =A0At the least errata should be issued.<br>
<br>
</div>They didn&#39;t miss that one, =A0It is there for a very reasonable p=
urpose.<br>
Btw. the next paragraph in the above RFC (and its predecessor 3850) reads:<=
br>
<br>
 =A0 Receiving agents SHOULD support X.509 version 2 attribute<br>
 =A0 certificates. =A0See [ACAUTH] for details about the profile for<br>
 =A0 attribute certificates.<br>
<br>
So it doesn&#39;t only call for X.509v1 certs, but even for X.509v2 certs!<=
br>
<br>
This definitely is not an error in that document.<br>
<font color=3D"#888888"><br>
<br>
-Martin<br>
</font><div><div></div><div class=3D"h5">__________________________________=
_____________<br>
dane mailing list<br>
<a href=3D"mailto:[e-mail]">[e-mail]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/dane</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a=
 href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--20cf3071cebc7b28ff04a0fa25d9--

From [e-mail]  Fri Apr 15 23:34:51 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BA2DBE06C9 for <[e-mail]>; Fri, 15 Apr 2011 23:34:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.513
X-Spam-Level: 
X-Spam-Status: No, score=-3.513 tagged_above=-999 required=5 tests=[AWL=0.086,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9soO8r6D0qt for <[e-mail]>; Fri, 15 Apr 2011 23:34:51 -0700 (PDT)
Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfc.amsl.com (Postfix) with ESMTP id 9BA0EE0682 for <[e-mail]>; Fri, 15 Apr 2011 23:34:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=[e-mail]; q=dns/txt; s=uoa; t=1302935690; x=1334471690; h=from:to:subject:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20<[e-mail]> |To:=[e-mail],=[e-mail]|Subject:=20Re: =20[dane]=20A=20browser's=20myopic=20view|In-Reply-To:=20 <[e-mail]>|Message-Id:=20<E1QAz5i-0000uj-EI@ login01.fos.auckland.ac.nz>|Date:=20Sat,=2016=20Apr=20201 1=2018:34:46=20+1200; bh=IBZ3kMSPzJ63Auvi/0hXAYrhRqeq6I6FEZVVVwsyQBM=; b=tDiw1vY8C4YuOp6GuKjy7oo4OCMSRU/i/sIOr0aR+WFuR+jBALNVrRxN Deabsa/BT8bvBpw6PI6wOoWqd53M8n45DrSNBgQy/3lAchjYNBXtpg9UM rr/ZOF+FsF90rdLqy4PFtIJmBhZr4WTjMF9u254kv4SlhPzrMi/IhWfjP w=;
X-IronPort-AV: E=Sophos;i="4.64,223,1301832000"; d="scan'208";a="57013493"
X-Ironport-HAT: APP-SERVERS - $RELAYED
X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing
Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 16 Apr 2011 18:34:46 +1200
Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <[e-mail]>) id 1QAz5i-0002jE-Hi; Sat, 16 Apr 2011 18:34:46 +1200
Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from <[e-mail]>) id 1QAz5i-0000uj-EI; Sat, 16 Apr 2011 18:34:46 +1200
From: Peter Gutmann <[e-mail]>
To: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Date: Sat, 16 Apr 2011 18:34:46 +1200
Subject: Re: [dane] A browser's myopic view
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 16 Apr 2011 06:34:51 -0000

=?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[e-mail]> writes:

>We have:
>
>- libunbound

libunbound is nice, but (at least for the Windows incarnation) it's a DNS
server that you have to install and run as a Windows service.  Bzzt, fail.

Peter.


From [e-mail]  Fri Apr 15 23:55:16 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 31A68E06AE for <[e-mail]>; Fri, 15 Apr 2011 23:55:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.516
X-Spam-Level: 
X-Spam-Status: No, score=-3.516 tagged_above=-999 required=5 tests=[AWL=0.083,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FWHM6Uzud8Ds for <[e-mail]>; Fri, 15 Apr 2011 23:55:14 -0700 (PDT)
Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfc.amsl.com (Postfix) with ESMTP id 97DDEE0677 for <[e-mail]>; Fri, 15 Apr 2011 23:55:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=[e-mail]; q=dns/txt; s=uoa; t=1302936914; x=1334472914; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20<[e-mail]> |To:=[e-mail],=[e-mail]|Subject:=20Re: =20[dane]=20Expectations=20for=20Self-Signed=20Cert=20Tru st=20Indicators=20under=20DANE|Cc:=[e-mail],=20kir [e-mail]|In-Reply-To:=20<BANLkTikBceXPK4m2919RSt [e-mail]>|Message-Id:=20<E1QAzPU-00022 [e-mail]>|Date:=20Sat,=2016=20Apr =202011=2018:55:12=20+1200; bh=gmbVthQXpBKJjCepFDIadW1Ux5zvJZ6RyBWV5Xs2lxc=; b=DB/r3q9h5lmqZFsiLhrtL19HTiBgBxaai2HqRS12d4Rfj+lmeT4lGDHh BXSW6tAGw1/+SnAHEJI+FsGD8Mw0KhoPKXAp6H0afF0gjl126JI4NgRYN V2tN87KHC3mucXs1igW2Vt+6i2enOnJGTnVVQh4p1082CPt5p1HzZOSHH 0=;
X-IronPort-AV: E=Sophos;i="4.64,223,1301832000"; d="scan'208";a="57014067"
X-Ironport-HAT: APP-SERVERS - $RELAYED
X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing
Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 16 Apr 2011 18:55:12 +1200
Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <[e-mail]>) id 1QAzPU-0003KD-Gx; Sat, 16 Apr 2011 18:55:12 +1200
Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from <[e-mail]>) id 1QAzPU-00022d-6h; Sat, 16 Apr 2011 18:55:12 +1200
From: Peter Gutmann <[e-mail]>
To: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Date: Sat, 16 Apr 2011 18:55:12 +1200
Cc: [e-mail], [e-mail]
Subject: Re: [dane] Expectations for Self-Signed Cert Trust Indicators under DANE
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 16 Apr 2011 06:55:16 -0000

Phillip Hallam-Baker <[e-mail]> writes:

> Can we stop the hyperbole?
> How many fraudulently issued CA certs in 15 years?

The answer to this is "we have absolutely no idea" (and I assume you mean
"certificates issued by commercial CAs" rather than "CAs issuing other CA
certificates").  From the evidence we have, both public and non-public (e.g.
security researchers trying to get a cert for, for example, apple.com, just to
see if they could), anyone who's ever tried to get a fraudulent certificate
has been able to.  In one case an AV researcher at F-Secure managed to trace
through the actions of a virus writer buying a certificate to sign malware,
and the malware author simply shopped around CAs until he found one who'd sell
him the certificate that he wanted.

So a more accurate summary of the situation is that "we have no evidence of
anyone who wanted to obtain a fraudulent certificate being prevented from
doing so".

Peter.



From [e-mail]  Sat Apr 16 06:23:17 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6BFA9E06AF for <[e-mail]>; Sat, 16 Apr 2011 06:23:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.141
X-Spam-Level: 
X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2Mgf093zjbz for <[e-mail]>; Sat, 16 Apr 2011 06:23:16 -0700 (PDT)
Received: from mail.mrt.ac.lk (mail.mrt.ac.lk [192.248.8.103]) by ietfc.amsl.com (Postfix) with ESMTP id E8B34E0675 for <[e-mail]>; Sat, 16 Apr 2011 06:23:13 -0700 (PDT)
Received: from localhost (smtp.mrt.ac.lk [192.248.8.101]) by mail.mrt.ac.lk (8.12.8/linuxconf) with ESMTP id p3GDN8s1021126 for <[e-mail]>; Sat, 16 Apr 2011 18:53:08 +0530
X-Virus-Scanned: amavisd-new at mrt.ac.lk
Received: from smtp.mrt.ac.lk ([127.0.0.1]) by localhost (smtp.mrt.ac.lk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPK9HFbbbhU2 for <[e-mail]>; Sat, 16 Apr 2011 18:47:06 +0600 (LKT)
Received: from inrelay.mrt.ac.lk (unknown [192.248.8.108]) by smtp.mrt.ac.lk (Postfix) with ESMTP id 6E3AA45A29E for <[e-mail]>; Sat, 16 Apr 2011 18:47:06 +0600 (LKT)
Received: from [192.168.1.4] (unknown [112.134.119.155]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gihan) by inrelay.mrt.ac.lk (Postfix) with ESMTPSA id 3B6AEB22B5 for <[e-mail]>; Sat, 16 Apr 2011 18:51:23 +0530 (IST)
Message-ID: <[e-mail]>
Date: Sat, 16 Apr 2011 18:53:10 +0530
From: Gihan Dias <[e-mail]>
Organization: University of Moratuwa
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3
MIME-Version: 1.0
To: [e-mail]
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [dane] Expectations for Self-Signed Cert Trust Indicators under DANE
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 16 Apr 2011 13:23:17 -0000

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 16-04-2011 12:25, Peter Gutmann wrote:
<blockquote cite="mid:[e-mail]"
 type="cite">
  <pre wrap="">From the evidence we have, both public and non-public (e.g.
security researchers trying to get a cert for, for example, apple.com, just to
see if they could), anyone who's ever tried to get a fraudulent certificate
has been able to.</pre>
</blockquote>
<font size="+1">Peter,<br>
<br>
Thanks for the info. Could you provide me some references for such
incidents?<br>
<br>
Regards,<br>
<br>
Gihan<br>
</font>
</body>
</html>

From [e-mail]  Sat Apr 16 10:37:04 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0AFF1E0714 for <[e-mail]>; Sat, 16 Apr 2011 10:37:04 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkl4UGih7qlO for <[e-mail]>; Sat, 16 Apr 2011 10:37:03 -0700 (PDT)
Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by ietfc.amsl.com (Postfix) with ESMTP id 24F01E0681 for <[e-mail]>; Sat, 16 Apr 2011 10:37:02 -0700 (PDT)
Received: from localhost (75-101-64-22.dsl.dynamic.omsoft.com [75.101.64.22]) by mail.hardakers.net (Postfix) with ESMTPSA id E249154; Sat, 16 Apr 2011 10:36:24 -0700 (PDT)
From: Wes Hardaker <[e-mail]>
To: Peter Gutmann <[e-mail]>
References: <[e-mail]>
Date: Sat, 16 Apr 2011 10:36:23 -0700
In-Reply-To: <[e-mail]> (Peter Gutmann's message of "Sat, 16 Apr 2011 18:34:46 +1200")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110012 (No Gnus v0.12) Emacs/23.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Cc: [e-mail]
Subject: Re: [dane] A browser's myopic view
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 16 Apr 2011 17:37:04 -0000

>>>>> On Sat, 16 Apr 2011 18:34:46 +1200, Peter Gutmann <[e-mail]> said:

>> - libunbound

PG> libunbound is nice, but (at least for the Windows incarnation) it's a DNS
PG> server that you have to install and run as a Windows service.  Bzzt, fail.

FYI, there are at least 1 maybe two other libraries that have/will-be
coming out (but I won't speak for them).

>From the DNSSEC-Tools side, we actually have two libraries.  One is a
pure resolving library and the second is the DNSSEC validation library.
They're intentionally divided into two pieces specifically so that in
theory the validation library could be re-attached to a different
resolving library (that supported the required features).  In practice,
we haven't actually tried to do this but architecturally it was designed
to meet the goals you're talking about.

The windows version of the library is very new and has been less well
tested, but it's been running on most of the "other OSes" for quite a while.
-- 
Wes Hardaker
Cobham Analytic Solutions

From [e-mail]  Sat Apr 16 14:20:31 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B0C4DE06FA for <[e-mail]>; Sat, 16 Apr 2011 14:20: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=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwBF17XXm7hT for <[e-mail]>; Sat, 16 Apr 2011 14:20:31 -0700 (PDT)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfc.amsl.com (Postfix) with ESMTP id EFA16E071E for <[e-mail]>; Sat, 16 Apr 2011 14:20:30 -0700 (PDT)
Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id A832FC60A; Sat, 16 Apr 2011 17:20:27 -0400 (EDT)
Date: Sat, 16 Apr 2011 17:20:26 -0400 (EDT)
From: Paul Wouters <[e-mail]>
To: Peter Gutmann <[e-mail]>
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: [e-mail]
Subject: Re: [dane] A browser's myopic view
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 16 Apr 2011 21:20:31 -0000

On Sat, 16 Apr 2011, Peter Gutmann wrote:

> =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[e-mail]> writes:
>
>> We have:
>>
>> - libunbound
>
> libunbound is nice, but (at least for the Windows incarnation) it's a DNS
> server that you have to install and run as a Windows service.  Bzzt, fail.

No. You are confusing the unbound daemon with libunbound.

The current dane patch uses libunbound as a library within nss within firefox.
No service or daemon needs to be started.

Paul

From [e-mail]  Sat Apr 16 20:10:04 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F228EE0683 for <[e-mail]>; Sat, 16 Apr 2011 20:10:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.523
X-Spam-Level: 
X-Spam-Status: No, score=-3.523 tagged_above=-999 required=5 tests=[AWL=0.076,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKBeg7SskNEH for <[e-mail]>; Sat, 16 Apr 2011 20:10:02 -0700 (PDT)
Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfc.amsl.com (Postfix) with ESMTP id DEB83E069F for <[e-mail]>; Sat, 16 Apr 2011 20:10:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=[e-mail]; q=dns/txt; s=uoa; t=1303009802; x=1334545802; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20<[e-mail]> |To:=[e-mail],=[e-mail] |Subject:=20Re:=20[dane]=20A=20browser's=20myopic=20view |Cc:=[e-mail],=[e-mail]|In-Reply-To: =20<[e-mail]. com>|Message-Id:=20<[e-mail] d.ac.nz>|Date:=20Sun,=2017=20Apr=202011=2015:09:58=20+120 0; bh=agjSuSlR/fx0aYxQ8zqxqxqdZzpVajoSPX/vPUYZQNM=; b=YYszyJJsfemGjpPiVUK4XD8JIWa0+zgZlEOHLi/6SIDfAK2WcO4Pulj+ WZsNhxsLk5EkTN7uNjq15FnNQTexblH8iefEIYUSKdiHFGsFWAYZ8enRo dj8PeRQB/rk6hPowSU4pcI4W7NU/NPe/07rgkfTDK6Q9HrBu+RKEh2FRM A=;
X-IronPort-AV: E=Sophos;i="4.64,225,1301832000"; d="scan'208";a="57056907"
X-Ironport-HAT: APP-SERVERS - $RELAYED
X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing
Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 17 Apr 2011 15:09:59 +1200
Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <[e-mail]>) id 1QBIN4-0002Xj-Hr; Sun, 17 Apr 2011 15:09:58 +1200
Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from <[e-mail]>) id 1QBIN4-0007kT-Fx; Sun, 17 Apr 2011 15:09:58 +1200
From: Peter Gutmann <[e-mail]>
To: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Date: Sun, 17 Apr 2011 15:09:58 +1200
Cc: [e-mail]
Subject: Re: [dane] A browser's myopic view
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 17 Apr 2011 03:10:04 -0000

Paul Wouters <[e-mail]> writes:

>No. You are confusing the unbound daemon with libunbound.
>
>The current dane patch uses libunbound as a library within nss within
>firefox. No service or daemon needs to be started.

Firefox is just a single case.  For DNSSEC to be useful everything that uses
the DNS has to be able to use it.  Under Windows this would mean a standalone
libunbound.dll that anything that talks TCP or UDP can use.

(I get the feeling that DNSSEC-aware Winsock is only going to be on Win7, and
possibly Vista (although given the IE10 Win7-only decision perhaps not), so
the largest, and most vulnerable user population won't have access to it
unless it's provided by a third party).

Peter.

From [e-mail]  Sun Apr 17 11:59:07 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B9872E0722 for <[e-mail]>; Sun, 17 Apr 2011 11:59:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srX+M3Ux++uA for <[e-mail]>; Sun, 17 Apr 2011 11:59:06 -0700 (PDT)
Received: from mail1.eff.org (mail1.eff.org [64.147.188.4]) by ietfc.amsl.com (Postfix) with ESMTP id 9C140E06EC for <[e-mail]>; Sun, 17 Apr 2011 11:59:06 -0700 (PDT)
Received: from [10.0.0.102] (173-228-80-232.dsl.static.sonic.net [173.228.80.232]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: chris) by mail1.eff.org (Postfix) with ESMTPSA id 69110BDD5E for <[e-mail]>; Sun, 17 Apr 2011 11:59:05 -0700 (PDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Apple Message framework v1084)
From: Chris Palmer <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Sun, 17 Apr 2011 11:59:04 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]>
To: [e-mail]
X-Mailer: Apple Mail (2.1084)
Subject: Re: [dane] A browser's myopic view
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 17 Apr 2011 18:59:07 -0000

On Apr 16, 2011, at 8:09 PM, Peter Gutmann wrote:

> Firefox is just a single case.  For DNSSEC to be useful everything =
that uses
> the DNS has to be able to use it.  Under Windows this would mean a =
standalone
> libunbound.dll that anything that talks TCP or UDP can use.
>=20
> (I get the feeling that DNSSEC-aware Winsock is only going to be on =
Win7, and
> possibly Vista (although given the IE10 Win7-only decision perhaps =
not), so
> the largest, and most vulnerable user population won't have access to =
it
> unless it's provided by a third party).

Skimming this guide to deploying DNSSEC for Windows 7/Server 2008 makes =
it seem like only Windows servers, but not Windows clients, can handle =
DNSSEC. (If that is true, it makes no sense other than to support =
software versioning business models and/or strange theories of network =
administration.) Therefore, the guide suggests you set clients to talk =
to their local recursive resolving servers via IPsec.

=
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=3D7a005a14-f74=
0-4689-8c43-9952b5c3d36f&displaylang=3Den

I haven't read it in full, but this passage is representative:

"""
Deploy Name Resolution Policy to Client Computers

In a DNSSEC deployment, validation of DNS queries by client computers is =
enabled through configuration of the following:

=95	IP security (IPsec). IPsec connection security rules are used to =
authenticate communications between DNS servers and client computers. =
For more information about configuring connection security rules, see =
Deploy IPsec Policy to DNS Servers and Deploy IPsec Policy to Client =
Computers.
=95	Name Resolution Policy Table (NRPT). The NRPT is a new feature =
available in Windows Server=AE 2008 R2 and Windows=AE 7 that contains =
policies and settings used by DNS clients when issuing DNS queries and =
receiving DNS responses. The NRPT enables a client to issue queries =
indicating the knowledge of DNSSEC and to check for validation in the =
response.

The following section provides information you can use to configure the =
NRPT.

You can use Group Policy to deploy DNSSEC settings to client computers =
if clients are domain members.  If all client computers are not domain =
members, you can configure DNSSEC settings in the Windows Registry or =
use registry scripts. For more information about the NRPT, see Appendix =
B: The Name Resolution Policy Table (NRPT).

Note: Client computers are typically configured to use multiple DNS =
servers on a network interface. For consistent client behavior, all DNS =
servers that are configured in client network interface properties =
should be capable of performing DNSSEC authentication of DNS queries.
"""

Phrases like "validation of DNS queries by client computers" suggests =
that clients will validate DNS responses, and yet the instructions have =
you using IPsec to rely on a server that does DNSSEC validation, =
suggesting that we are not enjoying end-to-end DNSSEC validation on =
Windows. I gather that the NRPT enables a client to tell its local =
resolving server, via IPsec, "Hey, do DNSSEC queries when querying on my =
behalf, validate the responses, and tell me the answer via IPsec also."

I am not a Windows network administration expert; hopefully somebody =
else on this list is and can clarify. Let's also just take any =
good-natured IPsec-related ribbing as read. ;)

In any case, if it is necessary to use libunbound as a client resolver =
library, or use the Unbound daemon on each client, I don't see what's so =
bad about that. Configuring a local service on all clients is easy =
enough with GPO or scripts, and is a small price to pay for actual =
end-to-end DNSSEC happiness. And it's better than building it into each =
application separately (which in turn is better than nothing).


--=20
Chris Palmer
Technology Director, Electronic Frontier Foundation
https://www.eff.org/code


From [e-mail]  Sun Apr 17 12:41:57 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B0D82E070B for <[e-mail]>; Sun, 17 Apr 2011 12:41:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.75
X-Spam-Level: 
X-Spam-Status: No, score=-2.75 tagged_above=-999 required=5 tests=[AWL=-0.152,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QcmoswTXjycy for <[e-mail]>; Sun, 17 Apr 2011 12:41:56 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfc.amsl.com (Postfix) with ESMTP id 2E5A1E0681 for <[e-mail]>; Sun, 17 Apr 2011 12:41:56 -0700 (PDT)
Received: by vxg33 with SMTP id 33so3865121vxg.31 for <[e-mail]>; Sun, 17 Apr 2011 12:41:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=oMKRMElPGJ8lxPVEacGFJAEfcDBj3mzEvEI/ceMlwZ4=; b=rgUGvd759BjsY7u1PCS1mIG+RkdhEFEs3Q/fvaRnW2qNBAtQhunqKNEYjs+J5jmtGZ dTmKqKN6oZBHNU1NUbf1ItyUOn4As6qQ+3tty2bQUsRSnx+aVTfVZ+/QMzkCMq4Sn8Zj mA4gaJ85UEPbKsI7HwBzkeeZX2gOmyEch7x1M=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=pcTKEKAC2aIwcIbrJy06E9r0gZ+9RRB2TTxUcECII/CYXMqIWr8jOnQNar54WrmD5W voQTF1vEaZLoPYGMBSGeX06x8xh1UkMdIUvIow4e8rZdkIVhroNN7j2/rlQRKgOOQ8HQ 45Xkvzcq6NkgujkPm15HB/bmlcR/ilG+H+g8A=
MIME-Version: 1.0
Received: by 10.52.98.230 with SMTP id el6mr2656931vdb.149.1303069315666; Sun, 17 Apr 2011 12:41:55 -0700 (PDT)
Received: by 10.52.166.230 with HTTP; Sun, 17 Apr 2011 12:41:55 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Sun, 17 Apr 2011 15:41:55 -0400
Message-ID: <BANLkTikaC-wR1XNaOyKyB8N5z0sJcafW=[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: Chris Palmer <[e-mail]>
Content-Type: multipart/alternative; boundary=20cf307cfcbcad947704a12277e5
Cc: [e-mail]
Subject: Re: [dane] A browser's myopic view
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 17 Apr 2011 19:41:57 -0000

--20cf307cfcbcad947704a12277e5
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

When I tried to get Microsoft interested in DNSSEC many moons ago the
response from very senior people there was that they did not see much point
in securing DNS without a trusted routing layer (no BGPSEC would not qualif=
y
even if it existed).

That is one reason why I became interested in keys in the DNS. But it is
still a very uphill battle as DNSSEC is a monolithic single routed hierarch=
y
and the people who make the decisions at Microsoft are very much into model=
s
like Web of Trust and SDSI.


Given the recent announcement that IE10 will only be for Windows 7 and up, =
I
can't see any more development for Vista being likely.


On Sun, Apr 17, 2011 at 2:59 PM, Chris Palmer <[e-mail]> wrote:

> On Apr 16, 2011, at 8:09 PM, Peter Gutmann wrote:
>
> > Firefox is just a single case.  For DNSSEC to be useful everything that
> uses
> > the DNS has to be able to use it.  Under Windows this would mean a
> standalone
> > libunbound.dll that anything that talks TCP or UDP can use.
> >
> > (I get the feeling that DNSSEC-aware Winsock is only going to be on Win=
7,
> and
> > possibly Vista (although given the IE10 Win7-only decision perhaps not)=
,
> so
> > the largest, and most vulnerable user population won't have access to i=
t
> > unless it's provided by a third party).
>
> Skimming this guide to deploying DNSSEC for Windows 7/Server 2008 makes i=
t
> seem like only Windows servers, but not Windows clients, can handle DNSSE=
C.
> (If that is true, it makes no sense other than to support software
> versioning business models and/or strange theories of network
> administration.) Therefore, the guide suggests you set clients to talk to
> their local recursive resolving servers via IPsec.
>
>
> http://www.microsoft.com/downloads/en/details.aspx?FamilyID=3D7a005a14-f7=
40-4689-8c43-9952b5c3d36f&displaylang=3Den
>
> I haven't read it in full, but this passage is representative:
>
> """
> Deploy Name Resolution Policy to Client Computers
>
> In a DNSSEC deployment, validation of DNS queries by client computers is
> enabled through configuration of the following:
>
> =95       IP security (IPsec). IPsec connection security rules are used t=
o
> authenticate communications between DNS servers and client computers. For
> more information about configuring connection security rules, see Deploy
> IPsec Policy to DNS Servers and Deploy IPsec Policy to Client Computers.
> =95       Name Resolution Policy Table (NRPT). The NRPT is a new feature
> available in Windows Server=AE 2008 R2 and Windows=AE 7 that contains pol=
icies
> and settings used by DNS clients when issuing DNS queries and receiving D=
NS
> responses. The NRPT enables a client to issue queries indicating the
> knowledge of DNSSEC and to check for validation in the response.
>
> The following section provides information you can use to configure the
> NRPT.
>
> You can use Group Policy to deploy DNSSEC settings to client computers if
> clients are domain members.  If all client computers are not domain membe=
rs,
> you can configure DNSSEC settings in the Windows Registry or use registry
> scripts. For more information about the NRPT, see Appendix B: The Name
> Resolution Policy Table (NRPT).
>
> Note: Client computers are typically configured to use multiple DNS serve=
rs
> on a network interface. For consistent client behavior, all DNS servers t=
hat
> are configured in client network interface properties should be capable o=
f
> performing DNSSEC authentication of DNS queries.
> """
>
> Phrases like "validation of DNS queries by client computers" suggests tha=
t
> clients will validate DNS responses, and yet the instructions have you us=
ing
> IPsec to rely on a server that does DNSSEC validation, suggesting that we
> are not enjoying end-to-end DNSSEC validation on Windows. I gather that t=
he
> NRPT enables a client to tell its local resolving server, via IPsec, "Hey=
,
> do DNSSEC queries when querying on my behalf, validate the responses, and
> tell me the answer via IPsec also."
>
> I am not a Windows network administration expert; hopefully somebody else
> on this list is and can clarify. Let's also just take any good-natured
> IPsec-related ribbing as read. ;)
>
> In any case, if it is necessary to use libunbound as a client resolver
> library, or use the Unbound daemon on each client, I don't see what's so =
bad
> about that. Configuring a local service on all clients is easy enough wit=
h
> GPO or scripts, and is a small price to pay for actual end-to-end DNSSEC
> happiness. And it's better than building it into each application separat=
ely
> (which in turn is better than nothing).
>
>
> --
> Chris Palmer
> Technology Director, Electronic Frontier Foundation
> https://www.eff.org/code
>
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane
>



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

--20cf307cfcbcad947704a12277e5
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div>When I tried to get Microsoft interested in DNSSEC many moons ago the =
response from very senior people there was that they did not see much point=
 in securing DNS without a trusted routing layer (no BGPSEC would not quali=
fy even if it existed).=A0</div>
<div><br></div><div>That is one reason why I became interested in keys in t=
he DNS. But it is still a very uphill battle as DNSSEC is a monolithic sing=
le routed hierarchy and the people who make the decisions at Microsoft are =
very much into models like Web of Trust and SDSI.=A0</div>
<div><br></div><div><br></div><div>Given the recent announcement that IE10 =
will only be for Windows 7 and up, I can&#39;t see any more development for=
 Vista being likely.=A0</div><div><br></div><div><br><div class=3D"gmail_qu=
ote">
On Sun, Apr 17, 2011 at 2:59 PM, Chris Palmer <span dir=3D"ltr">&lt;<a href=
=3D"mailto:[e-mail]">[e-mail]</a>&gt;</span> wrote:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex;">
<div class=3D"im">On Apr 16, 2011, at 8:09 PM, Peter Gutmann wrote:<br>
<br>
&gt; Firefox is just a single case. =A0For DNSSEC to be useful everything t=
hat uses<br>
&gt; the DNS has to be able to use it. =A0Under Windows this would mean a s=
tandalone<br>
&gt; libunbound.dll that anything that talks TCP or UDP can use.<br>
&gt;<br>
&gt; (I get the feeling that DNSSEC-aware Winsock is only going to be on Wi=
n7, and<br>
&gt; possibly Vista (although given the IE10 Win7-only decision perhaps not=
), so<br>
&gt; the largest, and most vulnerable user population won&#39;t have access=
 to it<br>
&gt; unless it&#39;s provided by a third party).<br>
<br>
</div>Skimming this guide to deploying DNSSEC for Windows 7/Server 2008 mak=
es it seem like only Windows servers, but not Windows clients, can handle D=
NSSEC. (If that is true, it makes no sense other than to support software v=
ersioning business models and/or strange theories of network administration=
.) Therefore, the guide suggests you set clients to talk to their local rec=
ursive resolving servers via IPsec.<br>

<br>
<a href=3D"http://www.microsoft.com/downloads/en/details.aspx?FamilyID=3D7a=
005a14-f740-4689-8c43-9952b5c3d36f&amp;displaylang=3Den" target=3D"_blank">=
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=3D7a005a14-f740=
-4689-8c43-9952b5c3d36f&amp;displaylang=3Den</a><br>

<br>
I haven&#39;t read it in full, but this passage is representative:<br>
<br>
&quot;&quot;&quot;<br>
Deploy Name Resolution Policy to Client Computers<br>
<br>
In a DNSSEC deployment, validation of DNS queries by client computers is en=
abled through configuration of the following:<br>
<br>
=95 =A0 =A0 =A0 IP security (IPsec). IPsec connection security rules are us=
ed to authenticate communications between DNS servers and client computers.=
 For more information about configuring connection security rules, see Depl=
oy IPsec Policy to DNS Servers and Deploy IPsec Policy to Client Computers.=
<br>

=95 =A0 =A0 =A0 Name Resolution Policy Table (NRPT). The NRPT is a new feat=
ure available in Windows Server=AE 2008 R2 and Windows=AE 7 that contains p=
olicies and settings used by DNS clients when issuing DNS queries and recei=
ving DNS responses. The NRPT enables a client to issue queries indicating t=
he knowledge of DNSSEC and to check for validation in the response.<br>

<br>
The following section provides information you can use to configure the NRP=
T.<br>
<br>
You can use Group Policy to deploy DNSSEC settings to client computers if c=
lients are domain members. =A0If all client computers are not domain member=
s, you can configure DNSSEC settings in the Windows Registry or use registr=
y scripts. For more information about the NRPT, see Appendix B: The Name Re=
solution Policy Table (NRPT).<br>

<br>
Note: Client computers are typically configured to use multiple DNS servers=
 on a network interface. For consistent client behavior, all DNS servers th=
at are configured in client network interface properties should be capable =
of performing DNSSEC authentication of DNS queries.<br>

&quot;&quot;&quot;<br>
<br>
Phrases like &quot;validation of DNS queries by client computers&quot; sugg=
ests that clients will validate DNS responses, and yet the instructions hav=
e you using IPsec to rely on a server that does DNSSEC validation, suggesti=
ng that we are not enjoying end-to-end DNSSEC validation on Windows. I gath=
er that the NRPT enables a client to tell its local resolving server, via I=
Psec, &quot;Hey, do DNSSEC queries when querying on my behalf, validate the=
 responses, and tell me the answer via IPsec also.&quot;<br>

<br>
I am not a Windows network administration expert; hopefully somebody else o=
n this list is and can clarify. Let&#39;s also just take any good-natured I=
Psec-related ribbing as read. ;)<br>
<br>
In any case, if it is necessary to use libunbound as a client resolver libr=
ary, or use the Unbound daemon on each client, I don&#39;t see what&#39;s s=
o bad about that. Configuring a local service on all clients is easy enough=
 with GPO or scripts, and is a small price to pay for actual end-to-end DNS=
SEC happiness. And it&#39;s better than building it into each application s=
eparately (which in turn is better than nothing).<br>

<font color=3D"#888888"><br>
<br>
--<br>
Chris Palmer<br>
Technology Director, Electronic Frontier Foundation<br>
<a href=3D"https://www.eff.org/code" target=3D"_blank">https://www.eff.org/=
code</a><br>
</font><div><div></div><div class=3D"h5"><br>
_______________________________________________<br>
dane mailing list<br>
<a href=3D"mailto:[e-mail]">[e-mail]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/dane</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a=
 href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--20cf307cfcbcad947704a12277e5--

From [e-mail]  Sun Apr 17 19:23:25 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2AA79E0688 for <[e-mail]>; Sun, 17 Apr 2011 19:23:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.526
X-Spam-Level: 
X-Spam-Status: No, score=-3.526 tagged_above=-999 required=5 tests=[AWL=0.073,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ETbfn+JYGotf for <[e-mail]>; Sun, 17 Apr 2011 19:23:24 -0700 (PDT)
Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfc.amsl.com (Postfix) with ESMTP id 0D061E066C for <[e-mail]>; Sun, 17 Apr 2011 19:23:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=[e-mail]; q=dns/txt; s=uoa; t=1303093404; x=1334629404; h=from:to:subject:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20<[e-mail]> |To:=[e-mail],=[e-mail]|Subject:=20Re:=20[d ane]=20A=20browser's=20myopic=20view|In-Reply-To:=20<F81A [e-mail]>|Message-Id:=20< [e-mail]>|Date:=20Mon ,=2018=20Apr=202011=2014:23:13=20+1200; bh=sn7wpTzsIMiBSPa3146kj9asV98bRQYLbRzeYOFuUyw=; b=HNrU9ZUmMycXdBJdQ8nJRRCETU2uINOH1MhBhl1IBIcxuNtjASbxtpKT MfOWdhRNMhjxsaK4WxK+y52AXE0A9V9kO1ezhoIJZP0H4DXo7h9KONUHl cP7X3n9zO8Au/hoY7pKwpqoH9ACMtqHd83yGZl9fz1O/b/8+i3pVRuphx M=;
X-IronPort-AV: E=Sophos;i="4.64,229,1301832000"; d="scan'208";a="57181248"
X-Ironport-HAT: APP-SERVERS - $RELAYED
X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing
Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 18 Apr 2011 14:23:14 +1200
Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <[e-mail]>) id 1QBe7N-00032f-IX; Mon, 18 Apr 2011 14:23:13 +1200
Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from <[e-mail]>) id 1QBe7N-0001TF-Ii; Mon, 18 Apr 2011 14:23:13 +1200
From: Peter Gutmann <[e-mail]>
To: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Date: Mon, 18 Apr 2011 14:23:13 +1200
Subject: Re: [dane] A browser's myopic view
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 18 Apr 2011 02:23:25 -0000

Chris Palmer <[e-mail]> writes:

>Skimming this guide to deploying DNSSEC for Windows 7/Server 2008 makes it
>seem like only Windows servers, but not Windows clients, can handle DNSSEC.
>(If that is true, it makes no sense other than to support software versioning
>business models and/or strange theories of network administration.)

I can think of several reasons other than that:

- "Turning on DNSSEC by default is going to cause lots of really hard-to- 
diagnose failures in end-user systems sitting behind crappy home networking 
gear and with ISPs that do odd things to DNS.  The support costs will be 
prohibitive (MS tries to optimise things to autoconfig themselves as much as 
possible, see their various auto-discovery protocols like WPAD and UPnP, 
because unlike everyone else even a 0.1% error rate is a crushing support 
load, and also unlike anyone else they'll make the front page of the NY Times 
if there are any problems).  We'll only enable it on the server, which has a 
knowledgeable sysadmin to try and sort things out".

- "DNSSEC isn't really defending against anything that attackers are 
exploiting, so the benefits consist primarily of (completely invisible to the 
user) warm fuzzies.  In addition the support costs [see above], therefore 
we'll only enable it on the server [see above]".

I'm sure there are others.  It's like AD, you'd never try and deploy that to
end-user PCs.

Peter.

From [e-mail]  Mon Apr 18 05:05:09 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9F241E07C2; Mon, 18 Apr 2011 05:05:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.17
X-Spam-Level: 
X-Spam-Status: No, score=-105.17 tagged_above=-999 required=5 tests=[AWL=1.429, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kxFBLLujV1bz; Mon, 18 Apr 2011 05:05:05 -0700 (PDT)
Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfc.amsl.com (Postfix) with ESMTP id E9340E067D; Mon, 18 Apr 2011 05:05:03 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id E55A2171C6A; Mon, 18 Apr 2011 13:05:01 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1303128296; bh=TFwrScYiaorvxR kWL397NEjui24sdgUMVa+a+RFaeHM=; b=Wvqi6t47gDu2ER0R/KY9mqxXVA1sRb KXv6sFl5qM2k1PZ8gKI2fLdNjii84gdYaUtGtFDNMM7R4qJaAeLWBD/o/cAm7cMb +ucvxJZazn70Z4Djp+FQETma5Qdf2y+L40SXIRRVQFUZV9k40XW/SiyjnwIeCEsA UPusfz29YZoldmYVts0iBeKkn4v7I077owtdcIwHj8HqhtYs6gXXZFjErRL2nWWN a4W/fbi22SYrxPdXqZwus2kbiM27K8FNqGUecnTlIcNFp132vslmclrPVpUulOI0 /C8lpSUdj1JjhAWCN1Ay5BRFLqOuJ1N7aXsbi7aDrUCRMb0kg1jB8lkg==
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id FmGRAwv8SLM7; Mon, 18 Apr 2011 13:04:56 +0100 (IST)
Received: from [134.226.36.137] (stephen-samy.dsg.cs.tcd.ie [134.226.36.137]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id B6F6D171C69; Mon, 18 Apr 2011 13:04:56 +0100 (IST)
Message-ID: <[e-mail]>
Date: Mon, 18 Apr 2011 13:04:55 +0100
From: Stephen Farrell <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
References: <[e-mail]> <p06240807c9ca89306d9d@[10.84.131.40]>
In-Reply-To: <p06240807c9ca89306d9d@[10.84.131.40]>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Cc: pkix <[e-mail]>, [e-mail]
Subject: [dane] 5280 and self-signed ee certs (was: Re: [keyassure] Use cases document.)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 18 Apr 2011 12:05:09 -0000

Sorry to drag this out but I think its worth being clear as to
where the possible disagreement lies since that might influence
how dane approaches handling TLS servers with these kind of
self-signed data structures.

On 15/04/11 18:00, Stephen Kent wrote:
> 5280 is not silent on this topic.  

This is where one of the pkix chairs and one of the authors
of 5280 (me:-) disagree. "This topic" is whether or not
self-signed x.509 structures that are not for CAs are
"covered" by 5280. I believe Steve is saying that 5280 says
that such things are not allowed, whereas I believe that
5280 says nothing about them. I guess we both believe our
interpretation is the right one:-)

> It says that a certificate is either
> and EE certificate of a CA certificate, and that CA certificates are of
> 3 types, one of which is self-signed. This is pretty clearly a partition
> of X.509 certificates in to EE and CA, and a further delineation of
> types of CA certificates. there is no ambiguity here, nor did I
> "misread" the RFC.  

Disagree. Quoting (end of p12):

   This specification covers two classes of certificates: CA
   certificates and end entity certificates.  CA certificates may be
   further divided into three classes: cross-certificates, self-issued
   certificates, and self-signed certificates.

That says that some CA certs are self-signed. It does not say that
all self-signed certs are CA certs. It does not partition EE certs
into any classes at all.

A little further down it says that:

   Self-issued certificates are CA certificates in which
   the issuer and subject are the same entity.  Self-issued certificates
   are generated to support changes in policy or operations.  Self-
   signed certificates are self-issued certificates where the digital
   signature may be verified by the public key bound into the
   certificate.  Self-signed certificates are used to convey a public
   key for use to begin certification paths.

I recall this being added as a result of some confusion as to what
a self-issued vs. self-signed cert might be. I do not recall it being
added as anything normative (indeed there is no 2119 language there).
In any case, in context, it clearly is only referring to CA certs
since those are the only kind for which different (informative)
classes are called out.

And finally:

   End entity certificates
   are issued to subjects that are not authorized to issue certificates.

So I think in 5280 terms its probably fair to say that the term
"self-signed end entity cert" is a bit of a misnomer. However, that
is at this stage a fairly well understood term so I'm not sure if
we'll benefit from trying to get folks to use a different term.

> I am aware of no text in 5280 or in X.509 that
> suggests a self-signed certificate is anything other than a CA certificate.

That's consistent with either interpretation.

So I also took a look at the pkix list archives, and found only one
relevant thread from 2004 that unfortunately doesn't really help. [1]

   [1] http://www.imc.org/ietf-pkix/old-archive-04/msg01611.html

I also found some offlist mail from the design team that we had to
develop 3280bis (which became 5280). It just says:

   "Harmonize language in path validation. Some places used the defined
    term “self-issued” certificate while some places states the
    requirement that subject and issuer names are identical. These
    definitions differ since the term “self-issued” also requires that
    names must be non-empty." (That was issue#65 in a spreadsheet
    Dave Cooper constructed collecting issues for 3280bis dated
    Jan 14 2005, not sure if there's a public archive for that
    [e-mail] list or not.)

So again that doesn't help us here. I didn't find any other mails
with "self" in the subject line from my copy of the 3280bis design
team mails.

My conclusion is that neither 5280 nor the pkix archives justify
any conclusion about self-signed end-entity certs.

I guess if more consideration of this is needed, we should move
the discussion to pkix alone, until there's a conclusion that dane
can use. (So if following up on just the pkix aspect, removing
dane from the cc list is probably the right thing to do.)

To the extent it helps, the W3C web security context WG did also
consider this topic, and included text in their recommendation about
self-signed certs. [2] I think that clearly shows that that group
did envisage the use of this kind of thing for some web servers.
(I was involved in that group as an invited expert, but I don't
recall this particular aspect being in any way controversial there.
There was debate about what to do with such things, but not about
the terminology that I recall.)

   [2] http://www.w3.org/TR/wsc-ui/#selfsignedcerts

Stephen.

PS: Note that Steve's on vacation so this might just sit for a
few weeks until he's back to argue his side of the issue.


From [e-mail]  Mon Apr 18 07:52:25 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5AB26E06D9 for <[e-mail]>; Mon, 18 Apr 2011 07:52:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.19
X-Spam-Level: 
X-Spam-Status: No, score=-6.19 tagged_above=-999 required=5 tests=[AWL=0.409,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGEtZ9s4EcxN for <[e-mail]>; Mon, 18 Apr 2011 07:52:24 -0700 (PDT)
Received: from exprod6og108.obsmtp.com (exprod6og108.obsmtp.com [64.18.1.21]) by ietfc.amsl.com (Postfix) with ESMTP id 12E8AE068E for <[e-mail]>; Mon, 18 Apr 2011 07:52:23 -0700 (PDT)
Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob108.postini.com ([64.18.5.12]) with SMTP ID [e-mail]; Mon, 18 Apr 2011 07:52:24 PDT
Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id p3IEqHGj001706;  Mon, 18 Apr 2011 10:52:17 -0400
Received: from DUL1WNEXMB11.vcorp.ad.vrsn.com ([10.170.13.11]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 18 Apr 2011 10:52:17 -0400
Received: from 10.131.30.110 ([10.131.30.110]) by DUL1WNEXMB11.vcorp.ad.vrsn.com ([10.170.13.11]) with Microsoft Exchange Server HTTP-DAV ; Mon, 18 Apr 2011 14:52:17 +0000
User-Agent: Microsoft-Entourage/12.29.0.110113
Date: Mon, 18 Apr 2011 10:52:17 -0400
From: "Osterweil, Eric" <[e-mail]>
To: Peter Gutmann <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: [dane] A browser's myopic view
Thread-Index: Acv8XOpZGjSBXXwqSO61XiwXf0k8dwBe0uas
In-Reply-To: <[e-mail]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 18 Apr 2011 14:52:17.0707 (UTC) FILETIME=[365DC7B0:01CBFDD8]
Cc: [e-mail]
Subject: Re: [dane] A browser's myopic view
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 18 Apr 2011 14:52:25 -0000

On 4/16/11 1:36 PM, "Wes Hardaker" <[e-mail]> wrote:

>>>>>> On Sat, 16 Apr 2011 18:34:46 +1200, Peter Gutmann
>>>>>> <[e-mail]> said:
> 
>>> - libunbound
> 
> PG> libunbound is nice, but (at least for the Windows incarnation) it's a DNS
> PG> server that you have to install and run as a Windows service.  Bzzt, fail.
> 
> FYI, there are at least 1 maybe two other libraries that have/will-be
> coming out (but I won't speak for them).
> 
> From the DNSSEC-Tools side, we actually have two libraries.  One is a
> pure resolving library and the second is the DNSSEC validation library.
> They're intentionally divided into two pieces specifically so that in
> theory the validation library could be re-attached to a different
> resolving library (that supported the required features).  In practice,
> we haven't actually tried to do this but architecturally it was designed
> to meet the goals you're talking about.
> 
> The windows version of the library is very new and has been less well
> tested, but it's been running on most of the "other OSes" for quite a while.
> --


There is also libvdns ( http://www.vantage-points.org/libvdns.html ) that
does validation as well.  A few research groups have been working on it for
a couple of years. 

Eric


From [e-mail]  Mon Apr 18 14:29:02 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8A623E078B for <[e-mail]>; Mon, 18 Apr 2011 14:29:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.75
X-Spam-Level: 
X-Spam-Status: No, score=-102.75 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z+tiQ-oat9Ld for <[e-mail]>; Mon, 18 Apr 2011 14:29:02 -0700 (PDT)
Received: from s87.loopia.se (s87.loopia.se [194.9.94.114]) by ietfc.amsl.com (Postfix) with ESMTP id 0DEF4E0786 for <[e-mail]>; Mon, 18 Apr 2011 14:28:59 -0700 (PDT)
Received: from s29.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id EB50C2BE5D9 for <[e-mail]>; Mon, 18 Apr 2011 23:29:06 +0200 (CEST)
Received: (qmail 22694 invoked from network); 18 Apr 2011 21:28:58 -0000
Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.8]) ([e-mail]@[213.64.142.247]) (envelope-sender <[e-mail]>) by s29.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 18 Apr 2011 21:28:58 -0000
User-Agent: Microsoft-MacOutlook/14.2.0.101115
Date: Mon, 18 Apr 2011 23:28:53 +0200
From: Stefan Santesson <[e-mail]>
To: Stephen Farrell <[e-mail]>, Stephen Kent <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: [pkix] 5280 and self-signed ee certs (was: Re: [dane] [keyassure] Use cases document.)
In-Reply-To: <[e-mail]>
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
X-Mailman-Approved-At: Mon, 18 Apr 2011 14:32:09 -0700
Cc: pkix <[e-mail]>, [e-mail]
Subject: Re: [dane] [pkix] 5280 and self-signed ee certs (was: Re: [keyassure] Use cases document.)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 18 Apr 2011 21:29:02 -0000

Stephen,

So let me land somewhere in-between.

I understand what you mean by self-signed end-entity certs, but the term
is misleading.

A self signed cert is simply a convenient way to communicate a public key
for an entity that has not been certified by a CA.
I would say that it is a self signed cert. Period. Disregarding what type
of entity it represents.

The internet is full of them. Denying their valid existence does not help
anyone.
As far as RFC 5280 goes, it only deals with these certificates when used
as trust anchors in path validation.

When self-signed certificates are found in e.g. Signed metadata of an
identity federation, that federation may have its own conventions
regarding their use. They are not subject to 5280 path validation so all
of that is out of scope.

/Stefan



On 11-04-18 2:04 PM, "Stephen Farrell" <[e-mail]> wrote:

>
>Sorry to drag this out but I think its worth being clear as to
>where the possible disagreement lies since that might influence
>how dane approaches handling TLS servers with these kind of
>self-signed data structures.
>
>On 15/04/11 18:00, Stephen Kent wrote:
>> 5280 is not silent on this topic.
>
>This is where one of the pkix chairs and one of the authors
>of 5280 (me:-) disagree. "This topic" is whether or not
>self-signed x.509 structures that are not for CAs are
>"covered" by 5280. I believe Steve is saying that 5280 says
>that such things are not allowed, whereas I believe that
>5280 says nothing about them. I guess we both believe our
>interpretation is the right one:-)
>
>> It says that a certificate is either
>> and EE certificate of a CA certificate, and that CA certificates are of
>> 3 types, one of which is self-signed. This is pretty clearly a partition
>> of X.509 certificates in to EE and CA, and a further delineation of
>> types of CA certificates. there is no ambiguity here, nor did I
>> "misread" the RFC.
>
>Disagree. Quoting (end of p12):
>
>   This specification covers two classes of certificates: CA
>   certificates and end entity certificates.  CA certificates may be
>   further divided into three classes: cross-certificates, self-issued
>   certificates, and self-signed certificates.
>
>That says that some CA certs are self-signed. It does not say that
>all self-signed certs are CA certs. It does not partition EE certs
>into any classes at all.
>
>A little further down it says that:
>
>   Self-issued certificates are CA certificates in which
>   the issuer and subject are the same entity.  Self-issued certificates
>   are generated to support changes in policy or operations.  Self-
>   signed certificates are self-issued certificates where the digital
>   signature may be verified by the public key bound into the
>   certificate.  Self-signed certificates are used to convey a public
>   key for use to begin certification paths.
>
>I recall this being added as a result of some confusion as to what
>a self-issued vs. self-signed cert might be. I do not recall it being
>added as anything normative (indeed there is no 2119 language there).
>In any case, in context, it clearly is only referring to CA certs
>since those are the only kind for which different (informative)
>classes are called out.
>
>And finally:
>
>   End entity certificates
>   are issued to subjects that are not authorized to issue certificates.
>
>So I think in 5280 terms its probably fair to say that the term
>"self-signed end entity cert" is a bit of a misnomer. However, that
>is at this stage a fairly well understood term so I'm not sure if
>we'll benefit from trying to get folks to use a different term.
>
>> I am aware of no text in 5280 or in X.509 that
>> suggests a self-signed certificate is anything other than a CA
>>certificate.
>
>That's consistent with either interpretation.
>
>So I also took a look at the pkix list archives, and found only one
>relevant thread from 2004 that unfortunately doesn't really help. [1]
>
>   [1] http://www.imc.org/ietf-pkix/old-archive-04/msg01611.html
>
>I also found some offlist mail from the design team that we had to
>develop 3280bis (which became 5280). It just says:
>
>   "Harmonize language in path validation. Some places used the defined
>    term =B3self-issued=B2 certificate while some places states the
>    requirement that subject and issuer names are identical. These
>    definitions differ since the term =B3self-issued=B2 also requires that
>    names must be non-empty." (That was issue#65 in a spreadsheet
>    Dave Cooper constructed collecting issues for 3280bis dated
>    Jan 14 2005, not sure if there's a public archive for that
>    [e-mail] list or not.)
>
>So again that doesn't help us here. I didn't find any other mails
>with "self" in the subject line from my copy of the 3280bis design
>team mails.
>
>My conclusion is that neither 5280 nor the pkix archives justify
>any conclusion about self-signed end-entity certs.
>
>I guess if more consideration of this is needed, we should move
>the discussion to pkix alone, until there's a conclusion that dane
>can use. (So if following up on just the pkix aspect, removing
>dane from the cc list is probably the right thing to do.)
>
>To the extent it helps, the W3C web security context WG did also
>consider this topic, and included text in their recommendation about
>self-signed certs. [2] I think that clearly shows that that group
>did envisage the use of this kind of thing for some web servers.
>(I was involved in that group as an invited expert, but I don't
>recall this particular aspect being in any way controversial there.
>There was debate about what to do with such things, but not about
>the terminology that I recall.)
>
>   [2] http://www.w3.org/TR/wsc-ui/#selfsignedcerts
>
>Stephen.
>
>PS: Note that Steve's on vacation so this might just sit for a
>few weeks until he's back to argue his side of the issue.
>
>_______________________________________________
>pkix mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/pkix



From [e-mail]  Mon Apr 18 15:00:16 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2E59CE081E; Mon, 18 Apr 2011 15:00:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.745
X-Spam-Level: 
X-Spam-Status: No, score=-2.745 tagged_above=-999 required=5 tests=[AWL=-0.147, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6dUpfBzt0Ai; Mon, 18 Apr 2011 15:00:14 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfc.amsl.com (Postfix) with ESMTP id E550EE06F7; Mon, 18 Apr 2011 15:00:13 -0700 (PDT)
Received: by vxg33 with SMTP id 33so4830374vxg.31 for <multiple recipients>; Mon, 18 Apr 2011 15:00:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=uouoW07oAvmQho6cociz6Waf5fOZ5Gy28SoO2tujrPQ=; b=hZ5ycQM2+zahBI4rnMnv+UdGA26E1DBKJ962lLuV89AHMtFbsEZpH3xsqcVQDhUABs Quuwm1Dkupz2acfaS2N4Dsc5RAzFvX8kG5uFaiWqbJWjHtJJssYJqiRWIfnfSNwruFKc cIq7B3omww4i5ePqs+85nLs3jCG6BAVAq1bsA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Jg8M6+BpJ2vY983/LGkMk20wlhVjEgezzSvZFW/ARYHCkEKrgW/2RIIPia4OvFLulh DrqIT0R8VXpKtP7WgbC50gibMhjhcm1yV/0E+2yb8FeVGLvkjjSXiSCHANHKMG0l6eJ8 GJJT8mEUySiUfJGbBuv+EhKqaJxjpSF8XU9zE=
MIME-Version: 1.0
Received: by 10.52.69.2 with SMTP id a2mr8368454vdu.5.1303164013537; Mon, 18 Apr 2011 15:00:13 -0700 (PDT)
Received: by 10.52.161.3 with HTTP; Mon, 18 Apr 2011 15:00:13 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Mon, 18 Apr 2011 18:00:13 -0400
Message-ID: <BANLkTi=[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: Stefan Santesson <[e-mail]>
Content-Type: multipart/alternative; boundary=20cf30780e6e1c6a9004a1388481
Cc: pkix <[e-mail]>, [e-mail]
Subject: Re: [dane] [pkix] 5280 and self-signed ee certs (was: Re: [keyassure] Use cases document.)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 18 Apr 2011 22:00:16 -0000

--20cf30780e6e1c6a9004a1388481
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I agree that Kent is right on what the spec says.

But the standard is set by the consensus and the running code which
recognize self-signed certs..


I see the following courses of action as being open:

D1) DANE says nothing at all about this issue in the DANE spec (I see no
reason it need be mentioned at all).

D2) DANE says that the EE cert can be a self signed EE cert in accordance
with customary Internet usage

P1) PKIX writes draft on how to specify self signed EE certs so that this i=
s
properly understood. I.E. relying applications MUST NOT rely on any claims
other than the POP of the key and any restrictions on validity/usage.

P2) PKIX ignores the issue.

Note that D1/2 and P1/2 are orthogonal.


These certs exist and I can't see there being a consensus likely to emerge
to require a chain with a CA cert at the head. Nor can I see a requirement
to introduce a downref to X.509v1 to try to circumvent this.



On Mon, Apr 18, 2011 at 5:28 PM, Stefan Santesson <[e-mail]>wrote=
:

> Stephen,
>
> So let me land somewhere in-between.
>
> I understand what you mean by self-signed end-entity certs, but the term
> is misleading.
>
> A self signed cert is simply a convenient way to communicate a public key
> for an entity that has not been certified by a CA.
> I would say that it is a self signed cert. Period. Disregarding what type
> of entity it represents.
>
> The internet is full of them. Denying their valid existence does not help
> anyone.
> As far as RFC 5280 goes, it only deals with these certificates when used
> as trust anchors in path validation.
>
> When self-signed certificates are found in e.g. Signed metadata of an
> identity federation, that federation may have its own conventions
> regarding their use. They are not subject to 5280 path validation so all
> of that is out of scope.
>
> /Stefan
>
>
>
> On 11-04-18 2:04 PM, "Stephen Farrell" <[e-mail]> wrote:
>
> >
> >Sorry to drag this out but I think its worth being clear as to
> >where the possible disagreement lies since that might influence
> >how dane approaches handling TLS servers with these kind of
> >self-signed data structures.
> >
> >On 15/04/11 18:00, Stephen Kent wrote:
> >> 5280 is not silent on this topic.
> >
> >This is where one of the pkix chairs and one of the authors
> >of 5280 (me:-) disagree. "This topic" is whether or not
> >self-signed x.509 structures that are not for CAs are
> >"covered" by 5280. I believe Steve is saying that 5280 says
> >that such things are not allowed, whereas I believe that
> >5280 says nothing about them. I guess we both believe our
> >interpretation is the right one:-)
> >
> >> It says that a certificate is either
> >> and EE certificate of a CA certificate, and that CA certificates are o=
f
> >> 3 types, one of which is self-signed. This is pretty clearly a partiti=
on
> >> of X.509 certificates in to EE and CA, and a further delineation of
> >> types of CA certificates. there is no ambiguity here, nor did I
> >> "misread" the RFC.
> >
> >Disagree. Quoting (end of p12):
> >
> >   This specification covers two classes of certificates: CA
> >   certificates and end entity certificates.  CA certificates may be
> >   further divided into three classes: cross-certificates, self-issued
> >   certificates, and self-signed certificates.
> >
> >That says that some CA certs are self-signed. It does not say that
> >all self-signed certs are CA certs. It does not partition EE certs
> >into any classes at all.
> >
> >A little further down it says that:
> >
> >   Self-issued certificates are CA certificates in which
> >   the issuer and subject are the same entity.  Self-issued certificates
> >   are generated to support changes in policy or operations.  Self-
> >   signed certificates are self-issued certificates where the digital
> >   signature may be verified by the public key bound into the
> >   certificate.  Self-signed certificates are used to convey a public
> >   key for use to begin certification paths.
> >
> >I recall this being added as a result of some confusion as to what
> >a self-issued vs. self-signed cert might be. I do not recall it being
> >added as anything normative (indeed there is no 2119 language there).
> >In any case, in context, it clearly is only referring to CA certs
> >since those are the only kind for which different (informative)
> >classes are called out.
> >
> >And finally:
> >
> >   End entity certificates
> >   are issued to subjects that are not authorized to issue certificates.
> >
> >So I think in 5280 terms its probably fair to say that the term
> >"self-signed end entity cert" is a bit of a misnomer. However, that
> >is at this stage a fairly well understood term so I'm not sure if
> >we'll benefit from trying to get folks to use a different term.
> >
> >> I am aware of no text in 5280 or in X.509 that
> >> suggests a self-signed certificate is anything other than a CA
> >>certificate.
> >
> >That's consistent with either interpretation.
> >
> >So I also took a look at the pkix list archives, and found only one
> >relevant thread from 2004 that unfortunately doesn't really help. [1]
> >
> >   [1] http://www.imc.org/ietf-pkix/old-archive-04/msg01611.html
> >
> >I also found some offlist mail from the design team that we had to
> >develop 3280bis (which became 5280). It just says:
> >
> >   "Harmonize language in path validation. Some places used the defined
> >    term =B3self-issued=B2 certificate while some places states the
> >    requirement that subject and issuer names are identical. These
> >    definitions differ since the term =B3self-issued=B2 also requires th=
at
> >    names must be non-empty." (That was issue#65 in a spreadsheet
> >    Dave Cooper constructed collecting issues for 3280bis dated
> >    Jan 14 2005, not sure if there's a public archive for that
> >    [e-mail] list or not.)
> >
> >So again that doesn't help us here. I didn't find any other mails
> >with "self" in the subject line from my copy of the 3280bis design
> >team mails.
> >
> >My conclusion is that neither 5280 nor the pkix archives justify
> >any conclusion about self-signed end-entity certs.
> >
> >I guess if more consideration of this is needed, we should move
> >the discussion to pkix alone, until there's a conclusion that dane
> >can use. (So if following up on just the pkix aspect, removing
> >dane from the cc list is probably the right thing to do.)
> >
> >To the extent it helps, the W3C web security context WG did also
> >consider this topic, and included text in their recommendation about
> >self-signed certs. [2] I think that clearly shows that that group
> >did envisage the use of this kind of thing for some web servers.
> >(I was involved in that group as an invited expert, but I don't
> >recall this particular aspect being in any way controversial there.
> >There was debate about what to do with such things, but not about
> >the terminology that I recall.)
> >
> >   [2] http://www.w3.org/TR/wsc-ui/#selfsignedcerts
> >
> >Stephen.
> >
> >PS: Note that Steve's on vacation so this might just sit for a
> >few weeks until he's back to argue his side of the issue.
> >
> >_______________________________________________
> >pkix mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/pkix
>
>
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane
>



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

--20cf30780e6e1c6a9004a1388481
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I agree that Kent is right on what the spec says.<div><br></div><div>But th=
e standard is set by the consensus and the running code which recognize sel=
f-signed certs..</div><div><br></div><div><br></div><div>I see the followin=
g courses of action as being open:</div>
<div><br></div><div>D1) DANE says nothing at all about this issue in the DA=
NE spec (I see no reason it need be mentioned at all).</div><div><br></div>=
<div>D2) DANE says that the EE cert can be a self signed EE cert in accorda=
nce with customary Internet usage</div>
<div><br></div><div>P1) PKIX writes draft on how to specify self signed EE =
certs so that this is properly understood. I.E. relying applications MUST N=
OT rely on any claims other than the POP of the key and any restrictions on=
 validity/usage.=A0</div>
<div><br></div><div>P2) PKIX ignores the issue.</div><div><br></div><div>No=
te that D1/2 and P1/2 are orthogonal.</div><div><br></div><div><br></div><d=
iv>These certs exist and I can&#39;t see there being a consensus likely to =
emerge to require a chain with a CA cert at the head. Nor can I see a requi=
rement to introduce a downref to X.509v1 to try to circumvent this.</div>
<div><br></div><div><br></div><div><br><div class=3D"gmail_quote">On Mon, A=
pr 18, 2011 at 5:28 PM, Stefan Santesson <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:[e-mail]">[e-mail]</a>&gt;</span> wrote:<br><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex;">
Stephen,<br>
<br>
So let me land somewhere in-between.<br>
<br>
I understand what you mean by self-signed end-entity certs, but the term<br=
>
is misleading.<br>
<br>
A self signed cert is simply a convenient way to communicate a public key<b=
r>
for an entity that has not been certified by a CA.<br>
I would say that it is a self signed cert. Period. Disregarding what type<b=
r>
of entity it represents.<br>
<br>
The internet is full of them. Denying their valid existence does not help<b=
r>
anyone.<br>
As far as RFC 5280 goes, it only deals with these certificates when used<br=
>
as trust anchors in path validation.<br>
<br>
When self-signed certificates are found in e.g. Signed metadata of an<br>
identity federation, that federation may have its own conventions<br>
regarding their use. They are not subject to 5280 path validation so all<br=
>
of that is out of scope.<br>
<br>
/Stefan<br>
<div><div></div><div class=3D"h5"><br>
<br>
<br>
On 11-04-18 2:04 PM, &quot;Stephen Farrell&quot; &lt;<a href=3D"mailto:step=
[e-mail]">[e-mail]</a>&gt; wrote:<br>
<br>
&gt;<br>
&gt;Sorry to drag this out but I think its worth being clear as to<br>
&gt;where the possible disagreement lies since that might influence<br>
&gt;how dane approaches handling TLS servers with these kind of<br>
&gt;self-signed data structures.<br>
&gt;<br>
&gt;On 15/04/11 18:00, Stephen Kent wrote:<br>
&gt;&gt; 5280 is not silent on this topic.<br>
&gt;<br>
&gt;This is where one of the pkix chairs and one of the authors<br>
&gt;of 5280 (me:-) disagree. &quot;This topic&quot; is whether or not<br>
&gt;self-signed x.509 structures that are not for CAs are<br>
&gt;&quot;covered&quot; by 5280. I believe Steve is saying that 5280 says<b=
r>
&gt;that such things are not allowed, whereas I believe that<br>
&gt;5280 says nothing about them. I guess we both believe our<br>
&gt;interpretation is the right one:-)<br>
&gt;<br>
&gt;&gt; It says that a certificate is either<br>
&gt;&gt; and EE certificate of a CA certificate, and that CA certificates a=
re of<br>
&gt;&gt; 3 types, one of which is self-signed. This is pretty clearly a par=
tition<br>
&gt;&gt; of X.509 certificates in to EE and CA, and a further delineation o=
f<br>
&gt;&gt; types of CA certificates. there is no ambiguity here, nor did I<br=
>
&gt;&gt; &quot;misread&quot; the RFC.<br>
&gt;<br>
&gt;Disagree. Quoting (end of p12):<br>
&gt;<br>
&gt; =A0 This specification covers two classes of certificates: CA<br>
&gt; =A0 certificates and end entity certificates. =A0CA certificates may b=
e<br>
&gt; =A0 further divided into three classes: cross-certificates, self-issue=
d<br>
&gt; =A0 certificates, and self-signed certificates.<br>
&gt;<br>
&gt;That says that some CA certs are self-signed. It does not say that<br>
&gt;all self-signed certs are CA certs. It does not partition EE certs<br>
&gt;into any classes at all.<br>
&gt;<br>
&gt;A little further down it says that:<br>
&gt;<br>
&gt; =A0 Self-issued certificates are CA certificates in which<br>
&gt; =A0 the issuer and subject are the same entity. =A0Self-issued certifi=
cates<br>
&gt; =A0 are generated to support changes in policy or operations. =A0Self-=
<br>
&gt; =A0 signed certificates are self-issued certificates where the digital=
<br>
&gt; =A0 signature may be verified by the public key bound into the<br>
&gt; =A0 certificate. =A0Self-signed certificates are used to convey a publ=
ic<br>
&gt; =A0 key for use to begin certification paths.<br>
&gt;<br>
&gt;I recall this being added as a result of some confusion as to what<br>
&gt;a self-issued vs. self-signed cert might be. I do not recall it being<b=
r>
&gt;added as anything normative (indeed there is no 2119 language there).<b=
r>
&gt;In any case, in context, it clearly is only referring to CA certs<br>
&gt;since those are the only kind for which different (informative)<br>
&gt;classes are called out.<br>
&gt;<br>
&gt;And finally:<br>
&gt;<br>
&gt; =A0 End entity certificates<br>
&gt; =A0 are issued to subjects that are not authorized to issue certificat=
es.<br>
&gt;<br>
&gt;So I think in 5280 terms its probably fair to say that the term<br>
&gt;&quot;self-signed end entity cert&quot; is a bit of a misnomer. However=
, that<br>
&gt;is at this stage a fairly well understood term so I&#39;m not sure if<b=
r>
&gt;we&#39;ll benefit from trying to get folks to use a different term.<br>
&gt;<br>
&gt;&gt; I am aware of no text in 5280 or in X.509 that<br>
&gt;&gt; suggests a self-signed certificate is anything other than a CA<br>
&gt;&gt;certificate.<br>
&gt;<br>
&gt;That&#39;s consistent with either interpretation.<br>
&gt;<br>
&gt;So I also took a look at the pkix list archives, and found only one<br>
&gt;relevant thread from 2004 that unfortunately doesn&#39;t really help. [=
1]<br>
&gt;<br>
&gt; =A0 [1] <a href=3D"http://www.imc.org/ietf-pkix/old-archive-04/msg0161=
1.html" target=3D"_blank">http://www.imc.org/ietf-pkix/old-archive-04/msg01=
611.html</a><br>
&gt;<br>
&gt;I also found some offlist mail from the design team that we had to<br>
&gt;develop 3280bis (which became 5280). It just says:<br>
&gt;<br>
&gt; =A0 &quot;Harmonize language in path validation. Some places used the =
defined<br>
&gt; =A0 =A0term =B3self-issued=B2 certificate while some places states the=
<br>
&gt; =A0 =A0requirement that subject and issuer names are identical. These<=
br>
&gt; =A0 =A0definitions differ since the term =B3self-issued=B2 also requir=
es that<br>
&gt; =A0 =A0names must be non-empty.&quot; (That was issue#65 in a spreadsh=
eet<br>
&gt; =A0 =A0Dave Cooper constructed collecting issues for 3280bis dated<br>
&gt; =A0 =A0Jan 14 2005, not sure if there&#39;s a public archive for that<=
br>
&gt; =A0 =A0<a href=3D"mailto:[e-mail]">[e-mail]</a> list o=
r not.)<br>
&gt;<br>
&gt;So again that doesn&#39;t help us here. I didn&#39;t find any other mai=
ls<br>
&gt;with &quot;self&quot; in the subject line from my copy of the 3280bis d=
esign<br>
&gt;team mails.<br>
&gt;<br>
&gt;My conclusion is that neither 5280 nor the pkix archives justify<br>
&gt;any conclusion about self-signed end-entity certs.<br>
&gt;<br>
&gt;I guess if more consideration of this is needed, we should move<br>
&gt;the discussion to pkix alone, until there&#39;s a conclusion that dane<=
br>
&gt;can use. (So if following up on just the pkix aspect, removing<br>
&gt;dane from the cc list is probably the right thing to do.)<br>
&gt;<br>
&gt;To the extent it helps, the W3C web security context WG did also<br>
&gt;consider this topic, and included text in their recommendation about<br=
>
&gt;self-signed certs. [2] I think that clearly shows that that group<br>
&gt;did envisage the use of this kind of thing for some web servers.<br>
&gt;(I was involved in that group as an invited expert, but I don&#39;t<br>
&gt;recall this particular aspect being in any way controversial there.<br>
&gt;There was debate about what to do with such things, but not about<br>
&gt;the terminology that I recall.)<br>
&gt;<br>
&gt; =A0 [2] <a href=3D"http://www.w3.org/TR/wsc-ui/#selfsignedcerts" targe=
t=3D"_blank">http://www.w3.org/TR/wsc-ui/#selfsignedcerts</a><br>
&gt;<br>
&gt;Stephen.<br>
&gt;<br>
&gt;PS: Note that Steve&#39;s on vacation so this might just sit for a<br>
&gt;few weeks until he&#39;s back to argue his side of the issue.<br>
&gt;<br>
&gt;_______________________________________________<br>
</div></div>&gt;pkix mailing list<br>
&gt;<a href=3D"mailto:[e-mail]">[e-mail]</a><br>
&gt;<a href=3D"https://www.ietf.org/mailman/listinfo/pkix" target=3D"_blank=
">https://www.ietf.org/mailman/listinfo/pkix</a><br>
<div><div></div><div class=3D"h5"><br>
<br>
_______________________________________________<br>
dane mailing list<br>
<a href=3D"mailto:[e-mail]">[e-mail]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/dane</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a=
 href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--20cf30780e6e1c6a9004a1388481--

From [e-mail]  Mon Apr 18 15:49:37 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1CCB2E085A; Mon, 18 Apr 2011 15:49:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.701
X-Spam-Level: 
X-Spam-Status: No, score=-9.701 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f49-sxJ6PfxY; Mon, 18 Apr 2011 15:49:36 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfc.amsl.com (Postfix) with ESMTP id 34016E084C; Mon, 18 Apr 2011 15:49:36 -0700 (PDT)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p3IMnSBI019261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 19 Apr 2011 00:49:32 +0200 (MEST)
From: Martin Rex <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail] (Phillip Hallam-Baker)
Date: Tue, 19 Apr 2011 00:49:28 +0200 (MEST)
In-Reply-To: <BANLkTi=[e-mail]> from "Phillip Hallam-Baker" at Apr 18, 11 06:00:13 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: [dane] [pkix] 5280 and self-signed ee certs (was: Re:
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: [e-mail]
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 18 Apr 2011 22:49:37 -0000

Phillip Hallam-Baker wrote:
> 
> But the standard is set by the consensus and the running code which
> recognize self-signed certs..
> 
> 
> I see the following courses of action as being open:
> 
> D1) DANE says nothing at all about this issue in the DANE spec (I see no
> reason it need be mentioned at all).
> 
> D2) DANE says that the EE cert can be a self signed EE cert in accordance
> with customary Internet usage
> 
> P1) PKIX writes draft on how to specify self signed EE certs so that this is
> properly understood. I.E. relying applications MUST NOT rely on any claims
> other than the POP of the key and any restrictions on validity/usage.
> 
> P2) PKIX ignores the issue.
> 
> Note that D1/2 and P1/2 are orthogonal.
> 
> 
> These certs exist and I can't see there being a consensus likely to emerge
> to require a chain with a CA cert at the head.


I have very little experience with / exposure to the discussions
in the PKIX WG, so I don't know how much I like (P1).

>From the data collected by EFF, there appear to be

  ~ 830000 self-signed X.509v3 Web Server Certs installed on the internet
           with the BasicConstraint cA=TRUE
  ~ 494000 self-signed X.509v1 Web Server Certs installed on the internet

  ~  56000 self-signed X.509v3 Web Server certs installed on the internet
           without the BasicConstraint cA=TRUE

There may be a much higher number of use case for self-signed certs
on home networks (HomeNAS, DSL-Router, Set-Top Boxes), but they're
probably irrelevant for DANE because most are on private IP-Addresses and
don't use officially registered DNS domains on their internal networks.


>
> Nor can I see a requirement
> to introduce a downref to X.509v1 to try to circumvent this.

I do not see the particular gripe that you have with X.509v1.

X.509v1 is a proper subset of X.509v3 -- nothing weird or awkard.


The beauty of X.509v1 certs is that they're *MUCH* easier to create
and hard to get wrong in an interop-impairing fashion.

And, the biggest advantage: enforcing a rule "do not accept as signers
of other certs" is trivial and fool-proof to implement, so that you
don't create immediate and serious problems when you add such
certs to the list of trusted keys for your PKI software along
with Trust Anchors from commercial CAs.

When you mix up self-signed CA certs from some web-servers into the
list of trusted keys next to rootCAs from commercial CAs, then
you may put yourself at risk today.

But what are you real options today, with programmatic clients?
Either disable the peer certificate check entirely, or add some
peers self-signed certs to the same file as the self-signed certs
of the commercial rootCAs.


-Martin

From [e-mail]  Tue Apr 19 00:46:12 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 77E70E0665 for <[e-mail]>; Tue, 19 Apr 2011 00:46:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.512
X-Spam-Level: 
X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lPvw+lh+OxeD for <[e-mail]>; Tue, 19 Apr 2011 00:46:12 -0700 (PDT)
Received: from s87.loopia.se (s87.loopia.se [194.9.94.114]) by ietfc.amsl.com (Postfix) with ESMTP id 16EAFE06F9 for <[e-mail]>; Tue, 19 Apr 2011 00:46:09 -0700 (PDT)
Received: from s60.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 4DC3D346D4A for <[e-mail]>; Tue, 19 Apr 2011 09:45:42 +0200 (CEST)
Received: (qmail 19999 invoked from network); 19 Apr 2011 07:45:39 -0000
Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.8]) ([e-mail]@[213.64.142.247]) (envelope-sender <[e-mail]>) by s60.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <[e-mail]>; 19 Apr 2011 07:45:39 -0000
User-Agent: Microsoft-MacOutlook/14.2.0.101115
Date: Tue, 19 Apr 2011 09:45:37 +0200
From: Stefan Santesson <[e-mail]>
To: <[e-mail]>, Phillip Hallam-Baker <[e-mail]>
Message-ID: <[e-mail]>
Thread-Topic: [pkix] [dane]  5280 and self-signed ee certs (was: Re:
In-Reply-To: <[e-mail]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: [e-mail], [e-mail]
Subject: Re: [dane] [pkix]   5280 and self-signed ee certs (was: Re:
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 19 Apr 2011 07:46:12 -0000

Martin,

For self signed certs in general I think X.509 v1 certs are just fine.

/Stefan

On 11-04-19 12:49 AM, "Martin Rex" <[e-mail]> wrote:

>Phillip Hallam-Baker wrote:
>> 
>> But the standard is set by the consensus and the running code which
>> recognize self-signed certs..
>> 
>> 
>> I see the following courses of action as being open:
>> 
>> D1) DANE says nothing at all about this issue in the DANE spec (I see no
>> reason it need be mentioned at all).
>> 
>> D2) DANE says that the EE cert can be a self signed EE cert in
>>accordance
>> with customary Internet usage
>> 
>> P1) PKIX writes draft on how to specify self signed EE certs so that
>>this is
>> properly understood. I.E. relying applications MUST NOT rely on any
>>claims
>> other than the POP of the key and any restrictions on validity/usage.
>> 
>> P2) PKIX ignores the issue.
>> 
>> Note that D1/2 and P1/2 are orthogonal.
>> 
>> 
>> These certs exist and I can't see there being a consensus likely to
>>emerge
>> to require a chain with a CA cert at the head.
>
>
>I have very little experience with / exposure to the discussions
>in the PKIX WG, so I don't know how much I like (P1).
>
>From the data collected by EFF, there appear to be
>
>  ~ 830000 self-signed X.509v3 Web Server Certs installed on the internet
>           with the BasicConstraint cA=TRUE
>  ~ 494000 self-signed X.509v1 Web Server Certs installed on the internet
>
>  ~  56000 self-signed X.509v3 Web Server certs installed on the internet
>           without the BasicConstraint cA=TRUE
>
>There may be a much higher number of use case for self-signed certs
>on home networks (HomeNAS, DSL-Router, Set-Top Boxes), but they're
>probably irrelevant for DANE because most are on private IP-Addresses and
>don't use officially registered DNS domains on their internal networks.
>
>
>>
>> Nor can I see a requirement
>> to introduce a downref to X.509v1 to try to circumvent this.
>
>I do not see the particular gripe that you have with X.509v1.
>
>X.509v1 is a proper subset of X.509v3 -- nothing weird or awkard.
>
>
>The beauty of X.509v1 certs is that they're *MUCH* easier to create
>and hard to get wrong in an interop-impairing fashion.
>
>And, the biggest advantage: enforcing a rule "do not accept as signers
>of other certs" is trivial and fool-proof to implement, so that you
>don't create immediate and serious problems when you add such
>certs to the list of trusted keys for your PKI software along
>with Trust Anchors from commercial CAs.
>
>When you mix up self-signed CA certs from some web-servers into the
>list of trusted keys next to rootCAs from commercial CAs, then
>you may put yourself at risk today.
>
>But what are you real options today, with programmatic clients?
>Either disable the peer certificate check entirely, or add some
>peers self-signed certs to the same file as the self-signed certs
>of the commercial rootCAs.
>
>
>-Martin
>_______________________________________________
>pkix mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/pkix



From [e-mail]  Tue Apr 19 07:40:11 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 17643E0700; Tue, 19 Apr 2011 07:40:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.941
X-Spam-Level: 
X-Spam-Status: No, score=-2.941 tagged_above=-999 required=5 tests=[AWL=0.057,  BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYNxxcPbYOXM; Tue, 19 Apr 2011 07:40:09 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id 4C06CE06E9; Tue, 19 Apr 2011 07:40:09 -0700 (PDT)
Received: by vws12 with SMTP id 12so5442049vws.31 for <multiple recipients>; Tue, 19 Apr 2011 07:40:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=VAMhcyBrVT6/O9fFaI9dnHu1204diTlRZgrnQM/pUoY=; b=hRJjE74JILI3Ta81a2Y1W6S6sS8GnqnQJl5eAbKIAYt3LV94pulLEqmBDD8WqN8Pdb X23XH2zuO45nH88fUCFQ59fp2a3YxE8KxrgYex6D+X/S/BdTrGjKufVQJNyI6lwvfJgp l/B/ECYRxJ+8IV4kfC12J4S9hNryw3QW6L/gg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=JQ7dSG7T47VjM7zoJuWXgc9IQDKEhUlzhSu+dXQ3UmMrlLswIPGfN3eYhiidm/9WAy I29Newi3Nx+EWgY1nHMpLml4a+4suVQZeKjRPqza2ScNMqkK6lE563WWGPCQHncwIFzR va9tGOaSyV4OmIwMn5PJjBkjDHpYccM9En1HQ=
MIME-Version: 1.0
Received: by 10.52.173.240 with SMTP id bn16mr3900481vdc.245.1303224007977; Tue, 19 Apr 2011 07:40:07 -0700 (PDT)
Received: by 10.52.161.3 with HTTP; Tue, 19 Apr 2011 07:40:07 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 19 Apr 2011 10:40:07 -0400
Message-ID: <[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: "Kemp, David P." <[e-mail]>
Content-Type: multipart/alternative; boundary=bcaec51b199d0eec5204a1467c71
Cc: Stefan Santesson <[e-mail]>, [e-mail], [e-mail]
Subject: Re: [dane] [pkix]  5280 and self-signed ee certs (was: Re:
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 19 Apr 2011 14:40:11 -0000

--bcaec51b199d0eec5204a1467c71
Content-Type: text/plain; charset=ISO-8859-1

There is no problem with using X.509v1 certs.

But there is a very big problem with trying to make a normative reference in
a new standards proposal to a standard that has been deprecated (ITU) or
made HISTORIC (IETF).


Given the vast number of v1 certs in circulation plus the very long
lifetimes on many of them, I can't see a problem with requiring relying
applications to process v1 certs. The use case here would be to support a
device that shipped with a built in v1 device cert without having to rekey
the device.

But I can see a very big problem with attempting to get round the PKIX
lawyering with a requirement that cannot be supported in a reasonable manner
using the current standards.


I really don't see this as a DANE issue. I see it as a requirement to
clarify the PKIX spec as follows:

* CA signing key usage MUST be set for keys used to sign certificates for
any key OTHER THAN THEMSELVES.

* EE certs may be CA signed or self-signed.

* Security considerations for using self-signed certs (probably two pages
worth at least). Specifically, no positive claims can be relied on other
than POP for the key, all use restrictions and validity conditions MUST be
observed.


Since this is currently the largest class of server certificate deployed by
number of certs it would be ostrich-like behavior to ignore them. I can't
see programmers deciding that they want to have applications that generate
self-signed certs create a chain of two certs for no other purpose than to
comply with the spec.





On Tue, Apr 19, 2011 at 9:18 AM, Kemp, David P. <[e-mail]>wrote:

> There's nothing wrong with self-signed X.509 v1 certs except the "X.509"
> part and the "certificate" part.
>
> Self-signed keys have nice properties other than proof of possession -
> they allow an entity to "stake a claim" on a
> cryptographically-guaranteed-unused identity and support
> continuity-based (or reputation-based) trust in that identity, in
> addition to standard out-of-band mechanisms.  If wishes were horses ...
> everyone would use a PKIX-standard signed key assertion that was NOT a
> syntactically-valid X.509 certificate.  I don't see how using X.509v1
> instead of x.509v3 for self-signed end-entity keys prevents applications
> from misusing them as CA certs.
>
> Dave
>
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Stefan Santesson
> Sent: Tuesday, April 19, 2011 3:46 AM
> To: [e-mail]; Phillip Hallam-Baker
> Cc: [e-mail]; [e-mail]
> Subject: Re: [pkix] [dane] 5280 and self-signed ee certs (was: Re:
>
> Martin,
>
> For self signed certs in general I think X.509 v1 certs are just fine.
>
> /Stefan
>
> On 11-04-19 12:49 AM, "Martin Rex" <[e-mail]> wrote:
>
> >Phillip Hallam-Baker wrote:
> >>
> >> But the standard is set by the consensus and the running code which
> >> recognize self-signed certs..
> >>
> >>
> >> I see the following courses of action as being open:
> >>
> >> D1) DANE says nothing at all about this issue in the DANE spec (I see
> no
> >> reason it need be mentioned at all).
> >>
> >> D2) DANE says that the EE cert can be a self signed EE cert in
> >>accordance
> >> with customary Internet usage
> >>
> >> P1) PKIX writes draft on how to specify self signed EE certs so that
> >>this is
> >> properly understood. I.E. relying applications MUST NOT rely on any
> >>claims
> >> other than the POP of the key and any restrictions on validity/usage.
> >>
> >> P2) PKIX ignores the issue.
> >>
> >> Note that D1/2 and P1/2 are orthogonal.
> >>
> >>
> >> These certs exist and I can't see there being a consensus likely to
> >>emerge
> >> to require a chain with a CA cert at the head.
> >
> >
> >I have very little experience with / exposure to the discussions
> >in the PKIX WG, so I don't know how much I like (P1).
> >
> >From the data collected by EFF, there appear to be
> >
> >  ~ 830000 self-signed X.509v3 Web Server Certs installed on the
> internet
> >           with the BasicConstraint cA=TRUE
> >  ~ 494000 self-signed X.509v1 Web Server Certs installed on the
> internet
> >
> >  ~  56000 self-signed X.509v3 Web Server certs installed on the
> internet
> >           without the BasicConstraint cA=TRUE
> >
> >There may be a much higher number of use case for self-signed certs
> >on home networks (HomeNAS, DSL-Router, Set-Top Boxes), but they're
> >probably irrelevant for DANE because most are on private IP-Addresses
> and
> >don't use officially registered DNS domains on their internal networks.
> >
> >
> >>
> >> Nor can I see a requirement
> >> to introduce a downref to X.509v1 to try to circumvent this.
> >
> >I do not see the particular gripe that you have with X.509v1.
> >
> >X.509v1 is a proper subset of X.509v3 -- nothing weird or awkard.
> >
> >
> >The beauty of X.509v1 certs is that they're *MUCH* easier to create
> >and hard to get wrong in an interop-impairing fashion.
> >
> >And, the biggest advantage: enforcing a rule "do not accept as signers
> >of other certs" is trivial and fool-proof to implement, so that you
> >don't create immediate and serious problems when you add such
> >certs to the list of trusted keys for your PKI software along
> >with Trust Anchors from commercial CAs.
> >
> >When you mix up self-signed CA certs from some web-servers into the
> >list of trusted keys next to rootCAs from commercial CAs, then
> >you may put yourself at risk today.
> >
> >But what are you real options today, with programmatic clients?
> >Either disable the peer certificate check entirely, or add some
> >peers self-signed certs to the same file as the self-signed certs
> >of the commercial rootCAs.
> >
> >
> >-Martin
> >_______________________________________________
> >pkix mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/pkix
>
>
> _______________________________________________
> pkix mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pkix
>



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

--bcaec51b199d0eec5204a1467c71
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

There is no problem with using X.509v1 certs.<div><br></div><div>But there =
is a very big problem with trying to make a normative reference in a new st=
andards proposal to a standard that has been deprecated (ITU) or made HISTO=
RIC (IETF).<br>
<br></div><div><br></div><div>Given the vast number of v1 certs in circulat=
ion plus the very long lifetimes on many of them, I can&#39;t see a problem=
 with requiring relying applications to process v1 certs. The use case here=
 would be to support a device that shipped with a built in v1 device cert w=
ithout having to rekey the device.=A0</div>
<div><br></div><div>But I can see a very big problem with attempting to get=
 round the PKIX lawyering with a requirement that cannot be supported in a =
reasonable manner using the current standards.=A0</div><div><br></div><div>
<br></div><div>I really don&#39;t see this as a DANE issue. I see it as a r=
equirement to clarify the PKIX spec as follows:</div><div><br></div><div>* =
CA signing key usage MUST be set for keys used to sign certificates for any=
 key OTHER THAN THEMSELVES.</div>
<div><br></div><div>* EE certs may be CA signed or self-signed.</div><div><=
br></div><div>* Security considerations for using self-signed certs (probab=
ly two pages worth at least). Specifically, no positive claims can be relie=
d on other than POP for the key, all use restrictions and validity conditio=
ns MUST be observed.</div>
<div><br></div><div><br></div><div>Since this is currently the largest clas=
s of server certificate deployed by number of certs it would be ostrich-lik=
e behavior to ignore them. I can&#39;t see programmers deciding that they w=
ant to have applications that generate self-signed certs create a chain of =
two certs for no other purpose than to comply with the spec.</div>
<div><br></div><div><br></div><div><br></div><div><br></div><div><br><div c=
lass=3D"gmail_quote">On Tue, Apr 19, 2011 at 9:18 AM, Kemp, David P. <span =
dir=3D"ltr">&lt;<a href=3D"mailto:[e-mail]">[e-mail].=
mil</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;">There&#39;s nothing wrong with self-signed =
X.509 v1 certs except the &quot;X.509&quot;<br>
part and the &quot;certificate&quot; part.<br>
<br>
Self-signed keys have nice properties other than proof of possession -<br>
they allow an entity to &quot;stake a claim&quot; on a<br>
cryptographically-guaranteed-unused identity and support<br>
continuity-based (or reputation-based) trust in that identity, in<br>
addition to standard out-of-band mechanisms. =A0If wishes were horses ...<b=
r>
everyone would use a PKIX-standard signed key assertion that was NOT a<br>
syntactically-valid X.509 certificate. =A0I don&#39;t see how using X.509v1=
<br>
instead of x.509v3 for self-signed end-entity keys prevents applications<br=
>
from misusing them as CA certs.<br>
<br>
Dave<br>
<br>
<br>
-----Original Message-----<br>
From: <a href=3D"mailto:[e-mail]">[e-mail]</a> [m=
ailto:<a href=3D"mailto:[e-mail]">[e-mail]</a>] O=
n Behalf Of<br>
Stefan Santesson<br>
Sent: Tuesday, April 19, 2011 3:46 AM<br>
To: <a href=3D"mailto:[e-mail]">[e-mail]</a>; Phillip Hallam-Baker<=
br>
Cc: <a href=3D"mailto:[e-mail]">[e-mail]</a>; <a href=3D"mailto:d=
[e-mail]">[e-mail]</a><br>
Subject: Re: [pkix] [dane] 5280 and self-signed ee certs (was: Re:<br>
<div><div></div><div class=3D"h5"><br>
Martin,<br>
<br>
For self signed certs in general I think X.509 v1 certs are just fine.<br>
<br>
/Stefan<br>
<br>
On 11-04-19 12:49 AM, &quot;Martin Rex&quot; &lt;<a href=3D"mailto:mrex@sap=
.com">[e-mail]</a>&gt; wrote:<br>
<br>
&gt;Phillip Hallam-Baker wrote:<br>
&gt;&gt;<br>
&gt;&gt; But the standard is set by the consensus and the running code whic=
h<br>
&gt;&gt; recognize self-signed certs..<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; I see the following courses of action as being open:<br>
&gt;&gt;<br>
&gt;&gt; D1) DANE says nothing at all about this issue in the DANE spec (I =
see<br>
no<br>
&gt;&gt; reason it need be mentioned at all).<br>
&gt;&gt;<br>
&gt;&gt; D2) DANE says that the EE cert can be a self signed EE cert in<br>
&gt;&gt;accordance<br>
&gt;&gt; with customary Internet usage<br>
&gt;&gt;<br>
&gt;&gt; P1) PKIX writes draft on how to specify self signed EE certs so th=
at<br>
&gt;&gt;this is<br>
&gt;&gt; properly understood. I.E. relying applications MUST NOT rely on an=
y<br>
&gt;&gt;claims<br>
&gt;&gt; other than the POP of the key and any restrictions on validity/usa=
ge.<br>
&gt;&gt;<br>
&gt;&gt; P2) PKIX ignores the issue.<br>
&gt;&gt;<br>
&gt;&gt; Note that D1/2 and P1/2 are orthogonal.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; These certs exist and I can&#39;t see there being a consensus like=
ly to<br>
&gt;&gt;emerge<br>
&gt;&gt; to require a chain with a CA cert at the head.<br>
&gt;<br>
&gt;<br>
&gt;I have very little experience with / exposure to the discussions<br>
&gt;in the PKIX WG, so I don&#39;t know how much I like (P1).<br>
&gt;<br>
&gt;From the data collected by EFF, there appear to be<br>
&gt;<br>
&gt; =A0~ 830000 self-signed X.509v3 Web Server Certs installed on the<br>
internet<br>
&gt; =A0 =A0 =A0 =A0 =A0 with the BasicConstraint cA=3DTRUE<br>
&gt; =A0~ 494000 self-signed X.509v1 Web Server Certs installed on the<br>
internet<br>
&gt;<br>
&gt; =A0~ =A056000 self-signed X.509v3 Web Server certs installed on the<br=
>
internet<br>
&gt; =A0 =A0 =A0 =A0 =A0 without the BasicConstraint cA=3DTRUE<br>
&gt;<br>
&gt;There may be a much higher number of use case for self-signed certs<br>
&gt;on home networks (HomeNAS, DSL-Router, Set-Top Boxes), but they&#39;re<=
br>
&gt;probably irrelevant for DANE because most are on private IP-Addresses<b=
r>
and<br>
&gt;don&#39;t use officially registered DNS domains on their internal netwo=
rks.<br>
&gt;<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; Nor can I see a requirement<br>
&gt;&gt; to introduce a downref to X.509v1 to try to circumvent this.<br>
&gt;<br>
&gt;I do not see the particular gripe that you have with X.509v1.<br>
&gt;<br>
&gt;X.509v1 is a proper subset of X.509v3 -- nothing weird or awkard.<br>
&gt;<br>
&gt;<br>
&gt;The beauty of X.509v1 certs is that they&#39;re *MUCH* easier to create=
<br>
&gt;and hard to get wrong in an interop-impairing fashion.<br>
&gt;<br>
&gt;And, the biggest advantage: enforcing a rule &quot;do not accept as sig=
ners<br>
&gt;of other certs&quot; is trivial and fool-proof to implement, so that yo=
u<br>
&gt;don&#39;t create immediate and serious problems when you add such<br>
&gt;certs to the list of trusted keys for your PKI software along<br>
&gt;with Trust Anchors from commercial CAs.<br>
&gt;<br>
&gt;When you mix up self-signed CA certs from some web-servers into the<br>
&gt;list of trusted keys next to rootCAs from commercial CAs, then<br>
&gt;you may put yourself at risk today.<br>
&gt;<br>
&gt;But what are you real options today, with programmatic clients?<br>
&gt;Either disable the peer certificate check entirely, or add some<br>
&gt;peers self-signed certs to the same file as the self-signed certs<br>
&gt;of the commercial rootCAs.<br>
&gt;<br>
&gt;<br>
&gt;-Martin<br>
&gt;_______________________________________________<br>
&gt;pkix mailing list<br>
&gt;<a href=3D"mailto:[e-mail]">[e-mail]</a><br>
&gt;<a href=3D"https://www.ietf.org/mailman/listinfo/pkix" target=3D"_blank=
">https://www.ietf.org/mailman/listinfo/pkix</a><br>
<br>
<br>
_______________________________________________<br>
pkix mailing list<br>
<a href=3D"mailto:[e-mail]">[e-mail]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/pkix" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/pkix</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a=
 href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--bcaec51b199d0eec5204a1467c71--

From [e-mail]  Tue Apr 19 07:51:38 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F0225E06BE; Tue, 19 Apr 2011 07:51:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.188
X-Spam-Level: 
X-Spam-Status: No, score=-105.188 tagged_above=-999 required=5 tests=[AWL=0.811, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nB6KX5Oke8Sk; Tue, 19 Apr 2011 07:51:37 -0700 (PDT)
Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfc.amsl.com (Postfix) with ESMTP id 6DE3EE06B2; Tue, 19 Apr 2011 07:51:37 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id D8989171C1D; Tue, 19 Apr 2011 15:51:35 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1303224694; bh=BME90IWWN2HHe8 56T9VnArRvPOhzpaP7sBI83ZVloeU=; b=DLkQ0kuaG6FRRZHB5gG/FAZnY0nLoA ffkUS+ApL+OiXZKSMbiGck6Tr6mzL+xmN2ZD3RcImZlfeLRWRc5iNAFKfh8x9BkQ B2w5XNtXToZ0Hdn79YL/Ztp4qQh93Pq+SjnKR2WK+NngAV01VrMGUxG3l/HLAL0m h7wBmaf4OGSemGjqNu/fKPxk2nCk6AsYq0hsicX1BwPLWGFCfNPtKSYDG6a2Sx+b 76BdFKn6mGOdVKaRGW/Hfp5jufiBjtlPCvOgTyof2AxAAL9YhI8MqQwf+7OSsCqS AyIHqZNzQ+nNazA3K2rwRUougPJfEqYGwjAM/iwXw1ZK+hZY/qAx73iQ==
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id mUZ9V8Pz9-0G; Tue, 19 Apr 2011 15:51:34 +0100 (IST)
Received: from [134.226.36.137] (stephen-samy.dsg.cs.tcd.ie [134.226.36.137]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id D4C5D171C19; Tue, 19 Apr 2011 15:51:30 +0100 (IST)
Message-ID: <[e-mail]>
Date: Tue, 19 Apr 2011 15:51:30 +0100
From: Stephen Farrell <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8
MIME-Version: 1.0
To: Phillip Hallam-Baker <[e-mail]>
References: <[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Stefan Santesson <[e-mail]>, "Kemp, David P." <[e-mail]>, [e-mail], [e-mail]
Subject: Re: [dane] [pkix]  5280 and self-signed ee certs (was: Re:
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 19 Apr 2011 14:51:39 -0000

So can we take the discussion over to pkix then and have this be
the last message on this topic to dane until pkix has come to some
conclusion?

So *please* remove dane from followups.

S.

On 19/04/11 15:40, Phillip Hallam-Baker wrote:
> There is no problem with using X.509v1 certs.
> 
> But there is a very big problem with trying to make a normative
> reference in a new standards proposal to a standard that has been
> deprecated (ITU) or made HISTORIC (IETF).
> 
> 
> Given the vast number of v1 certs in circulation plus the very long
> lifetimes on many of them, I can't see a problem with requiring relying
> applications to process v1 certs. The use case here would be to support
> a device that shipped with a built in v1 device cert without having to
> rekey the device. 
> 
> But I can see a very big problem with attempting to get round the PKIX
> lawyering with a requirement that cannot be supported in a reasonable
> manner using the current standards. 
> 
> 
> I really don't see this as a DANE issue. I see it as a requirement to
> clarify the PKIX spec as follows:
> 
> * CA signing key usage MUST be set for keys used to sign certificates
> for any key OTHER THAN THEMSELVES.
> 
> * EE certs may be CA signed or self-signed.
> 
> * Security considerations for using self-signed certs (probably two
> pages worth at least). Specifically, no positive claims can be relied on
> other than POP for the key, all use restrictions and validity conditions
> MUST be observed.
> 
> 
> Since this is currently the largest class of server certificate deployed
> by number of certs it would be ostrich-like behavior to ignore them. I
> can't see programmers deciding that they want to have applications that
> generate self-signed certs create a chain of two certs for no other
> purpose than to comply with the spec.
> 
> 
> 
> 
> 
> On Tue, Apr 19, 2011 at 9:18 AM, Kemp, David P. <[e-mail]
> <mailto:[e-mail]>> wrote:
> 
>     There's nothing wrong with self-signed X.509 v1 certs except the "X.509"
>     part and the "certificate" part.
> 
>     Self-signed keys have nice properties other than proof of possession -
>     they allow an entity to "stake a claim" on a
>     cryptographically-guaranteed-unused identity and support
>     continuity-based (or reputation-based) trust in that identity, in
>     addition to standard out-of-band mechanisms.  If wishes were horses ...
>     everyone would use a PKIX-standard signed key assertion that was NOT a
>     syntactically-valid X.509 certificate.  I don't see how using X.509v1
>     instead of x.509v3 for self-signed end-entity keys prevents applications
>     from misusing them as CA certs.
> 
>     Dave
> 
> 
>     -----Original Message-----
>     From: [e-mail] <mailto:[e-mail]>
>     [mailto:[e-mail] <mailto:[e-mail]>] On
>     Behalf Of
>     Stefan Santesson
>     Sent: Tuesday, April 19, 2011 3:46 AM
>     To: [e-mail] <mailto:[e-mail]>; Phillip Hallam-Baker
>     Cc: [e-mail] <mailto:[e-mail]>; [e-mail]
>     <mailto:[e-mail]>
>     Subject: Re: [pkix] [dane] 5280 and self-signed ee certs (was: Re:
> 
>     Martin,
> 
>     For self signed certs in general I think X.509 v1 certs are just fine.
> 
>     /Stefan
> 
>     On 11-04-19 12:49 AM, "Martin Rex" <[e-mail]
>     <mailto:[e-mail]>> wrote:
> 
>     >Phillip Hallam-Baker wrote:
>     >>
>     >> But the standard is set by the consensus and the running code which
>     >> recognize self-signed certs..
>     >>
>     >>
>     >> I see the following courses of action as being open:
>     >>
>     >> D1) DANE says nothing at all about this issue in the DANE spec (I see
>     no
>     >> reason it need be mentioned at all).
>     >>
>     >> D2) DANE says that the EE cert can be a self signed EE cert in
>     >>accordance
>     >> with customary Internet usage
>     >>
>     >> P1) PKIX writes draft on how to specify self signed EE certs so that
>     >>this is
>     >> properly understood. I.E. relying applications MUST NOT rely on any
>     >>claims
>     >> other than the POP of the key and any restrictions on validity/usage.
>     >>
>     >> P2) PKIX ignores the issue.
>     >>
>     >> Note that D1/2 and P1/2 are orthogonal.
>     >>
>     >>
>     >> These certs exist and I can't see there being a consensus likely to
>     >>emerge
>     >> to require a chain with a CA cert at the head.
>     >
>     >
>     >I have very little experience with / exposure to the discussions
>     >in the PKIX WG, so I don't know how much I like (P1).
>     >
>     >From the data collected by EFF, there appear to be
>     >
>     >  ~ 830000 self-signed X.509v3 Web Server Certs installed on the
>     internet
>     >           with the BasicConstraint cA=TRUE
>     >  ~ 494000 self-signed X.509v1 Web Server Certs installed on the
>     internet
>     >
>     >  ~  56000 self-signed X.509v3 Web Server certs installed on the
>     internet
>     >           without the BasicConstraint cA=TRUE
>     >
>     >There may be a much higher number of use case for self-signed certs
>     >on home networks (HomeNAS, DSL-Router, Set-Top Boxes), but they're
>     >probably irrelevant for DANE because most are on private IP-Addresses
>     and
>     >don't use officially registered DNS domains on their internal networks.
>     >
>     >
>     >>
>     >> Nor can I see a requirement
>     >> to introduce a downref to X.509v1 to try to circumvent this.
>     >
>     >I do not see the particular gripe that you have with X.509v1.
>     >
>     >X.509v1 is a proper subset of X.509v3 -- nothing weird or awkard.
>     >
>     >
>     >The beauty of X.509v1 certs is that they're *MUCH* easier to create
>     >and hard to get wrong in an interop-impairing fashion.
>     >
>     >And, the biggest advantage: enforcing a rule "do not accept as signers
>     >of other certs" is trivial and fool-proof to implement, so that you
>     >don't create immediate and serious problems when you add such
>     >certs to the list of trusted keys for your PKI software along
>     >with Trust Anchors from commercial CAs.
>     >
>     >When you mix up self-signed CA certs from some web-servers into the
>     >list of trusted keys next to rootCAs from commercial CAs, then
>     >you may put yourself at risk today.
>     >
>     >But what are you real options today, with programmatic clients?
>     >Either disable the peer certificate check entirely, or add some
>     >peers self-signed certs to the same file as the self-signed certs
>     >of the commercial rootCAs.
>     >
>     >
>     >-Martin
>     >_______________________________________________
>     >pkix mailing list
>     >[e-mail] <mailto:[e-mail]>
>     >https://www.ietf.org/mailman/listinfo/pkix
> 
> 
>     _______________________________________________
>     pkix mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/pkix
> 
> 
> 
> 
> -- 
> Website: http://hallambaker.com/
> 
> 
> 
> _______________________________________________
> pkix mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pkix

From [e-mail]  Tue Apr 19 08:01:33 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A7B22E0766; Tue, 19 Apr 2011 08:01:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.529
X-Spam-Level: 
X-Spam-Status: No, score=-3.529 tagged_above=-999 required=5 tests=[AWL=0.070,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifx5dorjdT7V; Tue, 19 Apr 2011 08:01:33 -0700 (PDT)
Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfc.amsl.com (Postfix) with ESMTP id C237AE075A; Tue, 19 Apr 2011 08:01:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=[e-mail]; q=dns/txt; s=uoa; t=1303225289; x=1334761289; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20<[e-mail]> |To:=[e-mail],=[e-mail] |Subject:=20Re:=20[pkix]=20[dane]=205280=20and=20self-sig ned=20ee=20certs=20(was:=20Re:|Cc:=[e-mail],=20mre [e-mail],=[e-mail],=[e-mail] |In-Reply-To:=20<[e-mail]>|Message-Id: =20<[e-mail]>|Date: =20Wed,=2020=20Apr=202011=2003:01:19=20+1200; bh=amAiaOhfdrCXMt3NySgf3j7SBsf11H0FpFUdOpYVFcE=; b=uyS2URzGNkn68z0wBGHP45V27ktWJjz3zBD3cBOJLFUvW/42cMlCHJWX Q5XjonnsumhHHpdTeVdqCljcfbxUx4qjVTHnL6Byn9hm0nEx0oReo9VEU j/2Bz54WdOP01T2bdu1kxT9DHmPEZYe8WSyqnWL45aMDwELxcn0xMGcNT U=;
X-IronPort-AV: E=Sophos;i="4.64,240,1301832000"; d="scan'208";a="57435833"
X-Ironport-HAT: APP-SERVERS - $RELAYED
X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing
Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 20 Apr 2011 03:01:19 +1200
Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <[e-mail]>) id 1QCCQZ-0007HF-He; Wed, 20 Apr 2011 03:01:19 +1200
Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from <[e-mail]>) id 1QCCQZ-0007S8-DE; Wed, 20 Apr 2011 03:01:19 +1200
From: Peter Gutmann <[e-mail]>
To: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Date: Wed, 20 Apr 2011 03:01:19 +1200
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: [dane] [pkix]  5280 and self-signed ee certs (was: Re:
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 19 Apr 2011 15:01:33 -0000

Stephen Farrell <[e-mail]> writes:

>So can we take the discussion over to pkix then and have this be the last
>message on this topic to dane until pkix has come to some conclusion?

What if they never come to a conclusion (which is not unusual whenever a tough
topic comes up)?  We should probably set a timer to expire after which
(shudder) things start up here again.

(Sorry, still sent to DANE since it's relevant here.  "Kick it over to PKIX"
presupposes that it'll converge on a solution at some point).

Peter.

From [e-mail]  Tue Apr 19 08:28:08 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EDAEDE0675 for <[e-mail]>; Tue, 19 Apr 2011 08:28:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qT7w3h4XLobf for <[e-mail]>; Tue, 19 Apr 2011 08:28:08 -0700 (PDT)
Received: from mail.nic.cl (mail.nic.cl [200.1.123.8]) by ietfc.amsl.com (Postfix) with ESMTP id D6EE4E0691 for <[e-mail]>; Tue, 19 Apr 2011 08:28:06 -0700 (PDT)
Received: from mail.nic.cl (localhost.localdomain [127.0.0.1]) by mail.nic.cl (Postfix) with ESMTP id 26446CC82BD for <[e-mail]>; Tue, 19 Apr 2011 12:28:04 -0300 (CLST)
Received: from vulcano.intra.nic.cl (vulcano.intra.nic.cl [172.30.10.58]) by mail.nic.cl (Postfix) with ESMTP id 19F3FCC82BC for <[e-mail]>; Tue, 19 Apr 2011 12:28:04 -0300 (CLST)
Message-ID: <[e-mail]>
Date: Tue, 19 Apr 2011 12:28:04 -0300
From: Hugo Salgado <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Thunderbird/3.1.9
MIME-Version: 1.0
To: [e-mail]
X-Enigmail-Version: 1.1.2
OpenPGP: id=B525FA6E
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP on Tue Apr 19 12:28:04 2011 -0300 (CLST)
Subject: [dane] Mnemonics in draft-ietf-dane-protocol
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 19 Apr 2011 15:28:09 -0000

Hi.
I think it should be a lot clearer if we use mnemonics with
the certificate types, adding another column in the 5.2 table,
besides the "value" number. Maybe something like "ENDCERT" and
"CACERT"?

I count seven times "type 1" referring to the certificates, two
of them having an explicit explanatory text "client certificate..."

Regards,

Hugo

From [e-mail]  Tue Apr 19 13:15:28 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 27A38E086E for <[e-mail]>; Tue, 19 Apr 2011 13:15:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.318
X-Spam-Level: 
X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yVbWKLQnN3t9 for <[e-mail]>; Tue, 19 Apr 2011 13:15:27 -0700 (PDT)
Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfc.amsl.com (Postfix) with ESMTP id E864EE085D for <[e-mail]>; Tue, 19 Apr 2011 13:15:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=5/u+MPvLaNmOJknjB0o4iRqkRY/j5Fg7oASEw+gNcSE=; b=uD8tOFh/SsXSRfVKN66PHG8h2PTrV/6gf/R2J8UzxDkyFAcGCZ76Buth7hspG9PbQxa2FrusjD0EW tZJjWlFYf4IB8Ty/1k5z+/tGWtBAW8EHWdN5QJPUMka0FvIqwLLXKbngd79vVUEzJU/l3TVEXYVHYY DOvftFOJDwSf58dU=
Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Tue, 19 Apr 2011 22:15:24 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Jakob Schlyter <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Tue, 19 Apr 2011 22:15:20 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]>
To: Hugo Salgado <[e-mail]>
X-Mailer: Apple Mail (2.1084)
Cc: [e-mail]
Subject: Re: [dane] Mnemonics in draft-ietf-dane-protocol
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 19 Apr 2011 20:15:28 -0000

On 19 apr 2011, at 17.28, Hugo Salgado wrote:

> I think it should be a lot clearer if we use mnemonics with
> the certificate types, adding another column in the 5.2 table,
> besides the "value" number. Maybe something like "ENDCERT" and
> "CACERT"?

One potential problem with this is that parsers implementing support for =
TLSA need to be updated every time a new certificate type is defined, =
most likely resulting in end user confusion. We do believe new types =
will be added in the future.

	jakob


From [e-mail]  Tue Apr 19 13:24:43 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E94E7E0719 for <[e-mail]>; Tue, 19 Apr 2011 13:24:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[AWL=0.375,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juaAPSZlrbxQ for <[e-mail]>; Tue, 19 Apr 2011 13:24:43 -0700 (PDT)
Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfc.amsl.com (Postfix) with ESMTP id 34399E0678 for <[e-mail]>; Tue, 19 Apr 2011 13:24:43 -0700 (PDT)
Received: by pwi5 with SMTP id 5so62109pwi.31 for <[e-mail]>; Tue, 19 Apr 2011 13:24:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=safw6jrAJk8iKst6p9linIcDL3YlrbwGiNGc61wSV50=; b=RXLV/Hfzm+AC9yWJh586mh9EGbat1NdZXQhep0zIb9Brd5Q/wifgNRN0G/Z1mhUV44 4tB1WQc/eJ6RR1yXxKBzn7KpqKa1AiBefykPooSCrdwtOZfDtCz0crxwT2ouPrU00L8H YlLEM7gNy7dPtZJ5KqMP0aDXu7UwT10P/rcJU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=ptjllWHBJ7BLUfIvIZR6xsn7rJwYmTYnMRNi8Z158435c0MFnTbv8TcfoH8NIe3Oqi ABU0qFVedTo4x3UlHl++Xu9vu+xsDG8kZcewG+wXRq2aHi8t2GydMPUpsIrl5dXvIKGv 1FM5B5/W8KBjMlzX4C6DbEra57I7W6PQELPg8=
MIME-Version: 1.0
Received: by 10.68.26.227 with SMTP id o3mr429104pbg.418.1303244484406; Tue, 19 Apr 2011 13:21:24 -0700 (PDT)
Sender: [e-mail]
Received: by 10.68.51.5 with HTTP; Tue, 19 Apr 2011 13:21:24 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Tue, 19 Apr 2011 13:21:24 -0700
X-Google-Sender-Auth: JjWLApOonrjeQ9yhvYssJAlYxhY
Message-ID: <BANLkTi=[e-mail]>
From: Zack Weinberg <[e-mail]>
To: Jakob Schlyter <[e-mail]>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: [e-mail]
Subject: Re: [dane] Mnemonics in draft-ietf-dane-protocol
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 19 Apr 2011 20:24:44 -0000

Maybe there could be mnemonics in the standard but not in the record
presentation format?  I do like the idea of not having to say "type 1
cert" / "type 2 cert" all over the place in the spec.

zw

On Tue, Apr 19, 2011 at 1:15 PM, Jakob Schlyter <[e-mail]> wrote:
> On 19 apr 2011, at 17.28, Hugo Salgado wrote:
>
>> I think it should be a lot clearer if we use mnemonics with
>> the certificate types, adding another column in the 5.2 table,
>> besides the "value" number. Maybe something like "ENDCERT" and
>> "CACERT"?
>
> One potential problem with this is that parsers implementing support for =
TLSA need to be updated every time a new certificate type is defined, most =
likely resulting in end user confusion. We do believe new types will be add=
ed in the future.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0jakob
>
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane
>

From [e-mail]  Tue Apr 19 06:19:14 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0CFB3E06B2; Tue, 19 Apr 2011 06:19:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.999
X-Spam-Level: 
X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cWDJRj4S+F0; Tue, 19 Apr 2011 06:19:13 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfc.amsl.com (Postfix) with ESMTP id 1F600E0663; Tue, 19 Apr 2011 06:19:13 -0700 (PDT)
Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id p3JDJ6h7064812; Tue, 19 Apr 2011 09:19:06 -0400 (EDT)
Received: from DABECK.missi.ncsc.mil ([144.51.60.16]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 19 Apr 2011 09:18:44 -0400
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Tue, 19 Apr 2011 09:18:48 -0400
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [pkix] [dane]  5280 and self-signed ee certs (was: Re:
Thread-Index: Acv+ZhMPYN6Whhr3TIW029gCnCBYOgAK8/jg
References: <[e-mail]> <[e-mail]>
From: "Kemp, David P." <[e-mail]>
To: "Stefan Santesson" <[e-mail]>, <[e-mail]>, "Phillip Hallam-Baker" <[e-mail]>
X-OriginalArrivalTime: 19 Apr 2011 13:18:44.0859 (UTC) FILETIME=[4F42E4B0:01CBFE94]
X-Mailman-Approved-At: Tue, 19 Apr 2011 13:55:43 -0700
Cc: [e-mail], [e-mail]
Subject: Re: [dane] [pkix]   5280 and self-signed ee certs (was: Re:
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 19 Apr 2011 13:19:14 -0000

There's nothing wrong with self-signed X.509 v1 certs except the "X.509"
part and the "certificate" part.

Self-signed keys have nice properties other than proof of possession -
they allow an entity to "stake a claim" on a
cryptographically-guaranteed-unused identity and support
continuity-based (or reputation-based) trust in that identity, in
addition to standard out-of-band mechanisms.  If wishes were horses ...
everyone would use a PKIX-standard signed key assertion that was NOT a
syntactically-valid X.509 certificate.  I don't see how using X.509v1
instead of x.509v3 for self-signed end-entity keys prevents applications
from misusing them as CA certs.

Dave


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Stefan Santesson
Sent: Tuesday, April 19, 2011 3:46 AM
To: [e-mail]; Phillip Hallam-Baker
Cc: [e-mail]; [e-mail]
Subject: Re: [pkix] [dane] 5280 and self-signed ee certs (was: Re:

Martin,

For self signed certs in general I think X.509 v1 certs are just fine.

/Stefan

On 11-04-19 12:49 AM, "Martin Rex" <[e-mail]> wrote:

>Phillip Hallam-Baker wrote:
>>=20
>> But the standard is set by the consensus and the running code which
>> recognize self-signed certs..
>>=20
>>=20
>> I see the following courses of action as being open:
>>=20
>> D1) DANE says nothing at all about this issue in the DANE spec (I see
no
>> reason it need be mentioned at all).
>>=20
>> D2) DANE says that the EE cert can be a self signed EE cert in
>>accordance
>> with customary Internet usage
>>=20
>> P1) PKIX writes draft on how to specify self signed EE certs so that
>>this is
>> properly understood. I.E. relying applications MUST NOT rely on any
>>claims
>> other than the POP of the key and any restrictions on validity/usage.
>>=20
>> P2) PKIX ignores the issue.
>>=20
>> Note that D1/2 and P1/2 are orthogonal.
>>=20
>>=20
>> These certs exist and I can't see there being a consensus likely to
>>emerge
>> to require a chain with a CA cert at the head.
>
>
>I have very little experience with / exposure to the discussions
>in the PKIX WG, so I don't know how much I like (P1).
>
>From the data collected by EFF, there appear to be
>
>  ~ 830000 self-signed X.509v3 Web Server Certs installed on the
internet
>           with the BasicConstraint cA=3DTRUE
>  ~ 494000 self-signed X.509v1 Web Server Certs installed on the
internet
>
>  ~  56000 self-signed X.509v3 Web Server certs installed on the
internet
>           without the BasicConstraint cA=3DTRUE
>
>There may be a much higher number of use case for self-signed certs
>on home networks (HomeNAS, DSL-Router, Set-Top Boxes), but they're
>probably irrelevant for DANE because most are on private IP-Addresses
and
>don't use officially registered DNS domains on their internal networks.
>
>
>>
>> Nor can I see a requirement
>> to introduce a downref to X.509v1 to try to circumvent this.
>
>I do not see the particular gripe that you have with X.509v1.
>
>X.509v1 is a proper subset of X.509v3 -- nothing weird or awkard.
>
>
>The beauty of X.509v1 certs is that they're *MUCH* easier to create
>and hard to get wrong in an interop-impairing fashion.
>
>And, the biggest advantage: enforcing a rule "do not accept as signers
>of other certs" is trivial and fool-proof to implement, so that you
>don't create immediate and serious problems when you add such
>certs to the list of trusted keys for your PKI software along
>with Trust Anchors from commercial CAs.
>
>When you mix up self-signed CA certs from some web-servers into the
>list of trusted keys next to rootCAs from commercial CAs, then
>you may put yourself at risk today.
>
>But what are you real options today, with programmatic clients?
>Either disable the peer certificate check entirely, or add some
>peers self-signed certs to the same file as the self-signed certs
>of the commercial rootCAs.
>
>
>-Martin
>_______________________________________________
>pkix mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/pkix


_______________________________________________
pkix mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/pkix

From [e-mail]  Wed Apr 20 11:30:05 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B183AE0732; Wed, 20 Apr 2011 11:30:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.742
X-Spam-Level: 
X-Spam-Status: No, score=-102.742 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bzf2ROtu8TyX; Wed, 20 Apr 2011 11:30:05 -0700 (PDT)
Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0CECEE0749; Wed, 20 Apr 2011 11:30:05 -0700 (PDT)
MIME-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
From: [e-mail]
To: [e-mail]
X-Test-IDTracker: no
X-IETF-IDTracker: 3.52
Message-ID: <[e-mail]>
Date: Wed, 20 Apr 2011 11:30:05 -0700
Cc: [e-mail]
Subject: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 20 Apr 2011 18:30:05 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF.


	Title           : Use Cases and Requirements for DNS-based Authentication of Named Entities
	Author(s)       : R. Barnes
	Filename        : draft-ietf-dane-use-cases-00.txt
	Pages           : 8
	Date            : 2011-04-20

Many current applications use the certificate-based authentication
features in TLS to allow clients to verify that a connected server
properly represents a desired domain name.  Traditionally, this
authentication has been based on PKIX trust hierarchies, rooted in
well-known CAs, but additional information can be provided via the
DNS itself.  This document describes a set of use cases in which the
DNS and DNSSEC could be used to make assertions that support the TLS
authentication process.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dane-use-cases-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body; name="draft-ietf-dane-use-cases-00.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[e-mail]>


--NextPart--

From [e-mail]  Wed Apr 20 11:39:41 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6C596E06C4 for <[e-mail]>; Wed, 20 Apr 2011 11:39:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDi+cUGMG+5g for <[e-mail]>; Wed, 20 Apr 2011 11:39:40 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfc.amsl.com (Postfix) with ESMTP id B990DE067D for <[e-mail]>; Wed, 20 Apr 2011 11:39:40 -0700 (PDT)
Received: from [192.1.255.191] (port=55533 helo=col-dhcp-192-1-255-191.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from <[e-mail]>) id 1QCcJQ-000PNO-8S for [e-mail]; Wed, 20 Apr 2011 14:39:40 -0400
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1082)
From: "Richard L. Barnes" <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Wed, 20 Apr 2011 14:39:39 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]>
To: [e-mail]
X-Mailer: Apple Mail (2.1082)
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 20 Apr 2011 18:39:41 -0000

This document is an attempt to capture
(1) A brief problem statement,
(2) The three main use cases discussed on the list, and
(3) A few additional requirements =20

Thanks especially to Eric, Zack, and Phil, from whom most of the =
underlying material is drawn.

Comments are welcome.

--Richard=20


On Apr 20, 2011, at 2:30 PM, [e-mail] wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
> This draft is a work item of the DNS-based Authentication of Named =
Entities Working Group of the IETF.
>=20
>=20
> 	Title           : Use Cases and Requirements for DNS-based =
Authentication of Named Entities
> 	Author(s)       : R. Barnes
> 	Filename        : draft-ietf-dane-use-cases-00.txt
> 	Pages           : 8
> 	Date            : 2011-04-20
>=20
> Many current applications use the certificate-based authentication
> features in TLS to allow clients to verify that a connected server
> properly represents a desired domain name.  Traditionally, this
> authentication has been based on PKIX trust hierarchies, rooted in
> well-known CAs, but additional information can be provided via the
> DNS itself.  This document describes a set of use cases in which the
> DNS and DNSSEC could be used to make assertions that support the TLS
> authentication process.
>=20
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-dane-use-cases-00.txt
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> <Mail Attachment>_______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane


From [e-mail]  Wed Apr 20 11:58:01 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3DEEEE067D for <[e-mail]>; Wed, 20 Apr 2011 11:58:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DsOC7lHJ2n+m for <[e-mail]>; Wed, 20 Apr 2011 11:58:00 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by ietfc.amsl.com (Postfix) with ESMTP id 7DE6CE066B for <[e-mail]>; Wed, 20 Apr 2011 11:58:00 -0700 (PDT)
Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7571E40D51; Wed, 20 Apr 2011 13:01:39 -0600 (MDT)
Message-ID: <[e-mail]>
Date: Wed, 20 Apr 2011 12:57:58 -0600
From: Peter Saint-Andre <[e-mail]>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: "Richard L. Barnes" <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 1.1.1
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050009030106010700090900"
Cc: [e-mail]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 20 Apr 2011 18:58:01 -0000

This is a cryptographically signed message in MIME format.

--------------ms050009030106010700090900
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 4/20/11 12:39 PM, Richard L. Barnes wrote:
> This document is an attempt to capture
> (1) A brief problem statement,
> (2) The three main use cases discussed on the list, and
> (3) A few additional requirements =20
>=20
> Thanks especially to Eric, Zack, and Phil, from whom most of the underl=
ying material is drawn.
>=20
> Comments are welcome.

My only comment is that this is a well-written and helpful document.

Peter

--=20
Peter Saint-Andre
https://stpeter.im/




--------------ms050009030106010700090900
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC
BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL
ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j
tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/
jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q
7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo
98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd
SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR
6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l
fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV
0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk
ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV
hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu
bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD
0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri
2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI
LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa
Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL
MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV
BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl
ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6
wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil
NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1
nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J
KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2
gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I
eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl
dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu
BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF
BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB
BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl
ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz
bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns
LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1
My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z
dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG
tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo
6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg
PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3
GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6
2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN
BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x
KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw
MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4
TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl
bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY
BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0
ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o
Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+
39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c
6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx
ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2
0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud
DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0
H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud
EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB
tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku
cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu
cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp
YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD
b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz
c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0
dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw
AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu
Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp
zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD
MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI
xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh
K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ
AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD
b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa
BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDQy
MDE4NTc1OFowIwYJKoZIhvcNAQkEMRYEFLGE7ytOE2JOPRZtsl+ZKVKTZ9kZMF8GCSqGSIb3
DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT
MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj
dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC
CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV
BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0
Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG
9w0BAQEFAASCAQCD6lCIIL3BV1IcG1OWSQiXvVgD/axkfvJpXdVqSwRWkJNDdib66OyEmNEL
Po55Ek1/zbqHewLSqhhp2/WWU9RdCbT1jTEjSWMerW/h3y0LwJzNYkL4m6FQjnBRBy/XB+Uk
cYP6dTyYYx8EF0ONJVctfREFOQB9ivdx9VTKsjoMnfvx1eRC2ygskQ3qUjxJGNXxBosPNwZ1
IuVJ3IYH3jHyZXSHbMN+dn7nC+nzlHqTTeabRwSlPT87zfpMd4pn/EKFtGU+AbZ2FBTPO3BF
qADm2GzcEAqemGNeRWHeuzbO2yw7ArV7JYeS7DWzprcZHTjTMnTGqZEFzTVhD/QewAJUAAAA
AAAA
--------------ms050009030106010700090900--

From [e-mail]  Wed Apr 20 14:02:14 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id ED2A2E06C4 for <[e-mail]>; Wed, 20 Apr 2011 14:02:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.566
X-Spam-Level: 
X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033,  BAYES_00=-2.599]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ReGfZNOxAU1a for <[e-mail]>; Wed, 20 Apr 2011 14:02:14 -0700 (PDT)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfc.amsl.com (Postfix) with ESMTP id E8A34E0669 for <[e-mail]>; Wed, 20 Apr 2011 14:02:13 -0700 (PDT)
Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 9740EC5BB; Wed, 20 Apr 2011 17:02:10 -0400 (EDT)
Date: Wed, 20 Apr 2011 17:02:10 -0400 (EDT)
From: Paul Wouters <[e-mail]>
To: "Richard L. Barnes" <[e-mail]>
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Cc: [e-mail]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 20 Apr 2011 21:02:15 -0000

On Wed, 20 Apr 2011, [e-mail] wrote:

> 	Title           : Use Cases and Requirements for DNS-based Authentication of Named Entities

Section 3 talks about "the two main use cases". I would rephrase that as
"two example use cases", as I doubt those are really the two main use
cases. In fact, they appear mostly to be one use case of "confirm PKIX
CA via DNSSEC". I think that the case of "no CA" is in fact the main use
case, if "main" is calculated in number of certificates deployed. I do
agree the second "main" use case is that of confirming the CA via DNSSEC
to avoid mis-issue by other CAs.

I would really like to see one of the use cases replaced with the
non-CA use case - preferably the one stating it *could* be used without
DNSSEC. I'd rather see that all DANE deployments insist on a mandatory
DNSSEC validation.

I like  the use cases in Section 4, but I miss the "HASTLS" type use
cases, where the DANE record can avoid a dangerous port 80 connect by
asserting via DANE with DNSSEC that all communication to a certain entity
is prefered or mandated to happen with TLS.

Paul

From [e-mail]  Wed Apr 20 14:06:27 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 16E7AE06F4 for <[e-mail]>; Wed, 20 Apr 2011 14:06:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.568
X-Spam-Level: 
X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031,  BAYES_00=-2.599]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f22cV+WoXrFc for <[e-mail]>; Wed, 20 Apr 2011 14:06:26 -0700 (PDT)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfc.amsl.com (Postfix) with ESMTP id EB0DDE0758 for <[e-mail]>; Wed, 20 Apr 2011 14:06:25 -0700 (PDT)
Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 6DFCBC5BB; Wed, 20 Apr 2011 17:06:25 -0400 (EDT)
Date: Wed, 20 Apr 2011 17:06:25 -0400 (EDT)
From: Paul Wouters <[e-mail]>
To: "Richard L. Barnes" <[e-mail]>
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: [e-mail]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 20 Apr 2011 21:06:27 -0000

On Wed, 20 Apr 2011, Paul Wouters wrote:

And one more thing I forgot,

I don't see any use case where the TLS server can use DANE to
identify the TLS client via DANE, or somehow confirm the
client TLS certificate via DNS. Using such channel-binding could
give the TLS client additional access to resources on the TLS
server (in similar ways to the IPsec BTNS proposals)

Paul

From [e-mail]  Wed Apr 20 14:51:06 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 205E6E07A6 for <[e-mail]>; Wed, 20 Apr 2011 14:51: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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sri-NywdCyft for <[e-mail]>; Wed, 20 Apr 2011 14:51:04 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfc.amsl.com (Postfix) with ESMTP id 74678E0795 for <[e-mail]>; Wed, 20 Apr 2011 14:51:04 -0700 (PDT)
Received: by wwa36 with SMTP id 36so957769wwa.13 for <[e-mail]>; Wed, 20 Apr 2011 14:51:03 -0700 (PDT)
Received: by 10.216.121.208 with SMTP id r58mr1236511weh.61.1303336263149; Wed, 20 Apr 2011 14:51:03 -0700 (PDT)
Received: from bblfish.home (ALagny-751-1-1-45.w86-218.abo.wanadoo.fr [86.218.40.45]) by mx.google.com with ESMTPS id j49sm671625wer.14.2011.04.20.14.51.01 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Apr 2011 14:51:02 -0700 (PDT)
From: Henry Story <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Wed, 20 Apr 2011 23:51:00 +0200
Message-Id: <[e-mail]>
To: [e-mail]
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: [dane] Identity in the Browser at W3C
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 20 Apr 2011 21:51:06 -0000

Hi all,

   there is a meeting "Idenitity in the Browser" at the W3C, with =
position papers due in
on 27th of this month.

    http://www.w3.org/2011/identity-ws/

   I hope this group will have a paper to present there. The WebID group =
mentions DANE
in the paper we are still writing. You can find the latest draft of that =
here

    http://bblfish.net/tmp/2011/04/20/

   All the best,

	Henry Story


Social Web Architect
http://bblfish.net/


From [e-mail]  Wed Apr 20 15:32:16 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7DD25E07BE for <[e-mail]>; Wed, 20 Apr 2011 15:32:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.677
X-Spam-Level: 
X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lm5nw0EmxUPM for <[e-mail]>; Wed, 20 Apr 2011 15:32:15 -0700 (PDT)
Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfc.amsl.com (Postfix) with ESMTP id 3477AE07BC for <[e-mail]>; Wed, 20 Apr 2011 15:32:15 -0700 (PDT)
Received: by pwi5 with SMTP id 5so787867pwi.31 for <[e-mail]>; Wed, 20 Apr 2011 15:32:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=w4hefiVOEPgM7sY7c9Qiy2LC+n4eAdQ86lbC/aBUoEc=; b=V4MEls1xWXxNoKpGMV25FYL8/odCtjUQGk7ERF4CG91739k97X3nFMIUnPr+ET8RND BMYAneZTaZE9ihS9Qf2MQ7F3QSfqhJ7S9NAWtPkJpO7RnPKkcaJEQ7YmbMbxqElFj4O7 DdhAG84NJeK7fZBgF3AgeA/R813b01uf9tNd8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=LuPGuUE/6c+aTLbZLDf3PJga6cRajmCsS9cCRK8AE8XmOYS7ij+mz3+L8otf4ScSuT v+gof09NJWF7nLVINQUtiGc7Fwkod3w7/lO1yVV4O4vOrBymkM0vCXMaxNuGbvp35Uvn 1ZrLDl5+hfwWC7yS4e0ge9Ku+6PNYBG/QLkik=
MIME-Version: 1.0
Received: by 10.68.26.227 with SMTP id o3mr1084647pbg.418.1303338734588; Wed, 20 Apr 2011 15:32:14 -0700 (PDT)
Sender: [e-mail]
Received: by 10.68.51.5 with HTTP; Wed, 20 Apr 2011 15:32:14 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Wed, 20 Apr 2011 15:32:14 -0700
X-Google-Sender-Auth: aUbcr4cZMLUdf7bUX9FUnyIyRDI
Message-ID: <BANLkTin4SROd1y+rOx9hAxP2ZRcH=[e-mail]>
From: Zack Weinberg <[e-mail]>
To: "Richard L. Barnes" <[e-mail]>
Content-Type: text/plain; charset=UTF-8
Cc: [e-mail]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 20 Apr 2011 22:32:16 -0000

On Wed, Apr 20, 2011 at 11:39 AM, Richard L. Barnes <[e-mail]> wrote:
> This document is an attempt to capture
> (1) A brief problem statement,
> (2) The three main use cases discussed on the list, and
> (3) A few additional requirements

Thanks for writing this up (and for incorporating my ideas :)
I generally like it, but I have a few small suggestions...

> 3.  Use Cases
>
>    In this section, we describe the two major use cases that the DANE
>    mechanism should support.  This list is not intended to represent all
>    possible ways that the DNS can be used to support TLS authentication.
>    Rather it represents the specific cases that comprise the initial
>    goal for DANE.

Sections 3.1, 3.2, and 3.3 currently each read as if they present an
independent use case, but you say there are only two use cases.
The connection between 3.1 and 3.2 should be made more obvious,
by factoring out the common text and describing them as two related
scenarios that fall under the same use case.

Or you could just change "two" to "three", but I think I prefer it if
CA-constraints and cert-constraints are lumped under the same
use case -- that leaves room for other mechanisms for limiting
the set of valid certificates.

>    Because these constraints do not increase the scope of PKIX-based
>    assertions about domains, there is not a strict requirement for
>    DNSSEC.  Deletion of records removes the protection provided by this
>    constraint, but the client is still protected by CA practices (as
>    now).  Injected or modified false records are not useful unless the
>    attacker can also obtain an unauthorized certificate.  In the worst
>    case, tampering with these constraints degrades security to the level
>    that is now standard.

Injected or modified false records can be used for denial of service
even if the attacker does not have an unauthorized certificate.  This
doesn't let an attacker who can tamper with DNS responses do anything
they couldn't already do by messing up the A record for the server.
DNSSEC wouldn't help, because the attacker could still cause a denial
of service by blocking *all* DNS responses for the target domain.  But
it should still be mentioned.

You should maybe also be clearer about what you mean by "unauthorized
certificate".  The attacker can of course generate keypairs, and over
in research land we usually assume an attacker can get a legitimate
cert (EV, even) *for a domain that they legitimately control*.  I
think by "unauthorized" you mean "certificate for the *target* domain,
illicitly signed by some CA."

>    Providing trust anchor material in this way clearly requires DNSSEC,
>    since corrupted or injected records could be used by an attacker to
>    cause clients to trust an attacker's certificate.  Deleted records
>    will only result in connection failure and denial of service,
>    although this could result on a bid-down to an unsecured protocol,
>    depending on the application.

... "bid-down to unsecured" is what we call a "downgrade attack" over
in research land.  Therefore, for this use case to be safe, clients
*must not* fall back to unsecured if records appear to have been deleted.

>    By the same token, this use case puts the most power in the hands of
>    DNS operators.  Since the operator of the appropriate DNS zone has de
>    facto control over the content and signing of the zone, he can create
>    false DANE records that bind a malicious party's certificate to a
>    domain.

Nice point.

>    This is not a significant incremental risk relative to the
>    current PKIX-based system, however, since it is possible for domain
>    operators to obtain certificates for domains under some well-known
>    certificate authorities today.

I can't parse this sentence.

>    Simple Key Management:  DANE must have a mode in which the domain
>       owner only needs to maintain a single long-lived public/private
>       key pair.

This one's new to me.  Why is it a must rather than a should?

>    Hard Failure:  Clients must be required to refuse to proceed with a
>       connection to a site if DANE indicates a security error.

People found this problematic.  Suggested replacement:

    No Downgrade: An attacker who can tamper with DNS responses should
    not be able to make a DANE-compliant client treat a site that has
    deployed DANE and DNSSEC like a site that has deployed neither.

I think that avoids all the objections while still getting at what I
wanted to get at in the first place.

>    Predictability:  Client behavior in response to DANE records must be
>       spelled out in the DANE specification as precisely as possible.

"DANE information" might be more appropriate than "DANE records",
since the actual record is probably not going to be called IN DANE.

Add "particularly for cases where DANE information is in conflict with
PKIX information", please.

zw

From [e-mail]  Wed Apr 20 16:05:44 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E1D13E07D3 for <[e-mail]>; Wed, 20 Apr 2011 16:05:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.749
X-Spam-Level: 
X-Spam-Status: No, score=-2.749 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mHUP0Zv9KTZ for <[e-mail]>; Wed, 20 Apr 2011 16:05:43 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfc.amsl.com (Postfix) with ESMTP id B45BAE07C1 for <[e-mail]>; Wed, 20 Apr 2011 16:05:43 -0700 (PDT)
Received: by vxg33 with SMTP id 33so1113184vxg.31 for <[e-mail]>; Wed, 20 Apr 2011 16:05:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=g4iKrR4laWxaSIX1+n8sfoYbN0xcV3iLlwJ0RoNqSac=; b=r1E0qA/6g+EMR/Nxg22zQ46pDwGv+TLRZoozd+xZaX72yRXXkb4uNjePqgzIZh9l+L pjsZohC6VksxgCAPv+EDFY0DcHLvag97qvxm5nQ5o1YCf8rpmMRFpLY8raNBb3+0/nmW KKlOn52CGWbgPs9VoaKsld4e0QOSZmwAoFAPw=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=f3/xBoX6RCk9FiTV4oA8emzKnmWmKLLPSi2bQbeZrcOMCBfeXarL2fLVwGZj5VuMAZ 2a+zcmwUnzkL/4XXFPjK+7XX80vjaD+UmcsptVtyHuiBP7OrElQQo/UNbzdrhvXBXDss nk++i7IRB8bcDfHNg4esYZWTPPLmZEc7hV5I0=
MIME-Version: 1.0
Received: by 10.52.71.240 with SMTP id y16mr621710vdu.125.1303340743399; Wed, 20 Apr 2011 16:05:43 -0700 (PDT)
Received: by 10.52.161.3 with HTTP; Wed, 20 Apr 2011 16:05:43 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Wed, 20 Apr 2011 19:05:43 -0400
Message-ID: <[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: "Richard L. Barnes" <[e-mail]>
Content-Type: multipart/alternative; boundary=20cf307d045c081bba04a161aa99
Cc: [e-mail]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 20 Apr 2011 23:05:45 -0000

--20cf307d045c081bba04a161aa99
Content-Type: text/plain; charset=ISO-8859-1

These are not use cases.

:"Alice would like to be able to use generate and use certificates for her
website on alice.example.com

No, Alice has never wanted to do that. Certificates are merely a means to an
end.

A use case is the end objective of the stakeholder, e.g Alice wants to let
Bob come to her Web site without Mallet intercepting the conversation.


Restating the answer in the form of a question does not make it a use case.
The whole point of this exercise is to raise the level of abstraction above
the technical implementation.

There was a very clear consensus in the room at Prague that the group had
failed to adequately define the use cases and requirements. In particular
there was no way to evaluate many of the design choices.

Restating the architecture in the form of use cases does not address that
problem. We need to have use cases that describe the actual end purpose of
the stakeholders and parties.


On Wed, Apr 20, 2011 at 2:39 PM, Richard L. Barnes <[e-mail]> wrote:

> This document is an attempt to capture
> (1) A brief problem statement,
> (2) The three main use cases discussed on the list, and
> (3) A few additional requirements
>
> Thanks especially to Eric, Zack, and Phil, from whom most of the underlying
> material is drawn.
>
> Comments are welcome.
>
> --Richard
>
>
> On Apr 20, 2011, at 2:30 PM, [e-mail] wrote:
>
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > This draft is a work item of the DNS-based Authentication of Named
> Entities Working Group of the IETF.
> >
> >
> >       Title           : Use Cases and Requirements for DNS-based
> Authentication of Named Entities
> >       Author(s)       : R. Barnes
> >       Filename        : draft-ietf-dane-use-cases-00.txt
> >       Pages           : 8
> >       Date            : 2011-04-20
> >
> > Many current applications use the certificate-based authentication
> > features in TLS to allow clients to verify that a connected server
> > properly represents a desired domain name.  Traditionally, this
> > authentication has been based on PKIX trust hierarchies, rooted in
> > well-known CAs, but additional information can be provided via the
> > DNS itself.  This document describes a set of use cases in which the
> > DNS and DNSSEC could be used to make assertions that support the TLS
> > authentication process.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-dane-use-cases-00.txt
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> > <Mail Attachment>_______________________________________________
> > dane mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dane
>
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane
>



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

--20cf307d045c081bba04a161aa99
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

These are not use cases.<div><br></div><div>:&quot;<meta charset=3D"utf-8">=
<span class=3D"Apple-style-span" style=3D"font-family: Times; font-size: me=
dium; "><span class=3D"Apple-style-span" style=3D"font-family: monospace; w=
hite-space: pre-wrap; ">Alice would like to be able to use generate and use=
 certificates for her website on <a href=3D"http://alice.example.com">alice=
.example.com</a> <br>
</span></span><br><div class=3D"gmail_quote">No, Alice has never wanted to =
do that. Certificates are merely a means to an end.</div><div class=3D"gmai=
l_quote"><br></div><div class=3D"gmail_quote">A use case is the end objecti=
ve of the stakeholder, e.g Alice wants to let Bob come to her Web site with=
out Mallet intercepting the conversation.</div>
<div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote"><br></div><=
div class=3D"gmail_quote">Restating the answer in the form of a question do=
es not make it a use case. The whole point of this exercise is to raise the=
 level of abstraction above the technical implementation.</div>
<div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">There was a=
 very clear consensus in the room at Prague that the group had failed to ad=
equately define the use cases and requirements. In particular there was no =
way to evaluate many of the design choices.</div>
<div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Restating t=
he architecture in the form of use cases does not address that problem. We =
need to have use cases that describe the actual end purpose of the stakehol=
ders and parties.</div>
<div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote"><br></div><=
div class=3D"gmail_quote">On Wed, Apr 20, 2011 at 2:39 PM, Richard L. Barne=
s <span dir=3D"ltr">&lt;<a href=3D"mailto:[e-mail]">[e-mail]<=
/a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;">This document is an attempt to capture<br>
(1) A brief problem statement,<br>
(2) The three main use cases discussed on the list, and<br>
(3) A few additional requirements<br>
<br>
Thanks especially to Eric, Zack, and Phil, from whom most of the underlying=
 material is drawn.<br>
<br>
Comments are welcome.<br>
<br>
--Richard<br>
<div><div></div><div class=3D"h5"><br>
<br>
On Apr 20, 2011, at 2:30 PM, <a href=3D"mailto:[e-mail]">In=
[e-mail]</a> wrote:<br>
<br>
&gt; A New Internet-Draft is available from the on-line Internet-Drafts dir=
ectories.<br>
&gt; This draft is a work item of the DNS-based Authentication of Named Ent=
ities Working Group of the IETF.<br>
&gt;<br>
&gt;<br>
&gt; =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Use Cases and Requirements for=
 DNS-based Authentication of Named Entities<br>
&gt; =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : R. Barnes<br>
&gt; =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-dane-use-cases-00.txt=
<br>
&gt; =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 8<br>
&gt; =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-04-20<br>
&gt;<br>
&gt; Many current applications use the certificate-based authentication<br>
&gt; features in TLS to allow clients to verify that a connected server<br>
&gt; properly represents a desired domain name. =A0Traditionally, this<br>
&gt; authentication has been based on PKIX trust hierarchies, rooted in<br>
&gt; well-known CAs, but additional information can be provided via the<br>
&gt; DNS itself. =A0This document describes a set of use cases in which the=
<br>
&gt; DNS and DNSSEC could be used to make assertions that support the TLS<b=
r>
&gt; authentication process.<br>
&gt;<br>
&gt; A URL for this Internet-Draft is:<br>
&gt; <a href=3D"http://www.ietf.org/internet-drafts/draft-ietf-dane-use-cas=
es-00.txt" target=3D"_blank">http://www.ietf.org/internet-drafts/draft-ietf=
-dane-use-cases-00.txt</a><br>
&gt;<br>
&gt; Internet-Drafts are also available by anonymous FTP at:<br>
&gt; <a href=3D"ftp://ftp.ietf.org/internet-drafts/" target=3D"_blank">ftp:=
//ftp.ietf.org/internet-drafts/</a><br>
&gt;<br>
&gt; Below is the data which will enable a MIME compliant mail reader<br>
&gt; implementation to automatically retrieve the ASCII version of the<br>
&gt; Internet-Draft.<br>
</div></div>&gt; &lt;Mail Attachment&gt;___________________________________=
____________<br>
&gt; dane mailing list<br>
&gt; <a href=3D"mailto:[e-mail]">[e-mail]</a><br>
&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_blan=
k">https://www.ietf.org/mailman/listinfo/dane</a><br>
<br>
_______________________________________________<br>
dane mailing list<br>
<a href=3D"mailto:[e-mail]">[e-mail]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/dane</a><br>
</blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a href=3D"htt=
p://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--20cf307d045c081bba04a161aa99--

From [e-mail]  Wed Apr 20 16:45:41 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0E6ECE07E1 for <[e-mail]>; Wed, 20 Apr 2011 16:45:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.58
X-Spam-Level: 
X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmwY9vJhm0Zy for <[e-mail]>; Wed, 20 Apr 2011 16:45:40 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfc.amsl.com (Postfix) with ESMTP id 1EDB8E0673 for <[e-mail]>; Wed, 20 Apr 2011 16:45:40 -0700 (PDT)
Received: from [128.89.253.71] (port=55870 helo=[192.168.1.10]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from <[e-mail]>) id 1QCh5X-000FMx-H5; Wed, 20 Apr 2011 19:45:39 -0400
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: "Richard L. Barnes" <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Wed, 20 Apr 2011 19:45:37 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
To: Paul Wouters <[e-mail]>
X-Mailer: Apple Mail (2.1082)
Cc: [e-mail]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 20 Apr 2011 23:45:41 -0000

Hey Paul,

Thanks for the quick review.  Responses inline.


> Section 3 talks about "the two main use cases".=20

This is a legacy of an earlier draft, which had two instead of three use =
cases (the "Cert Lock" and "CA Lock" cases were combined).  I'm just =
going to delete the "two", so it applies to however many we end up with =
:)


> I would really like to see one of the use cases replaced with the
> non-CA use case - preferably the one stating it *could* be used =
without
> DNSSEC. I'd rather see that all DANE deployments insist on a mandatory
> DNSSEC validation.

I'm not sure there's consensus around that idea.  Ekr suggested the idea =
initially, and I agree that while there is security benefit to using =
DNSSEC for those cases, there is not additional risk in omitting it.


> I like  the use cases in Section 4, but I miss the "HASTLS" type use
> cases, where the DANE record can avoid a dangerous port 80 connect by
> asserting via DANE with DNSSEC that all communication to a certain =
entity
> is prefered or mandated to happen with TLS.

That was discussed earlier, and there seemed to be agreement that HASTLS =
problem was outside of the scope of DANE, better suited to =
application-layer groups like WEBSEC. =20




From [e-mail]  Wed Apr 20 16:49:34 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8FD56E07E3 for <[e-mail]>; Wed, 20 Apr 2011 16:49:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.581
X-Spam-Level: 
X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpFTrmrNp5td for <[e-mail]>; Wed, 20 Apr 2011 16:49:34 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfc.amsl.com (Postfix) with ESMTP id 12B56E06E2 for <[e-mail]>; Wed, 20 Apr 2011 16:49:34 -0700 (PDT)
Received: from [128.89.253.71] (port=55871 helo=[192.168.1.10]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from <[e-mail]>) id 1QCh9J-000FO1-Mi; Wed, 20 Apr 2011 19:49:33 -0400
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: "Richard L. Barnes" <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Wed, 20 Apr 2011 19:49:32 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
To: Paul Wouters <[e-mail]>
X-Mailer: Apple Mail (2.1082)
Cc: [e-mail]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 20 Apr 2011 23:49:34 -0000

> I don't see any use case where the TLS server can use DANE to
> identify the TLS client via DANE, or somehow confirm the
> client TLS certificate via DNS. Using such channel-binding could
> give the TLS client additional access to resources on the TLS
> server (in similar ways to the IPsec BTNS proposals)

I don't recall having seen discussion of that case on the list, but I =
would be open to adding it if there were a coherent story and others =
agreed. =20

The main question would seem to be what domain name the server would use =
to identify the client, and thus to look up the DANE records.  And the =
answer to that question would seem to vary by application-layer protocol =
(a lot -- think server-to-server XMPP vs. email vs. HTTPS).

How about a note of the following form in the introduction:
"
The use cases in this document are framed in terms of adding protections =
to TLS server certificates, since the use of these certificates to =
authenticate server domain names is very common.  In applications where =
TLS clients are also identified by domain names (e.g., XMPP =
server-to-server channels), the same considerations and use cases apply =
to TLS client certificates.=20
"

--Richard=

From [e-mail]  Wed Apr 20 17:03:58 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B16F7E06F2 for <[e-mail]>; Wed, 20 Apr 2011 17:03:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.583
X-Spam-Level: 
X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dL-RbV3Ry97L for <[e-mail]>; Wed, 20 Apr 2011 17:03:57 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfc.amsl.com (Postfix) with ESMTP id 9A4A4E0673 for <[e-mail]>; Wed, 20 Apr 2011 17:03:57 -0700 (PDT)
Received: from [128.89.253.71] (port=55883 helo=[192.168.1.10]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from <[e-mail]>) id 1QChNE-000FUB-Tf; Wed, 20 Apr 2011 20:03:57 -0400
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: "Richard L. Barnes" <[e-mail]>
In-Reply-To: <BANLkTin4SROd1y+rOx9hAxP2ZRcH=[e-mail]>
Date: Wed, 20 Apr 2011 20:03:55 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <BANLkTin4SROd1y+rOx9hAxP2ZRcH=[e-mail]>
To: Zack Weinberg <[e-mail]>
X-Mailer: Apple Mail (2.1082)
Cc: [e-mail]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 21 Apr 2011 00:03:58 -0000

Hey Zack,

Thanks for the quick review.  Comments inline.

> Or you could just change "two" to "three", but I think I prefer it if
> CA-constraints and cert-constraints are lumped under the same
> use case -- that leaves room for other mechanisms for limiting
> the set of valid certificates.

The "two" is a vestige of an earlier version, in fact one in which the =
CA-constraints and cert-constraints *were* lumped together.  Some folks =
I sought early review from thought it would be clearer to have them =
separate. =20

As far as I'm concerned, it's a matter of taste / style.  I'll go with =
whichever gets the most votes.



> Injected or modified false records can be used for denial of service
> even if the attacker does not have an unauthorized certificate.  This
> doesn't let an attacker who can tamper with DNS responses do anything
> they couldn't already do by messing up the A record for the server.
> DNSSEC wouldn't help, because the attacker could still cause a denial
> of service by blocking *all* DNS responses for the target domain.  But
> it should still be mentioned.

Good point.  I will add something to this effect.


> You should maybe also be clearer about what you mean by "unauthorized
> certificate".  The attacker can of course generate keypairs, and over
> in research land we usually assume an attacker can get a legitimate
> cert (EV, even) *for a domain that they legitimately control*.  I
> think by "unauthorized" you mean "certificate for the *target* domain,
> illicitly signed by some CA.

That's correct.  I think instead of "unauthorized certificate", we can =
just use "a certificate for the target domain".


> ... "bid-down to unsecured" is what we call a "downgrade attack" over
> in research land.  Therefore, for this use case to be safe, clients
> *must not* fall back to unsecured if records appear to have been =
deleted.

Thanks, will change terminology and add text.


>=20
>>   By the same token, this use case puts the most power in the hands =
of
>>   DNS operators.  Since the operator of the appropriate DNS zone has =
de
>>   facto control over the content and signing of the zone, he can =
create
>>   false DANE records that bind a malicious party's certificate to a
>>   domain.
>=20
> Nice point.

Thanks!


>>   This is not a significant incremental risk relative to the
>>   current PKIX-based system, however, since it is possible for domain
>>   operators to obtain certificates for domains under some well-known
>>   certificate authorities today.
>=20
> I can't parse this sentence.

The current threat (as I understand it from others' posts on the list) =
is of the following form:=20
-- CAs need to validate that a CSR comes from a domain owner
-- CAs do this validation based on information about the domain, e.g., =
email addresses in WHOIS or the presence of certain records in the zone
-- DNS operators can control the DNS information that CAs base these =
validation decisions on
-- Therefore DNS operators can obtain certs for domains under their =
control

So the idea is that even though the "Autonomous Certificates" case =
enables an outsourced DNS operator to masquerade as a domain, he already =
has that ability.

Would it help to clarify here that we're talking about a domain =
*operator* versus a domain *owner* -- e.g., GoDaddy vs. me for =
geopriv.info?
=20


>>   Simple Key Management:  DANE must have a mode in which the domain
>>      owner only needs to maintain a single long-lived public/private
>>      key pair.
>=20
> This one's new to me.  Why is it a must rather than a should?

Paul Hoffman suggested this to me offline.  I'm willing to go with a =
should unless he objects.  (Note also that from a procedural POV, these =
are lower-case, so they don't have force of RFC 2119.)


>>   Hard Failure:  Clients must be required to refuse to proceed with a
>>      connection to a site if DANE indicates a security error.
>=20
> People found this problematic.  Suggested replacement:
>=20
>    No Downgrade: An attacker who can tamper with DNS responses should
>    not be able to make a DANE-compliant client treat a site that has
>    deployed DANE and DNSSEC like a site that has deployed neither.

Will change.


>=20
>>   Predictability:  Client behavior in response to DANE records must =
be
>>      spelled out in the DANE specification as precisely as possible.
>=20
> "DANE information" might be more appropriate than "DANE records",
> since the actual record is probably not going to be called IN DANE.

Will do.


> Add "particularly for cases where DANE information is in conflict with
> PKIX information", please.

Will do.=

From [e-mail]  Wed Apr 20 17:21:06 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 545C2E077E for <[e-mail]>; Wed, 20 Apr 2011 17:21:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.584
X-Spam-Level: 
X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xchS+1Pwfp1O for <[e-mail]>; Wed, 20 Apr 2011 17:21:05 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfc.amsl.com (Postfix) with ESMTP id E1409E0721 for <[e-mail]>; Wed, 20 Apr 2011 17:21:05 -0700 (PDT)
Received: from [128.89.253.71] (port=55919 helo=[192.168.1.10]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from <[e-mail]>) id 1QChdo-000FYT-TW; Wed, 20 Apr 2011 20:21:05 -0400
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: "Richard L. Barnes" <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Wed, 20 Apr 2011 20:21:03 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <BANLkTin4SROd1y+rOx9hAxP2ZRcH=[e-mail]> <[e-mail]>
To: "Richard L. Barnes" <[e-mail]>
X-Mailer: Apple Mail (2.1082)
Cc: [e-mail]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 21 Apr 2011 00:21:06 -0000

>>>  Hard Failure:  Clients must be required to refuse to proceed with a
>>>     connection to a site if DANE indicates a security error.
>>=20
>> People found this problematic.  Suggested replacement:
>>=20
>>   No Downgrade: An attacker who can tamper with DNS responses should
>>   not be able to make a DANE-compliant client treat a site that has
>>   deployed DANE and DNSSEC like a site that has deployed neither.
>=20
> Will change.

Also, I have taken the liberty of changing this from a "should" to a =
"must", since it's a rather important security requirement.

--Richard=

From [e-mail]  Wed Apr 20 18:01:37 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 267A5E0755 for <[e-mail]>; Wed, 20 Apr 2011 18:01:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.727
X-Spam-Level: 
X-Spam-Status: No, score=-2.727 tagged_above=-999 required=5 tests=[AWL=0.250,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLDFq6cJvE6k for <[e-mail]>; Wed, 20 Apr 2011 18:01:36 -0700 (PDT)
Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by ietfc.amsl.com (Postfix) with ESMTP id 1A3B9E0693 for <[e-mail]>; Wed, 20 Apr 2011 18:01:36 -0700 (PDT)
Received: by pxi20 with SMTP id 20so954820pxi.27 for <[e-mail]>; Wed, 20 Apr 2011 18:01:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=7vnZ9aG/1pTcG3kB+XUHGwSTZY4I82hGsBYoyTkEeg4=; b=wUP4aGfqw0TteZUNtp1chhdDh+7ZPmlP4qXYQIsbFxA5AeMm6KFWLi0ug2dxvDvePI 8HyEuUtBNjpTgAkQhciasCluNYE4sH+xf3GsqEMh+PqxgZOgbBeX1ev2Zegb+gwS6fvz cpDr+tByaAkHbwuqbXX4zx7cYIT9zbusJiLpo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=SMAAV3Rp6iorkYL35cC8ylw1noLnKppT9WP2xp1kmJd83oDPsortNIvAilTctVgJt3 GsKiijgT7u9jV7WWb66rzddfkD0iRNMAUo8A8KcGjA3E78e1WWJL65C1SjyV1zOF0oiU UA5eenZ8TcSZrOTp6FWDRi8zOXV+WKWZW9r3A=
MIME-Version: 1.0
Received: by 10.68.71.233 with SMTP id y9mr11701490pbu.150.1303347695145; Wed, 20 Apr 2011 18:01:35 -0700 (PDT)
Sender: [e-mail]
Received: by 10.68.51.5 with HTTP; Wed, 20 Apr 2011 18:01:34 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <BANLkTin4SROd1y+rOx9hAxP2ZRcH=[e-mail]> <[e-mail]>
Date: Wed, 20 Apr 2011 18:01:34 -0700
X-Google-Sender-Auth: 3thv71PbMWUZTIjFXQLp05ZdOJI
Message-ID: <[e-mail]>
From: Zack Weinberg <[e-mail]>
To: "Richard L. Barnes" <[e-mail]>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: [e-mail]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 21 Apr 2011 01:01:37 -0000

On Wed, Apr 20, 2011 at 5:03 PM, Richard L. Barnes <[e-mail]> wrote:
> The "two" is a vestige of an earlier version, in fact one in which the CA=
-constraints and cert-constraints *were* lumped together. =C2=A0Some folks =
I sought early review from thought it would be clearer to have them separat=
e.
>
> As far as I'm concerned, it's a matter of taste / style. =C2=A0I'll go wi=
th whichever gets the most votes.

Ok.  I don't care that much either way.

>> Injected or modified false records can be used for denial of service
>> even if the attacker does not have an unauthorized certificate.
>
> Good point. =C2=A0I will add something to this effect.

Thanks.

>> I think by "unauthorized" you mean "certificate for the *target* domain,
>> illicitly signed by some CA.
>
> That's correct. =C2=A0I think instead of "unauthorized certificate", we c=
an just use "a certificate for the target domain".

Sounds good.  It should be clear from context that the attacker isn't
supposed to have one of those.

>>> =C2=A0 This is not a significant incremental risk relative to the
>>> =C2=A0 current PKIX-based system, however, since it is possible for dom=
ain
>>> =C2=A0 operators to obtain certificates for domains under some well-kno=
wn
>>> =C2=A0 certificate authorities today.
>>
>> I can't parse this sentence.
>
> The current threat (as I understand it from others' posts on the list) is=
 of the following form:
> -- CAs need to validate that a CSR comes from a domain owner
> -- CAs do this validation based on information about the domain, e.g., em=
ail addresses in WHOIS or the presence of certain records in the zone
> -- DNS operators can control the DNS information that CAs base these vali=
dation decisions on
> -- Therefore DNS operators can obtain certs for domains under their contr=
ol
>
> So the idea is that even though the "Autonomous Certificates" case enable=
s an outsourced DNS operator to masquerade as a domain, he already has that=
 ability.

Yes, that helps a lot.

> Would it help to clarify here that we're talking about a domain *operator=
* versus a domain *owner* -- e.g., GoDaddy vs. me for geopriv.info?

Yes, I think so.

>> This one's new to me. =C2=A0Why is it a must rather than a should?
>
> Paul Hoffman suggested this to me offline. =C2=A0I'm willing to go with a=
 should unless he objects. =C2=A0(Note also that from a procedural POV, the=
se are lower-case, so they don't have force of RFC 2119.)

Ok, thanks for clarification.

>> =C2=A0 =C2=A0No Downgrade: An attacker who can tamper with DNS responses=
 should
>> =C2=A0 =C2=A0not be able to make a DANE-compliant client treat a site th=
at has
>> =C2=A0 =C2=A0deployed DANE and DNSSEC like a site that has deployed neit=
her.
>
> Will change. Also, I have taken the liberty of changing this from a "shou=
ld" to a "must", since it's a rather important security requirement.

Fine by me.  (I certainly hope that whatever language implements that
requirement in the final standard does get an uppercase MUST.)

zw

From [e-mail]  Wed Apr 20 18:04:36 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2FF3FE0693 for <[e-mail]>; Wed, 20 Apr 2011 18:04:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.57
X-Spam-Level: 
X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029,  BAYES_00=-2.599]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z03k0RTrxCMx for <[e-mail]>; Wed, 20 Apr 2011 18:04:35 -0700 (PDT)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfc.amsl.com (Postfix) with ESMTP id 98EF1E069A for <[e-mail]>; Wed, 20 Apr 2011 18:04:34 -0700 (PDT)
Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id F1515C5BB; Wed, 20 Apr 2011 21:04:32 -0400 (EDT)
Date: Wed, 20 Apr 2011 21:04:32 -0400 (EDT)
From: Paul Wouters <[e-mail]>
To: "Richard L. Barnes" <[e-mail]>
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: [e-mail]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 21 Apr 2011 01:04:36 -0000

On Wed, 20 Apr 2011, Richard L. Barnes wrote:

> How about a note of the following form in the introduction:
> "
> The use cases in this document are framed in terms of adding protections to TLS server certificates, since the use of these certificates to authenticate server domain names is very common.  In applications where TLS clients are also identified by domain names (e.g., XMPP server-to-server channels), the same considerations and use cases apply to TLS client certificates.
> "

That works for me.

Paul

From [e-mail]  Wed Apr 20 18:05:11 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 63B2BE06E2 for <[e-mail]>; Wed, 20 Apr 2011 18:05:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.585
X-Spam-Level: 
X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vALmsteEVuSW for <[e-mail]>; Wed, 20 Apr 2011 18:05:10 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfc.amsl.com (Postfix) with ESMTP id BCBDCE069A for <[e-mail]>; Wed, 20 Apr 2011 18:05:10 -0700 (PDT)
Received: from [128.89.253.71] (port=56689 helo=[192.168.1.10]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from <[e-mail]>) id 1QCiKT-0004Ys-Qd; Wed, 20 Apr 2011 21:05:10 -0400
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: "Richard L. Barnes" <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Wed, 20 Apr 2011 21:05:07 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <BANLkTin4SROd1y+rOx9hAxP2ZRcH=[e-mail]> <[e-mail]> <[e-mail]>
To: Zack Weinberg <[e-mail]>
X-Mailer: Apple Mail (2.1082)
Cc: [e-mail]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 21 Apr 2011 01:05:11 -0000

>>>>   This is not a significant incremental risk relative to the
>>>>   current PKIX-based system, however, since it is possible for =
domain
>>>>   operators to obtain certificates for domains under some =
well-known
>>>>   certificate authorities today.
>>>=20
>>> I can't parse this sentence.
>>=20
>> The current threat (as I understand it from others' posts on the =
list) is of the following form:
>> -- CAs need to validate that a CSR comes from a domain owner
>> -- CAs do this validation based on information about the domain, =
e.g., email addresses in WHOIS or the presence of certain records in the =
zone
>> -- DNS operators can control the DNS information that CAs base these =
validation decisions on
>> -- Therefore DNS operators can obtain certs for domains under their =
control
>>=20
>> So the idea is that even though the "Autonomous Certificates" case =
enables an outsourced DNS operator to masquerade as a domain, he already =
has that ability.
>=20
> Yes, that helps a lot.
>=20
>> Would it help to clarify here that we're talking about a domain =
*operator* versus a domain *owner* -- e.g., GoDaddy vs. me for =
geopriv.info?
>=20
> Yes, I think so.

Alright, I'll try to expand this text some to clarify these points.

--Richard


From [e-mail]  Wed Apr 20 18:13:15 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5CEB3E07EB for <[e-mail]>; Wed, 20 Apr 2011 18:13:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.572
X-Spam-Level: 
X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027,  BAYES_00=-2.599]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7gsx3KiaKXo for <[e-mail]>; Wed, 20 Apr 2011 18:13:14 -0700 (PDT)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfc.amsl.com (Postfix) with ESMTP id 9EA89E06E2 for <[e-mail]>; Wed, 20 Apr 2011 18:13:13 -0700 (PDT)
Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 2A03CC5BB; Wed, 20 Apr 2011 21:13:13 -0400 (EDT)
Date: Wed, 20 Apr 2011 21:13:12 -0400 (EDT)
From: Paul Wouters <[e-mail]>
To: "Richard L. Barnes" <[e-mail]>
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: [e-mail]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 21 Apr 2011 01:13:15 -0000

On Wed, 20 Apr 2011, Richard L. Barnes wrote:

>> I would really like to see one of the use cases replaced with the
>> non-CA use case - preferably the one stating it *could* be used without
>> DNSSEC. I'd rather see that all DANE deployments insist on a mandatory
>> DNSSEC validation.
>
> I'm not sure there's consensus around that idea.  Ekr suggested the idea initially, and I agree that while there is security benefit to using DNSSEC for those cases, there is not additional risk in omitting it.

Getting contradicting data is always a problem, whether it came from
falsification or not. That's why it is better to just draw a clear line
and say "MUST only use DANE information if the DNS answer was validated
with DNSSEC", thus avoiding contradicting data to begin with.

>> I like  the use cases in Section 4, but I miss the "HASTLS" type use
>> cases, where the DANE record can avoid a dangerous port 80 connect by
>> asserting via DANE with DNSSEC that all communication to a certain entity
>> is prefered or mandated to happen with TLS.
>
> That was discussed earlier, and there seemed to be agreement that HASTLS problem was outside of the scope of DANE, better suited to application-layer groups like WEBSEC.

I don't recall that at all. Does this mean the HASTLS work has been
moved out of the dane group? Has it been killed? Do you have a pointer
to information on that?

The risk here as mentioned before is that applications will start to
consider the presence of a TLSA/DANE record (at _443.tcp.*) as a "port
443 only" flag.

Paul

From [e-mail]  Wed Apr 20 18:23:23 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C9630E0810 for <[e-mail]>; Wed, 20 Apr 2011 18:23:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.574
X-Spam-Level: 
X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025,  BAYES_00=-2.599]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JcQkHDaJJQCA for <[e-mail]>; Wed, 20 Apr 2011 18:23:23 -0700 (PDT)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfc.amsl.com (Postfix) with ESMTP id 4C592E080E for <[e-mail]>; Wed, 20 Apr 2011 18:23:23 -0700 (PDT)
Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id B5873C5BB; Wed, 20 Apr 2011 21:23:22 -0400 (EDT)
Date: Wed, 20 Apr 2011 21:23:22 -0400 (EDT)
From: Paul Wouters <[e-mail]>
To: "Richard L. Barnes" <[e-mail]>
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: [e-mail]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 21 Apr 2011 01:23:23 -0000

On Wed, 20 Apr 2011, Richard L. Barnes wrote:

>> I would really like to see one of the use cases replaced with the
>> non-CA use case

You did not answer this part of my question yet, only:

>>- preferably the one stating it *could* be used without
>> DNSSEC. I'd rather see that all DANE deployments insist on a mandatory
>> DNSSEC validation.

The largest use case (by number) is to not use any CA/PKIX, and to phase
out all current warnings from browsers about self signed certs using
dane authenticated certificates.

Paul

From [e-mail]  Wed Apr 20 18:29:29 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EAA4FE07EB for <[e-mail]>; Wed, 20 Apr 2011 18:29:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.586
X-Spam-Level: 
X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ts3Ew3blNyKS for <[e-mail]>; Wed, 20 Apr 2011 18:29:29 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfc.amsl.com (Postfix) with ESMTP id 61215E0755 for <[e-mail]>; Wed, 20 Apr 2011 18:29:29 -0700 (PDT)
Received: from [128.89.253.71] (port=56756 helo=[192.168.1.10]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from <[e-mail]>) id 1QCii1-0004kZ-0N; Wed, 20 Apr 2011 21:29:29 -0400
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: "Richard L. Barnes" <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Wed, 20 Apr 2011 21:29:26 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
To: Paul Wouters <[e-mail]>
X-Mailer: Apple Mail (2.1082)
Cc: [e-mail]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 21 Apr 2011 01:29:30 -0000

>>> I would really like to see one of the use cases replaced with the
>>> non-CA use case
>=20
> You did not answer this part of my question yet

Sorry, I assumed this was a result of the "two" confusion, which has =
been resolved.  I removed the "two", so now it just says "the main use =
cases". =20

Why do we need to replace any use cases?  The non-CA use case is already =
in there (3.3); do you think one of the others (3.1, 3.2) needs to be =
deleted?

--Richard=

From [e-mail]  Wed Apr 20 18:41:25 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4B69BE0734 for <[e-mail]>; Wed, 20 Apr 2011 18:41:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.586
X-Spam-Level: 
X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVCaom4kEkd3 for <[e-mail]>; Wed, 20 Apr 2011 18:41:24 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfc.amsl.com (Postfix) with ESMTP id 7A959E06DB for <[e-mail]>; Wed, 20 Apr 2011 18:41:24 -0700 (PDT)
Received: from [128.89.253.71] (port=56767 helo=[192.168.1.10]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from <[e-mail]>) id 1QCitX-0004t4-I7; Wed, 20 Apr 2011 21:41:24 -0400
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: "Richard L. Barnes" <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Wed, 20 Apr 2011 21:41:21 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
To: Paul Wouters <[e-mail]>
X-Mailer: Apple Mail (2.1082)
Cc: [e-mail]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 21 Apr 2011 01:41:25 -0000

>>> I would really like to see one of the use cases replaced with the
>>> non-CA use case - preferably the one stating it *could* be used =
without
>>> DNSSEC. I'd rather see that all DANE deployments insist on a =
mandatory
>>> DNSSEC validation.
>>=20
>> I'm not sure there's consensus around that idea.  Ekr suggested the =
idea initially, and I agree that while there is security benefit to =
using DNSSEC for those cases, there is not additional risk in omitting =
it.
>=20
> Getting contradicting data is always a problem, whether it came from
> falsification or not. That's why it is better to just draw a clear =
line
> and say "MUST only use DANE information if the DNS answer was =
validated
> with DNSSEC", thus avoiding contradicting data to begin with.

This document isn't setting those sorts of requirements.  All it's doing =
is saying "If the solution doesn't require DNSSEC in this case, then =
these are the implications."  The protocol document could make this =
requirement, if there's consensus for it.=20


>>> I like  the use cases in Section 4, but I miss the "HASTLS" type use
>>> cases, where the DANE record can avoid a dangerous port 80 connect =
by
>>> asserting via DANE with DNSSEC that all communication to a certain =
entity
>>> is prefered or mandated to happen with TLS.
>>=20
>> That was discussed earlier, and there seemed to be agreement that =
HASTLS problem was outside of the scope of DANE, better suited to =
application-layer groups like WEBSEC.
>=20
> I don't recall that at all. Does this mean the HASTLS work has been
> moved out of the dane group? Has it been killed? Do you have a pointer
> to information on that?

See, e.g., the following mailing list posts:
<http://www.ietf.org/mail-archive/web/dane/current/msg00130.html>
<http://www.ietf.org/mail-archive/web/dane/current/msg00121.html>
<http://www.ietf.org/mail-archive/web/dane/current/msg00803.html>
<http://www.ietf.org/mail-archive/web/dane/current/msg00682.html>

With regard to ESRV (in the last of the above), see also the discussion =
of DNS-based HSTS alternatives at the WEBSEC meeting at IETF 79:
<http://tools.ietf.org/wg/websec/minutes?item=3Dminutes79.html>

--Richard



P.S. While trawling through the list archives, I found this message from =
an earlier version of myself:
"
I won't object very strongly to a problem statement I-D, but I don't =
think one is really necessary.
"
Oh well, so much for that!
<http://www.ietf.org/mail-archive/web/dane/current/msg00813.html>=

From [e-mail]  Wed Apr 20 18:50:03 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id AD6EBE06DB for <[e-mail]>; Wed, 20 Apr 2011 18:50:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.034
X-Spam-Level: 
X-Spam-Status: No, score=-102.034 tagged_above=-999 required=5 tests=[AWL=0.565, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rs9pDi+UttEr for <[e-mail]>; Wed, 20 Apr 2011 18:50:03 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by ietfc.amsl.com (Postfix) with ESMTP id EF514E0755 for <[e-mail]>; Wed, 20 Apr 2011 18:50:02 -0700 (PDT)
Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p3L1nHRe066704 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Apr 2011 18:49:18 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Paul Hoffman <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Wed, 20 Apr 2011 18:49:17 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
To: Paul Wouters <[e-mail]>
X-Mailer: Apple Mail (2.1084)
Cc: [e-mail]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 21 Apr 2011 01:50:03 -0000

On Apr 20, 2011, at 6:13 PM, Paul Wouters wrote:

>>> I like  the use cases in Section 4, but I miss the "HASTLS" type use
>>> cases, where the DANE record can avoid a dangerous port 80 connect =
by
>>> asserting via DANE with DNSSEC that all communication to a certain =
entity
>>> is prefered or mandated to happen with TLS.
>>=20
>> That was discussed earlier, and there seemed to be agreement that =
HASTLS problem was outside of the scope of DANE, better suited to =
application-layer groups like WEBSEC.
>=20
> I don't recall that at all.

It is not in our charter. Around the end of December, I suggested that =
it should be discussed in the Apps Area. Separately, Jeff Hodges has the =
HSTS draft in the websec WG.

> Does this mean the HASTLS work has been
> moved out of the dane group? Has it been killed? Do you have a pointer
> to information on that?

Yes; no; <https://datatracker.ietf.org/wg/appsawg/>. I am going to =
incorporate comments so far there and issue a new draft.

> The risk here as mentioned before is that applications will start to
> consider the presence of a TLSA/DANE record (at _443.tcp.*) as a "port
> 443 only" flag.

There is nothing in the current TLSA draft that indicates that, is =
there?

--Paul Hoffman


From [e-mail]  Wed Apr 20 19:01:34 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 31BF0E080B for <[e-mail]>; Wed, 20 Apr 2011 19:01:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.448
X-Spam-Level: 
X-Spam-Status: No, score=-102.448 tagged_above=-999 required=5 tests=[AWL=0.529, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JGvJwAoUcVln for <[e-mail]>; Wed, 20 Apr 2011 19:01:33 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfc.amsl.com (Postfix) with ESMTP id 2DDE6E0712 for <[e-mail]>; Wed, 20 Apr 2011 19:01:33 -0700 (PDT)
Received: by iwn39 with SMTP id 39so1371066iwn.31 for <[e-mail]>; Wed, 20 Apr 2011 19:01:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.42.161.3 with SMTP id r3mr828612icx.186.1303351292773; Wed, 20 Apr 2011 19:01:32 -0700 (PDT)
Received: by 10.42.229.199 with HTTP; Wed, 20 Apr 2011 19:01:32 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 20 Apr 2011 19:01:32 -0700
Message-ID: <BANLkTi=BT=nrUfkNXQ15GkoJSzsFPJj=[e-mail]>
From: Eric Rescorla <[e-mail]>
To: Paul Wouters <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Cc: [e-mail]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 21 Apr 2011 02:01:34 -0000

On Wed, Apr 20, 2011 at 6:23 PM, Paul Wouters <[e-mail]> wrote:
> On Wed, 20 Apr 2011, Richard L. Barnes wrote:
>
>>> I would really like to see one of the use cases replaced with the
>>> non-CA use case
>
> You did not answer this part of my question yet, only:
>
>>> - preferably the one stating it *could* be used without
>>> DNSSEC. I'd rather see that all DANE deployments insist on a mandatory
>>> DNSSEC validation.
>
> The largest use case (by number) is to not use any CA/PKIX, and to phase
> out all current warnings from browsers about self signed certs using
> dane authenticated certificates.

It's not clear to me that this is a valid inference.

Yes, it's true that there are a large number of self-signed certificates in use,
and that the operators deploying those certs could in principle use DANE, but
then said operators could in principle also get CA-issued certs. So, I
don't think
that it's at all clear that said operators will in fact constitute the
majority of
DANE deployments, given that they've already demonstrated that they don't
care much about suppressing browser warnings.

-Ekr

From [e-mail]  Wed Apr 20 19:19:56 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 92FA5E0822 for <[e-mail]>; Wed, 20 Apr 2011 19:19:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.575
X-Spam-Level: 
X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024,  BAYES_00=-2.599]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDyd6ilmr9tG for <[e-mail]>; Wed, 20 Apr 2011 19:19:55 -0700 (PDT)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfc.amsl.com (Postfix) with ESMTP id 50B1FE0819 for <[e-mail]>; Wed, 20 Apr 2011 19:19:55 -0700 (PDT)
Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 6B86AC60C; Wed, 20 Apr 2011 22:19:54 -0400 (EDT)
Date: Wed, 20 Apr 2011 22:19:54 -0400 (EDT)
From: Paul Wouters <[e-mail]>
To: "Richard L. Barnes" <[e-mail]>
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: [e-mail]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 21 Apr 2011 02:19:56 -0000

On Wed, 20 Apr 2011, Richard L. Barnes wrote:

> This document isn't setting those sorts of requirements.  All it's doing is saying "If the solution doesn't require DNSSEC in this case, then these are the implications."  The protocol document could make this requirement, if there's consensus for it.

Okay.

> See, e.g., the following mailing list posts:
> <http://www.ietf.org/mail-archive/web/dane/current/msg00130.html>
> <http://www.ietf.org/mail-archive/web/dane/current/msg00121.html>

Looking through these I just see HSTS, in fact I see draft-hodges-strict-transport-sec-02
which clearly states:

12.2. Bootstrap MITM Vulnerability


    The bootstrap MITM (Man-In-The-Middle) vulnerability is a
    vulnerability users and HSTS Servers encounter in the situation where
    the user manually enters, or follows a link, to a HSTS Server using a
    "http" URI rather than a "https" URI.  Because the UA uses an
    insecure channel in the initial attempt to interact with the
    specified serve, such an initial interaction is vulnerable to various
    attacks [ForceHTTPS] .

> <http://www.ietf.org/mail-archive/web/dane/current/msg00803.html>

One IESG member saying we cannot make any policy claims. And as was discussed before,
and the reason that I believe convinced Paul Hoffman to add the extra byte value,
was that in the absense of being able to tell web clients via DNS that they should
only connect securely, the presence of any indicator of a certificate in DNS will
lead people to implement that as "secure only". And thus it will lead to a non-specified
way of policy in the DNS anyways. The fact that tools like sslstrip are so readilly
available for people to use, and which clearly defeat any HSTS deployment that has
to come in over port 80 only shows the need for a full, not a partial, solution.

> <http://www.ietf.org/mail-archive/web/dane/current/msg00682.html>

That mentions SRV type records to address the problem, which I believed were
very much in the minority compared to the HASTLS solution.


> With regard to ESRV (in the last of the above), see also the discussion of DNS-based HSTS alternatives at the WEBSEC meeting at IETF 79:
> <http://tools.ietf.org/wg/websec/minutes?item=minutes79.html>

Those minutes suggest more that HSTS is a temporary stop-gap then a "let's kill alternatives"
approach.

I don't get the feeling consensus about dropping HASTLS for HSTS was
actually reached.  It seems more some procedural change motivated moving
this to another working group, where the DNS options were not really
discussed. But I'll dive in the websec working group archive to see what
actually happened.

Paul

From [e-mail]  Wed Apr 20 19:21:42 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E6384E07F7 for <[e-mail]>; Wed, 20 Apr 2011 19:21:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.245
X-Spam-Level: 
X-Spam-Status: No, score=-3.245 tagged_above=-999 required=5 tests=[AWL=0.353,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6d+bQhNQPT0F for <[e-mail]>; Wed, 20 Apr 2011 19:21:42 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id ED786E0712 for <[e-mail]>; Wed, 20 Apr 2011 19:21:41 -0700 (PDT)
Received: by vws12 with SMTP id 12so1259088vws.31 for <[e-mail]>; Wed, 20 Apr 2011 19:21:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=OCh8u1JU0IP+4zVWOqVJXk0vFqnkG7Fg7X8kmEBoQ98=; b=QI0STrSrsW5UOOE1ef2vSLs13og40hKaAIRYlzOj0V8+UJySalpbiPq/sAlgGa6MRD B9+oMxxQaGDZp4kPKdRHa6YOAcyKwLP4Dx2qeVY35mEeuN3/g8zEBPavnIrnJxaW+2Ol maq8++wGF28OC0I6IoojtlnasmeHe+w+epat0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=adHkozkiSnSe7pNOsguP3IoRuW4vLMFP0eMoztOAV+6bzaY9U3GhldPitQ07UUKznv XiriaSiExsuD3EDr801k/UzYks9ehgf+Hk/jtIWz7ed+li0GXOi8HhZfWNWiYzHQfMzO ukeFv52mE79hgS2MULk4K5JSNSUd3Os25+DPY=
MIME-Version: 1.0
Received: by 10.52.77.70 with SMTP id q6mr3539653vdw.165.1303352501317; Wed, 20 Apr 2011 19:21:41 -0700 (PDT)
Received: by 10.52.161.3 with HTTP; Wed, 20 Apr 2011 19:21:41 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 20 Apr 2011 22:21:41 -0400
Message-ID: <BANLkTi=[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: "Richard L. Barnes" <[e-mail]>
Content-Type: multipart/alternative; boundary=20cf3071cfaedbaeb504a16466dc
Cc: [e-mail]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 21 Apr 2011 02:21:43 -0000

--20cf3071cfaedbaeb504a16466dc
Content-Type: text/plain; charset=ISO-8859-1

The use case is to connect to a Web site with certain security properties
for the communication.

Questions as to whether DNSSEC is to be used or not would come under the
heading of constraints, for example:

* Use of DNSSEC requires X, Y, Z to be available
*Use of CA issued cert requires CA involved at issue

etc. etc.



On Wed, Apr 20, 2011 at 7:45 PM, Richard L. Barnes <[e-mail]> wrote:

> Hey Paul,
>
> Thanks for the quick review.  Responses inline.
>
>
> > Section 3 talks about "the two main use cases".
>
> This is a legacy of an earlier draft, which had two instead of three use
> cases (the "Cert Lock" and "CA Lock" cases were combined).  I'm just going
> to delete the "two", so it applies to however many we end up with :)
>
>
> > I would really like to see one of the use cases replaced with the
> > non-CA use case - preferably the one stating it *could* be used without
> > DNSSEC. I'd rather see that all DANE deployments insist on a mandatory
> > DNSSEC validation.
>
> I'm not sure there's consensus around that idea.  Ekr suggested the idea
> initially, and I agree that while there is security benefit to using DNSSEC
> for those cases, there is not additional risk in omitting it.
>
>
> > I like  the use cases in Section 4, but I miss the "HASTLS" type use
> > cases, where the DANE record can avoid a dangerous port 80 connect by
> > asserting via DANE with DNSSEC that all communication to a certain entity
> > is prefered or mandated to happen with TLS.
>
> That was discussed earlier, and there seemed to be agreement that HASTLS
> problem was outside of the scope of DANE, better suited to application-layer
> groups like WEBSEC.
>
>
>
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane
>



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

--20cf3071cfaedbaeb504a16466dc
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

The use case is to connect to a Web site with certain security properties f=
or the communication.<div><br></div><div>Questions as to whether DNSSEC is =
to be used or not would come under the heading of constraints, for example:=
</div>
<div><br></div><div>* Use of DNSSEC requires X, Y, Z to be available</div><=
div>*Use of CA issued cert requires CA involved at issue</div><div><br></di=
v><div>etc. etc.</div><div><br></div><div><br><br><div class=3D"gmail_quote=
">
On Wed, Apr 20, 2011 at 7:45 PM, Richard L. Barnes <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:[e-mail]">[e-mail]</a>&gt;</span> wrote:<br><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex;">
Hey Paul,<br>
<br>
Thanks for the quick review. =A0Responses inline.<br>
<div class=3D"im"><br>
<br>
&gt; Section 3 talks about &quot;the two main use cases&quot;.<br>
<br>
</div>This is a legacy of an earlier draft, which had two instead of three =
use cases (the &quot;Cert Lock&quot; and &quot;CA Lock&quot; cases were com=
bined). =A0I&#39;m just going to delete the &quot;two&quot;, so it applies =
to however many we end up with :)<br>

<div class=3D"im"><br>
<br>
&gt; I would really like to see one of the use cases replaced with the<br>
&gt; non-CA use case - preferably the one stating it *could* be used withou=
t<br>
&gt; DNSSEC. I&#39;d rather see that all DANE deployments insist on a manda=
tory<br>
&gt; DNSSEC validation.<br>
<br>
</div>I&#39;m not sure there&#39;s consensus around that idea. =A0Ekr sugge=
sted the idea initially, and I agree that while there is security benefit t=
o using DNSSEC for those cases, there is not additional risk in omitting it=
.<br>

<div class=3D"im"><br>
<br>
&gt; I like =A0the use cases in Section 4, but I miss the &quot;HASTLS&quot=
; type use<br>
&gt; cases, where the DANE record can avoid a dangerous port 80 connect by<=
br>
&gt; asserting via DANE with DNSSEC that all communication to a certain ent=
ity<br>
&gt; is prefered or mandated to happen with TLS.<br>
<br>
</div>That was discussed earlier, and there seemed to be agreement that HAS=
TLS problem was outside of the scope of DANE, better suited to application-=
layer groups like WEBSEC.<br>
<div><div></div><div class=3D"h5"><br>
<br>
<br>
_______________________________________________<br>
dane mailing list<br>
<a href=3D"mailto:[e-mail]">[e-mail]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/dane</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a=
 href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--20cf3071cfaedbaeb504a16466dc--

From [e-mail]  Wed Apr 20 19:34:27 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0BAAEE0819 for <[e-mail]>; Wed, 20 Apr 2011 19:34:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.577
X-Spam-Level: 
X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022,  BAYES_00=-2.599]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKjj3WyAqZ+j for <[e-mail]>; Wed, 20 Apr 2011 19:34:26 -0700 (PDT)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfc.amsl.com (Postfix) with ESMTP id 20C49E06DB for <[e-mail]>; Wed, 20 Apr 2011 19:34:26 -0700 (PDT)
Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 8E7BAC60C; Wed, 20 Apr 2011 22:34:25 -0400 (EDT)
Date: Wed, 20 Apr 2011 22:34:25 -0400 (EDT)
From: Paul Wouters <[e-mail]>
To: Paul Hoffman <[e-mail]>
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: [e-mail]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 21 Apr 2011 02:34:27 -0000

On Wed, 20 Apr 2011, Paul Hoffman wrote:

>>> That was discussed earlier, and there seemed to be agreement that HASTLS problem was outside of the scope of DANE, better suited to application-layer groups like WEBSEC.
>>
>> I don't recall that at all.
>
> It is not in our charter.

 	Specify mechanisms and techniques that allow Internet applications to
 	establish cryptographically secured communications by using information
 	distributed through DNSSEC for discovering and authenticating public
 	keys which are associated with a service located at a domain name.

I think "to establish cryptographically secured communications" does in fact
say just that. Publishing TLSA without making any TLS client behaviour change
to properly utilise that via a HASTLS like record would fall short of achieving
the goals as stated in the charter.

> Around the end of December, I suggested that it should be discussed in the Apps Area.

Did it get discussed there? Was anything from the HASTLS drafts re-used or reviewed?

> Yes; no; <https://datatracker.ietf.org/wg/appsawg/>. I am going to incorporate comments so far there and issue a new draft.

Thanks for this pointer. I see some discusion there at:
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg02344.html

>> The risk here as mentioned before is that applications will start to
>> consider the presence of a TLSA/DANE record (at _443.tcp.*) as a "port
>> 443 only" flag.
>
> There is nothing in the current TLSA draft that indicates that, is there?

That's the whole point. If the IETF cannot give guidance on this issue, the
only (non-specified) alternative is to make the assumption that if someone is
advanced enough to publish a TLSA, they probably want you to startout with TLS.

Perhaps the appawg work will proceed well enough thave some kind of DNS record
for this will make it out along with TLSA.

Thanks again for the pointers,

Paul

From [e-mail]  Wed Apr 20 19:37:39 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9AF1FE07EF for <[e-mail]>; Wed, 20 Apr 2011 19:37:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.578
X-Spam-Level: 
X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021,  BAYES_00=-2.599]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZaqJp5fcXZy for <[e-mail]>; Wed, 20 Apr 2011 19:37:38 -0700 (PDT)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfc.amsl.com (Postfix) with ESMTP id CD94DE06DB for <[e-mail]>; Wed, 20 Apr 2011 19:37:38 -0700 (PDT)
Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 42CD5C60C; Wed, 20 Apr 2011 22:37:38 -0400 (EDT)
Date: Wed, 20 Apr 2011 22:37:38 -0400 (EDT)
From: Paul Wouters <[e-mail]>
To: Eric Rescorla <[e-mail]>
In-Reply-To: <BANLkTi=BT=nrUfkNXQ15GkoJSzsFPJj=[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <BANLkTi=BT=nrUfkNXQ15GkoJSzsFPJj=[e-mail]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: [e-mail]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 21 Apr 2011 02:37:39 -0000

On Wed, 20 Apr 2011, Eric Rescorla wrote:

>> The largest use case (by number) is to not use any CA/PKIX, and to phase
>> out all current warnings from browsers about self signed certs using
>> dane authenticated certificates.
>
> It's not clear to me that this is a valid inference.
>
> Yes, it's true that there are a large number of self-signed certificates in use,
> and that the operators deploying those certs could in principle use DANE, but
> then said operators could in principle also get CA-issued certs.

DNS entries in your own zone have cost nothing. PKIX certificates are expensive,
especially because "*" is prohibitively more expensive.

> So, I don't think
> that it's at all clear that said operators will in fact constitute the majority of
> DANE deployments, given that they've already demonstrated that they don't
> care much about suppressing browser warnings.

They demonstrated they don't want each certificate/hostname change to cost $10-$25,
correct.

Paul

From [e-mail]  Wed Apr 20 19:41:15 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 17FDDE06DB for <[e-mail]>; Wed, 20 Apr 2011 19:41:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.587
X-Spam-Level: 
X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0V2f-sXdHFi for <[e-mail]>; Wed, 20 Apr 2011 19:41:13 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfc.amsl.com (Postfix) with ESMTP id B1130E0712 for <[e-mail]>; Wed, 20 Apr 2011 19:41:13 -0700 (PDT)
Received: from [128.89.253.71] (port=57903 helo=[192.168.1.10]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from <[e-mail]>) id 1QCjpQ-000GCH-05; Wed, 20 Apr 2011 22:41:12 -0400
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: "Richard L. Barnes" <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Wed, 20 Apr 2011 22:41:08 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
To: Paul Wouters <[e-mail]>
X-Mailer: Apple Mail (2.1082)
Cc: Paul Hoffman <[e-mail]>, [e-mail]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 21 Apr 2011 02:41:15 -0000

> That's the whole point. If the IETF cannot give guidance on this =
issue, the
> only (non-specified) alternative is to make the assumption that if =
someone is
> advanced enough to publish a TLSA, they probably want you to startout =
with TLS.

Nobody's saying that we're not going to work on the problem, just that =
we're not going to do it here.  Sounds like Paul's working on it over in =
APPSAWG.

--Richard=

From [e-mail]  Wed Apr 20 19:41:36 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E4944E07EF for <[e-mail]>; Wed, 20 Apr 2011 19:41:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.203
X-Spam-Level: 
X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9g216FYvfMFp for <[e-mail]>; Wed, 20 Apr 2011 19:41:36 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfc.amsl.com (Postfix) with ESMTP id 520E5E06DB for <[e-mail]>; Wed, 20 Apr 2011 19:41:36 -0700 (PDT)
Received: by vxg33 with SMTP id 33so1216326vxg.31 for <[e-mail]>; Wed, 20 Apr 2011 19:41:36 -0700 (PDT)
Received: by 10.52.90.73 with SMTP id bu9mr1854090vdb.92.1303353695308; Wed, 20 Apr 2011 19:41:35 -0700 (PDT)
Received: from [192.168.1.104] (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by mx.google.com with ESMTPS id cd8sm301123vdb.8.2011.04.20.19.41.32 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Apr 2011 19:41:34 -0700 (PDT)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <BANLkTi=BT=nrUfkNXQ15GkoJSzsFPJj=[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0 (iPhone Mail 8H7)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=us-ascii
Message-Id: <[e-mail]>
X-Mailer: iPhone Mail (8H7)
From: Eric Rescorla <[e-mail]>
Date: Wed, 20 Apr 2011 19:41:28 -0700
To: Paul Wouters <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 21 Apr 2011 02:41:37 -0000

On Apr 20, 2011, at 19:37, Paul Wouters <[e-mail]> wrote:

> On Wed, 20 Apr 2011, Eric Rescorla wrote:
>=20
>>> The largest use case (by number) is to not use any CA/PKIX, and to phase=

>>> out all current warnings from browsers about self signed certs using
>>> dane authenticated certificates.
>>=20
>> It's not clear to me that this is a valid inference.
>>=20
>> Yes, it's true that there are a large number of self-signed certificates i=
n use,
>> and that the operators deploying those certs could in principle use DANE,=
 but
>> then said operators could in principle also get CA-issued certs.
>=20
> DNS entries in your own zone have cost nothing. PKIX certificates are expe=
nsive,
> especially because "*" is prohibitively more expensive.
>=20

On the other hand pkix certs work for basically any browser whereas currentl=
y Dane-based auth works with approximately no browsers now and far will work=
 for far  less than all for quite some time.


>> So, I don't think
>> that it's at all clear that said operators will in fact constitute the ma=
jority of
>> DANE deployments, given that they've already demonstrated that they don't=

>> care much about suppressing browser warnings.
>=20
> They demonstrated they don't want each certificate/hostname change to cost=
 $10-$25,
> correct.

Right. So they must not value suppressing the warnings very much.

Ekr=

From [e-mail]  Wed Apr 20 19:44:17 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DE908E0712 for <[e-mail]>; Wed, 20 Apr 2011 19:44:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.588
X-Spam-Level: 
X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FzEbboa6ikye for <[e-mail]>; Wed, 20 Apr 2011 19:44:17 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfc.amsl.com (Postfix) with ESMTP id 69486E06DB for <[e-mail]>; Wed, 20 Apr 2011 19:44:17 -0700 (PDT)
Received: from [128.89.253.71] (port=57909 helo=[192.168.1.10]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from <[e-mail]>) id 1QCjsO-000GCv-HC; Wed, 20 Apr 2011 22:44:16 -0400
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: "Richard L. Barnes" <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Wed, 20 Apr 2011 22:44:14 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <BANLkTi=BT=nrUfkNXQ15GkoJSzsFPJj=[e-mail]> <[e-mail]>
To: Paul Wouters <[e-mail]>
X-Mailer: Apple Mail (2.1082)
Cc: [e-mail]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 21 Apr 2011 02:44:18 -0000

>> Yes, it's true that there are a large number of self-signed =
certificates in use,
>> and that the operators deploying those certs could in principle use =
DANE, but
>> then said operators could in principle also get CA-issued certs.
>=20
> DNS entries in your own zone have cost nothing.=20

Counterexample: GoDaddy sells DNSSEC for 3 USD/month.  You could run =
your own zone, but then you take on the whole cost of running it.

--Richard


From [e-mail]  Wed Apr 20 19:54:37 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 83BBDE0715 for <[e-mail]>; Wed, 20 Apr 2011 19:54:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.579
X-Spam-Level: 
X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020,  BAYES_00=-2.599]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id slxwFS8B3YXR for <[e-mail]>; Wed, 20 Apr 2011 19:54:36 -0700 (PDT)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfc.amsl.com (Postfix) with ESMTP id AA21EE0712 for <[e-mail]>; Wed, 20 Apr 2011 19:54:36 -0700 (PDT)
Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 87302C60C; Wed, 20 Apr 2011 22:54:35 -0400 (EDT)
Date: Wed, 20 Apr 2011 22:54:34 -0400 (EDT)
From: Paul Wouters <[e-mail]>
To: Eric Rescorla <[e-mail]>
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <BANLkTi=BT=nrUfkNXQ15GkoJSzsFPJj=[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 21 Apr 2011 02:54:37 -0000

On Wed, 20 Apr 2011, Eric Rescorla wrote:

>>> Yes, it's true that there are a large number of self-signed certificates in use,
>>> and that the operators deploying those certs could in principle use DANE, but
>>> then said operators could in principle also get CA-issued certs.
>>
>> DNS entries in your own zone have cost nothing. PKIX certificates are expensive,
>> especially because "*" is prohibitively more expensive.
>
> On the other hand pkix certs work for basically any browser whereas currently Dane-based auth works with approximately no browsers now and far will work for far  less than all for quite some time.

I'm not quite following the logic of "since we didn't finish the standard
yet, no one is using it" argument.

Nothing the IETF did or does, prevents those people from getting CA
backed certs right now. Still, they did not do so. Do you have any data
on why that is so? I mean, there could be other reasons beside money. It
could be too hard to do for someone who needs to do this twice a year.
And while it is possible that dane will not change anything, dane will
definitely not make the situation worse.

>>> So, I don't think
>>> that it's at all clear that said operators will in fact constitute the majority of
>>> DANE deployments, given that they've already demonstrated that they don't
>>> care much about suppressing browser warnings.
>>
>> They demonstrated they don't want each certificate/hostname change to cost $10-$25,
>> correct.
>
> Right. So they must not value suppressing the warnings very much.

Every single warning supression per entry within a zone costs more then a
year's worth of the entire zone's registration fees.

But which use cases are mentioned does not matter that much anyway (especially since
we're not naming the elephant "We trust DNSSEC more then commercial PKIX)

Richard: I'm fine with your use cases as-is.

Paul

From [e-mail]  Wed Apr 20 21:14:52 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BE183E06FF for <[e-mail]>; Wed, 20 Apr 2011 21:14:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.47
X-Spam-Level: 
X-Spam-Status: No, score=-102.47 tagged_above=-999 required=5 tests=[AWL=0.507, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMuP0uixwRd6 for <[e-mail]>; Wed, 20 Apr 2011 21:14:52 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfc.amsl.com (Postfix) with ESMTP id 2A834E069A for <[e-mail]>; Wed, 20 Apr 2011 21:14:52 -0700 (PDT)
Received: by iye19 with SMTP id 19so1427625iye.31 for <[e-mail]>; Wed, 20 Apr 2011 21:14:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.42.26.83 with SMTP id e19mr2299589icc.387.1303359291769; Wed, 20 Apr 2011 21:14:51 -0700 (PDT)
Received: by 10.42.229.199 with HTTP; Wed, 20 Apr 2011 21:14:51 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <BANLkTi=BT=nrUfkNXQ15GkoJSzsFPJj=[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 20 Apr 2011 21:14:51 -0700
Message-ID: <[e-mail]>
From: Eric Rescorla <[e-mail]>
To: Paul Wouters <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 21 Apr 2011 04:14:52 -0000

On Wed, Apr 20, 2011 at 7:54 PM, Paul Wouters <[e-mail]> wrote:
> On Wed, 20 Apr 2011, Eric Rescorla wrote:
>
>>>> Yes, it's true that there are a large number of self-signed certificat=
es
>>>> in use,
>>>> and that the operators deploying those certs could in principle use
>>>> DANE, but
>>>> then said operators could in principle also get CA-issued certs.
>>>
>>> DNS entries in your own zone have cost nothing. PKIX certificates are
>>> expensive,
>>> especially because "*" is prohibitively more expensive.
>>
>> On the other hand pkix certs work for basically any browser whereas
>> currently Dane-based auth works with approximately no browsers now and f=
ar
>> will work for far =A0less than all for quite some time.
>
> I'm not quite following the logic of "since we didn't finish the standard
> yet, no one is using it" argument.

That's not my argument.

You said that the most important use case by volume is people using self-si=
gned
certs and backing them via DANE. But the value of DANE to the server operat=
or
in that case is primarily in suppressing warnings at the user's browser. Wh=
at I
said is that operators who care about suppressing that warning could get
much more effective warning suppression now and for the foreseeable future
by getting a standard CA certificate. So given that they have not
chosen to do so,
I don't think it's obvious that a large number of those operators will choo=
se to
serve DNSSEC-based DANE certificates at some point in the future.

I agree it's not that particularly important to decide what the most import=
ant
use cases are, but I merely wanted to observe that I didn't think that it w=
as
in fact obvious that this was the most important use case.

-Ekr

From [e-mail]  Wed Apr 20 21:41:24 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DB908E06DB for <[e-mail]>; Wed, 20 Apr 2011 21:41:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.254
X-Spam-Level: 
X-Spam-Status: No, score=-3.254 tagged_above=-999 required=5 tests=[AWL=0.344,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKjLXudllDSN for <[e-mail]>; Wed, 20 Apr 2011 21:41:23 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id 27892E067E for <[e-mail]>; Wed, 20 Apr 2011 21:41:23 -0700 (PDT)
Received: by vws12 with SMTP id 12so1323633vws.31 for <[e-mail]>; Wed, 20 Apr 2011 21:41:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zxmQFBznTmRHHPhcTvx3RJBxM+RWHkPD+6Gz08NGdig=; b=d97yWUi0X7oHFPuuN9eiVZoakeOB1t6RZPIxu+OK2/U8WfdNgjfAxrKMNBVmt1WV18 deGhOPMCgZ8VyJqQ0zSwtdzhcn0tGNXPwfEPWEtzvt5MGSzkBLm1eAnDsag1GPbvEWmi 34ox0q0AbuQ/hSUXJTlpru0vUMxzlwenmT7/k=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=AveUN6FO7SpnHSF9fsstoZO+AiDyVGW4H3cAPPuCdkUjzMGQMCigP6ouJG0HTecOcs W8XWu20tdk8T++iy+W3SvqVSP1Ye8W7AXEuyY/kNxFOggaFqn5gZhAX4XZYB3Drj4p10 EAfA1RVGs6LddjSAUl9/Hfzk0setrXOCIOrCk=
MIME-Version: 1.0
Received: by 10.52.77.70 with SMTP id q6mr3676738vdw.165.1303360882530; Wed, 20 Apr 2011 21:41:22 -0700 (PDT)
Received: by 10.52.161.3 with HTTP; Wed, 20 Apr 2011 21:41:22 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <BANLkTi=BT=nrUfkNXQ15GkoJSzsFPJj=[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 21 Apr 2011 00:41:22 -0400
Message-ID: <[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: Eric Rescorla <[e-mail]>
Content-Type: multipart/alternative; boundary=20cf3071cfae6ad98004a1665afd
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 21 Apr 2011 04:41:25 -0000

--20cf3071cfae6ad98004a1665afd
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Apr 21, 2011 at 12:14 AM, Eric Rescorla <[e-mail]> wrote:

> On Wed, Apr 20, 2011 at 7:54 PM, Paul Wouters <[e-mail]> wrote:
> > On Wed, 20 Apr 2011, Eric Rescorla wrote:
> >
> >>>> Yes, it's true that there are a large number of self-signed
> certificates
> >>>> in use,
> >>>> and that the operators deploying those certs could in principle use
> >>>> DANE, but
> >>>> then said operators could in principle also get CA-issued certs.
> >>>
> >>> DNS entries in your own zone have cost nothing. PKIX certificates are
> >>> expensive,
> >>> especially because "*" is prohibitively more expensive.
> >>
> >> On the other hand pkix certs work for basically any browser whereas
> >> currently Dane-based auth works with approximately no browsers now and
> far
> >> will work for far  less than all for quite some time.
> >
> > I'm not quite following the logic of "since we didn't finish the standard
> > yet, no one is using it" argument.
>
> That's not my argument.
>
> You said that the most important use case by volume is people using
> self-signed
> certs and backing them via DANE. But the value of DANE to the server
> operator
> in that case is primarily in suppressing warnings at the user's browser.
> What I
> said is that operators who care about suppressing that warning could get
> much more effective warning suppression now and for the foreseeable future
> by getting a standard CA certificate. So given that they have not
> chosen to do so,
> I don't think it's obvious that a large number of those operators will
> choose to
> serve DNSSEC-based DANE certificates at some point in the future.
>
> I agree it's not that particularly important to decide what the most
> important
> use cases are, but I merely wanted to observe that I didn't think that it
> was
> in fact obvious that this was the most important use case.
>
> -Ekr
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane
>

I think this is best set out in use case form:

Use Case: Alice wants to set up Web site so that Bob can connect without
Mallet or Eve intercepting messages. Bob has a Dane capable browser

Constraint 1: Carol does not want to upgrade her browser, her user
experience MUST NOT be negatively impacted.
Constraint 2: Alice is not willing to pay for a CA issued cert (or
alternatively does not want to apply for one)

DANE does not provide a solution to this use case under these constraints by
itself.

DANE+HASTLS does provide a solution however. When Carol accesses the site
using her obsolete browser, it does not support the HASTLS mechanism and
thus does not know to try TLS and thus does not issue nuisance warnings.


This si the reason that I have been arguing that HASTLS type requirements
and Key publication requirements have to be considered together from the
very start.

Trying to propose a different way for people to do what they can do already
that is not backwards compatible is a futile waste of time.

The compelling use cases for putting keys in the DNS are to provide
additional security controls for CA issued certs (as CAA does), to enable
promiscuous security and to provide keys for Internet protocols that use TLS
but are not encumbered by a legacy base.

There is a reason that I have spent so much time ensuring that my proposal
works correctly and consistently when SRV, NAPTR or URI type discovery
mechanisms are used. It is because I believe that Web Services is the type
of niche use case that can drive a standard like Dane to reach critical
mass.


I can support the requirements of key issue restrictions, key publication
and advertising security features offered in a single framework that is just
as efficient as the current DANE proposal but does not have the limitations
imposed by the limited scope the authors keep insisting on.

Some people keep claiming that there is consensus for the current approach,
but I don't see one in the WG.


Why can't we choose the protocol architecture on the basis of the proposal
that supports the widest range of use cases with the simplest mechanism and
best objective performance metrics wins?

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

--20cf3071cfae6ad98004a1665afd
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Thu, Apr 21, 2011 at 12:14 AM, Eric R=
escorla <span dir=3D"ltr">&lt;<a href=3D"mailto:[e-mail]">[e-mail]<=
/a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">On Wed, Apr 20, 2011 at 7:54 PM, Paul Wouters &lt;<a href=
=3D"mailto:[e-mail]">[e-mail]</a>&gt; wrote:<br>
&gt; On Wed, 20 Apr 2011, Eric Rescorla wrote:<br>
&gt;<br>
&gt;&gt;&gt;&gt; Yes, it&#39;s true that there are a large number of self-s=
igned certificates<br>
&gt;&gt;&gt;&gt; in use,<br>
&gt;&gt;&gt;&gt; and that the operators deploying those certs could in prin=
ciple use<br>
&gt;&gt;&gt;&gt; DANE, but<br>
&gt;&gt;&gt;&gt; then said operators could in principle also get CA-issued =
certs.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; DNS entries in your own zone have cost nothing. PKIX certifica=
tes are<br>
&gt;&gt;&gt; expensive,<br>
&gt;&gt;&gt; especially because &quot;*&quot; is prohibitively more expensi=
ve.<br>
&gt;&gt;<br>
&gt;&gt; On the other hand pkix certs work for basically any browser wherea=
s<br>
&gt;&gt; currently Dane-based auth works with approximately no browsers now=
 and far<br>
&gt;&gt; will work for far =A0less than all for quite some time.<br>
&gt;<br>
&gt; I&#39;m not quite following the logic of &quot;since we didn&#39;t fin=
ish the standard<br>
&gt; yet, no one is using it&quot; argument.<br>
<br>
</div>That&#39;s not my argument.<br>
<br>
You said that the most important use case by volume is people using self-si=
gned<br>
certs and backing them via DANE. But the value of DANE to the server operat=
or<br>
in that case is primarily in suppressing warnings at the user&#39;s browser=
. What I<br>
said is that operators who care about suppressing that warning could get<br=
>
much more effective warning suppression now and for the foreseeable future<=
br>
by getting a standard CA certificate. So given that they have not<br>
chosen to do so,<br>
I don&#39;t think it&#39;s obvious that a large number of those operators w=
ill choose to<br>
serve DNSSEC-based DANE certificates at some point in the future.<br>
<br>
I agree it&#39;s not that particularly important to decide what the most im=
portant<br>
use cases are, but I merely wanted to observe that I didn&#39;t think that =
it was<br>
in fact obvious that this was the most important use case.<br>
<br>
-Ekr<br>
<div><div></div><div class=3D"h5">_________________________________________=
______<br>
dane mailing list<br>
<a href=3D"mailto:[e-mail]">[e-mail]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/dane</a><br>
</div></div></blockquote></div><br>I think this is best set out in use case=
 form:<div><br></div><div>Use Case: Alice wants to set up Web site so that =
Bob can connect without Mallet or Eve intercepting messages. Bob has a Dane=
 capable browser</div>
<div><br></div><div>Constraint 1: Carol does not want to upgrade her browse=
r, her user experience MUST NOT be negatively impacted.</div><div>Constrain=
t 2: Alice is not willing to pay for a CA issued cert (or alternatively doe=
s not want to apply for one)</div>
<div><br></div><div>DANE does not provide a solution to this use case under=
 these constraints by itself.</div><div><br></div><div>DANE+HASTLS does pro=
vide a solution however. When Carol accesses the site using her obsolete br=
owser, it does not support the HASTLS mechanism and thus does not know to t=
ry TLS and thus does not issue nuisance warnings.</div>
<div><br></div><div><br></div><div>This si the reason that I have been argu=
ing that HASTLS type requirements and Key publication requirements have to =
be considered together from the very start.=A0</div><div><br></div><div>Try=
ing to propose a different way for people to do what they can do already th=
at is not backwards compatible is a futile waste of time.=A0</div>
<div><br></div><div>The compelling use cases for putting keys in the DNS ar=
e to provide additional security controls for CA issued certs (as CAA does)=
, to enable promiscuous security and to provide keys for Internet protocols=
 that use TLS but are not encumbered by a legacy base.</div>
<div><br></div><div>There is a reason that I have spent so much time ensuri=
ng that my proposal works correctly and consistently when SRV, NAPTR or URI=
 type discovery mechanisms are used. It is because I believe that Web Servi=
ces is the type of niche use case that can drive a standard like Dane to re=
ach critical mass.</div>
<div><br></div><div><br></div><div>I can support the requirements of key is=
sue restrictions, key publication and advertising security features offered=
 in a single framework that is just as efficient as the current DANE propos=
al but does not have the limitations imposed by the limited scope the autho=
rs keep insisting on.</div>
<div><br></div><div>Some people keep claiming that there is consensus for t=
he current approach, but I don&#39;t see one in the WG.</div><div><br></div=
><div><br></div><div>Why can&#39;t we choose the protocol architecture on t=
he basis of the proposal that supports the widest range of use cases with t=
he simplest mechanism and best objective performance metrics wins?=A0</div>
<div><br>-- <br>Website: <a href=3D"http://hallambaker.com/">http://hallamb=
aker.com/</a><br><br>
</div>

--20cf3071cfae6ad98004a1665afd--

From [e-mail]  Thu Apr 21 13:24:26 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DDDC8E0732 for <[e-mail]>; Thu, 21 Apr 2011 13:24:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.702
X-Spam-Level: 
X-Spam-Status: No, score=-100.702 tagged_above=-999 required=5 tests=[AWL=-0.397, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_BL_SPAMCOP_NET=1.96, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id flGV00yBncaW for <[e-mail]>; Thu, 21 Apr 2011 13:24:26 -0700 (PDT)
Received: from oproxy2-pub.bluehost.com (oproxy2-pub.bluehost.com [67.222.39.60]) by ietfc.amsl.com (Postfix) with SMTP id D41C5E06B9 for <[e-mail]>; Thu, 21 Apr 2011 13:24:25 -0700 (PDT)
Received: (qmail 28294 invoked by uid 0); 21 Apr 2011 20:24:23 -0000
Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy2.bluehost.com with SMTP; 21 Apr 2011 20:24:23 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=0aQg0DEAAJkEA7uNpS4xTU+mZptvCc7d9y6mCefsgxv49iU8fHIYldkbTgLopLgW6cGijXneQHU85fegw8+NSbWCFcUFcbtW+LncqVLbxy2d0Kl6jaOB1NIL2e/I/07A;
Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.136.202]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <[e-mail]>) id 1QD0QJ-0007ZT-Kq for [e-mail]; Thu, 21 Apr 2011 14:24:23 -0600
Message-ID: <[e-mail]>
Date: Thu, 21 Apr 2011 13:24:23 -0700
From: =JeffH <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8
MIME-Version: 1.0
To: IETF DANE WG list <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com}
Subject: [dane] of self-signed cert use case (was: I-D Action:draft-ietf-dane-use-cases-00.txt)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 21 Apr 2011 20:24:27 -0000

Eric Rescorla <[e-mail]> said:
 >
 > I agree it's not that particularly important to decide what the most
 > important use cases are,

agreed.

 > but I merely wanted to observe that I didn't think that it was in fact
 > obvious that [the self-signed cert use case is] the most important use
 > case.

agreed.


Paul Wouters <[e-mail]> had stated:
 >
 > Nothing ... prevents those [self-signed TLS-based service operators] from
 > getting CA backed certs right now. Still, they did not do so. Do [we] have
 > any data on why that is so? I mean, there could be other reasons beside
 > money.

yes, this is an interesting question. It'd be nice if anyone with data could
share it. But answering it is not critical it seems, as long as the DANE 
mechanism ends up supporting non-CA-backed certs/key-pairs.


On Wed, Apr 20, 2011 at 7:54 PM, Paul Wouters <[e-mail]> wrote:
 > On Wed, 20 Apr 2011, Eric Rescorla wrote:
 >> Paul Woulters had replied:
 >>> EKR had stated:
 >>>
 >>>> Yes, it's true that there are a large number of self-signed
 >>>> certificates in use, and that the operators deploying those certs
 >>>> could in principle use DANE, but then said operators could in
 >>>> principle also get CA-issued certs.
 >>>
 >>> DNS entries in your own zone have cost nothing. PKIX certificates are
 >>> expensive, especially because "*" is prohibitively more expensive.
 >>
 >> On the other hand pkix certs work for basically any browser whereas
 >> currently Dane-based auth works with approximately no browsers now and ..
 >> will work for far less than all for quite some time.
 >
 > I'm not quite following the logic of "since we didn't finish the standard
 > yet, no one is using it" argument.


Eric Rescorla <[e-mail]> replied:
 >
 > You said that the most important use case by volume is people using
 > self-signed certs and backing them via DANE. But the value of DANE to the
 > server operator in that case is primarily in suppressing warnings at the
 > user's browser.

I think that obtaining "exclusion" (aka "pinning" or "locking" to a particular
CA or cert (aka key pair)) would also be a first-order consideration [for 
deploying the "DANE mechanism"], yes?


 > What I said is that operators who care about suppressing that warning could
 > get much more effective warning suppression now and for the foreseeable
 > future by getting a standard CA certificate.

Well, yes, that is one thing they could do.

However, they also can have users install their trust anchor CA cert into their 
client apps (which we've been assuming are largely off-the-shelf web browsers; 
how easy it is to distrib-and-install-a-TA depends to some extent on the nature 
of the user population), or they could distribute the(ir) client apps 
pre-configured.

We, here in this discussion anyway, don't really know what [self-signed 
TLS-based service operators] are doing and why, nor whether they in actuality 
"don't care" about warnings, or whether they "do care" but there's some 
reason(s) (effort/cost/awareness/whatever), or whether they have worked around 
warnings in some fashion, or whether warnings haven't mattered (or appeared).


 > ... I don't think it's obvious that a large number of [self-signed TLS-based
 > service operators] will choose to serve DNSSEC-based DANE certificates at
 > some point in the future.

Agreed modulo the notion of "large". It could well be that some chunk of 
[self-signed TLS-based service operators] will choose to employ the DANE 
mechanism. We just don't have a good understanding of the magnitude of the 
"chunk" and how it will evolve over time.

HTH,

=JeffH




From [e-mail]  Thu Apr 21 13:31:00 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2A76EE06E4 for <[e-mail]>; Thu, 21 Apr 2011 13:31:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.489
X-Spam-Level: 
X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=0.488, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chYwcFiWi+bw for <[e-mail]>; Thu, 21 Apr 2011 13:30:59 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfc.amsl.com (Postfix) with ESMTP id 9E453E06B9 for <[e-mail]>; Thu, 21 Apr 2011 13:30:59 -0700 (PDT)
Received: by iwn39 with SMTP id 39so84483iwn.31 for <[e-mail]>; Thu, 21 Apr 2011 13:30:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.42.140.193 with SMTP id l1mr480308icu.119.1303417859254; Thu, 21 Apr 2011 13:30:59 -0700 (PDT)
Received: by 10.42.229.199 with HTTP; Thu, 21 Apr 2011 13:30:59 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 21 Apr 2011 13:30:59 -0700
Message-ID: <[e-mail]>
From: Eric Rescorla <[e-mail]>
To: "=JeffH" <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Cc: IETF DANE WG list <[e-mail]>
Subject: Re: [dane] of self-signed cert use case (was: I-D Action:draft-ietf-dane-use-cases-00.txt)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 21 Apr 2011 20:31:00 -0000

On Thu, Apr 21, 2011 at 1:24 PM, =JeffH <[e-mail]> wrote:
> Eric Rescorla <[e-mail]> replied:
>>
>> You said that the most important use case by volume is people using
>> self-signed certs and backing them via DANE. But the value of DANE to the
>> server operator in that case is primarily in suppressing warnings at the
>> user's browser.
>
> I think that obtaining "exclusion" (aka "pinning" or "locking" to a
> particular
> CA or cert (aka key pair)) would also be a first-order consideration [for
> deploying the "DANE mechanism"], yes?

Yes. I tend towards the view that this is the primary value of DANE.
However, it seems
likely that those people already have CA-issued certs.

-Ekr

From [e-mail]  Thu Apr 21 13:48:07 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1DDBBE074E for <[e-mail]>; Thu, 21 Apr 2011 13:48:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.982
X-Spam-Level: 
X-Spam-Status: No, score=-9.982 tagged_above=-999 required=5 tests=[AWL=0.267,  BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3DuqVHQbSYV5 for <[e-mail]>; Thu, 21 Apr 2011 13:48:06 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfc.amsl.com (Postfix) with ESMTP id 41A72E06B9 for <[e-mail]>; Thu, 21 Apr 2011 13:48:06 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p3LKm4tP012630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 21 Apr 2011 22:48:04 +0200 (MEST)
From: Martin Rex <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail] (Eric Rescorla)
Date: Thu, 21 Apr 2011 22:48:03 +0200 (MEST)
In-Reply-To: <BANLkTi=BT=nrUfkNXQ15GkoJSzsFPJj=[e-mail]> from "Eric Rescorla" at Apr 20, 11 07:01:32 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: [e-mail]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: [e-mail]
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 21 Apr 2011 20:48:07 -0000

Eric Rescorla wrote:
> 
> On Wed, Apr 20, 2011 at 6:23 PM, Paul Wouters <[e-mail]> wrote:
> >
> > The largest use case (by number) is to not use any CA/PKIX, and to phase
> > out all current warnings from browsers about self signed certs using
> > dane authenticated certificates.

My impression was that about half of the not-obviously-invalid certs
on the internet are self-signed, the other half is issued under any
of the commercial CAs shipping in browsers.  I don't know how exactly
the number are for "hosts", because the queries that Peter Eckersley
from the EFF did so far where about unique server certs only.


> 
> Yes, it's true that there are a large number of self-signed certificates
> in use, and that the operators deploying those certs could in principle
> use DANE, but then said operators could in principle also get CA-issued
> certs. So, I don't think that it's at all clear that said operators will
> in fact constitute the majority of DANE deployments, given that they've
> already demonstrated that they don't care much about suppressing
> browser warnings.

Certs issued from commercial CAs are a royal PITA.  You have to pay a
yearly recurring fee, they're lifetime limited to one year, and so
if you have a couple of them, you get huge additional overhead.

Being able to create a self-signed cert once with a long lifetime
and use it until you dump or replace the equipment is *MUCH* preferable.

Here in the office, we have an open guest WLAN (internet access) with a
"captive portal".  The captive portal uses TLS with a commercial CA cert,
but there seem to several different boxes that use the exactly same
cert, on the one covering the WLAN for my office used an expired cert
a few weeks ago.  MSIE 7 did show a warning, offering to continue -- but
failed to connect anyway (apparently there was some hard-fail added
somewhere in XPsp3 SChannel).  So I had to resort using an older
firefox browser to be able to authenticate (and not have to wait
until my trouble ticket was processed and that particular network
component updated with a new cert).


-Martin

From [e-mail]  Thu Apr 21 14:19:44 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EADD6E06E4 for <[e-mail]>; Thu, 21 Apr 2011 14:19:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.582
X-Spam-Level: 
X-Spam-Status: No, score=-101.582 tagged_above=-999 required=5 tests=[AWL=0.683, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLN4y63iyWyG for <[e-mail]>; Thu, 21 Apr 2011 14:19:44 -0700 (PDT)
Received: from oproxy3-pub.bluehost.com (oproxy3-pub.bluehost.com [69.89.21.8]) by ietfc.amsl.com (Postfix) with SMTP id EC682E06C4 for <[e-mail]>; Thu, 21 Apr 2011 14:19:43 -0700 (PDT)
Received: (qmail 9252 invoked by uid 0); 21 Apr 2011 21:19:43 -0000
Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy3.bluehost.com with SMTP; 21 Apr 2011 21:19:43 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=vTDFhbDrYNPerHl1qbrerd443r0RPUJLSQOJtwNuBQnJ59HXzasWcYNqE1psG/WjRBFe/WNFXxQvaLKVSbc44ctdIoaZLXKfo+ryO9PMPIFBHUNySbgBLYU3lg36wTx4;
Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.136.202]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <[e-mail]>) id 1QD1Hq-00028b-QO for [e-mail]; Thu, 21 Apr 2011 15:19:43 -0600
Message-ID: <[e-mail]>
Date: Thu, 21 Apr 2011 14:19:42 -0700
From: =JeffH <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8
MIME-Version: 1.0
To: IETF DANE WG list <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com}
Subject: [dane] wrt HSTS, HASTLS, and DANE  (was: I-D Action:draft-ietf-dane-use-cases-00.txt)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 21 Apr 2011 21:19:45 -0000

On Wed, 20 Apr 2011 22:19:54 -0400 (EDT) Paul Wouters <[e-mail]> said:
 >
 >> See, e.g., the following mailing list posts:
 >> <http://www.ietf.org/mail-archive/web/dane/current/msg00130.html>
 >> <http://www.ietf.org/mail-archive/web/dane/current/msg00121.html>
 >
 > Looking through these I just see HSTS, in fact I see draft-hodges-strict-
 > transport-sec-02 ...

Just to update folks' pointers, draft-hodges-strict-transport-sec is superseded 
by..

   http://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec


 > The fact that tools like sslstrip are so readilly available for people to
 > use, and which clearly defeat any HSTS deployment that has to come in over
 > port 80 only shows the need for a full, not a partial, solution

While I understand your concern here wrt HSTS and the (legit) "Bootstrap MITM 
Vulnerability", it is a more nuanced problem than the way you've been 
portraying it, and I'm compelled to note some of the nuances here in response..

HSTS-enabled clients are only vulnerable to the Bootstrap MITM vuln if the 
website is not already noted in the client's HSTS-store. I.e. the very first 
time they connect, via http/tcp (rather than http/tls), to an uncached 
HSTS-host. Once they have successfully legitimately connected to a HSTS-host, 
they are protected for the max-age of the HSTS policy. Note that clients (ie 
browsers) can (and Chrome does) have a "factory-loaded" HSTS-store (and are 
encouraged to implement such :) -- thus HSTS-hosts listed in the 
"factory-loaded" HSTS-store are never connected to insecurely.

That said, you note..

 > Those minutes suggest more that HSTS is a temporary stop-gap then a "let's
 > kill alternatives" approach.

..and the short answer here is "yes", though I've been calling it an 
"intermediate term" solution rather than a "temporary stop-gap".


On another aspect of this overall HSTS, HASTLS, and DANE multi-faceted topic, 
you said..
 > Paul Hoffman had replied:
 >> You stated:
 >>> The risk here as mentioned before is that applications will start to
 >>> consider the presence of a TLSA/DANE record (at _443.tcp.*) as a "port
 >>> 443 only" flag.
 >>
 >> There is nothing in the current TLSA draft that indicates that, is there?
 >
 > That's the whole point. If the IETF cannot give guidance on this issue, the
 > only (non-specified) alternative is to make the assumption that if someone
 > is advanced enough to publish a TLSA, they probably want you to startout
 > with TLS.

Although I understand your concern and believe it is nominally legit, in the 
broad consumer case it is mostly a matter of ensuring that the (small number 
of) major browser vendors don't do that, which is manageable IMV.


 > Perhaps the appawg work will proceed well enough thave some kind of DNS
 > record for this will make it out along with TLSA.

agreed.

HTH,

=JeffH




From [e-mail]  Thu Apr 21 14:24:17 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0E079E0704 for <[e-mail]>; Thu, 21 Apr 2011 14:24:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.719
X-Spam-Level: 
X-Spam-Status: No, score=-101.719 tagged_above=-999 required=5 tests=[AWL=0.546, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2k5mb9zh9WVn for <[e-mail]>; Thu, 21 Apr 2011 14:24:16 -0700 (PDT)
Received: from oproxy3-pub.bluehost.com (oproxy3-pub.bluehost.com [69.89.21.8]) by ietfc.amsl.com (Postfix) with SMTP id 3CB10E0678 for <[e-mail]>; Thu, 21 Apr 2011 14:24:16 -0700 (PDT)
Received: (qmail 21889 invoked by uid 0); 21 Apr 2011 21:24:15 -0000
Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy3.bluehost.com with SMTP; 21 Apr 2011 21:24:15 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=PPwdOUDs/aGRX838mwNsp+3CDngyK359j450OzwPWdeWF7koDYz7w2Xb4YSd5zzT8pK7i8nDwYgPpVwea64maca8yTSzP2WiXYd8KEHPSvbAiyV4FKi37pvdlC/mqwwD;
Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.136.202]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <[e-mail]>) id 1QD1MF-0006VW-Jn for [e-mail]; Thu, 21 Apr 2011 15:24:15 -0600
Message-ID: <[e-mail]>
Date: Thu, 21 Apr 2011 14:24:15 -0700
From: =JeffH <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8
MIME-Version: 1.0
To: IETF DANE WG list <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com}
Subject: Re: [dane] of self-signed cert use case (was: I-D Action:draft-ietf-dane-use-cases-00.txt)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 21 Apr 2011 21:24:17 -0000

EKR replied:
 > On Thu, Apr 21, 2011 at 1:24 PM, =JeffH <[e-mail]> wrote:
 >> Eric Rescorla <[e-mail]> replied:
 >>>
 >>> You said that the most important use case by volume is people using
 >>> self-signed certs and backing them via DANE. But the value of DANE to the
 >>> server operator in that case is primarily in suppressing warnings at the
 >>> user's browser.
 >>
 >> I think that obtaining "exclusion" (aka "pinning" or "locking" to a
 >> particular CA or cert (aka key pair)) would also be a first-order
 >> consideration [for deploying the "DANE mechanism"], yes?
 >
 > Yes. I tend towards the view that this is the primary value of DANE.

me too.

 > However, it seems likely that those people already have CA-issued certs.

s/ that those people / that many of those people/


=JeffH



From [e-mail]  Thu Apr 21 14:26:27 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B6B12E078E for <[e-mail]>; Thu, 21 Apr 2011 14:26:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.107
X-Spam-Level: 
X-Spam-Status: No, score=-100.107 tagged_above=-999 required=5 tests=[AWL=-1.930, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_12=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_210=0.6, J_CHICKENPOX_25=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_28=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GP7Wc3LX5htp for <[e-mail]>; Thu, 21 Apr 2011 14:26:27 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfc.amsl.com (Postfix) with ESMTP id E0303E0704 for <[e-mail]>; Thu, 21 Apr 2011 14:26:26 -0700 (PDT)
Received: by iye19 with SMTP id 19so117026iye.31 for <[e-mail]>; Thu, 21 Apr 2011 14:26:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.42.222.9 with SMTP id ie9mr442565icb.454.1303421186372; Thu, 21 Apr 2011 14:26:26 -0700 (PDT)
Received: by 10.42.229.199 with HTTP; Thu, 21 Apr 2011 14:26:26 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <BANLkTi=BT=nrUfkNXQ15GkoJSzsFPJj=[e-mail]> <[e-mail]>
Date: Thu, 21 Apr 2011 14:26:26 -0700
Message-ID: <[e-mail]>
From: Eric Rescorla <[e-mail]>
To: [e-mail]
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: [e-mail]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 21 Apr 2011 21:26:27 -0000

On Thu, Apr 21, 2011 at 1:48 PM, Martin Rex <[e-mail]> wrote:
> Eric Rescorla wrote:
>> Yes, it's true that there are a large number of self-signed certificates
>> in use, and that the operators deploying those certs could in principle
>> use DANE, but then said operators could in principle also get CA-issued
>> certs. So, I don't think that it's at all clear that said operators will
>> in fact constitute the majority of DANE deployments, given that they've
>> already demonstrated that they don't care much about suppressing
>> browser warnings.
>
> Certs issued from commercial CAs are a royal PITA.

Sure.


>=A0You have to pay a
> yearly recurring fee,

Or you pay upfront, which, many CAs are happy to allow.


> they're lifetime limited to one year,

Not true. For instance:


Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            1f:19:f6:de:35:dd:63:a1:42:91:8a:d5:2c:c0:ab:12
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=3DZA, O=3DThawte Consulting (Pty) Ltd., CN=3DThawte SGC C=
A
        Validity
            Not Before: Dec 18 00:00:00 2009 GMT
            Not After : Dec 18 23:59:59 2011 GMT
        Subject: C=3DUS, ST=3DCalifornia, L=3DMountain View, O=3DGoogle Inc=
,
CN=3Dmail.google.com


or:
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            25:f5:d1:2d:5e:6f:0b:d4:ea:f2:a2:c9:66:f3:b4:ce
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=3DUS, O=3DVeriSign, Inc., OU=3DVeriSign Trust Network,
OU=3DTerms of use at https://www.verisign.com/rpa (c)09, CN=3DVeriSign
Class 3 Secure Server CA - G2
        Validity
            Not Before: Jul 15 00:00:00 2010 GMT
            Not After : Jul 14 23:59:59 2013 GMT
        Subject: C=3DUS, ST=3DWashington, L=3DSeattle, O=3DAmazon.com Inc.,
CN=3Dwww.amazon.com



> and so
> if you have a couple of them, you get huge additional overhead.

Well, it's not like having to run DNSSEC is somehow overhead free. I think =
it's
an open question whether DANE will in fact be more convenient.

-Ekr

From [e-mail]  Thu Apr 21 16:01:15 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DBC01E06CE for <[e-mail]>; Thu, 21 Apr 2011 16:01:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.986
X-Spam-Level: 
X-Spam-Status: No, score=-9.986 tagged_above=-999 required=5 tests=[AWL=0.263,  BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUevkTjRHBJA for <[e-mail]>; Thu, 21 Apr 2011 16:01:15 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfc.amsl.com (Postfix) with ESMTP id DD7F5E0695 for <[e-mail]>; Thu, 21 Apr 2011 16:01:14 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p3LN1DA4024608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 22 Apr 2011 01:01:13 +0200 (MEST)
From: Martin Rex <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail] (Eric Rescorla)
Date: Fri, 22 Apr 2011 01:01:12 +0200 (MEST)
In-Reply-To: <[e-mail]> from "Eric Rescorla" at Apr 21, 11 02:26:26 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: [e-mail]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: [e-mail]
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 21 Apr 2011 23:01:16 -0000

Eric Rescorla wrote:
> 
> > 
> > Certs issued from commercial CAs are a royal PITA.
> 
> Sure.
> 
> 
> > You have to pay a yearly recurring fee,
> 
> Or you pay upfront, which, many CAs are happy to allow.
> 
> 
> > they're lifetime limited to one year,
> 
> Not true.

You mean like this here:

http://www.sslshopper.com/cheapest-ssl-certificates.html


Yes you buy certs that are valid for several years, but
you have to pay several times as much, have to pay upfront,
and it doesn't look like that you get a 4 year refund if
you want to or have to move to a different hostname or
different domain after 1 year.


> 
> > and so if you have a couple of them, you get huge additional overhead.
> 
> Well, it's not like having to run DNSSEC is somehow overhead free.
> I think it's an open question whether DANE will in fact be more
> convenient.

When using DNSSEC, you only incur costs for setting it up once,
but then it can untouched for years until you want to or have to
change it (or want to rekey after a break-in) and you don't loose
money (fees and administrative overhead) like you do with commercial CAs.

The difference of maintaining one vs. two DNS records is negligible.
and you will have to maintain just as much with records with a cert
from commercial CA (just a different dane record type).


-Martin

From [e-mail]  Thu Apr 21 16:23:17 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D5286E065C for <[e-mail]>; Thu, 21 Apr 2011 16:23:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.438
X-Spam-Level: 
X-Spam-Status: No, score=-102.438 tagged_above=-999 required=5 tests=[AWL=0.539, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWEchtpxRlct for <[e-mail]>; Thu, 21 Apr 2011 16:23:17 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfc.amsl.com (Postfix) with ESMTP id 49512E00BE for <[e-mail]>; Thu, 21 Apr 2011 16:23:17 -0700 (PDT)
Received: by iye19 with SMTP id 19so177761iye.31 for <[e-mail]>; Thu, 21 Apr 2011 16:23:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.43.55.131 with SMTP id vy3mr519917icb.521.1303428196662; Thu, 21 Apr 2011 16:23:16 -0700 (PDT)
Received: by 10.42.229.199 with HTTP; Thu, 21 Apr 2011 16:23:16 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Thu, 21 Apr 2011 16:23:16 -0700
Message-ID: <BANLkTi=[e-mail]>
From: Eric Rescorla <[e-mail]>
To: [e-mail]
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: [e-mail]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 21 Apr 2011 23:23:18 -0000

On Thu, Apr 21, 2011 at 4:01 PM, Martin Rex <[e-mail]> wrote:
> Eric Rescorla wrote:
>>
>> >
>> > Certs issued from commercial CAs are a royal PITA.
>>
>> Sure.
>>
>>
>> >=A0You have to pay a yearly recurring fee,
>>
>> Or you pay upfront, which, many CAs are happy to allow.
>>
>>
>> > they're lifetime limited to one year,
>>
>> Not true.
>
> You mean like this here:
>
> http://www.sslshopper.com/cheapest-ssl-certificates.html
>
>
> Yes you buy certs that are valid for several years, but
> you have to pay several times as much, have to pay upfront,

I don't recall claiming otherwise. What I claimed was that, your assertion =
to
the contrary, you could in fact get certificates that were valid for >1 yea=
r.
As the certificates I posted [and you deleted] clearly demonstrate, I am co=
rrect
on this point.

-Ekr

From [e-mail]  Thu Apr 21 17:21:58 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 889D8E0751 for <[e-mail]>; Thu, 21 Apr 2011 17:21:58 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16Jc11NXHozP for <[e-mail]>; Thu, 21 Apr 2011 17:21:57 -0700 (PDT)
Received: from new-smtp02.pacifier.net (new-smtp02.pacifier.net [64.255.237.176]) by ietfc.amsl.com (Postfix) with ESMTP id BFF0AE065C for <[e-mail]>; Thu, 21 Apr 2011 17:21:57 -0700 (PDT)
Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: [e-mail]) by new-smtp02.pacifier.net (Postfix) with ESMTPSA id 584782CA64; Thu, 21 Apr 2011 17:21:56 -0700 (PDT)
From: "Jim Schaad" <[e-mail]>
To: "'Paul Wouters'" <[e-mail]>, "'Eric Rescorla'" <[e-mail]>
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<BANLkTi=BT=nrUfkNXQ15GkoJSzsFPJj=[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Thu, 21 Apr 2011 17:47:49 -0700
Message-ID: <009901cc0086$eba860c0$c2f92240$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQLHciyl4Bo3j1cASuiV1QClgchu9wIRRKSwAruV/h0CN7NQcgG1E+ThAfIydeOSHLDn0A==
Content-Language: en-us
Cc: [e-mail]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 22 Apr 2011 00:21:58 -0000

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Paul Wouters
> Sent: Wednesday, April 20, 2011 7:38 PM
> To: Eric Rescorla
> Cc: [e-mail]
> Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt
> 
> On Wed, 20 Apr 2011, Eric Rescorla wrote:
> 
> >> The largest use case (by number) is to not use any CA/PKIX, and to
> >> phase out all current warnings from browsers about self signed certs
> >> using dane authenticated certificates.
> >
> > It's not clear to me that this is a valid inference.
> >
> > Yes, it's true that there are a large number of self-signed
> > certificates in use, and that the operators deploying those certs
> > could in principle use DANE, but then said operators could in principle
also
> get CA-issued certs.
> 
> DNS entries in your own zone have cost nothing. PKIX certificates are
> expensive, especially because "*" is prohibitively more expensive.

This is not what I have found.  Since my DNS entries are maintained by a 3rd
party company they charge me for every DNS entry change that I want to make.

> 
> > So, I don't think
> > that it's at all clear that said operators will in fact constitute the
> > majority of DANE deployments, given that they've already demonstrated
> > that they don't care much about suppressing browser warnings.
> 
> They demonstrated they don't want each certificate/hostname change to
> cost $10-$25, correct.
> 
> Paul
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane


From [e-mail]  Thu Apr 21 18:43:47 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DC7BDE0721 for <[e-mail]>; Thu, 21 Apr 2011 18:43:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.263
X-Spam-Level: 
X-Spam-Status: No, score=-3.263 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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u0Bh9inFIxP8 for <[e-mail]>; Thu, 21 Apr 2011 18:43:46 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id D0C4DE0719 for <[e-mail]>; Thu, 21 Apr 2011 18:43:46 -0700 (PDT)
Received: by vws12 with SMTP id 12so238333vws.31 for <[e-mail]>; Thu, 21 Apr 2011 18:43:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=LXN0OhfiEjZt3BnEAJ2LcT2v8GZt0ZU0YZL0JaxtzfU=; b=V8QfNCZq4KDAiSe2hdYt1dV3HYAGByrPyPRfSTyYT/hRKmmdenn8gWF0zDJ2s5cctu vEH2m1raJqVhEXEksvgS44rrAT/wkx9saBZV9/soheRWVJjgQ/+Q6hYDBq2sbx3yJCKC 15WUgmZMHV+qxpin/C9L8wRaD7edtWBUITs9M=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=e/AsDyGWVKxNt7wvEacQzpsybIqnaJwtmUOaHs1H8RnWjIz1g/c1CVUr/aTI2QhgE9 itMg0NWDJKZNbO3XO1nXX2mBh3wZ4eiCQRkI/LEMta6UbwL8hC4WjHvGPjOyd9cc5mhr lIHCTgIpWev5X4iNfwZ1Ey+fZRrlVPdQXviNs=
MIME-Version: 1.0
Received: by 10.52.77.70 with SMTP id q6mr896233vdw.165.1303436626306; Thu, 21 Apr 2011 18:43:46 -0700 (PDT)
Received: by 10.52.161.3 with HTTP; Thu, 21 Apr 2011 18:43:46 -0700 (PDT)
In-Reply-To: <009901cc0086$eba860c0$c2f92240$@augustcellars.com>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <BANLkTi=BT=nrUfkNXQ15GkoJSzsFPJj=[e-mail]> <[e-mail]> <009901cc0086$eba860c0$c2f92240$@augustcellars.com>
Date: Thu, 21 Apr 2011 21:43:46 -0400
Message-ID: <[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: Jim Schaad <[e-mail]>
Content-Type: multipart/alternative; boundary=20cf3071cfae1925d704a177fd80
Cc: [e-mail]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 22 Apr 2011 01:43:48 -0000

--20cf3071cfae1925d704a177fd80
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Apr 21, 2011 at 8:47 PM, Jim Schaad <[e-mail]> wrote:

>
>
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On Behalf Of
> > Paul Wouters
> > Sent: Wednesday, April 20, 2011 7:38 PM
> > To: Eric Rescorla
> > Cc: [e-mail]
> > Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt
> >
> > On Wed, 20 Apr 2011, Eric Rescorla wrote:
> >
> > >> The largest use case (by number) is to not use any CA/PKIX, and to
> > >> phase out all current warnings from browsers about self signed certs
> > >> using dane authenticated certificates.
> > >
> > > It's not clear to me that this is a valid inference.
> > >
> > > Yes, it's true that there are a large number of self-signed
> > > certificates in use, and that the operators deploying those certs
> > > could in principle use DANE, but then said operators could in principle
> also
> > get CA-issued certs.
> >
> > DNS entries in your own zone have cost nothing. PKIX certificates are
> > expensive, especially because "*" is prohibitively more expensive.
>
> This is not what I have found.  Since my DNS entries are maintained by a
> 3rd
> party company they charge me for every DNS entry change that I want to
> make.


Such considerations are in any case a poor basis for making protocol design
decisions. Prices change in response to market conditions.

Back in the day two companies decided that the cost of using a US telephone
in London was so exorbitant that they would make a fortune out of a network
of geodesic satellites allowing someone to make a call from anywhere using
the same phone. By the time the service launched the mobile carriers had
dropped their prices and a phone now worked in 95% of the places people
wanted to use one and few saw the value in paying $5/min for the rest.

DNSSEC is going to cost registrars money to deploy so people should not
expect it to be cost free.


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

--20cf3071cfae1925d704a177fd80
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Thu, Apr 21, 2011 at 8:47 PM, Jim Sch=
aad <span dir=3D"ltr">&lt;<a href=3D"mailto:[e-mail]">ietf@au=
gustcellars.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
<br>
&gt; -----Original Message-----<br>
&gt; From: <a href=3D"mailto:[e-mail]">[e-mail]</=
a> [mailto:<a href=3D"mailto:[e-mail]">[e-mail]</=
a>] On Behalf Of<br>
&gt; Paul Wouters<br>
&gt; Sent: Wednesday, April 20, 2011 7:38 PM<br>
&gt; To: Eric Rescorla<br>
&gt; Cc: <a href=3D"mailto:[e-mail]">[e-mail]</a><br>
&gt; Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt<br>
<div class=3D"im">&gt;<br>
&gt; On Wed, 20 Apr 2011, Eric Rescorla wrote:<br>
&gt;<br>
&gt; &gt;&gt; The largest use case (by number) is to not use any CA/PKIX, a=
nd to<br>
&gt; &gt;&gt; phase out all current warnings from browsers about self signe=
d certs<br>
&gt; &gt;&gt; using dane authenticated certificates.<br>
&gt; &gt;<br>
&gt; &gt; It&#39;s not clear to me that this is a valid inference.<br>
&gt; &gt;<br>
&gt; &gt; Yes, it&#39;s true that there are a large number of self-signed<b=
r>
&gt; &gt; certificates in use, and that the operators deploying those certs=
<br>
&gt; &gt; could in principle use DANE, but then said operators could in pri=
nciple<br>
also<br>
&gt; get CA-issued certs.<br>
&gt;<br>
&gt; DNS entries in your own zone have cost nothing. PKIX certificates are<=
br>
&gt; expensive, especially because &quot;*&quot; is prohibitively more expe=
nsive.<br>
<br>
</div>This is not what I have found. =A0Since my DNS entries are maintained=
 by a 3rd<br>
party company they charge me for every DNS entry change that I want to make=
.</blockquote><div><br></div><div>Such considerations are in any case a poo=
r basis for making protocol design decisions. Prices change in response to =
market conditions.</div>
<div><br></div><div>Back in the day two companies decided that the cost of =
using a US telephone in London was so exorbitant that they would make a for=
tune out of a network of geodesic satellites allowing someone to make a cal=
l from anywhere using the same phone. By the time the service launched the =
mobile carriers had dropped their prices and a phone now worked in 95% of t=
he places people wanted to use one and few saw the value in paying $5/min f=
or the rest.</div>
<div><br></div><div>DNSSEC is going to cost registrars money to deploy so p=
eople should not expect it to be cost free.</div><div><br></div></div><br>-=
- <br>Website: <a href=3D"http://hallambaker.com/">http://hallambaker.com/<=
/a><br>
<br>

--20cf3071cfae1925d704a177fd80--

From [e-mail]  Thu Apr 21 19:49:24 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CB1B3E0793 for <[e-mail]>; Thu, 21 Apr 2011 19:49:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.531
X-Spam-Level: 
X-Spam-Status: No, score=-3.531 tagged_above=-999 required=5 tests=[AWL=0.068,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDRd+NPRx-QU for <[e-mail]>; Thu, 21 Apr 2011 19:49:23 -0700 (PDT)
Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfc.amsl.com (Postfix) with ESMTP id C8E8CE0790 for <[e-mail]>; Thu, 21 Apr 2011 19:49:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=[e-mail]; q=dns/txt; s=uoa; t=1303440563; x=1334976563; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20<[e-mail]> |To:=[e-mail]|Subject:=20Re:=20[dane]=20I-D=20Actio n:draft-ietf-dane-use-cases-00.txt|Cc:=[e-mail] |In-Reply-To:=20<[e-mail].s ap.corp>|Message-Id:=20<[e-mail] kland.ac.nz>|Date:=20Fri,=2022=20Apr=202011=2014:49:19=20 +1200; bh=S8MOHiwhhRfaCMAPzNoBvdpA11j8iNk9vKOPadTDdro=; b=XVIlSjSgolKAzYJjVskpz/LP7Eg43Fevlmf4NlEfBgv49KOOzo998SkU 9py0T65bv+z+A02OO73tWiL87IWtiphs7kAT8g3tuyAESseMzcQYcCWp6 QbyuUiyHx5rFfecuqRlXgAK/10tM2r6etuf1t0tkSZ4D5bwo5c6wj27eb 4=;
X-IronPort-AV: E=Sophos;i="4.64,252,1301832000"; d="scan'208";a="57827884"
X-Ironport-HAT: APP-SERVERS - $RELAYED
X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing
Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 22 Apr 2011 14:49:19 +1200
Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <[e-mail]>) id 1QD6Qp-00049l-IM; Fri, 22 Apr 2011 14:49:19 +1200
Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from <[e-mail]>) id 1QD6Qp-00046A-Kz; Fri, 22 Apr 2011 14:49:19 +1200
From: Peter Gutmann <[e-mail]>
To: [e-mail]
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Date: Fri, 22 Apr 2011 14:49:19 +1200
Cc: [e-mail]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 22 Apr 2011 02:49:25 -0000

Martin Rex <[e-mail]> writes:

>So I had to resort using an older firefox browser to be able to authenticate
>(and not have to wait until my trouble ticket was processed and that
>particular network component updated with a new cert).

Are there any browser extensions that deal with this braindamage?  Since it's
a capative portal (and presumably a non-publicly-visible device) Perspectives
can't help, and Certificate Patrol will warn of expired certs/changes but not
allow you to override false-positive ones.  Is there anything else?

(Anecdote about broken certificate handling in browsers: There's a web forum
that I participate in that has a slight mismatch between the cert issued and
the domain name.  Every single time I go there Firefox does the usual scary-
warning-dance, and a few seconds later Perspectives leaps in and swats aside
the false alarm saying "This is nonsense, the cert has been in use for this
site forever, continuing anyway".  So every single day I get reminded that
this is just broken security theatre that hampers rather than helps.

OK, so I could permanently trust the cert, but I get a modest degree of
satisfaction out of seeing the "This nonsensical error removed by
Perspectives" message that pops up :-).

Peter.


From [e-mail]  Fri Apr 22 04:23:00 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5D2F5E0696 for <[e-mail]>; Fri, 22 Apr 2011 04:23:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.517
X-Spam-Level: 
X-Spam-Status: No, score=-0.517 tagged_above=-999 required=5 tests=[AWL=-1.215, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vmq1eqIhb4P8 for <[e-mail]>; Fri, 22 Apr 2011 04:22:59 -0700 (PDT)
Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfc.amsl.com (Postfix) with ESMTP id 56979E0688 for <[e-mail]>; Fri, 22 Apr 2011 04:22:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:references:in-reply-to:mime-version:content-transfer-encoding: content-type:message-id:cc:x-mailer:from:subject:date:to; bh=TjN5MCe0xsWHlnXjGEmHhdKE6g8rCYS9oJexqtaKBww=; b=OoIpcemEPPFQ+S/CglSEb8OdbzkuXSoMaAy+6ymf1vw2P8EPFA2faC23kj7OVQfJO/QiI253qqFyV JlMubrbjqHRRBKIuU2zqq41lKW8vYi0kifbjaTbg2tXgxwFt3ert4OF4P1qFRIBsbStvaKYui/XdfD hbN9rUzjnzjfdXyI=
Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Fri, 22 Apr 2011 13:22:56 +0200 (CEST)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <BANLkTi=BT=nrUfkNXQ15GkoJSzsFPJj=[e-mail]> <[e-mail]> <009901cc0086$eba860c0$c2f92240$@augustcellars.com> <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0 (iPad Mail 8H7)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=us-ascii
Message-Id: <[e-mail]>
X-Mailer: iPad Mail (8H7)
From: Jakob Schlyter <[e-mail]>
Date: Fri, 22 Apr 2011 13:22:59 +0200
To: Phillip Hallam-Baker <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 22 Apr 2011 11:23:00 -0000

22 apr 2011 kl. 03:43 skrev Phillip Hallam-Baker <[e-mail]>:

> DNSSEC is going to cost registrars money to deploy so people should not ex=
pect it to be cost free.

I believe many registrars offering DNS services will choose to just add DNSS=
EC for free in order to keep it's customers. Just implementing a low assuran=
ce DNSSEC service for all its domains is less expensive and easier to operat=
e, than adding opt-in/out and the additional charging. Implementing high ass=
urance (e.g. using HSM) DNSSEC will most likely cost more.=20

  Jakob


From [e-mail]  Fri Apr 22 05:22:10 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 02E46E06FF for <[e-mail]>; Fri, 22 Apr 2011 05:22:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.271
X-Spam-Level: 
X-Spam-Status: No, score=-3.271 tagged_above=-999 required=5 tests=[AWL=0.327,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5bHzXFzRtfMn for <[e-mail]>; Fri, 22 Apr 2011 05:22:09 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id 04C1DE0694 for <[e-mail]>; Fri, 22 Apr 2011 05:22:08 -0700 (PDT)
Received: by vws12 with SMTP id 12so515552vws.31 for <[e-mail]>; Fri, 22 Apr 2011 05:22:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ZaoVMHI3CIOzo5sDd9kh4EipQRcC4RPqGLEv4rw2l8E=; b=OOsjRAcyP6XyAN2qEKO3leSIel5eVTow8DdlH6VtCwvWbEp6yG9qDE9PknskEPK0iu 6kGUzKJyQKfLZcFGU9Sbxzqu6Wa9WvxcTl3aby8QdKR76SC+au3NjDD7+hphDwB4cAkV bAHrRpW+hV8168M/umdPCgOIngSDkqR8lrfoA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=EQDghI6yGJJZgbMahA4CT+YkW8Xn0CD2uTGPD6ZlQbdAiwoijwG2QFlJDyRUyhCn5b 7qDQSlEoYz+oXbR0cls0hwslYQxgWBKFhtN+/kAAcn6rqZNx4kzWjtY6lglaOqJuseeF qdmA/h/VxUfomETWo2r2wpn5D/Rv2aZwo7amg=
MIME-Version: 1.0
Received: by 10.52.77.70 with SMTP id q6mr1604105vdw.165.1303474928642; Fri, 22 Apr 2011 05:22:08 -0700 (PDT)
Received: by 10.52.161.3 with HTTP; Fri, 22 Apr 2011 05:22:08 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <BANLkTi=BT=nrUfkNXQ15GkoJSzsFPJj=[e-mail]> <[e-mail]> <009901cc0086$eba860c0$c2f92240$@augustcellars.com> <[e-mail]> <[e-mail]>
Date: Fri, 22 Apr 2011 08:22:08 -0400
Message-ID: <[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: Jakob Schlyter <[e-mail]>
Content-Type: multipart/alternative; boundary=20cf3071cfae186bf904a180e841
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 22 Apr 2011 12:22:10 -0000

--20cf3071cfae186bf904a180e841
Content-Type: text/plain; charset=ISO-8859-1

I remember back in 2001 when certain people argued that registrars would
deploy DNSSEC to compete irrespective of whether the spec was changed to
make deployment economically feasible. that didn't work out so well.

Email costs next to nothing to provide, so does Web hosting, so do most of
the services ISPs provide. And not coincidentally, the cost of hosting
services are next to nothing.

But they are not zero.


There sare good reasons for working on DANE, but saving money on existing
security measures is not one of them. Promiscuous security, Pinning,
Security Policy, Web Services are all important and useful use cases.


On Fri, Apr 22, 2011 at 7:22 AM, Jakob Schlyter <[e-mail]> wrote:

> 22 apr 2011 kl. 03:43 skrev Phillip Hallam-Baker <[e-mail]>:
>
> > DNSSEC is going to cost registrars money to deploy so people should not
> expect it to be cost free.
>
> I believe many registrars offering DNS services will choose to just add
> DNSSEC for free in order to keep it's customers. Just implementing a low
> assurance DNSSEC service for all its domains is less expensive and easier to
> operate, than adding opt-in/out and the additional charging. Implementing
> high assurance (e.g. using HSM) DNSSEC will most likely cost more.
>
>  Jakob
>
>


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

--20cf3071cfae186bf904a180e841
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I remember back in 2001 when certain people argued that registrars would de=
ploy DNSSEC to compete irrespective of whether the spec was changed to make=
 deployment economically feasible. that didn&#39;t work out so well.<div>
<br></div><div>Email costs next to nothing to provide, so does Web hosting,=
 so do most of the services ISPs provide. And not coincidentally, the cost =
of hosting services are next to nothing.</div><div><br></div><div>But they =
are not zero.</div>
<div><br></div><div><br></div><div>There sare good reasons for working on D=
ANE, but saving money on existing security measures is not one of them. Pro=
miscuous security, Pinning, Security Policy, Web Services are all important=
 and useful use cases.</div>
<div><br></div><div><br><div class=3D"gmail_quote">On Fri, Apr 22, 2011 at =
7:22 AM, Jakob Schlyter <span dir=3D"ltr">&lt;<a href=3D"mailto:jakob@kirei=
.se">[e-mail]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;=
">
22 apr 2011 kl. 03:43 skrev Phillip Hallam-Baker &lt;<a href=3D"mailto:hall=
[e-mail]">[e-mail]</a>&gt;:<br>
<div class=3D"im"><br>
&gt; DNSSEC is going to cost registrars money to deploy so people should no=
t expect it to be cost free.<br>
<br>
</div>I believe many registrars offering DNS services will choose to just a=
dd DNSSEC for free in order to keep it&#39;s customers. Just implementing a=
 low assurance DNSSEC service for all its domains is less expensive and eas=
ier to operate, than adding opt-in/out and the additional charging. Impleme=
nting high assurance (e.g. using HSM) DNSSEC will most likely cost more.<br=
>

<font color=3D"#888888"><br>
 =A0Jakob<br>
<br>
</font></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a href=
=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--20cf3071cfae186bf904a180e841--

From [e-mail]  Fri Apr 22 05:32:03 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 13E61E06FE for <[e-mail]>; Fri, 22 Apr 2011 05:32:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Wj8+jRVelf3 for <[e-mail]>; Fri, 22 Apr 2011 05:32:02 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfc.amsl.com (Postfix) with ESMTP id 324DEE06C8 for <[e-mail]>; Fri, 22 Apr 2011 05:32:02 -0700 (PDT)
Received: from ros-dhcp192-1-51-22.bbn.com ([192.1.51.22]:50048) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from <[e-mail]>) id 1QDFWi-0006Kf-N2 for [e-mail]; Fri, 22 Apr 2011 08:32:01 -0400
From: "Richard L. Barnes" <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Fri, 22 Apr 2011 08:32:00 -0400
References: <[e-mail]>
To: [e-mail]
Message-Id: <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v1082)
X-Mailer: Apple Mail (2.1082)
Subject: [dane] Fwd: New Version Notification for draft-ietf-dane-use-cases-01
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 22 Apr 2011 12:32:03 -0000

This is an updated version of the use cases draft, which incorporates =
feedback on -00 and makes several editorial changes.  Diff is here:
<http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-dane-use-cases-01.txt>

Chairs: I believe this version is ready for WGLC.

--Richard




Begin forwarded message:

> From: IETF I-D Submission Tool <[e-mail]>
> Date: April 22, 2011 8:30:04 AM EDT
> To: [e-mail]
> Subject: New Version Notification for draft-ietf-dane-use-cases-01=20
>=20
>=20
> A new version of I-D, draft-ietf-dane-use-cases-01.txt has been =
successfully submitted by Richard Barnes and posted to the IETF =
repository.
>=20
> Filename:	 draft-ietf-dane-use-cases
> Revision:	 01
> Title:		 Use Cases and Requirements for DNS-based =
Authentication of Named Entities (DANE)
> Creation_date:	 2011-04-22
> WG ID:		 dane
> Number_of_pages: 9
>=20
> Abstract:
> Many current applications use the certificate-based authentication
> features in TLS to allow clients to verify that a connected server
> properly represents a desired domain name.  Traditionally, this
> authentication has been based on PKIX trust hierarchies, rooted in
> well-known CAs, but additional information can be provided via the
> DNS itself.  This document describes a set of use cases in which the
> DNS and DNSSEC could be used to make assertions that support the TLS
> authentication process.
>=20
>=20
>=20
> The IETF Secretariat.
>=20
>=20


From [e-mail]  Fri Apr 22 05:45:03 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D6E90E06CC; Fri, 22 Apr 2011 05:45:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.418
X-Spam-Level: 
X-Spam-Status: No, score=-103.418 tagged_above=-999 required=5 tests=[AWL=-0.819, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id au1ni9FG+C5N; Fri, 22 Apr 2011 05:45:03 -0700 (PDT)
Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0E6ABE067C; Fri, 22 Apr 2011 05:45:03 -0700 (PDT)
MIME-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
From: [e-mail]
To: [e-mail]
X-Test-IDTracker: no
X-IETF-IDTracker: 3.52
Message-ID: <[e-mail]>
Date: Fri, 22 Apr 2011 05:45:03 -0700
Cc: [e-mail]
Subject: [dane] I-D Action:draft-ietf-dane-use-cases-01.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 22 Apr 2011 12:45:04 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF.


	Title           : Use Cases and Requirements for DNS-based Authentication of Named Entities (DANE)
	Author(s)       : R. Barnes
	Filename        : draft-ietf-dane-use-cases-01.txt
	Pages           : 9
	Date            : 2011-04-22

Many current applications use the certificate-based authentication
features in TLS to allow clients to verify that a connected server
properly represents a desired domain name.  Traditionally, this
authentication has been based on PKIX trust hierarchies, rooted in
well-known CAs, but additional information can be provided via the
DNS itself.  This document describes a set of use cases in which the
DNS and DNSSEC could be used to make assertions that support the TLS
authentication process.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dane-use-cases-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body; name="draft-ietf-dane-use-cases-01.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[e-mail]>


--NextPart--

From [e-mail]  Fri Apr 22 05:49:15 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8B4AEE06CC for <[e-mail]>; Fri, 22 Apr 2011 05:49:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.778
X-Spam-Level: 
X-Spam-Status: No, score=-2.778 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vc4TIEmuJUCH for <[e-mail]>; Fri, 22 Apr 2011 05:49:14 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfc.amsl.com (Postfix) with ESMTP id 68046E0698 for <[e-mail]>; Fri, 22 Apr 2011 05:49:14 -0700 (PDT)
Received: by vxg33 with SMTP id 33so538095vxg.31 for <[e-mail]>; Fri, 22 Apr 2011 05:49:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BbIJ4suKaGfgo3N6+hsb5tYVSkAhhEPVNVA5AFooO9M=; b=a4xzZbjbYjEoQVS88HdWLc2hzqncVzovIWOvmE5DRKdEhX6ZBHTuOoIf/1353DAdZj PU4mN4IxNdgJCtKy3aphr7sPfsZVBA7mRM7NdTd1c99fv0riFUC9qSmfGFuRPg6zWe3N OC3YXBgFTQQW6e5PhD2hifvb9mNhaWrTwtnHI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=FnfP911a0KlgTtfZo0sYbKs/kuuTlaPt4L2bNlVVUxWSjE9cY39KRtwICwl0EKQVlL TzLx5ZRU15+WuY6wx0T3DpXWrtPRCBeMv4OaxwgkJVLEWZKU366F1z3NRMczptmEVXPl Zsq4W1yduZT2bphRGE7CfFEQdGWbPkmf4ACcY=
MIME-Version: 1.0
Received: by 10.52.0.136 with SMTP id 8mr1703974vde.45.1303476553838; Fri, 22 Apr 2011 05:49:13 -0700 (PDT)
Received: by 10.52.161.3 with HTTP; Fri, 22 Apr 2011 05:49:13 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Fri, 22 Apr 2011 08:49:13 -0400
Message-ID: <[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: "Richard L. Barnes" <[e-mail]>
Content-Type: multipart/alternative; boundary=20cf304346f4f6f09b04a181483f
Cc: [e-mail]
Subject: Re: [dane] Fwd: New Version Notification for draft-ietf-dane-use-cases-01
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 22 Apr 2011 12:49:15 -0000

--20cf304346f4f6f09b04a181483f
Content-Type: text/plain; charset=ISO-8859-1

I do not think it is ready.

There is a section titled 'other requirements', but the preceding sections
are titled 'use cases'. A use case is not a requirement. A use case is what
the set of requirements is deduced from

I think that Promiscuous Security and Web Services support should be added
to the use cases. TLS is used for much more than just Web Browsing and the
non-Web browsing use cases are rather more important in my view.


The section 'other requirements' appears to be mostly specifying
constraints, though they are stated as requirements.

One very important constraint is the need to support mechanisms for protocol
discovery that do not rely on port numbers.

Since we are running out of port numbers, this is an essential requirement.

The necessary text can be found in:
http://tools.ietf.org/html/draft-hallambaker-dane-requirements-01


As a matter of style, the ESA format that has the requirements tagged with a
reference number (e.g. [U-S-TRUST]) makes it easier to refer to the
requirements when determining if a proposal meets them.



On Fri, Apr 22, 2011 at 8:32 AM, Richard L. Barnes <[e-mail]> wrote:

> This is an updated version of the use cases draft, which incorporates
> feedback on -00 and makes several editorial changes.  Diff is here:
> <http://tools.ietf.org/rfcdiff?url2=draft-ietf-dane-use-cases-01.txt>
>
> Chairs: I believe this version is ready for WGLC.
>
> --Richard
>
>
>
>
> Begin forwarded message:
>
> > From: IETF I-D Submission Tool <[e-mail]>
> > Date: April 22, 2011 8:30:04 AM EDT
> > To: [e-mail]
> > Subject: New Version Notification for draft-ietf-dane-use-cases-01
> >
> >
> > A new version of I-D, draft-ietf-dane-use-cases-01.txt has been
> successfully submitted by Richard Barnes and posted to the IETF repository.
> >
> > Filename:      draft-ietf-dane-use-cases
> > Revision:      01
> > Title:                 Use Cases and Requirements for DNS-based
> Authentication of Named Entities (DANE)
> > Creation_date:         2011-04-22
> > WG ID:                 dane
> > Number_of_pages: 9
> >
> > Abstract:
> > Many current applications use the certificate-based authentication
> > features in TLS to allow clients to verify that a connected server
> > properly represents a desired domain name.  Traditionally, this
> > authentication has been based on PKIX trust hierarchies, rooted in
> > well-known CAs, but additional information can be provided via the
> > DNS itself.  This document describes a set of use cases in which the
> > DNS and DNSSEC could be used to make assertions that support the TLS
> > authentication process.
> >
> >
> >
> > The IETF Secretariat.
> >
> >
>
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane
>



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

--20cf304346f4f6f09b04a181483f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I do not think it is ready.<div><br></div><div>There is a section titled &#=
39;other requirements&#39;, but the preceding sections are titled &#39;use =
cases&#39;. A use case is not a requirement. A use case is what the set of =
requirements is deduced from</div>
<div><br></div><div>I think that Promiscuous Security and Web Services supp=
ort should be added to the use cases. TLS is used for much more than just W=
eb Browsing and the non-Web browsing use cases are rather more important in=
 my view.</div>
<div><br></div><div><br></div><div>The section &#39;other requirements&#39;=
 appears to be mostly specifying constraints, though they are stated as req=
uirements.=A0</div><div><br></div><div>One very important constraint is the=
 need to support mechanisms for protocol discovery that do not rely on port=
 numbers.</div>
<div><br>Since we are running out of port numbers, this is an essential req=
uirement.</div><div><br></div><div><meta charset=3D"utf-8"><div>The necessa=
ry text can be found in:</div><div><a href=3D"http://tools.ietf.org/html/dr=
aft-hallambaker-dane-requirements-01">http://tools.ietf.org/html/draft-hall=
ambaker-dane-requirements-01</a></div>
</div><div><br></div><div><br></div><div>As a matter of style, the ESA form=
at that has the requirements tagged with a reference number (e.g.=A0<span c=
lass=3D"Apple-style-span" style=3D"font-family: monospace; font-size: 16px;=
 white-space: pre; ">[<a name=3D"ref-U-S-TRUST" id=3D"ref-U-S-TRUST">U-S-TR=
UST</a>]</span>) makes it easier to refer to the requirements when determin=
ing if a proposal meets them.</div>
<div><br></div><div><br></div><div><br><div class=3D"gmail_quote">On Fri, A=
pr 22, 2011 at 8:32 AM, Richard L. Barnes <span dir=3D"ltr">&lt;<a href=3D"=
mailto:[e-mail]">[e-mail]</a>&gt;</span> wrote:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex;">
This is an updated version of the use cases draft, which incorporates feedb=
ack on -00 and makes several editorial changes. =A0Diff is here:<br>
&lt;<a href=3D"http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-dane-use-cas=
es-01.txt" target=3D"_blank">http://tools.ietf.org/rfcdiff?url2=3Ddraft-iet=
f-dane-use-cases-01.txt</a>&gt;<br>
<br>
Chairs: I believe this version is ready for WGLC.<br>
<br>
--Richard<br>
<br>
<br>
<br>
<br>
Begin forwarded message:<br>
<br>
&gt; From: IETF I-D Submission Tool &lt;<a href=3D"mailto:idsubmission@ietf=
.org">[e-mail]</a>&gt;<br>
&gt; Date: April 22, 2011 8:30:04 AM EDT<br>
&gt; To: <a href=3D"mailto:[e-mail]">[e-mail]</a><br>
&gt; Subject: New Version Notification for draft-ietf-dane-use-cases-01<br>
&gt;<br>
&gt;<br>
&gt; A new version of I-D, draft-ietf-dane-use-cases-01.txt has been succes=
sfully submitted by Richard Barnes and posted to the IETF repository.<br>
&gt;<br>
&gt; Filename: =A0 =A0 =A0draft-ietf-dane-use-cases<br>
&gt; Revision: =A0 =A0 =A001<br>
&gt; Title: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Use Cases and Requirements for =
DNS-based Authentication of Named Entities (DANE)<br>
&gt; Creation_date: =A0 =A0 =A0 =A0 2011-04-22<br>
&gt; WG ID: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 dane<br>
&gt; Number_of_pages: 9<br>
&gt;<br>
&gt; Abstract:<br>
&gt; Many current applications use the certificate-based authentication<br>
&gt; features in TLS to allow clients to verify that a connected server<br>
&gt; properly represents a desired domain name. =A0Traditionally, this<br>
&gt; authentication has been based on PKIX trust hierarchies, rooted in<br>
&gt; well-known CAs, but additional information can be provided via the<br>
&gt; DNS itself. =A0This document describes a set of use cases in which the=
<br>
&gt; DNS and DNSSEC could be used to make assertions that support the TLS<b=
r>
&gt; authentication process.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; The IETF Secretariat.<br>
&gt;<br>
&gt;<br>
<br>
_______________________________________________<br>
dane mailing list<br>
<a href=3D"mailto:[e-mail]">[e-mail]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/dane</a><br>
</blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a href=3D"htt=
p://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--20cf304346f4f6f09b04a181483f--

From [e-mail]  Fri Apr 22 06:01:57 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3E6E5E0698 for <[e-mail]>; Fri, 22 Apr 2011 06:01:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ooaV2Gyiq82a for <[e-mail]>; Fri, 22 Apr 2011 06:01:56 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfc.amsl.com (Postfix) with ESMTP id 5E053E067C for <[e-mail]>; Fri, 22 Apr 2011 06:01:56 -0700 (PDT)
Received: from ros-dhcp192-1-51-22.bbn.com ([192.1.51.22]:50851) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from <[e-mail]>) id 1QDFzf-0006fS-WB; Fri, 22 Apr 2011 09:01:56 -0400
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: "Richard L. Barnes" <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Fri, 22 Apr 2011 09:01:55 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
To: Phillip Hallam-Baker <[e-mail]>
X-Mailer: Apple Mail (2.1082)
Cc: [e-mail]
Subject: Re: [dane] Fwd: New Version Notification for draft-ietf-dane-use-cases-01
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 22 Apr 2011 13:01:57 -0000

> I think that Promiscuous Security and Web Services support should be =
added to the use cases. TLS is used for much more than just Web Browsing =
and the non-Web browsing use cases are rather more important in my view.

The use cases as described are in no way specific to web browsing.  They =
apply generally to applications using TLS that require authentication of =
domain names.  In any case, I do not see use cases titled "Promiscuous =
Security" or "Web Services" in draft-hallambaker-dane-requirements, so =
please propose text.


> One very important constraint is the need to support mechanisms for =
protocol discovery that do not rely on port numbers.

Protocol discovery is not in scope, not least because it varies from one =
application to another.  The use cases described apply equally well to =
dual-port (dedicated TLS port) and STARTTLS design patterns.  Indeed, =
examples of both are referenced in the introduction.

Key/cert discovery is in scope, but that does not have anything to do =
with port exhaustion.  The question there is whether a client can =
disambiguate services on different ports.


> As a matter of style, the ESA format that has the requirements tagged =
with a reference number (e.g. [U-S-TRUST]) makes it easier to refer to =
the requirements when determining if a proposal meets them.

I think we have few enough requirements here that there's not a need for =
a formalism.

--Richard





>=20
>=20
> On Fri, Apr 22, 2011 at 8:32 AM, Richard L. Barnes <[e-mail]> =
wrote:
> This is an updated version of the use cases draft, which incorporates =
feedback on -00 and makes several editorial changes.  Diff is here:
> <http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-dane-use-cases-01.txt>
>=20
> Chairs: I believe this version is ready for WGLC.
>=20
> --Richard
>=20
>=20
>=20
>=20
> Begin forwarded message:
>=20
> > From: IETF I-D Submission Tool <[e-mail]>
> > Date: April 22, 2011 8:30:04 AM EDT
> > To: [e-mail]
> > Subject: New Version Notification for draft-ietf-dane-use-cases-01
> >
> >
> > A new version of I-D, draft-ietf-dane-use-cases-01.txt has been =
successfully submitted by Richard Barnes and posted to the IETF =
repository.
> >
> > Filename:      draft-ietf-dane-use-cases
> > Revision:      01
> > Title:                 Use Cases and Requirements for DNS-based =
Authentication of Named Entities (DANE)
> > Creation_date:         2011-04-22
> > WG ID:                 dane
> > Number_of_pages: 9
> >
> > Abstract:
> > Many current applications use the certificate-based authentication
> > features in TLS to allow clients to verify that a connected server
> > properly represents a desired domain name.  Traditionally, this
> > authentication has been based on PKIX trust hierarchies, rooted in
> > well-known CAs, but additional information can be provided via the
> > DNS itself.  This document describes a set of use cases in which the
> > DNS and DNSSEC could be used to make assertions that support the TLS
> > authentication process.
> >
> >
> >
> > The IETF Secretariat.
> >
> >
>=20
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane
>=20
>=20
>=20
> --=20
> Website: http://hallambaker.com/
>=20


From [e-mail]  Fri Apr 22 06:14:58 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 017B5E071D for <[e-mail]>; Fri, 22 Apr 2011 06:14:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.45
X-Spam-Level: 
X-Spam-Status: No, score=-1.45 tagged_above=-999 required=5 tests=[AWL=0.250,  BAYES_00=-2.599, J_CHICKENPOX_46=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XUl7fdx97mL for <[e-mail]>; Fri, 22 Apr 2011 06:14:57 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfc.amsl.com (Postfix) with ESMTP id C0663E06FD for <[e-mail]>; Fri, 22 Apr 2011 06:14:56 -0700 (PDT)
Received: from anna-filinova.office.nic.cz (unknown [IPv6:2001:1488:ac14:1400:66b9:e8ff:febb:c1d6]) by mail.nic.cz (Postfix) with ESMTPSA id EE5582A283E for <[e-mail]>; Fri, 22 Apr 2011 15:14:55 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1303478096; bh=YHG7pZimvY17u7JHqIN24ceydNlX0EFSLneApGFZrm0=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=MLM8/NaJkket2rdhggUxYP3NpuiwxEv1pYKEnNLIN9UoZD/7QtIz2wAOPeCytetj4 ElOXlbWN96Q/4PA13JVJdMuzcfw38g3l4PKBX0rvQ4C7XI9asM45r0JfTMypn9pAWX xov/aF2IhVV5raJfbKD70C81g0UA3F5OjamHupYo=
Message-ID: <[e-mail]>
Date: Fri, 22 Apr 2011 15:14:55 +0200
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[e-mail]>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: [e-mail]
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<BANLkTi=BT=nrUfkNXQ15GkoJSzsFPJj=[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.96.5 at mail
X-Virus-Status: Clean
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 22 Apr 2011 13:14:58 -0000

On 4/21/11 6:41 AM, Phillip Hallam-Baker wrote:
>
>
> On Thu, Apr 21, 2011 at 12:14 AM, Eric Rescorla <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     On Wed, Apr 20, 2011 at 7:54 PM, Paul Wouters <[e-mail]
>     <mailto:[e-mail]>> wrote:
>      > On Wed, 20 Apr 2011, Eric Rescorla wrote:
>      >
>      >>>> Yes, it's true that there are a large number of self-signed
>     certificates
>      >>>> in use,
>      >>>> and that the operators deploying those certs could in
>     principle use
>      >>>> DANE, but
>      >>>> then said operators could in principle also get CA-issued certs.
>      >>>
>      >>> DNS entries in your own zone have cost nothing. PKIX
>     certificates are
>      >>> expensive,
>      >>> especially because "*" is prohibitively more expensive.
>      >>
>      >> On the other hand pkix certs work for basically any browser whereas
>      >> currently Dane-based auth works with approximately no browsers
>     now and far
>      >> will work for far  less than all for quite some time.
>      >
>      > I'm not quite following the logic of "since we didn't finish the
>     standard
>      > yet, no one is using it" argument.
>
>     That's not my argument.
>
>     You said that the most important use case by volume is people using
>     self-signed
>     certs and backing them via DANE. But the value of DANE to the server
>     operator
>     in that case is primarily in suppressing warnings at the user's
>     browser. What I
>     said is that operators who care about suppressing that warning could get
>     much more effective warning suppression now and for the foreseeable
>     future
>     by getting a standard CA certificate. So given that they have not
>     chosen to do so,
>     I don't think it's obvious that a large number of those operators
>     will choose to
>     serve DNSSEC-based DANE certificates at some point in the future.
>
>     I agree it's not that particularly important to decide what the most
>     important
>     use cases are, but I merely wanted to observe that I didn't think
>     that it was
>     in fact obvious that this was the most important use case.
>
>     -Ekr
>     _______________________________________________
>     dane mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/dane
>
>
> I think this is best set out in use case form:
>
> Use Case: Alice wants to set up Web site so that Bob can connect without
> Mallet or Eve intercepting messages. Bob has a Dane capable browser
>
> Constraint 1: Carol does not want to upgrade her browser, her user
> experience MUST NOT be negatively impacted.
> Constraint 2: Alice is not willing to pay for a CA issued cert (or
> alternatively does not want to apply for one)
>
> DANE does not provide a solution to this use case under these
> constraints by itself.
>
> DANE+HASTLS does provide a solution however. When Carol accesses the
> site using her obsolete browser, it does not support the HASTLS
> mechanism and thus does not know to try TLS and thus does not issue
> nuisance warnings.
>
>
> This si the reason that I have been arguing that HASTLS type
> requirements and Key publication requirements have to be considered
> together from the very start.
>
> Trying to propose a different way for people to do what they can do
> already that is not backwards compatible is a futile waste of time.
>
> The compelling use cases for putting keys in the DNS are to provide
> additional security controls for CA issued certs (as CAA does), to
> enable promiscuous security and to provide keys for Internet protocols
> that use TLS but are not encumbered by a legacy base.
>
> There is a reason that I have spent so much time ensuring that my
> proposal works correctly and consistently when SRV, NAPTR or URI type
> discovery mechanisms are used. It is because I believe that Web Services
> is the type of niche use case that can drive a standard like Dane to
> reach critical mass.

We have already discussed SRV in issue#1 and we the WG rejected the idea 
of using SRV.

> I can support the requirements of key issue restrictions, key
> publication and advertising security features offered in a single
> framework that is just as efficient as the current DANE proposal but
> does not have the limitations imposed by the limited scope the authors
> keep insisting on.
>
> Some people keep claiming that there is consensus for the current
> approach, but I don't see one in the WG.
>
>
> Why can't we choose the protocol architecture on the basis of the
> proposal that supports the widest range of use cases with the simplest
> mechanism and best objective performance metrics wins?

Anyway Phillip,

care to split your requirements into clear individual issues (as you see 
them)?  I'll log them into our issue tracker for reference, the mailing 
list is too crowded to keep track of anything.

Thanks,
O.

From [e-mail]  Fri Apr 22 06:19:22 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 29F75E0745 for <[e-mail]>; Fri, 22 Apr 2011 06:19:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.778
X-Spam-Level: 
X-Spam-Status: No, score=-1.778 tagged_above=-999 required=5 tests=[AWL=0.522,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UbM-5uigOO9I for <[e-mail]>; Fri, 22 Apr 2011 06:19:21 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfc.amsl.com (Postfix) with ESMTP id 7D5C0E071A for <[e-mail]>; Fri, 22 Apr 2011 06:19:21 -0700 (PDT)
Received: from anna-filinova.office.nic.cz (unknown [IPv6:2001:1488:ac14:1400:66b9:e8ff:febb:c1d6]) by mail.nic.cz (Postfix) with ESMTPSA id 0443F2A283D for <[e-mail]>; Fri, 22 Apr 2011 15:19:21 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1303478361; bh=e3+3A3zrUFnfF/hEK/jnXoFQDyIVj/7HMfwdUEOlpsM=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=bcyN1HZ2InswtJuPmNTG9xZ1oE1vv/b+q2w4EZGO9VTJjrqxPLt7TBVqrPyE75Pjr u56EgBcC01W7FFu7gPnpAj7FAdPZ+E7Oap/mIZ/By45diBNkEokAJpCjyC+whxzkjr xMCfuMv3HOPA1Wb/k81AJ0BNVXXJeywiCO4lawbQ=
Message-ID: <[e-mail]>
Date: Fri, 22 Apr 2011 15:19:21 +0200
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[e-mail]>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: [e-mail]
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<BANLkTi=BT=nrUfkNXQ15GkoJSzsFPJj=[e-mail]>	<[e-mail]>	<009901cc0086$eba860c0$c2f92240$@augustcellars.com> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.96.5 at mail
X-Virus-Status: Clean
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 22 Apr 2011 13:19:22 -0000

On 4/22/11 3:43 AM, Phillip Hallam-Baker wrote:
> DNSSEC is going to cost registrars money to deploy so people should
> not expect it to be cost free.

Speaking for .CZ which has highest DNSSEC penetration in the world
(122563/794330) - our DNSSEC registrars provide DNSSEC as free and those
two with highest number of DNSSEC provide it as default.

So lets stick to what you said earlier in the email:

> Such considerations are in any case a poor basis for making protocol
> design decisions.  Prices change in response to market conditions.

O.

From [e-mail]  Fri Apr 22 10:35:59 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0541AE06B0 for <[e-mail]>; Fri, 22 Apr 2011 10:35:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.203
X-Spam-Level: 
X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpVvK+u+qGRb for <[e-mail]>; Fri, 22 Apr 2011 10:35:58 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfc.amsl.com (Postfix) with ESMTP id EAFABE0655 for <[e-mail]>; Fri, 22 Apr 2011 10:35:57 -0700 (PDT)
Received: by iye19 with SMTP id 19so769353iye.31 for <[e-mail]>; Fri, 22 Apr 2011 10:35:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=Ib3ANw+PtSxk8l8RJz5+y3JKirhyYcqUSGIKfndT//w=; b=Ms4DblLGEcL9CwS8sMXycmUAd1LsJYQ6Do8wz+ZJwJfDG/Je9fE6NKHBvbfxeWv49e iYnSpTPctxBgyOiCgZkIuR182N1Ml+0VaVE3OujlwIVNoyKtBsENzYNz5cvem93uPn8W Eh0LOjeFPBEzfr7qhYMH9XeoUrdEhWEwn2AeY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=XfMIXg3wSGUr+viNoA0b1bTix+l8hg9uTbGFAkQBO7+rloFYvHx6JTB4JU7kTk0IeA JjkBR1PbsGT8rxhAnoUGN1ptrmDsrqmbCp1nydIj9UgGnmH57AXUmIG/DUJJRHOAulyj 5VNylwBwv7iuHgRWo8qbk3rxhTA30Ixl49e4g=
Received: by 10.231.47.130 with SMTP id n2mr957761ibf.152.1303493757512; Fri, 22 Apr 2011 10:35:57 -0700 (PDT)
Received: from [10.84.188.219] (mobile-166-137-137-011.mycingular.net [166.137.137.11]) by mx.google.com with ESMTPS id g16sm1193478ibb.37.2011.04.22.10.35.53 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Apr 2011 10:35:55 -0700 (PDT)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0 (iPhone Mail 8C148)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=us-ascii
Message-Id: <[e-mail]>
X-Mailer: iPhone Mail (8C148)
From: Phillip Hallam-Baker <[e-mail]>
Date: Fri, 22 Apr 2011 13:35:38 -0400
To: "Richard L. Barnes" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [dane] Fwd: New Version Notification for draft-ietf-dane-use-cases-01
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 22 Apr 2011 17:35:59 -0000

Working with the Internet architecture is in scope

Thus continuing to work with Ipv6 an without well known port discovery is in=
 scope

And in any case the point of this exercise is that the consensus in Prague w=
as that the wg had not shown   It is solving the right problem

Sent from my iPhone

On 22 Apr 2011, at 09:01, "Richard L. Barnes" <[e-mail]> wrote:

>> I think that Promiscuous Security and Web Services support should be adde=
d to the use cases. TLS is used for much more than just Web Browsing and the=
 non-Web browsing use cases are rather more important in my view.
>=20
> The use cases as described are in no way specific to web browsing.  They a=
pply generally to applications using TLS that require authentication of doma=
in names.  In any case, I do not see use cases titled "Promiscuous Security"=
 or "Web Services" in draft-hallambaker-dane-requirements, so please propose=
 text.
>=20
>=20
>> One very important constraint is the need to support mechanisms for proto=
col discovery that do not rely on port numbers.
>=20
> Protocol discovery is not in scope, not least because it varies from one a=
pplication to another.  The use cases described apply equally well to dual-p=
ort (dedicated TLS port) and STARTTLS design patterns.  Indeed, examples of b=
oth are referenced in the introduction.
>=20
> Key/cert discovery is in scope, but that does not have anything to do with=
 port exhaustion.  The question there is whether a client can disambiguate s=
ervices on different ports.
>=20
>=20
>> As a matter of style, the ESA format that has the requirements tagged wit=
h a reference number (e.g. [U-S-TRUST]) makes it easier to refer to the requ=
irements when determining if a proposal meets them.
>=20
> I think we have few enough requirements here that there's not a need for a=
 formalism.
>=20
> --Richard
>=20
>=20
>=20
>=20
>=20
>>=20
>>=20
>> On Fri, Apr 22, 2011 at 8:32 AM, Richard L. Barnes <[e-mail]> wrot=
e:
>> This is an updated version of the use cases draft, which incorporates fee=
dback on -00 and makes several editorial changes.  Diff is here:
>> <http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-dane-use-cases-01.txt>
>>=20
>> Chairs: I believe this version is ready for WGLC.
>>=20
>> --Richard
>>=20
>>=20
>>=20
>>=20
>> Begin forwarded message:
>>=20
>>> From: IETF I-D Submission Tool <[e-mail]>
>>> Date: April 22, 2011 8:30:04 AM EDT
>>> To: [e-mail]
>>> Subject: New Version Notification for draft-ietf-dane-use-cases-01
>>>=20
>>>=20
>>> A new version of I-D, draft-ietf-dane-use-cases-01.txt has been successf=
ully submitted by Richard Barnes and posted to the IETF repository.
>>>=20
>>> Filename:      draft-ietf-dane-use-cases
>>> Revision:      01
>>> Title:                 Use Cases and Requirements for DNS-based Authenti=
cation of Named Entities (DANE)
>>> Creation_date:         2011-04-22
>>> WG ID:                 dane
>>> Number_of_pages: 9
>>>=20
>>> Abstract:
>>> Many current applications use the certificate-based authentication
>>> features in TLS to allow clients to verify that a connected server
>>> properly represents a desired domain name.  Traditionally, this
>>> authentication has been based on PKIX trust hierarchies, rooted in
>>> well-known CAs, but additional information can be provided via the
>>> DNS itself.  This document describes a set of use cases in which the
>>> DNS and DNSSEC could be used to make assertions that support the TLS
>>> authentication process.
>>>=20
>>>=20
>>>=20
>>> The IETF Secretariat.
>>>=20
>>>=20
>>=20
>> _______________________________________________
>> dane mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dane
>>=20
>>=20
>>=20
>> --=20
>> Website: http://hallambaker.com/
>>=20
>=20

From [e-mail]  Fri Apr 22 10:54:55 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C1C49E065A for <[e-mail]>; Fri, 22 Apr 2011 10:54:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lj7vwaQfrTsx for <[e-mail]>; Fri, 22 Apr 2011 10:54:54 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfc.amsl.com (Postfix) with ESMTP id D4B3FE0611 for <[e-mail]>; Fri, 22 Apr 2011 10:54:54 -0700 (PDT)
Received: from ros-dhcp192-1-51-22.bbn.com ([192.1.51.22]:52828) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from <[e-mail]>) id 1QDKZC-0005bY-5r; Fri, 22 Apr 2011 13:54:54 -0400
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: "Richard L. Barnes" <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Fri, 22 Apr 2011 13:54:53 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
To: Phillip Hallam-Baker <[e-mail]>
X-Mailer: Apple Mail (2.1082)
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [dane] Fwd: New Version Notification for draft-ietf-dane-use-cases-01
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 22 Apr 2011 17:54:55 -0000

> Working with the Internet architecture is in scope
>=20
> Thus continuing to work with Ipv6 an without well known port discovery =
is in scope

Continuing to work with these things is clearly a goal, but it's =
satisfied trivially by having a clean interface: You give us a domain =
name and maybe a port number, and we'll help you authenticate that =
someone has the authorization to use them.

It doesn't matter if the domain name / port number came from
-- User entry
-- A URL
-- SRV
-- NAPTR
-- An SDP body in a SIP message
-- etc.

We support all these discovery use cases (and more!) by not doing =
anything with them and simply accepting their outputs.  Wei wu wei. =20

--Richard





> And in any case the point of this exercise is that the consensus in =
Prague was that the wg had not shown   It is solving the right problem
>=20
> Sent from my iPhone
>=20
> On 22 Apr 2011, at 09:01, "Richard L. Barnes" <[e-mail]> wrote:
>=20
>>> I think that Promiscuous Security and Web Services support should be =
added to the use cases. TLS is used for much more than just Web Browsing =
and the non-Web browsing use cases are rather more important in my view.
>>=20
>> The use cases as described are in no way specific to web browsing.  =
They apply generally to applications using TLS that require =
authentication of domain names.  In any case, I do not see use cases =
titled "Promiscuous Security" or "Web Services" in =
draft-hallambaker-dane-requirements, so please propose text.
>>=20
>>=20
>>> One very important constraint is the need to support mechanisms for =
protocol discovery that do not rely on port numbers.
>>=20
>> Protocol discovery is not in scope, not least because it varies from =
one application to another.  The use cases described apply equally well =
to dual-port (dedicated TLS port) and STARTTLS design patterns.  Indeed, =
examples of both are referenced in the introduction.
>>=20
>> Key/cert discovery is in scope, but that does not have anything to do =
with port exhaustion.  The question there is whether a client can =
disambiguate services on different ports.
>>=20
>>=20
>>> As a matter of style, the ESA format that has the requirements =
tagged with a reference number (e.g. [U-S-TRUST]) makes it easier to =
refer to the requirements when determining if a proposal meets them.
>>=20
>> I think we have few enough requirements here that there's not a need =
for a formalism.
>>=20
>> --Richard
>>=20
>>=20
>>=20
>>=20
>>=20
>>>=20
>>>=20
>>> On Fri, Apr 22, 2011 at 8:32 AM, Richard L. Barnes <[e-mail]> =
wrote:
>>> This is an updated version of the use cases draft, which =
incorporates feedback on -00 and makes several editorial changes.  Diff =
is here:
>>> =
<http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-dane-use-cases-01.txt>
>>>=20
>>> Chairs: I believe this version is ready for WGLC.
>>>=20
>>> --Richard
>>>=20
>>>=20
>>>=20
>>>=20
>>> Begin forwarded message:
>>>=20
>>>> From: IETF I-D Submission Tool <[e-mail]>
>>>> Date: April 22, 2011 8:30:04 AM EDT
>>>> To: [e-mail]
>>>> Subject: New Version Notification for draft-ietf-dane-use-cases-01
>>>>=20
>>>>=20
>>>> A new version of I-D, draft-ietf-dane-use-cases-01.txt has been =
successfully submitted by Richard Barnes and posted to the IETF =
repository.
>>>>=20
>>>> Filename:      draft-ietf-dane-use-cases
>>>> Revision:      01
>>>> Title:                 Use Cases and Requirements for DNS-based =
Authentication of Named Entities (DANE)
>>>> Creation_date:         2011-04-22
>>>> WG ID:                 dane
>>>> Number_of_pages: 9
>>>>=20
>>>> Abstract:
>>>> Many current applications use the certificate-based authentication
>>>> features in TLS to allow clients to verify that a connected server
>>>> properly represents a desired domain name.  Traditionally, this
>>>> authentication has been based on PKIX trust hierarchies, rooted in
>>>> well-known CAs, but additional information can be provided via the
>>>> DNS itself.  This document describes a set of use cases in which =
the
>>>> DNS and DNSSEC could be used to make assertions that support the =
TLS
>>>> authentication process.
>>>>=20
>>>>=20
>>>>=20
>>>> The IETF Secretariat.
>>>>=20
>>>>=20
>>>=20
>>> _______________________________________________
>>> dane mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dane
>>>=20
>>>=20
>>>=20
>>> --=20
>>> Website: http://hallambaker.com/
>>>=20
>>=20


From [e-mail]  Fri Apr 22 11:12:51 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8BC75E07EA for <[e-mail]>; Fri, 22 Apr 2011 11:12:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.124
X-Spam-Level: 
X-Spam-Status: No, score=-3.124 tagged_above=-999 required=5 tests=[AWL=0.174,  BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tZvEeNSbYjd for <[e-mail]>; Fri, 22 Apr 2011 11:12:50 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id 91766E07CB for <[e-mail]>; Fri, 22 Apr 2011 11:12:50 -0700 (PDT)
Received: by vws12 with SMTP id 12so726454vws.31 for <[e-mail]>; Fri, 22 Apr 2011 11:12:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zeVjMC24H93R0/ng7Pmgzzl8wqQx+V+IEbuu5I4J4Ao=; b=CGIB3YN0/JJd2N3GvNcrs/trX+u9rNu4n8k5EkEfmoER5yoYFbwwKx8fnuxZ4IZEuX eYYkgusvYoerqwE4WDvRCuLtdGSx7Adl2gOtzCWiJ8Rbvc/kmZ4gfAPzbb+Dn/V2ii6l l1w0He/y5+05DW2l2SPyolQ8oOmZGF6mHqeBk=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=hKcP+OUzqlzdoLvHo6VZBEgXGs//pAzuzL9sVljRAd7upThMY6sFwVp+NzJdWV6zh+ bXNdogUXHYKmXp9TlrEstWqc96minoyUh1Oh+EQl7eBaioJMQhTbgEMUEhdkd6dMLEPd 4BOfJA6baK9SuBHuK414UGJjFlZZW4/LeC1PU=
MIME-Version: 1.0
Received: by 10.52.0.136 with SMTP id 8mr2168215vde.45.1303495970213; Fri, 22 Apr 2011 11:12:50 -0700 (PDT)
Received: by 10.52.161.3 with HTTP; Fri, 22 Apr 2011 11:12:50 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <BANLkTi=BT=nrUfkNXQ15GkoJSzsFPJj=[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 22 Apr 2011 14:12:50 -0400
Message-ID: <[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[e-mail]>
Content-Type: multipart/alternative; boundary=20cf304346f4454fc304a185ce2d
Cc: [e-mail]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 22 Apr 2011 18:12:51 -0000

--20cf304346f4454fc304a185ce2d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Apr 22, 2011 at 9:14 AM, Ond=C5=99ej Sur=C3=BD <[e-mail]>=
 wrote:

> On 4/21/11 6:41 AM, Phillip Hallam-Baker wrote:
>
>>
>> There is a reason that I have spent so much time ensuring that my
>> proposal works correctly and consistently when SRV, NAPTR or URI type
>> discovery mechanisms are used. It is because I believe that Web Services
>> is the type of niche use case that can drive a standard like Dane to
>> reach critical mass.
>>
>
> We have already discussed SRV in issue#1 and we the WG rejected the idea =
of
> using SRV.
>
>
That decision is now irrelevant. The WG has been required to go back and
consider use cases for keys in the DNS.

The WG may decide not to meet all the proposed use cases but they should al=
l
be documented.


And one of the consequences of not meeting a use case is that it may well
mean that we end up with two keys in the DNS protocols rather than one.

I would much prefer there to be one joint proposal that meets all our needs
but when a WG decides not to support a use case or constraint it is also
saying 'we do not object to others meeting that use case in a different
way'. If there is a WG consensus that you would all prefer me to address my
use case my way and not bother the group, that is fine with me. But if the
WG decides that is what they want to do they are going to have to take all
the responsibility for there being two protocols instead of one.


The purpose of this exercise is to find out if we can find common ground.
The point is lost if a people decide that because they are 5 out of the 8
active people in a WG that whatever they decide has consensus.

Why can't we choose the protocol architecture on the basis of the
>> proposal that supports the widest range of use cases with the simplest
>> mechanism and best objective performance metrics wins?
>>
>
> Anyway Phillip,
>
> care to split your requirements into clear individual issues (as you see
> them)?  I'll log them into our issue tracker for reference, the mailing l=
ist
> is too crowded to keep track of anything.
>

I would prefer to capture them in the use cases document as constraints.

I have the text but it will probably be Monday or Tuesday before I can get
access to the machine.


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

--20cf304346f4454fc304a185ce2d
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Fri, Apr 22, 2011 at 9:14 AM, Ond=F8e=
j Sur=FD <span dir=3D"ltr">&lt;<a href=3D"mailto:[e-mail]">ondrej=
[e-mail]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">On 4/21/11 6:41 AM, Phillip Hallam-Baker wrote:<br>
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div class=3D"im"><br></div><div><div =
class=3D"h5">
There is a reason that I have spent so much time ensuring that my<br>
proposal works correctly and consistently when SRV, NAPTR or URI type<br>
discovery mechanisms are used. It is because I believe that Web Services<br=
>
is the type of niche use case that can drive a standard like Dane to<br>
reach critical mass.<br>
</div></div></blockquote>
<br>
We have already discussed SRV in issue#1 and we the WG rejected the idea of=
 using SRV.<div class=3D"im"><br></div></blockquote><div><br></div><div>Tha=
t decision is now irrelevant. The WG has been required to go back and consi=
der use cases for keys in the DNS.=A0</div>
<div><br></div><div>The WG may decide not to meet all the proposed use case=
s but they should all be documented.</div><div><br></div><div><br></div><di=
v>And one of the consequences of not meeting a use case is that it may well=
 mean that we end up with two keys in the DNS protocols rather than one.</d=
iv>
<div><br></div><div>I would much prefer there to be one joint proposal that=
 meets all our needs but when a WG decides not to support a use case or con=
straint it is also saying &#39;we do not object to others meeting that use =
case in a different way&#39;. If there is a WG consensus that you would all=
 prefer me to address my use case my way and not bother the group, that is =
fine with me. But if the WG decides that is what they want to do they are g=
oing to have to take all the responsibility for there being two protocols i=
nstead of one.</div>
<div><br></div><div><br></div><div>The purpose of this exercise is to find =
out if we can find common ground. The point is lost if a people decide that=
 because they are 5 out of the 8 active people in a WG that whatever they d=
ecide has consensus.=A0</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex;"><div class=3D"im"><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex">
Why can&#39;t we choose the protocol architecture on the basis of the<br>
proposal that supports the widest range of use cases with the simplest<br>
mechanism and best objective performance metrics wins?<br>
</blockquote>
<br></div>
Anyway Phillip,<br>
<br>
care to split your requirements into clear individual issues (as you see th=
em)? =A0I&#39;ll log them into our issue tracker for reference, the mailing=
 list is too crowded to keep track of anything.<br></blockquote><div><br>
</div><div>I would prefer to capture them in the use cases document as cons=
traints.</div><div><br></div><div>I have the text but it will probably be M=
onday or Tuesday before I can get access to the machine.</div><div><br>
</div><div>=A0</div></div>-- <br>Website: <a href=3D"http://hallambaker.com=
/">http://hallambaker.com/</a><br><br>

--20cf304346f4454fc304a185ce2d--

From [e-mail]  Fri Apr 22 11:19:57 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1EC38E081D for <[e-mail]>; Fri, 22 Apr 2011 11:19:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.278
X-Spam-Level: 
X-Spam-Status: No, score=-3.278 tagged_above=-999 required=5 tests=[AWL=0.320,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9k7pjwt16Cbx for <[e-mail]>; Fri, 22 Apr 2011 11:19:56 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id 48437E081C for <[e-mail]>; Fri, 22 Apr 2011 11:19:56 -0700 (PDT)
Received: by vws12 with SMTP id 12so730338vws.31 for <[e-mail]>; Fri, 22 Apr 2011 11:19:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rsGy+4O70yJBAVloJiRK/Haar6niVDAkKk5t1L5P9PU=; b=sVGAiztLxyTjB3CCi71jvHePRUmdKnjaU9l4Z0kf1ePON1sJ6rXDIkSPXzBXdt3+NK mv3L+N23pWwzjtlOAJsW4i7m4TO01ycJbSlS2kgkNV2GCp71Jplrgxur1LK1C3AK4M7S S56YUne594fAnIuZ1s1gfRXg8vXQ4rUpNPqEc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=tmg/aeVtIl0KBO2vOSgZcvjvKpu20Ojnw/G9T/A/kw6B1qQH3E83v/xjGrhbj0lyW6 qNcEAe3SEporvFySBQKy7AST3K68W1kCIP7BXDkudoWDtwcWJFQ8X9hZFR3hl4o2oMIX 6qdnMALFaQdp8ayqQMyIdd5KiR8MUPSqhj3EA=
MIME-Version: 1.0
Received: by 10.52.184.98 with SMTP id et2mr2034949vdc.285.1303496395547; Fri, 22 Apr 2011 11:19:55 -0700 (PDT)
Received: by 10.52.161.3 with HTTP; Fri, 22 Apr 2011 11:19:55 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 22 Apr 2011 14:19:55 -0400
Message-ID: <BANLkTi=[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: "Richard L. Barnes" <[e-mail]>
Content-Type: multipart/alternative; boundary=bcaec548a0679f645b04a185e779
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [dane] Fwd: New Version Notification for draft-ietf-dane-use-cases-01
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 22 Apr 2011 18:19:57 -0000

--bcaec548a0679f645b04a185e779
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Apr 22, 2011 at 1:54 PM, Richard L. Barnes <[e-mail]> wrote:

> > Working with the Internet architecture is in scope
> >
> > Thus continuing to work with Ipv6 an without well known port discovery is
> in scope
>
> Continuing to work with these things is clearly a goal, but it's satisfied
> trivially by having a clean interface: You give us a domain name and maybe a
> port number, and we'll help you authenticate that someone has the
> authorization to use them.
>
> It doesn't matter if the domain name / port number came from
> -- User entry
> -- A URL
> -- SRV
> -- NAPTR
> -- An SDP body in a SIP message
> -- etc.
>
> We support all these discovery use cases (and more!) by not doing anything
> with them and simply accepting their outputs.  Wei wu wei.


That does not work very well for Web Services because there are typically
multiple services on the same port.

It can probably be made to work, but the spec has to explain how to make it
work.

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

--bcaec548a0679f645b04a185e779
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Fri, Apr 22, 2011 at 1:54 PM, Richard=
 L. Barnes <span dir=3D"ltr">&lt;<a href=3D"mailto:[e-mail]">rbarnes=
@bbn.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">&gt; Working with the Internet architecture is in scope<b=
r>
&gt;<br>
&gt; Thus continuing to work with Ipv6 an without well known port discovery=
 is in scope<br>
<br>
</div>Continuing to work with these things is clearly a goal, but it&#39;s =
satisfied trivially by having a clean interface: You give us a domain name =
and maybe a port number, and we&#39;ll help you authenticate that someone h=
as the authorization to use them.<br>

<br>
It doesn&#39;t matter if the domain name / port number came from<br>
-- User entry<br>
-- A URL<br>
-- SRV<br>
-- NAPTR<br>
-- An SDP body in a SIP message<br>
-- etc.<br>
<br>
We support all these discovery use cases (and more!) by not doing anything =
with them and simply accepting their outputs. =A0Wei wu wei.</blockquote><d=
iv><br></div><div>That does not work very well for Web Services because the=
re are typically multiple services on the same port.</div>
<div><br></div><div>It can probably be made to work, but the spec has to ex=
plain how to make it work.=A0</div><div><br></div></div>-- <br>Website: <a =
href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>

--bcaec548a0679f645b04a185e779--

From [e-mail]  Fri Apr 22 11:29:20 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7F9C0E0837 for <[e-mail]>; Fri, 22 Apr 2011 11:29:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.131
X-Spam-Level: 
X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[AWL=-0.229, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-krn5auFUNC for <[e-mail]>; Fri, 22 Apr 2011 11:29:08 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfc.amsl.com (Postfix) with ESMTP id EE918E0710 for <[e-mail]>; Fri, 22 Apr 2011 11:29:07 -0700 (PDT)
Received: from [109.183.198.100] (109-183-198-100.tmcz.cz [109.183.198.100]) by mail.nic.cz (Postfix) with ESMTPSA id 41D122A00AD; Fri, 22 Apr 2011 20:29:05 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1303496946; bh=jIyWSwrhAiIDl/NshvEL6aOELhO563xjiIjHWCl6s28=; h=References:In-Reply-To:Mime-Version:Content-Transfer-Encoding: Content-Type:Message-Id:Cc:From:Subject:Date:To; b=dh63KvF1oo0g2UYpA2SNUCeq4CkbudoHocVDfELtsRXXdWAotwaOdC0PmhCh7QToV yrOlq15c8k0rYmSXQMXjFMG8x/eKr5efXmTURaiPVqm/ykVfjR/U5lFe4Cl2U//zHv Fjf2lRxMA9g09RThk7myqNgz53JQ6DHztytLJO+g=
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <BANLkTi=BT=nrUfkNXQ15GkoJSzsFPJj=[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0 (iPhone Mail 8H7)
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative; boundary=Apple-Mail-2-919711709
Message-Id: <[e-mail]>
X-Mailer: iPhone Mail (8H7)
From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= <[e-mail]>
Date: Fri, 22 Apr 2011 20:28:55 +0200
To: Phillip Hallam-Baker <[e-mail]>
X-Virus-Scanned: clamav-milter 0.96.5 at mail
X-Virus-Status: Clean
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 22 Apr 2011 18:29:20 -0000

--Apple-Mail-2-919711709
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

[replying on my phone, so sorry for being terse and for any errors]

On 22.4.2011, at 20:12, Phillip Hallam-Baker <[e-mail]> wrote:

>=20
>=20
> On Fri, Apr 22, 2011 at 9:14 AM, Ond=C5=99ej Sur=C3=BD <[e-mail]=
> wrote:
> On 4/21/11 6:41 AM, Phillip Hallam-Baker wrote:
>=20
> There is a reason that I have spent so much time ensuring that my
> proposal works correctly and consistently when SRV, NAPTR or URI type
> discovery mechanisms are used. It is because I believe that Web Services
> is the type of niche use case that can drive a standard like Dane to
> reach critical mass.
>=20
> We have already discussed SRV in issue#1 and we the WG rejected the idea o=
f using SRV.
>=20
>=20
> That decision is now irrelevant. The WG has been required to go back and c=
onsider use cases for keys in the DNS.=20

Here we don't agree. The WG was requested to write use cases document and no=
t to throw away all past work and restart from scratch.

> The WG may decide not to meet all the proposed use cases but they should a=
ll be documented.
>=20
>=20
> And one of the consequences of not meeting a use case is that it may well m=
ean that we end up with two keys in the DNS protocols rather than one.
>=20
> I would much prefer there to be one joint proposal that meets all our need=
s but when a WG decides not to support a use case or constraint it is also s=
aying 'we do not object to others meeting that use case in a different way'.=
 If there is a WG consensus that you would all prefer me to address my use c=
ase my way and not bother the group, that is fine with me. But if the WG dec=
ides that is what they want to do they are going to have to take all the res=
ponsibility for there being two protocols instead of one.
>=20

Rejecting a use case doesn't mean that WG don't object to others picking it u=
p. I really don't think the implication is there as you're suggesting.

> The purpose of this exercise is to find out if we can find common ground. T=
he point is lost if a people decide that because they are 5 out of the 8 act=
ive people in a WG that whatever they decide has consensus.=20

Nobody is implying that. The WG sticks to the IETF protocols for WG. If you h=
ave any specific objections how any issue and it's call for consensus were d=
one please contact the chairs (me or Warren).

> Why can't we choose the protocol architecture on the basis of the
> proposal that supports the widest range of use cases with the simplest
> mechanism and best objective performance metrics wins?
>=20
> Anyway Phillip,
>=20
> care to split your requirements into clear individual issues (as you see t=
hem)?  I'll log them into our issue tracker for reference, the mailing list i=
s too crowded to keep track of anything.
>=20
> I would prefer to capture them in the use cases document as constraints.
>=20
> I have the text but it will probably be Monday or Tuesday before I can get=
 access to the machine.

Fine with me.

O.=

--Apple-Mail-2-919711709
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><body bgcolor=3D"#FFFFFF"><div>[replying on my phone, so sorry for bei=
ng terse and for any errors]</div><div><br></div><div>On 22.4.2011, at 20:12=
, Phillip Hallam-Baker &lt;<a href=3D"mailto:[e-mail]">hallam@gmail.=
com</a>&gt; wrote:<br><br></div><div></div><blockquote type=3D"cite"><div><b=
r><br><div class=3D"gmail_quote">On Fri, Apr 22, 2011 at 9:14 AM, Ond=C5=99e=
j Sur=C3=BD <span dir=3D"ltr">&lt;<a href=3D"mailto:[e-mail]"><a h=
ref=3D"mailto:[e-mail]">[e-mail]</a></a>&gt;</span> wrot=
e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">On 4/21/11 6:41 AM, Phillip Hallam-Baker wrote:<br>
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div class=3D"im"><br></div><div><div cl=
ass=3D"h5">
There is a reason that I have spent so much time ensuring that my<br>
proposal works correctly and consistently when SRV, NAPTR or URI type<br>
discovery mechanisms are used. It is because I believe that Web Services<br>=

is the type of niche use case that can drive a standard like Dane to<br>
reach critical mass.<br>
</div></div></blockquote>
<br>
We have already discussed SRV in issue#1 and we the WG rejected the idea of u=
sing SRV.<div class=3D"im"><br></div></blockquote><div><br></div><div>That d=
ecision is now irrelevant. The WG has been required to go back and consider u=
se cases for keys in the DNS.&nbsp;</div></div></div></blockquote><div><br><=
/div><div>Here we don't agree. The WG was requested to write use cases docum=
ent and not to throw away all past work and restart from scratch.</div><br><=
blockquote type=3D"cite"><div><div class=3D"gmail_quote"><div>The WG may dec=
ide not to meet all the proposed use cases but they should all be documented=
.</div><div><br></div><div><br></div><div>And one of the consequences of not=
 meeting a use case is that it may well mean that we end up with two keys in=
 the DNS protocols rather than one.</div>
<div><br></div><div>I would much prefer there to be one joint proposal that m=
eets all our needs but when a WG decides not to support a use case or constr=
aint it is also saying 'we do not object to others meeting that use case in a=
 different way'. If there is a WG consensus that you would all prefer me to a=
ddress my use case my way and not bother the group, that is fine with me. Bu=
t if the WG decides that is what they want to do they are going to have to t=
ake all the responsibility for there being two protocols instead of one.</di=
v>
<div><br></div></div></div></blockquote><div><br></div><div>Rejecting a use c=
ase doesn't mean that WG don't object to others picking it up. I really don'=
t think the implication is there as you're suggesting.</div><br><blockquote t=
ype=3D"cite"><div><div class=3D"gmail_quote"><div>The purpose of this exerci=
se is to find out if we can find common ground. The point is lost if a peopl=
e decide that because they are 5 out of the 8 active people in a WG that wha=
tever they decide has consensus.&nbsp;</div></div></div></blockquote><div><b=
r></div><div>Nobody is implying that. The WG sticks to the IETF protocols fo=
r WG. If you have any specific objections how any issue and it's call for co=
nsensus were done please contact the chairs (me or Warren).</div><br><blockq=
uote type=3D"cite"><div><div class=3D"gmail_quote"><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex;"><div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Why can't we choose the protocol architecture on the basis of the<br>
proposal that supports the widest range of use cases with the simplest<br>
mechanism and best objective performance metrics wins?<br>
</blockquote>
<br></div>
Anyway Phillip,<br>
<br>
care to split your requirements into clear individual issues (as you see the=
m)? &nbsp;I'll log them into our issue tracker for reference, the mailing li=
st is too crowded to keep track of anything.<br></blockquote><div><br>
</div><div>I would prefer to capture them in the use cases document as const=
raints.</div><div><br></div><div>I have the text but it will probably be Mon=
day or Tuesday before I can get access to the machine.</div></div>
</div></blockquote><br><div>Fine with me.</div><div><br></div><div>O.</div><=
/body></html>=

--Apple-Mail-2-919711709--

From [e-mail]  Fri Apr 22 11:53:08 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5D558E07A3 for <[e-mail]>; Fri, 22 Apr 2011 11:53:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.635
X-Spam-Level: 
X-Spam-Status: No, score=-2.635 tagged_above=-999 required=5 tests=[AWL=-0.337, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zA7ESWOaXUX for <[e-mail]>; Fri, 22 Apr 2011 11:53:07 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfc.amsl.com (Postfix) with ESMTP id 99898E079D for <[e-mail]>; Fri, 22 Apr 2011 11:53:04 -0700 (PDT)
Received: by vxg33 with SMTP id 33so759766vxg.31 for <[e-mail]>; Fri, 22 Apr 2011 11:53:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=GC4/maPEPLyr3EvL6ks9lIhxTwGBxlM7YuESDDS464Q=; b=tDwNm/hpahK2qmD2gpzar2NdXk33GoEzTtkw504ms5lQRV5pxd66RqXC+pjfLwmm3Q Pc98UhRwn+NGBMviR4lInQYORROFWVBlA2zk3aQJpxLbBnCiXVLEoQZeozDZgQlza/CJ Ob0fPchT7CyvhfDHxyuJstaDWeDprkJTv5/XE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=OhUdLRYUolKFp+/bVizQqZoLNhOdxHL82iTNYhqtnYYToFN11vB7nIMQBHrZcuj7Sj rYNvdCNWNPNt4huct/rbHUZf+EV3EVTMOFuEzi+4veop0aBLcmJuM1B15WqSmaGT2qzC Y21zLeIQTDEDm3friBPeXS+SaJbkYy8snEgCg=
MIME-Version: 1.0
Received: by 10.52.69.2 with SMTP id a2mr2267643vdu.5.1303498384174; Fri, 22 Apr 2011 11:53:04 -0700 (PDT)
Received: by 10.52.161.3 with HTTP; Fri, 22 Apr 2011 11:53:04 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <BANLkTi=BT=nrUfkNXQ15GkoJSzsFPJj=[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 22 Apr 2011 14:53:04 -0400
Message-ID: <BANLkTimcNkx7MJYC7LZYny70tbi=[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[e-mail]>
Content-Type: multipart/alternative; boundary=20cf30780e6e276e8504a1865e04
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 22 Apr 2011 18:53:08 -0000

--20cf30780e6e276e8504a1865e04
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Apr 22, 2011 at 2:28 PM, Ond=C5=99ej Sur=C3=BD <[e-mail]>=
 wrote:

> [replying on my phone, so sorry for being terse and for any errors
>
>
> That decision is now irrelevant. The WG has been required to go back and
> consider use cases for keys in the DNS.
>
>
> Here we don't agree. The WG was requested to write use cases document and
> not to throw away all past work and restart from scratch.
>

So you think it is going to be ok to make no changes to what you propose to
do and just give more of an explanation of why?



> Rejecting a use case doesn't mean that WG don't object to others picking =
it
> up. I really don't think the implication is there as you're suggesting.
>

No, but rejecting a use case means that the WG has forfeited the right to
make an objection.

If a WG wants people to use their proposal then they support their use
cases. If they refuse to support a use cases they accept that there may be
alternatives.

Whether people mind or not is irrelevant. If you want there to be one
protocol to meet this set of needs then you need to look to support 95% of
the use cases. If you decide that you don't want to support a use case you
are telling people to look elsewhere. That is what use cases mean.


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

--20cf30780e6e276e8504a1865e04
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Fri, Apr 22, 2011 at 2:28 PM, Ond=C5=
=99ej Sur=C3=BD <span dir=3D"ltr">&lt;<a href=3D"mailto:[e-mail]"=
>[e-mail]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;=
">
<div bgcolor=3D"#FFFFFF"><div>[replying on my phone, so sorry for being ter=
se and for any errors</div><div class=3D"im"><blockquote type=3D"cite"><div=
><div class=3D"gmail_quote"><div><br></div><div>That decision is now irrele=
vant. The WG has been required to go back and consider use cases for keys i=
n the DNS.=C2=A0</div>
</div></div></blockquote><div><br></div></div><div>Here we don&#39;t agree.=
 The WG was requested to write use cases document and not to throw away all=
 past work and restart from scratch.</div></div></blockquote><div><br></div=
>
<div>So you think it is going to be ok to make no changes to what you propo=
se to do and just give more of an explanation of why?</div><div><br></div><=
div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex;">
<div bgcolor=3D"#FFFFFF"><div>Rejecting a use case doesn&#39;t mean that WG=
 don&#39;t object to others picking it up. I really don&#39;t think the imp=
lication is there as you&#39;re suggesting.</div></div></blockquote><div>
<br></div><div>No, but rejecting a use case means that the WG has forfeited=
 the right to make an objection.</div><div><br></div><div>If a WG wants peo=
ple to use their proposal then they support their use cases. If they refuse=
 to support a use cases they accept that there may be alternatives.=C2=A0</=
div>
<div><br></div><div>Whether people mind or not is irrelevant. If you want t=
here to be one protocol to meet this set of needs then you need to look to =
support 95% of the use cases. If you decide that you don&#39;t want to supp=
ort a use case you are telling people to look elsewhere. That is what use c=
ases mean.</div>
<div><br></div><div><br></div></div>-- <br>Website: <a href=3D"http://halla=
mbaker.com/">http://hallambaker.com/</a><br><br>

--20cf30780e6e276e8504a1865e04--

From [e-mail]  Fri Apr 22 20:49:24 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2BB86E06E2 for <[e-mail]>; Fri, 22 Apr 2011 20:49:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id unQityhyiDuU for <[e-mail]>; Fri, 22 Apr 2011 20:49:23 -0700 (PDT)
Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfc.amsl.com (Postfix) with ESMTP id 022EBE065C for <[e-mail]>; Fri, 22 Apr 2011 20:49:22 -0700 (PDT)
Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: [e-mail]) by smtp2.pacifier.net (Postfix) with ESMTP id 790EE6A49E; Fri, 22 Apr 2011 20:49:21 -0700 (PDT)
From: "Jim Schaad" <[e-mail]>
To: "'Richard L. Barnes'" <[e-mail]>, <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Fri, 22 Apr 2011 21:15:28 -0700
Message-ID: <012301cc016d$14b103f0$3e130bd0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQNyg4lXwmk6n5EjxFLUypP4wfIz8wGfclnvkRB3zMA=
Content-Language: en-us
Subject: Re: [dane] Fwd: New Version Notification for	draft-ietf-dane-use-cases-01
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 23 Apr 2011 03:49:24 -0000

Comments on the draft:

Abstract:
1.  "Traditionally, this
   authentication has been based on PKIX trust hierarchies, rooted in
   well-known CAs, but additional information can be provided via the
   DNS itself. "
 I don't know that this is true based on the messages that have been sent on
the list.  Given the amount of apparent self-signed certs that are used for
TLS I don't think it can be said that this is the tradition.  One might be
able to say conceptually but not traditionally.

Section 1. Introduction
1. "After locating the server via an A or AAAA record,"  This is what gives
you an address for a server, however the process of locating the server is
much more complicated and involves all sorts of different DNS records (MX,
CNAME, SRV, ...).   Better would be "After obtaining the address of a server
via an A or AAAA record,"

2.  The last sentence in this paragraph should refer to the new RFC on how
to do this process, since it is complicated and may depend on DNS records
not  mentioned above.

3.  "In most current applications, this decision process is based on PKIX
validation and name matching."  This text implies that the name matching is
also a PKIX defined functionality.  It is not it is based on the protocol
that is using the TLS process.  (See note on PSA draft above.)  Suggested
text would be "PKIX path validation and protocol based name matching."

Section 3.

I want to add a number of actors to this list since I have a set of use
cases that are not covered that I think should be.

Add Trent a well-known CA that is installed as a trust anchor on Bobs
machine.

Charlie becomes a CA that issues certificates with domain names as
identifiers.  Charlie may be the same as Trent, operator as an intermediate
CA below Trent either being the same as or independent of Alice.

Diane is the operator of a TLS-protected service for Alice. 
(Or make Alice the owner and administrator of the domain and say that Diane
and Alice could be the same entity.)

Now in the CA constraints, Alice may want to restrict to either Trent (a
known trust point) or Charlie (an intermediate CA).

The reason for the restrict is now possibly down to Trent or Charlie.  Or it
can be that there is a restriction to what Diane is permitted to use (this
is also the 3.2 example I assume.)

The following  is not a use case?  I thought this was constantly coming up
on the list.
Alice runs the domain alice.example.com, but Diane (diane.example.com)
operates a TLS secured service for Alice.

3.2 is, I assume supposed to be a restriction on the EE certificate - and
thus would restrict both Bob and Diane in what they can do.

In 3.3 - there are now two different cases that can come about.  1) Alice is
now running her own CA that is not well-known or trusted and 2) Alice wants
Bob to trust Trent (or maybe Charlie), but Bob does not either by default or
by policy.

Section 4 - Other Requirements

In some cases is the statement about Encapsulation correct?  In the event of
an SRV or CNAME or MX record (and so forth).  Should you be able to make
statements about the party that is actually going to provide the services if
they are outsourced?

Predictability - Given that we are making statements that we don't care
about cases where things like SRV records exist.  What is the likelihood
that protocols are going to want to change the DANE behavior about thinks
like encapsulation and which DANE record formats exist.   How are you
defining PKIX information in this case given that it can be defined by
different protocols and how the domain information is dealt with in those
cases is going to be treated differently.  Are you going to define the DANE
values as inputs to the PKIX path validation process?  So that they are
constrained by name constraints?

For the Wild Cards and CNAME items, does this mean we need to have a BCP
statement for how to fill in your DNS so that people will get it correct?
It is of much greater importance that people who do not correctly understand
how DNS wild card matching works get top of the line guidance on how to
configure and fill in their DNS structure in order to get it working
correct.  This is of special importance since much of the group believes
that this work is going to be done by non-specialists who are not willing to
pay for additional security services (i.e. getting a certificate from a
well-known CA).

Jim


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Richard L. Barnes
> Sent: Friday, April 22, 2011 5:32 AM
> To: [e-mail]
> Subject: [dane] Fwd: New Version Notification for
draft-ietf-dane-use-cases-
> 01
> 
> This is an updated version of the use cases draft, which incorporates
> feedback on -00 and makes several editorial changes.  Diff is here:
> <http://tools.ietf.org/rfcdiff?url2=draft-ietf-dane-use-cases-01.txt>
> 
> Chairs: I believe this version is ready for WGLC.
> 
> --Richard
> 
> 
> 
> 
> Begin forwarded message:
> 
> > From: IETF I-D Submission Tool <[e-mail]>
> > Date: April 22, 2011 8:30:04 AM EDT
> > To: [e-mail]
> > Subject: New Version Notification for draft-ietf-dane-use-cases-01
> >
> >
> > A new version of I-D, draft-ietf-dane-use-cases-01.txt has been
> successfully submitted by Richard Barnes and posted to the IETF
repository.
> >
> > Filename:	 draft-ietf-dane-use-cases
> > Revision:	 01
> > Title:		 Use Cases and Requirements for DNS-based
Authentication
> of Named Entities (DANE)
> > Creation_date:	 2011-04-22
> > WG ID:		 dane
> > Number_of_pages: 9
> >
> > Abstract:
> > Many current applications use the certificate-based authentication
> > features in TLS to allow clients to verify that a connected server
> > properly represents a desired domain name.  Traditionally, this
> > authentication has been based on PKIX trust hierarchies, rooted in
> > well-known CAs, but additional information can be provided via the DNS
> > itself.  This document describes a set of use cases in which the DNS
> > and DNSSEC could be used to make assertions that support the TLS
> > authentication process.
> >
> >
> >
> > The IETF Secretariat.
> >
> >
> 
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane


From [e-mail]  Sat Apr 23 10:03:16 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 62406E070E for <[e-mail]>; Sat, 23 Apr 2011 10:03:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.549
X-Spam-Level: 
X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPFBCNx12ryA for <[e-mail]>; Sat, 23 Apr 2011 10:03:15 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfc.amsl.com (Postfix) with ESMTP id C2781E06C8 for <[e-mail]>; Sat, 23 Apr 2011 10:03:15 -0700 (PDT)
Received: from [128.89.252.149] (port=53629 helo=[172.27.17.202]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from <[e-mail]>) id 1QDgEl-000GFI-AZ; Sat, 23 Apr 2011 13:03:15 -0400
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: "Richard L. Barnes" <[e-mail]>
In-Reply-To: <BANLkTi=[e-mail]>
Date: Sat, 23 Apr 2011 13:03:14 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <BANLkTi=[e-mail]>
To: Phillip Hallam-Baker <[e-mail]>
X-Mailer: Apple Mail (2.1082)
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [dane] Fwd: New Version Notification for draft-ietf-dane-use-cases-01
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 23 Apr 2011 17:03:16 -0000

> That does not work very well for Web Services because there are =
typically multiple services on the same port.
>=20
> It can probably be made to work, but the spec has to explain how to =
make it work.=20


Could you be a little more explicit?  The Web Services Security =
framework I'm aware of [1] does not use TLS, and thus is not something =
germane to this working group.

[1] <http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=3Dwss>=

From [e-mail]  Sat Apr 23 11:29:13 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 74422E067C for <[e-mail]>; Sat, 23 Apr 2011 11:29:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.551
X-Spam-Level: 
X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0a42IvKGhjF3 for <[e-mail]>; Sat, 23 Apr 2011 11:29:12 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfc.amsl.com (Postfix) with ESMTP id 48522E0668 for <[e-mail]>; Sat, 23 Apr 2011 11:29:12 -0700 (PDT)
Received: from [128.89.252.149] (port=54635 helo=[172.27.17.202]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from <[e-mail]>) id 1QDhZv-000INe-Ri; Sat, 23 Apr 2011 14:29:12 -0400
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: Richard L. Barnes <[e-mail]>
In-Reply-To: <012301cc016d$14b103f0$3e130bd0$@augustcellars.com>
Date: Sat, 23 Apr 2011 14:29:11 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <012301cc016d$14b103f0$3e130bd0$@augustcellars.com>
To: "Jim Schaad" <[e-mail]>
X-Mailer: Apple Mail (2.1082)
Cc: [e-mail]
Subject: Re: [dane] Fwd: New Version Notification for	draft-ietf-dane-use-cases-01
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 23 Apr 2011 18:29:13 -0000

Hey Jim,

Thanks for the comments.  Responses inline.

> Abstract:
> 1.  "Traditionally, this
>   authentication has been based on PKIX trust hierarchies, rooted in
>   well-known CAs, but additional information can be provided via the
>   DNS itself. "
> I don't know that this is true based on the messages that have been =
sent on
> the list.  Given the amount of apparent self-signed certs that are =
used for
> TLS I don't think it can be said that this is the tradition.  One =
might be
> able to say conceptually but not traditionally.

Well, I guess the self-signed case as it exists today is still PKIX, but =
with very ad-hoc TA management.  I think the sense is probably clear =
enough to set context in the Abstract.


> Section 1. Introduction
> 1. "After locating the server via an A or AAAA record,"  This is what =
gives
> you an address for a server, however the process of locating the =
server is
> much more complicated and involves all sorts of different DNS records =
(MX,
> CNAME, SRV, ...).   Better would be "After obtaining the address of a =
server
> via an A or AAAA record,"

Good point.  This also relates to Phil's point about other discovery =
mechanisms.  Revised paragraph:
One feature that is common to most uses of TLS is the use of =
certificates to authenticate domain names for services. The TLS client =
begins the TLS connection process with the goal of connecting to a =
server with a specific domain name.  (The process of obtaining this =
domain name is application-specific.  It could be entered by a user or =
found through an automated discovery process, e.g., via an SRV or NAPTR =
record.) After obtaining the address of the server via an A or AAAA =
record, the client conducts a TLS handshake with the server, during =
which the server presents a PKIX certificate for itself [RFC5280]. Based =
on this certificate, the client decides whether the server properly =
represents the desired domain name, and thus whether to proceed with the =
TLS connection or not.



> 2.  The last sentence in this paragraph should refer to the new RFC on =
how
> to do this process, since it is complicated and may depend on DNS =
records
> not  mentioned above.

Are you referring to RFC 6125?  There's to that a reference in the next =
paragraph, which actually discusses the decision process.


> 3.  "In most current applications, this decision process is based on =
PKIX
> validation and name matching."  This text implies that the name =
matching is
> also a PKIX defined functionality.  It is not it is based on the =
protocol
> that is using the TLS process.  (See note on PSA draft above.)  =
Suggested
> text would be "PKIX path validation and protocol based name matching."

Done.  (Using "application-specific" instead of "protocol based")


> The reason for the restrict is now possibly down to Trent or Charlie.  =
Or it
> can be that there is a restriction to what Diane is permitted to use =
(this
> is also the 3.2 example I assume.)
>=20
> The following  is not a use case?  I thought this was constantly =
coming up
> on the list.
> Alice runs the domain alice.example.com, but Diane (diane.example.com)
> operates a TLS secured service for Alice.

So you're saying that publishing DANE records also constrains what certs =
an outsourced service provider can use?  What's the threat here?  =20


> 3.2 is, I assume supposed to be a restriction on the EE certificate - =
and
> thus would restrict both Bob and Diane in what they can do.

I think that going into that level of detail in this document isn't =
really necessary -- we can just say that the cert we're concerned about =
is "the cert for the server" regardless of the specific characteristics =
of that cert.  But you're correct that the DANE record also constrains =
Diane.


> In 3.3 - there are now two different cases that can come about.  1) =
Alice is
> now running her own CA that is not well-known or trusted and 2) Alice =
wants
> Bob to trust Trent (or maybe Charlie), but Bob does not either by =
default or
> by policy.

Two valid cases, but they look basically the same from a technical point =
of view: Either way, it's a TA that the rest of the world doesn't know =
about.  How about a clarifying sentence at the end of the second =
paragraph of 3.3 (or possibly as a separate para):
"
[In dramatis personae:]
Trent: A CA that issues certificates with domain names as identifiers, =
but is not generally well-known.

This use case is functionally equivalent to the case where Alice doesn't =
issue her own certificates, but uses a CA Trent that is not well-known.  =
In this case, Alice would be advising Bob that he should treat Trent as =
a trust anchor for purposes of validating Alice's certificates.
"


> Section 4 - Other Requirements
>=20
> In some cases is the statement about Encapsulation correct?  In the =
event of
> an SRV or CNAME or MX record (and so forth).  Should you be able to =
make
> statements about the party that is actually going to provide the =
services if
> they are outsourced?

This seems like an application-layer question, and it depends on a few =
things, such as (1) whether the outsourcing is done securely or =
insecurely, and (2) whether the outsourcing is visible to the client =
(via CNAME/MX/etc) or not (via A/AAAA).  For example, if you get a =
secure SRV to a different domain, that seems like an explicit, secure =
delegation of services, in which case the client is OK to authenticate =
the outsourcing provider directly.

All of these questions, though, relate to what name a client is looking =
for.  So there is a clean interface to DANE:
1. Identify the name of the service you want to connect to (either the =
starting name or the name of the outsourcing provider)
2. Use DANE + TLS to authenticate that name

(And regardless of these distinctions, the domain owner still has =
control by choosing how to outsource, and whom to outsource to.  It's =
just a question of whether the control is in SRV or TLSA.)

Net of these concerns, I think the encapsulation requirement is still =
correct.


> Predictability - Given that we are making statements that we don't =
care
> about cases where things like SRV records exist.  What is the =
likelihood
> that protocols are going to want to change the DANE behavior about =
thinks
> like encapsulation and which DANE record formats exist.   How are you
> defining PKIX information in this case given that it can be defined by
> different protocols and how the domain information is dealt with in =
those
> cases is going to be treated differently.  Are you going to define the =
DANE
> values as inputs to the PKIX path validation process?  So that they =
are
> constrained by name constraints?

In this case, we have exactly one set of PKIX information, the cert =
chain in the TLS handshake.  DANE will address whether that cert =
properly represents a domain; applications can choose which domain to =
use, and check other things if they want.  DANE will probably override =
some of RFC 6125, but that's part of the idea.  These are also more =
questions for the mechanism draft, rather than use cases / requirements.


> For the Wild Cards and CNAME items, does this mean we need to have a =
BCP
> statement for how to fill in your DNS so that people will get it =
correct?

Of course, general advice about configuring DNS properly is not the =
domain (haha) of this group, but of DNSOP.  I would think that we would =
have some provisioning advice in our documents, though, at the level of =
RECOMMENDED patterns.






From [e-mail]  Sat Apr 23 11:47:50 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F160BE0691 for <[e-mail]>; Sat, 23 Apr 2011 11:47:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.19
X-Spam-Level: 
X-Spam-Status: No, score=-100.19 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GomCqnHjJRqe for <[e-mail]>; Sat, 23 Apr 2011 11:47:50 -0700 (PDT)
Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfc.amsl.com (Postfix) with SMTP id 21A99E0668 for <[e-mail]>; Sat, 23 Apr 2011 11:47:49 -0700 (PDT)
Received: (qmail 11779 invoked by uid 0); 23 Apr 2011 18:47:49 -0000
Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy3.bluehost.com with SMTP; 23 Apr 2011 18:47:49 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=TWcC0iLKzqHLAy2Rt1QSwlJTxg8ggO70kJGxOPq8CTE9cx6ZJXXCe5bNjqdvwxWjuz3T7dLTIaCxhWDmBV4ICuu5iLEujP8q/Ph7vwMbYqbAQwlEY1DB3GHmeW/CJ6if;
Received: from c-24-4-122-173.hsd1.ca.comcast.net ([24.4.122.173] helo=[192.168.11.10]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <[e-mail]>) id 1QDhrw-0000FJ-UF for [e-mail]; Sat, 23 Apr 2011 12:47:49 -0600
Message-ID: <[e-mail]>
Date: Sat, 23 Apr 2011 11:47:48 -0700
From: =JeffH <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8
MIME-Version: 1.0
To: IETF DANE WG list <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com}
Subject: Re: [dane] Fwd: New Version Notification for draft-ietf-dane-use-cases-01
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 23 Apr 2011 18:47:51 -0000

 >> That does not work very well for Web Services because there are typically
 >> multiple services on the same port.
 >>
 >> It can probably be made to work, but the spec has to explain how to make
 >> it work.
 >
 >
 > Could you be a little more explicit?

Indeed -- i.e. what do you (PHB) mean by "web services" ?   There's a plethora 
of things out there calling themselves "web services".

thanks,

=JeffH


From [e-mail]  Sat Apr 23 19:53:10 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3A61DE06F9 for <[e-mail]>; Sat, 23 Apr 2011 19:53:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.278
X-Spam-Level: 
X-Spam-Status: No, score=-3.278 tagged_above=-999 required=5 tests=[AWL=0.320,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sW28WtkX3T2Z for <[e-mail]>; Sat, 23 Apr 2011 19:53:09 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfc.amsl.com (Postfix) with ESMTP id 05781E0673 for <[e-mail]>; Sat, 23 Apr 2011 19:53:08 -0700 (PDT)
Received: by vws12 with SMTP id 12so1431088vws.31 for <[e-mail]>; Sat, 23 Apr 2011 19:53:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BxdnRV+72DOWfQHhTfhIVMjvGX9uNks9c2uwd4osNQ0=; b=s50zRw+DP2ElieD5JyHK7kNla1dgJ3YT6Pg0sziN0mybwkTy22Jb90QSXneIMEfMWq EtxBw1Gs0a2lkB6T6HvK3rdDe58PEuglkqkqKzXI2lkcW3EE+wikD9UO/eEylZVbqKgo 5efy9Lx6SlTThqHhBtW5p5WhtdgWfbdp+UXBI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=vpNcVyfRFVKzRfuFy9sXbfbVvlx9dE9nCb05aV8XtbvQqGbwxAmY9d/r22BOGMBCYF WMTpMkyAr5E+nedQ29ieU2DH95f68XD91fjN6PNM8flvWnwLRN01SHY/fMZKvw9mxjTM uWJH6Pim9tdEyObG7pM98fIrD94G6BUXh62uc=
MIME-Version: 1.0
Received: by 10.52.77.70 with SMTP id q6mr4094208vdw.165.1303613588623; Sat, 23 Apr 2011 19:53:08 -0700 (PDT)
Received: by 10.52.161.3 with HTTP; Sat, 23 Apr 2011 19:53:08 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Sat, 23 Apr 2011 22:53:08 -0400
Message-ID: <[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: "=JeffH" <[e-mail]>
Content-Type: multipart/alternative; boundary=20cf3071cfaedfd0ee04a1a13070
Cc: IETF DANE WG list <[e-mail]>
Subject: Re: [dane] Fwd: New Version Notification for draft-ietf-dane-use-cases-01
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 24 Apr 2011 02:53:10 -0000

--20cf3071cfaedfd0ee04a1a13070
Content-Type: text/plain; charset=ISO-8859-1

Web Services are generally understood to be machine-machine protocols
running over the 'Web' platform.

That minimally means using URIs as identifiers, DNS as the naming scheme but
in the typical case also means layering over HTTP as transport.

There are two main camps in Web Services, SOAP and non-SOAP (usually
referred to as REST regardless of whether it is). At this point it seems
fairly settled that both are to be called 'Web Services'. There is something
of an ideological divide and both sides probably have a point.

SOAP is really designed to make it easy to wrap a network wrapper around an
existing piece of infrastructure like a .COM library or an SQL database. It
provides little if any value for protocols like SAML or XKMS which are
scratch built and use their own security mechanisms. Both would run just as
well over raw HTTP as far as I can remember.


I am aware of the WS-* series of specifications being an author of the
original proposal and an editor of the OASIS spec. They are not designed to
provide security at the same layer as TLS though. TLS gives transport layer
security while WS-* is message layer. So WS-* can deliver non-repudiation
while TLS secures both the body and the headers. Both are needed.

Its the same situation with email. There are pros and cons to using S/MIME
and TLS and neither is really a complete substitute for the other.

WS-* is deeply embedded in SOAP anyway, so it only works for some Web
Services.


The big challenge in both cases is that we have been lacking a model for how
Web Services work out what security enhancements are on offer and how to
apply them. In the original scheme proposed by Microsoft and IBM, this was
going to be the job of UDDI. But that went the way of every other 'replace
the DNS' project to date leaving a hole in the Web Services architecture.

Most Web Services use TLS for security today and not WS-*. But the approach
to doing so is pretty ad hoc and confused. There is a real opportunity there
to clarify matters.


On Sat, Apr 23, 2011 at 2:47 PM, =JeffH <[e-mail]>wrote:

> >> That does not work very well for Web Services because there are
> typically
> >> multiple services on the same port.
> >>
> >> It can probably be made to work, but the spec has to explain how to make
> >> it work.
> >
> >
> > Could you be a little more explicit?
>
> Indeed -- i.e. what do you (PHB) mean by "web services" ?   There's a
> plethora of things out there calling themselves "web services".
>
> thanks,
>
> =JeffH
>
>
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane
>



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

--20cf3071cfaedfd0ee04a1a13070
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Web Services are generally understood to be machine-machine protocols runni=
ng over the &#39;Web&#39; platform.=A0<div><br></div><div>That minimally me=
ans using URIs as identifiers, DNS as the naming scheme but in the typical =
case also means layering over HTTP as transport.</div>
<div><br></div><div>There are two main camps in Web Services, SOAP and non-=
SOAP (usually referred to as REST regardless of whether it is). At this poi=
nt it seems fairly settled that both are to be called &#39;Web Services&#39=
;. There is something of an ideological divide and both sides probably have=
 a point.</div>
<div><br></div><div>SOAP is really designed to make it easy to wrap a netwo=
rk wrapper around an existing piece of infrastructure like a .COM library o=
r an SQL database. It provides little if any value for protocols like SAML =
or XKMS which are scratch built and use their own security mechanisms. Both=
 would run just as well over raw HTTP as far as I can remember.</div>
<div><br></div><div><br></div><div>I am aware of the WS-* series of specifi=
cations being an author of the original proposal and an editor of the OASIS=
 spec. They are not designed to provide security at the same layer as TLS t=
hough. TLS gives transport layer security while WS-* is message layer. So W=
S-* can deliver non-repudiation while TLS secures both the body and the hea=
ders. Both are needed.</div>
<div><br></div><div>Its the same situation with email. There are pros and c=
ons to using S/MIME and TLS and neither is really a complete substitute for=
 the other.</div><div><br></div><div>WS-* is deeply embedded in SOAP anyway=
, so it only works for some Web Services.=A0</div>
<div><br></div><div><br></div><div>The big challenge in both cases is that =
we have been lacking a model for how Web Services work out what security en=
hancements are on offer and how to apply them. In the original scheme propo=
sed by Microsoft and IBM, this was going to be the job of UDDI. But that we=
nt the way of every other &#39;replace the DNS&#39; project to date leaving=
 a hole in the Web Services architecture.=A0</div>
<div><br>Most Web Services use TLS for security today and not WS-*. But the=
 approach to doing so is pretty ad hoc and confused. There is a real opport=
unity there to clarify matters.</div><div><br></div><div><br><div class=3D"=
gmail_quote">
On Sat, Apr 23, 2011 at 2:47 PM, =3DJeffH <span dir=3D"ltr">&lt;<a href=3D"=
mailto:[e-mail]">[e-mail]</a>&gt;=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">&gt;&gt; That does not work very well for Web Services be=
cause there are typically<br>
&gt;&gt; multiple services on the same port.<br>
&gt;&gt;<br>
&gt;&gt; It can probably be made to work, but the spec has to explain how t=
o make<br>
&gt;&gt; it work.<br>
&gt;<br>
&gt;<br>
&gt; Could you be a little more explicit?<br>
<br></div>
Indeed -- i.e. what do you (PHB) mean by &quot;web services&quot; ? =A0 The=
re&#39;s a plethora of things out there calling themselves &quot;web servic=
es&quot;.<br>
<br>
thanks,<br><font color=3D"#888888">
<br>
=3DJeffH</font><div><div></div><div class=3D"h5"><br>
<br>
_______________________________________________<br>
dane mailing list<br>
<a href=3D"mailto:[e-mail]" target=3D"_blank">[e-mail]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/dane</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a=
 href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--20cf3071cfaedfd0ee04a1a13070--

From [e-mail]  Sun Apr 24 19:36:20 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 63F1BE0670 for <[e-mail]>; Sun, 24 Apr 2011 19:36:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.553
X-Spam-Level: 
X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vI5CcN6WSMd for <[e-mail]>; Sun, 24 Apr 2011 19:36:19 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfc.amsl.com (Postfix) with ESMTP id 7E988E0669 for <[e-mail]>; Sun, 24 Apr 2011 19:36:19 -0700 (PDT)
Received: from [128.89.253.170] (port=58312 helo=[192.168.1.100]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from <[e-mail]>) id 1QEBer-000OhB-Mb; Sun, 24 Apr 2011 22:36:17 -0400
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: "Richard L. Barnes" <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Sun, 24 Apr 2011 22:36:17 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
To: Phillip Hallam-Baker <[e-mail]>
X-Mailer: Apple Mail (2.1082)
Cc: IETF DANE WG list <[e-mail]>
Subject: Re: [dane] Fwd: New Version Notification for draft-ietf-dane-use-cases-01
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 25 Apr 2011 02:36:20 -0000

Ok, thanks for being a little clearer.  So the question is then how all =
this translates into use cases / requirements for DANE.

It seems like to the extent that these systems are labeling service =
points with HTTPS URIs and using 2818-style authentication, the existing =
use cases cover web services as well.

Are you suggesting that clients should be able to use some sort of =
supra-HTTP-layer identifiers to look up keys/certs using DANE?  If so, =
that seems pretty different from what people have generally envisioned =
this technology to cover, namely looking up keys/certs based on domain =
names.

--Richard



On Apr 23, 2011, at 10:53 PM, Phillip Hallam-Baker wrote:

> Web Services are generally understood to be machine-machine protocols =
running over the 'Web' platform.=20
>=20
> That minimally means using URIs as identifiers, DNS as the naming =
scheme but in the typical case also means layering over HTTP as =
transport.
>=20
> There are two main camps in Web Services, SOAP and non-SOAP (usually =
referred to as REST regardless of whether it is). At this point it seems =
fairly settled that both are to be called 'Web Services'. There is =
something of an ideological divide and both sides probably have a point.
>=20
> SOAP is really designed to make it easy to wrap a network wrapper =
around an existing piece of infrastructure like a .COM library or an SQL =
database. It provides little if any value for protocols like SAML or =
XKMS which are scratch built and use their own security mechanisms. Both =
would run just as well over raw HTTP as far as I can remember.
>=20
>=20
> I am aware of the WS-* series of specifications being an author of the =
original proposal and an editor of the OASIS spec. They are not designed =
to provide security at the same layer as TLS though. TLS gives transport =
layer security while WS-* is message layer. So WS-* can deliver =
non-repudiation while TLS secures both the body and the headers. Both =
are needed.
>=20
> Its the same situation with email. There are pros and cons to using =
S/MIME and TLS and neither is really a complete substitute for the =
other.
>=20
> WS-* is deeply embedded in SOAP anyway, so it only works for some Web =
Services.=20
>=20
>=20
> The big challenge in both cases is that we have been lacking a model =
for how Web Services work out what security enhancements are on offer =
and how to apply them. In the original scheme proposed by Microsoft and =
IBM, this was going to be the job of UDDI. But that went the way of =
every other 'replace the DNS' project to date leaving a hole in the Web =
Services architecture.=20
>=20
> Most Web Services use TLS for security today and not WS-*. But the =
approach to doing so is pretty ad hoc and confused. There is a real =
opportunity there to clarify matters.
>=20
>=20
> On Sat, Apr 23, 2011 at 2:47 PM, =3DJeffH =
<[e-mail]> wrote:
> >> That does not work very well for Web Services because there are =
typically
> >> multiple services on the same port.
> >>
> >> It can probably be made to work, but the spec has to explain how to =
make
> >> it work.
> >
> >
> > Could you be a little more explicit?
>=20
> Indeed -- i.e. what do you (PHB) mean by "web services" ?   There's a =
plethora of things out there calling themselves "web services".
>=20
> thanks,
>=20
> =3DJeffH
>=20
>=20
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane
>=20
>=20
>=20
> --=20
> Website: http://hallambaker.com/
>=20
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane


From [e-mail]  Sun Apr 24 20:30:02 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5A3D6E0698 for <[e-mail]>; Sun, 24 Apr 2011 20:30:02 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rlJtKltZuE7F for <[e-mail]>; Sun, 24 Apr 2011 20:30:00 -0700 (PDT)
Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfc.amsl.com (Postfix) with ESMTP id B5C5FE0689 for <[e-mail]>; Sun, 24 Apr 2011 20:30:00 -0700 (PDT)
Received: from TITUS (50-39-220-175.bvtn.or.frontiernet.net [50.39.220.175]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: [e-mail]) by smtp1.pacifier.net (Postfix) with ESMTP id ED6BE6EF13; Sun, 24 Apr 2011 20:29:58 -0700 (PDT)
From: "Jim Schaad" <[e-mail]>
To: "'Richard L.Barnes'" <[e-mail]>
References: <[e-mail]> <[e-mail]> <012301cc016d$14b103f0$3e130bd0$@augustcellars.com> <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Sun, 24 Apr 2011 20:56:05 -0700
Message-ID: <000001cc02fc$b6afcb10$240f6130$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQNyg4lXwmk6n5EjxFLUypP4wfIz8wGfclnvAZ9YaK0BM4arjJD9VAfg
Content-Language: en-us
Cc: [e-mail]
Subject: Re: [dane] Fwd: New Version Notification for	draft-ietf-dane-use-cases-01
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 25 Apr 2011 03:30:02 -0000

> -----Original Message-----
> From: Richard L.Barnes [mailto:[e-mail]]
> Sent: Saturday, April 23, 2011 11:29 AM
> To: Jim Schaad
> Cc: [e-mail]
> Subject: Re: [dane] Fwd: New Version Notification for draft-ietf-dane-use-
> cases-01
> 
> Hey Jim,
> 
> Thanks for the comments.  Responses inline.
> 
> > Abstract:
> > 1.  "Traditionally, this
> >   authentication has been based on PKIX trust hierarchies, rooted in
> >   well-known CAs, but additional information can be provided via the
> >   DNS itself. "
> > I don't know that this is true based on the messages that have been
> > sent on the list.  Given the amount of apparent self-signed certs that
> > are used for TLS I don't think it can be said that this is the
> > tradition.  One might be able to say conceptually but not traditionally.
> 
> Well, I guess the self-signed case as it exists today is still PKIX, but
with very
> ad-hoc TA management.  I think the sense is probably clear enough to set
> context in the Abstract.
> 
> 
> 
> > 2.  The last sentence in this paragraph should refer to the new RFC on
> > how to do this process, since it is complicated and may depend on DNS
> > records not  mentioned above.
> 
> Are you referring to RFC 6125?  There's to that a reference in the next
> paragraph, which actually discusses the decision process.

Personal preference is to put this type of thing early or have something to
say I am expanding on this later.

> 
> > The reason for the restrict is now possibly down to Trent or Charlie.
> > Or it can be that there is a restriction to what Diane is permitted to
> > use (this is also the 3.2 example I assume.)
> >
> > The following  is not a use case?  I thought this was constantly
> > coming up on the list.
> > Alice runs the domain alice.example.com, but Diane (diane.example.com)
> > operates a TLS secured service for Alice.
> 
> So you're saying that publishing DANE records also constrains what certs
an
> outsourced service provider can use?  What's the threat here?

Yes, I would like this to happen.

If Diane is running a service for multiple people and is running it on the
same port, then no single DANE record published by Diane would correctly
state the CA restrictions that Alice wants to place on the certificates that
are to be used by Bob for contacting her.   Diane may, in the back end,
redirect the conversation from Bob based on the domain named passed in as
part of the TLS hello message and it would end up at a different server or
using different keys based on the party Bob wants to talk to.  However this
may still be all on one port.

So the situations are:
1.  Alice has the A/AAAA records in her DNS and can sign them along with the
DANE record, but Diane and Alice now need to have tight coordination if the
address and/or the DANE records change.

2.  Alice refers to Diane's DNS w/ a domain name and has no control over the
DANE, HASTLS or any other pieces under Diane's control.

3.  Alice can put DANE records into her DNS, but the address records are in
Diane's DNS.  This means that Alice can control the usage of certificates
but Diane is free to move the servers around as needed.  The only
coordination needed is when the certificates change, and then it would
depend on how the DANE record is setup (i.e. a CA or an EE certificate
pointer).

It is just as much in Alice's interest to restrict Diane from getting a
certificate from a CA that Alice does not trust as it is to not allow Bob to
validate to such a certificate if an attacker gets it into Alice's systems.

> 
> 
> > 3.2 is, I assume supposed to be a restriction on the EE certificate -
> > and thus would restrict both Bob and Diane in what they can do.
> 
> I think that going into that level of detail in this document isn't really
> necessary -- we can just say that the cert we're concerned about is "the
cert
> for the server" regardless of the specific characteristics of that cert.
But
> you're correct that the DANE record also constrains Diane.
> 

I find the term "the certificate for the server" to be sufficiently fuzzy
that I can never be too sure what it is referring to.   If I have the chain
of certs Trent->Charlie->Alice->Alice's Service.  Section 3.2 could be
talking about the cert for Alice or the cert for Alice's Service.  Both of
those certificates are presented, but if the cert for Alice is presented it
could be under section 3.1 or under section 3.2.  Also I find it hard to
believe that the security constraints are the same.  If the really are the
same then I don't understand any need to distinguish between sections 3.1
and 3.2.  I assume there is a real reason for presenting them as separate
cases, but in that case they need to be readily distinguished.

> 
> > In 3.3 - there are now two different cases that can come about.  1)
> > Alice is now running her own CA that is not well-known or trusted and
> > 2) Alice wants Bob to trust Trent (or maybe Charlie), but Bob does not
> > either by default or by policy.
> 
> Two valid cases, but they look basically the same from a technical point
of
> view: Either way, it's a TA that the rest of the world doesn't know about.
> How about a clarifying sentence at the end of the second paragraph of 3.3
(or
> possibly as a separate para):
> "
> [In dramatis personae:]
> Trent: A CA that issues certificates with domain names as identifiers, but
is
> not generally well-known.
> 
> This use case is functionally equivalent to the case where Alice doesn't
issue
> her own certificates, but uses a CA Trent that is not well-known.  In this
case,
> Alice would be advising Bob that he should treat Trent as a trust anchor
for
> purposes of validating Alice's certificates.
> "

In my mind there is a vast difference, especially in the way things should
be treated, between three different cases here:

1.  The trust anchor certificate claims to be owned by and signed by Alice
and is referenced in Alice's DNS records
2.  The trust anchor certificate is owned by Trent, who is not well known to
Bob but is vouched for by Alice in Alice's DNS record, and
3.  The trust anchor certificate is owned by Trish, who is well known to Bob
and is either explicitly not trusted or maybe even distrusted, but is
vouched for by Alice in Alice's DNS record.

The way and amount of trust that Bob might give in each of these cases is
vastly different going to - Yes I might automatically trust to I would never
trust.


> 
> 
> > Section 4 - Other Requirements
> >
> > In some cases is the statement about Encapsulation correct?  In the
> > event of an SRV or CNAME or MX record (and so forth).  Should you be
> > able to make statements about the party that is actually going to
> > provide the services if they are outsourced?
> 
> This seems like an application-layer question, and it depends on a few
things,
> such as (1) whether the outsourcing is done securely or insecurely, and
(2)
> whether the outsourcing is visible to the client (via CNAME/MX/etc) or not
> (via A/AAAA).  For example, if you get a secure SRV to a different domain,
> that seems like an explicit, secure delegation of services, in which case
the
> client is OK to authenticate the outsourcing provider directly.
> 
> All of these questions, though, relate to what name a client is looking
for.  So
> there is a clean interface to DANE:
> 1. Identify the name of the service you want to connect to (either the
> starting name or the name of the outsourcing provider) 2. Use DANE + TLS
to
> authenticate that name
> 
> (And regardless of these distinctions, the domain owner still has control
by
> choosing how to outsource, and whom to outsource to.  It's just a question
> of whether the control is in SRV or TLSA.)
> 
> Net of these concerns, I think the encapsulation requirement is still
correct.

See above.

> 
> 
> > Predictability - Given that we are making statements that we don't
> > care about cases where things like SRV records exist.  What is the
> > likelihood that protocols are going to want to change the DANE behavior
> about thinks
> > like encapsulation and which DANE record formats exist.   How are you
> > defining PKIX information in this case given that it can be defined by
> > different protocols and how the domain information is dealt with in
> > those cases is going to be treated differently.  Are you going to
> > define the DANE values as inputs to the PKIX path validation process?
> > So that they are constrained by name constraints?
> 
> In this case, we have exactly one set of PKIX information, the cert chain
in
> the TLS handshake.  DANE will address whether that cert properly
represents
> a domain; applications can choose which domain to use, and check other
> things if they want.  DANE will probably override some of RFC 6125, but
that's
> part of the idea.  These are also more questions for the mechanism draft,
> rather than use cases / requirements.
> 

I don't believe DANE addresses if a cert properly represents a domain
(depending on how you parse that language).  I believe it is addressing
issues of does a Domain represent that a certificate should be trusted for a
domain.   Overriding behavior of 6125 is not, in my mind, a way to lead to
predictability, issues of that type should be left strictly up to the
application/protocol in question.  I think that this may be a very hard
thing to produce given other issues.

> 
> > For the Wild Cards and CNAME items, does this mean we need to have a
> > BCP statement for how to fill in your DNS so that people will get it
correct?
> 
> Of course, general advice about configuring DNS properly is not the domain
> (haha) of this group, but of DNSOP.  I would think that we would have some
> provisioning advice in our documents, though, at the level of
> RECOMMENDED patterns.

However this is a security protocol, and misconfiguration is a security
issue.  As such, I believe that this is an important issue to be covered.

> 
> 
> 



From [e-mail]  Mon Apr 25 06:30:39 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B119AE0747 for <[e-mail]>; Mon, 25 Apr 2011 06:30:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.024
X-Spam-Level: 
X-Spam-Status: No, score=-3.024 tagged_above=-999 required=5 tests=[AWL=0.574,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3OCuftsx4bK for <[e-mail]>; Mon, 25 Apr 2011 06:30:38 -0700 (PDT)
Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfc.amsl.com (Postfix) with ESMTP id 18F0CE0746 for <[e-mail]>; Mon, 25 Apr 2011 06:30:38 -0700 (PDT)
Received: by gwb20 with SMTP id 20so804702gwb.31 for <[e-mail]>; Mon, 25 Apr 2011 06:30:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=JCttcVhSSEZkZ3D7CbthpPctBs6BygelQ3KBe5LqGEA=; b=NnkKICAxzpuH73/Vq2d7DdRwrEE2PrIOySKYNV/BlZVXzjndMAgbZmJIk+SvR/lePC RWqwXwR0Ico1U3aa6N7TDRsMSSrgJaxmZJI+aZY8Yu5cRSdc8oN6pMl6FkpFE3EdJu5i MjqWWgAtKwSmH7LeIJs/y8Mo3e7yqDht3ECzo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=JjMXwY3lcXBS2OlWiS8TavuLDkQWSZZFOB0zb1DQ3ETL98XojOsqqmUidqaNcUVxVU tCl5vd/gS3Lt0ZjQWxGqQjAkNtidw8rHHLSYt15N8V+gyu4zzkpK0NeIq5ii4v4Gfxwv mR5R81CqAPb6l/FjD+p/yZymTezTMDynnpT6I=
MIME-Version: 1.0
Received: by 10.101.191.34 with SMTP id t34mr2131362anp.31.1303738237763; Mon, 25 Apr 2011 06:30:37 -0700 (PDT)
Received: by 10.100.9.12 with HTTP; Mon, 25 Apr 2011 06:30:37 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Mon, 25 Apr 2011 09:30:37 -0400
Message-ID: <BANLkTinTfRXpE6bS_=[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: "Richard L. Barnes" <[e-mail]>
Content-Type: multipart/alternative; boundary=001636ef0ac48abf7a04a1be3640
Cc: IETF DANE WG list <[e-mail]>
Subject: Re: [dane] Fwd: New Version Notification for draft-ietf-dane-use-cases-01
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 25 Apr 2011 13:30:39 -0000

--001636ef0ac48abf7a04a1be3640
Content-Type: text/plain; charset=ISO-8859-1

The way that I look at this problem is that key discovery is actually a
special case of the generalized service discovery problem.

This makes little difference in terms of order of operations but it has some
implications for extensibility requirements.


So when a client is trying to connect up to a Web Service the starting point
for the process is that the client knows only the domain name of the Web
Service and the protocol identifier. The client's objective is to find the
'best' connection to that Web Service according to criteria that are decided
by the client.

Amongst the criteria that would be relevant are:

* Application protocol supported
* Protocol version supported
* Security enhancements offered
* Security enhancements mandated (strict security)
* Trust assertions offered
* Redundancy
* Endpoint identifier

I don't think we want to address all of those in DANE, but I do want to have
an extensible framework that allows them to be supported. Its not that
difficult to do either. Tag-Value pairs have done just fine for SMTP and
HTTP.

Basically the difference that shows through in the architecture is how
special cases are handled. At the moment the proposal is to use prefix
records, which allows the special case 'many hosts' to be addressed.
Essentially we have taken one specific special case and made it the general
case.

A few iterations back we had a proposal where the client first looked for
the general case and only did more if it was told there was special handling
required. With a few small changes, that approach provides for a general
framework that is capable of being arbitrarily expressive.


What this comes down to is whether you see DANE as being an Application
protocol or a DNS protocol. It is a DNS record certainly, but its purpose is
to support an application protocol which is why I see the application layer
idiom of tag-value pairs as being more appropriate as a design.

On Sun, Apr 24, 2011 at 10:36 PM, Richard L. Barnes <[e-mail]> wrote:

> Ok, thanks for being a little clearer.  So the question is then how all
> this translates into use cases / requirements for DANE.
>
> It seems like to the extent that these systems are labeling service points
> with HTTPS URIs and using 2818-style authentication, the existing use cases
> cover web services as well.
>
> Are you suggesting that clients should be able to use some sort of
> supra-HTTP-layer identifiers to look up keys/certs using DANE?  If so, that
> seems pretty different from what people have generally envisioned this
> technology to cover, namely looking up keys/certs based on domain names.
>
> --Richard
>
>
>
> On Apr 23, 2011, at 10:53 PM, Phillip Hallam-Baker wrote:
>
> > Web Services are generally understood to be machine-machine protocols
> running over the 'Web' platform.
> >
> > That minimally means using URIs as identifiers, DNS as the naming scheme
> but in the typical case also means layering over HTTP as transport.
> >
> > There are two main camps in Web Services, SOAP and non-SOAP (usually
> referred to as REST regardless of whether it is). At this point it seems
> fairly settled that both are to be called 'Web Services'. There is something
> of an ideological divide and both sides probably have a point.
> >
> > SOAP is really designed to make it easy to wrap a network wrapper around
> an existing piece of infrastructure like a .COM library or an SQL database.
> It provides little if any value for protocols like SAML or XKMS which are
> scratch built and use their own security mechanisms. Both would run just as
> well over raw HTTP as far as I can remember.
> >
> >
> > I am aware of the WS-* series of specifications being an author of the
> original proposal and an editor of the OASIS spec. They are not designed to
> provide security at the same layer as TLS though. TLS gives transport layer
> security while WS-* is message layer. So WS-* can deliver non-repudiation
> while TLS secures both the body and the headers. Both are needed.
> >
> > Its the same situation with email. There are pros and cons to using
> S/MIME and TLS and neither is really a complete substitute for the other.
> >
> > WS-* is deeply embedded in SOAP anyway, so it only works for some Web
> Services.
> >
> >
> > The big challenge in both cases is that we have been lacking a model for
> how Web Services work out what security enhancements are on offer and how to
> apply them. In the original scheme proposed by Microsoft and IBM, this was
> going to be the job of UDDI. But that went the way of every other 'replace
> the DNS' project to date leaving a hole in the Web Services architecture.
> >
> > Most Web Services use TLS for security today and not WS-*. But the
> approach to doing so is pretty ad hoc and confused. There is a real
> opportunity there to clarify matters.
> >
> >
> > On Sat, Apr 23, 2011 at 2:47 PM, =JeffH <[e-mail]>
> wrote:
> > >> That does not work very well for Web Services because there are
> typically
> > >> multiple services on the same port.
> > >>
> > >> It can probably be made to work, but the spec has to explain how to
> make
> > >> it work.
> > >
> > >
> > > Could you be a little more explicit?
> >
> > Indeed -- i.e. what do you (PHB) mean by "web services" ?   There's a
> plethora of things out there calling themselves "web services".
> >
> > thanks,
> >
> > =JeffH
> >
> >
> > _______________________________________________
> > dane mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dane
> >
> >
> >
> > --
> > Website: http://hallambaker.com/
> >
> > _______________________________________________
> > dane mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dane
>
>


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

--001636ef0ac48abf7a04a1be3640
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

The way that I look at this problem is that key discovery is actually a spe=
cial case of the generalized service discovery problem.<div><br></div><div>=
This makes little difference in terms of order of operations but it has som=
e implications for extensibility requirements.=A0</div>
<div><br></div><div><br></div><div>So when a client is trying to connect up=
 to a Web Service the starting point for the process is that the client kno=
ws only the domain name of the Web Service and the protocol identifier. The=
 client&#39;s objective is to find the &#39;best&#39; connection to that We=
b Service according to criteria that are decided by the client.</div>
<div><br></div><div>Amongst the criteria that would be relevant are:</div><=
div><br></div><div>* Application protocol supported=A0</div><div>* Protocol=
 version supported</div><div>* Security enhancements offered</div><div>* Se=
curity enhancements mandated (strict security)</div>
<div>* Trust assertions offered</div><div>* Redundancy</div><div>* Endpoint=
 identifier<br><div><br></div><div>I don&#39;t think we want to address all=
 of those in DANE, but I do want to have an extensible framework that allow=
s them to be supported. Its not that difficult to do either. Tag-Value pair=
s have done just fine for SMTP and HTTP.=A0</div>
<div><br></div><div>Basically the difference that shows through in the arch=
itecture is how special cases are handled. At the moment the proposal is to=
 use prefix records, which allows the special case &#39;many hosts&#39; to =
be addressed. Essentially we have taken one specific special case and made =
it the general case.</div>
<div><br></div><div>A few iterations back we had a proposal where the clien=
t first looked for the general case and only did more if it was told there =
was special handling required. With a few small changes, that approach prov=
ides for a general framework that is capable of being arbitrarily expressiv=
e.</div>
<div><br></div><div><br></div><div>What this comes down to is whether you s=
ee DANE as being an Application protocol or a DNS protocol. It is a DNS rec=
ord certainly, but its purpose is to support an application protocol which =
is why I see the application layer idiom of tag-value pairs as being more a=
ppropriate as a design.</div>
<div><br><div class=3D"gmail_quote">On Sun, Apr 24, 2011 at 10:36 PM, Richa=
rd L. Barnes <span dir=3D"ltr">&lt;<a href=3D"mailto:[e-mail]">rbarn=
[e-mail]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Ok, thanks for being a little clearer. =A0So the question is then how all t=
his translates into use cases / requirements for DANE.<br>
<br>
It seems like to the extent that these systems are labeling service points =
with HTTPS URIs and using 2818-style authentication, the existing use cases=
 cover web services as well.<br>
<br>
Are you suggesting that clients should be able to use some sort of supra-HT=
TP-layer identifiers to look up keys/certs using DANE? =A0If so, that seems=
 pretty different from what people have generally envisioned this technolog=
y to cover, namely looking up keys/certs based on domain names.<br>

<font color=3D"#888888"><br>
--Richard<br>
</font><div><div></div><div class=3D"h5"><br>
<br>
<br>
On Apr 23, 2011, at 10:53 PM, Phillip Hallam-Baker wrote:<br>
<br>
&gt; Web Services are generally understood to be machine-machine protocols =
running over the &#39;Web&#39; platform.<br>
&gt;<br>
&gt; That minimally means using URIs as identifiers, DNS as the naming sche=
me but in the typical case also means layering over HTTP as transport.<br>
&gt;<br>
&gt; There are two main camps in Web Services, SOAP and non-SOAP (usually r=
eferred to as REST regardless of whether it is). At this point it seems fai=
rly settled that both are to be called &#39;Web Services&#39;. There is som=
ething of an ideological divide and both sides probably have a point.<br>

&gt;<br>
&gt; SOAP is really designed to make it easy to wrap a network wrapper arou=
nd an existing piece of infrastructure like a .COM library or an SQL databa=
se. It provides little if any value for protocols like SAML or XKMS which a=
re scratch built and use their own security mechanisms. Both would run just=
 as well over raw HTTP as far as I can remember.<br>

&gt;<br>
&gt;<br>
&gt; I am aware of the WS-* series of specifications being an author of the=
 original proposal and an editor of the OASIS spec. They are not designed t=
o provide security at the same layer as TLS though. TLS gives transport lay=
er security while WS-* is message layer. So WS-* can deliver non-repudiatio=
n while TLS secures both the body and the headers. Both are needed.<br>

&gt;<br>
&gt; Its the same situation with email. There are pros and cons to using S/=
MIME and TLS and neither is really a complete substitute for the other.<br>
&gt;<br>
&gt; WS-* is deeply embedded in SOAP anyway, so it only works for some Web =
Services.<br>
&gt;<br>
&gt;<br>
&gt; The big challenge in both cases is that we have been lacking a model f=
or how Web Services work out what security enhancements are on offer and ho=
w to apply them. In the original scheme proposed by Microsoft and IBM, this=
 was going to be the job of UDDI. But that went the way of every other &#39=
;replace the DNS&#39; project to date leaving a hole in the Web Services ar=
chitecture.<br>

&gt;<br>
&gt; Most Web Services use TLS for security today and not WS-*. But the app=
roach to doing so is pretty ad hoc and confused. There is a real opportunit=
y there to clarify matters.<br>
&gt;<br>
&gt;<br>
&gt; On Sat, Apr 23, 2011 at 2:47 PM, =3DJeffH &lt;<a href=3D"mailto:Jeff.H=
[e-mail]">[e-mail]</a>&gt; wrote:<br>
&gt; &gt;&gt; That does not work very well for Web Services because there a=
re typically<br>
&gt; &gt;&gt; multiple services on the same port.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; It can probably be made to work, but the spec has to explain =
how to make<br>
&gt; &gt;&gt; it work.<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; Could you be a little more explicit?<br>
&gt;<br>
&gt; Indeed -- i.e. what do you (PHB) mean by &quot;web services&quot; ? =
=A0 There&#39;s a plethora of things out there calling themselves &quot;web=
 services&quot;.<br>
&gt;<br>
&gt; thanks,<br>
&gt;<br>
&gt; =3DJeffH<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; dane mailing list<br>
&gt; <a href=3D"mailto:[e-mail]">[e-mail]</a><br>
&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_blan=
k">https://www.ietf.org/mailman/listinfo/dane</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt; Website: <a href=3D"http://hallambaker.com/" target=3D"_blank">http://=
hallambaker.com/</a><br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; dane mailing list<br>
&gt; <a href=3D"mailto:[e-mail]">[e-mail]</a><br>
&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_blan=
k">https://www.ietf.org/mailman/listinfo/dane</a><br>
<br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a=
 href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div></div>

--001636ef0ac48abf7a04a1be3640--

From [e-mail]  Mon Apr 25 09:50:00 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2ED12E0749 for <[e-mail]>; Mon, 25 Apr 2011 09:50:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.83
X-Spam-Level: 
X-Spam-Status: No, score=-100.83 tagged_above=-999 required=5 tests=[AWL=-0.525, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_BL_SPAMCOP_NET=1.96, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Up9vwkyoQ8+i for <[e-mail]>; Mon, 25 Apr 2011 09:49:59 -0700 (PDT)
Received: from oproxy5-pub.bluehost.com (oproxy5-pub.bluehost.com [67.222.39.38]) by ietfc.amsl.com (Postfix) with SMTP id 58ACEE0674 for <[e-mail]>; Mon, 25 Apr 2011 09:49:58 -0700 (PDT)
Received: (qmail 5404 invoked by uid 0); 25 Apr 2011 16:49:58 -0000
Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy2.bluehost.com with SMTP; 25 Apr 2011 16:49:58 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=J47ORlZbOkOxvPCgNLQey2yIqYQP+7NMCgkhb1KAcoZ20rNRatXoz2TLbPTeALFboaiOEcLNGKwuuVZtKSs08GhHq/SgS6q5iktwlISQ98MCIgBD3O7UBgZFIEGgu/zE;
Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.137.171]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <[e-mail]>) id 1QEOyz-0006g6-Ou for [e-mail]; Mon, 25 Apr 2011 10:49:57 -0600
Message-ID: <[e-mail]>
Date: Mon, 25 Apr 2011 09:49:57 -0700
From: =JeffH <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8
MIME-Version: 1.0
To: IETF DANE WG list <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com}
Subject: Re: [dane] Fwd: New Version Notification for draft-ietf-dane-use-cases-01
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 25 Apr 2011 16:50:00 -0000

 > Web Services are generally understood to be machine-machine protocols
 > running over the 'Web' platform.
 >
 > That minimally means using URIs as identifiers, DNS as the naming scheme but
 > in the typical case also means layering over HTTP as transport.
 >
 > There are two main camps in Web Services, SOAP and non-SOAP (usually
 > referred to as REST regardless of whether it is). At this point it seems
 > fairly settled that both are to be called 'Web Services'. There is something
 > of an ideological divide and both sides probably have a point.

thx, that answers the question wrt the breadth of the (ambiguous) term "web 
services" when you use it.

It's even more ambiguous because there's multiple SOAP-based "web services 
stacks" and "web services architectures", not only ws-* (e.g. Liberty).

but that's off topic for this list.

=JeffH



From [e-mail]  Mon Apr 25 10:14:06 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C8E33E06AE for <[e-mail]>; Mon, 25 Apr 2011 10:14:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.735
X-Spam-Level: 
X-Spam-Status: No, score=-101.735 tagged_above=-999 required=5 tests=[AWL=0.530, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Un2XYuQ8FsS for <[e-mail]>; Mon, 25 Apr 2011 10:14:06 -0700 (PDT)
Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfc.amsl.com (Postfix) with SMTP id B7CF5E068A for <[e-mail]>; Mon, 25 Apr 2011 10:14:05 -0700 (PDT)
Received: (qmail 15823 invoked by uid 0); 25 Apr 2011 17:14:04 -0000
Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy3.bluehost.com with SMTP; 25 Apr 2011 17:14:04 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=GA5mVS5jrxeX+kq7/qK+O3x/3QNjy7BeHzoO1eJJaaw+H2yhNrUjLxLynbVCz0SM3je4EbF9rFhxb+QKHFWB4xbwcjgDB6sXVHvM2YiRiweIPE05SANXK/hDm26tahgD;
Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.137.171]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <[e-mail]>) id 1QEPMK-0008Dj-DV for [e-mail]; Mon, 25 Apr 2011 11:14:04 -0600
Message-ID: <[e-mail]>
Date: Mon, 25 Apr 2011 10:14:03 -0700
From: =JeffH <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8
MIME-Version: 1.0
To: IETF DANE WG list <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com}
Subject: Re: [dane] DANE mech semantics and RFC6125 (was: Fwd: New Version Notification for draft-ietf-dane-use-cases-01)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 25 Apr 2011 17:14:06 -0000

"Jim Schaad" <[e-mail]> replied:
 >  "'Richard L.Barnes'" <[e-mail]> said
 >> In this case, we have exactly one set of PKIX information, the cert chain
 >> in the TLS handshake.  DANE will address whether that cert properly
 >> represents a domain; applications can choose which domain to use, and
 >> check other things if they want.  DANE will probably override some of RFC
 >> 6125, but that's part of the idea.  These are also more questions for the
 >> mechanism draft, rather than use cases / requirements.
 >
 > I don't believe DANE addresses if a cert properly represents a domain
 > (depending on how you parse that language).  I believe it is addressing
 > issues of does a Domain represent that a certificate should be trusted for a
 > domain. ..

I tend to agree with Jim's assessment here. To me, the draft DANE mechanism 
allows a domain administrator, of a particular domain name, to assert that one 
must receive certs certified by a particular CA, or particular certs, during 
TLS establishment with the end entity host whose network address is obtained by 
dereferencing that particular domain name.


 > ..  Overriding behavior of 6125 is not, in my mind, a way to lead to
 > predictability, issues of that type should be left strictly up to the
 > application/protocol in question. ...

agreed in the sense that RFC6125 is strictly about *application layer dns 
domain name matching* in the context of PKIX certs and TLS establishment. IMHO, 
it prescribes matching/checking that an app service client implementation 
really should perform, whether or not the DANE mechanism is employed and 
successfully verifies during the TLS handshake.

If there's anything anyone sees in RFC6125 that is in conflict with the above 
assessment, please explicitly identify it.

thanks,

=JeffH



From [e-mail]  Mon Apr 25 15:18:22 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4C8E0683 for <[e-mail]>; Mon, 25 Apr 2011 15:18:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEUQOs6Ig6XL for <[e-mail]>; Mon, 25 Apr 2011 15:18:22 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA5CE066F for <[e-mail]>; Mon, 25 Apr 2011 15:18:19 -0700 (PDT)
Received: from ros-dhcp192-1-51-22.bbn.com ([192.1.51.22]:60577) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from <[e-mail]>) id 1QEU6k-000GPg-9L; Mon, 25 Apr 2011 18:18:18 -0400
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: "Richard L. Barnes" <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Mon, 25 Apr 2011 18:18:12 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]>
To: =JeffH <[e-mail]>
X-Mailer: Apple Mail (2.1082)
Cc: IETF DANE WG list <[e-mail]>
Subject: Re: [dane] DANE mech semantics and RFC6125 (was: Fwd: New Version Notification for draft-ietf-dane-use-cases-01)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 25 Apr 2011 22:18:22 -0000

> > I don't believe DANE addresses if a cert properly represents a =
domain
> > (depending on how you parse that language).  I believe it is =
addressing
> > issues of does a Domain represent that a certificate should be =
trusted for a
> > domain. ..
>=20
> I tend to agree with Jim's assessment here. To me, the draft DANE =
mechanism allows a domain administrator, of a particular domain name, to =
assert that one must receive certs certified by a particular CA, or =
particular certs, during TLS establishment with the end entity host =
whose network address is obtained by dereferencing that particular =
domain name.

This seems like mostly an issue of wording to me.  Care to suggest =
something?


> > ..  Overriding behavior of 6125 is not, in my mind, a way to lead to
> > predictability, issues of that type should be left strictly up to =
the
> > application/protocol in question. ...
>=20
> agreed in the sense that RFC6125 is strictly about *application layer =
dns domain name matching* in the context of PKIX certs and TLS =
establishment. IMHO, it prescribes matching/checking that an app service =
client implementation really should perform, whether or not the DANE =
mechanism is employed and successfully verifies during the TLS =
handshake.
>=20
> If there's anything anyone sees in RFC6125 that is in conflict with =
the above assessment, please explicitly identify it.

Fair enough.  Perhaps a better way to say it is that DANE is an =
independent check to RFC 6125, which applications / clients can choose =
to take or leave.  Sort of like the various checks that mail servers =
apply to vet other MTAs that send them mail.  Is there a text impact =
here?

--Richard




From [e-mail]  Mon Apr 25 20:18:32 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12786E06C3 for <[e-mail]>; Mon, 25 Apr 2011 20:18:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.58
X-Spam-Level: 
X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 j0fk7wDh5JOX for <[e-mail]>; Mon, 25 Apr 2011 20:18:31 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 62681E06B7 for <[e-mail]>; Mon, 25 Apr 2011 20:18:28 -0700 (PDT)
Received: from [128.89.253.196] (port=61813 helo=[192.168.1.10]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from <[e-mail]>) id 1QEYnD-000BZ4-PP; Mon, 25 Apr 2011 23:18:27 -0400
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: "Richard L. Barnes" <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Mon, 25 Apr 2011 23:18:25 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]>
To: =JeffH <[e-mail]>
X-Mailer: Apple Mail (2.1082)
Cc: IETF DANE WG list <[e-mail]>
Subject: Re: [dane] Fwd: New Version Notification for draft-ietf-dane-use-cases-01
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 26 Apr 2011 03:18:32 -0000

> > Web Services are generally understood to be machine-machine =
protocols
> > running over the 'Web' platform.
> >
> > That minimally means using URIs as identifiers, DNS as the naming =
scheme but
> > in the typical case also means layering over HTTP as transport.
> >
> > There are two main camps in Web Services, SOAP and non-SOAP (usually
> > referred to as REST regardless of whether it is). At this point it =
seems
> > fairly settled that both are to be called 'Web Services'. There is =
something
> > of an ideological divide and both sides probably have a point.
>=20
> thx, that answers the question wrt the breadth of the (ambiguous) term =
"web services" when you use it.
>=20
> It's even more ambiguous because there's multiple SOAP-based "web =
services stacks" and "web services architectures", not only ws-* (e.g. =
Liberty).

Thanks to both of you for making this a little more concrete.

As I said before, it seems like the document already supports these =
services to the extent that they use URIs as identifiers and DNS as a =
naming scheme.  If there's a further authentication (e.g., of individual =
SOAP message handlers?) that you think should also be supported, could =
you please write a 1-2 paragraph use case?

Thanks,
--Richard=

From [e-mail]  Mon Apr 25 21:17:04 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED6BEE06CA for <[e-mail]>; Mon, 25 Apr 2011 21:17:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.581
X-Spam-Level: 
X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 1jf++-dsjXzS for <[e-mail]>; Mon, 25 Apr 2011 21:17:04 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id CD685E067C for <[e-mail]>; Mon, 25 Apr 2011 21:17:03 -0700 (PDT)
Received: from [128.89.253.196] (port=62280 helo=[192.168.1.10]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from <[e-mail]>) id 1QEZhu-000BtG-LY; Tue, 26 Apr 2011 00:17:03 -0400
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: "Richard L. Barnes" <[e-mail]>
In-Reply-To: <000001cc02fc$b6afcb10$240f6130$@augustcellars.com>
Date: Tue, 26 Apr 2011 00:17:00 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <012301cc016d$14b103f0$3e130bd0$@augustcellars.com> <[e-mail]> <000001cc02fc$b6afcb10$240f6130$@augustcellars.com>
To: Jim Schaad <[e-mail]>
X-Mailer: Apple Mail (2.1082)
Cc: [e-mail]
Subject: Re: [dane] Fwd: New Version Notification for	draft-ietf-dane-use-cases-01
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 26 Apr 2011 04:17:05 -0000

>>> 2.  The last sentence in this paragraph should refer to the new RFC =
on
>>> how to do this process, since it is complicated and may depend on =
DNS
>>> records not  mentioned above.
>>=20
>> Are you referring to RFC 6125?  There's to that a reference in the =
next
>> paragraph, which actually discusses the decision process.
>=20
> Personal preference is to put this type of thing early or have =
something to
> say I am expanding on this later.

Think I'm going to leave this as-is.  The difference is only from one =
sentence to the next.


>>> The reason for the restrict is now possibly down to Trent or =
Charlie.
>>> Or it can be that there is a restriction to what Diane is permitted =
to
>>> use (this is also the 3.2 example I assume.)
>>>=20
>>> The following  is not a use case?  I thought this was constantly
>>> coming up on the list.
>>> Alice runs the domain alice.example.com, but Diane =
(diane.example.com)
>>> operates a TLS secured service for Alice.
>>=20
>> So you're saying that publishing DANE records also constrains what =
certs
> an
>> outsourced service provider can use?  What's the threat here?
>=20
> Yes, I would like this to happen.
>=20
> If Diane is running a service for multiple people and is running it on =
the
> same port, then no single DANE record published by Diane would =
correctly
> state the CA restrictions that Alice wants to place on the =
certificates that
> are to be used by Bob for contacting her.   Diane may, in the back =
end,
> redirect the conversation from Bob based on the domain named passed in =
as
> part of the TLS hello message and it would end up at a different =
server or
> using different keys based on the party Bob wants to talk to.  However =
this
> may still be all on one port.
>=20
> So the situations are:
> 1.  Alice has the A/AAAA records in her DNS and can sign them along =
with the
> DANE record, but Diane and Alice now need to have tight coordination =
if the
> address and/or the DANE records change.
>=20
> 2.  Alice refers to Diane's DNS w/ a domain name and has no control =
over the
> DANE, HASTLS or any other pieces under Diane's control.
>=20
> 3.  Alice can put DANE records into her DNS, but the address records =
are in
> Diane's DNS.  This means that Alice can control the usage of =
certificates
> but Diane is free to move the servers around as needed.  The only
> coordination needed is when the certificates change, and then it would
> depend on how the DANE record is setup (i.e. a CA or an EE certificate
> pointer).
>=20
> It is just as much in Alice's interest to restrict Diane from getting =
a
> certificate from a CA that Alice does not trust as it is to not allow =
Bob to
> validate to such a certificate if an attacker gets it into Alice's =
systems.

OK, I think I get this.  The idea is that the owner of the domain might =
use DANE to constrain not only what certificates CAs can issue (and =
still be accepted by clients), but also what certificates outsourcing =
providers can use.

It doesn't seem like this is a fully independent use case, since at base =
what's happening is that Alice is making assertions about her domain.  =
I've added the following text to Sections 3, 3.1, 3.2
"
Oscar: An outsourcing provider that operates TLS-protected services on =
behalf of customers.
...
In addition to guarding against CA mis-issue, CA constraints can also be =
used to constrain the set of certificates that can be used by an =
outsourcing provider.  Suppose that Oscar operates alice.example.com on =
behalf of Alice.  In particular, Oscar then has de facto control over =
what certificates to present in TLS handshakes for alice.example.com.  =
Alice can use the same mechanism for advising about CA constraints to =
advise Bob that Oscar should present a certificate under a given CA.
...
As in Section 3.1., Alice's assertions about server certificates can be =
used to constrain the behavior of an outsourcing provider Oscar as well =
as the CA Charlie and other CAs.  Such a certificate constraint requires =
Oscar to present the specified certificate to clients and not another.
"

The specific provisioning cases are valuable, but probably better suited =
for the mechanism document.




> I find the term "the certificate for the server" to be sufficiently =
fuzzy
> that I can never be too sure what it is referring to.   If I have the =
chain
> of certs Trent->Charlie->Alice->Alice's Service.  Section 3.2 could be
> talking about the cert for Alice or the cert for Alice's Service.  =
Both of
> those certificates are presented, but if the cert for Alice is =
presented it
> could be under section 3.1 or under section 3.2.  Also I find it hard =
to
> believe that the security constraints are the same.  If the really are =
the
> same then I don't understand any need to distinguish between sections =
3.1
> and 3.2.  I assume there is a real reason for presenting them as =
separate
> cases, but in that case they need to be readily distinguished.

Actually, I thought the term "certificate for the server" was one of the =
more concrete terms in the document -- it's the one with the public key =
that Bob uses to compute the PreMasterSecret in TLS.  In RFC 5246 terms, =
it's the first cert in the certificate_list payload:
"
   certificate_list
      This is a sequence (chain) of certificates.  The sender's
      certificate MUST come first in the list.  Each following
      certificate MUST directly certify the one preceding it.  Because
      certificate validation requires that root keys be distributed
      independently, the self-signed certificate that specifies the root
      certificate authority MAY be omitted from the chain, under the
      assumption that the remote end must already possess it in order to
      validate it in any case.
"

I was trying to avoid saying "EE cert", because that explicitly places a =
constraint on the form of the certificate beyond what TLS says (which =
puts it beyond this WG's remit). Instead, the intent of 3.1 and 3.2 is =
to say:

3.1. The indicated cert MUST appear in the certificate_list
3.2. The indicated cert MUST be the first in the certificate_list

I'll try to be a little more explicit about this:
"
In TLS terms, Alice is letting Bob know that Charlie's certificate must =
appear somewhere in the server Certificate message certificate_list =
structure.
...
In TLS terms, Alice is letting Bob know that her certificate must appear =
as the first certificate in the server Certificate message.
"

The security concerns are different, as discussed in the use case: 3.1. =
addresses other CAs, while 3.2. addresses Charlie.  The other concerns, =
namely the way that this changes the balance of power between the DNS =
operator and the CA, are the same between the two cases.  I've changed =
the text in 3.2. to say "The other security considerations..."



> In my mind there is a vast difference, especially in the way things =
should
> be treated, between three different cases here:
>=20
> 1.  The trust anchor certificate claims to be owned by and signed by =
Alice
> and is referenced in Alice's DNS records
> 2.  The trust anchor certificate is owned by Trent, who is not well =
known to
> Bob but is vouched for by Alice in Alice's DNS record, and
> 3.  The trust anchor certificate is owned by Trish, who is well known =
to Bob
> and is either explicitly not trusted or maybe even distrusted, but is
> vouched for by Alice in Alice's DNS record.
>=20
> The way and amount of trust that Bob might give in each of these cases =
is
> vastly different going to - Yes I might automatically trust to I would =
never
> trust.

As with PKIX certificates, it's always up to Bob to decide who he =
trusts.  All DANE is doing is letting Alice assert who she thinks should =
be trusted.  Ignoring Bob, cases 2 and 3 are the same.

Nonetheless, this might be a good comment for the mechanism document, =
which might note that a relying party MAY apply additional criteria =
beyond DANE to decide whether or not to accept a DANE-asserted TA.  For =
example, checking against a white- or black-list as you suggest.


> I don't believe DANE addresses if a cert properly represents a domain
> (depending on how you parse that language).  I believe it is =
addressing
> issues of does a Domain represent that a certificate should be trusted =
for a
> domain.   Overriding behavior of 6125 is not, in my mind, a way to =
lead to
> predictability, issues of that type should be left strictly up to the
> application/protocol in question.  I think that this may be a very =
hard
> thing to produce given other issues.

See my responses to =3DJeffH. =20

Summary:
1. Glad to change wording.
2. "Override" is the wrong word; these are independent checks/assertions =
from 6125 and apps can decide how to composite them.


>> Of course, general advice about configuring DNS properly is not the =
domain
>> (haha) of this group, but of DNSOP.  I would think that we would have =
some
>> provisioning advice in our documents, though, at the level of
>> RECOMMENDED patterns.
>=20
> However this is a security protocol, and misconfiguration is a =
security
> issue.  As such, I believe that this is an important issue to be =
covered.

Definitely agree.  But I see this more as a mechanism / implementation =
issue than a use case / requirements issue. =20


From [e-mail]  Tue Apr 26 20:44:20 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1DFE0686 for <[e-mail]>; Tue, 26 Apr 2011 20:44:20 -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 BJRUHo3+P2Xc for <[e-mail]>; Tue, 26 Apr 2011 20:44:19 -0700 (PDT)
Received: from new-smtp01.pacifier.net (new-smtp01.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 084E7E0685 for <[e-mail]>; Tue, 26 Apr 2011 20:44:19 -0700 (PDT)
Received: from TITUS (50-39-220-175.bvtn.or.frontiernet.net [50.39.220.175]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: [e-mail]) by new-smtp01.pacifier.net (Postfix) with ESMTPSA id 490352CA3E; Tue, 26 Apr 2011 20:44:18 -0700 (PDT)
From: "Jim Schaad" <[e-mail]>
To: "'Richard L. Barnes'" <[e-mail]>
References: <[e-mail]> <[e-mail]> <012301cc016d$14b103f0$3e130bd0$@augustcellars.com> <[e-mail]> <000001cc02fc$b6afcb10$240f6130$@augustcellars.com> <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Tue, 26 Apr 2011 21:10:28 -0700
Message-ID: <009401cc0491$0b8fe350$22afa9f0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQNyg4lXwmk6n5EjxFLUypP4wfIz8wGfclnvAZ9YaK0BM4arjAIoMlFgAkG9vTiQ3TY3IA==
Content-Language: en-us
Cc: [e-mail]
Subject: Re: [dane] Fwd: New Version Notification for	draft-ietf-dane-use-cases-01
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 27 Apr 2011 03:44:20 -0000

> -----Original Message-----
> From: Richard L. Barnes [mailto:[e-mail]]
> Sent: Monday, April 25, 2011 9:17 PM
> To: Jim Schaad
> Cc: [e-mail]
> Subject: Re: [dane] Fwd: New Version Notification for draft-ietf-dane-use-
> cases-01
> 
> >>> 2.  The last sentence in this paragraph should refer to the new RFC
> >>> on how to do this process, since it is complicated and may depend on
> >>> DNS records not  mentioned above.
> >>
> >> Are you referring to RFC 6125?  There's to that a reference in the
> >> next paragraph, which actually discusses the decision process.
> >
> > Personal preference is to put this type of thing early or have
> > something to say I am expanding on this later.
> 
> Think I'm going to leave this as-is.  The difference is only from one
sentence
> to the next.
> 
> 
> >>> The reason for the restrict is now possibly down to Trent or Charlie.
> >>> Or it can be that there is a restriction to what Diane is permitted
> >>> to use (this is also the 3.2 example I assume.)
> >>>
> >>> The following  is not a use case?  I thought this was constantly
> >>> coming up on the list.
> >>> Alice runs the domain alice.example.com, but Diane
> >>> (diane.example.com) operates a TLS secured service for Alice.
> >>
> >> So you're saying that publishing DANE records also constrains what
> >> certs
> > an
> >> outsourced service provider can use?  What's the threat here?
> >
> > Yes, I would like this to happen.
> >
> > If Diane is running a service for multiple people and is running it on
> > the same port, then no single DANE record published by Diane would
> > correctly state the CA restrictions that Alice wants to place on the
> certificates that
> > are to be used by Bob for contacting her.   Diane may, in the back end,
> > redirect the conversation from Bob based on the domain named passed in
> > as part of the TLS hello message and it would end up at a different
> > server or using different keys based on the party Bob wants to talk
> > to.  However this may still be all on one port.
> >
> > So the situations are:
> > 1.  Alice has the A/AAAA records in her DNS and can sign them along
> > with the DANE record, but Diane and Alice now need to have tight
> > coordination if the address and/or the DANE records change.
> >
> > 2.  Alice refers to Diane's DNS w/ a domain name and has no control
> > over the DANE, HASTLS or any other pieces under Diane's control.
> >
> > 3.  Alice can put DANE records into her DNS, but the address records
> > are in Diane's DNS.  This means that Alice can control the usage of
> > certificates but Diane is free to move the servers around as needed.
> > The only coordination needed is when the certificates change, and then
> > it would depend on how the DANE record is setup (i.e. a CA or an EE
> > certificate pointer).
> >
> > It is just as much in Alice's interest to restrict Diane from getting
> > a certificate from a CA that Alice does not trust as it is to not
> > allow Bob to validate to such a certificate if an attacker gets it into
Alice's
> systems.
> 
> OK, I think I get this.  The idea is that the owner of the domain might
use
> DANE to constrain not only what certificates CAs can issue (and still be
> accepted by clients), but also what certificates outsourcing providers can
use.
> 
> It doesn't seem like this is a fully independent use case, since at base
what's
> happening is that Alice is making assertions about her domain.  I've added
> the following text to Sections 3, 3.1, 3.2 "
> Oscar: An outsourcing provider that operates TLS-protected services on
> behalf of customers.
> ...
> In addition to guarding against CA mis-issue, CA constraints can also be
used
> to constrain the set of certificates that can be used by an outsourcing
> provider.  Suppose that Oscar operates alice.example.com on behalf of
Alice.
> In particular, Oscar then has de facto control over what certificates to
present
> in TLS handshakes for alice.example.com.  Alice can use the same mechanism
> for advising about CA constraints to advise Bob that Oscar should present
a
> certificate under a given CA.
> ...
> As in Section 3.1., Alice's assertions about server certificates can be
used to
> constrain the behavior of an outsourcing provider Oscar as well as the CA
> Charlie and other CAs.  Such a certificate constraint requires Oscar to
present
> the specified certificate to clients and not another.
> "
> 
> The specific provisioning cases are valuable, but probably better suited
for
> the mechanism document.
> 

I would like to disagree.  I think that I have presented many interesting
and useful, for the purposes of discussion, cases that, while variations on
a theme, are important things that need to be considered in how the other
documents progress.  One could just as easily say - oh no they belong in the
implementation guidelines document.   But in any case of all of these
nuances are not captured here then we can basically say that all of them are
unimportant as only those which would be implemented by the main document
could ever be covered.  I.e. I don't expect it to say what it cannot due in
cases where it was not told that it needed to do it.

> 
> 
> 
> > I find the term "the certificate for the server" to be sufficiently
fuzzy
> > that I can never be too sure what it is referring to.   If I have the
chain
> > of certs Trent->Charlie->Alice->Alice's Service.  Section 3.2 could be
> > talking about the cert for Alice or the cert for Alice's Service.
> > Both of those certificates are presented, but if the cert for Alice is
> > presented it could be under section 3.1 or under section 3.2.  Also I
> > find it hard to believe that the security constraints are the same.
> > If the really are the same then I don't understand any need to
> > distinguish between sections 3.1 and 3.2.  I assume there is a real
> > reason for presenting them as separate cases, but in that case they need
to
> be readily distinguished.
> 
> Actually, I thought the term "certificate for the server" was one of the
more
> concrete terms in the document -- it's the one with the public key that
Bob
> uses to compute the PreMasterSecret in TLS.  In RFC 5246 terms, it's the
first
> cert in the certificate_list payload:
> "

A much better term would be "certificate for the service" as the server may
have multiple certificates for different services and a single service could
have the same public key used by multiple servers.

>    certificate_list
>       This is a sequence (chain) of certificates.  The sender's
>       certificate MUST come first in the list.  Each following
>       certificate MUST directly certify the one preceding it.  Because
>       certificate validation requires that root keys be distributed
>       independently, the self-signed certificate that specifies the root
>       certificate authority MAY be omitted from the chain, under the
>       assumption that the remote end must already possess it in order to
>       validate it in any case.
> "
> 
> I was trying to avoid saying "EE cert", because that explicitly places a
> constraint on the form of the certificate beyond what TLS says (which puts
it
> beyond this WG's remit). Instead, the intent of 3.1 and 3.2 is to say:
> 
> 3.1. The indicated cert MUST appear in the certificate_list 3.2. The
indicated
> cert MUST be the first in the certificate_list
> 
> I'll try to be a little more explicit about this:
> "
> In TLS terms, Alice is letting Bob know that Charlie's certificate must
appear
> somewhere in the server Certificate message certificate_list structure.
> ...
> In TLS terms, Alice is letting Bob know that her certificate must appear
as the
> first certificate in the server Certificate message.
> "
> 
> The security concerns are different, as discussed in the use case: 3.1.
> addresses other CAs, while 3.2. addresses Charlie.  The other concerns,
> namely the way that this changes the balance of power between the DNS
> operator and the CA, are the same between the two cases.  I've changed the
> text in 3.2. to say "The other security considerations..."
> 

See above suggested text change - talking about the service certificate
rather than the server certificate makes it clear what certificate is being
discussed.

> 
> 
> > In my mind there is a vast difference, especially in the way things
> > should be treated, between three different cases here:
> >
> > 1.  The trust anchor certificate claims to be owned by and signed by
> > Alice and is referenced in Alice's DNS records 2.  The trust anchor
> > certificate is owned by Trent, who is not well known to Bob but is
> > vouched for by Alice in Alice's DNS record, and 3.  The trust anchor
> > certificate is owned by Trish, who is well known to Bob and is either
> > explicitly not trusted or maybe even distrusted, but is vouched for by
> > Alice in Alice's DNS record.
> >
> > The way and amount of trust that Bob might give in each of these cases
> > is vastly different going to - Yes I might automatically trust to I
> > would never trust.
> 
> As with PKIX certificates, it's always up to Bob to decide who he trusts.
All
> DANE is doing is letting Alice assert who she thinks should be trusted.
> Ignoring Bob, cases 2 and 3 are the same.
> 
> Nonetheless, this might be a good comment for the mechanism document,
> which might note that a relying party MAY apply additional criteria beyond
> DANE to decide whether or not to accept a DANE-asserted TA.  For example,
> checking against a white- or black-list as you suggest.
> 

And is also good to have in this document.  It may be that the main DANE
documents will choose to ignore this case as they currently do not discuss
many of these types of issues.  They are left up to the protocol or
implementation.

> 
> > I don't believe DANE addresses if a cert properly represents a domain
> > (depending on how you parse that language).  I believe it is
> > addressing issues of does a Domain represent that a certificate should
be
> trusted for a
> > domain.   Overriding behavior of 6125 is not, in my mind, a way to lead
to
> > predictability, issues of that type should be left strictly up to the
> > application/protocol in question.  I think that this may be a very
> > hard thing to produce given other issues.
> 
> See my responses to =JeffH.
> 
> Summary:
> 1. Glad to change wording.
> 2. "Override" is the wrong word; these are independent checks/assertions
> from 6125 and apps can decide how to composite them.
> 
> 
> >> Of course, general advice about configuring DNS properly is not the
> >> domain
> >> (haha) of this group, but of DNSOP.  I would think that we would have
> >> some provisioning advice in our documents, though, at the level of
> >> RECOMMENDED patterns.
> >
> > However this is a security protocol, and misconfiguration is a
> > security issue.  As such, I believe that this is an important issue to
be
> covered.
> 
> Definitely agree.  But I see this more as a mechanism / implementation
issue
> than a use case / requirements issue.

I needed to go back and figure out what this was in response to.  I believe
that this is a valid topic to be addressed in the security considerations
section.

jim


From [e-mail]  Wed Apr 27 11:25:17 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF01E0769 for <[e-mail]>; Wed, 27 Apr 2011 11:25:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.089
X-Spam-Level: 
X-Spam-Status: No, score=-3.089 tagged_above=-999 required=5 tests=[AWL=0.509,  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 gt++5Nv3eval for <[e-mail]>; Wed, 27 Apr 2011 11:25:15 -0700 (PDT)
Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by ietfa.amsl.com (Postfix) with ESMTP id 6478CE06BC for <[e-mail]>; Wed, 27 Apr 2011 11:25:15 -0700 (PDT)
Received: by gxk28 with SMTP id 28so1114538gxk.27 for <[e-mail]>; Wed, 27 Apr 2011 11:25:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=xnqh/41RMu3Ui1gak0xgUIf9GgNwI/CSMyt0OO+o6kQ=; b=aYbzaFlUGaNT7+KgyP2IYEHk+JjHrjIatTpccNWezl/rhNuJv2Lvb3/o+7bMrpWvug 2p4AE7aSAjP8lXIU1M+wcSy9v0kY3LmQvZrAjK9KDDQUshrp2VeCauSPnbUEPqmMoCOa JmRVuPMKqFNpifdCwTKQOmVkPfzQbFmlSDJZw=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Foc/zh6AQpabJuZW7oYFgdfuHRcya82msM5+hMYLzxbedyU1GRjxNSsNTHOrJUl7Yr hiDsLF5asbHKpW0jp+K4CwifhMuEUIB7VeEJsQjFlSKljn3AhDZ8F3PpkZXsXsT9EMxf LhIA5NxFb19GAOcYucN5jOGQ+OZ4EWaoG1lwY=
MIME-Version: 1.0
Received: by 10.100.115.10 with SMTP id n10mr1651197anc.119.1303928714440; Wed, 27 Apr 2011 11:25:14 -0700 (PDT)
Received: by 10.100.239.4 with HTTP; Wed, 27 Apr 2011 11:25:14 -0700 (PDT)
Date: Wed, 27 Apr 2011 14:25:14 -0400
Message-ID: <BANLkTi=Ud98JARqsCO=[e-mail]>
From: Phillip Hallam-Baker <[e-mail]>
To: [e-mail]
Content-Type: multipart/alternative; boundary=0016e644cf92d632ef04a1ea8f82
Subject: [dane] Requested Use Cases
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 27 Apr 2011 18:25:17 -0000

--0016e644cf92d632ef04a1ea8f82
Content-Type: text/plain; charset=ISO-8859-1

OK here are the additional use cases for Web Services and for motivating
promiscuous security.


Use Case: Promiscuous Security in Web Browsing

Alice wishes to publish her Web site so that Bob will always have the
benefit of the best security his client is capable of without resulting in a
negative user experience when using a legacy browser. In particular Bob uses
two browsers on different machines, one is a legacy browser that does not
support DANE and cannot be updated, the other is a browser that has full
support for DANE.

Derived requirement: An enabled client must be able to determine that DANE
security is available for a site.


Use Case: DNS Driven Web Services

A Web Service is an Internet protocol designed to support direct
machine-to-machine communication without the intervention of a human
operator or other form of supervisor. Since Web Services are application
protocols, the one aspect of Internet architecture that is essential as far
as a Web Service is concerned is that the DNS be used as the naming system
for service discovery.

Web Services typically evolve over time. A service provider must frequently
support legacy clients alongside new and in many cases multiple versions of
each protocol.

Discovering the certificates or keys to be used to secure the connection to
the Web service represents merely one aspect of the more general problem of
Web Service property discovery.


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

--0016e644cf92d632ef04a1ea8f82
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

OK here are the additional use cases for Web Services and for motivating pr=
omiscuous security.<div><br></div><div><br></div><div>Use Case: Promiscuous=
 Security in Web Browsing</div><div><br></div><div>Alice wishes to publish =
her Web site so that Bob will always have the benefit of the best security =
his client is capable of without resulting in a negative user experience wh=
en using a legacy browser. In particular Bob uses two browsers on different=
 machines, one is a legacy browser that does not support DANE and cannot be=
 updated, the other is a browser that has full support for DANE.</div>
<div><br></div><div>Derived requirement: An enabled client must be able to =
determine that DANE security is available for a site.</div><div><br></div><=
div><br></div><div>Use Case: DNS Driven Web Services</div><div><br></div>
<div>A Web Service is an Internet protocol designed to support direct machi=
ne-to-machine communication without the intervention of a human operator or=
 other form of supervisor. Since Web Services are application protocols, th=
e one aspect of Internet architecture that is essential as far as a Web Ser=
vice is concerned is that the DNS be used as the naming system for service =
discovery.</div>
<div><br></div><div>Web Services typically evolve over time. A service prov=
ider must frequently support legacy clients alongside new and in many cases=
 multiple versions of each protocol.</div><div><br></div><div>Discovering t=
he certificates or keys to be used to secure the connection to the Web serv=
ice represents merely one aspect of the more general problem of Web Service=
 property discovery.</div>
<div><br></div><div><br>-- <br>Website: <a href=3D"http://hallambaker.com/"=
>http://hallambaker.com/</a><br><br>
</div>

--0016e644cf92d632ef04a1ea8f82--

From [e-mail]  Wed Apr 27 21:31:15 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D184BE0682 for <[e-mail]>; Wed, 27 Apr 2011 21:31:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.583
X-Spam-Level: 
X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 p3QwbVpOCvof for <[e-mail]>; Wed, 27 Apr 2011 21:31:15 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 134C9E0680 for <[e-mail]>; Wed, 27 Apr 2011 21:31:15 -0700 (PDT)
Received: from [128.89.253.235] (port=61900 helo=[192.168.1.10]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from <[e-mail]>) id 1QFIsj-0001Oz-PD; Thu, 28 Apr 2011 00:31:14 -0400
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: "Richard L. Barnes" <[e-mail]>
In-Reply-To: <BANLkTi=Ud98JARqsCO=[e-mail]>
Date: Thu, 28 Apr 2011 00:31:11 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <BANLkTi=Ud98JARqsCO=[e-mail]>
To: Phillip Hallam-Baker <[e-mail]>
X-Mailer: Apple Mail (2.1082)
Cc: [e-mail]
Subject: Re: [dane] Requested Use Cases
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 28 Apr 2011 04:31:15 -0000

Thanks, these are good.  I'll get them added.
--Richard

On Apr 27, 2011, at 2:25 PM, Phillip Hallam-Baker wrote:

> OK here are the additional use cases for Web Services and for =
motivating promiscuous security.
>=20
>=20
> Use Case: Promiscuous Security in Web Browsing
>=20
> Alice wishes to publish her Web site so that Bob will always have the =
benefit of the best security his client is capable of without resulting =
in a negative user experience when using a legacy browser. In particular =
Bob uses two browsers on different machines, one is a legacy browser =
that does not support DANE and cannot be updated, the other is a browser =
that has full support for DANE.
>=20
> Derived requirement: An enabled client must be able to determine that =
DANE security is available for a site.
>=20
>=20
> Use Case: DNS Driven Web Services
>=20
> A Web Service is an Internet protocol designed to support direct =
machine-to-machine communication without the intervention of a human =
operator or other form of supervisor. Since Web Services are application =
protocols, the one aspect of Internet architecture that is essential as =
far as a Web Service is concerned is that the DNS be used as the naming =
system for service discovery.
>=20
> Web Services typically evolve over time. A service provider must =
frequently support legacy clients alongside new and in many cases =
multiple versions of each protocol.
>=20
> Discovering the certificates or keys to be used to secure the =
connection to the Web service represents merely one aspect of the more =
general problem of Web Service property discovery.
>=20
>=20
> --=20
> Website: http://hallambaker.com/
>=20
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane


From [e-mail]  Wed Apr 27 21:43:26 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA22E0696 for <[e-mail]>; Wed, 27 Apr 2011 21:43:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.584
X-Spam-Level: 
X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hA259KHF9ZwM for <[e-mail]>; Wed, 27 Apr 2011 21:43:25 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 5D54DE0680 for <[e-mail]>; Wed, 27 Apr 2011 21:43:25 -0700 (PDT)
Received: from [128.89.253.235] (port=61928 helo=[192.168.1.10]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from <[e-mail]>) id 1QFJ4W-0001Y8-Ge; Thu, 28 Apr 2011 00:43:24 -0400
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: "Richard L. Barnes" <[e-mail]>
In-Reply-To: <009401cc0491$0b8fe350$22afa9f0$@augustcellars.com>
Date: Thu, 28 Apr 2011 00:43:24 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <012301cc016d$14b103f0$3e130bd0$@augustcellars.com> <[e-mail]> <000001cc02fc$b6afcb10$240f6130$@augustcellars.com> <[e-mail]> <009401cc0491$0b8fe350$22afa9f0$@augustcellars.com>
To: Jim Schaad <[e-mail]>
X-Mailer: Apple Mail (2.1082)
Cc: [e-mail]
Subject: Re: [dane] Fwd: New Version Notification for	draft-ietf-dane-use-cases-01
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 28 Apr 2011 04:43:26 -0000

> I would like to disagree.  I think that I have presented many =
interesting
> and useful, for the purposes of discussion, cases that, while =
variations on
> a theme, are important things that need to be considered in how the =
other
> documents progress.  One could just as easily say - oh no they belong =
in the
> implementation guidelines document.   But in any case of all of these
> nuances are not captured here then we can basically say that all of =
them are
> unimportant as only those which would be implemented by the main =
document
> could ever be covered.  I.e. I don't expect it to say what it cannot =
due in
> cases where it was not told that it needed to do it.

Ok, fair enough.  I'll pull this stuff into an independent use case.  =
I'll send you some proposed text off-list to avoid thread bloat.



> A much better term would be "certificate for the service" as the =
server may
> have multiple certificates for different services and a single service =
could
> have the same public key used by multiple servers.

The term "server" is well-defined in TLS, in that TLS is a client-server =
protocol.  So a server in TLS is actually what you're calling a service.

I've added a note to the Terminology section to clarify:
"
Note in particular that the term "server" in this document refers to the =
server role in TLS, rather than to a physical server.  Multiple servers =
of this type may be co-located on a single physical server, using =
different ports, and each of these can use different certificates.
"


>> As with PKIX certificates, it's always up to Bob to decide who he =
trusts.
> All
>> DANE is doing is letting Alice assert who she thinks should be =
trusted.
>> Ignoring Bob, cases 2 and 3 are the same.
>>=20
>> Nonetheless, this might be a good comment for the mechanism document,
>> which might note that a relying party MAY apply additional criteria =
beyond
>> DANE to decide whether or not to accept a DANE-asserted TA.  For =
example,
>> checking against a white- or black-list as you suggest.
>>=20
>=20
> And is also good to have in this document.  It may be that the main =
DANE
> documents will choose to ignore this case as they currently do not =
discuss
> many of these types of issues.  They are left up to the protocol or
> implementation.

Suggested additional text for 3.3:
"
Alice's advertising of trust anchor material in this way does not =
guarantee that Bob will accept the advertised trust anchor.  For =
example, Bob might have out-of-band information (such as a pre-existing =
local policy) that indicates that the CA Trent advertised by Alice is =
not trustworthy, which would lead him to decide not to accept Trent as a =
TA, and thus to reject Alice's certificate if it is issued under Trent. =20=

"



From [e-mail]  Thu Apr 28 10:22:45 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 117C6E0729 for <[e-mail]>; Thu, 28 Apr 2011 10:22:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eg5R06ZcS8I7 for <[e-mail]>; Thu, 28 Apr 2011 10:22:43 -0700 (PDT)
Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id D4435E0728 for <[e-mail]>; Thu, 28 Apr 2011 10:22:42 -0700 (PDT)
Received: from dot.her.corp.google.com (unknown [74.202.225.33]) by vimes.kumari.net (Postfix) with ESMTPSA id 1C78A1B40930; Thu, 28 Apr 2011 13:22:42 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Warren Kumari <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Thu, 28 Apr 2011 13:22:40 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
To: Richard L. Barnes <[e-mail]>
X-Mailer: Apple Mail (2.1084)
Cc: [e-mail]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 28 Apr 2011 17:22:45 -0000

Hi all,

It has now been just over a week since this came out (but it fells much =
much longer) and it has generated a large amount of traffic and =
comments. That said, it feels to me like we have covered the largest =
issues and are moving towards having some consensus...

So, I would like us to start wrapping up the discussions soon so that we =
(well, Richard :-P) can get -02 out, we can review it to make sure that =
folk are happy and have been heard, and then move to WGLC.

Please note: I'm not trying to censor / limit anyone, but rather trying =
to avoid us moving into the pontificating and navel gazing stage...=20

W


On Apr 20, 2011, at 2:39 PM, Richard L. Barnes wrote:

> This document is an attempt to capture
> (1) A brief problem statement,
> (2) The three main use cases discussed on the list, and
> (3) A few additional requirements =20
>=20
> Thanks especially to Eric, Zack, and Phil, from whom most of the =
underlying material is drawn.
>=20
> Comments are welcome.
>=20
> --Richard=20
>=20
>=20
> On Apr 20, 2011, at 2:30 PM, [e-mail] wrote:
>=20
>> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
>> This draft is a work item of the DNS-based Authentication of Named =
Entities Working Group of the IETF.
>>=20
>>=20
>> 	Title           : Use Cases and Requirements for DNS-based =
Authentication of Named Entities
>> 	Author(s)       : R. Barnes
>> 	Filename        : draft-ietf-dane-use-cases-00.txt
>> 	Pages           : 8
>> 	Date            : 2011-04-20
>>=20
>> Many current applications use the certificate-based authentication
>> features in TLS to allow clients to verify that a connected server
>> properly represents a desired domain name.  Traditionally, this
>> authentication has been based on PKIX trust hierarchies, rooted in
>> well-known CAs, but additional information can be provided via the
>> DNS itself.  This document describes a set of use cases in which the
>> DNS and DNSSEC could be used to make assertions that support the TLS
>> authentication process.
>>=20
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-dane-use-cases-00.txt
>>=20
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>=20
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>> <Mail Attachment>_______________________________________________
>> dane mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dane
>=20
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane
>=20


From [e-mail]  Thu Apr 28 11:08:32 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 790F4E06C8 for <[e-mail]>; Thu, 28 Apr 2011 11:08:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.583
X-Spam-Level: 
X-Spam-Status: No, score=-101.583 tagged_above=-999 required=5 tests=[AWL=0.682, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 Kw8xeLk+y6GE for <[e-mail]>; Thu, 28 Apr 2011 11:08:31 -0700 (PDT)
Received: from oproxy5-pub.bluehost.com (oproxy5-pub.bluehost.com [67.222.39.38]) by ietfa.amsl.com (Postfix) with SMTP id C3FC8E0670 for <[e-mail]>; Thu, 28 Apr 2011 11:08:31 -0700 (PDT)
Received: (qmail 31506 invoked by uid 0); 28 Apr 2011 18:08:31 -0000
Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy2.bluehost.com with SMTP; 28 Apr 2011 18:08:31 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=GRdC8wsdSR9NxcKDlgUuNa1U2D2O9t+NzAhevWQDB62AnwCYkIqLlv2QDZfY6hGVTBpAud8BElB7tWOI9kLVV4jE5TPK60v3XddNUxZjOmFYSCS7gomGpJLYrWAGdYz6;
Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.136.202]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <[e-mail]>) id 1QFVdf-0007bI-24 for [e-mail]; Thu, 28 Apr 2011 12:08:31 -0600
Message-ID: <[e-mail]>
Date: Thu, 28 Apr 2011 11:08:30 -0700
From: =JeffH <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8
MIME-Version: 1.0
To: IETF DANE WG list <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com}
Subject: Re: [dane] Fwd: New Version Notification for draft-ietf-dane-use-cases-01
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 28 Apr 2011 18:08:32 -0000

 >> A much better term would be "certificate for the service" as the server
 >> may have multiple certificates for different services and a single
 >> service could have the same public key used by multiple servers.
 >
 > The term "server" is well-defined in TLS, in that TLS is a client-server
 > protocol.  So a server in TLS is actually what you're calling a service.
 >
 > I've added a note to the Terminology section to clarify: " Note in
 > particular that the term "server" in this document refers to the server
 > role in TLS, rather than to a physical server.  Multiple servers of this
 > type may be co-located on a single physical server, using different ports,
 > and each of these can use different certificates. "

Good, I was about to suggest this.

Also, we might want/need to define "single physical server" as a "host", but
can wait to see.


thanks,

=JeffH



From [e-mail]  Thu Apr 28 11:08:57 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A49E6E0698 for <[e-mail]>; Thu, 28 Apr 2011 11:08:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.848
X-Spam-Level: 
X-Spam-Status: No, score=-101.848 tagged_above=-999 required=5 tests=[AWL=0.751, 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 TYDZJjqMJBqR for <[e-mail]>; Thu, 28 Apr 2011 11:08:57 -0700 (PDT)
Received: from oproxy1-pub.bluehost.com (oproxy1-pub.bluehost.com [66.147.249.253]) by ietfa.amsl.com (Postfix) with SMTP id 22E30E0670 for <[e-mail]>; Thu, 28 Apr 2011 11:08:57 -0700 (PDT)
Received: (qmail 27922 invoked by uid 0); 28 Apr 2011 18:08:56 -0000
Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy1.bluehost.com with SMTP; 28 Apr 2011 18:08:56 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=RxCKKuRe8HwPNdTj33EUML9JSM2S2p2TZk/Fi2Sopx36sNQxoFJSWjcyxGBJN4BdxyE/aFF53HHfgqtYrQvcBHianHbuaK8CW5Ktf6JaATsZA3L7hf+TBq+t+IHnl88Q;
Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.136.202]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <[e-mail]>) id 1QFVe4-000817-CJ for [e-mail]; Thu, 28 Apr 2011 12:08:56 -0600
Message-ID: <[e-mail]>
Date: Thu, 28 Apr 2011 11:08:56 -0700
From: =JeffH <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8
MIME-Version: 1.0
To: IETF DANE WG list <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com}
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 28 Apr 2011 18:08:57 -0000

 > I would like us to start wrapping up the discussions soon so that we (well,
 > Richard :-P) can get -02 out, we can review it to make sure that folk are
 > happy and have been heard, and then move to WGLC.

I will do a detailed review & feedback of the use cases doc, but am thinking I 
ought to do it on a -02 that incorps the settled feedback-so-far.

=JeffH


From [e-mail]  Thu Apr 28 12:14:55 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E021BE0670 for <[e-mail]>; Thu, 28 Apr 2011 12:14:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3U-J6gcnLeg for <[e-mail]>; Thu, 28 Apr 2011 12:14:55 -0700 (PDT)
Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 3584EE0669 for <[e-mail]>; Thu, 28 Apr 2011 12:14:54 -0700 (PDT)
Received: from dot.her.corp.google.com (unknown [74.202.225.33]) by vimes.kumari.net (Postfix) with ESMTPSA id 424111B40C3D; Thu, 28 Apr 2011 15:14:54 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Warren Kumari <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Thu, 28 Apr 2011 15:14:53 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]>
To: =JeffH <[e-mail]>
X-Mailer: Apple Mail (2.1084)
Cc: IETF DANE WG list <[e-mail]>
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 28 Apr 2011 19:14:56 -0000

On Apr 28, 2011, at 2:08 PM, =3DJeffH wrote:

> > I would like us to start wrapping up the discussions soon so that we =
(well,
> > Richard :-P) can get -02 out, we can review it to make sure that =
folk are
> > happy and have been heard, and then move to WGLC.
>=20
> I will do a detailed review & feedback of the use cases doc, but am =
thinking I ought to do it on a -02 that incorps the settled =
feedback-so-far.

Ok, I believe that Richard will submit -02 tonight / tomorrow, =
incorporating comments received so far, and then we will kick off WGLC.

W

>=20
> =3DJeffH
>=20
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane
>=20


From [e-mail]  Thu Apr 28 16:16:35 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC880E06A6 for <[e-mail]>; Thu, 28 Apr 2011 16:16:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.1
X-Spam-Level: 
X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[AWL=0.149,  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 Cr2BjMHkl0fu for <[e-mail]>; Thu, 28 Apr 2011 16:16:34 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 78F0EE06EC for <[e-mail]>; Thu, 28 Apr 2011 16:16:34 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p3SNGRJd029578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 29 Apr 2011 01:16:32 +0200 (MEST)
From: Martin Rex <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail] (=JeffH)
Date: Fri, 29 Apr 2011 01:16:27 +0200 (MEST)
In-Reply-To: <[e-mail]> from "=JeffH" at Apr 28, 11 11:08:30 am
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: [e-mail]
Subject: Re: [dane] Fwd: New Version Notification for
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: [e-mail]
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 28 Apr 2011 23:16:36 -0000

=JeffH wrote:
> 
>  >> A much better term would be "certificate for the service" as the server
>  >> may have multiple certificates for different services and a single
>  >> service could have the same public key used by multiple servers.
>  >
>  > The term "server" is well-defined in TLS, in that TLS is a client-server
>  > protocol.  So a server in TLS is actually what you're calling a service.
>  >
>  > I've added a note to the Terminology section to clarify: " Note in
>  > particular that the term "server" in this document refers to the server
>  > role in TLS, rather than to a physical server.  Multiple servers of this
>  > type may be co-located on a single physical server, using different ports,
>  > and each of these can use different certificates. "
> 
> Good, I was about to suggest this.
> 
> Also, we might want/need to define "single physical server" as a "host", but
> can wait to see.

I assume he meant that there could be many (virtual) host(names) all
pointing to the same physical server.  In order to support virtual
hosting with TLS, you either need TLS server certs with lots of
subjectAltNames, or support (and use) of the TLS extension
"server name indication" (SNI) by both, TLS client and TLS server.

"host" / "hostname" is an abstract logical/virtual concept of an entity,
and in general needs to be carefully distinguished from real servers.

-Martin

From [e-mail]  Thu Apr 28 20:51:34 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DBB0E06AE for <[e-mail]>; Thu, 28 Apr 2011 20:51:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.586
X-Spam-Level: 
X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.014, 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 2EHfWlr9rn6K for <[e-mail]>; Thu, 28 Apr 2011 20:51:34 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 25C6AE062B for <[e-mail]>; Thu, 28 Apr 2011 20:51:33 -0700 (PDT)
Received: from [128.89.254.3] (port=55178 helo=[192.168.1.10]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from <[e-mail]>) id 1QFejr-000IIZ-5C; Thu, 28 Apr 2011 23:51:31 -0400
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: "Richard L. Barnes" <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Thu, 28 Apr 2011 23:51:22 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]>
To: [e-mail]
X-Mailer: Apple Mail (2.1082)
Cc: [e-mail]
Subject: Re: [dane] Fwd: New Version Notification for
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 29 Apr 2011 03:51:34 -0000

>>> I've added a note to the Terminology section to clarify: " Note in
>>> particular that the term "server" in this document refers to the =
server
>>> role in TLS, rather than to a physical server.  Multiple servers of =
this
>>> type may be co-located on a single physical server, using different =
ports,
>>> and each of these can use different certificates. "
>>=20
>> Good, I was about to suggest this.
>>=20
>> Also, we might want/need to define "single physical server" as a =
"host", but
>> can wait to see.
>=20
> I assume he meant that there could be many (virtual) host(names) all
> pointing to the same physical server.  In order to support virtual
> hosting with TLS, you either need TLS server certs with lots of
> subjectAltNames, or support (and use) of the TLS extension
> "server name indication" (SNI) by both, TLS client and TLS server.
>=20
> "host" / "hostname" is an abstract logical/virtual concept of an =
entity,
> and in general needs to be carefully distinguished from real servers.

No, I actually meant what I wrote: Separate servers on separate ports.  =
Like, say, an SMTP server, an IMAP server, an XMPP server, and an HTTPS =
server.

It's not really this group's job to deal with distinguishing which host =
name the client should be looking for and which the server should =
present.  As you note, there are already existing technologies to do =
that, including multiple subjectAltNames, SNI, and STARTTLS. =20

--Richard=

From [e-mail]  Thu Apr 28 21:15:06 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28E7FE062B; Thu, 28 Apr 2011 21:15:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.469
X-Spam-Level: 
X-Spam-Status: No, score=-102.469 tagged_above=-999 required=5 tests=[AWL=0.131, 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 gA+vufdjjzSe; Thu, 28 Apr 2011 21:15:01 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A83ADE066F; Thu, 28 Apr 2011 21:15:01 -0700 (PDT)
MIME-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
From: [e-mail]
To: [e-mail]
X-Test-IDTracker: no
X-IETF-IDTracker: 3.52
Message-ID: <[e-mail]>
Date: Thu, 28 Apr 2011 21:15:01 -0700
Cc: [e-mail]
Subject: [dane] I-D Action:draft-ietf-dane-use-cases-02.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 29 Apr 2011 04:15:06 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF.


	Title           : Use Cases and Requirements for DNS-based Authentication of Named Entities (DANE)
	Author(s)       : R. Barnes
	Filename        : draft-ietf-dane-use-cases-02.txt
	Pages           : 11
	Date            : 2011-04-28

Many current applications use the certificate-based authentication
features in TLS to allow clients to verify that a connected server
properly represents a desired domain name.  Traditionally, this
authentication has been based on PKIX trust hierarchies, rooted in
well-known CAs, but additional information can be provided via the
DNS itself.  This document describes a set of use cases in which the
DNS and DNSSEC could be used to make assertions that support the TLS
authentication process.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dane-use-cases-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body; name="draft-ietf-dane-use-cases-02.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[e-mail]>


--NextPart--

From [e-mail]  Fri Apr 29 09:03:22 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABA2AE06AB for <[e-mail]>; Fri, 29 Apr 2011 09:03:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.449
X-Spam-Level: 
X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 oATZyQSkH3Jm for <[e-mail]>; Fri, 29 Apr 2011 09:03:18 -0700 (PDT)
Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 9F816E06A2 for <[e-mail]>; Fri, 29 Apr 2011 09:03:18 -0700 (PDT)
Received: from [172.19.118.237] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id E1C5C1B40C3D for <[e-mail]>; Fri, 29 Apr 2011 12:03:15 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1084)
From: Warren Kumari <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Fri, 29 Apr 2011 12:03:12 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]>
To: [e-mail]
X-Mailer: Apple Mail (2.1084)
Subject: [dane] Starting WGLC on: draft-ietf-dane-use-cases-02
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 29 Apr 2011 16:03:22 -0000

Hi all,

I think that Richard has integrated most of the comments received =
on-list into this most recent version of the doc and so, as I mentioned, =
we are going to kick off WGLC...

Please get y'er comments in --  WGLC will be closing on 2011-05-13 at =
16:00UTC (noonish EDT).

W

On Apr 29, 2011, at 12:15 AM, [e-mail] wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
> This draft is a work item of the DNS-based Authentication of Named =
Entities Working Group of the IETF.
>=20
>=20
> 	Title           : Use Cases and Requirements for DNS-based =
Authentication of Named Entities (DANE)
> 	Author(s)       : R. Barnes
> 	Filename        : draft-ietf-dane-use-cases-02.txt
> 	Pages           : 11
> 	Date            : 2011-04-28
>=20
> Many current applications use the certificate-based authentication
> features in TLS to allow clients to verify that a connected server
> properly represents a desired domain name.  Traditionally, this
> authentication has been based on PKIX trust hierarchies, rooted in
> well-known CAs, but additional information can be provided via the
> DNS itself.  This document describes a set of use cases in which the
> DNS and DNSSEC could be used to make assertions that support the TLS
> authentication process.
>=20
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-dane-use-cases-02.txt
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> <Mail Attachment>_______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane


From [e-mail]  Sat Apr 30 18:24:10 2011
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF86E06E8 for <[e-mail]>; Sat, 30 Apr 2011 18:24:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.487
X-Spam-Level: 
X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=0.113, 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 HhRCjt0QGpKl for <[e-mail]>; Sat, 30 Apr 2011 18:24:09 -0700 (PDT)
Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 329BEE0593 for <[e-mail]>; Sat, 30 Apr 2011 18:24:05 -0700 (PDT)
Received: from [172.19.118.237] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 8D1351B405EE; Sat, 30 Apr 2011 21:24:04 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Warren Kumari <[e-mail]>
In-Reply-To: <[e-mail]>
Date: Sat, 30 Apr 2011 21:24:02 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
To: Warren Kumari <[e-mail]>
X-Mailer: Apple Mail (2.1084)
Cc: [e-mail]
Subject: Re: [dane] Starting WGLC on: draft-ietf-dane-use-cases-02
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 01 May 2011 01:24:10 -0000

On Apr 29, 2011, at 12:03 PM, Warren Kumari wrote:

> Hi all,
>=20
> I think that Richard has integrated most of the comments received =
on-list into this most recent version of the doc and so, as I mentioned, =
we are going to kick off WGLC...
>=20
> Please get y'er comments in --  WGLC will be closing on 2011-05-13 at =
16:00UTC (noonish EDT).

Oh, also I wanted to make sure that everyone was aware / on the same =
page -- we are planning on releasing this as it's own doc (and not =
folding it into the other document).

W

>=20
> W
>=20
> On Apr 29, 2011, at 12:15 AM, [e-mail] wrote:
>=20
>> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
>> This draft is a work item of the DNS-based Authentication of Named =
Entities Working Group of the IETF.
>>=20
>>=20
>> 	Title           : Use Cases and Requirements for DNS-based =
Authentication of Named Entities (DANE)
>> 	Author(s)       : R. Barnes
>> 	Filename        : draft-ietf-dane-use-cases-02.txt
>> 	Pages           : 11
>> 	Date            : 2011-04-28
>>=20
>> Many current applications use the certificate-based authentication
>> features in TLS to allow clients to verify that a connected server
>> properly represents a desired domain name.  Traditionally, this
>> authentication has been based on PKIX trust hierarchies, rooted in
>> well-known CAs, but additional information can be provided via the
>> DNS itself.  This document describes a set of use cases in which the
>> DNS and DNSSEC could be used to make assertions that support the TLS
>> authentication process.
>>=20
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-dane-use-cases-02.txt
>>=20
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>=20
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>> <Mail Attachment>_______________________________________________
>> dane mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dane
>=20
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane
>=20