Subject: Re: [keyassure] HTTPS -> HTTP downgrade
From: "Jeffrey A. Williams" <[email-masked]>
To: [email-masked]
Date: Thu, 30 Dec 2010 12:35:09 -0600 (GMT-06:00)
List-Id: Key Assurance With DNSSEC <keyassure.ietf.org>

Phillip and all,

I could not agree more.  The key term here is "Willing".  PKI needen't have cost over $1b to

provide for a method by which the Military or any other government agency/department could

with relitive ease change over to a very secure email platform, and BTW clouds ain't it.

-----Original Message-----
From: Phillip Hallam-Baker
Sent: Dec 29, 2010 6:51 PM
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] HTTPS -> HTTP downgrade

Chatting on an iphone all day is somewhat tedious. An iPad on the other hand - no problem.

I think that is one of the changes that argues for restrictions to be thought through more carefully. But in general there are a whole rack of issues that mobile computers are bringing.

Trying to get institutions to take security realistically is really difficult. Recently we discovered that a French bank had lost over $1.2 billion due to an internal fraud. The relevant compliance records were kept using a manually updated excel spreadsheet. And last I heard, not a single one of the people responsible for that fiasco lost their jobs.

Over the last decade the US government has spent over a billion dollars on a PKI. Yet none of the emails sent out by the US military to journalists are signed and a low ranking clerk was allegedly able to extract and leak a quarter million classified diplomatic cables.

We have to deliver security in a form that people are willing to use.

On Thu, Dec 30, 2010 at 12:17 AM, Martin Rex <[email-masked]> wrote:

Phillip Hallam-Baker wrote:
>
> There is also a fairly important Wall Street use case.
>
> Regulators require banks to have complete archives of client-broker
> communications. So brokers connecting up to TLS protected Web sites from
> work machines becomes problematic. So some block TLS entirely.

So everyone is using their private SmartPhone to do HTTPS traffic?
... which also prevents any traces from improper communication
to ever get created on the work machines...

-Martin

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

Kindest regards,
Jeffrey A. Williams
"Obedience of the law is the greatest freedom" -
Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
Network security Eng. SR. Eng. Network data security,
IT/information security.
ABA member in good standing member ID 01257402
E-Mail [email-masked]
Phone: 214-244-4827

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B1EC3A6824 for ; Thu, 30 Dec 2010 08:40:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.097
X-Spam-Level:
X-Spam-Status: No, score=-8.097 tagged_above=-999 required=5 tests=[AWL=1.020, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, 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 A4CgWZuop1xT for ; Thu, 30 Dec 2010 08:40:44 -0800 (PST)
Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) by core3.amsl.com (Postfix) with ESMTP id D34E33A6821 for ; Thu, 30 Dec 2010 08:40:44 -0800 (PST)
DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:CC: Date:Subject:Thread-Topic:Thread-Index:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: x-ems-proccessed:x-ems-stamp:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=ITbOHQ8WfmI5/AXT0b25TLc45AxzBiP1D+NUsOCces01vVO/RXAjpeEj 6SFnDQhz8XTenLDBr8sRFLv7oEQ3/kjf6T6FIjXO4gE0h3FKKag7Md7Jx WvzdqAt3ZNJNtWy;
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=[email-masked]; q=dns/txt; s=ppinc; t=1293727371; x=1325263371; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; z=From:=20"Steingruebl,=20Andy"=20|To:=20"[email-masked]"=20|CC:=20"paul.h [email-masked]"=20,=20"keyassure@ ietf.org"=0D=0A=09|Date:=20Thu,=2030 =20Dec=202010=2009:42:49=20-0700|Subject:=20RE:=20[keyass ure]=20HTTPS=20->=20HTTP=20downgrade|Message-ID:=20<5EE04 [email-masked]. ebay.com>|References:=20<5EE049BA3C6538409BBE6F1760F328AB [email-masked]>=0D=0A=20from=20"S teingruebl,=20Andy"=20at=20Dec=2029,=2010=2005:08:21=20pm =0D=0A=20<[email-masked] >|In-Reply-To:=20<[email-masked]. sap.corp>|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=q55qvElHs2s1Gl1hPEaOED/Bad1XdICpiAGvtGQFhow=; b=aS/YoAs+KS+BtdHAswrK4hmtxGJDY0LClDflzKT2BJ8LOT4z9RyNMOt3 2EHvDaElp/7iFW3l9TsNQs7GSkR9o2zvXg6zoPo+iASkg2xItnI3xfLm1 OdODF07P9VZKwGf;
X-EBay-Corp: Yes
X-IronPort-AV: E=Sophos;i="4.60,250,1291622400"; d="scan'208";a="631440"
Received: from den-vtenf-002.corp.ebay.com (HELO DEN-MEXHT-002.corp.ebay.com) ([10.101.112.213]) by den-mipot-002.corp.ebay.com with ESMTP; 30 Dec 2010 08:42:50 -0800
Received: from DEN-MEXMS-001.corp.ebay.com ([10.241.16.225]) by DEN-MEXHT-002.corp.ebay.com ([10.241.17.53]) with mapi; Thu, 30 Dec 2010 09:42:49 -0700
From: "Steingruebl, Andy"
To: "[email-masked]"
Date: Thu, 30 Dec 2010 09:42:49 -0700
Thread-Topic: [keyassure] HTTPS -> HTTP downgrade
Thread-Index: AcunvDtDYNODjB0XTmeol4a61HS4jgAg3XBA
Message-ID: <[email-masked]>
References: <[email-masked]> from "Steingruebl, Andy" at Dec 29, 10 05:08:21 pm <[email-masked]>
In-Reply-To: <[email-masked]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A==
x-ems-stamp: Lbs6VdU9Y/TarOY0fE8pdg==
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter: Scanned
Cc: "[email-masked]" , "[email-masked]"
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 30 Dec 2010 16:40:46 -0000

> From: Martin Rex [mailto:[email-masked]]
>=20
> sslstrip is used to make it _appear_ as if "https://www.paypal.com" is us=
ed,
> although at the TLS protocol level, a completely different IDNS hostname =
is
> involved.
>
> See page 91ff of this presentation:
> http://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-
> DC-09-Marlinspike-Defeating-SSL.pdf
>=20
> If you're targetting a very specific server, you will _not_ need a wildca=
rd cert.

Not sure what this has to do with HSTS on PayPal itself? You're rewriting =
the source target page, not PayPal. The attack in a sense isn't directly a=
gainst paypal.com, but any page that is non-HTTPS that is hosting a link to=
PayPal.com. OK, but given that sslstrip is an attack that is about confus=
ing the UI, and a lot of people don't notice when it is in action, faked ce=
rtificates, etc. aren't really even necessary.

I'm just not sure why you think PayPal is specifically interesting for this=
attack? If the user gets MiTM's on a domain that isn't paypal.com, I'm co=
ncerned, but there also isn't a lot I can do directly about that in the con=
text of HTTPS, HSTS, etc. I'll admit ebay.com is a special case of this of=
course given the relationship between them, and something I'm investigatin=
g.

Can you more clearly explain why you think this attack has anything to do w=
ith HSTS, and PayPal specifically?

- Andy

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37E1828C136 for ; Wed, 29 Dec 2010 16:53:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.15
X-Spam-Level:
X-Spam-Status: No, score=-10.15 tagged_above=-999 required=5 tests=[AWL=0.099, 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 lNtXMXiPTK1N for ; Wed, 29 Dec 2010 16:53:08 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 969E228C132 for ; Wed, 29 Dec 2010 16:53:08 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id oBU0t82k016401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 Dec 2010 01:55:13 +0100 (MET)
From: Martin Rex
Message-Id: <[email-masked]>
To: [email-masked] (Steingruebl Andy)
Date: Thu, 30 Dec 2010 01:55:07 +0100 (MET)
In-Reply-To: <[email-masked]> from "Steingruebl, Andy" at Dec 29, 10 05:08:21 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: [email-masked]
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 30 Dec 2010 00:53:10 -0000

Steingruebl, Andy wrote:
>
> > -----Original Message-----
> > From: Martin Rex [mailto:[email-masked]]
> >
> >
> > PayPal is an extremely bad example.
> >
> > The majority of its use cases (that I've encountered: ebay payments) are fully
> > vulnerable to sslstrip because of ebay's notorious NON-use of HTTPS.
> > When used with ebay, paypal isn't accessed through secure bookmarks and
> > neither through trustworthy user input, but instead by clicking through a
> > chain of URLs starting on completely untrustworthy HTML pages received
> > from ebay through plain and vulnerable HTTP. So an sslstrip attack is still
> > quite feasible.
>
> With something like HSTS set/bootstrapped onto client machines already,
> sslstrip attacks go away. That said, if the attacker can control the
> non-paypal source page, they can just modify the link to not be
> paypal.com at all, no sslstrip necessary.

sslstrip is used to make it _appear_ as if "https://www.paypal.com" is used,
although at the TLS protocol level, a completely different IDNS hostname
is involved.

See page 91ff of this presentation:
http://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf

If you're targetting a very specific server, you will _not_ need a
wildcard cert.

>
> So sure, that is theoretical, but not something I can fix myself.

The only difficulty is to actually mount an active attack.

Everything else is easy and straightforward, and a Firesheep-like
tool for it quite possible.

The existing TLS PKI is built on the threat model of pervasive active attacks,
otherwise we could just get rid of all the commercial CAs and simply move
to the SSH-style leap-of-faith on initial encounter that is the predominant
authentication scheme in the offline world of humans and other species.

-Martin

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DD0228C134 for ; Wed, 29 Dec 2010 16:48:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.887
X-Spam-Level:
X-Spam-Status: No, score=-2.887 tagged_above=-999 required=5 tests=[AWL=-0.289, 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 TVVVTNVqrh4O for ; Wed, 29 Dec 2010 16:48:57 -0800 (PST)
Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id 4E65C28C132 for ; Wed, 29 Dec 2010 16:48:57 -0800 (PST)
Received: by yie19 with SMTP id 19so2604788yie.31 for ; Wed, 29 Dec 2010 16:51:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=bxQ6UYYHfVxYO8NxIDHF68X7U10b3ga+cN4EPcnOyTY=; b=Xqx7SYpUGKqCbkiNVBCzxyOiv1iiTpuyuIMuAUYDXNh1hlzy5WtCbmrlMKPzy0i4IQ cSy6s5256WE+UdZ9qphztij8hmIwOCTx7l4IsSU9CAo5ou5TimX9ELz/36YtURFNdaRj cE7jWFj+hetEOq/GzmE61IfA9mFLJ5TX19Kp0=
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=MzEKtiZ8yJ2lXhWbwuK8lHDJ4JfNe5vjy2SzUzL2RiTIPhl/nuYJNycNGnY1wIyVM/ 5M71Hnm9hORv8JvFOPhUMy2TowlQOnITFWMOcdYw8PjSJnBLgVPWCvAIvq5THc+T77uD DNsVCGP8dXmGb8s1zCQPqCriwcTikg7LRGvdA=
MIME-Version: 1.0
Received: by 10.100.228.14 with SMTP id a14mr7299295anh.239.1293670262598; Wed, 29 Dec 2010 16:51:02 -0800 (PST)
Received: by 10.100.31.8 with HTTP; Wed, 29 Dec 2010 16:51:02 -0800 (PST)
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Thu, 30 Dec 2010 00:51:02 +0000
Message-ID:
From: Phillip Hallam-Baker
To: [email-masked]
Content-Type: multipart/alternative; boundary=0016e6d27671756d9c04989614b1
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 30 Dec 2010 00:48:59 -0000

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

Chatting on an iphone all day is somewhat tedious. An iPad on the other hand
- no problem.

I think that is one of the changes that argues for restrictions to be
thought through more carefully. But in general there are a whole rack of
issues that mobile computers are bringing.

Trying to get institutions to take security realistically is really
difficult. Recently we discovered that a French bank had lost over $1.2
billion due to an internal fraud. The relevant compliance records were kept
using a manually updated excel spreadsheet. And last I heard, not a single
one of the people responsible for that fiasco lost their jobs.

Over the last decade the US government has spent over a billion dollars on a
PKI. Yet none of the emails sent out by the US military to journalists are
signed and a low ranking clerk was allegedly able to extract and leak a
quarter million classified diplomatic cables.

We have to deliver security in a form that people are willing to use.

On Thu, Dec 30, 2010 at 12:17 AM, Martin Rex wrote:

> Phillip Hallam-Baker wrote:
> >
> > There is also a fairly important Wall Street use case.
> >
> > Regulators require banks to have complete archives of client-broker
> > communications. So brokers connecting up to TLS protected Web sites from
> > work machines becomes problematic. So some block TLS entirely.
>
>
> So everyone is using their private SmartPhone to do HTTPS traffic?
> ... which also prevents any traces from improper communication
> to ever get created on the work machines...
>
> -Martin
>

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

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

Chatting on an iphone all day is somewhat tedious. An iPad on the other han=
d - no problem.=A0

I think that is one of the chang=
es that argues for restrictions to be thought through more carefully. But i=
n general there are a whole rack of issues that mobile computers are bringi=
ng.

Trying to get institutions to take security realistical=
ly is really difficult. Recently we discovered that a French bank had lost =
over $1.2 billion due to an internal fraud. The relevant compliance records=
were kept using a manually updated excel spreadsheet. And last I heard, no=
t a single one of the people responsible for that fiasco lost their jobs.

Over the last decade the US government has spent over a=
billion dollars on a PKI. Yet none of the emails sent out by the US milita=
ry to journalists are signed and a low ranking clerk was allegedly able to =
extract and leak a quarter million classified diplomatic cables.

We have to deliver security in a fo=
rm that people are willing to use.

On Thu, Dec 30, 2010 at 12:17 AM, Martin Rex <[email-masked]> wrote:

Phillip Hallam-Baker wrot=
e:

>

> There is also a fairly important Wall Street use case.

>

> Regulators require banks to have complete archives of client-broker
> communications. So brokers connecting up to TLS protected Web sites fr=
om

> work machines becomes problematic. So some block TLS entirely.

So everyone is using their private SmartPhone to do HTTPS traffic?
... which also prevents any traces from improper communication

to ever get created on the work machines...

-Martin

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

--0016e6d27671756d9c04989614b1--

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3DD328C124 for ; Wed, 29 Dec 2010 16:36:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.149
X-Spam-Level:
X-Spam-Status: No, score=-10.149 tagged_above=-999 required=5 tests=[AWL=0.100, 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 yXbzLEzpzfcT for ; Wed, 29 Dec 2010 16:36:07 -0800 (PST)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 8371228C121 for ; Wed, 29 Dec 2010 16:36:07 -0800 (PST)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id oBU0cAnk005060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 Dec 2010 01:38:11 +0100 (MET)
From: Martin Rex
Message-Id: <[email-masked]>
To: [email-masked] (Phillip Hallam-Baker)
Date: Thu, 30 Dec 2010 01:38:10 +0100 (MET)
In-Reply-To: from "Phillip Hallam-Baker" at Dec 23, 10 09:34:26 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: [email-masked]
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 30 Dec 2010 00:36:08 -0000

Phillip Hallam-Baker wrote:
>
> One of the un-noticed costs of the cryptowars was that making protocols
> resistant to Louis Freeh became a higher priority than making them easy to
> use. And as a result we ended up with two email encryption schemes that are
> really, really secure but practically unused.

With respect to collision attacks, PKCS#7 and its successor S/MIME,CMS
actually give me slight worries because their dangerous "signedAttributes"
indirect signature design.

With the standardized "randomNonce" signed Attribute (PKCS#9)
you get exactly the wiggle room that you need for precomputed collision
(or preimage) attacks while keeping the signed (and the forged) application
data seperate and pristine from any residual of such attacks.

What could be use cases of a collision attack?

Maybe creating _two_ correctly signed "documents" with a single
signature operation from a "controlled" PKCS7/CMS signature key (and only one
of the signed documents appearing in the official records of the signer...).

-Martin

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5939428C11F for ; Wed, 29 Dec 2010 16:15:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.147
X-Spam-Level:
X-Spam-Status: No, score=-10.147 tagged_above=-999 required=5 tests=[AWL=0.102, 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 n35FfaIKHknt for ; Wed, 29 Dec 2010 16:15:10 -0800 (PST)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 60D8E28B797 for ; Wed, 29 Dec 2010 16:15:10 -0800 (PST)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id oBU0HAH3003089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 Dec 2010 01:17:10 +0100 (MET)
From: Martin Rex
Message-Id: <[email-masked]>
To: [email-masked] (Phillip Hallam-Baker)
Date: Thu, 30 Dec 2010 01:17:09 +0100 (MET)
In-Reply-To: from "Phillip Hallam-Baker" at Dec 23, 10 05:02:24 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: [email-masked]
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 30 Dec 2010 00:15:11 -0000

Phillip Hallam-Baker wrote:
>
> There is also a fairly important Wall Street use case.
>
> Regulators require banks to have complete archives of client-broker
> communications. So brokers connecting up to TLS protected Web sites from
> work machines becomes problematic. So some block TLS entirely.

So everyone is using their private SmartPhone to do HTTPS traffic?
... which also prevents any traces from improper communication
to ever get created on the work machines...

-Martin

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C02E128B797 for ; Wed, 29 Dec 2010 16:06:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.052
X-Spam-Level:
X-Spam-Status: No, score=-8.052 tagged_above=-999 required=5 tests=[AWL=1.065, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, 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 rHXMaP4Dt5D2 for ; Wed, 29 Dec 2010 16:06:17 -0800 (PST)
Received: from den-mipot-001.corp.ebay.com (den-mipot-001.corp.ebay.com [216.113.175.152]) by core3.amsl.com (Postfix) with ESMTP id 994F728C11F for ; Wed, 29 Dec 2010 16:06:17 -0800 (PST)
DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:CC: Date:Subject:Thread-Topic:Thread-Index:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: x-ems-proccessed:x-ems-stamp:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=WuXuCw2TOGJ7p2MnTnFZrYHuDUzsp4PgL1ej5Ig3LRTDaayKkzszqGAt F2icWX7cTRUAdLLc+dx7fH8sBu+LxCyBOBxXBhIZmucLWac1ucLVKrxAZ pjpYNS6x26XN9iC;
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=[email-masked]; q=dns/txt; s=ppinc; t=1293667703; x=1325203703; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; z=From:=20"Steingruebl,=20Andy"=20|To:=20"[email-masked]"=20,=20Paul=20Hof fman=20|CC:=20"[email-masked]" =20|Date:=20Wed,=2029=20Dec=202010=20 17:08:21=20-0700|Subject:=20RE:=20[keyassure]=20HTTPS=20- >=20HTTP=20downgrade|Message-ID:=20<5EE049BA3C6538409BBE6 [email-masked]> |References:=20=20f rom=20"Paul=20Hoffman"=20at=0D=0A=20Dec=2022,=2010=2007:4 3:37=20am=20<[email-masked] orp>|In-Reply-To:=20<[email-masked] df.sap.corp>|Content-Transfer-Encoding:=20quoted-printabl e|MIME-Version:=201.0; bh=ZbCcqSKr4dwB1SZEjoLEYv0ZKJ4EZPqMHPwM+tJuA4w=; b=OFzPf0y7rGVIsnQZKrU1QvY+lvUER7Iu5Cj3L/ywBqepZjtkoeAG2kfH Eltb7I9GARn39dhk6L7jhfL9PMdeFcKqsZ3J7BKdFsEYdcAwDHUvUBncE +HDZDlVUYobniyD;
X-EBay-Corp: Yes
X-IronPort-AV: E=Sophos;i="4.60,246,1291622400"; d="scan'208";a="142233"
Received: from den-vtenf-002.corp.ebay.com (HELO DEN-MEXHT-002.corp.ebay.com) ([10.101.112.213]) by den-mipot-001.corp.ebay.com with ESMTP; 29 Dec 2010 16:08:23 -0800
Received: from DEN-MEXMS-001.corp.ebay.com ([10.241.16.225]) by DEN-MEXHT-002.corp.ebay.com ([10.241.17.53]) with mapi; Wed, 29 Dec 2010 17:08:22 -0700
From: "Steingruebl, Andy"
To: "[email-masked]" , Paul Hoffman
Date: Wed, 29 Dec 2010 17:08:21 -0700
Thread-Topic: [keyassure] HTTPS -> HTTP downgrade
Thread-Index: AcuntM+WwZbzGuQcToShTcOKpxOidAAAI+WA
Message-ID: <[email-masked]>
References: from "Paul Hoffman" at Dec 22, 10 07:43:37 am <[email-masked]>
In-Reply-To: <[email-masked]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A==
x-ems-stamp: XzfZeypvoIBQC0MWY+M7kA==
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter: Scanned
Cc: "[email-masked]"
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 30 Dec 2010 00:06:18 -0000

> -----Original Message-----
> From: Martin Rex [mailto:[email-masked]]
>=20
>=20
> PayPal is an extremely bad example.
>=20
> The majority of its use cases (that I've encountered: ebay payments) are =
fully
> vulnerable to sslstrip because of ebay's notorious NON-use of HTTPS.
> When used with ebay, paypal isn't accessed through secure bookmarks and
> neither through trustworthy user input, but instead by clicking through a
> chain of URLs starting on completely untrustworthy HTML pages received
> from ebay through plain and vulnerable HTTP. So an sslstrip attack is st=
ill
> quite feasible.

With something like HSTS set/bootstrapped onto client machines already, ssl=
strip attacks go away. That said, if the attacker can control the non-payp=
al source page, they can just modify the link to not be paypal.com at all, =
no sslstrip necessary. So sure, that is theoretical, but not something I c=
an fix myself.

- Andy

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A82C33A68FA for ; Wed, 29 Dec 2010 16:00:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.146
X-Spam-Level:
X-Spam-Status: No, score=-10.146 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jl4JG1GUsrrR for ; Wed, 29 Dec 2010 16:00:00 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 733E63A68F7 for ; Wed, 29 Dec 2010 15:59:59 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id oBU024tG011415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 Dec 2010 01:02:04 +0100 (MET)
From: Martin Rex
Message-Id: <[email-masked]>
To: [email-masked] (Paul Hoffman)
Date: Thu, 30 Dec 2010 01:02:03 +0100 (MET)
In-Reply-To: from "Paul Hoffman" at Dec 22, 10 07:43:37 am
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: [email-masked]
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: [email-masked]
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 30 Dec 2010 00:00:01 -0000

Paul Hoffman wrote:
>
> You have no way of knowing that, and I have no way of knowing the
> opposite. The fact that PayPal has been TLS-only for years has taught
> PayPal users to expect 443, but PayPal is (sadly) in the very small
> minority, so your users are not a good metric.

PayPal is an extremely bad example.

The majority of its use cases (that I've encountered: ebay payments) are
fully vulnerable to sslstrip because of ebay's notorious NON-use of HTTPS.
When used with ebay, paypal isn't accessed through secure bookmarks
and neither through trustworthy user input, but instead by clicking through
a chain of URLs starting on completely untrustworthy HTML pages received
from ebay through plain and vulnerable HTTP. So an sslstrip attack
is still quite feasible.

>
> Andy Steingruebl wrote:
> >
> > If the sites only does a redirect on port -80 -> 443, the user won't get
> > anything meaningful at port-80 anyway.

An unconditional port 80 -> 443 redirect has some very specific
(and limited) usefulness. Make it more difficult for users to
bookmark http: (instead of https:) URLs and reduce the
effectiveness of pure passive (=eavesdropping) attacks (like Firesheep).

But one should be careful about "deployed" non-HTTPS URLs not getting
spoiled with 302s.

I've seen a commercial CA that serves you a 302 for a published
CRL Distribution Point
http:///.crl -> http:///2.crl

Any PKI software following a 302 redirect (received over plain HTTP)
exhibits a serious security vulnerability, and it looks like a
CA breakage to actually configure something like this.

-Martin

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDE923A6875; Wed, 29 Dec 2010 12:08:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.498
X-Spam-Level:
X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, 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 JW5ea2hXhckv; Wed, 29 Dec 2010 12:08:32 -0800 (PST)
Received: from emh06.mail.saunalahti.fi (emh06.mail.saunalahti.fi [62.142.5.116]) by core3.amsl.com (Postfix) with ESMTP id 244563A686A; Wed, 29 Dec 2010 12:08:31 -0800 (PST)
Received: from saunalahti-vams (vs3-10.mail.saunalahti.fi [62.142.5.94]) by emh06-2.mail.saunalahti.fi (Postfix) with SMTP id 4CE93C7D4F; Wed, 29 Dec 2010 22:10:35 +0200 (EET)
Received: from emh05.mail.saunalahti.fi ([62.142.5.111]) by vs3-10.mail.saunalahti.fi ([62.142.5.94]) with SMTP (gateway) id A003C0495B1; Wed, 29 Dec 2010 22:10:35 +0200
Received: from LK-Perkele-VI (a88-112-56-215.elisa-laajakaista.fi [88.112.56.215]) by emh05.mail.saunalahti.fi (Postfix) with ESMTP id AA0EC27D88; Wed, 29 Dec 2010 22:10:30 +0200 (EET)
Date: Wed, 29 Dec 2010 22:11:31 +0200
From: Ilari Liusvaara
To: Paul Hoffman
Message-ID: <[email-masked]>
References: <[email-masked]> <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <[email-masked]>
User-Agent: Mutt/1.5.20 (2009-06-14)
Sender: Ilari Liusvaara
X-Antivirus: VAMS
Cc: "[email-masked]" , "[email-masked]"
Subject: Re: [keyassure] [websec] HASTLS and client policy preference
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 29 Dec 2010 20:08:38 -0000

On Tue, Dec 28, 2010 at 04:55:27PM -0800, Paul Hoffman wrote:
> On 12/27/10 6:35 PM, Paul Wouters wrote:

> Both those expectations are probably unwise. The first assumes that
> all clients that use HASTLS want to do TLS; some won't. The second
> assumes that all applications will use TLS for security, which is
> probably unwise.

Have field for security protocol type. And I think TLS should split into
TLS (start connection with TLS client hello) and STARTTLS (upgrade to
TLS).

Also, I think that insecure port should be always be specified so
the client can identify its own stuff (one might want to use TLS
with protocols without official TLS port).

-Ilari

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E146228C0FD for ; Wed, 29 Dec 2010 05:30:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.955
X-Spam-Level:
X-Spam-Status: No, score=-103.955 tagged_above=-999 required=5 tests=[AWL=-1.978, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 jL86hv0O7dIz for ; Wed, 29 Dec 2010 05:30:51 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 511EE28C0DE for ; Wed, 29 Dec 2010 05:30:50 -0800 (PST)
Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id oBTDWsbW001724 for ; Wed, 29 Dec 2010 05:32:55 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1293629575; bh=Km2UeKYIEIr0U4QE8yqKg5o0zFI=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=iRM67gQE0RLA2FilsxBAJZ/ddciq8aw7N7dOtGF/YQPTdT0jkc7KAGoAaduATDNze jzgmKV4iZF7Mh4+5oyxoQ==
Received: from qyk10 (qyk10.prod.google.com [10.241.83.138]) by wpaz9.hot.corp.google.com with ESMTP id oBTDWfld031506 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 29 Dec 2010 05:32:53 -0800
Received: by qyk10 with SMTP id 10so12761233qyk.15 for ; Wed, 29 Dec 2010 05:32:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/zWkUK+Oe83sDsw7RlxsGe7OE3mcDwDmBJLahEGlYEM=; b=P2gdotndFD8A11RgG/18fNv9KiEOwCjyuXOKwQpTF98L4pKQhyx0rA9q7crf6VXgCM nyNMCV/TRh92MIWsox1g==
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=UQoCE47YFJBOv9WU6KFJKVA/6MJ27HPntsUOZMKPYp3vBhYx/mcD9A1zInrJObFADO gKHTqLHLKIuYNxAQUrLQ==
MIME-Version: 1.0
Received: by 10.224.53.193 with SMTP id n1mr13986121qag.270.1293629571645; Wed, 29 Dec 2010 05:32:51 -0800 (PST)
Received: by 10.220.88.137 with HTTP; Wed, 29 Dec 2010 05:32:51 -0800 (PST)
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Wed, 29 Dec 2010 13:32:51 +0000
Message-ID:
From: Ben Laurie
To: Paul Wouters
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
Cc: [email-masked], [email-masked], Paul Hoffman
Subject: Re: [keyassure] [websec] HASTLS and client policy preference
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 29 Dec 2010 13:30:53 -0000

On 29 December 2010 05:26, Paul Wouters wrote:
> On Tue, 28 Dec 2010, Paul Hoffman wrote:
>
> Actually, one more question. You wrote in section 2:
>
> =A0 =A0 =A0 =A0An example of a hash for a single certificate:
>
> =A0 =A0 =A0 =A0www.example.com. IN TLSA 1 2 AgHne3GdTpxjwLCgMzvgpBiOSQthj=
g=3D=3D
>
> The hash type here is 2, and you refer to
> http://www.iana.org/assignments/tls-parameters
> which refers to http://tools.ietf.org/html/rfc5246 for sha1, but I did no=
t
> find that RFC
> (about TLS) mentioning anything about encoding of the hash.
>
> The above listed encoding seems to not have enough characters to be a bas=
e64
> string of a sha1 hash,

It is 30 characters, + 2 padding, which seems just about right to me.

> so I'm a little confused what you generated. Which
> means it should probably get a better explanation in the text.
>
> Paul
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97AA73A688C; Tue, 28 Dec 2010 21:24:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.585
X-Spam-Level:
X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 CIxgxsdT83H8; Tue, 28 Dec 2010 21:24:46 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 533793A6889; Tue, 28 Dec 2010 21:24:45 -0800 (PST)
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 AFD59C4F3; Wed, 29 Dec 2010 00:26:49 -0500 (EST)
Date: Wed, 29 Dec 2010 00:26:49 -0500 (EST)
From: Paul Wouters
To: Paul Hoffman
In-Reply-To: <[email-masked]>
Message-ID:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] [websec] HASTLS and client policy preference
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 29 Dec 2010 05:24:47 -0000

On Tue, 28 Dec 2010, Paul Hoffman wrote:

Actually, one more question. You wrote in section 2:

An example of a hash for a single certificate:

www.example.com. IN TLSA 1 2 AgHne3GdTpxjwLCgMzvgpBiOSQthjg==

The hash type here is 2, and you refer to http://www.iana.org/assignments/tls-parameters
which refers to http://tools.ietf.org/html/rfc5246 for sha1, but I did not find that RFC
(about TLS) mentioning anything about encoding of the hash.

The above listed encoding seems to not have enough characters to be a base64
string of a sha1 hash, so I'm a little confused what you generated. Which
means it should probably get a better explanation in the text.

Paul

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42BC128C0D6; Tue, 28 Dec 2010 18:14:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.584
X-Spam-Level:
X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 Tr+TXartNzcO; Tue, 28 Dec 2010 18:14:50 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 1D53228B23E; Tue, 28 Dec 2010 18:14:50 -0800 (PST)
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 66FD2C4F3; Tue, 28 Dec 2010 21:16:53 -0500 (EST)
Date: Tue, 28 Dec 2010 21:16:52 -0500 (EST)
From: Paul Wouters
To: Paul Hoffman
In-Reply-To: <[email-masked]>
Message-ID:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] [websec] HASTLS and client policy preference
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 29 Dec 2010 02:14:51 -0000

On Tue, 28 Dec 2010, Paul Hoffman wrote:

> On 12/26/10 7:16 PM, Paul Wouters wrote:
>> I'm not sure if CIO/CSO/CFB are still described properly, because it is
>> no longer a "client type" but it depends on the particular tripplet.
> The client still gets to decide what its policy is. It gets to decide whether
> or not it conforms to the HASTLS semantics.

I meant (as below) that a client type now belongs to a service tripplet.

>> For instance, if we have IN HASTLS (25 25 0 80 443 1) then what would you
>> call the "server" or the matching "client"?
> I don't understand the question.

Same here

>> They are CFB/SFB for some protocols
>> and CSO/SSO for other protocols.
> IN the above, if there is an SMTP client, it could be either CSO, CFB, or
> CIO.

I meant to talk about servers in this aspect, because based on the HASTLS record
we know what the server is. And they can be CFB for some and SFB for others,
depending on service tripplet.

>> This should probably have some "protocol" modifiers added, eg
>>
>> 1 -- If the client could be configured as either CFB or CSO for a
>> particular service tripplet, and ..."
> Good point, yes. I'll add that in the next draft.
>> Perhaps it should also be stated that the client policy preference MUST be
>> 0 if either the secure or insecure port is specified as 0.
> I don't think so. This can lead to some silly states, like if you specify "1"
> and the TLS-based service goes down for some reason.

If either the insecure or the secure service is 0 (but not both), it means
HASTLS compliant clients will only have one way to connect. So there is no
"preference". You can only connect to the one secure or insecure port.

> I said in the sentence following what you quoted above:
> Note that specifying 1 for the client policy preference when a host
> does not support a protocol securely makes no sense, but it also does
> no harm.
> I still believe that is true.

But it does no good either. In some sense, it is "lying" because there can be
no preference. Imagine an implementation first checks the 5th byte, and then
blindly assumes there is a secure and insecure version (why else list the
preference as 1) and then picking the secure version, while the HASTLS record
stated (80 0 1) and there is none.

I would still say, preference SHOULD or MUST be 0 if the service is only offered
with one method.

>> Other then that, the changes address all my issues. Thanks!
> Glad to hear it.

Thanks for your work on this!

Paul

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C42B3A68F6; Tue, 28 Dec 2010 16:53:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.626
X-Spam-Level:
X-Spam-Status: No, score=-101.626 tagged_above=-999 required=5 tests=[AWL=0.420, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 EU-FyB20cSDE; Tue, 28 Dec 2010 16:53:41 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id B686C3A6826; Tue, 28 Dec 2010 16:53:41 -0800 (PST)
Received: from MacBook-08.local (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 oBT0tYtg074888 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 28 Dec 2010 17:55:36 -0700 (MST) (envelope-from [email-masked])
Message-ID: <[email-masked]>
Date: Tue, 28 Dec 2010 16:55:34 -0800
From: Paul Hoffman
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: Paul Wouters
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]>
In-Reply-To:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] [websec] HASTLS and client policy preference
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 29 Dec 2010 00:53:42 -0000

On 12/26/10 7:16 PM, Paul Wouters wrote:
> I'm not sure if CIO/CSO/CFB are still described properly, because it is
> no longer a "client type" but it depends on the particular tripplet.
The client still gets to decide what its policy is. It gets to decide
whether or not it conforms to the HASTLS semantics.
> For instance, if we have IN HASTLS (25 25 0 80 443 1) then what would you
> call the "server" or the matching "client"?
I don't understand the question. There is an SMTP server and an HTTP
server. The system requesting the information might have clients for
both, either, or none.
> They are CFB/SFB for some protocols
> and CSO/SSO for other protocols.
IN the above, if there is an SMTP client, it could be either CSO, CFB,
or CIO.
>
>
> 1 -- If the client could be configured as either CFB or CSO, and
> the host's administrator was able to configure the client, that
> administrator would configure the client as CSO. Stated another
> way, the host's administrator does not want any CFB client to
> access the host.
>
> This should probably have some "protocol" modifiers added, eg
>
> 1 -- If the client could be configured as either CFB or CSO for a
> particular service tripplet, and ..."
Good point, yes. I'll add that in the next draft.
> Perhaps it should also be stated that the client policy preference
> MUST be
> 0 if either the secure or insecure port is specified as 0.
I don't think so. This can lead to some silly states, like if you
specify "1" and the TLS-based service goes down for some reason. I said
in the sentence following what you quoted above:
Note that specifying 1 for the client policy preference when a host
does not support a protocol securely makes no sense, but it also does
no harm.
I still believe that is true.
>
> Other then that, the changes address all my issues. Thanks!
Glad to hear it.

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D46E3A6962; Tue, 28 Dec 2010 16:53:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.623
X-Spam-Level:
X-Spam-Status: No, score=-101.623 tagged_above=-999 required=5 tests=[AWL=0.423, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 An5pbS5EDcOs; Tue, 28 Dec 2010 16:53:26 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id E1D2B3A696E; Tue, 28 Dec 2010 16:53:26 -0800 (PST)
Received: from MacBook-08.local (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 oBT0tR7R074885 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 28 Dec 2010 17:55:30 -0700 (MST) (envelope-from [email-masked])
Message-ID: <[email-masked]>
Date: Tue, 28 Dec 2010 16:55:27 -0800
From: Paul Hoffman
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: Paul Wouters
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]>
In-Reply-To:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "[email-masked]" , "[email-masked]"
Subject: Re: [keyassure] [websec] HASTLS and client policy preference
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 29 Dec 2010 00:53:27 -0000

On 12/27/10 6:35 PM, Paul Wouters wrote:
> For services where you have no secure/TLS version, their entries could
> simply be omitted and not be part of the HASTLS record. That is, you
> could not specify:
>
> insecure.org. IN HASTLS (80 0 0 25 25 1)
>
> but instead:
>
> insecure.org. IN HASTLS (25 25 1)
This does not tell an HTTP client that is CIO or CFB that there is, in
fact, a server at port 80. Why do you want to prevent them from knowing
that?
> An exception might be if you want to prevent clients from connecting to
> you at all, by specifying
>
> insecure.org. IN HASTLS ()
That is prohibited by the spec, on purpose.
> Though I blieve the HASTLS record should not become the "legitimate
> open port list" of a host though, people should not trust clients to
> adhere to HASTLS for their server security, and instead have proper
> firewall policies.
Correct.
> Though I think Paul Hoffman would prefer the first entry over the second
> one. Though all records, including not having a HASTLS record at all,
> should have the same effect for clients supporting this RRTYPE. Though
> they could decided there is nothing on port 80 and refuse to even try
> in the latter two examples.
Yes, that's a reasonable policy.
> Personally, I would prefer not to have to build a list of insecure ports
> if I have no secure version of it available, but then again I would
> expect any client that can do HASTLS to be able to do the secure version
> anyway. And for new protocols to not come out with an insecure version.
Both those expectations are probably unwise. The first assumes that all
clients that use HASTLS want to do TLS; some won't. The second assumes
that all applications will use TLS for security, which is probably unwise.
> Perhaps it makes sense to rename HASTLS to something else. TLSSTAT?
> STATTLS? TLSAVAIL?
Bikeshed.

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 542623A68F6; Tue, 28 Dec 2010 16:53:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.322
X-Spam-Level:
X-Spam-Status: No, score=-101.322 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_31=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 oD1gRscIh7YH; Tue, 28 Dec 2010 16:53:15 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 6C5B23A6826; Tue, 28 Dec 2010 16:53:15 -0800 (PST)
Received: from MacBook-08.local (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 oBT0tGUv074866 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 28 Dec 2010 17:55:19 -0700 (MST) (envelope-from [email-masked])
Message-ID: <[email-masked]>
Date: Tue, 28 Dec 2010 16:55:16 -0800
From: Paul Hoffman
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: "Steingruebl, Andy"
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "[email-masked]" , "[email-masked]"
Subject: Re: [keyassure] [websec] HASTLS and client policy preference
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 29 Dec 2010 00:53:16 -0000

On 12/27/10 3:52 PM, Steingruebl, Andy wrote:
> 1. I think it would be useful in the security considerations to discuss (briefly?) the MITM threat model at play here. You discuss it in the context of delivery of the DNS data itself, but not the motivation for this proposal in the first place. A major motivation is the MITM attack against the non-TLS version of a protocol.
Good call, yes.
> 2. Do you have any examples of CFB apps?
Many. Most SMTP servers, for example. Many POP and IMAP clients. Many
SIP clients. And so on.
> A few clients such as Mozilla's Thunderbird when in "discovery" mode will try this, but it isn't very common in my experience, and it would be good to have a few examples I could think about.
You are focusing on "current web", not "TLS".
> 3. We argues a lot when working on HSTS about the proper behavior of a server supporting HSTS and whether it SHOULD or MUST redirect all HTTP traffic to HTTPS. You come down on the MUST front in this proposal, at least philosophically.
If I did, it was a mistake. I don't see where I do so.
> Some sites (well, 1 anyway) have chosen not to. I won't go into the details, and it isn't a major issue.
I think both policies are reasonable.
> 4. One way in protocols that don't support redirects to also indicate to a client that it should not communicate "insecurely" is with error codes. POP/IMAP can both do this with error codes, some of which are usually shown to the user (in some implementations). So, though they don't support protocol-level "redirects" like HTTPS, then still allow signaling to the client albeit in a non-automated way.
The POP and IMAP error codes are too obtuse to show to end users.
> 5. Maybe this came up earlier but I'm still slightly confused on overall semantics of this proposal. If HASTLS is about TLS, it is odd to me that it should talk about non-TLS policy, where it listens "insecurely", etc.
Any client-server protocol that does not require TLS all the time will
have instances where the server is insecure. Some clients will want to
know if a server is even offering the non-TLS version; if not, it will
never try to go to the non-secure port on that server.
> I have a few thoughts on the general topic of service discovery, but HASTLS seems to bundle two ideas together: a) service discovery and b) whether/how that service operates with TLS. It seems to me that they are slighty different, and co-mingling them doesn't seem quite right.
HASTLS is *not* about service discovery at all. The spec states "Setting
both the "insecure-port" and "secure-port" to 0 in a porttriple is
explicitly undefined", but that maybe should be strengthened to a
prohibition.
> Related to #5, the biggest protocol in our minds that is problematic wrt sslstrip-type attacks is HTTP/HTTPS, because it is the one protocol that where non fully qualified names, URI(L?)'s are entered, and where the browser has some of its own converting between names and protocols that go on. It is also the one protocol most easily MITM'd in a lot of ways, because much of the web is HTTP, and active attackers can easily insert references to resources causing the client to retrieve them. The same isn't true of most other protocols such as IMAP. Which isn't to say that this proposal isn't a good idea for IMAP, its just that IMAP/POP aren't quite so ripe for abuse generally.
I understand your emphasis on TLS, but there is a much bigger world out
there, and attacks in that world are just as serious. If one security
extension can cover multiple server protocols, that would be good, I think.

--Paul Hoffman

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 681113A6890; Tue, 28 Dec 2010 09:02:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.668
X-Spam-Level:
X-Spam-Status: No, score=-3.668 tagged_above=-999 required=5 tests=[AWL=-0.070, 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 u24xp2msSJ0q; Tue, 28 Dec 2010 09:02:28 -0800 (PST)
Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id DCE5C3A687F; Tue, 28 Dec 2010 09:02:27 -0800 (PST)
Received: by gwj17 with SMTP id 17so6036921gwj.31 for ; Tue, 28 Dec 2010 09:04:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=202S2KdgB8wm9EtfgZZSJwOfHAdUZRXLdxmMpwM5gOI=; b=W1xjc+aI+yxjeXBHyksBA1Ha6R4ybxCnIriOZIY4+wGqBkShZEvViwuk4MJio4ClIR GsPlwacNlXZM4TKJVIEd1iHNWzH3Rvn+Jix8ETKS3BzCxTlLFJIVtSN1SHtZq/RggMBC GYzy+Tzyjn10VkSjizgmILWtDgGeoDXATQbmA=
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=HrFiu9+gGYaGaSE0pXdPcipKMtrCaPsxlvxAGhnFls+GrTs/dmwW868YnhW9EPlnOh GoDWswN7NtZbTH4/R4enULiDVi/7CMO4Y2hvJLcFt/5h8ywjTJflkKxDovsjFvziLSUj UrtC4m4GHzXRxb0Lc9aZZYQOhwrjmHn8T2C/Q=
MIME-Version: 1.0
Received: by 10.100.96.1 with SMTP id t1mr7902055anb.137.1293555872769; Tue, 28 Dec 2010 09:04:32 -0800 (PST)
Received: by 10.100.31.8 with HTTP; Tue, 28 Dec 2010 09:04:32 -0800 (PST)
In-Reply-To: <[email-masked]>
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Tue, 28 Dec 2010 17:04:32 +0000
Message-ID:
From: Phillip Hallam-Baker
To: "Steingruebl, Andy"
Content-Type: multipart/alternative; boundary=0016e644caf04b275e04987b72f4
Cc: "[email-masked]" , "[email-masked]" , Paul Hoffman
Subject: Re: [keyassure] [websec] HASTLS and client policy preference
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 28 Dec 2010 17:02:29 -0000

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

I think that is a great idea.

SRV and extended discovery in general can deliver advantages in addition to
security.

I have found persuading people to change protocol behavior for the sake of
security alone to be very hard. SRV offers potential reliability and
performance benefits. Which makes it much easier to get adoption.

On Tue, Dec 28, 2010 at 4:25 PM, Steingruebl, Andy <
[email-masked]> wrote:

> > -----Original Message-----
> > From: Paul Wouters [mailto:[email-masked]]
>
> > Though I blieve the HASTLS record should not become the "legitimate open
> > port list" of a host though, people should not trust clients to adhere to
> > HASTLS for their server security, and instead have proper firewall
> policies.
> >
> > Personally, I would prefer not to have to build a list of insecure ports
> if I have
> > no secure version of it available, but then again I would expect any
> client that
> > can do HASTLS to be able to do the secure version anyway. And for new
> > protocols to not come out with an insecure version.
> >
> > Perhaps it makes sense to rename HASTLS to something else. TLSSTAT?
> > STATTLS? TLSAVAIL?
>
> The idea I've been toying around with is actually changing how service
> lookups happen. I don't have a well-formulated idea yet but it seems that
> just as many protocols/applications (I struggle for the right word here) do
> SRV lookups, maybe we ought to somehow bundle the TLS preference into that
> lookup scheme. If we did, we could tackle the keys-in-dns problem and
> has/requires-TLS problem in the same SRV lookup. HASTLS would be a part of
> looking up the properties of a service you're about to connect to.
>
> I'm more than a little inexperienced with existing SRV lookups, so can't
> quite articulate how I think this would best work.
>
> - Andy
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

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

I think that is a great idea.

SRV and extended discovery=
in general can deliver advantages in addition to security.=A0

I have found persuading people to change protocol behavior for=
the sake of security alone to be very hard. SRV offers potential reliabili=
ty and performance benefits. Which makes it much easier to get adoption.

On Tue, Dec 28, 2010 at =
4:25 PM, Steingruebl, Andy <[email-masked]> wrote:
<=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
#ccc solid;padding-left:1ex;">

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

> From: Paul Wouters [mailto:paul@=
xelerance.com]

> Though I blieve the HASTLS record should not become the "legitima=
te open

> port list" of a host though, people should not trust clients to a=
dhere to

> HASTLS for their server security, and instead have proper firewall pol=
icies.

>

> Personally, I would prefer not to have to buil=
d a list of insecure ports if I have

> no secure version of it available, but then again I would expect any c=
lient that

> can do HASTLS to be able to do the secure version anyway. And for new<=
br>
> protocols to not come out with an insecure version.

>

> Perhaps it makes sense to rename HASTLS to something else. TLSSTAT?
> STATTLS? TLSAVAIL?

The idea I've been toying around with is actually changing how se=
rvice lookups happen. =A0I don't have a well-formulated idea yet but it=
seems that just as many protocols/applications (I struggle for the right w=
ord here) do SRV lookups, maybe we ought to somehow bundle the TLS preferen=
ce into that lookup scheme. =A0 If we did, we could tackle the keys-in-dns =
problem and has/requires-TLS problem in the same SRV lookup. =A0HASTLS woul=
d be a part of looking up the properties of a service you're about to c=
onnect to.

I'm more than a little inexperienced with existing SRV lookups, so can&=
#39;t quite articulate how I think this would best work.

- Andy

__________________________________=
_____________

keyassure mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/keyassure

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

--0016e644caf04b275e04987b72f4--

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5784B3A692D; Tue, 28 Dec 2010 08:23:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.004
X-Spam-Level:
X-Spam-Status: No, score=-8.004 tagged_above=-999 required=5 tests=[AWL=1.113, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, 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 Dqg5Dgu88ZgL; Tue, 28 Dec 2010 08:23:19 -0800 (PST)
Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) by core3.amsl.com (Postfix) with ESMTP id C63753A687F; Tue, 28 Dec 2010 08:23:18 -0800 (PST)
DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:CC: Date:Subject:Thread-Topic:Thread-Index:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: x-ems-proccessed:x-ems-stamp:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=R/VbPyZ814AAuGEwqMnw0Ca28UfzJ/s5TKbHWDPDAj7zp1sbJeP/C5Zr PjHYVLJBZqQOnSnut4sYI0S15W/f9sgCIBS0SPMo4RvuhCN/b23hHdXYT +7puSMcrwyWHVfX;
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=[email-masked]; q=dns/txt; s=ppinc; t=1293553524; x=1325089524; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; z=From:=20"Steingruebl,=20Andy"=20|To:=20Paul=20Wouters=20|CC:=20P aul=20Hoffman=20,=20"keyassure@iet f.org"=0D=0A=09,=20"[email-masked]" =20|Date:=20Tue,=2028=20Dec=202010=2009: 25:22=20-0700|Subject:=20RE:=20[keyassure]=20[websec]=20H ASTLS=20and=20client=20policy=20preference|Message-ID:=20 <5EE049BA3C6538409BBE6F1760F328ABEB19C1FEAE@DEN-MEXMS-001 .corp.ebay.com>|References:=20<20101213220001.24500.52050 .idtracker@localhost>=0D=0A=20<1292899636.1888.75.camel@m attlaptop2.local>=0D=0A=20=0D=0A=20=0D=0A=20=0D=0A=20<5EE049BA3C6538409BBE6F1760F328ABEB19B00699@D EN-MEXMS-001.corp.ebay.com>=0D=0A=20=0D=0A=20=0D=0A=20=0D=0A=20=0D =0A=20=0D=0A=20=0D=0A=20=0D=0A=20=0D=0A =20=0D=0A=20 =0D=0A=20<5EE049BA3C6538409BBE6F1760F328ABEB19C1FD7D@DEN- MEXMS-001.corp.ebay.com>=0D=0A=20|In-Reply-To:=20 |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=ACoEL/BBa+E3J/QBl4ocP2hdwhJ98YQCNO2nutLR31I=; b=U60blQSrnRAaQAUWeB/niiUIGlzmPglQIhxW91lOvFNYI1F+55vtW3Vq U7yy7xNZfn4d8Dh/w2TghERZFaidFagC+kTzzbruf3h3o7PasNbSOfFJk r3UopT12zpr5Yob;
X-EBay-Corp: Yes
X-IronPort-AV: E=Sophos;i="4.60,239,1291622400"; d="scan'208";a="607970"
Received: from den-vtenf-002.corp.ebay.com (HELO DEN-MEXHT-001.corp.ebay.com) ([10.101.112.213]) by den-mipot-002.corp.ebay.com with ESMTP; 28 Dec 2010 08:25:24 -0800
Received: from DEN-MEXMS-001.corp.ebay.com ([10.241.16.225]) by DEN-MEXHT-001.corp.ebay.com ([10.241.17.52]) with mapi; Tue, 28 Dec 2010 09:25:23 -0700
From: "Steingruebl, Andy"
To: Paul Wouters
Date: Tue, 28 Dec 2010 09:25:22 -0700
Thread-Topic: [keyassure] [websec] HASTLS and client policy preference
Thread-Index: AcumN+ceo9ielK5/TC2CIQopAbld3QAc3hxg
Message-ID: <[email-masked]>
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To:
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A==
x-ems-stamp: OghTtTLTovPEsnRVpS0WhQ==
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter: Scanned
Cc: "[email-masked]" , "[email-masked]" , Paul Hoffman
Subject: Re: [keyassure] [websec] HASTLS and client policy preference
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 28 Dec 2010 16:23:20 -0000

> -----Original Message-----
> From: Paul Wouters [mailto:[email-masked]]
=20
> Though I blieve the HASTLS record should not become the "legitimate open
> port list" of a host though, people should not trust clients to adhere to
> HASTLS for their server security, and instead have proper firewall polici=
es.
>=20
> Personally, I would prefer not to have to build a list of insecure ports =
if I have
> no secure version of it available, but then again I would expect any clie=
nt that
> can do HASTLS to be able to do the secure version anyway. And for new
> protocols to not come out with an insecure version.
>=20
> Perhaps it makes sense to rename HASTLS to something else. TLSSTAT?
> STATTLS? TLSAVAIL?

The idea I've been toying around with is actually changing how service look=
ups happen. I don't have a well-formulated idea yet but it seems that just=
as many protocols/applications (I struggle for the right word here) do SRV=
lookups, maybe we ought to somehow bundle the TLS preference into that loo=
kup scheme. If we did, we could tackle the keys-in-dns problem and has/re=
quires-TLS problem in the same SRV lookup. HASTLS would be a part of looki=
ng up the properties of a service you're about to connect to.

I'm more than a little inexperienced with existing SRV lookups, so can't qu=
ite articulate how I think this would best work.

- Andy

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F6C73A6908; Mon, 27 Dec 2010 18:33:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.584
X-Spam-Level:
X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 w7pTLb5Lj174; Mon, 27 Dec 2010 18:33:00 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 4386B3A6800; Mon, 27 Dec 2010 18:32:59 -0800 (PST)
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 3E10FC45B; Mon, 27 Dec 2010 21:35:03 -0500 (EST)
Date: Mon, 27 Dec 2010 21:35:02 -0500 (EST)
From: Paul Wouters
To: "Steingruebl, Andy"
In-Reply-To: <[email-masked]>
Message-ID:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: "[email-masked]" , "[email-masked]" , Paul Hoffman
Subject: Re: [keyassure] [websec] HASTLS and client policy preference
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 28 Dec 2010 02:33:02 -0000

On Mon, 27 Dec 2010, Steingruebl, Andy wrote:

> 5. Maybe this came up earlier but I'm still slightly confused on overall semantics of this proposal. If HASTLS is about TLS, it is odd to me that it should talk about non-TLS policy, where it listens "insecurely", etc. I have a few thoughts on the general topic of service discovery, but HASTLS seems to bundle two ideas together: a) service discovery and b) whether/how that service operates with TLS. It seems to me that they are slighty different, and co-mingling them doesn't seem quite right.

You are somewhat right.

For services where you have no secure/TLS version, their entries could
simply be omitted and not be part of the HASTLS record. That is, you
could not specify:

insecure.org. IN HASTLS (80 0 0 25 25 1)

but instead:

insecure.org. IN HASTLS (25 25 1)

An exception might be if you want to prevent clients from connecting to
you at all, by specifying

insecure.org. IN HASTLS ()

Though I blieve the HASTLS record should not become the "legitimate
open port list" of a host though, people should not trust clients to
adhere to HASTLS for their server security, and instead have proper
firewall policies.

Though I think Paul Hoffman would prefer the first entry over the second
one. Though all records, including not having a HASTLS record at all,
should have the same effect for clients supporting this RRTYPE. Though
they could decided there is nothing on port 80 and refuse to even try
in the latter two examples.

Personally, I would prefer not to have to build a list of insecure ports
if I have no secure version of it available, but then again I would
expect any client that can do HASTLS to be able to do the secure version
anyway. And for new protocols to not come out with an insecure version.

Perhaps it makes sense to rename HASTLS to something else. TLSSTAT? STATTLS? TLSAVAIL?

Paul

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE7F83A68F6; Mon, 27 Dec 2010 15:50:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.665
X-Spam-Level:
X-Spam-Status: No, score=-7.665 tagged_above=-999 required=5 tests=[AWL=0.852, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, J_CHICKENPOX_31=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 w9FRzKV6FDmn; Mon, 27 Dec 2010 15:50:34 -0800 (PST)
Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) by core3.amsl.com (Postfix) with ESMTP id 4BB863A68ED; Mon, 27 Dec 2010 15:50:31 -0800 (PST)
DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:Date: Subject:Thread-Topic:Thread-Index:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: x-ems-proccessed:x-ems-stamp:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=isu39BI/Cp9W0XhjMFvqxS8jYAy5c9K3S9yABQc0N30FiWJYXo15NmEH pDO+IDI33i1MEqQ22suu0ScgzN6CfVxs1HEejki1qmjH8kw3TYKDsgj96 wjzN4Ytbvx2x3Cc;
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=[email-masked]; q=dns/txt; s=ppinc; t=1293493957; x=1325029957; h=from:to:date:subject:message-id:references:in-reply-to: content-transfer-encoding:mime-version; z=From:=20"Steingruebl,=20Andy"=20|To:=20Paul=20Hoffman=20,=20" [email-masked]"=0D=0A=09,=20"webs [email-masked]"=20|Date:=20Mon,=2027=20Dec =202010=2016:52:34=20-0700|Subject:=20RE:=20[websec]=20HA STLS=20and=20client=20policy=20preference|Message-ID:=20< 5EE049BA3C6538409BBE6F1760F328ABEB19C1FD7D@DEN-MEXMS-001. corp.ebay.com>|References:=20<20101213220001.24500.52050. idtracker@localhost>=0D=0A=09<1292803814.1885.16.camel@ma ttlaptop2.local>=0D=0A=09=0D=0A=09=0D=0A=09=0D=0A=09=0D=0A=09<1292899636.1888.75.camel@mattlaptop 2.local>=0D=0A=09=0D =0A=09=0D=0A=09=0D =0A=09<5EE049BA3C6538409BBE6F1760F328ABEB19B00699@DEN-MEX MS-001.corp.ebay.com>=0D=0A=09=0D=0A=09=0D=0A=09=0D=0A=09=0D=0A=09=0D=0A=09=0D=0A=09=0D=0A=09=0D=0A=09 =0D=0A=20 |In-Reply-To:=20 |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=37NxVxVpl9RfapIqqfT6fxeRLJbTyFnFBGi2z1NL5Hc=; b=W//gNN429l+OlvxyVQMrJQCBzSzskZd+FAOo0IlePXeSpJ2dZ+zz53i7 5tftqE6IhFpoZnOxdpAbDjJuMfiv24s6LZzW8oVAQ9IaaqJwhZEAsSB3T 1WLZx6dqnq+4M9Q;
X-EBay-Corp: Yes
X-IronPort-AV: E=Sophos;i="4.60,237,1291622400"; d="scan'208";a="602502"
Received: from den-vtenf-002.corp.ebay.com (HELO DEN-MEXHT-002.corp.ebay.com) ([10.101.112.213]) by den-mipot-002.corp.ebay.com with ESMTP; 27 Dec 2010 15:52:36 -0800
Received: from DEN-MEXMS-001.corp.ebay.com ([10.241.16.225]) by DEN-MEXHT-002.corp.ebay.com ([10.241.17.53]) with mapi; Mon, 27 Dec 2010 16:52:35 -0700
From: "Steingruebl, Andy"
To: Paul Hoffman , "[email-masked]" , "[email-masked]"
Date: Mon, 27 Dec 2010 16:52:34 -0700
Thread-Topic: [websec] HASTLS and client policy preference
Thread-Index: AculWZjEmnCIz8UqSiiQbTZJX0O5SQAxg+3w
Message-ID: <[email-masked]>
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To:
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A==
x-ems-stamp: tKGPcji1e5ggIgpbtW2SJw==
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter: Scanned
Subject: Re: [keyassure] [websec] HASTLS and client policy preference
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 27 Dec 2010 23:50:36 -0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Paul Hoffman
>=20
> Greetings again. I still don't like the idea of a host asserting a client=
policy
> preference, but I hear many folks wanting it. I think I have added it cle=
anly in
> draft-hoffman-server-has-tls-02, but I'm not sure and would like to hear
> more from folks, especially those who like the current semantics in draft=
-
> hodges-strict-transport-sec. The new draft is at
> , and the dif=
fs
> from the last draft are at server-has-tls-02.txt>.

A few thoughts.

1. I think it would be useful in the security considerations to discuss (br=
iefly?) the MITM threat model at play here. You discuss it in the context =
of delivery of the DNS data itself, but not the motivation for this proposa=
l in the first place. A major motivation is the MITM attack against the no=
n-TLS version of a protocol.

2. Do you have any examples of CFB apps? A few clients such as Mozilla's T=
hunderbird when in "discovery" mode will try this, but it isn't very common=
in my experience, and it would be good to have a few examples I could thin=
k about.

3. We argues a lot when working on HSTS about the proper behavior of a serv=
er supporting HSTS and whether it SHOULD or MUST redirect all HTTP traffic =
to HTTPS. You come down on the MUST front in this proposal, at least philo=
sophically. Some sites (well, 1 anyway) have chosen not to. I won't go into=
the details, and it isn't a major issue.

4. One way in protocols that don't support redirects to also indicate to a =
client that it should not communicate "insecurely" is with error codes. PO=
P/IMAP can both do this with error codes, some of which are usually shown t=
o the user (in some implementations). So, though they don't support protoc=
ol-level "redirects" like HTTPS, then still allow signaling to the client a=
lbeit in a non-automated way.

5. Maybe this came up earlier but I'm still slightly confused on overall se=
mantics of this proposal. If HASTLS is about TLS, it is odd to me that it =
should talk about non-TLS policy, where it listens "insecurely", etc. I ha=
ve a few thoughts on the general topic of service discovery, but HASTLS see=
ms to bundle two ideas together: a) service discovery and b) whether/how th=
at service operates with TLS. It seems to me that they are slighty differe=
nt, and co-mingling them doesn't seem quite right. =20

Related to #5, the biggest protocol in our minds that is problematic wrt ss=
lstrip-type attacks is HTTP/HTTPS, because it is the one protocol that wher=
e non fully qualified names, URI(L?)'s are entered, and where the browser h=
as some of its own converting between names and protocols that go on. It =
is also the one protocol most easily MITM'd in a lot of ways, because much =
of the web is HTTP, and active attackers can easily insert references to re=
sources causing the client to retrieve them. The same isn't true of most o=
ther protocols such as IMAP. Which isn't to say that this proposal isn't a=
good idea for IMAP, its just that IMAP/POP aren't quite so ripe for abuse =
generally.

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FA2B3A683E; Sun, 26 Dec 2010 19:14:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.584
X-Spam-Level:
X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 AUvXqDmqYoRP; Sun, 26 Dec 2010 19:14:18 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 297B53A6835; Sun, 26 Dec 2010 19:14:18 -0800 (PST)
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 237C0C4F3; Sun, 26 Dec 2010 22:16:21 -0500 (EST)
Date: Sun, 26 Dec 2010 22:16:20 -0500 (EST)
From: Paul Wouters
To: Paul Hoffman
In-Reply-To:
Message-ID:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] HASTLS and client policy preference
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 27 Dec 2010 03:14:19 -0000

On Sun, 26 Dec 2010, Paul Hoffman wrote:

> Greetings again. I still don't like the idea of a host asserting a client policy preference, but I hear many folks wanting it. I think I have added it cleanly in draft-hoffman-server-has-tls-02, but I'm not sure and would like to hear more from folks, especially those who like the current semantics in draft-hodges-strict-transport-sec. The new draft is at , and the diffs from the last draft are at .

I'm not sure if CIO/CSO/CFB are still described properly, because it is
no longer a "client type" but it depends on the particular tripplet.

For instance, if we have IN HASTLS (25 25 0 80 443 1) then what would you
call the "server" or the matching "client"? They are CFB/SFB for some protocols
and CSO/SSO for other protocols.

1 -- If the client could be configured as either CFB or CSO, and
the host's administrator was able to configure the client, that
administrator would configure the client as CSO. Stated another
way, the host's administrator does not want any CFB client to
access the host.

This should probably have some "protocol" modifiers added, eg

1 -- If the client could be configured as either CFB or CSO for a
particular service tripplet, and ..."

Perhaps it should also be stated that the client policy preference MUST be
0 if either the secure or insecure port is specified as 0.

Other then that, the changes address all my issues. Thanks!

Paul

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF1253A6843; Sun, 26 Dec 2010 16:02:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.432
X-Spam-Level:
X-Spam-Status: No, score=-100.432 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_40=-0.185, HELO_MISMATCH_COM=0.553, 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 1bjTpXTQ9YFu; Sun, 26 Dec 2010 16:02:05 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 425583A6841; Sun, 26 Dec 2010 16:02:05 -0800 (PST)
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 oBR0486s067537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 26 Dec 2010 17:04:09 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Sun, 26 Dec 2010 16:04:06 -0800
To: [email-masked], [email-masked]
From: Paul Hoffman
Content-Type: text/plain; charset="us-ascii"
Subject: [keyassure] HASTLS and client policy preference
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 27 Dec 2010 00:02:06 -0000

Greetings again. I still don't like the idea of a host asserting a client policy preference, but I hear many folks wanting it. I think I have added it cleanly in draft-hoffman-server-has-tls-02, but I'm not sure and would like to hear more from folks, especially those who like the current semantics in draft-hodges-strict-transport-sec. The new draft is at , and the diffs from the last draft are at .

FWIW, I don't think that draft-hoffman-server-has-tls formally belongs in either DANE or WEBSEC, and will probably try to move it into the AppsArea WG in the new year, but if folks want to comment before then, that's great.

--Paul Hoffman, Director
--VPN Consortium

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFD383A66B4 for ; Fri, 24 Dec 2010 04:05:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.388
X-Spam-Level:
X-Spam-Status: No, score=-3.388 tagged_above=-999 required=5 tests=[AWL=0.210, 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 Ltj1KibnRgaU for ; Fri, 24 Dec 2010 04:05:30 -0800 (PST)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id A22293A6765 for ; Fri, 24 Dec 2010 04:05:30 -0800 (PST)
Received: by gyd12 with SMTP id 12so3172490gyd.31 for ; Fri, 24 Dec 2010 04:07:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=fsKBjMpXboN1zGhPp0C4I/b5lfvJY29zxmNgXYmlNZo=; b=NsQ7S9FR81GVmbKLzThMf00v/wP5HI+6vHh31ddNk04zeVqR0gHGPeEOAy8a8K+6mF VvuAJ/PDeNNMTeL/TWkflhbCb3cQK722OIKikQ3bJ4wzz8c0RdCShgvTzzIspl6bGXuf 0mhK/vHVquYQqyaBRQg+6iL0Xk0N56kTyOXzo=
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=BCWCvzotMz4WXI9RiD0OgpPSzk7vVjaQk6EBApWVUKB2dBn1CFCHXTOrSKdUi5qw9L 5LC6xHJXZtIaryAToZCmT68d1mlacWGASmElgM585/fwVg5FuxkTEzIgp3wQvrasLbcy vfI7l0LIBWVrvq7k9eBcRPLY+P2+qE9ZQix18=
MIME-Version: 1.0
Received: by 10.100.110.16 with SMTP id i16mr5621864anc.103.1293192451166; Fri, 24 Dec 2010 04:07:31 -0800 (PST)
Received: by 10.100.31.8 with HTTP; Fri, 24 Dec 2010 04:07:31 -0800 (PST)
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Fri, 24 Dec 2010 12:07:31 +0000
Message-ID:
From: Phillip Hallam-Baker
To: Paul Wouters
Content-Type: multipart/alternative; boundary=0016e645ab9aad90f8049826d4b3
Cc: "[email-masked]" , Paul Hoffman
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 24 Dec 2010 12:05:34 -0000

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

Again you completely misrepresent me and those you are quoting.

There is a huge difference between not supporting the key escrow schemes
demanded by Louis Freeh and making resistance to government mandated
intercept the primary design consideration.

My point is that you do not achieve security through application of a
blinkered ideology. There are many cases where one security interest is
trumped by another.

In the case of Wall Street traders there is a confidentiality concern, but
the concern is the responsibility of the firm and NOT the individual trader.
Not only does a broker not have a right to engage in private conversations
with the company clients, enforcing such a rule is in the interests of both
the customer and the company.

Hey, if someone is prepared to pay me a million bucks a year to gamble with
a billion dollars or so of their money, they can read my email too. OK,
maybe a bit more than a million, but if they will throw in an Aston I could
be tempted.

In any case, the question is moot since local policy will always trump the
standard. If the local policy is that all traffic must be en-clair at the
firewall, the person who writes that code is going to ignore what the spec
says.

Trying to design out the possibility of people doing this type of thing is
pointless. We tried that in the cryptowars and ended up with junk protocols
nobody uses.

Just design stuff that works when people are not mucking with the
infrastructure and then consider how to fix the infrastructure level attack
as a completely separate issue.

On Fri, Dec 24, 2010 at 1:57 AM, Paul Wouters wrote:

> On Thu, 23 Dec 2010, Phillip Hallam-Baker wrote:
>
> Well it was 14 years ago.
>>
>
> I don't see an "obsoleted by RFCxxxx"?
>
>
> It was an informational RFC and is not binding on the current membership:
>>
>
> Yes, an information RFC not just by any WG, but by the IAB and the IESG.
> that might suggest it is kinda a big deal.
>
>
> Moreover it does not make the statement you allege concerning MITM.
>>
>
> I will quote again:
>
>
> Cryptography is the most powerful single tool that users
> can use to secure the Internet. Knowingly making that tool weaker
> threatens their ability to do so, and has no proven benefit.
>
> Just to make it more clear, to me allowing a port 80 downgrade falls
> under "making cryptography [...] weaker".
>
>
> So not only is RFC 1984 not binding IETF policy, it does not make the
>> statement you claim.
>>
>
> I hope I sufficiently addressed this above. If not, please let me know.
>
>
> I do wish that people would actually read documents that they keep
>> referencing. In this case it is only 4 pages long.
>>
>
> I read them, and I still strongly disagree with your statement. But I will
> refrain from claiming you did not read the RFC, because I have no way of
> proving any such hypothesis. Perhaps you should give me the same courtesy.
>
> And stating you wish to protect the stock brokers from only using https
> (for regularory compliance) while claiming the common user being vulnerable
> to port 80 downgrade is out of scope is something I strongly disagree with
> and frown upon.
>
>
> On Thu, Dec 23, 2010 at 9:42 PM, Paul Wouters wrote:
>> On Thu, 23 Dec 2010, Phillip Hallam-Baker wrote:
>>
>> I was referring there to DANE rather than the IETF.
>>
>>
>> But DANE is part of an IETF WG, and RFC1984 is a firm statement by
>> the IAB/IESG
>>
>> In my view we should separate design of censorship
>> busting protocols from design of regular protocols.
>>
>>
>> You mentioned MITM's should not be "either supported or attempted
>> to prevent".
>>
>> I wanted to remind everyone that the IETF concensus is that
>> preventing
>> MITM is very much its goal (on the protocol level)
>>
>> If you are going to deploy something that is robust you
>> have to make busting censorship your first last and
>> only goal
>> (e.g. Tor).
>>
>>
>> Agreed, but for MITM attacks against TLS/SSL, we should clearly
>> have a "MUST abort" when the
>> client detects a MITM for our protocol specifications. And not
>> build in a "china" or "school" or
>> "stock brokers" function. Leave that to the implementors (as
>> RFC1984 states)
>>
>> One of the un-noticed costs of the cryptowars was that
>> making protocols resistant to Louis Freeh became a
>> higher
>> priority than making them easy to use. And as a result
>> we ended up with two email encryption schemes that are
>> really,
>> really secure but practically unused.
>>
>> A protocol should be one or the other, trying to be
>> both ends up with a scheme that serves neither purpose.
>>
>>
>> I'm not sure if I agree, but regardless this seems out of scope on
>> the current discussion on
>> "client policy" vs "protocol specification placed limits on what
>> clients SHOULD do".
>>
>> This particular capability is like key-escrow. It is
>> something that is perfectly acceptable within specific
>> circumstances but totally unacceptable when it becomes
>> a mandate with the government in control.
>>
>>
>> And hence, again, RFC1984 says "do not add escrow to the protocol,
>> add it to the implementation".
>>
>> Which is what I am arguing for the "MUST NOT fallback to port 80"
>>
>> Paul
>>
>>
>>
>>
>> --
>> Website: http://hallambaker.com/
>>
>>
>>
>>

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

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

Again you completely misrepresent me and those you are quoting.

There is a huge difference between not supporting the key escrow sc=
hemes demanded by Louis Freeh and making resistance to government mandated =
intercept the primary design consideration.

My point is that you do not achieve secu=
rity through application of a blinkered ideology. There are many cases wher=
e one security interest is trumped by another.

In the case of Wall Street traders there is a confidentiality concern, but =
the concern is the responsibility of the firm and NOT the individual trader=
. Not only does a broker not have a right to engage in private conversation=
s with the company clients, enforcing such a rule is in the interests of bo=
th the customer and the company.

H=
ey, if someone is prepared to pay me a million bucks a year to gamble with =
a billion dollars or so of their money, they can read my email too. OK, may=
be a bit more than a million, but if they will throw in an Aston I could be=
tempted.

In any case, the question is moot since =
local policy will always trump the standard. If the local policy is that al=
l traffic must be en-clair at the firewall, the person who writes that code=
is going to ignore what the spec says.

Trying to design out the possibility of people doing th=
is type of thing is pointless. We tried that in the cryptowars and ended up=
with junk protocols nobody uses.

Just design stuff that works when people are not mucking with the infrastru=
cture and then consider how to fix the infrastructure level attack as a com=
pletely separate issue.

On Fri, Dec 24, 2010 at 1:57 AM, Paul Wouters <[email-masked]> wrote:
=

On Thu, 23 Dec 2010, Phillip Hallam-Baker wrote:

Well it was 14 years ago.

I don't see an "obsoleted by RFCxxxx"?

It was an informational RFC and is not binding on the current membership:

Yes, an information RFC not just by any WG, but by the IAB and the IESG.
that might suggest it is kinda a big deal.

Moreover it does not make the statement you allege concerning MITM.

I will quote again:

=A0 =A0 =A0 =A0Cryptography is the most powerful single tool that users
=A0 =A0 =A0 =A0can use to secure the Internet. Knowingly making that tool =
weaker

=A0 =A0 =A0 =A0threatens their ability to do so, and has no proven benefit=
.

Just to make it more clear, to me allowing a port 80 downgrade falls

under "making cryptography [...] weaker".

So not only is RFC 1984 not binding IETF policy, it does not make the

statement you claim.

I hope I sufficiently addressed this above. If not, please let me know.

I do wish that people would actually read documents that they keep

referencing. In this case it is only 4 pages long.=A0

I read them, and I still strongly disagree with your statement. But I will<=
br>
refrain from claiming you did not read the RFC, because I have no way of
proving any such hypothesis. Perhaps you should give me the same courtesy.<=
br>

And stating you wish to protect the stock brokers from only using https

(for regularory compliance) while claiming the common user being vulnerable=

to port 80 downgrade is out of scope is something I strongly disagree with<=
br>
and frown upon.

On Thu, Dec 23, 2010 at 9:42 PM, Paul Wouters <[email-masked]> wrote:

=A0 =A0 =A0On Thu, 23 Dec 2010, Phillip Hallam-Baker wrote:

=A0 =A0 =A0I was referring there to DANE rather than the IETF.

But DANE is part of an IETF WG, and RFC1984 is a firm statement by

the IAB/IESG

=A0 =A0 =A0In my view we should separate design of censorship

=A0 =A0 =A0busting protocols from design of regular protocols.=A0

You mentioned MITM's should not be "either supported or attempted<=
br>
to prevent".

I wanted to remind everyone that the IETF concensus is that

preventing

MITM is very much its goal (on the protocol level)

=A0 =A0 =A0If you are going to deploy something that is robust you

=A0 =A0 =A0have to make busting censorship your first last and

=A0 =A0 =A0only goal

=A0 =A0 =A0(e.g. Tor).

Agreed, but for MITM attacks against TLS/SSL, we should clearly

have a "MUST abort" when the

client detects a MITM for our protocol specifications. And not

build in a "china" or "school" or

"stock brokers" function. Leave that to the implementors (as

RFC1984 states)

=A0 =A0 =A0One of the un-noticed costs of the cryptowars was that

=A0 =A0 =A0making protocols resistant to Louis Freeh became a

=A0 =A0 =A0higher

=A0 =A0 =A0priority than making them easy to use. And as a result

=A0 =A0 =A0we ended up with two email encryption schemes that are

=A0 =A0 =A0really,

=A0 =A0 =A0really secure but practically unused.=A0

=A0 =A0 =A0A protocol should be one or the other, trying to be

=A0 =A0 =A0both ends up with a scheme that serves neither purpose.

I'm not sure if I agree, but regardless this seems out of scope on

the current discussion on

"client policy" vs "protocol specification placed limits on =
what

clients SHOULD do".

=A0 =A0 =A0This particular capability is like key-escrow. It is

=A0 =A0 =A0something that is perfectly acceptable within specific

=A0 =A0 =A0circumstances but totally unacceptable when it becomes

=A0 =A0 =A0a mandate with the government in control.

And hence, again, RFC1984 says "do not add escrow to the protocol,

add it to the implementation".

Which is what I am arguing for the "MUST NOT fallback to port 80"=

Paul

--

Website: http://halla=
mbaker.com/

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

--0016e645ab9aad90f8049826d4b3--

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C5F43A6930 for ; Fri, 24 Dec 2010 03:02:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.064
X-Spam-Level:
X-Spam-Status: No, score=-104.064 tagged_above=-999 required=5 tests=[AWL=-2.087, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 s6dR+vvV1vGk for ; Fri, 24 Dec 2010 03:02:01 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 5C2183A6805 for ; Fri, 24 Dec 2010 03:02:00 -0800 (PST)
Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id oBOB42OV031719 for ; Fri, 24 Dec 2010 03:04:02 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1293188642; bh=Dhu+vLlJcndLNn0g01m/9fK5VQs=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=Px5jLsLWnAOBwiCW5jeM88Au81zkZQk9hzbQiGmlWlLCX+EsgHU8m+Im+tRyLoHzV k8pPeYcJEC+Sb1I5/IRYQ==
Received: from qyk8 (qyk8.prod.google.com [10.241.83.136]) by hpaq5.eem.corp.google.com with ESMTP id oBOB40Oi010078 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 24 Dec 2010 03:04:01 -0800
Received: by qyk8 with SMTP id 8so7642046qyk.6 for ; Fri, 24 Dec 2010 03:04:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=SUvBcAgpaJHeRF5uv2W38LyCa2QT69yvTUPnt6zqNYw=; b=fGOvCmZMRLuopyOOFkndMDEZlGUWT0EU0QKIJMxJjxrs68h1OZYaVX6UZgIhtROCvd 3wISKNYJILqK5cu19Ctg==
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; b=TY2zmWsVVmFmH0bC3YUA6XA2QDDlUWIV93jyEV+YM0OVeimE+/yVG+7l77iSZ4ziYy +Wi7EaLxnNaska+Vyr2g==
MIME-Version: 1.0
Received: by 10.224.74.14 with SMTP id s14mr8571665qaj.370.1293188639910; Fri, 24 Dec 2010 03:03:59 -0800 (PST)
Received: by 10.220.88.137 with HTTP; Fri, 24 Dec 2010 03:03:59 -0800 (PST)
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Fri, 24 Dec 2010 11:03:59 +0000
Message-ID:
From: Ben Laurie
To: Paul Wouters
Content-Type: text/plain; charset=ISO-8859-1
X-System-Of-Record: true
Cc: "[email-masked]" , Phillip Hallam-Baker , Paul Hoffman
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 24 Dec 2010 11:02:02 -0000

On 24 December 2010 01:57, Paul Wouters wrote:
> And stating you wish to protect the stock brokers from only using https
> (for regularory compliance) while claiming the common user being vulnerable
> to port 80 downgrade is out of scope is something I strongly disagree with
> and frown upon.

+1

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9372A3A68EE; Thu, 23 Dec 2010 21:46:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.489
X-Spam-Level:
X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 mYPcsMX0yWvh; Thu, 23 Dec 2010 21:46:26 -0800 (PST)
Received: from emh06.mail.saunalahti.fi (emh06.mail.saunalahti.fi [62.142.5.116]) by core3.amsl.com (Postfix) with ESMTP id BEB4C3A68ED; Thu, 23 Dec 2010 21:46:25 -0800 (PST)
Received: from saunalahti-vams (vs3-11.mail.saunalahti.fi [62.142.5.95]) by emh06-2.mail.saunalahti.fi (Postfix) with SMTP id 65EBDC7F0F; Fri, 24 Dec 2010 07:48:25 +0200 (EET)
Received: from emh04.mail.saunalahti.fi ([62.142.5.110]) by vs3-11.mail.saunalahti.fi ([62.142.5.95]) with SMTP (gateway) id A0363562674; Fri, 24 Dec 2010 07:48:25 +0200
Received: from LK-Perkele-VI (a88-112-56-215.elisa-laajakaista.fi [88.112.56.215]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id F148041BE4; Fri, 24 Dec 2010 07:48:22 +0200 (EET)
Date: Fri, 24 Dec 2010 07:48:46 +0200
From: Ilari Liusvaara
To: [email-masked]
Message-ID: <[email-masked]>
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <[email-masked]>
User-Agent: Mutt/1.5.20 (2009-06-14)
Sender: Ilari Liusvaara
X-Antivirus: VAMS
Cc: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 24 Dec 2010 05:46:27 -0000

On Tue, Dec 14, 2010 at 09:38:18AM +0200, Ilari Liusvaara wrote:
> On Mon, Dec 13, 2010 at 02:00:01PM -0800, [email-masked] 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 : Using Secure DNS to Associate Certificates with Domain Names For TLS
> > Author(s) : P. Hoffman, J. Schlyter
> > Filename : draft-ietf-dane-protocol-00.txt
> > Pages : 9
> > Date : 2010-12-12
>
> Various unclear things:
>
> - Since hash #0 is identity anyway, is there reason not to merge 1 and 2
> (and also 3 and 4)?

Actually, I think the whole "certificate type" is underspecified.

The following is how I would modify it:

- Merge 1 and 2. Hash type will tell full certificates and certificate
hashes apart anyway. This removes the possiblity of "01 00" and "02 02"
nonsense.
- Merge 3 and 4. Same reasons as for previous.
- Specify that unknown certificate types are to be treated as usable but
not matching if the hash function is known.

The reson for last one is that were new certificate type (raw keys?) to
be added to TLS, otherwise one would need a new DNS RR and interaction
between that type and TLSA would have to be specified (plus other muti-
RR issues!). The result might even be a security issue if client not
supporting new RR tries to connect to server using new certificate type
only (the connection should fail and not offer some attacker oppurtunity
to send a mistakenly issued PKIX certificate).

The last attack would not be possible if unknown records were usable but
not matching. The client would see only type 5 (or whatever) records and
conclude (correctly) that connecting can't possibly work, even if the
connection is MITM'd by someone with mistakenly issued PKIX certificate
for the server.

-Ilari

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34F563A68C4 for ; Thu, 23 Dec 2010 17:55:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.584
X-Spam-Level:
X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 QXi45643kHRA for ; Thu, 23 Dec 2010 17:55:47 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 94EAF3A68C7 for ; Thu, 23 Dec 2010 17:55:46 -0800 (PST)
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 65AC2C412; Thu, 23 Dec 2010 20:57:46 -0500 (EST)
Date: Thu, 23 Dec 2010 20:57:45 -0500 (EST)
From: Paul Wouters
To: Phillip Hallam-Baker
In-Reply-To:
Message-ID:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT
Cc: "[email-masked]" , Paul Hoffman
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 24 Dec 2010 01:55:49 -0000

On Thu, 23 Dec 2010, Phillip Hallam-Baker wrote:

> Well it was 14 years ago.

I don't see an "obsoleted by RFCxxxx"?

> It was an informational RFC and is not binding on the current membership:

Yes, an information RFC not just by any WG, but by the IAB and the IESG.
that might suggest it is kinda a big deal.

> Moreover it does not make the statement you allege concerning MITM.

I will quote again:

Cryptography is the most powerful single tool that users
can use to secure the Internet. Knowingly making that tool weaker
threatens their ability to do so, and has no proven benefit.

Just to make it more clear, to me allowing a port 80 downgrade falls
under "making cryptography [...] weaker".

> So not only is RFC 1984 not binding IETF policy, it does not make the
> statement you claim.

I hope I sufficiently addressed this above. If not, please let me know.

> I do wish that people would actually read documents that they keep
> referencing. In this case it is only 4 pages long.�

I read them, and I still strongly disagree with your statement. But I will
refrain from claiming you did not read the RFC, because I have no way of
proving any such hypothesis. Perhaps you should give me the same courtesy.

And stating you wish to protect the stock brokers from only using https
(for regularory compliance) while claiming the common user being vulnerable
to port 80 downgrade is out of scope is something I strongly disagree with
and frown upon.

> On Thu, Dec 23, 2010 at 9:42 PM, Paul Wouters wrote:
> On Thu, 23 Dec 2010, Phillip Hallam-Baker wrote:
>
> I was referring there to DANE rather than the IETF.
>
>
> But DANE is part of an IETF WG, and RFC1984 is a firm statement by
> the IAB/IESG
>
> In my view we should separate design of censorship
> busting protocols from design of regular protocols.�
>
>
> You mentioned MITM's should not be "either supported or attempted
> to prevent".
>
> I wanted to remind everyone that the IETF concensus is that
> preventing
> MITM is very much its goal (on the protocol level)
>
> If you are going to deploy something that is robust you
> have to make busting censorship your first last and
> only goal
> (e.g. Tor).
>
>
> Agreed, but for MITM attacks against TLS/SSL, we should clearly
> have a "MUST abort" when the
> client detects a MITM for our protocol specifications. And not
> build in a "china" or "school" or
> "stock brokers" function. Leave that to the implementors (as
> RFC1984 states)
>
> One of the un-noticed costs of the cryptowars was that
> making protocols resistant to Louis Freeh became a
> higher
> priority than making them easy to use. And as a result
> we ended up with two email encryption schemes that are
> really,
> really secure but practically unused.�
>
> A protocol should be one or the other, trying to be
> both ends up with a scheme that serves neither purpose.
>
>
> I'm not sure if I agree, but regardless this seems out of scope on
> the current discussion on
> "client policy" vs "protocol specification placed limits on what
> clients SHOULD do".
>
> This particular capability is like key-escrow. It is
> something that is perfectly acceptable within specific
> circumstances but totally unacceptable when it becomes
> a mandate with the government in control.
>
>
> And hence, again, RFC1984 says "do not add escrow to the protocol,
> add it to the implementation".
>
> Which is what I am arguing for the "MUST NOT fallback to port 80"
>
> Paul
>
>
>
>
> --
> Website: http://hallambaker.com/
>
>
>

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D61A3A68AF for ; Thu, 23 Dec 2010 14:32:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.76
X-Spam-Level:
X-Spam-Status: No, score=-101.76 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_64=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 MM4lharfGdEU for ; Thu, 23 Dec 2010 14:32:56 -0800 (PST)
Received: from oproxy3-pub.bluehost.com (oproxy3-pub.bluehost.com [69.89.21.8]) by core3.amsl.com (Postfix) with SMTP id 263B43A6895 for ; Thu, 23 Dec 2010 14:32:56 -0800 (PST)
Received: (qmail 20243 invoked by uid 0); 23 Dec 2010 22:34:56 -0000
Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy3.bluehost.com with SMTP; 23 Dec 2010 22:34: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=dTAhhYF19RP9fa/H3tCuvsDYS7RcUNB0HLg5yMTKfY/p8WfO8uSGSlWUBYiA77+kG0ah5v+pTcMaXhALySfiRw8sme7IfGl61OgRi9OrYd1Ursou4YInRXSVJ6UUstR5;
Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.136.151]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1PVtkO-0005Yc-1y for [email-masked]; Thu, 23 Dec 2010 15:34:56 -0700
Message-ID: <[email-masked]>
Date: Thu, 23 Dec 2010 14:34:54 -0800
From: =JeffH
User-Agent: Thunderbird 2.0.0.24 (X11/20101027)
MIME-Version: 1.0
To: IETF DANE WG list
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com}
Subject: [keyassure] client behavior in context of host policy (was: HTTPS -> HTTP downgrade)
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 23 Dec 2010 22:32:57 -0000

Paul Hoffman replied..
>
>> eg something like:
>>
>> "If a service is offered on both insecure and secure ports, and the c=
lient
>> supports the secure port, it SHOULD|MUST connect to the secure port =
only"
>>
>
> And, again, that is you telling someone else what they MUST do, regard=
less
> of what they want.

Yes, because what they "want", or are just blindly trying to do (eg in or=
der to=20
accomplish some task) -- i.e. e.g. connect to the host via http/80 -- may=
not=20
be what they ought to be doing in order to make use of the webapp/site th=
ey are=20
attempting to connect to.

E.g. for a site that has a deployment history on http/80 (or a mixture of=
=20
http/80 & https/443) and wishes to move to being a TLS-only https/443 sit=
e, it=20
will need to at a minimum listen on http/80 and http-redirect to https/44=
3 if=20
it wishes to maximize continued use as well as minimize breakage due to "=
http:"=20
links (and equivalents) embedded in itself and/or in other webapps/sites.=

Thus, this stipulation in draft-hoffman-server-has-tls-01 (aka HASTLS)..

Given this, a host that wants clients to only use the secure form of=

a protocol MUST only be configured to be SSO [server secure only];
a client that wants to only communicate with a server securely MUST
only be configured to be CSO [client secure only].

=2E.isn't realistically deployable today in the HTTP-based world for a la=
rge=20
number of sites, due to the behavior of the installed base of both server=
s and=20
clients.

Also, presently web browsers, and possibly other HTTP clients (i don't kn=
ow for
sure), when given a URI fragment containing the host and perhaps a path,
attempt http/80 first by default (modulo those that understand HSTS and h=
ave
the site cached). So this behavior would have to continue as-is for quite=
some
time, because there's going to be a transition period of years as sites s=
tart
emitting HSTS (HTTP Strict Transport Security) policy and/or adopting som=
ething=20
else that might emerge, eg HASTLS (ie the consumer browser vendors aren't=
going=20
to want to alter their default behavior for a long time if ever), and dep=
loyed=20
browsers start to understand HSTS, HASTLS, and whatever else we come up w=
ith.

>> To me, this falls in the same category as "MUST NOT use a nonce twice=
".
>> It's inheritant in the security protocol to counter an attack vector.=

>
> They are completely unrelated. To repeat my example from a day or two =
ago:
> assume that the client does not have the trust anchor you require for =
TLS in
> their trust anchor store. "SHOULD|MUST connect to the secure port only=
"
> means "you're going to fail to connect, tough luck".

Yes, in that particular example, that is what would, and correctly should=
=20
happen, if the client supports, for example, HSTS=20
(draft-hodges-strict-transport-sec), and/or I would argue, whatever else =
we=20
come up with for the longer term, eg whatever HASTLS becomes.

Note that in the above example the webapp/site would have to have both=20
advertised a policy of "TLS only" _and_ not ensured that it is using a ce=
rt=20
that properly chains up to a trust anchor that's loaded in its users clie=
nts.=20
So it's sorta shooting itself in the foot, unfortunately (and we're betti=
ng=20
this is a uncommon occurrence and is an edge case).

The sort of use case we're more concerned with is where the webapp/site _=
is_=20
properly configured both policy- and cert-wise, and there's a MITM or an =

impersonator, and here we want the connection attempt to hard fail by def=
ault.

> More likely it will
> mean "you will tell your client to let you through anyway, ignoring wh=
at
> HASTLS told you securely".

Well, that's typical behavior today because clients have made it inordina=
tely=20
easy for any user to simply "click-through" the warnings and proceed=20
insecurely. We _really_ want to prevent that by default going forward.

The rationale being that there are formal user studies (see below) plus t=
ons of=20
anecdotal evidence illustrating that most person-off-the-street users hav=
e no=20
context to understand what is going on when given a choice whether to pro=
ceed=20
insecurely or to just stop and are inclined to continue getting their tas=
k done=20
if it is made easy for them to do so (i.e. their task workflow isn't=20
unavoidably interrupted).

Note that this _does not_ for example obviate the client being configurab=
le
such that HSTS policy adherence could be turned off for any or all sites.=
We
note this and other "suggested" UA features in "UA Implementation Advice"=
in
draft-hodges-strict-transport-sec.

Now, that all said, it seems that HASTLS, as presently imagined, advertis=
es
host capabilities in terms of on which ports it speaks TLS, and then a cl=
ient,
depending upon what client policy is in effect (the {CIO,CSO,CFB} as outl=
ined
in the draft-hoffman-server-has-tls) behaves according to the combination=
of=20
what the host is advertising and what the client policy is.

What HSTS does, essentially, is instruct the client that for a given host=
,
implement the CSO (client security only) policy, which is presently state=
d in=20
draft-hoffman-server-has-tls as..

o A client whose policy is that it is a CSO MUST only try to
communicate securely with a server that has the secure-port set t=
o
a non-zero number; it MUST NOT try to communicate with the server=

on the insecure-port value given.

Which is essentially the HSTS behavior for a client when connecting to a =
"known
HSTS host".

And also for consumer general-purpose browsers, it seems to me that they =
will
need to behave as whichever of {CIO,CSO,CFB} on a per-host (ie per webapp=
)
basis.

hope this helps,

=3DJeffH
------

[quickly selected bibliography, nominally ordered reverse-chrono; all pap=
ers=20
should be available on web, discoverable by google scholar and/or citesee=
r]

You=92ve Been Warned: An Empirical Study of the
Effectiveness of Web Browser Phishing Warnings
Serge Egelman, Lorrie Faith Cranor, Jason Hong; 2010

Crying Wolf: An Empirical Study of SSL Warning Effectiveness
Joshua Sunshine, Serge Egelman, Hazim Almuhimedi, Neha Atri, and Lorrie F=
aith=20
Cranor; 2009

Browser Interfaces and Extended Validation
SSL Certificates: An Empirical Study
Sobey, Whalen, Biddle, van Oorschot, Patrick; 2009

Browser Interfaces and EV-SSL Certificates:
Confusion, Inconsistencies and HCI Challenges
Jennifer Sobey, P.C. van Oorschot, and Andrew S. Patrick; 2009

Exploring User Reactions to New Browser Cues
for Extended Validation Certificates
Jennifer Sobey, Robert Biddle, P.C. van Oorschot, and Andrew S. Patrick; =
2008

The Emperor=92s New Security Indicators
An evaluation of website authentication
and the effect of role playing on usability studies
Stuart E. Schechter Rachna Dhamija Andy Ozment Ian Fischer; 2007

An Evaluation of Extended Validation and
Picture-in-Picture Phishing Attacks
Collin Jackson, Daniel R. Simon, Desney S. Tan, and Adam Barth; 2007

Deceit and Deception: A Large User Study of Phishing
Alex Tsow and Markus Jakobsson; 2007

Do Security Toolbars Actually Prevent Phishing Attacks?
Min Wu, Robert C. Miller, Simson L. Garfinkel; 2006

Gathering Evidence: Use of Visual Security Cues in Web Browsers
Tara Whalen Kori M. Inkpen; 2005

User Perceptions of Privacy and Security on the Web
Scott Flinn and Joanna Lumsden; 2005

---
end

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 375343A6895 for ; Thu, 23 Dec 2010 13:50:00 -0800 (PST)
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.212, 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 lZ4uUL0f1j4q for ; Thu, 23 Dec 2010 13:49:59 -0800 (PST)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id C927D3A68AC for ; Thu, 23 Dec 2010 13:49:58 -0800 (PST)
Received: by gyd12 with SMTP id 12so2958804gyd.31 for ; Thu, 23 Dec 2010 13:51:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=PzQVYUNtu9x/Sz91RBefZQi8TXhi4A06bFR3LExQJAA=; b=W1CMMhzvOfK9Hzy9CjDoCqqXV+aTyvCyrEX16SY3zu3NgoDdNiDVJ5BzbeorBviLTX ZGdLbgQ1z5oRQVkqWKhUsSXxMtyrjxGFNb5J9JJKN0tnmFaBYtS1f+srIL75o3yqE+Dh kSdoWwSmoDVdWcGtVHgC1Y+zbgbWzGhEcU8/s=
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=s0+xnMaxLC8FZrNWm9twioe1VfXYQjkbx2sCf3xHSemiYbd6+4ItoHA3RbRsEUABzr 04giU6zKqAv6WqcPezyqQpAqiR94BcWwDpOyloL4CLZu6ghr+5iGMj8JdTNnAQvLm/G8 +bYpU9Prq9m/YdHjyJTXVBfmH5/EGflQMePTE=
MIME-Version: 1.0
Received: by 10.100.57.11 with SMTP id f11mr2093047ana.205.1293141118963; Thu, 23 Dec 2010 13:51:58 -0800 (PST)
Received: by 10.100.31.8 with HTTP; Thu, 23 Dec 2010 13:51:58 -0800 (PST)
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Thu, 23 Dec 2010 21:51:58 +0000
Message-ID:
From: Phillip Hallam-Baker
To: Paul Wouters
Content-Type: multipart/alternative; boundary=0016e644c7040a4e3904981ae123
Cc: "[email-masked]" , Paul Hoffman
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 23 Dec 2010 21:50:00 -0000

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

Well it was 14 years ago.

It was an informational RFC and is not binding on the current membership:

Status of This Memo

This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited

Moreover it does not make the statement you allege concerning MITM.

So not only is RFC 1984 not binding IETF policy, it does not make the
statement you claim.

I do wish that people would actually read documents that they keep
referencing. In this case it is only 4 pages long.

On Thu, Dec 23, 2010 at 9:42 PM, Paul Wouters wrote:

> On Thu, 23 Dec 2010, Phillip Hallam-Baker wrote:
>
> I was referring there to DANE rather than the IETF.
>>
>
> But DANE is part of an IETF WG, and RFC1984 is a firm statement by the
> IAB/IESG
>
>
> In my view we should separate design of censorship busting protocols from
>> design of regular protocols.
>>
>
> You mentioned MITM's should not be "either supported or attempted to
> prevent".
>
> I wanted to remind everyone that the IETF concensus is that preventing
> MITM is very much its goal (on the protocol level)
>
>
> If you are going to deploy something that is robust you have to make
>> busting censorship your first last and only goal
>> (e.g. Tor).
>>
>
> Agreed, but for MITM attacks against TLS/SSL, we should clearly have a
> "MUST abort" when the
> client detects a MITM for our protocol specifications. And not build in a
> "china" or "school" or
> "stock brokers" function. Leave that to the implementors (as RFC1984
> states)
>
>
> One of the un-noticed costs of the cryptowars was that making protocols
>> resistant to Louis Freeh became a higher
>> priority than making them easy to use. And as a result we ended up with
>> two email encryption schemes that are really,
>> really secure but practically unused.
>>
>> A protocol should be one or the other, trying to be both ends up with a
>> scheme that serves neither purpose.
>>
>
> I'm not sure if I agree, but regardless this seems out of scope on the
> current discussion on
> "client policy" vs "protocol specification placed limits on what clients
> SHOULD do".
>
>
> This particular capability is like key-escrow. It is something that is
>> perfectly acceptable within specific
>> circumstances but totally unacceptable when it becomes a mandate with the
>> government in control.
>>
>
> And hence, again, RFC1984 says "do not add escrow to the protocol, add it
> to the implementation".
>
> Which is what I am arguing for the "MUST NOT fallback to port 80"
>
> Paul
>

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

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

Well it was 14 years ago.

It was an informational RFC an=
d is not binding on the current membership:

Status of This Memo

This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited

Moreover it does not m=
ake the statement you allege concerning MITM.

So n=
ot only is RFC 1984 not binding IETF policy, it does not make the statement=
you claim.

I do wish that people would actually read documents tha=
t they keep referencing. In this case it is only 4 pages long.=A0

On Thu, Dec 23, 2010 at 9:42=
PM, Paul Wouters <[email-masked]> wrote:

On Thu, 23 Dec 2010, Phil=
lip Hallam-Baker wrote:

I was referring there to DANE rather than the IETF.

But DANE is part of an IETF WG, and RFC1984 is a firm statement by the IAB/=
IESG

In my view we should separate design of censorship busting protocols from d=
esign of regular protocols.=A0

You mentioned MITM's should not be "either supported or attempted =
to prevent".

I wanted to remind everyone that the IETF concensus is that preventing

MITM is very much its goal (on the protocol level)

If you are going to deploy something that is robust you have to make bustin=
g censorship your first last and only goal

(e.g. Tor).

Agreed, but for MITM attacks against TLS/SSL, we should clearly have a &quo=
t;MUST abort" when the

client detects a MITM for our protocol specifications. And not build in a &=
quot;china" or "school" or

"stock brokers" function. Leave that to the implementors (as RFC1=
984 states)

One of the un-noticed costs of the cryptowars was that making protocols res=
istant to Louis Freeh became a higher

priority than making them easy to use. And as a result we ended up with two=
email encryption schemes that are really,

really secure but practically unused.=A0

A protocol should be one or the other, trying to be both ends up with a sch=
eme that serves neither purpose.

I'm not sure if I agree, but regardless this seems out of scope on the =
current discussion on

"client policy" vs "protocol specification placed limits on =
what clients SHOULD do".

This particular capability is like key-escrow. It is something that is perf=
ectly acceptable within specific

circumstances but totally unacceptable when it becomes a mandate with the g=
overnment in control.

And hence, again, RFC1984 says "do not add escrow to the protocol, add=
it to the implementation".

Which is what I am arguing for the "MUST NOT fallback to port 80"=

Paul

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

--0016e644c7040a4e3904981ae123--

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BADB3A68A9 for ; Thu, 23 Dec 2010 13:40:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.583
X-Spam-Level:
X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 vM5L8t5-FTtX for ; Thu, 23 Dec 2010 13:40:12 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 8074F3A68A4 for ; Thu, 23 Dec 2010 13:40:11 -0800 (PST)
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 0C1E8C412; Thu, 23 Dec 2010 16:42:12 -0500 (EST)
Date: Thu, 23 Dec 2010 16:42:11 -0500 (EST)
From: Paul Wouters
To: Phillip Hallam-Baker
In-Reply-To:
Message-ID:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT
Cc: "[email-masked]" , Paul Hoffman
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 23 Dec 2010 21:40:13 -0000

On Thu, 23 Dec 2010, Phillip Hallam-Baker wrote:

> I was referring there to DANE rather than the IETF.

But DANE is part of an IETF WG, and RFC1984 is a firm statement by the IAB/IESG

> In my view we should separate design of censorship busting protocols from design of regular protocols.�

You mentioned MITM's should not be "either supported or attempted to prevent".

I wanted to remind everyone that the IETF concensus is that preventing
MITM is very much its goal (on the protocol level)

> If you are going to deploy something that is robust you have to make busting censorship your first last and only goal
> (e.g. Tor).

Agreed, but for MITM attacks against TLS/SSL, we should clearly have a "MUST abort" when the
client detects a MITM for our protocol specifications. And not build in a "china" or "school" or
"stock brokers" function. Leave that to the implementors (as RFC1984 states)

> One of the un-noticed costs of the cryptowars was that making protocols resistant to Louis Freeh became a higher
> priority than making them easy to use. And as a result we ended up with two email encryption schemes that are really,
> really secure but practically unused.�
>
> A protocol should be one or the other, trying to be both ends up with a scheme that serves neither purpose.

I'm not sure if I agree, but regardless this seems out of scope on the current discussion on
"client policy" vs "protocol specification placed limits on what clients SHOULD do".

> This particular capability is like key-escrow. It is something that is perfectly acceptable within specific
> circumstances but totally unacceptable when it becomes a mandate with the government in control.

And hence, again, RFC1984 says "do not add escrow to the protocol, add it to the implementation".

Which is what I am arguing for the "MUST NOT fallback to port 80"

Paul

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67B0E3A68A7 for ; Thu, 23 Dec 2010 13:32:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.384
X-Spam-Level:
X-Spam-Status: No, score=-3.384 tagged_above=-999 required=5 tests=[AWL=0.214, 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 V99h5F0rDLd0 for ; Thu, 23 Dec 2010 13:32:26 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 439093A68A4 for ; Thu, 23 Dec 2010 13:32:26 -0800 (PST)
Received: by gxk28 with SMTP id 28so3441370gxk.31 for ; Thu, 23 Dec 2010 13:34:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=C9jYmxFGC8CvJV0cpI8ejFw5lIVjmiYdGoS6RZamF/Y=; b=rYVf8BJY80UIo4u9PUJ+oOQ+KMh76Q6nyBMHHUCslNWSw45XVeXHLsxL5uaPglc5db Ha3f8Ox2Xz9ROIpqRJBERbdpNNIAk95xyA7dJgWZD8miIDB0wiPZRihcJ9Djtv2z9t0n 5rGxLZvq5ay7JG4jrIaVnmCI7K2KzcOlunzhE=
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=hmW+sCkCEzbfqMUi62NGXcwPxGbA5y4hpdgT+kpBCHjJS9rbkCbQrSyglrosOpuV4o 3C88pL3bvqqENpJ1TbMtLgjuB23UoTt7PL2l0VYPfy9oBQzFte/MZPeEbfsDEYdDryt8 YdYlz8GJoKDzpdkPCDUdVt1dU5eXCUDlJZWtI=
MIME-Version: 1.0
Received: by 10.100.228.14 with SMTP id a14mr3766721anh.239.1293140066872; Thu, 23 Dec 2010 13:34:26 -0800 (PST)
Received: by 10.100.31.8 with HTTP; Thu, 23 Dec 2010 13:34:26 -0800 (PST)
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Thu, 23 Dec 2010 21:34:26 +0000
Message-ID:
From: Phillip Hallam-Baker
To: Paul Wouters
Content-Type: multipart/alternative; boundary=0016e6d2767154ae1504981aa238
Cc: "[email-masked]" , Paul Hoffman
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 23 Dec 2010 21:32:28 -0000

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

I was referring there to DANE rather than the IETF.

In my view we should separate design of censorship busting protocols from
design of regular protocols.

If you are going to deploy something that is robust you have to make busting
censorship your first last and only goal (e.g. Tor).

One of the un-noticed costs of the cryptowars was that making protocols
resistant to Louis Freeh became a higher priority than making them easy to
use. And as a result we ended up with two email encryption schemes that are
really, really secure but practically unused.

A protocol should be one or the other, trying to be both ends up with a
scheme that serves neither purpose.

This particular capability is like key-escrow. It is something that is
perfectly acceptable within specific circumstances but totally unacceptable
when it becomes a mandate with the government in control.

On Thu, Dec 23, 2010 at 9:12 PM, Paul Wouters wrote:

> On Thu, 23 Dec 2010, Phillip Hallam-Baker wrote:
>
> [ MITM SSL, authorised or not]
>
>
> Obviously, there are very big problems with this type of behavior when it
>> is being used by ISPs to spy on their
>> customers, as certain authoritarian governments require. But those are not
>> use cases I think we need to either support
>>
>
> Agreed.
>
> or attempt to prevent.
>>
>
> Disagreed. Not just by me, but as clearly stated in RFC 1984
>
> The IAB and IESG would like to encourage policies that allow ready
> access to uniform strong cryptographic technology for all Internet
> users in all countries.
>
> [...]
>
> Cryptography is the most powerful single tool that users
> can use to secure the Internet. Knowingly making that tool weaker
> threatens their ability to do so, and has no proven benefit.
>
> But I think we agree that a big large warning in the browser about the
> DNSEEC/CA validated key mismatch
> is where our preventative action should stop.
>
>
> Note that there are various institutions that view TLS as an evil not
>> to be tolerated (schools being a notable example), so many services
>> are unable to go TLS-only.
>>
>
> I remember France once tried to ban ssh nationally as well. Which ones
> would we be willing to support and which ones would we not? I think RFC
> 1984 is clear that at the protocol level, we should not make decisions
> based on the crypto restrictions of certain regimes or businesses,
> and that any crippling of crypto should be left to implementors.
>
> Paul
>

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

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

I was referring there to DANE rather than the IETF.

In m=
y view we should separate design of censorship busting protocols from desig=
n of regular protocols.=A0

If you are going to dep=
loy something that is robust you have to make busting censorship your first=
last and only goal (e.g. Tor).

One of the un-noticed costs of the cryptowars was that =
making protocols resistant to Louis Freeh became a higher priority than mak=
ing them easy to use. And as a result we ended up with two email encryption=
schemes that are really, really secure but practically unused.=A0

A protocol should be one or the other, trying to be bot=
h ends up with a scheme that serves neither purpose.

This particular capability is like key-escrow. It is some=
thing that is perfectly acceptable within specific circumstances but totall=
y unacceptable when it becomes a mandate with the government in control.

On Thu, Dec 23, 2010 at 9:12 PM, Paul W=
outers <paul@xel=
erance.com> wrote:

On Thu, 23 Dec 2010, Phillip Hallam-Baker wrote:

[ MITM SSL, authorised or not]

Obviously, there are very big problems with this type of behavior when it i=
s being used by ISPs to spy on their

customers, as certain authoritarian governments require. But those are not =
use cases I think we need to either support

Agreed.

or attempt to prevent.=A0

Disagreed. Not just by me, but as clearly stated in RFC 1984

=A0 =A0 =A0 =A0The IAB and IESG would like to encourage policies that allo=
w ready

=A0 =A0 =A0 =A0access to uniform strong cryptographic technology for all I=
nternet

=A0 =A0 =A0 =A0users in all countries.

[...]

=A0 =A0 =A0 =A0Cryptography is the most powerful single tool that users
=A0 =A0 =A0 =A0can use to secure the Internet. Knowingly making that tool =
weaker

=A0 =A0 =A0 =A0threatens their ability to do so, and has no proven benefit=
.

But I think we agree that a big large warning in the browser about the DNSE=
EC/CA validated key mismatch

is where our preventative action should stop.

Note that there are various institutions that view TLS as an evil not

to be tolerated (schools being a notable example), so many services

are unable to go TLS-only.

I remember France once tried to ban ssh nationally as well. Which ones

would we be willing to support and which ones would we not? I think RFC

1984 is clear that at the protocol level, we should not make decisions

based on the crypto restrictions of certain regimes or businesses,

and that any crippling of crypto should be left to implementors.

Paul

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

--0016e6d2767154ae1504981aa238--

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DF463A6899 for ; Thu, 23 Dec 2010 13:10:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.583
X-Spam-Level:
X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 mmdhiQkNw7UH for ; Thu, 23 Dec 2010 13:10:13 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 11A063A6893 for ; Thu, 23 Dec 2010 13:10:13 -0800 (PST)
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 80759C4EC; Thu, 23 Dec 2010 16:12:12 -0500 (EST)
Date: Thu, 23 Dec 2010 16:12:11 -0500 (EST)
From: Paul Wouters
To: Phillip Hallam-Baker
In-Reply-To:
Message-ID:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT
Cc: "[email-masked]" , Paul Hoffman
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 23 Dec 2010 21:10:14 -0000

On Thu, 23 Dec 2010, Phillip Hallam-Baker wrote:

[ MITM SSL, authorised or not]

> Obviously, there are very big problems with this type of behavior when it is being used by ISPs to spy on their
> customers, as certain authoritarian governments require. But those are not use cases I think we need to either support

Agreed.

> or attempt to prevent.�

Disagreed. Not just by me, but as clearly stated in RFC 1984

The IAB and IESG would like to encourage policies that allow ready
access to uniform strong cryptographic technology for all Internet
users in all countries.

[...]

Cryptography is the most powerful single tool that users
can use to secure the Internet. Knowingly making that tool weaker
threatens their ability to do so, and has no proven benefit.

But I think we agree that a big large warning in the browser about the DNSEEC/CA validated key mismatch
is where our preventative action should stop.

> Note that there are various institutions that view TLS as an evil not
> to be tolerated (schools being a notable example), so many services
> are unable to go TLS-only.

I remember France once tried to ban ssh nationally as well. Which ones
would we be willing to support and which ones would we not? I think RFC
1984 is clear that at the protocol level, we should not make decisions
based on the crypto restrictions of certain regimes or businesses,
and that any crippling of crypto should be left to implementors.

Paul

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45C523A683C for ; Thu, 23 Dec 2010 09:00:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.671
X-Spam-Level:
X-Spam-Status: No, score=-3.671 tagged_above=-999 required=5 tests=[AWL=-0.073, 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 6ywKbsuD18af for ; Thu, 23 Dec 2010 09:00:25 -0800 (PST)
Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id E3E2E3A6833 for ; Thu, 23 Dec 2010 09:00:24 -0800 (PST)
Received: by gwj17 with SMTP id 17so4595971gwj.31 for ; Thu, 23 Dec 2010 09:02:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=COoMarTX9kdjBq+Q6v6o2FA6qx7+J3SuZd3w3oQioGU=; b=lJ6P0RcNliFVdkSGx8u/2X4l5AqPavJqr14M/DhHN17r3wxoNQfL0MBYF9VeeDYbMj +819N3FdFGp0KJIUaxerpTnMiUVrIHdUgU884NTelQRtGS4Y25EYXbtrs+6q1Vj0Qcxt O1yFQ1OQcDZRM7OD+49itRgeSor11pAWD+GQQ=
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=usu9k99HA0yEr2zUMFNjRX/D5aUnhbAXzFNZuKa0VjzYDDR6IqU5ruEaQOxCOnOX6Z ZVTlujM/cJ2kAf8uJuaoWYsggKKIKAjWasFAtzB6Yy84oH1QCilVHY0BQiUKpK33/5nH 4PIDB/mQWIBfemnnelipRQlUeWQRAY0L9X3Ko=
MIME-Version: 1.0
Received: by 10.101.67.16 with SMTP id u16mr5095245ank.1.1293123744430; Thu, 23 Dec 2010 09:02:24 -0800 (PST)
Received: by 10.100.31.8 with HTTP; Thu, 23 Dec 2010 09:02:24 -0800 (PST)
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Thu, 23 Dec 2010 17:02:24 +0000
Message-ID:
From: Phillip Hallam-Baker
To: Ben Laurie
Content-Type: multipart/alternative; boundary=00163662e65b6ffc58049816d567
Cc: "[email-masked]" , Paul Hoffman
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 23 Dec 2010 17:00:26 -0000

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

There is also a fairly important Wall Street use case.

Regulators require banks to have complete archives of client-broker
communications. So brokers connecting up to TLS protected Web sites from
work machines becomes problematic. So some block TLS entirely.

I prefer a solution where the browser knows that the security policy for the
zone requires the TLS connection to be intermediated *AND* clearly notifies
the user that this is in use.

Obviously, there are very big problems with this type of behavior when it is
being used by ISPs to spy on their customers, as certain authoritarian
governments require. But those are not use cases I think we need to either
support or attempt to prevent.

On Thu, Dec 23, 2010 at 2:35 PM, Ben Laurie wrote:

> On 22 December 2010 15:43, Paul Hoffman wrote:
> > You have no way of knowing that, and I have no way of knowing the
> opposite. The fact that PayPal has been TLS-only for years has taught PayPal
> users to expect 443, but PayPal is (sadly) in the very small minority, so
> your users are not a good metric.
>
> Note that there are various institutions that view TLS as an evil not
> to be tolerated (schools being a notable example), so many services
> are unable to go TLS-only.
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

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

There is also a fairly important Wall Street use case.

R=
egulators require banks to have complete archives of client-broker communic=
ations. So brokers connecting up to TLS protected Web sites from work machi=
nes becomes problematic. So some block TLS entirely.

I prefer a solution where the browser knows that the se=
curity policy for the zone requires the TLS connection to be intermediated =
*AND* clearly notifies the user that this is in use.

Obviously, there are very big problems with this type o=
f behavior when it is being used by ISPs to spy on their customers, as cert=
ain authoritarian governments require. But those are not use cases I think =
we need to either support or attempt to prevent.=A0

On Thu, Dec 23, 2010 at 2:35 PM, Be=
n Laurie <benl@goog=
le.com> wrote:

On 22 December 2010 15:43, Paul Hoffman <[email-masked]> wrote:

> You have no way of knowing that, and I have no way of knowing the oppo=
site. The fact that PayPal has been TLS-only for years has taught PayPal us=
ers to expect 443, but PayPal is (sadly) in the very small minority, so you=
r users are not a good metric.

Note that there are various institutions that view TLS as an evil not=

to be tolerated (schools being a notable example), so many services

are unable to go TLS-only.

_________________________________________=
______

keyassure mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/keyassure

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

--00163662e65b6ffc58049816d567--

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CC123A67D7 for ; Thu, 23 Dec 2010 06:47:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.894
X-Spam-Level:
X-Spam-Status: No, score=-2.894 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wEB9xzsbcPB5 for ; Thu, 23 Dec 2010 06:47:16 -0800 (PST)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 2FA093A67D1 for ; Thu, 23 Dec 2010 06:47:16 -0800 (PST)
Received: by iwn40 with SMTP id 40so6620782iwn.31 for ; Thu, 23 Dec 2010 06:49:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=i6fFdIOIYkt+mM8X6twcy1aS4UtBHc+xULqGKjN6Sms=; b=NgsLd9LdP01P61D7YKE2iKrtKvaEkCVe6F/V/YO5SzrVWzm74lwECNTEMbkom/+sem kJrqwkUyx+484wAUjg0mL0Ezsh+v6ml9y1jkeaioV+fTHieMKM61INd5O0z/wFQk6RVp 7mXfQzX4Y6ZW/gKyj4uqTQtZeEHlZy/+f+xN8=
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=PeqXDdkMvbLQYDAlDq3MUK8oAJzRBwHzdnIMxdYjghkRViwu6ZOqLr+XH/TZNVhj7k lpzi7rPHwzboOyA+wwstGQzd705jhuDsJ7AGdwf8MMwzwRl1y1Tt5IGTO/Q154E7gUQr ayS+qJO1b2501+d7yHdVquQdy9LCQVbPvmLF0=
MIME-Version: 1.0
Received: by 10.42.178.69 with SMTP id bl5mr8390719icb.338.1293115755826; Thu, 23 Dec 2010 06:49:15 -0800 (PST)
Sender: [email-masked]
Received: by 10.42.219.134 with HTTP; Thu, 23 Dec 2010 06:49:15 -0800 (PST)
In-Reply-To:
References:
Date: Thu, 23 Dec 2010 09:49:15 -0500
X-Google-Sender-Auth: ervB6-EgWMSUy7-ix1E11rLyCTs
Message-ID:
From: Adam Langley
To: Phillip Hallam-Baker
Content-Type: text/plain; charset=UTF-8
Cc: [email-masked]
Subject: Re: [keyassure] Efficient Mega-Queries
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 23 Dec 2010 14:47:17 -0000

On Thu, Dec 23, 2010 at 9:02 AM, Phillip Hallam-Baker wrote:
> Extended discovery mechanisms can be implemented in ways that offer
> equivalent performance to existing methods.

There are a couple of assumptions that I would like to question here.

1) That doing two DNS lookups (to the same zone) in parallel costs the
same as doing a single lookup.

Firstly, ignoring caching, we can assume that the zone's nameserver is
50ms away and that the host resolver's timeout (over which we
typically have no control) is 3 seconds. Therefore the time taken to
do a single lookup is:

50ms + p*(3000ms + 50ms) (where p is the packet loss rate)

Over the public Internet, p = 1% isn't too far off, giving a total
time of 80.5ms. (The effect of double packet loss is so small that we
can ignore it.)

Now, for two concurrent lookups, the time taken is

50ms + (1-(1-p)^2)*(3000 + 50) = 110.7ms (again, ignoring double loss)

There are a couple of assumptions in there which can be called into
question. I've assumed that packet loss is i.i.d, although sometimes
it certainly isn't depending on the type of competing network traffic
and the queue management of the bottleneck router. If loss is
correlated in time then the concurrent requests look *better*. On the
otherhand, it's misleading to suggest that the average DNS query time
is what we should be measuring. The tail is important too and, in the
above model, the tail ends up nearly twice as fat.

Concurrent requests might have unintended consequences if we consider
caching. Since each different RR type will have its own signature, we
are increasing the pressure on the cache. This might cause the general
hit-rate to drop affecting everybody.

2) That we can overlap TCP socket creation and the TLS handshake with
DNS requests.

Currently Chrome is already capable of 0-RTT TLS handshakes. If we had
the server's public key in place at the start of the connection, we
could use it.

Also, in the lab, Chrome is capable of sending a single TCP SYN +
payload packet and, with it, setting up the TCP connection, TLS
connection and delivering application data. It would be nice not to
preclude these possibilities. Although, they are based on cached
information from the server so it may be reasonable to assume that the
client could also cache any needed DNS information.

Cheers

AGL

--
Adam Langley [email-masked] http://www.imperialviolet.org

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DA8A3A67E4 for ; Thu, 23 Dec 2010 06:41:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gc40e6Hbux3G for ; Thu, 23 Dec 2010 06:41:44 -0800 (PST)
Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by core3.amsl.com (Postfix) with ESMTP id 857543A67E3 for ; Thu, 23 Dec 2010 06:41:44 -0800 (PST)
Received: from albook.hsd1.ca.comcast.net (c-67-164-126-174.hsd1.ca.comcast.net [67.164.126.174]) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id 2C78A36A586; Thu, 23 Dec 2010 06:43:45 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: Nicholas Weaver
In-Reply-To:
Date: Thu, 23 Dec 2010 06:43:44 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
To: Ben Laurie
X-Mailer: Apple Mail (2.1082)
Cc: "[email-masked]" , Paul Hoffman
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 23 Dec 2010 14:41:45 -0000

On Dec 23, 2010, at 6:35 AM, Ben Laurie wrote:

> On 22 December 2010 15:43, Paul Hoffman wrote:
>> You have no way of knowing that, and I have no way of knowing the =
opposite. The fact that PayPal has been TLS-only for years has taught =
PayPal users to expect 443, but PayPal is (sadly) in the very small =
minority, so your users are not a good metric.
>=20
> Note that there are various institutions that view TLS as an evil not
> to be tolerated (schools being a notable example), so many services
> are unable to go TLS-only.

In fact, this is why HTTPS://www.google.com redirects to =
https://encrypted.google.com

OTOH, we shouldn't encourage this behavior in DNS or elsewhere: If =
network policy demands unencrypted traffic, it should instead demand =
that the browsers snitch the session keys to the IDS (easy enough to do) =
and the IDS blocks unsnitched sessions only.

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6895E3A67D7 for ; Thu, 23 Dec 2010 06:41:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.187
X-Spam-Level:
X-Spam-Status: No, score=-104.187 tagged_above=-999 required=5 tests=[AWL=-2.210, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 xBjRiC+umDfQ for ; Thu, 23 Dec 2010 06:41:41 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 5A7303A67D1 for ; Thu, 23 Dec 2010 06:41:41 -0800 (PST)
Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id oBNEheZ2027906 for ; Thu, 23 Dec 2010 06:43:40 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1293115420; bh=eQ7tlMbUcUxVFEUgfLvza4LfHg4=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=mSRZ2PdCieRVh7fPBPQ5LDIeiiAI4HRqjPeNgo7+j6qFDhImCKNmSse++benrEyiX mKuP6Qs+At9xmRc4xk7qg==
Received: from qyk27 (qyk27.prod.google.com [10.241.83.155]) by hpaq1.eem.corp.google.com with ESMTP id oBNEhcBN016959 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 23 Dec 2010 06:43:39 -0800
Received: by qyk27 with SMTP id 27so6230623qyk.8 for ; Thu, 23 Dec 2010 06:43:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=dymgppuF2SF9lYkESwHId7qGT6fngKhGHW/0XwbYzm4=; b=EyIRpnLacOtvO6gzuEdiU5mQO8Pbk2RExLPjEbZzUYpkff95VCDRboVLhlodDRnnuL JZQ24/KX5FOuJ1MpC3Uw==
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; b=of4OvQzIvj4L/GtoRB7MPeI/lbhf3njr8mWHLSIU9q4HBNoiczkn6wRTWMHuP77TAe caElWLclVO/ROrAmYOyA==
MIME-Version: 1.0
Received: by 10.224.19.131 with SMTP id a3mr1422640qab.388.1293115416991; Thu, 23 Dec 2010 06:43:36 -0800 (PST)
Received: by 10.220.126.219 with HTTP; Thu, 23 Dec 2010 06:43:36 -0800 (PST)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Date: Thu, 23 Dec 2010 14:43:36 +0000
Message-ID:
From: Ben Laurie
To: Ilari Liusvaara
Content-Type: text/plain; charset=ISO-8859-1
X-System-Of-Record: true
Cc: "[email-masked]" , Phillip Hallam-Baker , Paul Hoffman
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 23 Dec 2010 14:41:42 -0000

On 22 December 2010 23:54, Ilari Liusvaara wrote:
> On Wed, Dec 22, 2010 at 09:39:51PM +0000, Phillip Hallam-Baker wrote:
>> I look at the problem differently.
>>
>> The server site is merely describing its local security policy to whoever
>> might want to connect. So it is making statements such as
>>
>> "TLS is always offered"
>> "TLS must be used"
>> "IPSEC must be used"
>> "A path for the cert can be formed from CA cert X"
>> "The key is Y"
>>
>> These are all merely descriptive of the server security policy. IOf clients
>> want to connect, they can make their own choices.
>
> I don't consider the first and last two as not policy but as facts. The other
> two are policy.
>
> I consider statements about behaviour of genuine server(s) and domain as whole
> as facts. These include if it offers (START)TLS or not, what keys it uses, what
> CAs (if any) those certificates chain to, etc... Those three statements all
> directly map to properties of the host.
>
> "TLS/IPSEC must be used" don't directly map to any property of the server nor
> the domain.

If you express them as "Only TLS/IPSEC are offered", then they, too,
become factual.

>
>> Server policies such as 'must use TLS' are going to be very hard to
>> implement outside of closed environments. The NSA and banks can use that
>> policy internally. It would be rather difficult for most sites to do so.
>
> That's because they are policy.
>
> -Ilari
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFDF03A67D3 for ; Thu, 23 Dec 2010 06:33:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.056
X-Spam-Level:
X-Spam-Status: No, score=-106.056 tagged_above=-999 required=5 tests=[AWL=-0.079, 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 uLRH6-Qhf8JI for ; Thu, 23 Dec 2010 06:33:13 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id D30BD3A6784 for ; Thu, 23 Dec 2010 06:33:12 -0800 (PST)
Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id oBNEZCTM017825 for ; Thu, 23 Dec 2010 06:35:12 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1293114912; bh=foat3MDaZJHUY2NFSzdJjV0Tj8g=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=mGvX9Ml21H5J/319TOEAL1ZaczrK4nUHkVC52PANHmisFWb1n4RBJuJeUqdcFuNUy JY+r+Ira+fzL0fleEnIdw==
Received: from qwj9 (qwj9.prod.google.com [10.241.195.73]) by hpaq5.eem.corp.google.com with ESMTP id oBNEZAnn012498 for ; Thu, 23 Dec 2010 06:35:10 -0800
Received: by qwj9 with SMTP id 9so6750298qwj.41 for ; Thu, 23 Dec 2010 06:35:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=IchrvC1BPHf2k08YwNP+sCDV7SkYJZZ3WJ06qE1Hf8U=; b=Qzch5ErueeWgosZoJQiRUMILGq8k4NlPwGvD2D2FrT3x/t+gok5GE4Rna7GD3VmVzk 6r3BPjN9zE9q8pvsj0GQ==
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; b=Nj7sfNkKTTSWv+p7h2Dsg5L6uVhfBS68YGb1dG9/mxco3s5dxFoUgo/vbVmx9Tmao0 U7CuR51yFvmDkvIJxxpw==
MIME-Version: 1.0
Received: by 10.224.11.12 with SMTP id r12mr7530219qar.288.1293114909412; Thu, 23 Dec 2010 06:35:09 -0800 (PST)
Received: by 10.220.126.219 with HTTP; Thu, 23 Dec 2010 06:35:09 -0800 (PST)
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Thu, 23 Dec 2010 14:35:09 +0000
Message-ID:
From: Ben Laurie
To: Paul Hoffman
Content-Type: text/plain; charset=ISO-8859-1
X-System-Of-Record: true
Cc: "[email-masked]"
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 23 Dec 2010 14:33:14 -0000

On 22 December 2010 15:43, Paul Hoffman wrote:
> You have no way of knowing that, and I have no way of knowing the opposite. The fact that PayPal has been TLS-only for years has taught PayPal users to expect 443, but PayPal is (sadly) in the very small minority, so your users are not a good metric.

Note that there are various institutions that view TLS as an evil not
to be tolerated (schools being a notable example), so many services
are unable to go TLS-only.

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 017153A67B3 for ; Thu, 23 Dec 2010 06:12:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.478
X-Spam-Level:
X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 GyYpH+BsIHpG for ; Thu, 23 Dec 2010 06:12:51 -0800 (PST)
Received: from emh02.mail.saunalahti.fi (emh02.mail.saunalahti.fi [62.142.5.108]) by core3.amsl.com (Postfix) with ESMTP id 155B73A67AB for ; Thu, 23 Dec 2010 06:12:51 -0800 (PST)
Received: from saunalahti-vams (vs3-11.mail.saunalahti.fi [62.142.5.95]) by emh02-2.mail.saunalahti.fi (Postfix) with SMTP id 1376BF0CC8; Thu, 23 Dec 2010 16:14:50 +0200 (EET)
Received: from emh05.mail.saunalahti.fi ([62.142.5.111]) by vs3-11.mail.saunalahti.fi ([62.142.5.95]) with SMTP (gateway) id A061F40662B; Thu, 23 Dec 2010 16:14:50 +0200
Received: from LK-Perkele-VI (a88-112-56-215.elisa-laajakaista.fi [88.112.56.215]) by emh05.mail.saunalahti.fi (Postfix) with ESMTP id 67F8D27D85; Thu, 23 Dec 2010 16:14:46 +0200 (EET)
Date: Thu, 23 Dec 2010 16:15:05 +0200
From: Ilari Liusvaara
To: Phillip Hallam-Baker
Message-ID: <[email-masked]>
References: <[email-masked]> <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To:
User-Agent: Mutt/1.5.20 (2009-06-14)
Sender: Ilari Liusvaara
X-Antivirus: VAMS
Cc: "[email-masked]" , Paul Hoffman
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 23 Dec 2010 14:12:52 -0000

On Thu, Dec 23, 2010 at 10:20:15AM +0000, Phillip Hallam-Baker wrote:
> On Wed, Dec 22, 2010 at 11:54 PM, Ilari Liusvaara <
> [email-masked]> wrote:
>
> > On Wed, Dec 22, 2010 at 09:39:51PM +0000, Phillip Hallam-Baker wrote:
> > >
> > > "TLS is always offered"
> > > "TLS must be used"
> > > "IPSEC must be used"
> > > "A path for the cert can be formed from CA cert X"
> > > "The key is Y"
> > >

> Why do you think the last two are not factual? Could we express them in a
> fashion that you consider to be objective?

I said last two ARE factual (might have miscommunicated this).

-Ilari

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAEF73A676A for ; Thu, 23 Dec 2010 06:00:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.947
X-Spam-Level:
X-Spam-Status: No, score=-2.947 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, 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 NYQAUM1a4IZl for ; Thu, 23 Dec 2010 06:00:17 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id A74F43A66B4 for ; Thu, 23 Dec 2010 06:00:16 -0800 (PST)
Received: by gxk28 with SMTP id 28so3271065gxk.31 for ; Thu, 23 Dec 2010 06:02:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=JexmczgVeCPH/sTgi4pNvzG9BDX6/ZIedb2mwyYwj+E=; b=IA/qO4x+oZ6MISvmQHYgRBiGae37i77W2FhGvU9pB73oGlQGTOBKZgZyFEvxicPJXP moH/oP2cDUkM0xxivLR47eZa+ouyFac/RBYseb5RfZlLX1bDbiDyu3CNwCuvnJorRlp6 BvOo7wvpia9ZP8r4o8469eCLslawGoDYArSfA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=eOZfVIyZ8szkzAT8pcxFM71SeUkghC/roNzuuqj0M808HdNacWOeYdNAcAUJXW3NCn FN94gk4QPWnJUd19YAVJdPm1G7Z6qnPLF4uI9Protwrfgg2XuW2DpFQYQlusnz8QJcQ5 pOkBqIZF24mk0EvihLEyECnzyRLe9VPgge5os=
MIME-Version: 1.0
Received: by 10.100.122.9 with SMTP id u9mr5022490anc.171.1293112935957; Thu, 23 Dec 2010 06:02:15 -0800 (PST)
Received: by 10.100.31.8 with HTTP; Thu, 23 Dec 2010 06:02:15 -0800 (PST)
Date: Thu, 23 Dec 2010 14:02:15 +0000
Message-ID:
From: Phillip Hallam-Baker
To: [email-masked]
Content-Type: multipart/alternative; boundary=0016e6407e8033c6680498145179
Subject: [keyassure] Efficient Mega-Queries
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 23 Dec 2010 14:00:19 -0000

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

One of the points Adam Langley keeps bringing up is his desire to perform
all lookups in as few round trips as possible. After thinking about the
problem, I now have a scheme that allows a complete extended discovery query
to be performed with only 1 DNS round trip occurring in the critical path.

While I am presenting this in terms of my own Extended Service Discovery
Scheme, the same approach could be applied to other schemes. So think of
this as a demonstration of an approach rather than an insistence on a
particular scheme.

In the current version of ESRV, we may require up to 3 round trips and 6
different RRSIGs to complete resolution:

ESRV ("www.example.com", "_http._tcp")

(1)
www.example.com ? RR-A
www.example.com CNAME example.com
www.example.com RRSIG (CNAME)
example.com RR-A disc srv
example.com RRSIG (RR-A)

(2)
_http._tcp.example.com ? RR-B
_http._tcp.example.com RR-B tls "required"
_http._tcp.example.com RRSIG (RR-B)
_http._tcp.example.com ? SRV
_http._tcp.example.com SRV 1 1 443 host1.example.com
_http._tcp.example.com SRV 1 1 443 host2.example.com
_http._tcp.example.com RRSIG (SRV)

(3)
_http._tcp.host1.example.com ? RR-B
_http._tcp.host1.example.com RR-B eekey ......
_http._tcp.host1.example.com RRSIG (RR-B)
_http._tcp.host1.example.com ? A
_http._tcp.host1.example.com A 10.1.1.2
_http._tcp.host1.example.com RRSIG (A)

Using RSA 2048 the 6 RRSIG records alone add up to 1.5 Kb

But the actual data is considerably more modest. It is 7 RRs with typically
32 bytes of data. Only one of them is substantial - 80 bytes for the SHA-256
digest of the end entity key.

So we can fit all the data for the typical extended discovery case in about
300 bytes or so. The problem is the signatures.

Now imagine that we separate out delivery of the signature from delivery of
the data. So the DNS server will respond to a mega-query with the extended
discovery data and as many RRSIGs as it can fit, but no problem if they
don't all fit.

The client can start acting on the extended discovery data as soon as it is
available and start queries for the next round in parallel. Starting the
TCP/IP connection will itself take several round trips. So we should have
all the necessary information returned from DNS before we begin the TLS
connection initiation.

But in the worst case, we don't need to worry about the security of the
potential connection until we have reached the point where we start sending
data down it. If we discover that there is a problem we can (and SHOULD)
abort.

So the critical path of our connection establishment process now looks like

SEQUENTIAL
PARALLEL
DNS ! A (www.example.com)
DNS ! ESRV-MEGA (www.example.com, _http._tcp)
PARALLEL
DNS ? A
DNS ? ESRV-MEGA
PARALLEL
SEQUENTIAL
... build TCP socket according to indicated policy ...
SEQUENTIAL
PARALLEL
SEQUENTIAL
DNS ! ESRV (example.com)
DNS ? ESRV (example.com)
SEQUENTIAL
DNS ! SRV (_http._tcp.example.com)
...
... other DNS queries
... check signatures
IF
... policy or signature violation detected ...
... abort connection ...

Performance wise we have two cases of interest:

1) Server does not use extended discovery
In this case we have to wait for a response to two DNS queries to
arrive instead of just one. But these queries are taking place in parallel.

2) Server uses the most extended discovery possible and supports mega-query
In this case the public key operations take place in parallel with the
communications. Even if we are performing full end-client validation there
should be negligible impact on performance.

In either case there is only one DNS round trip in the critical path and
only 2 DNS round trips in total.

The other cases of interest are:

3) Server uses extended discovery but their DNS does not support mega-query.
Well, they don't seem to care about performance, it should not be an
overriding concern for the client.

4) Server uses extended discovery but tunes response so that time sensitive
cases can be delat with in a single request-response.

5) Resolver strips out the unsigned responses
At present the precise behavior of validating resolvers is not fully
defined. But a MegaQuery response can still return all the information that
the client requires to begin a TCP/IP connection including necessary
signatures (CNAME, SRV, A) and the remaining information can be acquired in
a single additional round trip.

Notes:

1) I left out IPv6 lookup from these examples on purpose. This is because
Extended discovery is a very big hammer that can be used to make the IPv6
transition work a lot better. Rather than blindly querying for A and AAAA
records, I would let the service direct which was appropriate. So if someone
is behind a NAT for IPv4 but has direct access for IPv6, they can
preferentially request IPv6 access.

2) I use SRV as an example of the discovery mechanism, but we can go beyond
that approach and use geo-location sensitive discovery and other
optimization techniques.

Conclusion:

Extended discovery mechanisms can be implemented in ways that offer
equivalent performance to existing methods.

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

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

One of the points Adam Langley keeps bringing up is his desire to perform a=
ll lookups in as few round trips as possible. After thinking about the prob=
lem, I now have a scheme that allows a complete extended discovery query to=
be performed with only 1 DNS round trip occurring in the critical path.

While I am presenting this in terms of my own Extended Servi=
ce Discovery Scheme, the same approach could be applied to other schemes. S=
o think of this as a demonstration of an approach rather than an insistence=
on a particular scheme.

In the current version of ESRV, we may r=
equire up to 3 round trips and 6 different RRSIGs to complete resolution:

ESRV ("www.=
example.com", "_http._tcp")

(1)

www.ex=
ample.com ? RR-A=A0

=A0=A0 =A0www.example.com CNAME example=
.com

=A0=A0 =A0www.example.com RRSIG=
(CNAME)

=A0=A0 =A0example.=
com RR-A disc srv

=A0=A0 =A0example.com RRSIG (RR-A)<=
/font>

(2)

_http._tcp.example.com ? RR-B

=A0=A0 =A0_http._tcp.example.com RR-B tls "required"

=A0=A0 =A0_http._tcp.example.com=A0RRSIG (RR-B)

tcp.example.com ? SRV

=
=A0=A0 =A0_http._tcp.example.com SRV=
1 1 443 host1.example.com<=
/div>

=
=A0=A0 =A0_http._tcp.example.com SRV=
1 1 443 host2.example.com<=
/div>

=
=A0=A0 =A0_http._=
tcp.example.com=A0RRSIG (SRV)

(3)

_http._tcp.host1.example.com ? RR-B
<=
div>
=
=A0=A0 =A0_http._tcp.host1.example=
.com RR-B eekey ......=A0=A0 =A0
=A0=A0 =A0_http._tcp.host1.example.com RRSIG (RR-B)

_http._tcp.host1.example.com ? A

=
=A0=A0 =A0_http._tcp.host1.example=
.com A 10.1.1.2

=A0=A0 =A0_http._tcp.host1.example.com RRSIG (A)

Using RSA 2048 the 6 RRSIG records alone add up to 1.5 Kb
<=
div>

But the actual data is considerably more modest. It is 7=
RRs with typically 32 bytes of data. Only one of them is substantial - 80 =
bytes for the SHA-256 digest of the end entity key.

So we can fit all the data for the typical extended dis=
covery case in about 300 bytes or so. The problem is the signatures.
<=
div>

Now imagine that we separate out delivery=
of the signature from delivery of the data. So the DNS server will respond=
to a mega-query with the extended discovery data and as many RRSIGs as it =
can fit, but no problem if they don't all fit.

The client can start acting on the extended discovery d=
ata as soon as it is available and start queries for the next round in para=
llel. Starting the TCP/IP connection will itself take several round trips. =
So we should have all the necessary information returned from DNS before we=
begin the TLS connection initiation.

But in the worst case, we don't need to worry about=
the security of the potential connection until we have reached the point w=
here we start sending data down it. If we discover that there is a problem =
we can (and SHOULD) abort.

So the critical path of our connection e=
stablishment process now looks like

SEQUENTIAL

=A0=A0 PARALLEL

=A0=A0 =A0 =A0DNS ! A (www.example.com)

=A0=A0 =A0 =A0DNS ! ESRV-MEGA (www.=
example.com, _http._tcp)

=A0=A0 PARALLEL

=A0=A0 =A0 =A0DNS ? A

=A0=A0 =A0 =A0DNS ? ESRV-MEGA

=A0=A0 PARALLEL

=A0=A0 =A0 =A0SEQUENTIAL

=A0=A0 =A0 =A0 =A0 ... build=
TCP socket according to indicated policy ...

=A0=A0 =A0 =A0SEQUENTIAL

=A0=A0 =A0 =A0 =A0 PARALLEL<=
/font>

=A0=A0 =A0 =A0 =A0 =A0 =A0SEQUENTIAL

=A0=A0 =A0 =A0=A0=A0 =
=A0 =A0 =A0 DNS ! ESRV (example.com)

=A0=A0 =A0 =A0=A0=A0 =A0 =A0=A0=A0 DNS ?=A0ESRV (example.com)

=A0=A0 =A0 =A0=A0=A0 =A0 =A0=A0=A0 DNS ! SRV (_http._tcp.exampl=
e.com)

=A0=A0=
=A0 =A0 =A0=A0 =A0 =A0 =A0 ...

=A0=A0 =A0 =A0 =A0 =A0 =A0... other DNS querie=
s

=A0=A0 =A0 =A0 =A0 ... check signatures

=A0=A0 =A0IF

=A0=A0 =A0 =A0 ... policy or signature v=
iolation detected ...

=A0=A0 =A0 =A0 =A0 =A0... abort connection ...

Performance wise we have two cases of interest:

1)=
Server does not use extended discovery

=A0=A0 =A0 In this case w=
e have to wait for a response to two DNS queries to arrive instead of just =
one. But these queries are taking place in parallel.

2) Server uses the most extended discovery possible and=
supports mega-query

=A0=A0 =A0In this case the public key operat=
ions take place in parallel with the communications. Even if we are perform=
ing full end-client validation there should be negligible impact on perform=
ance.

In either case there is only one DNS round trip in the =
critical path and only 2 DNS round trips in total.

The other cases of interest are:

3) Server uses extended discovery but their DNS does not support mega-query=
.

=A0=A0 =A0Well, they don't seem to care about performance, =
it should not be an overriding concern for the client.

=

4) Server uses extended discovery but tunes response so that time sensitive=
cases can be delat with in a single request-response.

=

5) Resolver strips out the unsigned responses

=A0=A0 =A0At p=
resent the precise behavior of validating resolvers is not fully defined. B=
ut a MegaQuery response can still return all the information that the clien=
t requires to begin a TCP/IP connection including necessary signatures (CNA=
ME, SRV, A) and the remaining information can be acquired in a single addit=
ional round trip.

Notes:

1) I lef=
t out IPv6 lookup from these examples on purpose. This is because Extended =
discovery is a very big hammer that can be used to make the IPv6 transition=
work a lot better. Rather than blindly querying for A and AAAA records, I =
would let the service direct which was appropriate. So if someone is behind=
a NAT for IPv4 but has direct access for IPv6, they can preferentially req=
uest IPv6 access.

2) I use SRV as an example of the discovery mechanism, =
but we can go beyond that approach and use geo-location sensitive discovery=
and other optimization techniques.

Conclusion:

Extended discovery mechanisms can=
be implemented in ways that offer equivalent performance to existing metho=
ds.

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

--0016e6407e8033c6680498145179--

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50B703A6AF7 for ; Thu, 23 Dec 2010 02:18:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.89
X-Spam-Level:
X-Spam-Status: No, score=-2.89 tagged_above=-999 required=5 tests=[AWL=-0.292, 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 VbyOK2lag4Kf for ; Thu, 23 Dec 2010 02:18:16 -0800 (PST)
Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id 060843A6805 for ; Thu, 23 Dec 2010 02:18:15 -0800 (PST)
Received: by yie19 with SMTP id 19so1001033yie.31 for ; Thu, 23 Dec 2010 02:20:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=YF/tpMINWU6YADFZoOvCJQuGM+71RZZhyWESMNenXWI=; b=V4Kv9aHPW1vcbEOzNzoy08ySQsoCWre3llq3/keqJ9c3D2dUBW4kM9kC5MIN/pa4tx +lA9HWNh20vu/+Z7uUbN+4BVIq2m6UYlcK5LKX0HGYZsyEwDeQCTZmJkfWRhKGyT3DdX SVmN+aoLW8uj372WtfkoTF3OrYo7i0XgiQwiI=
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=nw+YBs2jnuVYrOdBoloQ7EdoJyg3f0qHT+psWo5lYR0Z6ZGdmXH1ElgkpzFadcZCkI fXoGISy4kQ2cxbYdoxq00oQtcnJYMYTeBko/9XDf6O3K/S0bvpBpAsTQYAW7PuT0QGwo GNh+wIasJRTv4eed8188QA7C4Aao8CDzjJ6WM=
MIME-Version: 1.0
Received: by 10.100.93.11 with SMTP id q11mr3287140anb.35.1293099615845; Thu, 23 Dec 2010 02:20:15 -0800 (PST)
Received: by 10.100.31.8 with HTTP; Thu, 23 Dec 2010 02:20:15 -0800 (PST)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Date: Thu, 23 Dec 2010 10:20:15 +0000
Message-ID:
From: Phillip Hallam-Baker
To: Ilari Liusvaara
Content-Type: multipart/alternative; boundary=0016e642d3884304740498113712
Cc: "[email-masked]" , Paul Hoffman
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 23 Dec 2010 10:18:17 -0000

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

On Wed, Dec 22, 2010 at 11:54 PM, Ilari Liusvaara <
[email-masked]> wrote:

> On Wed, Dec 22, 2010 at 09:39:51PM +0000, Phillip Hallam-Baker wrote:
> > I look at the problem differently.
> >
> > The server site is merely describing its local security policy to whoever
> > might want to connect. So it is making statements such as
> >
> > "TLS is always offered"
> > "TLS must be used"
> > "IPSEC must be used"
> > "A path for the cert can be formed from CA cert X"
> > "The key is Y"
> >
> > These are all merely descriptive of the server security policy. IOf
> clients
> > want to connect, they can make their own choices.
>
> I don't consider the first and last two as not policy but as facts. The
> other
> two are policy
>

Well they are certainly objective statements of fact about the server
security policy.

Which is the point. Security policy can be a very nebulous concept. But if
we stick to objective statements of fact we can avoid getting stuck.

Why do you think the last two are not factual? Could we express them in a
fashion that you consider to be objective?

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

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

On Wed, Dec 22, 2010 at 11:54 PM, Ilari =
Liusvaara <[email-masked]> wrote:

On Wed, Dec 22, 2010 at 09:39:51PM +0000, Phillip Hallam-=
Baker wrote:

> I look at the problem differently.

>

> The server site is merely describing its local security policy to whoe=
ver

> might want to connect. So it is making statements such as

>

> "TLS is always offered"

> "TLS must be used"

> "IPSEC must be used"

> "A path for the cert can be formed from CA cert X"

> "The key is Y"

>

> These are all merely descriptive of the server security policy. IOf cl=
ients

> want to connect, they can make their own choices.

I don't consider the first and last two as not policy but as fact=
s. The other

two are policy

Well they are certainly =
objective statements of fact about the server security policy.

Which is the point. Security policy can be a very nebulous con=
cept. But if we stick to objective statements of fact we can avoid getting =
stuck.

Why do you think the last two are not fa=
ctual? Could we express them in a fashion that you consider to be objective=
?

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

--0016e642d3884304740498113712--

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 458B93A6AF6 for ; Thu, 23 Dec 2010 02:12:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.388
X-Spam-Level:
X-Spam-Status: No, score=-3.388 tagged_above=-999 required=5 tests=[AWL=0.210, 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 EMohTk47UmSF for ; Thu, 23 Dec 2010 02:12:05 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id C43633A69BC for ; Thu, 23 Dec 2010 02:12:04 -0800 (PST)
Received: by ywk9 with SMTP id 9so2824235ywk.31 for ; Thu, 23 Dec 2010 02:14:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=QceyyrpYh92PyQLZyJZHo5ltEuOgqsTHn2MtN/7BwtM=; b=uYW7OjCZEPYzlBZZLknkEe1wxl6iHULtprytKWtK8eukuVlaG7MSpUjbRA/YJwVt/F e9XBMRLZqMFrzzXmDAErjdKEdnHGwSzXT8oMtNYQ9Caf3Tg5YYtVDzHQs3RwurT6tmG9 2g9DFucQz2Ml0AxuCRdyYdv+lhZ18XrDwryFE=
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=XkititZDLkipOd+TTrwZXBdRO7QYQpT2CJvg/97zFOx88wFxs/ZzToVcihNXqQpHSM QO8r4IZbOpg7uVHDEQjoExPWmQGVc4l7Zt8t3uAmLRe6/1Pq8JOC4R1r+ZQblIjK2DOM rU7aicAtljActjhOKGBIMw5fHnmTx3smr6SFM=
MIME-Version: 1.0
Received: by 10.100.57.11 with SMTP id f11mr1629405ana.205.1293099244284; Thu, 23 Dec 2010 02:14:04 -0800 (PST)
Received: by 10.100.31.8 with HTTP; Thu, 23 Dec 2010 02:14:04 -0800 (PST)
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]>
Date: Thu, 23 Dec 2010 10:14:04 +0000
Message-ID:
From: Phillip Hallam-Baker
To: Paul Hoffman
Content-Type: multipart/alternative; boundary=0016e644c7041d6d390498112133
Cc: [email-masked]
Subject: Re: [keyassure] TLSA and HASTLS
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 23 Dec 2010 10:12:06 -0000

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

On Wed, Dec 22, 2010 at 11:45 PM, Paul Hoffman wrote:

> At 11:30 PM +0000 12/22/10, Phillip Hallam-Baker wrote:
> >No, what you actually said was
> >
> >"TLSA *is* just about TLS currently, as was requested by the pre-WG. If
> you want to change that, that is a completely separate thread."
> >
> >
> >The terms 'requested' and 'change' imply a status quo.
>
> Correct.
>
> >We do not have a status quo for the simple reason that you stepped in to
> suppress discussions that might have led to one being formed by saying that
> they should take place after the WG was formed.
>
> Phill, given that you have been a WG chair, you must know that what you are
> saying is poppycock. A WG starts somewhere. Even your WG did, as the
> archives clearly show.
>

Please try to keep your language under control. And its a good idea to
understand what a word actually means before you use it. 'Poppycock' means
soft feces.

A working group does start somewhere. But as you admit, this point was
raised earlier and at your personal insistence deferred to a later time.

When others agreed to defer the discussion it was on the implicit
understanding that no decision had been taken, not as you are now attempting
to claim that your personal preference had been adopted as WG policy in the
interim.

You keep taking great exception when people allegedly put words into your
mouth but have no compunction about speaking for the whole Working Group to
put words in our mouths.

And as for being a WG chair, I note that on several occasions in this thread
you have either stated or implied that your way is the consensus and that if
others don't like that choice they can form their own group. I regard that
approach to be an attempt to bully people into agreeing with you. Which is
not something I would have tolerated as a WG chair.

I suggest that from now on we argue technical issues strictly on the merits
and that you stop trying to suppress discussion by first claiming that it is
too early to raise an issue and afterwards that it is now too late.

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

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

On Wed, Dec 22, 2010 at 11:45 PM, Paul H=
offman <paul.=
[email-masked]> wrote:

At 11:30 PM +0000 12/22/10, Phillip Hallam-Baker wrote:
>No, what you actually said was

>

>"TLSA *is* just about TLS currently, as was requested by the pre-W=
G. If you want to change that, that is a completely separate thread."<=
br>
>

>

>The terms 'requested' and 'change' imply a status quo.<=
br>

Correct.

>We do not have a status quo for the simple reason that you stepped in t=
o suppress discussions that might have led to one being formed by saying th=
at they should take place after the WG was formed.

Phill, given that you have been a WG chair, you must know that what y=
ou are saying is poppycock. A WG starts somewhere. Even your WG did, as the=
archives clearly show.

Please try to k=
eep your language under control. And its a good idea to understand what a w=
ord actually means before you use it. 'Poppycock' means soft feces.=

A working group does start somewhere. Bu=
t as you admit, this point was raised earlier and at your personal insisten=
ce deferred to a later time.

When others agreed to=
defer the discussion it was on the implicit understanding that no decision=
had been taken, not as you are now attempting to claim that your personal =
preference had been adopted as WG policy in the interim.=A0

You keep taking great exception when people allegedly p=
ut words into your mouth but have no compunction about speaking for the who=
le Working Group to put words in our mouths.

And as for being a WG chair, I note that on several occasions in=
this thread you have either stated or implied that your way is the consens=
us and that if others don't like that choice they can form their own gr=
oup. I regard that approach to be an attempt to bully people into agreeing =
with you. Which is not something I would have tolerated as a WG chair.

I suggest that from now on we argue tech=
nical issues strictly on the merits and that you stop trying to suppress di=
scussion by first claiming that it is too early to raise an issue and after=
wards that it is now too late.=A0

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

--0016e644c7041d6d390498112133--

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 129ED3A6AA6 for ; Wed, 22 Dec 2010 17:05:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.071
X-Spam-Level:
X-Spam-Status: No, score=-103.071 tagged_above=-999 required=5 tests=[AWL=1.194, BAYES_00=-2.599, GB_I_INVITATION=-2, IP_NOT_FRIENDLY=0.334, 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 poVb18aHgct5 for ; Wed, 22 Dec 2010 17:05:51 -0800 (PST)
Received: from oproxy2-pub.bluehost.com (oproxy2-pub.bluehost.com [67.222.39.60]) by core3.amsl.com (Postfix) with SMTP id 177143A6A67 for ; Wed, 22 Dec 2010 17:05:51 -0800 (PST)
Received: (qmail 2336 invoked by uid 0); 23 Dec 2010 01:07:50 -0000
Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy2.bluehost.com with SMTP; 23 Dec 2010 01:07:50 -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:CC:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=NrgbcWgHtqb045HbWts5OdYID8cvq38vIIG9gkqtX1zXyRzC8e4UWFcz2PPxU0PW5zV7nDy2rEjqsUaeH7+IqmtbHz9AGRS9F7sKlS0XpNmrj/4cEIuXoxmo2huOL4Ka;
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 ) id 1PVZeo-0008CU-4a; Wed, 22 Dec 2010 18:07:50 -0700
Message-ID: <[email-masked]>
Date: Wed, 22 Dec 2010 17:07:48 -0800
From: =JeffH
User-Agent: Thunderbird 2.0.0.24 (X11/20101027)
MIME-Version: 1.0
To: Phillip Hallam-Baker
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}
Cc: IETF DANE WG list
Subject: Re: [keyassure] TLSA and HASTLS
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 23 Dec 2010 01:05:52 -0000

At 8:58 AM -0500 12/21/10, James Cloos wrote:
> A bare public key is generally useful, and DANE shouldn't be just about TLS.

PaulH had said..
>
> TLSA *is* just about TLS currently, as was requested by the pre-WG. If you
> want to change that, that is a completely separate thread.

Phillip Hallam-Baker observed..
>
> Well since you appeared to be telling someone 'this has already been
> decided, shut up and go away'

FWIW, I didn't read what PaulH said as that, but rather as an invitation to
start a discussion WRT JamesC's above observation/request/suggestion in a
separate thread, that's all.

=JeffH

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5F963A691A for ; Wed, 22 Dec 2010 15:52:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.465
X-Spam-Level:
X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.134, 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 gN9xaoq7ObNt for ; Wed, 22 Dec 2010 15:52:35 -0800 (PST)
Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) by core3.amsl.com (Postfix) with ESMTP id B76AD3A68FB for ; Wed, 22 Dec 2010 15:52:34 -0800 (PST)
Received: from saunalahti-vams (vs3-12.mail.saunalahti.fi [62.142.5.96]) by emh04-2.mail.saunalahti.fi (Postfix) with SMTP id 293F513C651; Thu, 23 Dec 2010 01:54:32 +0200 (EET)
Received: from emh04.mail.saunalahti.fi ([62.142.5.110]) by vs3-12.mail.saunalahti.fi ([62.142.5.96]) with SMTP (gateway) id A004E20D994; Thu, 23 Dec 2010 01:54:32 +0200
Received: from LK-Perkele-VI (a88-112-56-215.elisa-laajakaista.fi [88.112.56.215]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id 9D90B41BE4; Thu, 23 Dec 2010 01:54:28 +0200 (EET)
Date: Thu, 23 Dec 2010 01:54:44 +0200
From: Ilari Liusvaara
To: Phillip Hallam-Baker
Message-ID: <[email-masked]>
References: <[email-masked]> <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To:
User-Agent: Mutt/1.5.20 (2009-06-14)
Sender: Ilari Liusvaara
X-Antivirus: VAMS
Cc: "[email-masked]" , Paul Hoffman
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 22 Dec 2010 23:52:35 -0000

On Wed, Dec 22, 2010 at 09:39:51PM +0000, Phillip Hallam-Baker wrote:
> I look at the problem differently.
>
> The server site is merely describing its local security policy to whoever
> might want to connect. So it is making statements such as
>
> "TLS is always offered"
> "TLS must be used"
> "IPSEC must be used"
> "A path for the cert can be formed from CA cert X"
> "The key is Y"
>
> These are all merely descriptive of the server security policy. IOf clients
> want to connect, they can make their own choices.

I don't consider the first and last two as not policy but as facts. The other
two are policy.

I consider statements about behaviour of genuine server(s) and domain as whole
as facts. These include if it offers (START)TLS or not, what keys it uses, what
CAs (if any) those certificates chain to, etc... Those three statements all
directly map to properties of the host.

"TLS/IPSEC must be used" don't directly map to any property of the server nor
the domain.

> Server policies such as 'must use TLS' are going to be very hard to
> implement outside of closed environments. The NSA and banks can use that
> policy internally. It would be rather difficult for most sites to do so.

That's because they are policy.

-Ilari

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43AA43A6B9B for ; Wed, 22 Dec 2010 15:43:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.63
X-Spam-Level:
X-Spam-Status: No, score=-101.63 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 hCRNnPyfrj9g for ; Wed, 22 Dec 2010 15:43:57 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 694113A6BA5 for ; Wed, 22 Dec 2010 15:43:26 -0800 (PST)
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 oBMNjNcQ094787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Dec 2010 16:45:24 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]>
Date: Wed, 22 Dec 2010 15:45:21 -0800
To: Phillip Hallam-Baker
From: Paul Hoffman
Content-Type: text/plain; charset="us-ascii"
Cc: [email-masked]
Subject: Re: [keyassure] TLSA and HASTLS
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 22 Dec 2010 23:43:58 -0000

At 11:30 PM +0000 12/22/10, Phillip Hallam-Baker wrote:
>No, what you actually said was
>
>"TLSA *is* just about TLS currently, as was requested by the pre-WG. If you want to change that, that is a completely separate thread."
>
>
>The terms 'requested' and 'change' imply a status quo.

Correct.

>We do not have a status quo for the simple reason that you stepped in to suppress discussions that might have led to one being formed by saying that they should take place after the WG was formed.

Phill, given that you have been a WG chair, you must know that what you are saying is poppycock. A WG starts somewhere. Even your WG did, as the archives clearly show.

In this case, it starts with the document authors guessing on what would be accepted by the WG and asking for people to have a discussion. If Jakob and I guessed wrong, we'll be corrected by the WG.

>If people wondered why I took exception to earlier attempts to defer other discussions, they will now see the explanation.

Where?

--Paul Hoffman, Director
--VPN Consortium

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65EF33A6A92 for ; Wed, 22 Dec 2010 15:28:16 -0800 (PST)
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.212, 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 hRmhjCNx7keW for ; Wed, 22 Dec 2010 15:28:15 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 22CAB3A68F7 for ; Wed, 22 Dec 2010 15:28:14 -0800 (PST)
Received: by gxk28 with SMTP id 28so3018445gxk.31 for ; Wed, 22 Dec 2010 15:30:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=j4YfrKfSCKw+hGU/6ozQRltHWIZxMvBFNOaLIgGm+rA=; b=Mcng/kHO2RYvbvS7p9SbCux/pXDvJTLXDpg+fnnlM5Cg5Dbs8+I0P3PAkDx2C6EHVh hejBxbIyebG3xlqON6y3ykpKTUuY/vKmellrbM4a/32/YrvXCghss6vhHrdpyZ5acoPW ygpbai8wR6iSwgAkdDiKhRPNnfkgXH+HRGiDw=
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=q5VP96jLVceHfQNJn/Ec9CgVtmRGiS/UqhiRe67wP0fZrr0XV0ZEGakX5O4tmMcTAJ iGRfcDhzDezRsj4Q++j0mhP5C4s8Z/a3TNWCr259Ruk1mF3k2ODy2Pk04PRZGvVjByGW Y4hDmbhizp9XN6V2AJ9m5ruE1G3znM2qIxM9Y=
MIME-Version: 1.0
Received: by 10.100.57.11 with SMTP id f11mr1339533ana.205.1293060613846; Wed, 22 Dec 2010 15:30:13 -0800 (PST)
Received: by 10.100.31.8 with HTTP; Wed, 22 Dec 2010 15:30:13 -0800 (PST)
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]>
Date: Wed, 22 Dec 2010 23:30:13 +0000
Message-ID:
From: Phillip Hallam-Baker
To: Paul Hoffman
Content-Type: multipart/alternative; boundary=0016e644c7048fb7a30498082200
Cc: [email-masked]
Subject: Re: [keyassure] TLSA and HASTLS
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 22 Dec 2010 23:28:16 -0000

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

No, what you actually said was

"TLSA *is* just about TLS currently, as was requested by the pre-WG. If you
want to change that, that is a completely separate thread."

The terms 'requested' and 'change' imply a status quo.

We do not have a status quo for the simple reason that you stepped in to
suppress discussions that might have led to one being formed by saying that
they should take place after the WG was formed.

If people wondered why I took exception to earlier attempts to defer other
discussions, they will now see the explanation.

On Wed, Dec 22, 2010 at 11:16 PM, Paul Hoffman wrote:

> At 10:26 PM +0000 12/22/10, Phillip Hallam-Baker wrote:
> >Well since you appeared to be telling someone 'this has already been
> decided, shut up and go away', the fact that earlier you were telling people
> that this would be discussed later is rather relevant.
>
> I explicitly said "If you want to change that, that is a completely
> separate thread." What part of the word "If" did you not understand?
>
> >Since you clearly had no intention of implying that this issue had already
> been decided, we can now have the discussion we agreed earlier to postpone,
> having made no decision or commitment whatsoever.
>
> Correct.
>
> --Paul Hoffman, Director
> --VPN Consortium
>

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

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

No, what you actually said was

"TLSA *is* just abo=
ut TLS currently, as was requested by the pre-WG. If you want to change tha=
t, that is a completely separate thread."

The terms 'requested' and 'change' i=
mply a status quo.=A0

We do not have a status quo for the simple =
reason that you stepped in to suppress discussions that might have led to o=
ne being formed by saying that they should take place after the WG was form=
ed.

If people wondered why I took exception to =
earlier attempts to defer other discussions, they will now see the explanat=
ion.

On Wed, Dec 22, 201=
0 at 11:16 PM, Paul Hoffman <[email-masked]> wrote:

At 10:26 PM +0000 12/22/10, Phillip Hallam-Baker wrote:
>Well since you appeared to be telling someone 'this has already bee=
n decided, shut up and go away', the fact that earlier you were telling=
people that this would be discussed later is rather relevant.

I explicitly said "If you want to change that, that is a complet=
ely separate thread." What part of the word "If" did you not=
understand?

>Since you clearly had no intention of implying that this issue had alre=
ady been decided, we can now have the discussion we agreed earlier to postp=
one, having made no decision or commitment whatsoever.

Correct.

--Paul Hoffman, Director

--VPN Consortium

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

--0016e644c7048fb7a30498082200--

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C1923A68C7 for ; Wed, 22 Dec 2010 15:16:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.621
X-Spam-Level:
X-Spam-Status: No, score=-101.621 tagged_above=-999 required=5 tests=[AWL=0.425, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 8fJCyI4a1kPV for ; Wed, 22 Dec 2010 15:16:26 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 898F23A687A for ; Wed, 22 Dec 2010 15:16:26 -0800 (PST)
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 oBMNGPKT094064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Dec 2010 16:16:26 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]>
Date: Wed, 22 Dec 2010 15:16:23 -0800
To: Phillip Hallam-Baker
From: Paul Hoffman
Content-Type: text/plain; charset="us-ascii"
Cc: [email-masked]
Subject: Re: [keyassure] TLSA and HASTLS
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 22 Dec 2010 23:16:27 -0000

At 10:26 PM +0000 12/22/10, Phillip Hallam-Baker wrote:
>Well since you appeared to be telling someone 'this has already been decided, shut up and go away', the fact that earlier you were telling people that this would be discussed later is rather relevant.

I explicitly said "If you want to change that, that is a completely separate thread." What part of the word "If" did you not understand?

>Since you clearly had no intention of implying that this issue had already been decided, we can now have the discussion we agreed earlier to postpone, having made no decision or commitment whatsoever.

Correct.

--Paul Hoffman, Director
--VPN Consortium

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 084353A68C1 for ; Wed, 22 Dec 2010 15:03:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.384
X-Spam-Level:
X-Spam-Status: No, score=-3.384 tagged_above=-999 required=5 tests=[AWL=0.214, 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 kW17TzX9v19E for ; Wed, 22 Dec 2010 15:03:11 -0800 (PST)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 99E1F3A68BE for ; Wed, 22 Dec 2010 15:03:11 -0800 (PST)
Received: by yxt33 with SMTP id 33so2632677yxt.31 for ; Wed, 22 Dec 2010 15:05:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=UhXDcV0mRKMiGKgaRUVgeAUOhYIlzfvqaM2ITwvKjHc=; b=ZdeEO1Hf0hI/2sDHbHOsIcBsdlDPzhV3QpxYOTapiAHP8cuWOapkd7KlfBXiD+dwnZ TcwxwNaVxMju/JEE8m4LEfKOMVt7waeUnlEHk/v1h9DsWkJJLBnwlm01hqxoTxzXAyzH EB1hGKgpiIvjSEdylaTuaI+HQfUFmkZN/xWsY=
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=m4sQYzXRMD6Y8FjEQpFIprPPD+w5UtS9TAlp6YWDFFvN/PHFIvm/Xvh+pXlLGRa/kd l9mQ3kkx7HPyFN3hkk15TU9QK/eciY0aecbWaBToCbllTHs6lA5iT0GaELOF0CJ0H1KS Y+puWtvWP2ReqG6Wi9kfp0JBl5+NLW4N+pPiA=
MIME-Version: 1.0
Received: by 10.100.57.11 with SMTP id f11mr1326948ana.205.1293059110434; Wed, 22 Dec 2010 15:05:10 -0800 (PST)
Received: by 10.100.31.8 with HTTP; Wed, 22 Dec 2010 15:05:10 -0800 (PST)
In-Reply-To: <[email-masked]>
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Wed, 22 Dec 2010 23:05:10 +0000
Message-ID:
From: Phillip Hallam-Baker
To: "Steingruebl, Andy"
Content-Type: multipart/alternative; boundary=0016e644c704f37633049807c859
Cc: "[email-masked]" , Paul Hoffman
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 22 Dec 2010 23:03:13 -0000

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

The part that worries me is attempting to define the semantics of the
security policy statement in terms of the client behavior.

Thinking in terms of the desired endpoint behavior is easy for people, but
rather hard for machines. If this scheme is going to be manageable on a
large scale, we need to be able to automate the generation of the security
policy information. That is going to be easiest if the security policy maps
directly to the server state rather than some desired client state.

Now clearly, if client is reading the security policy it MUST NOT attempt or
accept a connection that is incompatible with that stated policy and SHOULD
always attempt to make the strongest connection possible that is compatible
within the intersection of their security policies.

But working in terms of the client behavior is unhelpful because a sensible
client is always going to ensure the connection is secure.

For example, consider the following servers:

Server A: Requires use of TLS

Server B: Always offers TLS

Off hand I can't think of a reason why an endpoint client I wrote would
differentiate between those two cases. I am going to always attempt to
connect using TLS and never bother with trying the http connection.

There is an important difference: Attempting to connect to Server A enclair
can only be the result of either a mis-stated security policy or a downgrade
attack.

On Wed, Dec 22, 2010 at 9:59 PM, Steingruebl, Andy <
[email-masked]> wrote:

> > From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Phillip Hallam-Baker
>
>
> > These are all merely descriptive of the server security policy. IOf
> clients want to connect, they can make their own choices.
>
> They can, of course. We can't "enforce" it on them, as we don't directly
> control their code. But, what we can control is whether this is a "MAY" or
> a "MUST" requirement in the spec. In my mind it's a MUST, not a MAY/SHOULD.
> We don't want fuzziness here, as we're trying to protect against known
> attacks and we want uniformity of implementation. My sense from the major
> browser vendors - who really are the major target for this spec anyway from
> the client side - is that they'd want MUST also, and uniformity.
>
> I also think it should be explicit, not implicit in publishing keys in DNS.
> I would deploy it today if I could, totally absent a fully specified
> keys-in-dns spec from this group.
>
> - Andy
>

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

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

The part that worries me is attempting to define the semantics of the secur=
ity policy statement in terms of the client behavior.

Thinking in terms of the desired =
endpoint behavior is easy for people, but rather hard for machines. If this=
scheme is going to be manageable on a large scale, we need to be able to a=
utomate the generation of the security policy information. That is going to=
be easiest if the security policy maps directly to the server state rather=
than some desired client state.

Now clearly, if client is reading =
the security policy it MUST NOT attempt or accept a connection that is inco=
mpatible with that stated policy and SHOULD always attempt to make the stro=
ngest connection possible that is compatible within the intersection of the=
ir security policies.

But working in terms of the client behavior is unhelpfu=
l because a sensible client is always going to ensure the connection is sec=
ure.

For example, consider the following servers:<=
/div>

Server A: Requires use of TLS

=
Server B: Always offers TLS

Off hand I can't t=
hink of a reason why an endpoint client I wrote would differentiate between=
those two cases. I am going to always attempt to connect using TLS and nev=
er bother with trying the http connection.

There is an important difference: Attempting to connect=
to Server A enclair can only be the result of either a mis-stated security=
policy or a downgrade attack.=A0

On Wed, Dec 22, 2010 at 9:59 PM, =
Steingruebl, Andy <[email-masked]> wrote:

> From: keyassure-bounces@=
ietf.org [mailto:keyassur=
[email-masked]] On Behalf Of Phillip Hallam-Baker

> These are all merely descriptive of the server security policy. IOf cl=
ients want to connect, they can make their own choices.

They can, of course. =A0We can't "enforce" it on them, =
as we don't directly control their code. =A0But, what we can control is=
whether this is a =A0"MAY" or a "MUST" requirement in =
the spec. =A0In my mind it's a MUST, not a MAY/SHOULD. =A0We don't =
want fuzziness here, as we're trying to protect against known attacks a=
nd we want uniformity of implementation. =A0My sense from the major browser=
vendors - who really are the major target for this spec anyway from the cl=
ient side - is that they'd want MUST also, and uniformity.

I also think it should be explicit, not implicit in publishing keys in DNS.=
I would deploy it today if I could, totally absent a fully specified keys-=
in-dns spec from this group.

- Andy

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

--0016e644c704f37633049807c859--

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88AAC3A6B8B for ; Wed, 22 Dec 2010 14:27:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.321
X-Spam-Level:
X-Spam-Status: No, score=-101.321 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_64=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 ARj7dnH7+dqP for ; Wed, 22 Dec 2010 14:27:40 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 0388E3A6B75 for ; Wed, 22 Dec 2010 14:27:39 -0800 (PST)
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 oBMMTbJ3092305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Dec 2010 15:29:38 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References: <[email-masked]>
Date: Wed, 22 Dec 2010 14:29:35 -0800
To: Paul Wouters
From: Paul Hoffman
Content-Type: text/plain; charset="us-ascii"
Cc: "[email-masked]"
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 22 Dec 2010 22:27:41 -0000

At 5:11 PM -0500 12/22/10, Paul Wouters wrote:
>Note that "preference" is not good enough - it would allow an attacker
>to use a downgrade attack. Though I would be okay with "80 443"
>meaning preference and "0 443" meaning "just 443".

That was my intention...

>But then we have the
>compatibility issue of running on port 80 while HASTLS says there is
>nothing on port 80. Again. I am fine with that, because I am going by
>the assumption that clients that impkement HASTLS will also implement the
>"no non-secure fallback when secure port is dnssec validated",

That's one assumption, but one that does not match what most users have today.

>eg something like:
>
>"If a service is offered on both insecure and secure ports, and the client
>supports the secure port, it SHOULD|MUST connect to the secure port only"

And, again, that is you telling someone else what they MUST do, regardless of what they want.

>To me, this falls in the same category as "MUST NOT use a nonce twice". It's
>inheritant in the security protocol to counter an attack vector.

They are completely unrelated. To repeat my example from a day or two ago: assume that the client does not have the trust anchor you require for TLS in their trust anchor store. "SHOULD|MUST connect to the secure port only" means "you're going to fail to connect, tough luck". More likely it will mean "you will tell your client to let you through anyway, ignoring what HASTLS told you securely".

>I think we all agree that is what sane clients should do. We don't agree
>on forcing them to do this. And part of my argument has been that if we
>don't specify this in the HASTLS document, we might end up with mixed
>behaviour where some will take (80 443) to mean "443 only" and others
>will take it as "either port is fine".

We fully agree that will happen: that's what client policy is all about. That's why hoffman-server-has-tls differentiates these types of clients as CSO and CFB, while other proposals pretends that the difference doesn't exist even though both clearly do exist.

--Paul Hoffman, Director
--VPN Consortium

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 014DB3A68C6 for ; Wed, 22 Dec 2010 14:24:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.887
X-Spam-Level:
X-Spam-Status: No, score=-2.887 tagged_above=-999 required=5 tests=[AWL=-0.289, 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 SeXFrgpb+yDb for ; Wed, 22 Dec 2010 14:24:20 -0800 (PST)
Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id 22C9B3A68BE for ; Wed, 22 Dec 2010 14:24:20 -0800 (PST)
Received: by yie19 with SMTP id 19so892179yie.31 for ; Wed, 22 Dec 2010 14:26:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=x61iWIQCznB/Ka2wSonutuYzy9EBv7rnob4MOo5yE0I=; b=deEi76nLwxd6Nh1QgIy2gL14RCVLtMXDoRHIygt7fitL4i4RBmfTTAGnL8hdar3UYh QsBTva9aZKMEIptGIEF/zabZjgzXmRDFT93nvbVYw1Ehqr6M7PBjDvQ5lJGh+4Eciu/U fTpBN5GloRxQFB/o6j23ov73fajAUyBBDlnHY=
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=ldAmiupsQbCMcJEgqUeMJWPRvxfaZIIDMuU5mg+EF/3PBSvNma8MF74f7f69K29C3k FLRkBmncELY8h9qvnf3tvYMJRXm1XeZKKwL2dEhToOn9seYua5H/TrdMfCqsV1ZWTQqo GqrtFjbGISm0vZ4YJLJ5sPABhSfnRABywQOvU=
MIME-Version: 1.0
Received: by 10.100.225.7 with SMTP id x7mr4469833ang.69.1293056778895; Wed, 22 Dec 2010 14:26:18 -0800 (PST)
Received: by 10.100.31.8 with HTTP; Wed, 22 Dec 2010 14:26:18 -0800 (PST)
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]>
Date: Wed, 22 Dec 2010 22:26:18 +0000
Message-ID:
From: Phillip Hallam-Baker
To: Paul Hoffman
Content-Type: multipart/alternative; boundary=001636920544fb03390498073d34
Cc: [email-masked]
Subject: Re: [keyassure] TLSA and HASTLS
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 22 Dec 2010 22:24:24 -0000

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

Well since you appeared to be telling someone 'this has already been
decided, shut up and go away', the fact that earlier you were telling people
that this would be discussed later is rather relevant.

Since you clearly had no intention of implying that this issue had already
been decided, we can now have the discussion we agreed earlier to postpone,
having made no decision or commitment whatsoever.

On Wed, Dec 22, 2010 at 10:07 PM, Paul Hoffman wrote:

> At 9:42 PM +0000 12/22/10, Phillip Hallam-Baker wrote:
> >Actually, that was what you requested in the Pre-WG.
> >
> >Moreover at the time you kept saying that these are all decisions that the
> WG can revisit should it be formed.
>
> Exactly right.
>
> >And I predicted at the time that this tactic would be used.
>
> "This tactic"? What problem do you have with requesting that an issue be
> opened in the WG? That's the way the IETF works. If you don't like that,
> maybe you can find another SDO that works more to your liking.
>
> --Paul Hoffman, Director
> --VPN Consortium
>

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

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

Well since you appeared to be telling someone 'this has already been de=
cided, shut up and go away', the fact that earlier you were telling peo=
ple that this would be discussed later is rather relevant.

Since you clearly had no intention of implying that this issue had alr=
eady been decided, we can now have the discussion we agreed earlier to post=
pone, having made no decision or commitment whatsoever.

On Wed, Dec 22, 2010 at 10:07 PM, Paul Hoffman <=
span dir=3D"ltr"><paul.hoffman@=
vpnc.org> wrote:

At 9:42 PM +0000 12/22/10, Phillip Hallam-Baker wrote:
>Actually, that was what you requested in the Pre-WG.

>

>Moreover at the time you kept saying that these are all decisions that =
the WG can revisit should it be formed.

Exactly right.

>And I predicted at the time that this tactic would be used.

"This tactic"? What problem do you have with requesting tha=
t an issue be opened in the WG? That's the way the IETF works. If you d=
on't like that, maybe you can find another SDO that works more to your =
liking.

--Paul Hoffman, Director

--VPN Consortium

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

--001636920544fb03390498073d34--

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E64E33A6B92 for ; Wed, 22 Dec 2010 14:09:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.288
X-Spam-Level:
X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=-0.289, BAYES_00=-2.599, J_CHICKENPOX_64=0.6]
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 Qlx09C+c41Nl for ; Wed, 22 Dec 2010 14:09:45 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id A261F3A6B2A for ; Wed, 22 Dec 2010 14:09:44 -0800 (PST)
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 47755C412; Wed, 22 Dec 2010 17:11:42 -0500 (EST)
Date: Wed, 22 Dec 2010 17:11:41 -0500 (EST)
From: Paul Wouters
To: "Jeffrey A. Williams"
In-Reply-To: <[email-masked]>
Message-ID:
References: <[email-masked]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: "[email-masked]"
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 22 Dec 2010 22:09:46 -0000

On Wed, 22 Dec 2010, Jeffrey A. Williams wrote:

>>> And there is also no way to say "we prefer you to come in at port 443",
>>> that would allow the local client policy to overrule a systems preference.
>>
>> We could add such a preference to the announcement protocol, but seems kind of silly: it is obvious that servers would prefer you use the secure protocol.
>
> +1

Note that "preference" is not good enough - it would allow an attacker
to use a downgrade attack. Though I would be okay with "80 443"
meaning preference and "0 443" meaning "just 443". But then we have the
compatibility issue of running on port 80 while HASTLS says there is
nothing on port 80. Again. I am fine with that, because I am going by
the assumption that clients that impkement HASTLS will also implement the
"no non-secure fallback when secure port is dnssec validated",

eg something like:

"If a service is offered on both insecure and secure ports, and the client
supports the secure port, it SHOULD|MUST connect to the secure port only"

To me, this falls in the same category as "MUST NOT use a nonce twice". It's
inheritant in the security protocol to counter an attack vector.

I think we all agree that is what sane clients should do. We don't agree
on forcing them to do this. And part of my argument has been that if we
don't specify this in the HASTLS document, we might end up with mixed
behaviour where some will take (80 443) to mean "443 only" and others
will take it as "either port is fine".

Paul

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A90D3A6B72 for ; Wed, 22 Dec 2010 14:06:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.618
X-Spam-Level:
X-Spam-Status: No, score=-101.618 tagged_above=-999 required=5 tests=[AWL=0.428, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 J86a4kesIuOf for ; Wed, 22 Dec 2010 14:06:06 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id D44153A68BE for ; Wed, 22 Dec 2010 14:06:04 -0800 (PST)
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 oBMM80aG091629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Dec 2010 15:08:01 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]>
Date: Wed, 22 Dec 2010 14:07:58 -0800
To: Phillip Hallam-Baker
From: Paul Hoffman
Content-Type: text/plain; charset="us-ascii"
Cc: [email-masked]
Subject: Re: [keyassure] TLSA and HASTLS
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 22 Dec 2010 22:06:07 -0000

At 9:42 PM +0000 12/22/10, Phillip Hallam-Baker wrote:
>Actually, that was what you requested in the Pre-WG.
>
>Moreover at the time you kept saying that these are all decisions that the WG can revisit should it be formed.

Exactly right.

>And I predicted at the time that this tactic would be used.

"This tactic"? What problem do you have with requesting that an issue be opened in the WG? That's the way the IETF works. If you don't like that, maybe you can find another SDO that works more to your liking.

--Paul Hoffman, Director
--VPN Consortium

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 402933A6B45 for ; Wed, 22 Dec 2010 13:57:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.908
X-Spam-Level:
X-Spam-Status: No, score=-7.908 tagged_above=-999 required=5 tests=[AWL=1.209, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, 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 T4+AuCAaX1SR for ; Wed, 22 Dec 2010 13:57:16 -0800 (PST)
Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) by core3.amsl.com (Postfix) with ESMTP id 1087B3A6B37 for ; Wed, 22 Dec 2010 13:57:15 -0800 (PST)
DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:CC: Date:Subject:Thread-Topic:Thread-Index:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: x-ems-proccessed:x-ems-stamp:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=Oohkce6Bw/bd7zIKjxzaBI/P3gaogEJbcRfdtfZCJcJHVcvCLC1OxMp8 EviSl3EIiAwUblZgrLMhnVRcWB78ccRkkqqsJqHpJBrxWQ9gkf8IFN60U MZpOsyUR4mwn/ip;
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=[email-masked]; q=dns/txt; s=ppinc; t=1293055155; x=1324591155; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; z=From:=20"Steingruebl,=20Andy"=20|To:=20Phillip=20Hallam-Baker=20, =20Paul=20Hoffman=0D=0A=09|CC:=20" [email-masked]"=20|Date:=20Wed, =2022=20Dec=202010=2014:59:13=20-0700|Subject:=20RE:=20[k eyassure]=20HTTPS=20->=20HTTP=20downgrade|Message-ID:=20< 5EE049BA3C6538409BBE6F1760F328ABEB19B00DE2@DEN-MEXMS-001. corp.ebay.com>|References:=20<20101213220001.24500.52050. idtracker@localhost>=0D=0A=09=0D=0A=09=0D=0A=09=0D=0A=09=0D=0A=09<129280035 [email-masked]>=0D=0A=09=0D=0A=09<1292 [email-masked]>=0D=0A=09=0D=0A =09=0D=0A=09=0D=0A =09=0D=0A=09<12928996 [email-masked]>=0D=0A=09=0D=0A=09=0D=0A=09=0D=0A=09<5EE049BA3C6538409BBE6F1760 [email-masked]>=0D=0A=09=0D=0A=09=0D=0A=09=0D=0A=20 |In-Reply-To:=20|Content-Transfer-Encoding:=20quot ed-printable|MIME-Version:=201.0; bh=nGYtb10DrvBsxKlZTdRWOLapchopOS91pD+SqCBTL7Y=; b=E0mhol+1HUmhmjMwzUAutaPVzKC4RIBLxih1o1KQI66Jm/JbCRQdIDu8 y5QeS2m1T86AxS3eGQS6Fh3ZEgrJTsfHp00OTTeSQEWo0tMJz2uiAkEUs jDJ4G4Ong9fb74m;
X-EBay-Corp: Yes
X-IronPort-AV: E=Sophos;i="4.60,215,1291622400"; d="scan'208";a="567310"
Received: from den-vtenf-002.corp.ebay.com (HELO DEN-MEXHT-002.corp.ebay.com) ([10.101.112.213]) by den-mipot-002.corp.ebay.com with ESMTP; 22 Dec 2010 13:59:14 -0800
Received: from DEN-MEXMS-001.corp.ebay.com ([10.241.16.225]) by DEN-MEXHT-002.corp.ebay.com ([10.241.17.53]) with mapi; Wed, 22 Dec 2010 14:59:14 -0700
From: "Steingruebl, Andy"
To: Phillip Hallam-Baker , Paul Hoffman
Date: Wed, 22 Dec 2010 14:59:13 -0700
Thread-Topic: [keyassure] HTTPS -> HTTP downgrade
Thread-Index: AcuiIO+85J/ZhkLITPq99qQ8XCFEDQAAiOeQ
Message-ID: <[email-masked]>
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To:
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A==
x-ems-stamp: klP5kQ5er3vLbNl6iFeYPg==
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter: Scanned
Cc: "[email-masked]"
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 22 Dec 2010 21:57:17 -0000

> From: [email-masked] [mailto:[email-masked]] On B=
ehalf Of Phillip Hallam-Baker

> These are all merely descriptive of the server security policy. IOf clien=
ts want to connect, they can make their own choices.

They can, of course. We can't "enforce" it on them, as we don't directly c=
ontrol their code. But, what we can control is whether this is a "MAY" or=
a "MUST" requirement in the spec. In my mind it's a MUST, not a MAY/SHOUL=
D. We don't want fuzziness here, as we're trying to protect against known =
attacks and we want uniformity of implementation. My sense from the major =
browser vendors - who really are the major target for this spec anyway from=
the client side - is that they'd want MUST also, and uniformity.

I also think it should be explicit, not implicit in publishing keys in DNS.=
I would deploy it today if I could, totally absent a fully specified keys-=
in-dns spec from this group.

- Andy

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D59B93A6A09 for ; Wed, 22 Dec 2010 13:40:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.385
X-Spam-Level:
X-Spam-Status: No, score=-3.385 tagged_above=-999 required=5 tests=[AWL=0.213, 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 Z8oSI-qOnu1M for ; Wed, 22 Dec 2010 13:40:34 -0800 (PST)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id CDACB3A6888 for ; Wed, 22 Dec 2010 13:40:33 -0800 (PST)
Received: by yxt33 with SMTP id 33so2605397yxt.31 for ; Wed, 22 Dec 2010 13:42:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=oIb0UoFPJZNmTjINtVYSwIXCfMjukA2v3tbaauJT2Hw=; b=wmam6U+VM8v/m30lLcQNBfFIVoawEkWgwPktQtn4jT2UUJci/q5FPR280JtqUCnfhb UxpvhySLBMwRbxPXRJS9CTyg1wJGCs8eusIhkyNyEcP0nsmBakbURUdx3iIYZ9+ej5Ri j4YZTx0yCI/2N9oRuyA3NPif8+NSwhtw+0KNs=
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=DM9J5Yv7Vjiqzw+LXDcXgit0oI0qZ/nnwzKK1cqWU//JLa5Er2DBB92+0t32r6Gxq2 +ZGsFMADbZhwz0eO6eDqRgaDbp4bOduq/oEycZfcv1+yrazG+cYcmE6CurtBkadzANIb YjU2th/kjEs718+ulElLqYK8tCF/98LD+jVYY=
MIME-Version: 1.0
Received: by 10.100.110.16 with SMTP id i16mr4440440anc.103.1293054152256; Wed, 22 Dec 2010 13:42:32 -0800 (PST)
Received: by 10.100.31.8 with HTTP; Wed, 22 Dec 2010 13:42:32 -0800 (PST)
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]>
Date: Wed, 22 Dec 2010 21:42:32 +0000
Message-ID:
From: Phillip Hallam-Baker
To: Paul Hoffman
Content-Type: multipart/alternative; boundary=0016e645ab9a6bad45049806a166
Cc: [email-masked]
Subject: Re: [keyassure] TLSA and HASTLS
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 22 Dec 2010 21:40:34 -0000

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

Actually, that was what you requested in the Pre-WG.

Moreover at the time you kept saying that these are all decisions that the
WG can revisit should it be formed.

And I predicted at the time that this tactic would be used.

On Wed, Dec 22, 2010 at 3:32 PM, Paul Hoffman wrote:

> At 8:58 AM -0500 12/21/10, James Cloos wrote:
> >A bare public key is generally useful, and DANE shouldn't be just about
> TLS.
>
> TLSA *is* just about TLS currently, as was requested by the pre-WG. If you
> want to change that, that is a completely separate thread.
>
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

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

Actually, that was what you requested in the Pre-WG.

Mor=
eover at the time you kept saying that these are all decisions that the WG =
can revisit should it be formed.

And I predicted at the time that this tactic would be used.

<=
/div>

On Wed, Dec 22, 2010 at 3:32 P=
M, Paul Hoffman <[email-masked]> wrote:

At 8:58 AM -0500 12/21/10=
, James Cloos wrote:

>A bare public key is generally useful, and DANE shouldn't be just a=
bout TLS.

TLSA *is* just about TLS currently, as was requested by the pre-WG. I=
f you want to change that, that is a completely separate thread.

--Paul Hoffman, Director

--VPN Consortium

_______________________________________________

keyassure mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/keyassure

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

--0016e645ab9a6bad45049806a166--

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F4B73A6BA2 for ; Wed, 22 Dec 2010 13:37:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.888
X-Spam-Level:
X-Spam-Status: No, score=-2.888 tagged_above=-999 required=5 tests=[AWL=-0.290, 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 pb7KNnk-Gpnh for ; Wed, 22 Dec 2010 13:37:57 -0800 (PST)
Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id 7346B3A6B72 for ; Wed, 22 Dec 2010 13:37:53 -0800 (PST)
Received: by yie19 with SMTP id 19so883780yie.31 for ; Wed, 22 Dec 2010 13:39:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=Yjd2p7vbBPXPytY91XqhJB12phGk5+k2u5wBcIwQ9+c=; b=NoiW7zht+xa6ZOXDWTFToO7+dPrfNGjzTcUEF6C8fb0LZEbOPBqVqVWit5imR28O/U 5iJuJ3LDz8QL4Q+godGgkZRfwkaZyAWNqqaIoj0b0l26S5NjnOwisikaV2v/61txhNB/ ZBgZrCDeJfBwrq+lsla9qGC4GMUR3vwn6hWTI=
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=c8lba6lKwNRd2R9eZ9sGJEIusSizg133prCQKtSpKTO2QI7RdG9wTkUcBq1Ht1FAyy bvggj9NFDchHlu0d/WjT+EqIpoJppddID4am56p7dNoHZFe65kAL5kX5PckmF0R/xdHJ t8bk9F1Km4TP6MtuvhLX5ZpjfbDCLKhg/rkTI=
MIME-Version: 1.0
Received: by 10.101.67.16 with SMTP id u16mr4461844ank.1.1293053991231; Wed, 22 Dec 2010 13:39:51 -0800 (PST)
Received: by 10.100.31.8 with HTTP; Wed, 22 Dec 2010 13:39:51 -0800 (PST)
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Wed, 22 Dec 2010 21:39:51 +0000
Message-ID:
From: Phillip Hallam-Baker
To: Paul Hoffman
Content-Type: multipart/alternative; boundary=00163662e65bd29f890498069708
Cc: "[email-masked]"
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 22 Dec 2010 21:37:58 -0000

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

I look at the problem differently.

The server site is merely describing its local security policy to whoever
might want to connect. So it is making statements such as

"TLS is always offered"
"TLS must be used"
"IPSEC must be used"
"A path for the cert can be formed from CA cert X"
"The key is Y"

These are all merely descriptive of the server security policy. IOf clients
want to connect, they can make their own choices.

Server policies such as 'must use TLS' are going to be very hard to
implement outside of closed environments. The NSA and banks can use that
policy internally. It would be rather difficult for most sites to do so.

The implicit policy approach that people have been pushing is not going to
work very well in practice because there is a wide range of possible
security policies sites will want to implement and the implicit approach
invites everyone to read into the spec whatever they would like to see
there.

If the implicit approach is followed, we will have a long series of
arguments of this type and at the end each browser will interpret the
implicit semantics as makes sense to them.

We will do much better with a clean architecture that separates the
assertion of keys, paths and other credentials from the declaration of
security policy.

It is convenient to do both in a single record. Doing so goes beyond the
scope of the CERT record, but I don't see much value in using that anyway.

On Wed, Dec 22, 2010 at 7:46 PM, Paul Hoffman wrote:

> At 2:11 PM -0500 12/22/10, Paul Wouters wrote:
> >That discussion keeps circling into "you cannot dictate policy" vs
> >"that's so insecure the protocol should provide a way to prevent it".
>
> We agree that we keep circling to an either X or Y question. I would state
> the question as "you { can | cannot } dictate a policy that demands that a
> client only use a secure service on a particular host". Once we have
> agreement on whether that is "can" or "cannot", moving forwards on the
> resulting protocol is much easier.
>
> >And there is also no way to say "we prefer you to come in at port 443",
> >that would allow the local client policy to overrule a systems preference.
>
> We could add such a preference to the announcement protocol, but seems kind
> of silly: it is obvious that servers would prefer you use the secure
> protocol.
>
> >>>Are you saying that other than the one corner case I've outlined that
> this will be a common occurrence, and that users will somehow actually want
> to control this, disregard the policy offered by the site?
> >>
> >>I certainly am not saying that, and I don't know if Paul Wouters is.
> >
> >The beviour of first going to port 80 and depending on a redirect to
> >port 443 is not a corner case. It is the common case.
>
> Fully agree.
>
> >Having a DNSSEC
> >validatable method to tell the client to start out on port 443 is
> >needed.
>
> Disagree, but no need to bludgeon that.
>
> >Since we are doing TLS related DNS records, this seems a good
> >time to include support for this.
>
> Fully agree.
>
> >Again, these attacks are happening, they are not theoretical.
>
> No one has said otherwise.
>
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

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

I look at the problem differently.

The server site is me=
rely describing its local security policy to whoever might want to connect.=
So it is making statements such as=A0

"TLS i=
s always offered"

"TLS must be used"

"IPSEC must be used"<=
/div>
"A path for the cert can be formed from CA cert X"
"The key is Y"

These are all merely descriptive of the server security policy. IOf clients=
want to connect, they can make their own choices.

Server policies such as 'must use TLS' are going to be very hard t=
o implement outside of closed environments. The NSA and banks can use that =
policy internally. It would be rather difficult for most sites to do so.

The implicit policy approach that people have been push=
ing is not going to work very well in practice because there is a wide rang=
e of possible security policies sites will want to implement and the implic=
it approach invites everyone to read into the spec whatever they would like=
to see there.

If the implicit approach is followed, we will have a lo=
ng series of arguments of this type and at the end each browser will interp=
ret the implicit semantics as makes sense to them.=A0

We will do much better with a clean architecture that s=
eparates the assertion of keys, paths and other credentials from the declar=
ation of security policy.

It is convenient to do b=
oth in a single record. Doing so goes beyond the scope of the CERT record, =
but I don't see much value in using that anyway.

On Wed, Dec 22, 2010 at =
7:46 PM, Paul Hoffman <[email-masked]> wrote:

At 2:11 PM -0500 12/22/10, Paul Wouters wrote:

>That discussion keeps circling into "you cannot dictate policy&quo=
t; vs

>"that's so insecure the protocol should provide a way to preve=
nt it".

We agree that we keep circling to an either X or Y question. I would =
state the question as "you { can | cannot } dictate a policy that dema=
nds that a client only use a secure service on a particular host". Onc=
e we have agreement on whether that is "can" or "cannot"=
;, moving forwards on the resulting protocol is much easier.

>And there is also no way to say "we prefer you to come in at port =
443",

>that would allow the local client policy to overrule a systems preferen=
ce.

We could add such a preference to the announcement protocol, but seem=
s kind of silly: it is obvious that servers would prefer you use the secure=
protocol.

>>>Are you saying that other than the one corner case I've out=
lined that this will be a common occurrence, and that users will somehow ac=
tually want to control this, disregard the policy offered by the site?

>>

>>I certainly am not saying that, and I don't know if Paul Wouter=
s is.

>

>The beviour of first going to port 80 and depending on a redirect to
>port 443 is not a corner case. It is the common case.

Fully agree.

>Having a DNSSEC

>validatable method to tell the client to start out on port 443 is

>needed.

Disagree, but no need to bludgeon that.

>Since we are doing TLS related DNS records, this seems a good

>time to include support for this.

Fully agree.

>Again, these attacks are happening, they are not theoretical.

No one has said otherwise.

--Paul Hoffman, Director

--VPN Consortium

_______________________________________________

keyassure mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/keyassure

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

--00163662e65bd29f890498069708--

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 110A83A6A07 for ; Wed, 22 Dec 2010 12:01:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.196
X-Spam-Level:
X-Spam-Status: No, score=-2.196 tagged_above=-999 required=5 tests=[AWL=0.403, 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 zDoo4PnX+0W0 for ; Wed, 22 Dec 2010 12:01:37 -0800 (PST)
Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 8E99F3A6866 for ; Wed, 22 Dec 2010 12:01:37 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=Rq3FgmOhAeOst2WL/QjmtcEM9rAjHstFrPwvXM5Pk0tj3qDkSlvIy+r5aw4/dl5m; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.47] (helo=elwamui-rubis.atl.sa.earthlink.net) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1PVUuO-0007tL-3p for [email-masked]; Wed, 22 Dec 2010 15:03:36 -0500
Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Wed, 22 Dec 2010 15:03:36 -0500
Message-ID: <[email-masked]>
Date: Wed, 22 Dec 2010 14:03:36 -0600 (GMT-06:00)
From: "Jeffrey A. Williams"
To: "[email-masked]"
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e519606880e61ce995930cc5832e7bdca8ba6af86350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.47
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: "Jeffrey A. Williams"
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 22 Dec 2010 20:01:39 -0000

Paul and all,

-----Original Message-----
>From: Paul Hoffman
>Sent: Dec 22, 2010 1:46 PM
>To: Paul Wouters
>Cc: "[email-masked]"
>Subject: Re: [keyassure] HTTPS -> HTTP downgrade
>
>At 2:11 PM -0500 12/22/10, Paul Wouters wrote:
>>That discussion keeps circling into "you cannot dictate policy" vs
>>"that's so insecure the protocol should provide a way to prevent it".
>
>We agree that we keep circling to an either X or Y question. I would state the question as "you { can | cannot } dictate a policy that demands that a client only use a secure service on a particular host". Once we have agreement on whether that is "can" or "cannot", moving forwards on the resulting protocol is much easier.

I agree with this but I am sure that you know that there will be
some political push back at some point from State and USTR on this.
Me thinks that they will want/demand that 'CAN' is the preferred
or strongly desired option.
>
>>And there is also no way to say "we prefer you to come in at port 443",
>>that would allow the local client policy to overrule a systems preference.
>
>We could add such a preference to the announcement protocol, but seems kind of silly: it is obvious that servers would prefer you use the secure protocol.

+1
>
>>>>Are you saying that other than the one corner case I've outlined that this will be a common occurrence, and that users will somehow actually want to control this, disregard the policy offered by the site?
>>>
>>>I certainly am not saying that, and I don't know if Paul Wouters is.
>>
>>The beviour of first going to port 80 and depending on a redirect to
>>port 443 is not a corner case. It is the common case.
>
>Fully agree.
>
>>Having a DNSSEC
>>validatable method to tell the client to start out on port 443 is
>>needed.
>
>Disagree, but no need to bludgeon that.
>
>>Since we are doing TLS related DNS records, this seems a good
>>time to include support for this.
>
>Fully agree.

+1
>
>>Again, these attacks are happening, they are not theoretical.
>
>No one has said otherwise.
>
>--Paul Hoffman, Director
>--VPN Consortium
>_______________________________________________
>keyassure mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/keyassure

Kindest regards,
Jeffrey A. Williams
"Obedience of the law is the greatest freedom" -
Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
Network security Eng. SR. Eng. Network data security,
IT/information security.
ABA member in good standing member ID 01257402
E-Mail [email-masked]
Phone: 214-244-4827

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74E703A6A48 for ; Wed, 22 Dec 2010 11:44:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.612
X-Spam-Level:
X-Spam-Status: No, score=-101.612 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 BR4WwsxY3B-l for ; Wed, 22 Dec 2010 11:44:42 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 9EE4E3A6A06 for ; Wed, 22 Dec 2010 11:44:42 -0800 (PST)
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 oBMJkdA0081979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Dec 2010 12:46:41 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Wed, 22 Dec 2010 11:46:38 -0800
To: Paul Wouters
From: Paul Hoffman
Content-Type: text/plain; charset="us-ascii"
Cc: "[email-masked]"
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 22 Dec 2010 19:44:43 -0000

At 2:11 PM -0500 12/22/10, Paul Wouters wrote:
>That discussion keeps circling into "you cannot dictate policy" vs
>"that's so insecure the protocol should provide a way to prevent it".

We agree that we keep circling to an either X or Y question. I would state the question as "you { can | cannot } dictate a policy that demands that a client only use a secure service on a particular host". Once we have agreement on whether that is "can" or "cannot", moving forwards on the resulting protocol is much easier.

>And there is also no way to say "we prefer you to come in at port 443",
>that would allow the local client policy to overrule a systems preference.

We could add such a preference to the announcement protocol, but seems kind of silly: it is obvious that servers would prefer you use the secure protocol.

>>>Are you saying that other than the one corner case I've outlined that this will be a common occurrence, and that users will somehow actually want to control this, disregard the policy offered by the site?
>>
>>I certainly am not saying that, and I don't know if Paul Wouters is.
>
>The beviour of first going to port 80 and depending on a redirect to
>port 443 is not a corner case. It is the common case.

Fully agree.

>Having a DNSSEC
>validatable method to tell the client to start out on port 443 is
>needed.

Disagree, but no need to bludgeon that.

>Since we are doing TLS related DNS records, this seems a good
>time to include support for this.

Fully agree.

>Again, these attacks are happening, they are not theoretical.

No one has said otherwise.

--Paul Hoffman, Director
--VPN Consortium

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44D8A3A6A8D for ; Wed, 22 Dec 2010 11:09:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.588
X-Spam-Level:
X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 bPkB-TmWYXxX for ; Wed, 22 Dec 2010 11:09:38 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 9806C3A68A5 for ; Wed, 22 Dec 2010 11:09:37 -0800 (PST)
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 7334EC4D0; Wed, 22 Dec 2010 14:11:34 -0500 (EST)
Date: Wed, 22 Dec 2010 14:11:33 -0500 (EST)
From: Paul Wouters
To: Paul Hoffman
In-Reply-To:
Message-ID:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: "[email-masked]"
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 22 Dec 2010 19:09:39 -0000

On Wed, 22 Dec 2010, Paul Hoffman wrote:

>> I don't imagine many sites deploying identical content on port-80 and port-443, but advertising "must use TLS" to clients, but still supporting unencrypted content on port-80.
>
> Fully agree, which is why I think Paul Wouters "lie to them" idea will cause confusion to the point of getting people to turn it off.

The matter is not whether or not port 80 has identical content or not. The
issue is that once a client connects on port 80, an attacker can *prevent*
them from going to port 443. I am looking for a DNSSEC validated policy
to tell clients to never connect to port 80.

Once we are on port 443, we will have the TLSA/HASTLS (or CA's) to ensure
we're not ending up at a rogue side

That discussion keeps circling into "you cannot dictate policy" vs
"that's so insecure the protocol should provide a way to prevent it".

And there is also no way to say "we prefer you to come in at port 443",
that would allow the local client policy to overrule a systems preference.

>> Are you saying that other than the one corner case I've outlined that this will be a common occurrence, and that users will somehow actually want to control this, disregard the policy offered by the site?
>
> I certainly am not saying that, and I don't know if Paul Wouters is.

The beviour of first going to port 80 and depending on a redirect to
port 443 is not a corner case. It is the common case. Having a DNSSEC
validatable method to tell the client to start out on port 443 is
needed. Since we are doing TLS related DNS records, this seems a good
time to include support for this.

Again, these attacks are happening, they are not theoretical.

Paul

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF4B03A6A68 for ; Wed, 22 Dec 2010 10:17:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.609
X-Spam-Level:
X-Spam-Status: No, score=-101.609 tagged_above=-999 required=5 tests=[AWL=0.437, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 Tb+zn+jPaue7 for ; Wed, 22 Dec 2010 10:17:46 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 212513A68F7 for ; Wed, 22 Dec 2010 10:17:46 -0800 (PST)
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 oBMIJhrE073863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Dec 2010 11:19:44 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To: <[email-masked]>
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Wed, 22 Dec 2010 10:19:42 -0800
To: Matt McCutchen
From: Paul Hoffman
Content-Type: text/plain; charset="us-ascii"
Cc: [email-masked]
Subject: Re: [keyassure] TLSA and HASTLS
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 22 Dec 2010 18:17:46 -0000

At 12:17 PM -0500 12/22/10, Matt McCutchen wrote:
>On Wed, 2010-12-22 at 07:32 -0800, Paul Hoffman wrote:
>> At 8:58 AM -0500 12/21/10, James Cloos wrote:
>> >A bare public key is generally useful, and DANE shouldn't be just about TLS.
>>
>> TLSA *is* just about TLS currently, as was requested by the pre-WG. If
>> you want to change that, that is a completely separate thread.
>
>Right... so will you rename the draft to a name that contains "tls" so
>people do not get confused?

It says TLS right in the title: "Using Secure DNS to Associate Certificates with Domain Names For TLS". Are you suggesting moving "TLS" to earlier in the title? I don't see a good way to do that.

--Paul Hoffman, Director
--VPN Consortium

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A080F3A6A60 for ; Wed, 22 Dec 2010 09:15:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YYiwjpFZzkjf for ; Wed, 22 Dec 2010 09:15:56 -0800 (PST)
Received: from homiemail-a62.g.dreamhost.com (mx1.spunky.mail.dreamhost.com [208.97.132.47]) by core3.amsl.com (Postfix) with ESMTP id B28FA3A67FD for ; Wed, 22 Dec 2010 09:15:56 -0800 (PST)
Received: from homiemail-a62.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTP id 2BCDA63406E; Wed, 22 Dec 2010 09:17:55 -0800 (PST)
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=bYMKFCZ1IwNBklmAxrufH0VUzmAkaX55W6YUvkBE3kY LuglcQEqlILuiMgWfj7ozHpf3wSE48GklDywaijngm75x/jjZrjycKTV5jHF4kJs VMFeMmfGczi65CJ4vzUUFuQ+GyU+hGQRBv5aUavyahMXvMr/DtvQSpV6SpAFIb4A =
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=daEcgBTq9529E1c7vstfSmxbwgc=; b=hjH/XtnUSj 74jp6tvWPQX8GzcWnZdcNubnkhJXIQXD6192d4E8LhsTruywvvxDU8mHW6qyV4cZ ulRXZFxIyEPmvGUh8F6JzOFfn+sg9rLlIi5rwevTtaOxMRNYnYPBeiHr2dG9LDAk kThh1Od2c3oBfomCo+ackPXVL8wuBa+bg=
Received: from [192.168.1.40] (pool-96-231-10-176.washdc.east.verizon.net [96.231.10.176]) (Authenticated sender: [email-masked]) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTPA id B10B5634064; Wed, 22 Dec 2010 09:17:54 -0800 (PST)
From: Matt McCutchen
To: Paul Hoffman
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset="UTF-8"
Date: Wed, 22 Dec 2010 12:17:53 -0500
Message-ID: <[email-masked]>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.1
Content-Transfer-Encoding: 7bit
Cc: [email-masked]
Subject: Re: [keyassure] TLSA and HASTLS
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 22 Dec 2010 17:15:57 -0000

On Wed, 2010-12-22 at 07:32 -0800, Paul Hoffman wrote:
> At 8:58 AM -0500 12/21/10, James Cloos wrote:
> >A bare public key is generally useful, and DANE shouldn't be just about TLS.
>
> TLSA *is* just about TLS currently, as was requested by the pre-WG. If
> you want to change that, that is a completely separate thread.

Right... so will you rename the draft to a name that contains "tls" so
people do not get confused?

--
Matt

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DAD43A6BAA for ; Wed, 22 Dec 2010 08:44:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.796
X-Spam-Level:
X-Spam-Status: No, score=-9.796 tagged_above=-999 required=5 tests=[AWL=0.803, 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 Acb2zObc7io6 for ; Wed, 22 Dec 2010 08:44:57 -0800 (PST)
Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by core3.amsl.com (Postfix) with ESMTP id 23FAA3A6B12 for ; Wed, 22 Dec 2010 08:44:57 -0800 (PST)
Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id oBMGi7qw015444; Wed, 22 Dec 2010 11:44:07 -0500
Received: from DUL1WNEXMB11.vcorp.ad.vrsn.com ([10.170.13.11]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Dec 2010 11:46:55 -0500
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 ; Wed, 22 Dec 2010 16:46:54 +0000
User-Agent: Microsoft-Entourage/12.27.0.100910
Date: Wed, 22 Dec 2010 11:46:54 -0800
From: "Osterweil, Eric"
To: Paul Wouters , Paul Hoffman
Message-ID:
Thread-Topic: [keyassure] TLSA and HASTLS
Thread-Index: AcufzSB+U3eg9sxrTYGHoDpozG0vYgCKrYiP
In-Reply-To:
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 22 Dec 2010 16:46:55.0033 (UTC) FILETIME=[D73DB290:01CBA1F7]
Cc: KIDNS
Subject: Re: [keyassure] TLSA and HASTLS
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 22 Dec 2010 16:44:58 -0000

On 12/19/10 2:35 PM, "Paul Wouters" wrote:

> On Fri, 17 Dec 2010, Paul Hoffman wrote:
>
>>> Hmm, so draft-hoffman-server-has-tls-01 defines a HASTLS record. Execsum:
>>>
>>> www.example.com IN HASTLS (25 25 0 443)
>>>
>>> But we have no method defined anyway to get all this information at once. So
>>> now this becomes two full roundtrip DNS queries
>>> to get enough information about the pubkey used on a website.
>>
>> Not at all. If you are about to do TLS and only TLS, then you don't need to
>> query for HASTLS: it is only if you want to do TLS but cannot get there that
>> you need to do HASTLS.
>>
>>> Is there any work being done on optimising this with an EDNS
>>> option?
>>
>> It's a thought, but one that has not garnered much interest in the past.
>
> So am I right that the consensus seems to be to continue with TLSA and HASTLS
> now, and look into
> an EDNS method later to optimise?
>
> I would be okay with that, and willing to take on the EDNS work to produce a
> draft. But I would
> also really like to see a "pubkey only" type being added to the TLSA draft to
> satisfy those who
> do not want to deal with any certificate information. This might go a long way
> to make TLSA a
> complete solution for those who want to minimize and maximize CA/cert usage.
> And would probably
> be enough to avoid Kaminsky/Gilmore and co to not deploy more TXT record
> overloads.

I don't understand the idea of the use of EDNS0 here? Op codes in EDNS0
from stub to recursive resolver will not (necessarily) be forwarded to
authoritative name servers during resolution, and OPT records coming back
from authorities are not allowed to be cached, and therefore are not
forwarded to stubs. Thus, if a client issues a query to anything other than
the authoritative server, it will not be able to use EDNS0, right? Maybe
I'm missing something?

Eric

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E51593A6BA3; Wed, 22 Dec 2010 08:44:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.394
X-Spam-Level:
X-Spam-Status: No, score=-9.394 tagged_above=-999 required=5 tests=[AWL=1.205, 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 y1hU+9AuVvPz; Wed, 22 Dec 2010 08:44:50 -0800 (PST)
Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by core3.amsl.com (Postfix) with ESMTP id ABEF63A6B12; Wed, 22 Dec 2010 08:44:50 -0800 (PST)
Received: from dul1wnexcn04.vcorp.ad.vrsn.com (dul1wnexcn04.vcorp.ad.vrsn.com [10.170.12.139]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id oBMGhF6a026004; Wed, 22 Dec 2010 11:43:15 -0500
Received: from DUL1WNEXMB11.vcorp.ad.vrsn.com ([10.170.13.11]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Dec 2010 11:46:48 -0500
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 ; Wed, 22 Dec 2010 16:46:48 +0000
User-Agent: Microsoft-Entourage/12.27.0.100910
Date: Wed, 22 Dec 2010 11:46:47 -0800
From: "Osterweil, Eric"
To: ,
Message-ID:
Thread-Topic: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
Thread-Index: AcubEWqVBxEInFbcTyaVmiQvURfk3gG5mffy
In-Reply-To: <20101213220001.24500.52050.idtracker@localhost>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 22 Dec 2010 16:46:48.0902 (UTC) FILETIME=[D3962E60:01CBA1F7]
Cc: KIDNS
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 22 Dec 2010 16:44:52 -0000

Hey everyone,

I have a few comments/questions about that draft that I don't _think_ have
yet been covered by the extensive discussion in this thread. :)

In Section 2.1, should there be any text requiring that the name of a cert
be in bailiwick for the domain name that covers it? I don't think the text
restricts me from placing a cert under name foo.com and then having that
cert's CN be bar.com. Shouldn't we try to limit the DNS' ability to verify
certs that are not in bailiwick?

In Section 3.1, I strongly disagree with the comment:
"The preceding paragraph is probably wrong ... There is
probably no reason to even use this protocol unless you are going to
fully trust the results..."

IMHO, this doc is not the place to dictate client behavior. My feeling is
that whether the client fully/partially/doesn't at all trust something
should be their call. If other working groups that focus on specific
clients feel there are different way to interpret data. Some of the
discussion so far has threaded around TLS' specification, when to use or not
use PKIX, etc. Couldn't we be better served by focusing on what the meaning
of data served is, and then allow clients to specify their own behaviors
(with sane suggestions, not mandates)? I think one of the drawbacks to
specifying behaviors of clients is that we now need to consider their
various requirements. The extent to which those diverge from each other is
the extent to which I think we might find ourselves straddling diverging
trains.

I don't understand the need for Section 3.1.1. I would have thought that
this work was ideal for self-signed certs that need orthogonal
authentication mechanisms. Instead, the text seems to suggest that
self-signed certs are still not to be trusted. Did I misread this? If I
generate my own self-signed cert and put it in my zone, then I imagine that
my intent is to rely on DNSSEC validation to vouch for my (say) TLS cert on
my https site, no?

Eric

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 898573A6ACA for ; Wed, 22 Dec 2010 07:41:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.606
X-Spam-Level:
X-Spam-Status: No, score=-101.606 tagged_above=-999 required=5 tests=[AWL=0.440, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 R0sNSnnmol3W for ; Wed, 22 Dec 2010 07:41:42 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id AF3693A69EC for ; Wed, 22 Dec 2010 07:41:42 -0800 (PST)
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 oBMFhdVU063408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Dec 2010 08:43:40 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To: <[email-masked]>
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Wed, 22 Dec 2010 07:43:37 -0800
To: "Steingruebl, Andy"
From: Paul Hoffman
Content-Type: text/plain; charset="us-ascii"
Cc: "[email-masked]"
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 22 Dec 2010 15:41:43 -0000

At 12:39 PM -0700 12/21/10, Steingruebl, Andy wrote:
> > -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of Paul Hoffman
>>
>> We are talking past each other here. You want to only support one model
>> (the one that cannot be circumvented by sslstrip) and completely prevent
>> users from getting to port 80. I want to let the user choose what they should
>> do, even if it is unsafe, *as long as* they can know securely what the system
>> is hosting.
>>
>> You believe that users will take your forced approach, and I do not. If you're
>> right, great: they'll be safer. If you're wrong, we have done nothing for them.
>
>Can you give me a better example here? If most common web browsers implement this as a "forced" redirect to port-443, users can go in and tweak their internal browser configuration, but I don't expect that most will.

You have no way of knowing that, and I have no way of knowing the opposite. The fact that PayPal has been TLS-only for years has taught PayPal users to expect 443, but PayPal is (sadly) in the very small minority, so your users are not a good metric.

>If the sites only does a redirect on port -80 -> 443, the user won't get anything meaningful at port-80 anyway. So, if they break their port-443 responder, things are totally broken anyway.

And yet that is exactly the reason we are having this discussion: users have vigorously and willingly said "do this unsafe thing for me" for over a decade.

>I don't imagine many sites deploying identical content on port-80 and port-443, but advertising "must use TLS" to clients, but still supporting unencrypted content on port-80.

Fully agree, which is why I think Paul Wouters "lie to them" idea will cause confusion to the point of getting people to turn it off.

>I do know of one site doing this, and they are doing it because of problems with filtering gateways in certain countries that want to content-inspect and don't allow HTTPS. They are forced to still serve all of their content on port-80, even though they are currently sending "Strict-Transport-Security" headers in their HTTPS replies.

It is probably not even "certain countries": there are lots of corporate firewalls that allow this setting.

>I view this as an extreme corner case. No other site I know of that wants to set STS still wants to serve content on port-80.

It's *much* too early to tell that: STS is in its infancy, HASTLS isn't even implementable.

>Are you saying that other than the one corner case I've outlined that this will be a common occurrence, and that users will somehow actually want to control this, disregard the policy offered by the site?

I certainly am not saying that, and I don't know if Paul Wouters is.

--Paul Hoffman, Director
--VPN Consortium

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CAC23A6ACA for ; Wed, 22 Dec 2010 07:35:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.603
X-Spam-Level:
X-Spam-Status: No, score=-101.603 tagged_above=-999 required=5 tests=[AWL=0.443, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 rd40A6rNM28q for ; Wed, 22 Dec 2010 07:35:06 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 3D0853A6AAF for ; Wed, 22 Dec 2010 07:35:06 -0800 (PST)
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 oBMFb215063169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Dec 2010 08:37:04 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To: <[email-masked]>
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Wed, 22 Dec 2010 07:36:59 -0800
To: Matt McCutchen
From: Paul Hoffman
Content-Type: text/plain; charset="us-ascii"
Cc: [email-masked]
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 22 Dec 2010 15:35:07 -0000

At 12:35 PM -0500 12/21/10, Matt McCutchen wrote:
>On Tue, 2010-12-21 at 09:03 -0800, Paul Hoffman wrote:
>> At 12:43 AM -0500 12/21/10, Matt McCutchen wrote:
>> >On Mon, 2010-12-20 at 20:30 -0800, Paul Hoffman wrote:
>> >> The real question, one that will be addressed in both DANE and WEBSEC,
>> >> is whether it is reasonable to say "I speak on port 80 but you MUST
>> >> use 443 instead, even if you wanted to do port 80". If you can come up
>> >> with non-silly semantics for that without obvious problems, the WGs
>> >> might buy it. I'm skeptical, though; I see many reasons for a client
>> >> to say "I know 443 is going to fail me, so I'm willing to fall back to
>> >> 80". The most obvious example is "you're using a CA who I don't trust,
>> >> so I'm going to fail during the TLS handshake".
>> >
>> >If http://foo:80 is just a redirection to https://foo:443, then it is
>> >quite reasonable because all that falling back to http://foo:80 buys you
>> >is the possibility of getting attacked.
>>
>> Quite right.
>
>So how is that expressed in HASTLS? I was proposing "0 443", but you
>said that was a lie. I think this was the only place we disagreed.

HASTLS currently has no semantics for "insecure port does a redirect to strong port" because most applications don't have redirection; only HTTP does. We could add such a semantic if we can find clean wording for it.

--Paul Hoffman, Director
--VPN Consortium

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DFA73A6AC0 for ; Wed, 22 Dec 2010 07:31:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.861
X-Spam-Level:
X-Spam-Status: No, score=-100.861 tagged_above=-999 required=5 tests=[AWL=-0.304, BAYES_05=-1.11, HELO_MISMATCH_COM=0.553, 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 vu59pd3tx-12 for ; Wed, 22 Dec 2010 07:31:04 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 0AC3E3A6AAF for ; Wed, 22 Dec 2010 07:31:03 -0800 (PST)
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 oBMFX0cg063000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Dec 2010 08:33:01 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]>
Date: Wed, 22 Dec 2010 07:32:59 -0800
To: James Cloos
From: Paul Hoffman
Content-Type: text/plain; charset="us-ascii"
Cc: [email-masked]
Subject: Re: [keyassure] TLSA and HASTLS
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 22 Dec 2010 15:31:04 -0000

At 8:58 AM -0500 12/21/10, James Cloos wrote:
>A bare public key is generally useful, and DANE shouldn't be just about TLS.

TLSA *is* just about TLS currently, as was requested by the pre-WG. If you want to change that, that is a completely separate thread.

--Paul Hoffman, Director
--VPN Consortium

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FEE73A691A for ; Tue, 21 Dec 2010 15:23:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J11WRWjhwTIc for ; Tue, 21 Dec 2010 15:23:18 -0800 (PST)
Received: from homiemail-a38.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by core3.amsl.com (Postfix) with ESMTP id BEACD3A67FA for ; Tue, 21 Dec 2010 15:23:18 -0800 (PST)
Received: from homiemail-a38.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a38.g.dreamhost.com (Postfix) with ESMTP id 8758910AFAA; Tue, 21 Dec 2010 15:25:15 -0800 (PST)
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=R/VIvNs7D3NijLN5BT2ra974oYo7691Pz9OdIk4I8Xo affkoT9xtfM8mV/pb05eI6BGC1Yt6R+8n95FJvVwfPzf2rzMvSwR16QYDNvd8Fj4 b0f3QeHan6eN2PyooYVtEQLQi513o0wBoyKNcgqlazV6Zc31jLaAY4v6+cVlNnVc =
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=Jt8ElOqO9ccD3RrR+0tQVGZ9qN0=; b=Jcf99MaAAF 7PzCye9CWEYcVhUVL9ILShmMBs0MMhLJw32ZcwULiQeAvif4dAAW4JsGJvPa/HUl Ae0rs7K8nr3WsSQrDZOVZlW0etisXtGUbsZnFZFFLSk4CMn+BzBhGwoqYRk1Ku+1 vPta3KH1cyRUwRSX2JGKd85gE0OVTQf7M=
Received: from [192.168.1.40] (pool-96-231-10-176.washdc.east.verizon.net [96.231.10.176]) (Authenticated sender: [email-masked]) by homiemail-a38.g.dreamhost.com (Postfix) with ESMTPA id 04B4610AFA5; Tue, 21 Dec 2010 15:25:14 -0800 (PST)
From: Matt McCutchen
To: James Cloos
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 21 Dec 2010 18:25:13 -0500
Message-ID: <[email-masked]>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.1
Content-Transfer-Encoding: 7bit
Cc: [email-masked]
Subject: Re: [keyassure] TLSA and HASTLS
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 21 Dec 2010 23:23:19 -0000

On Tue, 2010-12-21 at 08:58 -0500, James Cloos wrote:
> >>>>> "PH" == Paul Hoffman writes:
>
> PH> Just to be clear: are you are proposing DANE adding "bare public key"
> PH> *before* any version of TLS allows that?
>
> A bare public key is generally useful, and DANE shouldn't be just about TLS.

Indeed, the DANE charter puts IPsec in scope, but the current draft is
just about TLS. (It should probably be renamed to clarify that, unless
the intent is to add IPsec to the same document.) When we specify DANE
for a security protocol that supports bare public keys, then we can
include bare public keys in the list of association types.

--
Matt

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38F3B3A6AB5 for ; Tue, 21 Dec 2010 11:37:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.844
X-Spam-Level:
X-Spam-Status: No, score=-7.844 tagged_above=-999 required=5 tests=[AWL=1.273, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, 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 6BQJY29AbOS8 for ; Tue, 21 Dec 2010 11:37:41 -0800 (PST)
Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) by core3.amsl.com (Postfix) with ESMTP id D4C193A6A8B for ; Tue, 21 Dec 2010 11:37:40 -0800 (PST)
DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:CC: Date:Subject:Thread-Topic:Thread-Index:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: x-ems-proccessed:x-ems-stamp:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=WPvY8o3baodroOTPrHZAVW2fbMJ71kf/qe2ze+/ZHqoOFs13W7rz+0j7 KWGGZzDiuXCIdVQafjdAC91pWogDYgNsX1S5BLqiuKHuKFMYOlhQEaFq6 2Jc4CKjAXPLNvUb;
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=[email-masked]; q=dns/txt; s=ppinc; t=1292960378; x=1324496378; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; z=From:=20"Steingruebl,=20Andy"=20|To:=20Paul=20Hoffman=20,=20P aul=20Wouters=20|CC:=20"keyassure@iet f.org"=20|Date:=20Tue,=2021=20Dec=202 010=2012:39:36=20-0700|Subject:=20RE:=20[keyassure]=20HTT PS=20->=20HTTP=20downgrade|Message-ID:=20<5EE049BA3C65384 [email-masked]> |References:=20<20101213220001.24500.52050.idtracker@loca lhost>=0D=0A=20=09=0D=0A=20=09=0D=0A=20=09=0D=0A=20=09=0D=0A=20=09<129280 [email-masked]>=0D=0A=20=09=0D=0A =20=09<[email-masked]>=0D=0A =20=09=0D=0A=20=09 =0D=0A=20=09=0D=0A=20=09=0D=0A=09<[email-masked] l>=0D=0A=09=0D=0A =09=0D=0A=20 |In-Reply-To:=20 |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=v7kTDvew66FlpAyqEfZ6/Gn1lokDl4UPDs14MYkXH9A=; b=mt+e8HFV5/RmwPWwqObBo5L41Ld5ROXr01eHwrJX2W67nDy0HLE70xjY xr18yxIlvSlO+lxCx9d+wxfXdK94fdvsVJHJ6GCwgcr5V7h7oZKzP3hjD NctTpKNSWFeiCpP;
X-EBay-Corp: Yes
X-IronPort-AV: E=Sophos;i="4.60,209,1291622400"; d="scan'208";a="550894"
Received: from den-vtenf-002.corp.ebay.com (HELO DEN-MEXHT-002.corp.ebay.com) ([10.101.112.213]) by den-mipot-002.corp.ebay.com with ESMTP; 21 Dec 2010 11:39:37 -0800
Received: from DEN-MEXMS-001.corp.ebay.com ([10.241.16.225]) by DEN-MEXHT-002.corp.ebay.com ([10.241.17.53]) with mapi; Tue, 21 Dec 2010 12:39:36 -0700
From: "Steingruebl, Andy"
To: Paul Hoffman , Paul Wouters
Date: Tue, 21 Dec 2010 12:39:36 -0700
Thread-Topic: [keyassure] HTTPS -> HTTP downgrade
Thread-Index: AcuhMCwaF2zACU8XS0ClOCq4g77JJwAFf8uA
Message-ID: <[email-masked]>
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To:
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A==
x-ems-stamp: ffe6pvfiJ8quFS2PplLNeg==
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter: Scanned
Cc: "[email-masked]"
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 21 Dec 2010 19:37:42 -0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Paul Hoffman
>=20
> We are talking past each other here. You want to only support one model
> (the one that cannot be circumvented by sslstrip) and completely prevent
> users from getting to port 80. I want to let the user choose what they sh=
ould
> do, even if it is unsafe, *as long as* they can know securely what the sy=
stem
> is hosting.
>
> You believe that users will take your forced approach, and I do not. If y=
ou're
> right, great: they'll be safer. If you're wrong, we have done nothing for=
them.

Can you give me a better example here? If most common web browsers impleme=
nt this as a "forced" redirect to port-443, users can go in and tweak their=
internal browser configuration, but I don't expect that most will. If the=
sites only does a redirect on port -80 -> 443, the user won't get anything=
meaningful at port-80 anyway. So, if they break their port-443 responder,=
things are totally broken anyway.

I don't imagine many sites deploying identical content on port-80 and port-=
443, but advertising "must use TLS" to clients, but still supporting unencr=
ypted content on port-80. I do know of one site doing this, and they are d=
oing it because of problems with filtering gateways in certain countries th=
at want to content-inspect and don't allow HTTPS. They are forced to still=
serve all of their content on port-80, even though they are currently send=
ing "Strict-Transport-Security" headers in their HTTPS replies.

I view this as an extreme corner case. No other site I know of that wants =
to set STS still wants to serve content on port-80. =20

Are you saying that other than the one corner case I've outlined that this =
will be a common occurrence, and that users will somehow actually want to c=
ontrol this, disregard the policy offered by the site?

- Andy

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F6C43A6998 for ; Tue, 21 Dec 2010 10:55:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.397
X-Spam-Level:
X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[AWL=0.201, 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 ZKgj2w3vvdm8 for ; Tue, 21 Dec 2010 10:55:09 -0800 (PST)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id C2D1C3A6A4E for ; Tue, 21 Dec 2010 10:55:08 -0800 (PST)
Received: by gyd12 with SMTP id 12so1937399gyd.31 for ; Tue, 21 Dec 2010 10:57:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=zUFWq0ox4WZjUdPHlySFy8FThnBhfqUPO1aWvrxrsco=; b=wwKR3hPgfD0VC7MHrhNkLCxJgMpJFzVI392midXV6pHn3Wp45D98Vc9Iq+5JTt7vIx km9THoscIgQMr78q15XPhOIPOH33hWU3vmZeOlyYYIH4oq0C0nkAsuZoeupsfV3F8uIK dbfCO+xzjOuJBpVLwnbMg+CCkqc+tWjlllzfM=
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=DrxIc4iBjPZfujAZjMTieC3EG/ZwZhPV3YtA2Blc+r2QaPu9X31pwG2BO4K8Yfr/zK U1NQnPQWv6l3I65KhvfZbDhBP3nG/lRsQVQikxH0odX1U0sDwXJnsKQcRbwpP4uIU8ky 5dFV+GtZOji4uWmNRpyDo00h506IXHzYZ6KG0=
MIME-Version: 1.0
Received: by 10.100.225.7 with SMTP id x7mr3486127ang.69.1292957825071; Tue, 21 Dec 2010 10:57:05 -0800 (PST)
Received: by 10.100.31.8 with HTTP; Tue, 21 Dec 2010 10:57:04 -0800 (PST)
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Tue, 21 Dec 2010 18:57:04 +0000
Message-ID:
From: Phillip Hallam-Baker
To: Paul Wouters
Content-Type: multipart/alternative; boundary=001636920544df790a0497f033ca
Cc: [email-masked], Paul Hoffman
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 21 Dec 2010 18:55:10 -0000

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

Take a look at my proposal in the other thread, I think it meets your
requirements.

If you really really want to put the key into the DNS, then this is how I
would do it:

1) Put the raw key in the DNS
2) Sign with a RRSIG
3) Write a note that states that this combination is directly equivalent to
a PKIX certificate signed under the DNS ZSK with a subjectAltName of the
corresponding domain label.

But this combination would have to be submitted to the TLS working group and
you would probably have to wait until the basic DANE architecture was
defined before that was practical.

On Tue, Dec 21, 2010 at 6:36 PM, Paul Wouters wrote:

> On Tue, 21 Dec 2010, Phillip Hallam-Baker wrote:
>
> One odd consequence of DNSSEC is that additional responses no longer get
>> us out of trouble as we might like. If we
>> have a general record RR-A and a protocol specific detail record RR-B, a
>> response containing RR-A and likely
>> relevant RR-B's will now contain two RRSIGs, which will likely bust the
>> packet length.
>>
>
> This is an argument in favour of merging the HASTLS and TLSA records,
> where the TLSA part becomes an optional part inside HASTLS. It would
> indeed save us an RRSIG (and an additional roundtrip, if we haven't
> optimised it yet)
>
> However, a TLSA record containing a full cert probably already busts
> the packet length, regardless of an extra RRSIG or two.
>
> When no CA's are used, a TLSA bare public key or hash would be smaller.
>
> Paul
>

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

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

Take a look at my proposal in the other thread, I think it meets your =
requirements.

If you really really want to put the=
key into the DNS, then this is how I would do it:

1) Put the raw key in the DNS

2) Sign with a RRSIG

3) W=
rite a note that states that this combination is directly equivalent to a P=
KIX certificate signed under the DNS ZSK with a subjectAltName of the corre=
sponding domain label.

But this combination would have to be submitted to the =
TLS working group and you would probably have to wait until the basic DANE =
architecture was defined before that was practical.=A0

On Tue, Dec 21, 2010 at 6:36=
PM, Paul Wouters <[email-masked]> wrote:

On Tue, 21 Dec 2010, Phillip Hallam-Baker wrote:

One odd consequence of DNSSEC is that additional responses no longer get us=
out of trouble as we might like. If we

have a general record RR-A and a protocol specific detail record RR-B, a re=
sponse containing RR-A and likely

relevant RR-B's will now contain two RRSIGs, which will likely bust the=
packet length.

This is an argument in favour of merging the HASTLS and TLSA records,

where the TLSA part becomes an optional part inside HASTLS. It would

indeed save us an RRSIG (and an additional roundtrip, if we haven't

optimised it yet)

However, a TLSA record containing a full cert probably already busts

the packet length, regardless of an extra RRSIG or two.

When no CA's are used, a TLSA bare public key or hash would be smaller.=

Paul

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

--001636920544df790a0497f033ca--

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A5063A6AA5 for ; Tue, 21 Dec 2010 10:34:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.588
X-Spam-Level:
X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 UTkG26oEUewI for ; Tue, 21 Dec 2010 10:34:50 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 770963A6A06 for ; Tue, 21 Dec 2010 10:34:50 -0800 (PST)
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 9DB08C4BE; Tue, 21 Dec 2010 13:36:44 -0500 (EST)
Date: Tue, 21 Dec 2010 13:36:44 -0500 (EST)
From: Paul Wouters
To: Phillip Hallam-Baker
In-Reply-To:
Message-ID:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: [email-masked], Paul Hoffman
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 21 Dec 2010 18:34:51 -0000

On Tue, 21 Dec 2010, Phillip Hallam-Baker wrote:

> One odd consequence of DNSSEC is that additional responses no longer get us out of trouble as we might like. If we
> have a general record RR-A and a protocol specific detail record RR-B, a response containing RR-A and likely
> relevant RR-B's will now contain two RRSIGs, which will likely bust the packet length.

This is an argument in favour of merging the HASTLS and TLSA records,
where the TLSA part becomes an optional part inside HASTLS. It would
indeed save us an RRSIG (and an additional roundtrip, if we haven't
optimised it yet)

However, a TLSA record containing a full cert probably already busts
the packet length, regardless of an extra RRSIG or two.

When no CA's are used, a TLSA bare public key or hash would be smaller.

Paul

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FBF53A6A94 for ; Tue, 21 Dec 2010 09:49:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.958
X-Spam-Level:
X-Spam-Status: No, score=-2.958 tagged_above=-999 required=5 tests=[AWL=-0.244, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, 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 sqvYTKdmimIw for ; Tue, 21 Dec 2010 09:48:59 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id EE5D83A6A75 for ; Tue, 21 Dec 2010 09:48:58 -0800 (PST)
Received: by ywk9 with SMTP id 9so2031689ywk.31 for ; Tue, 21 Dec 2010 09:50:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=2MrYay/haFuDL7eVoRO2xyqmM7KCnaJK7U9XWRmfb6Y=; b=sp0Hfvkz9yqjdiLJRXfhM/4qSxUZpIOf+87KMH0fF9RBsiRhedqEC1WeiAlnnuvqQJ nPdUZ491CM+pZXbartyTwFJ0A394JvN82RWjmfhNtxvmRzhc9RxNxE5OcBeQTMVUreM7 /vxdSXUtrAjAjIm0I0SF1N7UFFRC1Tpa2G9/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=AiiAna6o1fDL6wxG4jS65PsRoV/yXMrSwGr/BYvsnubtxu/gzF+1XVRkIH5/2ev6lu joWtj2VlQy1QWZuD4yb4j22sgkETC2ZB66v5YTyommGy6tVoBuYl1YI2nB8Fu2NGNvfS ta+1hIEF1d9HZKj66XCMQlMAQ6lNEKlQPWAgo=
MIME-Version: 1.0
Received: by 10.100.228.14 with SMTP id a14mr1961785anh.239.1292953854494; Tue, 21 Dec 2010 09:50:54 -0800 (PST)
Received: by 10.100.31.8 with HTTP; Tue, 21 Dec 2010 09:50:54 -0800 (PST)
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Tue, 21 Dec 2010 17:50:54 +0000
Message-ID:
From: Phillip Hallam-Baker
To: Paul Hoffman
Content-Type: multipart/alternative; boundary=0016e6d2767135478a0497ef4731
Cc: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 21 Dec 2010 17:49:00 -0000

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

That is true, we have two dimensions of choice. One is to specify protocols
by prefix or port. The other is to enumerate all the possible choices in one
record or to use a selector approach.

So we could have

1) example.com XXX "use TLS on port 80"
2) example.com XXX "use TLS for _http._tcp"
3) _80.example.com XXX "use TLS"
4) _http._tcp.example.com XXX "use TLS"
5) example.com XXX "look at protocol detail"

This has the following consequences:

1 & 2) We have a potential scaling problem if we have a very large site with
a large number of protocols. If we have 1000 Web services at example.com we
would have 1000 XXX records if this is the only option.

3 & 4) Will require 2 round trips to resolve in the general case since if
example.com is a CNAME, the prefix must be applied to the canonical.

5) Introduces some additional complexity to the code, but could perhaps be
tolerated. We only need perform detailed queries if we don't get what we
need in the first lookup.

One odd consequence of DNSSEC is that additional responses no longer get us
out of trouble as we might like. If we have a general record RR-A and a
protocol specific detail record RR-B, a response containing RR-A and likely
relevant RR-B's will now contain two RRSIGs, which will likely bust the
packet length.

Say we have:

example.com RR-A path qoweoqwiejoiwqejfo==
example.com RR-A detail protocol
_http._tcp.example.com RR-B tls required

The response for a query of RR-A on example.com would be:

example.com RR-A path qoweoqwiejoiwqejfo==
example.com RR-A detail protocol

[Additional]
example.com RRSIG(RR-A)
_http._tcp.example.com RR-B tls required
_http._tcp.example.com RRSIG(RR-B)

That gets close to the edge size-wise. And is going to get really, really
iffy if we are going to put host specific keys in the mix. We also have a
problem in that the authoritative server has to work out which protocol
records to send as additional RRs. The most requested RRs are not
necessarily the ones where we care about interactive response.

Another option would be to allow enumeration of the most likely to be
requested detail records at the general level:

example.com RR-A path qoweoqwiejoiwqejfo==
example.com RR-A detail protocol
example.com RR-A add [_http._tcp tls required]
_http._tcp.example.com RR-B tls required

The response then becomes:

example.com RR-A path qoweoqwiejoiwqejfo==
example.com RR-A detail protocol
example.com RR-A add [_http._tcp tls required]

[Additional]
example.com RRSIG(RR-a)

Which is likely to serve 99% of cases where a fast response was required.

Ideally, the DNS server is going to simplify administration by automatically
calculating the content of the add records to present.

The hybrid approach allows us the speed of single round trip response for
99% of lookups without introducing scale constraints.

On Tue, Dec 21, 2010 at 5:15 PM, Paul Hoffman wrote:

> At 11:32 AM +0000 12/21/10, Phillip Hallam-Baker wrote:
> >Architecturally, we have a choice between prefix by port and prefix by
> protocol.
>
> Or "port in the response". I'm not advocating for those, but they have been
> proposed as well.
>
>
> --Paul Hoffman, Director
> --VPN Consortium
>

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

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

That is true, we have two dimensions of choice. One is to specify protocols=
by prefix or port. The other is to enumerate all the possible choices in o=
ne record or to use a selector approach.=A0

So we could =
have=A0

1) example.com =A0 =
=A0 =A0 =A0 =A0 =A0 XXX "use TLS on port 80"

2) =
example.com =A0 =A0 =A0 =A0 =A0 =A0 XXX =
"use TLS for _http._tcp"

3) _80.example.com =A0 =A0 =A0 =
=A0 XXX "use TLS"

4) _http._tcp.example.com =A0XXX "use TLS"

5) example.com =A0 =A0 =A0 =A0 =A0 =
=A0 XXX "look at protocol detail"

This has the following consequences:

1 & 2) We have a potential scaling problem if we ha=
ve a very large site with a large number of protocols. If we have 1000 Web =
services at example.com we would have 10=
00 XXX records if this is the only option.

3 & 4) Will require 2 round trips to resolve in the=
general case since if example.com is a =
CNAME, the prefix must be applied to the canonical.

5) Introduces some additional complexity to the code, but could perhaps be =
tolerated. We only need perform detailed queries if we don't get what w=
e need in the first lookup.

One odd=
consequence of DNSSEC is that additional responses no longer get us out of=
trouble as we might like. If we have a general record RR-A and a protocol =
specific detail record RR-B, a response containing RR-A and likely relevant=
RR-B's will now contain two RRSIGs, which will likely bust the packet =
length.

Say we have:

example.com =A0 =A0 =A0 =A0 =A0 =A0 RR-A =A0 path qoweoqwiejoiwqejfo=
=3D=3D

=
example.com =A0 =A0 =A0 =A0 =A0 =A0 RR-A=
=A0 detail protocol

_http._tcp.example.com =A0RR-B =A0 tls required

The response for a query of RR-A on example.com would be:

example.com =A0 =A0 =A0=
=A0 =A0 =A0 RR-A =A0 path qoweoqwiejoiwqejfo=3D=3D

example.com =A0 =A0 =A0 =A0 =A0 =A0=
RR-A =A0 detail protocol

[Additional]

example.com =A0 =A0 =A0 =A0 =A0 =A0 RRSIG(RR-A)

_http._tcp.example.com =A0RR-B =
=A0 tls required

_http._tcp.example.com =A0RRSIG(RR-B)

That gets close to the edge size-wise. And is going to =
get really, really iffy if we are going to put host specific keys in the mi=
x. We also have a problem in that the authoritative server has to work out =
which protocol records to send as additional RRs. The most requested RRs ar=
e not necessarily the ones where we care about interactive response.

Another option would be to allow enumeration of the mos=
t likely to be requested detail records at the general level:

exa=
mple.com =A0 =A0 =A0 =A0 =A0 =A0 RR-A =A0 path qoweoqwiejoiwqejfo=3D=3D=

example.com =A0 =A0 =A0 =A0 =A0 =A0=
RR-A =A0 detail protocol

example.com =A0 =A0 =A0 =A0 =A0 =A0 RR-A =A0 ad=
d [_http._tcp tls required]

_http._tcp.example.com =A0RR-B =
=A0 tls required

The response then be=
comes:

example.com =A0 =A0 =A0 =A0 =A0 =A0 RR-A =A0 path qoweoqwiejoiwqej=
fo=3D=3D

=
example.com =A0 =A0 =A0 =A0 =A0 =A0 RR-A=
=A0 detail protocol

example.com =A0 =A0 =A0 =A0 =A0 =A0 RR-A =A0 add [_http._tcp=A0tls required]

[Additional]

=
example.com =A0 =A0 =A0 =A0 =A0 =A0 RRSI=
G(RR-a)

Which is likely to serve 99% of cases where a fast respon=
se was required.

Ideally, the DNS server is going =
to simplify administration by automatically calculating the content of the =
add records to present.=A0

The hybrid approach allows us the speed of single round=
trip response for 99% of lookups without introducing scale constraints.

On Tue=
, Dec 21, 2010 at 5:15 PM, Paul Hoffman <[email-masked]> wrote:

At 11:32 AM +0000 12/21/1=
0, Phillip Hallam-Baker wrote:

>Architecturally, we have a choice between prefix by port and prefix by =
protocol.

Or "port in the response". I'm not advocating for those=
, but they have been proposed as well.

--Paul Hoffman, Director

--VPN Consortium

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

--0016e6d2767135478a0497ef4731--

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84C8B3A6B52 for ; Tue, 21 Dec 2010 09:45:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.982
X-Spam-Level:
X-Spam-Status: No, score=-1.982 tagged_above=-999 required=5 tests=[AWL=0.573, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044]
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-M7eo7C3UKJ for ; Tue, 21 Dec 2010 09:45:43 -0800 (PST)
Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by core3.amsl.com (Postfix) with ESMTP id 0C2333A6B54 for ; Tue, 21 Dec 2010 09:45:42 -0800 (PST)
Received: by eagle.jhcloos.com (Postfix, from userid 10) id BC98C40463; Tue, 21 Dec 2010 17:47:12 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1292953656; bh=9cl7elzSGR07TzgvMXct0WFqpA97WvBTesiqvrsXsx4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=txanS4a+SOw1/eI8UgWWemSS2MCZZTyLNuT8lrDuW+0Hk+ogbFTWfPZI+xJ0mgGWT ipt9XqTOhSxlQ0oU1A8q+m4k0/qA8BiYZX8F0kc5ms0caQs1tBiD5aA+fv8f80XYDX 32VIlf9kGj+vuObhUWvYfxakBisfLp6FWEv8vhCM=
Received: from carbon (localhost [127.0.0.1]) by carbon.jhcloos.org (Postfix) with ESMTP id 7E91E30002A; Tue, 21 Dec 2010 13:58:51 +0000 (UTC)
From: James Cloos
To: Paul Hoffman
In-Reply-To: (Paul Hoffman's message of "Mon\, 20 Dec 2010 08\:54\:15 -0800")
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux)
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABHNCSVQICAgIfAhkiAAAAI1J REFUOE+lU9ESgCAIg64P1y+ngUdxhl5H8wFbbM0OmUiEhKkCYaZThXCo6KE5sCbA1DDX3genvO4d eBQgEMaM5qy6uWk4SfBYfdu9jvBN9nSVDOKRtwb+I3epboOsOX5pZbJNsBJFvmQQ05YMfieIBnYX FK2N6dOawd97r/e8RjkTLzmMsiVgrAoEugtviCM3v2WzjgAAAABJRU5ErkJggg==
Copyright: Copyright 2009 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, 21 Dec 2010 08:58:51 -0500
Message-ID:
Lines: 10
MIME-Version: 1.0
Content-Type: text/plain
X-Hashcash: 1:30:101221:[email-masked]::fPr/mP9SbX7sWB3R:0000000000000000000000000000000000000002eJGq
X-Hashcash: 1:30:101221:[email-masked]::czp5quFUQeazDBEo:000000000000000000000000000000000000000000g1xZ5
X-Hashcash: 1:30:101221:[email-masked]::mpHqbBIRTXuW/VvP:00000000000000000000000000000000000000zCpBa
X-Hashcash: 1:30:101221:[email-masked]::u6oouowq5cGfYLGh:000000000000000000000000000000000000000000VjNQQ
Cc: [email-masked]
Subject: Re: [keyassure] TLSA and HASTLS
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 21 Dec 2010 17:45:44 -0000

>>>>> "PH" == Paul Hoffman writes:

PH> Just to be clear: are you are proposing DANE adding "bare public key"
PH> *before* any version of TLS allows that?

A bare public key is generally useful, and DANE shouldn't be just about TLS.

-JimC
--
James Cloos OpenPGP: 1024D/ED7DAEA6

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0383E3A6A8C for ; Tue, 21 Dec 2010 09:42:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.179
X-Spam-Level:
X-Spam-Status: No, score=-2.179 tagged_above=-999 required=5 tests=[AWL=0.420, 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 tT0bntR7RhXP for ; Tue, 21 Dec 2010 09:41:58 -0800 (PST)
Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by core3.amsl.com (Postfix) with ESMTP id 753C23A6B37 for ; Tue, 21 Dec 2010 09:41:58 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=G1tZqjNiPiuvh7I+llVhtLX/YWNa202x/qqmHDyqwIdR7nz00u5lCEJoDC/XMRWg; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.25] (helo=mswamui-backed.atl.sa.earthlink.net) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1PV6Fe-0007sN-Qt for [email-masked]; Tue, 21 Dec 2010 12:43:54 -0500
Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Tue, 21 Dec 2010 12:43:54 -0500
Message-ID: <[email-masked]>
Date: Tue, 21 Dec 2010 12:43:54 -0500 (EST)
From: "Jeffrey A. Williams"
To: "[email-masked]"
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e519606881110173ffd5508fd87ed7d62b56fa25f350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.25
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: "Jeffrey A. Williams"
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 21 Dec 2010 17:42:00 -0000

Paul and all,

-----Original Message-----
>From: Paul Hoffman
>Sent: Dec 20, 2010 11:30 PM
>To: Matt McCutchen
>Cc: [email-masked]
>Subject: Re: [keyassure] HTTPS -> HTTP downgrade
>
>At 9:47 PM -0500 12/20/10, Matt McCutchen wrote:
>>I would argue that if http://foo:80 is just a redirection to
>>https://foo:443, that is not really "service" in the sense envisioned by
>>draft-hoffman-server-has-tls and hence it is not a lie to specify "0
>>443".
>
>It *is* a lie because you control the redirection. The semantics of "0 443" are "if you find a responder at port 80, it isn't me, and you are probably getting scammed". If, insetad, you announced "80 443" and did a redirect as above, it is not at all a lie.
>
>>The effect is really the same as that described for an SSO for a
>>protocol that uses in-band security update, except that the "band"
>>consists of two ports.
>
>...and, as you say, something that is not a service.
>
>>The more controversial case is when the server offers real service on
>>both http://example.com:80 and https://example.com:443 .
>
>Something on 80 that redirects to 443 *is* a real service in every sense of the word.
>
>>I think the
>>real question here is who gets blamed if the desired level of security
>>is not achieved. In some cases there's only one party that can be
>>blamed (e.g., if one side leaks the master key or the client accepts an
>>invalid PKIX certificate or DNSSEC chain). Beyond that, it's a gray
>>area and I'm having difficulty formulating any coherent statement, so I
>>will stop here.
>
>The real question, one that will be addressed in both DANE and WEBSEC, is whether it is reasonable to say "I speak on port 80 but you MUST use 443 instead, even if you wanted to do port 80". If you can come up with non-silly semantics for that without obvious problems, the WGs might buy it. I'm skeptical, though; I see many reasons for a client to say "I know 443 is going to fail me, so I'm willing to fall back to 80". The most obvious example is "you're using a CA who I don't trust, so I'm going to fail during the TLS handshake".

Your last statement/sentance here is what is of the most importance
IMO. We all know but are often times reluctant to directly mention
that there are some and/or few CA's that may be questionable and
that ALL CA's from time to time inadvertantly or otherwise loose some
level of control of integraty of their key database for any number
of reasons. Question(s) then become how to deal with such effectively?
>
>--Paul Hoffman, Director
>--VPN Consortium
>_______________________________________________
>keyassure mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/keyassure

Kindest regards,
Jeffrey A. Williams
"Obedience of the law is the greatest freedom" -
Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
Network security Eng. SR. Eng. Network data security,
IT/information security.
ABA member in good standing member ID 01257402
E-Mail [email-masked]
Phone: 214-244-4827

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3EF73A6A69 for ; Tue, 21 Dec 2010 09:33:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kfv7TP1SggNt for ; Tue, 21 Dec 2010 09:33:11 -0800 (PST)
Received: from homiemail-a60.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by core3.amsl.com (Postfix) with ESMTP id DFB903A6A2E for ; Tue, 21 Dec 2010 09:33:11 -0800 (PST)
Received: from homiemail-a60.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a60.g.dreamhost.com (Postfix) with ESMTP id 4F2363BC06C; Tue, 21 Dec 2010 09:35:08 -0800 (PST)
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=hDywQocHPTejmp2KgdEknMY5KS0sNN/5G3kzrc7gbIv 16npCkUfvHaCoFjgwFwDP6BOI7WE3ThDek6WlULucvuGd7/XaAABUzUHHMH96iei wJb8aELkg36AQflkWzIipO6etvCVBVdbSSSnld3K3yIqeBWw7rWFzYDz95PBezMk =
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=Qx+KxxodH4JVPGhhVsXLyTCMs4U=; b=nRGeMsu84U GbtDtvajgPmg+dmgOOh3tL35fesnpEYA7oW//kcYMoGQbD9lHg1lXvkTwAjDzzDM 1O6MKIvbu49JNWkcFOIMuN84knDjMp6bNNS52Ih/SC8Axn8r7upZ6c5iep403JHG 97bb6WHn03wfbU5CMBiIFPiYKtdoHQ26I=
Received: from [192.168.1.40] (pool-96-231-10-176.washdc.east.verizon.net [96.231.10.176]) (Authenticated sender: [email-masked]) by homiemail-a60.g.dreamhost.com (Postfix) with ESMTPA id D55043BC06B; Tue, 21 Dec 2010 09:35:07 -0800 (PST)
From: Matt McCutchen
To: Paul Hoffman
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 21 Dec 2010 12:35:06 -0500
Message-ID: <[email-masked]>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.1
Content-Transfer-Encoding: 7bit
Cc: [email-masked]
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 21 Dec 2010 17:33:12 -0000

On Tue, 2010-12-21 at 09:03 -0800, Paul Hoffman wrote:
> At 12:43 AM -0500 12/21/10, Matt McCutchen wrote:
> >On Mon, 2010-12-20 at 20:30 -0800, Paul Hoffman wrote:
> >> The real question, one that will be addressed in both DANE and WEBSEC,
> >> is whether it is reasonable to say "I speak on port 80 but you MUST
> >> use 443 instead, even if you wanted to do port 80". If you can come up
> >> with non-silly semantics for that without obvious problems, the WGs
> >> might buy it. I'm skeptical, though; I see many reasons for a client
> >> to say "I know 443 is going to fail me, so I'm willing to fall back to
> >> 80". The most obvious example is "you're using a CA who I don't trust,
> >> so I'm going to fail during the TLS handshake".
> >
> >If http://foo:80 is just a redirection to https://foo:443, then it is
> >quite reasonable because all that falling back to http://foo:80 buys you
> >is the possibility of getting attacked.
>
> Quite right.

So how is that expressed in HASTLS? I was proposing "0 443", but you
said that was a lie. I think this was the only place we disagreed.

--
Matt

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E45BD3A6A72 for ; Tue, 21 Dec 2010 09:14:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.602
X-Spam-Level:
X-Spam-Status: No, score=-101.602 tagged_above=-999 required=5 tests=[AWL=0.444, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 eWihVEXGKOXs for ; Tue, 21 Dec 2010 09:14:02 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 38B213A67FA for ; Tue, 21 Dec 2010 09:14:02 -0800 (PST)
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 oBLHFtFA013276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Dec 2010 10:15:56 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Tue, 21 Dec 2010 09:15:54 -0800
To: Phillip Hallam-Baker , Matt McCutchen
From: Paul Hoffman
Content-Type: text/plain; charset="us-ascii"
Cc: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 21 Dec 2010 17:14:03 -0000

At 11:32 AM +0000 12/21/10, Phillip Hallam-Baker wrote:
>Architecturally, we have a choice between prefix by port and prefix by protocol.

Or "port in the response". I'm not advocating for those, but they have been proposed as well.

--Paul Hoffman, Director
--VPN Consortium

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E91B53A6A6D for ; Tue, 21 Dec 2010 09:08:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.398
X-Spam-Level:
X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[AWL=0.200, 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 PQ2fp6UYEsT1 for ; Tue, 21 Dec 2010 09:08:57 -0800 (PST)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 0CD633A67E3 for ; Tue, 21 Dec 2010 09:08:56 -0800 (PST)
Received: by yxt33 with SMTP id 33so2007225yxt.31 for ; Tue, 21 Dec 2010 09:10:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=jpotqZvfzyzhJJXi33/6GVT8F2/5qR/uvEjgp0farGE=; b=NtDSNxrEX7CiWf9tM/zevnJf4MiXS5NUdubzRLXNvP/XNcncTvQ1QXuvP6wWM7q5LW pmxkzdvrYLDPU6c67855lor4V6Md+W/kCJ37qGlz2XY0TYJXZ0IBjP0QZ6XnEZomSbGb KEG8A+X8HTvsWrYSsCDyBZpEG4EWf/IDhmbfY=
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=DDIzkgHoB38D4thVURmNu6Wm7Wo65+FQ6DnM0TSYw4dsW90keMuo+MKz0RpIiJB0VA L4anB1ZJNLgrz07dXJzo0hEz3NwQ2hM+t6zA0tyCZ30Kioj0IgmIyeVfLOHR75L46EHr A39OmhZoPffrbi1dB8xAjfeq+MzFtjzCHATvI=
MIME-Version: 1.0
Received: by 10.100.96.1 with SMTP id t1mr3470744anb.137.1292951453027; Tue, 21 Dec 2010 09:10:53 -0800 (PST)
Received: by 10.100.31.8 with HTTP; Tue, 21 Dec 2010 09:10:52 -0800 (PST)
In-Reply-To: <[email-masked]>
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]>
Date: Tue, 21 Dec 2010 17:10:52 +0000
Message-ID:
From: Phillip Hallam-Baker
To: Matt McCutchen
Content-Type: multipart/alternative; boundary=0016e644caf011cf110497eeb88e
Cc: [email-masked]
Subject: Re: [keyassure] TLSA and HASTLS
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 21 Dec 2010 17:08:59 -0000

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

On Tue, Dec 21, 2010 at 4:43 PM, Matt McCutchen wrote:

> On Tue, 2010-12-21 at 12:28 +0000, Phillip Hallam-Baker wrote:
> > On Tue, Dec 21, 2010 at 4:07 AM, Matt McCutchen
> > wrote:
> > - When TLSA of type 3 or 4 is used, what reference
> > identifier(s) are
> > used for the server ID check?
> >
> >
> > It really depends on what you are going to do. If it is just turn on
> > TLS on a http lookup and not mention it to anyone, that is always
> > going to reduce the sope for the attack. If it is going to be to tell
> > the user 'hey you are safe, this is definitely PayPal Inc., and slap
> > the logo on the screen, well we have problems.
>
> I'm trying to handle a request for https://example.com, which could have
> been manually typed or from a bookmark or another site. This needs to
> have strong semantics for the reasons described at
> https://bugzilla.mozilla.org/show_bug.cgi?id=327181#c14 .

I would break this down as follows:

1) https is indicated, therefore we have a 'must use TLS' condition.

My current feeling here is that it should not matter how the 'must use'
condition is specified, they all have equal weight. In the past though I did
think that maybe the user typing in https had a stronger weight than
following something from a bookmark.

2) If the lookup is flagged 'MUST use TLS' then we have to have a strong
binding that links the original target domain to the key.

This could be any of the following:

* CA issued certificate under embedded root for example.com (domain can be
canonical or aliased to anywhere, it does not matter)

* CA issued certificate under embedded root for example.net plus a CNAME
with valid RRSIG for example.com -> example.net

* key asserted as valid at example.com with valid RRSIG (domain cannot be
aliased as there is a RR at example.com)

* key asserted as valid at example.net with valid RRSIG plus a CNAME with
valid RRSIG for example.com -> example.net

* path asserted as valid at example.com with valid RRSIG (domain cannot be
aliased)

* path asserted as valid at example.net with valid RRSIG plus a CNAME with
valid RRSIG for example.com -> example.net

Now we might want to consider whether we would really want to accept each
one of these cases and if we would want to put in additional considerations
in addition.

If the example given was www.example.com, I would be much happier about
using a certificate for example.com.

And this is looking at the problem only from the perspective of Web lookups.
If there was actual money involved (say we are talking about deep e-commerce
and transactional services) then I would probably have a stronger condition
on the 'valid RRSIG' than merely 'chains to ICANN root'. I would probably
want both trust paths to meet the necessary requirements for the transaction
(which I presume ICANN does not intend to warranty). Although only one path
would actually require insurance.

At some point we would have to think about whether it would be possible to
accept DNSSEC validated RRSIGs in an EV cert chain and if so whether the
ICANN chain would be sufficient or whether that would also require EV
backing.

> - Early on, you pointed out that CERT RRs of existing types do
> > not offer
> > an assurance and therefore we need something different. The
> > same is
> > true of CNAME.
> >
> >
> > CNAME does make an assertion that 'this name is equivalent to that
> > name'. If we respect that, I think we are OK.
>
> /At the DNS level/. Traditionally, if www.google.com is a CNAME to
> www.l.google.com, the reference identifier for the server ID check is
> still www.google.com. We would be changing that and effectively
> assuming that the target of the CNAME is trusted to use certificates in
> its own name, not just to resolve to the right IP address. That may be
> OK, but it deserves some thought.
>

Again we have to work around some of the limitations of the TLS protocol,
one of which is that the target host does not know the domain name until
after the connection has been completed. I know that there is a fix in the
works for this, but it is not fully deployed yet.

We have in the past been considering CNAMEs as merely DNS level plumbing.
Which is of course all you can do when you can't trust the data from DNS.

Once you can trust the data from DNS, things become rather interesting.
Particularly since you now have (potentially) two separate trust chains to
consider.

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

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

On Tue, Dec 21, 2010 at 4:43 PM, Matt Mc=
Cutchen <mat=
[email-masked]> wrote:

On Tue, 2010-12-21 at 12:28 +0000, Phillip Hallam-Baker w=
rote:

> On Tue, Dec 21, 2010 at 4:07 AM, Matt McCutchen

> <[email-masked]> wrote:

> =A0 =A0 =A0 =A0 - When TLSA of type 3 or 4 is =
used, what reference

> =A0 =A0 =A0 =A0 identifier(s) are

> =A0 =A0 =A0 =A0 used for the server ID check?

>

>

> It really depends on what you are going to do. If it is just turn on
> TLS on a http lookup and not mention it to anyone, that is always

> going to reduce the sope for the attack. If it is going to be to tell<=
br>
> the user 'hey you are safe, this is definitely PayPal Inc., and sl=
ap

> the logo on the screen, well we have problems.

I'm trying to handle a request for https://example.com, which could have

been manually typed or from a bookmark or another site. =A0This needs to
have strong semantics for the reasons described at

https://bugzilla.mozilla.org/show_bug.cgi?id=3D327181#c14 =
.

I would break this down as=
follows:

1) https is indicated, therefore we have a 'must us=
e TLS' condition.

My current feeling here is t=
hat it should not matter how the 'must use' condition is specified,=
they all have equal weight. In the past though I did think that maybe the =
user typing in https had a stronger weight than following something from a =
bookmark.

2) If the lookup is flagged 'MUST use TLS' then=
we have to have a strong binding that links the original target domain to =
the key.

This could be any of the following:

* CA issued certificate under embedded r=
oot for example.com (domain can be canon=
ical or aliased to anywhere, it does not matter)

* CA issued certificate under embedded root for example.net plus a CNAME with valid RRSIG for example.com -> example.net<=
/a>

* key asserted as valid at example.com with valid RRSIG (domain cannot be aliased as there is a=
RR at example.com)

* key asserted as valid at example.net with valid RRSIG=A0plus a CNAME with valid RRSI=
G for example.com -> example.net

* path asserted =A0as valid at =
example.com with valid RRSIG (domain can=
not be aliased)

*=A0path a=
sserted =A0as valid at example.net with =
valid RRSIG=A0plus a CNAME with valid RRSIG for example.com -> example.net

Now we might want to consider whether we would really want to accep=
t each one of these cases and if we would want to put in additional conside=
rations in addition.

If the example given was www.example.com, I would be much happier about using a certificate=
for example.com.

And this is looking at the problem only from the perspective=
of Web lookups. If there was actual money involved (say we are talking abo=
ut deep e-commerce and transactional services) then I would probably have a=
stronger condition on the 'valid RRSIG' than merely 'chains to=
ICANN root'. I would probably want both trust paths to meet the necess=
ary requirements for the transaction (which I presume ICANN does not intend=
to warranty). Although only one path would actually require insurance.

At some point we would have to think about whether it w=
ould be possible to accept DNSSEC validated RRSIGs in an EV cert chain and =
if so whether the ICANN chain would be sufficient or whether that would als=
o require EV backing.

> =A0 =A0 =A0 =A0 - Early on, you pointed out that CERT RRs of existing =
types do

> =A0 =A0 =A0 =A0 not offer

> =A0 =A0 =A0 =A0 an assurance and therefore we need something different=
. =A0The

> =A0 =A0 =A0 =A0 same is

> =A0 =A0 =A0 =A0 true of CNAME.

>

>

> CNAME does make an assertion that 'this name is equivalent to that=

> name'. If we respect that, I think we are OK.

/At the DNS level/. =A0Traditionally, if www.google.com is a CNAME to

www.l.google.com,=
the reference identifier for the server ID check is

still www.google.com. =A0We would be changing that and effectively

assuming that the target of the CNAME is trusted to use certificates in

its own name, not just to resolve to the right IP address. =A0That may be
OK, but it deserves some thought.

Again=
we have to work around some of the limitations of the TLS protocol, one of=
which is that the target host does not know the domain name until after th=
e connection has been completed. I know that there is a fix in the works fo=
r this, but it is not fully deployed yet.

We have in the past been considering CNAMEs as merely D=
NS level plumbing. Which is of course all you can do when you can't tru=
st the data from DNS.

Once you can trust the data =
from DNS, things become rather interesting. Particularly since you now have=
(potentially) two separate trust chains to consider.

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

--0016e644caf011cf110497eeb88e--

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 238663A67E3 for ; Tue, 21 Dec 2010 09:01:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.599
X-Spam-Level:
X-Spam-Status: No, score=-101.599 tagged_above=-999 required=5 tests=[AWL=0.447, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 fkVXANvD-5Ax for ; Tue, 21 Dec 2010 09:01:09 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id CA69B3A67FA for ; Tue, 21 Dec 2010 09:01:09 -0800 (PST)
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 oBLH34Rq012755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Dec 2010 10:03:05 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To: <[email-masked]>
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Tue, 21 Dec 2010 09:03:03 -0800
To: Matt McCutchen
From: Paul Hoffman
Content-Type: text/plain; charset="us-ascii"
Cc: [email-masked]
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 21 Dec 2010 17:01:11 -0000

At 12:43 AM -0500 12/21/10, Matt McCutchen wrote:
>On Mon, 2010-12-20 at 20:30 -0800, Paul Hoffman wrote:
>> At 9:47 PM -0500 12/20/10, Matt McCutchen wrote:
>> >I would argue that if http://foo:80 is just a redirection to
>> >https://foo:443, that is not really "service" in the sense envisioned by
>> >draft-hoffman-server-has-tls and hence it is not a lie to specify "0
>> >443".
>>
>> It *is* a lie because you control the redirection. The semantics of "0
>> 443" are "if you find a responder at port 80, it isn't me, and you are
>> probably getting scammed". If, insetad, you announced "80 443" and did
>> a redirect as above, it is not at all a lie.
>
>I guess you get to state the intended semantics of your draft, and then
>I'm left to submit a different one.

Indeed. That way, the WG can decide which it prefers. We don't have a WG yet, and we should probably try to get one soon so we can nail down the desired semantics.

> > The real question, one that will be addressed in both DANE and WEBSEC,
>> is whether it is reasonable to say "I speak on port 80 but you MUST
>> use 443 instead, even if you wanted to do port 80". If you can come up
>> with non-silly semantics for that without obvious problems, the WGs
>> might buy it. I'm skeptical, though; I see many reasons for a client
>> to say "I know 443 is going to fail me, so I'm willing to fall back to
>> 80". The most obvious example is "you're using a CA who I don't trust,
>> so I'm going to fail during the TLS handshake".
>
>If http://foo:80 is just a redirection to https://foo:443, then it is
>quite reasonable because all that falling back to http://foo:80 buys you
>is the possibility of getting attacked.

Quite right.

>Upon further reflection, I agree that when they both provide the
>service, the MUST is not right. The client can choose at its own risk.
>The trouble is that most of the public is ill equipped to make this
>choice and expects to be able to type mybank.com into a mainstream
>browser and blame the browser or the site if anything bad happens. So I
>propose that the DNS contain a hint, "users typically want strong
>confidentiality and/or integrity with this service", which mainstream
>browsers would honor by default but advanced users could override. The
>point being that a site that sets the hint cannot be blamed if a client
>uses the non-TLS service and gets attacked.

That type of advice can certainly be added if the WG wants.

>I'm not sure if the TLS hint is appropriate for IETF standardization or
>would just be a convention among the browsers and sites that have to
>cope with user expectations. But I think it is really what sites want
>(at least it's what I want), not HASTLS.

It is certainly worth discussing, however, in case we want to add something to the document.

--Paul Hoffman, Director
--VPN Consortium

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA4173A6A68 for ; Tue, 21 Dec 2010 08:55:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.596
X-Spam-Level:
X-Spam-Status: No, score=-101.596 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 5fwCvtxg8rMV for ; Tue, 21 Dec 2010 08:55:16 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 20E593A6A55 for ; Tue, 21 Dec 2010 08:55:16 -0800 (PST)
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 oBLGvAbi012448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Dec 2010 09:57:12 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Tue, 21 Dec 2010 08:57:09 -0800
To: Paul Wouters
From: Paul Hoffman
Content-Type: text/plain; charset="us-ascii"
Cc: [email-masked]
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 21 Dec 2010 16:55:16 -0000

At 12:22 AM -0500 12/21/10, Paul Wouters wrote:
>On Mon, 20 Dec 2010, Paul Hoffman wrote:
>
>>The real question, one that will be addressed in both DANE and WEBSEC, is whether it is reasonable to say "I speak on port 80 but you MUST use 443 instead, even if you wanted to do port 80". If you can come up with non-silly semantics for that without obvious problems, the WGs might buy it. I'm skeptical, though; I see many reasons for a client to say "I know 443 is going to fail me, so I'm willing to fall back to 80".
>
>You can't. sslstrip made that inheritantly unsafe.

We are talking past each other here. You want to only support one model (the one that cannot be circumvented by sslstrip) and completely prevent users from getting to port 80. I want to let the user choose what they should do, even if it is unsafe, *as long as* they can know securely what the system is hosting.

You believe that users will take your forced approach, and I do not. If you're right, great: they'll be safer. If you're wrong, we have done nothing for them.

>>The most obvious example is "you're using a CA who I don't trust, so I'm going to fail during the TLS handshake".
>
>How would a fallback in this case ever be safer?

Please do not put words in my mouth: I never said it would be "safer". However, we have over a decade of experience showing that they want to do it and will ignore anything we put in front of them.

For me, the question is whether we give them better information or not. For you, it is whether we force them to be safe even though they might just turn off the new "feature".

--Paul Hoffman, Director
--VPN Consortium

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 816FD3A6A53 for ; Tue, 21 Dec 2010 08:41:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdQolyxFGYru for ; Tue, 21 Dec 2010 08:41:10 -0800 (PST)
Received: from homiemail-a3.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by core3.amsl.com (Postfix) with ESMTP id 76D5B3A67E3 for ; Tue, 21 Dec 2010 08:41:10 -0800 (PST)
Received: from homiemail-a3.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a3.g.dreamhost.com (Postfix) with ESMTP id AAD63284078; Tue, 21 Dec 2010 08:43:06 -0800 (PST)
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=vpPjyDvPg8TzQ/pv3AlO4DUTZzI/pkGBLaegJG89vSE MAiOZxbUFIHai7ZqsoEAZJyhGHSBGNAcDiT9SdKTJTephLClFQbgqzkdVgVh65cx 3zGwq6sppQ6yMNGLREW9u9D+A1Bb6okwmO0fd/XkTwvophOcNH7c1kmmTzumfeuw =
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=fHW7YCrfmWIuG/3MRzerb0q/rJQ=; b=mO55ijS4dZ Hyy9ykyJBUwwqYBsl0ZPvzPuVtsaZId2kTSA3bVqd2/xfoVUIVh5gv/DpirWFb98 Zp+jvdMrxwn4WCmBqcwLYbxeXhAcCMtapsPeiXP9oZBjEdV2zHFHBzwpZJMth+3e hctYajEOXRMpPs5e7bFroVlDbsa1u5XNQ=
Received: from [192.168.1.40] (pool-96-231-10-176.washdc.east.verizon.net [96.231.10.176]) (Authenticated sender: [email-masked]) by homiemail-a3.g.dreamhost.com (Postfix) with ESMTPA id 36F1D284071; Tue, 21 Dec 2010 08:43:06 -0800 (PST)
From: Matt McCutchen
To: Phillip Hallam-Baker
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]>
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 21 Dec 2010 11:43:04 -0500
Message-ID: <[email-masked]>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.1
Content-Transfer-Encoding: 7bit
Cc: [email-masked]
Subject: Re: [keyassure] TLSA and HASTLS
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 21 Dec 2010 16:41:11 -0000

On Tue, 2010-12-21 at 12:28 +0000, Phillip Hallam-Baker wrote:
> On Tue, Dec 21, 2010 at 4:07 AM, Matt McCutchen
> wrote:
> - When TLSA of type 3 or 4 is used, what reference
> identifier(s) are
> used for the server ID check?
>
>
> It really depends on what you are going to do. If it is just turn on
> TLS on a http lookup and not mention it to anyone, that is always
> going to reduce the sope for the attack. If it is going to be to tell
> the user 'hey you are safe, this is definitely PayPal Inc., and slap
> the logo on the screen, well we have problems.

I'm trying to handle a request for https://example.com, which could have
been manually typed or from a bookmark or another site. This needs to
have strong semantics for the reasons described at
https://bugzilla.mozilla.org/show_bug.cgi?id=327181#c14 .

> - Early on, you pointed out that CERT RRs of existing types do
> not offer
> an assurance and therefore we need something different. The
> same is
> true of CNAME.
>
>
> CNAME does make an assertion that 'this name is equivalent to that
> name'. If we respect that, I think we are OK.

/At the DNS level/. Traditionally, if www.google.com is a CNAME to
www.l.google.com, the reference identifier for the server ID check is
still www.google.com. We would be changing that and effectively
assuming that the target of the CNAME is trusted to use certificates in
its own name, not just to resolve to the right IP address. That may be
OK, but it deserves some thought.

--
Matt

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B4223A67E5 for ; Tue, 21 Dec 2010 08:23:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.396
X-Spam-Level:
X-Spam-Status: No, score=-3.396 tagged_above=-999 required=5 tests=[AWL=0.202, 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 wwk2m+Fn2uJI for ; Tue, 21 Dec 2010 08:23:08 -0800 (PST)
Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by core3.amsl.com (Postfix) with ESMTP id B0D253A6B13 for ; Tue, 21 Dec 2010 08:23:08 -0800 (PST)
Received: by gxk8 with SMTP id 8so1877247gxk.27 for ; Tue, 21 Dec 2010 08:25:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=y9/XC+Q4iYGUWpf0n5tRdjjhzkcl6k7scLVf06VnhWQ=; b=AYkzogSjqT4Bl1UfpyPISqz9K90C+PzH0yEw61ndOgn6hwXUJ20Z8INo6gmgXafftb 0N18NaheL5Pdfzi01+1mcsWBCqsaAHtcpPeTEwTCpCSM2p9WcGHaR8WkpyZ0uC0wo8Fe iQ5lfq+nuUKldKHEeZOnR1my8sasLAAihTUSM=
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=Wiw9E2GbO1oBiW3IxkDgLyypGzb3lFwJjXk7gcE9jyMYEfVBMJ6uAatEi6LaSZ5HZQ wirETIOYxA4PA8Ra5cpC6oKE+QLfFCXERj2L7t4yyvn4gH2x2Vd0oj6FmwNkrzk43sUW 7ggZSaMkd1MKjlrx0YD5xDpDoRVEjlEx/rUsQ=
MIME-Version: 1.0
Received: by 10.100.93.11 with SMTP id q11mr1871506anb.35.1292948704559; Tue, 21 Dec 2010 08:25:04 -0800 (PST)
Received: by 10.100.31.8 with HTTP; Tue, 21 Dec 2010 08:25:04 -0800 (PST)
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]>
Date: Tue, 21 Dec 2010 16:25:04 +0000
Message-ID:
From: Phillip Hallam-Baker
To: Paul Wouters
Content-Type: multipart/alternative; boundary=0016e642d3883f84db0497ee14b5
Cc: [email-masked]
Subject: Re: [keyassure] TLSA and HASTLS
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 21 Dec 2010 16:23:10 -0000

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

Making it work should always take precedence over an extra DNS round trip.

And arguments attempting to rule out an approach due to performance
considerations should be backed up by actual figures.

It is really very easy to eliminate the DNS round trips and get all the
information required in a single request/response. But that is an
optimization.

It is pretty easy to make something efficient by deciding on one particular
set of circumstances that you are going to support and drive away anyone who
has other ideas from the working group by saying that they are off topic.

The result of that type of behavior is that the protocol stack acquires a
series of special cases that have to be accounted for and worked round in
future designs.

The complete session setup here is going to involve (some) DNS round trips
(some) Digital Signature verifications, a TCP connection setup, a PKI cert
chain construction and verification and a TLS session initiation.

In most cases we can run the network and processing in parallel. I am also
working to design the stack in such a way that the resolver can work
intelligently and pre-fetch as much data as possible. Whether or not we
trust the path that the resolver builds, we want it to be able to do as much
work on our behalf so that all that the endpoint need ever do is verify the
path math.

Since we are about to do a public key exchange protocol, the cost of an
extra DNS round trip is not going to be my primary concern performance wise.
In fact I think you will find that the performance impact is rather minimal
if the code begins fetching the next group of records as it verifies the
signatures on the last ones:

So assuming that we have protocol level detail on http lookup for
www.example.com, the discovery process is going to be:

Phase 1:
Send requests out for A, AAAA and RR-A records on www.example.com. Since
we do not know whether www.example.com is canonical or wildcarded at this
point, we cannot use prefixes.

Phase 2a:
As soon as the first response is received, we know if the target domain
is an alias or canonical. We can thus begin the request for the _http._tcp
RR-B and then start verification of the sigs on the first set of records. We
have a minimum of 2.

Phase 3:
Depending on the relative speed of our machine and our DNS server, we
will receive our protocol specific RR-B result back before or after the
signature verification completes.

On my office setup, the DNS server responds faster, here in the UK, the
Public Key completes first. We really need some timing tests before we
commit to an approach here.

Counter-intuitively, the three step discovery process does not incur any
additional performance penalty over the two step. This is because setting up
a TCP/IP connection is a multi-round trip affair and we can start
constructing the TCP/IP socket as soon as we know the IP address and port.
We do not have to wait to know the protocol options unless there is a reason
to do so.

And all of this is without going a step further and using meta-queries or
DPLS.

I have really not looked into the optimization of the discovery stage in
great detail because I know that it is possible to make browsers using the
full extended protocol discovery mechanism work considerably faster than the
current one.

If we care about performance, lets design a system that allows us to drop in
a geo-location balanced discovery mechanism. Then the browser goes to the
best service automatically.

On Tue, Dec 21, 2010 at 3:15 PM, Paul Wouters wrote:

> On Tue, 21 Dec 2010, Phillip Hallam-Baker wrote:
>
> So if we have a generic domain-wide property stating 'TLS always offered',
>> this might be overridden for specific
>> protocols to state 'TLS must be used' or 'TLS not supported'.
>>
>
> That requires more queries though to find out the particular policy if you
> don't find it at
> the host, and after getting a NXDOMAIN you'd have to go look at the domain.
> Is it worth the
> extra query? Especially if we need separate records for the pubkey for each
> host anyway, it
> makes more sense to just bundle the "https preference" in that record.
>
> Paul
>

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

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

Making it work should always take precedence over an extra DNS round trip.<=
div>

And arguments attempting to rule out an approach due to =
performance considerations should be backed up by actual figures.

It is really very easy to eliminate the DNS round trips and =
get all the information required in a single request/response. But that is =
an optimization.=A0

It is pretty ea=
sy to make something efficient by deciding on one particular set of circums=
tances that you are going to support and drive away anyone who has other id=
eas from the working group by saying that they are off topic.

The result of that type of behavior is that the protoco=
l stack acquires a series of special cases that have to be accounted for an=
d worked round in future designs.

The complete session setup here is =
going to involve (some) DNS round trips (some) Digital Signature verificati=
ons, a TCP connection setup, a PKI cert chain construction and verification=
and a TLS session initiation.

In most cases we can run the network and processing in =
parallel. I am also working to design the stack in such a way that the reso=
lver can work intelligently and pre-fetch as much data as possible. Whether=
or not we trust the path that the resolver builds, we want it to be able t=
o do as much work on our behalf so that all that the endpoint need ever do =
is verify the path math.

Since we are about to do a public =
key exchange protocol, the cost of an extra DNS round trip is not going to =
be my primary concern performance wise. In fact I think you will find that =
the performance impact is rather minimal if the code begins fetching the ne=
xt group of records as it verifies the signatures on the last ones:

So assuming that we have protocol level detail on http =
lookup for www.example.com, the disc=
overy process is going to be:

Phase 1:

=A0=A0 Send requests out for A, AAAA and RR-A records on www.example.com. Since we do not know whether www.example.com is canonical or wildcarded =
at this point, we cannot use prefixes.

Phase 2a:

=A0=A0 As soon as the first respons=
e is received, we know if the target domain is an alias or canonical. We ca=
n thus begin the request for the _http._tcp RR-B and then start verificatio=
n of the sigs on the first set of records. We have a minimum of 2.

Phase 3:

=A0=A0 Depending on the relative spe=
ed of our machine and our DNS server, we will receive our protocol specific=
RR-B result back before or after the signature verification completes.=A0<=
/div>

On my office setup, the DNS server responds faster, her=
e in the UK, the Public Key completes first. We really need some timing tes=
ts before we commit to an approach here.

Counter-intuitively, the three step discovery process does not incur a=
ny additional performance penalty over the two step. This is because settin=
g up a TCP/IP connection is a multi-round trip affair and we can start cons=
tructing the TCP/IP socket as soon as we know the IP address and port. We d=
o not have to wait to know the protocol options unless there is a reason to=
do so.

And all of this is without going a step =
further and using meta-queries or DPLS.=A0

I have =
really not looked into the=A0optimization=A0of the discovery stage in great=
detail because I know that it is possible to make browsers using the full =
extended protocol discovery mechanism work considerably faster than the cur=
rent one.

If we care about performance, lets design a system that=
allows us to drop in a geo-location balanced discovery mechanism. Then the=
browser goes to the best service automatically.=A0

On Tue, Dec 21, 2010 at 3:15 PM, Paul Wouter=
s <paul@xeleranc=
e.com> wrote:

On Tue, 21 Dec 2010, Phillip Hallam-Baker wrote:

So if we have a generic domain-wide property stating 'TLS always offere=
d', this might be overridden for specific

protocols to state 'TLS must be used' or 'TLS not supported'=
;.=A0

That requires more queries though to find out the particular policy if you =
don't find it at

the host, and after getting a NXDOMAIN you'd have to go look at the dom=
ain. Is it worth the

extra query? Especially if we need separate records for the pubkey for each=
host anyway, it

makes more sense to just bundle the "https preference" in that re=
cord.

Paul

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

--0016e642d3883f84db0497ee14b5--

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72A123A6A4A for ; Tue, 21 Dec 2010 07:13:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.587
X-Spam-Level:
X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 q0qf+jXvRogk for ; Tue, 21 Dec 2010 07:13:35 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id A41AA3A69EC for ; Tue, 21 Dec 2010 07:13:34 -0800 (PST)
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 008FFC4BE; Tue, 21 Dec 2010 10:15:28 -0500 (EST)
Date: Tue, 21 Dec 2010 10:15:27 -0500 (EST)
From: Paul Wouters
To: Phillip Hallam-Baker
In-Reply-To:
Message-ID:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT
Cc: [email-masked]
Subject: Re: [keyassure] TLSA and HASTLS
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 21 Dec 2010 15:13:36 -0000

On Tue, 21 Dec 2010, Phillip Hallam-Baker wrote:

> So if we have a generic domain-wide property stating 'TLS always offered', this might be overridden for specific
> protocols to state 'TLS must be used' or 'TLS not supported'.�

That requires more queries though to find out the particular policy if you don't find it at
the host, and after getting a NXDOMAIN you'd have to go look at the domain. Is it worth the
extra query? Especially if we need separate records for the pubkey for each host anyway, it
makes more sense to just bundle the "https preference" in that record.

Paul

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9567B3A69E0 for ; Tue, 21 Dec 2010 04:26:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.393
X-Spam-Level:
X-Spam-Status: No, score=-3.393 tagged_above=-999 required=5 tests=[AWL=0.205, 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 7SJjygMbew9j for ; Tue, 21 Dec 2010 04:26:18 -0800 (PST)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 214033A6869 for ; Tue, 21 Dec 2010 04:26:18 -0800 (PST)
Received: by yxt33 with SMTP id 33so1883034yxt.31 for ; Tue, 21 Dec 2010 04:28:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=M/9+wSTqAAYVeVQQeMIi0fHF2RMOO3Qj97/bZGKoKbA=; b=wGGbBI2fnYTg5OD5X7bXviuDQttJFMmKFnI3h4nGtlpv4QgGa46ar6Ys9PVKG+PimK 2loITfmcVdbrffeKXaGrwb5ZNBW8+9qLZ4KbfKM5szVVBsL24oKikvODeqBjRBK3cS0X LIZfPavHOS5zeeXx9/L1wKGBruZxLa09ZPkDc=
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=oZ+hM331PMxZDswHfsHHnZ5oV/z+9UliOagcNvce/TXznk5wadNiFnheCrBy3/nuyU Eny9TNryM+W33U8JAPFaw3wF0wma+bAWV/gv9YDICHkpSCZJt9YEClalTtNx9xh0fKjY fK73Ib7cDmsR+emKbF01DnoGMu3RZXSyMQFWA=
MIME-Version: 1.0
Received: by 10.100.122.9 with SMTP id u9mr3258648anc.171.1292934493606; Tue, 21 Dec 2010 04:28:13 -0800 (PST)
Received: by 10.100.31.8 with HTTP; Tue, 21 Dec 2010 04:28:13 -0800 (PST)
In-Reply-To: <[email-masked]>
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]>
Date: Tue, 21 Dec 2010 12:28:13 +0000
Message-ID:
From: Phillip Hallam-Baker
To: Matt McCutchen
Content-Type: multipart/alternative; boundary=0016e6407e8035949a0497eac5b6
Cc: [email-masked]
Subject: Re: [keyassure] TLSA and HASTLS
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 21 Dec 2010 12:26:19 -0000

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

On Tue, Dec 21, 2010 at 4:07 AM, Matt McCutchen wrote:

> On Mon, 2010-12-20 at 11:35 +0000, Phillip Hallam-Baker wrote:
> > I see a three layer scheme that allows for protocol information to be
> > expressed with increasing specificity as discovery progresses. [...]
>
> I like this scheme. There are just some details to fill in:
>
> - If information of the same type (e.g., TLSA) is specified at all three
> stages, how is it combined?
>

If there is a conflict, the most specific information should take priority,
which will also be the last returned.

So if we have a generic domain-wide property stating 'TLS always offered',
this might be overridden for specific protocols to state 'TLS must be used'
or 'TLS not supported'.

- When TLSA of type 3 or 4 is used, what reference identifier(s) are
> used for the server ID check?
>

It really depends on what you are going to do. If it is just turn on TLS on
a http lookup and not mention it to anyone, that is always going to reduce
the sope for the attack. If it is going to be to tell the user 'hey you are
safe, this is definitely PayPal Inc., and slap the logo on the screen, well
we have problems.

If there is a CNAME alias in the discovery chain it is going to have to be
authenticated with an RRSIG if we are going to be able to put any trust in a
key tied to the canonical.

- Early on, you pointed out that CERT RRs of existing types do not offer
> an assurance and therefore we need something different. The same is
> true of CNAME.

CNAME does make an assertion that 'this name is equivalent to that name'. If
we respect that, I think we are OK.

> > I would prefer a new meta query record that the server advertises
> > support for. This would be advertised as being supported using EDNS0
> > and would take an extensible tag-value separated list of properties.
> >
> >
> > MEGA-Q www.example.com _http._tcp
> > source-ip = 10.1.1.1
> > ipv6=yes
> >
> >
> > The reason for these additional parameter slots is that I would like
> > to introduce new and better discovery mechanisms over time.
>
> If we go this way, the (untrusted) DNS server will need to return all
> the RRsets that it checked (or their NSECs) so the client can verify
> that it executed the discovery process faithfully. If the server is not
> capable of returning everything the client wants, the client will end up
> pulling individual RRsets to avoid being downgraded. Still, we might
> hope to eliminate a round trip or two in the common case.
>
> (With an external resolver, these concerns apply only between the
> resolver and the DNS server.)
>

This gets tricky because the RRSIG records start to add up and we end up
needing multi-packet responses if we are not careful.

One way to adress this is to use a DPLS like approach where a DNS request is
always one packet but can lead to a multi-packet response.

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

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

On Tue, Dec 21, 2010 at 4:07 AM, Matt McCutchen <[email-masked]> =
wrote:

On Mon, 2010-12-20 at 11:35 +0000, Phillip Hallam-Baker w=
rote:

> I see a three layer scheme that allows for protocol information to be<=
br>

> expressed with increasing specificity as discovery progresses. [=
...]

I like this scheme. =A0There are just some details to fill in:

- If information of the same type (e.g., TLSA) is specified at all three
stages, how is it combined?

If there is=
a conflict, the most specific information should take priority, which will=
also be the last returned.

So if we have a generi=
c domain-wide property stating 'TLS always offered', this might be =
overridden for specific protocols to state 'TLS must be used' or &#=
39;TLS not supported'.=A0

- When TLSA of type 3 or 4 is used, what reference identifier(s) are

used for the server ID check?

It really=
depends on what you are going to do. If it is just turn on TLS on a http l=
ookup and not mention it to anyone, that is always going to reduce the sope=
for the attack. If it is going to be to tell the user 'hey you are saf=
e, this is definitely PayPal Inc., and slap the logo on the screen, well we=
have problems.

If there is a CNAME alias in the discovery chain it is =
going to have to be authenticated with an RRSIG if we are going to be able =
to put any trust in a key tied to the canonical.

- Early on, you pointed out that CERT RRs of existing types do not offer
an assurance and therefore we need something different. =A0The same is

true of CNAME.

CNAME does make an assertion=
that 'this name is equivalent to that name'. If we respect that, I=
think we are OK.

=A0

> I would prefer a new meta query record that the server advertises

> support for. This would be advertised as being supported using EDNS0
> and would take an extensible tag-value separated list of properties.
>

>

> MEGA-Q =A0www.exa=
mple.com _http._tcp

> =A0 =A0 source-ip =3D 10.1.1.1

> =A0 =A0 ipv6=3Dyes

>

>

> The reason for these additional parameter slots is that I would like
> to introduce new and better discovery mechanisms over time.

If we go this way, the (untrusted) DNS server will need to return all=

the RRsets that it checked (or their NSECs) so the client can verify

that it executed the discovery process faithfully. =A0If the server is not<=
br>
capable of returning everything the client wants, the client will end up
pulling individual RRsets to avoid being downgraded. =A0Still, we might

hope to eliminate a round trip or two in the common case.

(With an external resolver, these concerns apply only between the

resolver and the DNS server.)

This gets tricky be=
cause the RRSIG records start to add up and we end up needing multi-packet =
responses if we are not careful.

One way to adress this =
is to use a DPLS like approach where a DNS request is always one packet but=
can lead to a multi-packet response.

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

--0016e6407e8035949a0497eac5b6--

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8180F3A682E for ; Tue, 21 Dec 2010 03:31:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.405
X-Spam-Level:
X-Spam-Status: No, score=-3.405 tagged_above=-999 required=5 tests=[AWL=0.193, 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 3Ma7PJSULVsn for ; Tue, 21 Dec 2010 03:31:01 -0800 (PST)
Received: from mail-gw0-f42.google.com (mail-gw0-f42.google.com [74.125.83.42]) by core3.amsl.com (Postfix) with ESMTP id 3AF3F3A6846 for ; Tue, 21 Dec 2010 03:31:01 -0800 (PST)
Received: by gwb20 with SMTP id 20so3914098gwb.15 for ; Tue, 21 Dec 2010 03:32:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=mKyNvVJK0wzJvOlvuVoPvdyLT7DGr7FF7E6DRJ7yjcM=; b=pAZuaZA/1a277S1WTw23PUA4c83VJVZivfmpM4Uc+M00lnEaPIfjRfnziAOZ6lJVtH 3Pkgqj61umrtRMbzJG0878nSo6L22fwwphevxAxNYK1EG3ujjBTZQT9D3oAoT0rbqSHK 63YIadwtJDWb60/DysCABsYsmVhHCEwMcuP48=
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=PiKlI+gxXIjF+n8zk+eVY5QZiq58+4EGrdM7Jpb3H1ty1KscQIq69ohuxB/bhb/v79 491SWMT/vLeXF0zAw+brgRb+uuatA8bmrX2A95wE8lf8k2NBteshAay5t+WQ9lKVnIzG EnA8tfpgHzR83+CCKKaECd63Nd7dvAgAz7a0U=
MIME-Version: 1.0
Received: by 10.100.110.16 with SMTP id i16mr3171653anc.103.1292931176696; Tue, 21 Dec 2010 03:32:56 -0800 (PST)
Received: by 10.100.31.8 with HTTP; Tue, 21 Dec 2010 03:32:56 -0800 (PST)
In-Reply-To: <[email-masked]>
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Tue, 21 Dec 2010 11:32:56 +0000
Message-ID:
From: Phillip Hallam-Baker
To: Matt McCutchen
Content-Type: multipart/alternative; boundary=0016e645ab9a818e150497e9ff01
Cc: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 21 Dec 2010 11:31:02 -0000

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

Ah, that is much better, sorry.

Architecturally, we have a choice between prefix by port and prefix by
protocol.

I much prefer to have prefix by protocol as ports are a packet layer concept
and TLS is transport layer. We are going to run out of ports very quickly if
we cling to the 'one port per protocol' concept.

I would still prefer to have separate statements for 'this key is valid' and
'must/should use tls'

This should be architected as a generic mechanism for specifying protocol
attributes with the security properties the first set of requirements to be
defined.

On Tue, Dec 21, 2010 at 12:50 AM, Matt McCutchen wrote:

> On Mon, 2010-12-20 at 23:52 +0000, Phillip Hallam-Baker wrote:
> > While you might find the requirement for two protocols on one DNS name
> > to not be compelling, it happens to be the way the Internet was
> > designed, is today and will be even more so in the future.
>
> You misunderstood me. Keep both protocols at the same name, but do
> something to the TLSA record to make it apply to only one protocol.
> E.g., put the TLSA record at _smtp.example.com. That, rather than
> throwing away exclusivity, seems to be the solution proportionate to the
> problem.
>
> > What is the compelling reason for taking an approach that is known to
> > be broken now when there is an alternative on the table that meets all
> > the requirements?
>
> If the alternative you mean is non-exclusive TLSA, it does not meet my
> requirement to be able to make an exclusive statement that clients can
> choose to honor and thereby no longer be exposed to the increasingly
> unmanageable public CA system.
>
> --
> Matt
>
>

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

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

Ah, that is much better, sorry.

Architecturally, we have=
a choice between prefix by port and prefix by protocol.

I much prefer to have prefix by protocol as ports are a packet layer=
concept and TLS is transport layer. We are going to run out of ports very =
quickly if we cling to the 'one port per protocol' concept.

I would still prefer to have separate st=
atements for 'this key is valid' and 'must/should use tls'<=
/div>

This should be architected as a generic mechanism =
for specifying protocol attributes with the security properties the first s=
et of requirements to be defined.

On Tue, Dec 21, 2010 at =
12:50 AM, Matt McCutchen <[email-masked]> wrote:

On Mon, 2010-12-20 at 23:52 +0000, Phillip Hallam-Baker w=
rote:

> While you might find the requirement for two protocols on one DNS name=

> to not be compelling, it happens to be the way the Internet was

> designed, is today and will be even more so in the future.

You misunderstood me. =A0Keep both protocols at the same name, but do=

something to the TLSA record to make it apply to only one protocol.

E.g., put the TLSA record at _smtp.example.com. =A0That, rather than

throwing away exclusivity, seems to be the solution proportionate to the
problem.

> What is the compelling reason for taking an approach that is known to<=
br>
> be broken now when there is an alternative on the table that meets all=

> the requirements?

If the alternative you mean is non-exclusive TLSA, it does not meet m=
y

requirement to be able to make an exclusive statement that clients can

choose to honor and thereby no longer be exposed to the increasingly

unmanageable public CA system.

--

Matt

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

--0016e645ab9a818e150497e9ff01--

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F9073A699E for ; Mon, 20 Dec 2010 21:41:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SREpxHaLrBvR for ; Mon, 20 Dec 2010 21:41:43 -0800 (PST)
Received: from homiemail-a2.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by core3.amsl.com (Postfix) with ESMTP id 3F2723A69A9 for ; Mon, 20 Dec 2010 21:41:43 -0800 (PST)
Received: from homiemail-a2.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a2.g.dreamhost.com (Postfix) with ESMTP id A06D1280063; Mon, 20 Dec 2010 21:43:38 -0800 (PST)
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=kZGxoxUgHZMmX5+qVxmoa4/b4XK734w6Z9V/lzdBMQV SoXfbB1trh2mGJISfGsgmU5vDL8LiQdKiyqITZdr/cQDu8GBO80Abfdl7DbERoae 8jgN8+WHrAI5G9bisqkKL9D2oBhgn6hU7aZdgfy6oFJmrF0mzdwSm/6bdVGrS3Ac =
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=QPOfLBhh9bLDMBM2lvWk+kIbQBk=; b=YQKEHOC0iT c3Fl9JvJUu8k/Mxaa9P+avRaOV5jW8i3aA4kCytwHyKVZPM9bGFypM1/HYoE3F/6 rIY/Pa9tnyBBIXE3OKg0jSOesc/05uR04vP+wJMcExEMc6uHKeuSabciLq33oLLo EuquycWNsmTCWyqamyJwkjVqHeZ4g+/PM=
Received: from [192.168.1.40] (pool-96-231-10-176.washdc.east.verizon.net [96.231.10.176]) (Authenticated sender: [email-masked]) by homiemail-a2.g.dreamhost.com (Postfix) with ESMTPA id 331F7280061; Mon, 20 Dec 2010 21:43:38 -0800 (PST)
From: Matt McCutchen
To: Paul Hoffman
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 21 Dec 2010 00:43:36 -0500
Message-ID: <[email-masked]>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.1
Content-Transfer-Encoding: 7bit
Cc: [email-masked]
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 21 Dec 2010 05:41:44 -0000

On Mon, 2010-12-20 at 20:30 -0800, Paul Hoffman wrote:
> At 9:47 PM -0500 12/20/10, Matt McCutchen wrote:
> >I would argue that if http://foo:80 is just a redirection to
> >https://foo:443, that is not really "service" in the sense envisioned by
> >draft-hoffman-server-has-tls and hence it is not a lie to specify "0
> >443".
>
> It *is* a lie because you control the redirection. The semantics of "0
> 443" are "if you find a responder at port 80, it isn't me, and you are
> probably getting scammed". If, insetad, you announced "80 443" and did
> a redirect as above, it is not at all a lie.

I guess you get to state the intended semantics of your draft, and then
I'm left to submit a different one.

> The real question, one that will be addressed in both DANE and WEBSEC,
> is whether it is reasonable to say "I speak on port 80 but you MUST
> use 443 instead, even if you wanted to do port 80". If you can come up
> with non-silly semantics for that without obvious problems, the WGs
> might buy it. I'm skeptical, though; I see many reasons for a client
> to say "I know 443 is going to fail me, so I'm willing to fall back to
> 80". The most obvious example is "you're using a CA who I don't trust,
> so I'm going to fail during the TLS handshake".

If http://foo:80 is just a redirection to https://foo:443, then it is
quite reasonable because all that falling back to http://foo:80 buys you
is the possibility of getting attacked.

Upon further reflection, I agree that when they both provide the
service, the MUST is not right. The client can choose at its own risk.
The trouble is that most of the public is ill equipped to make this
choice and expects to be able to type mybank.com into a mainstream
browser and blame the browser or the site if anything bad happens. So I
propose that the DNS contain a hint, "users typically want strong
confidentiality and/or integrity with this service", which mainstream
browsers would honor by default but advanced users could override. The
point being that a site that sets the hint cannot be blamed if a client
uses the non-TLS service and gets attacked.

I'm not sure if the TLS hint is appropriate for IETF standardization or
would just be a convention among the browsers and sites that have to
cope with user expectations. But I think it is really what sites want
(at least it's what I want), not HASTLS.

--
Matt

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B56A3A69AC for ; Mon, 20 Dec 2010 21:20:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.587
X-Spam-Level:
X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 J-2cZPO1xfgw for ; Mon, 20 Dec 2010 21:20:20 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 42B243A69A9 for ; Mon, 20 Dec 2010 21:20:20 -0800 (PST)
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 B5B66C439; Tue, 21 Dec 2010 00:22:12 -0500 (EST)
Date: Tue, 21 Dec 2010 00:22:12 -0500 (EST)
From: Paul Wouters
To: Paul Hoffman
In-Reply-To:
Message-ID:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: [email-masked]
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 21 Dec 2010 05:20:21 -0000

On Mon, 20 Dec 2010, Paul Hoffman wrote:

> The real question, one that will be addressed in both DANE and WEBSEC, is whether it is reasonable to say "I speak on port 80 but you MUST use 443 instead, even if you wanted to do port 80". If you can come up with non-silly semantics for that without obvious problems, the WGs might buy it. I'm skeptical, though; I see many reasons for a client to say "I know 443 is going to fail me, so I'm willing to fall back to 80".

You can't. sslstrip made that inheritantly unsafe.

> The most obvious example is "you're using a CA who I don't trust, so I'm going to fail during the TLS handshake".

How would a fallback in this case ever be safer? Either you are connecting
to the right host but are lacking proof, or you are connecting to
something malicious. In the first case, you're better of praying and
continuing then going to port 80 for which you have no identity proof
either. In the second case, going back to port 80 is not going to make
the attacker go away.

Paul

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7347F3A6997 for ; Mon, 20 Dec 2010 20:29:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.598
X-Spam-Level:
X-Spam-Status: No, score=-101.598 tagged_above=-999 required=5 tests=[AWL=0.448, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 dJKMZJqT7aVp for ; Mon, 20 Dec 2010 20:29:00 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id A823C3A67EE for ; Mon, 20 Dec 2010 20:29:00 -0800 (PST)
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 oBL4UrBN079788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Dec 2010 21:30:55 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To: <[email-masked]>
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Mon, 20 Dec 2010 20:30:52 -0800
To: Matt McCutchen
From: Paul Hoffman
Content-Type: text/plain; charset="us-ascii"
Cc: [email-masked]
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 21 Dec 2010 04:29:01 -0000

At 9:47 PM -0500 12/20/10, Matt McCutchen wrote:
>I would argue that if http://foo:80 is just a redirection to
>https://foo:443, that is not really "service" in the sense envisioned by
>draft-hoffman-server-has-tls and hence it is not a lie to specify "0
>443".

It *is* a lie because you control the redirection. The semantics of "0 443" are "if you find a responder at port 80, it isn't me, and you are probably getting scammed". If, insetad, you announced "80 443" and did a redirect as above, it is not at all a lie.

>The effect is really the same as that described for an SSO for a
>protocol that uses in-band security update, except that the "band"
>consists of two ports.

...and, as you say, something that is not a service.

>The more controversial case is when the server offers real service on
>both http://example.com:80 and https://example.com:443 .

Something on 80 that redirects to 443 *is* a real service in every sense of the word.

>I think the
>real question here is who gets blamed if the desired level of security
>is not achieved. In some cases there's only one party that can be
>blamed (e.g., if one side leaks the master key or the client accepts an
>invalid PKIX certificate or DNSSEC chain). Beyond that, it's a gray
>area and I'm having difficulty formulating any coherent statement, so I
>will stop here.

The real question, one that will be addressed in both DANE and WEBSEC, is whether it is reasonable to say "I speak on port 80 but you MUST use 443 instead, even if you wanted to do port 80". If you can come up with non-silly semantics for that without obvious problems, the WGs might buy it. I'm skeptical, though; I see many reasons for a client to say "I know 443 is going to fail me, so I'm willing to fall back to 80". The most obvious example is "you're using a CA who I don't trust, so I'm going to fail during the TLS handshake".

--Paul Hoffman, Director
--VPN Consortium

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9163D3A67EE for ; Mon, 20 Dec 2010 20:05:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qT4te8cBjU+7 for ; Mon, 20 Dec 2010 20:05:55 -0800 (PST)
Received: from homiemail-a61.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by core3.amsl.com (Postfix) with ESMTP id 9F0E23A67BD for ; Mon, 20 Dec 2010 20:05:55 -0800 (PST)
Received: from homiemail-a61.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a61.g.dreamhost.com (Postfix) with ESMTP id A532257806C; Mon, 20 Dec 2010 20:07:50 -0800 (PST)
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=pwTIjAiSslCBzRMTFmiKFaHYD7U0ldNYOv3zf+p4vvY RhmP3j9IGcE3CDKutuXzJKPpgNhWG/6eT+OzSjWWkb9NCR23C94RR8QTGVxA55Mc NEtZzC/MmxHfkNXGSPoNtgo4ai4d3bk971BTRNZsRUB4ZxZhXrq5ztsjR3bW9Uo0 =
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=mBRSFYP6xZ3USyds1vgXwcERkkM=; b=e/ik/cjyFm UmTmpoIKtKcUIsdKigzhf7PtIs7f7DTOKh9071zb0qP5pvwGfrOqtW3IrVCeQY6X sgLhZZABCJ6K/yKrrdq/GgLZK5c78aVM3IYnutZYQEYwPMbOvq9R0wei3Rfkl2Xc eO+C8tRu/fPlK878oILkCAm57+29vpgQw=
Received: from [192.168.1.40] (pool-96-231-10-176.washdc.east.verizon.net [96.231.10.176]) (Authenticated sender: [email-masked]) by homiemail-a61.g.dreamhost.com (Postfix) with ESMTPA id 2F71C578073; Mon, 20 Dec 2010 20:07:50 -0800 (PST)
From: Matt McCutchen
To: Phillip Hallam-Baker
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost>
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 20 Dec 2010 23:07:44 -0500
Message-ID: <[email-masked]>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.1
Content-Transfer-Encoding: 7bit
Cc: [email-masked]
Subject: Re: [keyassure] TLSA and HASTLS
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 21 Dec 2010 04:05:56 -0000

On Mon, 2010-12-20 at 11:35 +0000, Phillip Hallam-Baker wrote:
> I see a three layer scheme that allows for protocol information to be
> expressed with increasing specificity as discovery progresses. [...]

I like this scheme. There are just some details to fill in:

- If information of the same type (e.g., TLSA) is specified at all three
stages, how is it combined?

- When TLSA of type 3 or 4 is used, what reference identifier(s) are
used for the server ID check?

- Early on, you pointed out that CERT RRs of existing types do not offer
an assurance and therefore we need something different. The same is
true of CNAME.

> I would prefer a new meta query record that the server advertises
> support for. This would be advertised as being supported using EDNS0
> and would take an extensible tag-value separated list of properties.
>
>
> MEGA-Q www.example.com _http._tcp
> source-ip = 10.1.1.1
> ipv6=yes
>
>
> The reason for these additional parameter slots is that I would like
> to introduce new and better discovery mechanisms over time.

If we go this way, the (untrusted) DNS server will need to return all
the RRsets that it checked (or their NSECs) so the client can verify
that it executed the discovery process faithfully. If the server is not
capable of returning everything the client wants, the client will end up
pulling individual RRsets to avoid being downgraded. Still, we might
hope to eliminate a round trip or two in the common case.

(With an external resolver, these concerns apply only between the
resolver and the DNS server.)

--
Matt

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65A3D3A6989 for ; Mon, 20 Dec 2010 19:25:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4mZsYIPfE1S for ; Mon, 20 Dec 2010 19:25:56 -0800 (PST)
Received: from homiemail-a2.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by core3.amsl.com (Postfix) with ESMTP id 753003A689D for ; Mon, 20 Dec 2010 19:25:56 -0800 (PST)
Received: from homiemail-a2.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a2.g.dreamhost.com (Postfix) with ESMTP id 8FA6B280070; Mon, 20 Dec 2010 19:27:51 -0800 (PST)
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=YAMSYKXMOhUKORbHMbjSXiEfFdfArdC45HvVW9BGn+e FPBRSv9aDhZWZzJCCSOvQSCL5hNSYXtTX0TI+60bydaioJk7Lczc0ymxw4ItGMmC e26srzT1O1r6cP0lxhUVPmaW+DEhV1FPy8IwPIY3aVcxAKoQULFPScrQ15HvAous =
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=9fMYaSOp9gS6hmwehUHkUFoAjv8=; b=tPAcPpB1Dl UPBWO3MmFGB0x2mjVA2at/l+PIBkSvFoVaFPBxNhP7d4O8KMBiQXB1QCkKkDen8l w75Y/EPa0tkIDX6QpObCNU501uPChrkfO+mlyjfb1jLW4QxjR7UDMlauwKWPH+06 iex8juRQHE6Mzlb590YFASadfS0ZTV/oc=
Received: from [192.168.1.40] (pool-96-231-10-176.washdc.east.verizon.net [96.231.10.176]) (Authenticated sender: [email-masked]) by homiemail-a2.g.dreamhost.com (Postfix) with ESMTPA id A68D528006D; Mon, 20 Dec 2010 19:27:50 -0800 (PST)
From: Matt McCutchen
To: Phillip Hallam-Baker
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 20 Dec 2010 22:27:48 -0500
Message-ID: <[email-masked]>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.1
Content-Transfer-Encoding: 7bit
Cc: [email-masked]
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 21 Dec 2010 03:25:57 -0000

On Tue, 2010-12-21 at 00:05 +0000, Phillip Hallam-Baker wrote:
> And what do browsers do when a self-signed cert is presented today?
>
> What you have there is a user interface issue. None of the positive
> claims in a self-asserted key should be shown to the user in primary
> chrome under any circumstance. [Negative claims such as restrictions
> on validity are another matter]
>
> This is already known.
>
> Since people are going to insist on being able to use self-signed
> certs for this purpose (and will ignore any DANE proposal if they are
> not supported),

[Side note: and why shouldn't they? The point of this work is to take
advantage of the DNSSEC authority chain. Why would one use a
public-CA-signed certificate with DANE for any reason other than EV or
compatibility with legacy clients?]

> what you are proposing is a new format that will only be used by the
> good guys.
>
> If browsers treat self-signed certs in idiot ways the risk you
> identify will still exist. In fact this proposal makes it more likely
> the risk will be realized by making it more likely browser authors
> think the problem is solved.

Interesting point. But the fact that security software is responsible
for defending against peers that don't act as they are supposed to is
widely recognized. Either way, we call out the issue in the security
considerations, and then if the browsers mess it up, it is their fault.

--
Matt

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4B263A698B for ; Mon, 20 Dec 2010 19:04:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 K6Jvzl6grFSf for ; Mon, 20 Dec 2010 19:03:59 -0800 (PST)
Received: from homiemail-a37.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by core3.amsl.com (Postfix) with ESMTP id AD51E3A6989 for ; Mon, 20 Dec 2010 19:03:59 -0800 (PST)
Received: from homiemail-a37.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTP id C44F91D0063; Mon, 20 Dec 2010 19:05:54 -0800 (PST)
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=jOK6Hz99lFrVKPsAGIGrB3+vpiC8MHFJ5+/SmDMgsgd gARTmo7nCfJq/qL+HluMuxOKtfqrQBBLUl31xhO8USR5kT3hXSVkajwoiWxYN5Mb EGO0+OIdtsQUyMHZMSjiSU3W4cxaIi9XXd1H7I8creYnXWvX4FIzG6oc3Sd3t6Tk =
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=0+wapnTUsN//W0H3TqIyLOrnepA=; b=DfT/20ya/c sioueI6xj1RDhwL/Ni9FwENmIm675xax1u/SrkNR8PaQdXiz9JPTG+iPOCUCBjnx /S0olm9+jArmAExHMs3lybzGbB0LCLoLTUCmY9qoCFCNTJppT2EQB7neaJK934e6 TBzqzGlrnhTpo/zhN6ZQGAoDtFYNVeep8=
Received: from [192.168.1.40] (pool-96-231-10-176.washdc.east.verizon.net [96.231.10.176]) (Authenticated sender: [email-masked]) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTPA id 4E9291D0058; Mon, 20 Dec 2010 19:05:54 -0800 (PST)
From: Matt McCutchen
To: Paul Wouters
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 20 Dec 2010 22:05:52 -0500
Message-ID: <[email-masked]>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.1
Content-Transfer-Encoding: 7bit
Cc: [email-masked]
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 21 Dec 2010 03:04:00 -0000

On Mon, 2010-12-20 at 16:51 -0500, Paul Wouters wrote:
> On Mon, 20 Dec 2010, Steingruebl, Andy wrote:
>
> >> My self signed cert containing CN=www.paypal.com
>
> > What do you mean "reach the end user"?
> >
> > 1. Show up in the location bar?
> > 2. Show up when I click "certificate details"?
> > 3. Something else?
>
> The browser vendor CA policy does or will have constraints that prevent
> unvalidated information from being present in all CA-issued certificates.
>
> They highly recommend being consistent with that policy to clear
> DNSSEC-based cert chain validation for inclusion in their browser.

This is the fallacy. DANE is not a method of validating a certificate
as such, it is a method of determining the acceptability of a
certificate for a particular TLS server. It replaces the combination of
PKIX chain validation + server ID check.

The browser should simply not show the irrelevant parts of a
DANE-endorsed certificate, unless it elects to also perform PKIX
validation against its trust anchor set and the validation succeeds. I
don't think it makes sense to impose requirements on the whole Internet
for the sake of not having to refactor this browser's code.

--
Matt

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B38853A698C for ; Mon, 20 Dec 2010 18:45:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yxP3NT0El8RC for ; Mon, 20 Dec 2010 18:45:23 -0800 (PST)
Received: from homiemail-a3.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by core3.amsl.com (Postfix) with ESMTP id A518E3A698B for ; Mon, 20 Dec 2010 18:45:23 -0800 (PST)
Received: from homiemail-a3.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a3.g.dreamhost.com (Postfix) with ESMTP id 922EC284071; Mon, 20 Dec 2010 18:47:18 -0800 (PST)
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=rDnzO9AB3omwqxA85l69PfzQD/8f+AIyr4W+6HPiR8i REosuV+JDU7ggqoO1Ds6DdwO7bbXj+uerTN5MWxahsDAoj5qkUFQPtJmz6+38Gdk RMSepOP0nnLgPd2K4diRRslnosqzRCIvQnbA37gnEoLl+egelJXiiB326TQQeGJA =
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=Fcz/Kp5gY6CI/aPt7ZXTpIGelI8=; b=u2TQB9kjaK +t30NPLMg7aug6ajl3xUCqxGqZvPA2gyWQJW+Gps5h+j6jhpRs69OAmp1FchhATr rrEf1JOi8sLkuL2cEaWYyG5oDgh2XUhhcHWJlJGDZ8QUUAoxqzykgVO5KLKqUKN6 yF0TK0LkkV3EzO030O9EOGkEvcYXKVjQQ=
Received: from [192.168.1.40] (pool-96-231-10-176.washdc.east.verizon.net [96.231.10.176]) (Authenticated sender: [email-masked]) by homiemail-a3.g.dreamhost.com (Postfix) with ESMTPA id CD9A528406A; Mon, 20 Dec 2010 18:47:17 -0800 (PST)
From: Matt McCutchen
To: Paul Hoffman
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 20 Dec 2010 21:47:16 -0500
Message-ID: <[email-masked]>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.1
Content-Transfer-Encoding: 7bit
Cc: [email-masked]
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 21 Dec 2010 02:45:24 -0000

On Mon, 2010-12-20 at 11:43 -0800, Paul Hoffman wrote:
> At 1:24 PM -0500 12/20/10, Paul Wouters wrote:
> >We would need to signal to new clients "ignore unseured port".
>
> This, again, is you saying to a client "I could care less what your
> policy is, you must do what I say". That's a model of security that
> has not been widely accepted, to say the least.
>
> >A current "hack" would be to specify "0 443", while in fact keeping
> things running on port 80.
> >This would tell new clients to never fallback on port 80, while older
> clients could still use
> >it (while of course remaining vulnerable to sslstrip)
>
> ...and that goes directly against the purpose of the expanded
> semantics of HASTLS over the current draft of HSTS: it tells the
> client in a secure fashion what is reality and assumes that the client
> will use the client's policy in the face of known reality.
>
> >My proposal was for some kind of change to formalise this, so that
> the most common deployment
> >would not be something not part of the original design (the lying
> about port 80)
>
> You can propose lying; I would object and instead continue to propose
> honesty. It really comes down to that.

I would argue that if http://foo:80 is just a redirection to
https://foo:443, that is not really "service" in the sense envisioned by
draft-hoffman-server-has-tls and hence it is not a lie to specify "0
443". The effect is really the same as that described for an SSO for a
protocol that uses in-band security update, except that the "band"
consists of two ports.

The more controversial case is when the server offers real service on
both http://example.com:80 and https://example.com:443 . I think the
real question here is who gets blamed if the desired level of security
is not achieved. In some cases there's only one party that can be
blamed (e.g., if one side leaks the master key or the client accepts an
invalid PKIX certificate or DNSSEC chain). Beyond that, it's a gray
area and I'm having difficulty formulating any coherent statement, so I
will stop here.

--
Matt

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 282603A695D for ; Mon, 20 Dec 2010 17:40:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46USk--TzYav for ; Mon, 20 Dec 2010 17:40:49 -0800 (PST)
Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by core3.amsl.com (Postfix) with ESMTP id 04CC63A695C for ; Mon, 20 Dec 2010 17:40:48 -0800 (PST)
Received: by wwi17 with SMTP id 17so3470843wwi.1 for ; Mon, 20 Dec 2010 17:42:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=wI9HbCx7zIouhCPS40CD29nJsEtUjMvD3oLdnU6v2dQ=; b=Ha2SpjUu+ygSXD7iJauLSxclUl0DBaqX3rui23vXMAfTY+FCQSVEb38JkVPPDyzrDD i7h4dXGWWMOi1mXdtk0o//mlReZPKs2IH3bh8eVhIEpiAZP9FiK4DKLz1HT6Mdo/OKgb fA8fM0HFY8e6kEPG46ThVsJynGF2VY/ZI7ngs=
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=Ge2dQ/H1eqdUcPIm67tmG4vWkzfsL9hHXaUpaWUCCpRJVuB5cznpGtSvQwZkF3O71x TXHlQWRvz5f5IwAguiKPLAOGawguOTASJe5pjxPm7jkPzYyLIhfI7wS45AUqt7lQKS29 10XkK8aIxsduA3DoIjWr1b+t+uAfNRlRWVCp0=
MIME-Version: 1.0
Received: by 10.227.96.212 with SMTP id i20mr3044738wbn.157.1292895763146; Mon, 20 Dec 2010 17:42:43 -0800 (PST)
Sender: [email-masked]
Received: by 10.227.133.149 with HTTP; Mon, 20 Dec 2010 17:42:43 -0800 (PST)
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]>
Date: Mon, 20 Dec 2010 17:42:43 -0800
X-Google-Sender-Auth: kSjI8j2I2r-BhqXzD8NppWu6abA
Message-ID:
From: Zack Weinberg
To: Geoff Beier
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: [email-masked], Paul Hoffman
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 21 Dec 2010 01:40:50 -0000

On Mon, Dec 20, 2010 at 4:51 PM, Geoff Beier wrote:
>> Why would you not simply turn off port 80? =C2=A0Users of older clients
>> would have to manually type https://, and inbound links might break,
>> but I don't see any other negative consequences.
>>
> Wouldn't this just break the web for browsers that attempt to connect
> to port 80 first in every case *except* when there's a MITM attacking
> them? I see two scenarios if you just turn it off:
>
> 1. An old browser attempts to connect to port 80 under normal
> circumstances. The user gets an error indicating that the site is
> unavailable, and the web is broken unless that user is savvy enough to
> type https and try again.
>
> 2. An old browser attempts to connect to port 80 in the presence of a
> MITM attack. The MITM makes connections back to the real https server,
> monkeys with the data, and sends it back to the user. The site appears
> to work, and the attack is successful.

This is an excellent point, I withdraw my suggestion.

zw

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A28553A6930 for ; Mon, 20 Dec 2010 16:50:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4MLCy8I7uCUt for ; Mon, 20 Dec 2010 16:50:07 -0800 (PST)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id A82113A6917 for ; Mon, 20 Dec 2010 16:50:06 -0800 (PST)
Received: by wyf23 with SMTP id 23so3475183wyf.31 for ; Mon, 20 Dec 2010 16:52:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=Lle31mqI2lqQaNFAaGKvffaXJUBddBZWSzpu5G3vAhI=; b=MrLKaNyXGuIC0frQ/KEFmlW5VKS/fPFZQSVUGsg/OTXCzo8aGc5VFv1IRAgV+jSsgi Y7w7ijuWB2jkrTNPzLs6e4MB8O57rqE1xmMUGIwKS7YsGox77hBQeKZhKDtnjp2d/Vmo wuKzqyXqlxZY7dZnu0+cWBHaElcTuyC9FUqkU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=nL/q8PflmJlPx0/1/kKwBn/g0wyqVvyMMT55SZlqCOIfHFyjeVrYpnuHv9sQDuxIey zJYXoY7/9C5HJo3kLAG21XeQO5SHI+orJBqXkTMDTgxMFB2wmdixA7u8VKembBWWfs2Y Z33UU8PU/bvKR5kOX1tRn6vhSbnkc4vz5ifps=
Received: by 10.216.175.132 with SMTP id z4mr5634412wel.11.1292892720887; Mon, 20 Dec 2010 16:52:00 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.183.198 with HTTP; Mon, 20 Dec 2010 16:51:40 -0800 (PST)
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]>
From: Geoff Beier
Date: Mon, 20 Dec 2010 19:51:40 -0500
Message-ID:
To: Zack Weinberg
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: [email-masked], Paul Hoffman
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 21 Dec 2010 00:50:07 -0000

On Mon, Dec 20, 2010 at 14:35, Zack Weinberg wro=
te:

>> It would be a common deployment to leave port 80 running for old clients=
not
>> supporting =A0these records to continue to work (and be vulnerable to ss=
lstrip)
>
> Why would you not simply turn off port 80? =A0Users of older clients
> would have to manually type https://, and inbound links might break,
> but I don't see any other negative consequences.
>
Wouldn't this just break the web for browsers that attempt to connect
to port 80 first in every case *except* when there's a MITM attacking
them? I see two scenarios if you just turn it off:

1. An old browser attempts to connect to port 80 under normal
circumstances. The user gets an error indicating that the site is
unavailable, and the web is broken unless that user is savvy enough to
type https and try again.

2. An old browser attempts to connect to port 80 in the presence of a
MITM attack. The MITM makes connections back to the real https server,
monkeys with the data, and sends it back to the user. The site appears
to work, and the attack is successful.

By my math, simply turning it offl leaves things apparently broken
when there's no attack and apparently functional when an attack is in
progress. That strikes me as the opposite of a desirable outcome, and
as a significant negative consequence.

Geoff

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 495ED3A6917 for ; Mon, 20 Dec 2010 16:48:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1ttvIndXQmo for ; Mon, 20 Dec 2010 16:48:41 -0800 (PST)
Received: from homiemail-a60.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by core3.amsl.com (Postfix) with ESMTP id 946103A67AF for ; Mon, 20 Dec 2010 16:48:41 -0800 (PST)
Received: from homiemail-a60.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a60.g.dreamhost.com (Postfix) with ESMTP id 558C83BC062; Mon, 20 Dec 2010 16:50:36 -0800 (PST)
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=RDu/PNtStv1TAioRsAKr0Ybj1QgW6sQc+dw/M4PUuHX 34AAlpcOHngcbYs95ep1y3uvjRxAVecvSkQCocK9GhMjN5423GctO+4BpZLj4ZaG HlofnK31++rzU5ian390NWHDsSCdRufnb6ZOkMnPSb1Dl1j1yqAPkQqXktzY4lKc =
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=uR/hbjwBRLFFTjlJ37VMOlpzTKM=; b=WjT6gm4uOo 0DV6amk6fQk6fz8GNdPXfOPkJDgOg8mEeg6NMyjkn/G1rxNYJjVYjM/NWm/y7enj FuGhFRUHxYiI84sexapkLvuZzozxWCJWRyyvaJgQ+bz3E2FMWIw9x/ai8VKyRbtT 5GH0G52+8isjxcGj0T0YNKSlfkUlpxYVA=
Received: from [192.168.1.40] (pool-96-231-10-176.washdc.east.verizon.net [96.231.10.176]) (Authenticated sender: [email-masked]) by homiemail-a60.g.dreamhost.com (Postfix) with ESMTPA id D8BBA3BC059; Mon, 20 Dec 2010 16:50:35 -0800 (PST)
From: Matt McCutchen
To: Phillip Hallam-Baker
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 20 Dec 2010 19:50:34 -0500
Message-ID: <[email-masked]>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.1
Content-Transfer-Encoding: 7bit
Cc: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 21 Dec 2010 00:48:42 -0000

On Mon, 2010-12-20 at 23:52 +0000, Phillip Hallam-Baker wrote:
> While you might find the requirement for two protocols on one DNS name
> to not be compelling, it happens to be the way the Internet was
> designed, is today and will be even more so in the future.

You misunderstood me. Keep both protocols at the same name, but do
something to the TLSA record to make it apply to only one protocol.
E.g., put the TLSA record at _smtp.example.com. That, rather than
throwing away exclusivity, seems to be the solution proportionate to the
problem.

> What is the compelling reason for taking an approach that is known to
> be broken now when there is an alternative on the table that meets all
> the requirements?

If the alternative you mean is non-exclusive TLSA, it does not meet my
requirement to be able to make an exclusive statement that clients can
choose to honor and thereby no longer be exposed to the increasingly
unmanageable public CA system.

--
Matt

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A06EC3A6952 for ; Mon, 20 Dec 2010 16:03:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.391
X-Spam-Level:
X-Spam-Status: No, score=-3.391 tagged_above=-999 required=5 tests=[AWL=0.207, 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 e4PbUAFYSyRB for ; Mon, 20 Dec 2010 16:03:10 -0800 (PST)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 378E93A694C for ; Mon, 20 Dec 2010 16:03:10 -0800 (PST)
Received: by yxt33 with SMTP id 33so1664125yxt.31 for ; Mon, 20 Dec 2010 16:05:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=gpo+8RSUwENbrd/Pwk46HINC4Rv5yEf+9nltIm+Ny8Y=; b=Jw2jJdGm8csXzzekWqGYDaaQ9aLNnwiYEIhuGgfhn6UENflF/Imu0pUOxBgKQ9OiTV WY0Pdrhx1sFGZNvlICHULM5zv7aLuTKQoIM7hlRuS6SQrBl0D7JdmNrzw82kqJcH+Haf e+Wf1yKouj9FxqJT6KultLwNFzCoW9IeexRH8=
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=VjnVRewrHOlPveh7vxO0X6ieztN1o9b77F9Hp4wOw75a464WxZ5Q4+jgafPh1l95FY USXvGG2SjVPUIQWlGAE1sGFUQ38swniA/gR+AjBLiJDvyyrbW44f+Ik1Lef5Vs2jqjUd 6zhZXkSV+EDHFHXW61zq+LBx+KKexSq0OH3E4=
MIME-Version: 1.0
Received: by 10.100.96.1 with SMTP id t1mr2874821anb.137.1292889904730; Mon, 20 Dec 2010 16:05:04 -0800 (PST)
Received: by 10.100.31.8 with HTTP; Mon, 20 Dec 2010 16:05:04 -0800 (PST)
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Tue, 21 Dec 2010 00:05:04 +0000
Message-ID:
From: Phillip Hallam-Baker
To: Paul Wouters
Content-Type: multipart/alternative; boundary=0016e644caf08153e50497e063e9
Cc: [email-masked]
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 21 Dec 2010 00:03:11 -0000

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

And what do browsers do when a self-signed cert is presented today?

What you have there is a user interface issue. None of the positive claims
in a self-asserted key should be shown to the user in primary chrome under
any circumstance. [Negative claims such as restrictions on validity are
another matter]

This is already known.

Since people are going to insist on being able to use self-signed certs for
this purpose (and will ignore any DANE proposal if they are not supported),
what you are proposing is a new format that will only be used by the good
guys.

If browsers treat self-signed certs in idiot ways the risk you identify will
still exist. In fact this proposal makes it more likely the risk will be
realized by making it more likely browser authors think the problem is
solved.

On Mon, Dec 20, 2010 at 9:41 PM, Paul Wouters wrote:

> On Mon, 20 Dec 2010, Phillip Hallam-Baker wrote:
>
> Indeed. And deployment can go up dramatically as well if we can work
>> around the hostname/CN= limitation
>> of SSL, hence the desire for a "bare public key" as well.
>>
>> Just wrap the key in an X.509 self signed cert and it is done.
>>
>> I don't see why you think this is an issue.
>>
>
> My self signed cert containing CN=www.paypal.com
>
> Browser vendors do not want to display that when there was a self signed
> cert without CA/EV backing and only the pubkey was validated via DNSSEC.
>
> So it would have to be a very specific kind of self signed cert to
> pass. Instead of adding X.509 policy on the various certificate bits that
> SHOULD NOT be used for DNSSEC validated self-signed certs, I proposed the
> "ignore all these bits and treat as a "bare public key". This means no
> CN= would ever reach the enduser.
>
> Paul
>

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

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

And what do browsers do when a self-signed cert is presented today?

What you have there is a user interface issue. N=
one of the positive claims in a self-asserted key should be shown to the us=
er in primary chrome under any circumstance. [Negative claims such as restr=
ictions on validity are another matter]

This is already known.

Since people are going to insist on being able to use self-signed c=
erts for this purpose (and will ignore any DANE proposal if they are not su=
pported), what you are proposing is a new format that will only be used by =
the good guys.

If browsers treat self-signed certs in idiot ways the r=
isk you identify will still exist. In fact this proposal makes it more like=
ly the risk will be realized by making it more likely browser authors think=
the problem is solved.

On Mon, Dec 20, 2010=
at 9:41 PM, Paul Wouters <[email-masked]> wrote:

On Mon, 20 Dec 2010, Phillip Hallam-Baker wrote:

Indeed. And deployment can go up dramatically as well if we can work around=
the hostname/CN=3D limitation

of SSL, hence the desire for a "bare public key" as well.

Just wrap the key in an X.509 self signed cert and it is done.

I don't see why you think this is an issue.

My self signed cert containing CN=3Dwww.paypal.com

Browser vendors do not want to display that when there was a self signed
cert without CA/EV backing and only the pubkey was validated via DNSSEC.

So it would have to be a very specific kind of self signed cert to

pass. Instead of adding X.509 policy on the various certificate bits that
SHOULD NOT be used for DNSSEC validated self-signed certs, I proposed the
"ignore all these bits and treat as a "bare public key". Thi=
s means no

CN=3D would ever reach the enduser.

Paul

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

--0016e644caf08153e50497e063e9--

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3A353A693E for ; Mon, 20 Dec 2010 15:50:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.388
X-Spam-Level:
X-Spam-Status: No, score=-3.388 tagged_above=-999 required=5 tests=[AWL=0.210, 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 BloOE2w+eVf2 for ; Mon, 20 Dec 2010 15:50:48 -0800 (PST)
Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by core3.amsl.com (Postfix) with ESMTP id 558753A6929 for ; Mon, 20 Dec 2010 15:50:48 -0800 (PST)
Received: by gxk8 with SMTP id 8so1579276gxk.27 for ; Mon, 20 Dec 2010 15:52:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=ycMlMW9eqActm69sYcVPFyENTPHvkfX+5SMDtEFtkAY=; b=MmWHr2IO/vK4/SSu0BIgpCrGryfWpShmV+E2s3JJGyLSzYKMyniFr/R1/O6URQzIa6 IrPcSxGrDGfdOFf8w9r267ZQzT961STAVOl0MT1ZLGwhEGV6CxLZX8htCftzhKaLO39n swZMcjVzd5VCLpjModHw2TgJ17hF9tV15FJQo=
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=VG7fFh9/Kpy80IVOPmBm1XNZcKjUmqZxym8va6aMlLx3mVzlVRnd9Tkl/aoyosGGxH s+wiBujjHZz2ogxeZEQCwSvzup+2pmrvMQjh+01UXKHxX/kRpfS3trwxL0kcPY+7/6ER G+KEOLy0b7XwnquKjQAaFbT8cHGPANALtPJlQ=
MIME-Version: 1.0
Received: by 10.101.67.16 with SMTP id u16mr2838188ank.1.1292889160810; Mon, 20 Dec 2010 15:52:40 -0800 (PST)
Received: by 10.100.31.8 with HTTP; Mon, 20 Dec 2010 15:52:40 -0800 (PST)
In-Reply-To: <[email-masked]>
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Mon, 20 Dec 2010 23:52:40 +0000
Message-ID:
From: Phillip Hallam-Baker
To: Matt McCutchen
Content-Type: multipart/alternative; boundary=00163662e65b29ff810497e0377a
Cc: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 20 Dec 2010 23:50:49 -0000

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

While you might find the requirement for two protocols on one DNS name to
not be compelling, it happens to be the way the Internet was designed, is
today and will be even more so in the future.

What is the compelling reason for taking an approach that is known to be
broken now when there is an alternative on the table that meets all the
requirements?

These are really not difficult problems to solve when people are prepared to
actually recognize them as problems. We seem to be fitting the problem to
the chosen technology, not looking at the problem and working out the best
way to solve it.

On Mon, Dec 20, 2010 at 9:55 PM, Matt McCutchen wrote:

> On Mon, 2010-12-20 at 19:59 +0100, W.C.A. Wijngaards wrote:
> > I want to split 2 into two parts.
> > 2.1) DNSSEC-secured domains that have zero TLSA records.
> > 2.2) DNSSEC-secured domains that have non-matching TLSA records.
> >
> > 2.1 MAY choose to fall back on PKIX.
>
> Correct.
>
> > 2.2 MUST be access denied, otherwise you have a 'downgrade to PKIX'.
>
> Correct, assuming the TLSA records are exclusive. Phillip has argued
> that it should be possible to use TLSA non-exclusively. I don't find
> the example of two protocols on the same host compelling (the right way
> to handle that is to put the TLSA at a name specific to the protocol),
> but it seems easy enough to have a flag, unless there's an argument that
> doing so is harmful.
>
> > So, an operator can 'opt-in' by deploying DNSSEC-signed TLSA records.
>
> Exactly.
>
> --
> Matt
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

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

While you might find the requirement for two protocols on one DNS name =
to not be compelling, it happens to be the way the Internet was designed, i=
s today and will be even more so in the future.

What is the compelling reason for taking an approach that is known to =
be broken now when there is an alternative on the table that meets all the =
requirements?

These are really not difficult probl=
ems to solve when people are prepared to actually recognize them as problem=
s. We seem to be fitting the problem to the chosen technology, not looking =
at the problem and working out the best way to solve it.

On Mon, Dec 20, 2010 at =
9:55 PM, Matt McCutchen <[email-masked]> wrote:

On Mon, 2010-12-20 at 19:59 +0100, W.C.A. Wijngaards wrot=
e:

> I want to split 2 into two parts.

> 2.1) DNSSEC-secured domains that have zero TLSA records.

> 2.2) DNSSEC-secured domains that have non-matching TLSA records.

>

> 2.1 MAY choose to fall back on PKIX.

Correct.

> 2.2 MUST be access denied, otherwise you have a 'downgrade to PKIX=
'.

Correct, assuming the TLSA records are exclusive. =A0Phillip has argu=
ed

that it should be possible to use TLSA non-exclusively. =A0I don't find=

the example of two protocols on the same host compelling (the right way

to handle that is to put the TLSA at a name specific to the protocol),

but it seems easy enough to have a flag, unless there's an argument tha=
t

doing so is harmful.

> So, an operator can 'opt-in' by deploying DNSSEC-signed TLSA r=
ecords.

Exactly.

--

Matt

_______________________________________________

keyassure mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/keyassure

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

--00163662e65b29ff810497e0377a--

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 186683A6925 for ; Mon, 20 Dec 2010 15:09:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.595
X-Spam-Level:
X-Spam-Status: No, score=-101.595 tagged_above=-999 required=5 tests=[AWL=0.451, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 NT3uie1-Xaag for ; Mon, 20 Dec 2010 15:09:53 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 4E9C53A6932 for ; Mon, 20 Dec 2010 15:09:53 -0800 (PST)
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 oBKNBjpU067859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Dec 2010 16:11:47 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]>
Date: Mon, 20 Dec 2010 15:11:44 -0800
To: Paul Wouters
From: Paul Hoffman
Content-Type: text/plain; charset="us-ascii"
Cc: [email-masked]
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 20 Dec 2010 23:09:54 -0000

At 3:21 PM -0500 12/20/10, Paul Wouters wrote:
>How do we protect the user that implements DANE protocols from
>sslstrip?

With HASTLS.

>For this exercise, you may not use PKIX based trust.

Not needed if you have DANE.

>It's an obvious hole in the drafts. I've made suggestions you don't
>like. Your only alternative offered has been a "design a totally new draft
>for that". Your objection is based on "DNSSEC cannot dictate policy, only
>PKIX may do that". Yet DANE is meant to provide an alternative to PKIX.

No, it isn't. It is meant to provide security services that the current TLS model does not handle.

>If we can't even use these new drafts to protect browsers, why ARE we
>writing new drafts?

So that you can start spouting hyperbole instead of doing hard security work?

--Paul Hoffman, Director
--VPN Consortium

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF8EA3A6948 for ; Mon, 20 Dec 2010 15:09:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.592
X-Spam-Level:
X-Spam-Status: No, score=-101.592 tagged_above=-999 required=5 tests=[AWL=0.454, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 NDr4ksjxmNxP for ; Mon, 20 Dec 2010 15:09:53 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id D63763A6925 for ; Mon, 20 Dec 2010 15:09:52 -0800 (PST)
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 oBKNBjpS067859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Dec 2010 16:11:47 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]>
Date: Mon, 20 Dec 2010 15:08:27 -0800
To: Paul Wouters
From: Paul Hoffman
Content-Type: text/plain; charset="us-ascii"
Cc: [email-masked]
Subject: Re: [keyassure] TLSA and HASTLS
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 20 Dec 2010 23:09:53 -0000

At 3:26 PM -0500 12/20/10, Paul Wouters wrote:
>On Mon, 20 Dec 2010, Paul Hoffman wrote:
>
>>>>Just to be clear: are you are proposing DANE adding "bare public key" *before* any version of TLS allows that? That means that DANE will be changing the TLS semantics for all current versions of TLS. It is possible we could do that, but that seems a bit daunting given the low value of the first three items on your list.
>>>
>>>Is there a technical reason why it can't?
>>
>>I don't think so. I said "daunting" because having a new WG like DANE say "we're changing the semantics of all existing versions of TLS" is procedurally, er, interesting.
>
>Okay. How about adding a private use type so we have something to code
>against while we look into adding a new "bare public key" option to TLS?

Using DANE as an end-run around the TLS extension process is one possibility: actually doing the work for a TLS extension is another.

>>Using PKIX certificates for TLS is a "policy" that every vendor that uses TLS has chosen to do already.
>
>We could limit the flag/option to the non-PKIX case? So we would in no
>way alter the policy of PKIX as implemented to date.

That would be fine.

--Paul Hoffman, Director
--VPN Consortium

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61DF53A6AFD for ; Mon, 20 Dec 2010 14:32:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMcIml42t0zr for ; Mon, 20 Dec 2010 14:32:16 -0800 (PST)
Received: from homiemail-a1.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by core3.amsl.com (Postfix) with ESMTP id 9D81C3A68FD for ; Mon, 20 Dec 2010 14:32:16 -0800 (PST)
Received: from homiemail-a1.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a1.g.dreamhost.com (Postfix) with ESMTP id 1D48A34806C; Mon, 20 Dec 2010 14:34:11 -0800 (PST)
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=gfyl0Es6EdyQ5W5eKQx9r3UTLuKUi1OXvyQYX1L880t uNIwhQTCpMB9weCuNhi/1H2F0qruxoQXExyEsRv1Kceww0rBVX1og30BCbqyMKUt RtrdICYrt4TB0SdqPH0w6Ru5MMCpt3ehl6Qh4XDa/WidzLSIpgYUpezFX0UBWxjw =
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=QZ+pzLgvBIPQsvYCfUeKu8l0iRo=; b=otY8VJhhT5 uNJ3rxPbnd6gjK008V06j1daKyMzlyWN5tdxhud90I+W6NrjTAOj83Xerhk7y7O3 VadVc3W7ed5KhuMw07xb+7s5qAnJo8abjJslhQGNjwNjlKCU0ybRD1jX/JP1Stpm VGqE7APWBr6BU/DPolIJmnJFQ6F9uh09g=
Received: from [192.168.1.40] (pool-96-231-10-176.washdc.east.verizon.net [96.231.10.176]) (Authenticated sender: [email-masked]) by homiemail-a1.g.dreamhost.com (Postfix) with ESMTPA id 99BF9348062; Mon, 20 Dec 2010 14:34:10 -0800 (PST)
From: Matt McCutchen
To: "Steingruebl, Andy"
In-Reply-To: <[email-masked]>
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 20 Dec 2010 17:34:08 -0500
Message-ID: <[email-masked]>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.1
Content-Transfer-Encoding: 7bit
Cc: [email-masked]
Subject: [keyassure] Need for SNI when multiple virtual hosts can designate the same key
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 20 Dec 2010 22:32:17 -0000

On Mon, 2010-12-20 at 14:59 -0700, Steingruebl, Andy wrote:
> 2. TLSA records aren't signed by a CA, but can be trusted to safely bootstrap TLS.
>
> In the case of #2 btw, where we have raw public keys, what is the
> impact on SNI? In some cases having "raw" public keys lets us avoid
> SNI, because the same virtual host can present the same public key for
> all virtual hosts, advertise them in DNS, but not need SNI.

Agreed, the issue of not knowing which certificate to present among
mutually trusting sites on the same server goes away. There are still
some uses for SNI:

- SNI makes it possible for a frontend to distribute connections
requesting different server names to different backends without
terminating TLS. The backends could even be mutually untrusting with
different public keys. Granted, SNI may not have been intended to
support this use case.

- SNI makes it possible to catch diversion of a connection by a MITM to
a server that has credentials valid for the requested site but does not
intend to serve it at the TLS level. Otherwise, the job falls to the
application, and the error reporting is not as clean. See:

http://www.ietf.org/mail-archive/web/tls/current/msg07133.html

--
Matt

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2FD53A6909 for ; Mon, 20 Dec 2010 14:13:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.297
X-Spam-Level:
X-Spam-Status: No, score=-1.297 tagged_above=-999 required=5 tests=[AWL=0.657, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334]
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 o6EH6pu-qTu0 for ; Mon, 20 Dec 2010 14:13:29 -0800 (PST)
Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 49B623A68FD for ; Mon, 20 Dec 2010 14:13:29 -0800 (PST)
Received: from marajade.sandelman.ca (cmr-208-124-129-34.cr.net.cable.rogers.com [208.124.129.34]) by relay.sandelman.ca (Postfix) with ESMTPS id 623573483F; Mon, 20 Dec 2010 17:22:43 -0500 (EST)
Received: from marajade.sandelman.ca (marajade.sandelman.ca [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 7617398563; Mon, 20 Dec 2010 17:15:22 -0500 (EST)
From: Michael Richardson
To: Paul Wouters
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]>
X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21)
Date: Mon, 20 Dec 2010 17:15:22 -0500
Message-ID: <[email-masked]>
Sender: [email-masked]
Cc: [email-masked], Phillip Hallam-Baker
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 20 Dec 2010 22:13:30 -0000

>>>>> "Paul" == Paul Wouters writes:
>> Indeed. And deployment can go up dramatically as well if we can work around the hostname/CN= limitation
>> of SSL, hence the desire for a "bare public key" as well.
>> Just wrap the key in an X.509 self signed cert and it is done.
>> I don't see why you think this is an issue.

Paul> My self signed cert containing CN=www.paypal.com

Paul> Browser vendors do not want to display that when there was a self signed
Paul> cert without CA/EV backing and only the pubkey was validated via DNSSEC.

Paul> So it would have to be a very specific kind of self signed cert to
Paul> pass. Instead of adding X.509 policy on the various certificate bits that
Paul> SHOULD NOT be used for DNSSEC validated self-signed certs, I proposed the
Paul> "ignore all these bits and treat as a "bare public key". This means no
Paul> CN= would ever reach the enduser.

+1

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17E883A68FB for ; Mon, 20 Dec 2010 14:06:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZz3Tmiak1R4 for ; Mon, 20 Dec 2010 14:06:51 -0800 (PST)
Received: from homiemail-a60.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by core3.amsl.com (Postfix) with ESMTP id 661503A68EC for ; Mon, 20 Dec 2010 14:06:51 -0800 (PST)
Received: from homiemail-a60.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a60.g.dreamhost.com (Postfix) with ESMTP id 035373BC06C; Mon, 20 Dec 2010 14:08:45 -0800 (PST)
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=vfIJtxnphAH+jG8zw/4KKEwOfekhxGVhZl8As1PQ06k e4cCpegYF3HZwjtgpHstHeqQlb7t62stRG6IhbvqaEu3IoQNt/AJ99Q80qvN87Qp 1Oij6qeUxijj32bCoGoCs3FK9+oerNwFxvjJcuW118D01Lk3lywu5L/Ykyq4POyc =
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=UUK3hqnef87AtT8a40VB1Biz42s=; b=Uu5svi/rsg B24taEXiIZD1kyugSfcQ3RC1JrlGY5TgU9eo3R7ZIY/GnOwnucSNIz+7Era+URdw JyD/lBfz5jU0V6xQDqz2O96PT5Sd5j3OiNpz7vBlJpzhq6btdSqnu78EBY4jEBwp O4BgycJoqXC3iEc8dTHhQD3Eua37Xhv7k=
Received: from [192.168.1.40] (pool-96-231-10-176.washdc.east.verizon.net [96.231.10.176]) (Authenticated sender: [email-masked]) by homiemail-a60.g.dreamhost.com (Postfix) with ESMTPA id 669183BC06A; Mon, 20 Dec 2010 14:08:45 -0800 (PST)
From: Matt McCutchen
To: Paul Wouters
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 20 Dec 2010 17:08:42 -0500
Message-ID: <[email-masked]>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.1
Content-Transfer-Encoding: 7bit
Cc: [email-masked]
Subject: Re: [keyassure] "hostname/CN= limitation"
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 20 Dec 2010 22:06:52 -0000

On Mon, 2010-12-20 at 16:05 -0500, Paul Wouters wrote:
> On Mon, 20 Dec 2010, Phillip Hallam-Baker wrote:
> > Now consider what is possible when a site has a way of saying 'TLS is always offered, here is the key'.
> >
> > Deployment now becomes a no-downside option for any server which would not normally have used security.
>
> Indeed. And deployment can go up dramatically as well if we can work around the hostname/CN= limitation
> of SSL, hence the desire for a "bare public key" as well.

My understanding is that DANE does not care about the server names in
end-entity certificates designated by associations of type 1 or 2.
Obviously it needs to care for type 3 or 4. This needs clarification in
the draft, but assuming my understanding is correct, there is no issue
that would be a reason to use bare public keys.

--
Matt

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5A4C3A6B04 for ; Mon, 20 Dec 2010 13:57:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.773
X-Spam-Level:
X-Spam-Status: No, score=-7.773 tagged_above=-999 required=5 tests=[AWL=1.344, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, 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 XOEIBlWmKnlE for ; Mon, 20 Dec 2010 13:57:38 -0800 (PST)
Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) by core3.amsl.com (Postfix) with ESMTP id A0BD13A6B03 for ; Mon, 20 Dec 2010 13:57:38 -0800 (PST)
DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:CC: Date:Subject:Thread-Topic:Thread-Index:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: x-ems-proccessed:x-ems-stamp:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=c9WBZws53LzUCGKS1XnoUwGVSM30b9E06W8N9NcHZEUTRvpTnhdMY0bJ ph8NS3/XS2XS/JqRSE7vV2bopo9EEILMiCpxstZms8HK8pqj9mgv5g2go 97zgdaekeZEczgx;
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=[email-masked]; q=dns/txt; s=ppinc; t=1292882373; x=1324418373; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; z=From:=20"Steingruebl,=20Andy"=20|To:=20Paul=20Wouters=20|CC:=20P hillip=20Hallam-Baker=20,=20"keyassure@ ietf.org"=0D=0A=09|Date:=20Mon,=2020 =20Dec=202010=2014:59:31=20-0700|Subject:=20RE:=20[keyass ure]=20HTTPS=20->=20HTTP=20downgrade|Message-ID:=20<5EE04 [email-masked]. ebay.com>|References:=20<20101213220001.24500.52050.idtra cker@localhost>=0D=0A=20=0D=0A=20=0D=0A=20=0D=0A=20<1292800354.1885.7.camel@ mattlaptop2.local>=0D=0A=20=0D=0A=20<1292803814.1885.16. [email-masked]>=0D=0A=20=0D=0A=20=0D=0A=20=0D=0A=20=0D=0A=20<1 [email-masked]>=0D=0A=20 =0D=0A=20=0D=0A=20=0D=0A=20=0D=0A=20<5EE049BA3C6 [email-masked] om>=0D=0A=20|In-Reply-To:=20|Content-Transfer-Encoding: =20quoted-printable|MIME-Version:=201.0; bh=Ux4Ieo+IwKjidV1IYaQ9c9cxifB5ATGBFmevbLDN93w=; b=qfCyf0MaK1RUYqy4obsaWrQrZwF1w+sEVYWhDpTn72ylQdMTeEb370QR LJepcaU1OnosCSYx7YgbJFFq0AxQytlwuyx3UvOgsqjGIVCR3F3wrR6hK 9QvD8SxeOkHPudY;
X-EBay-Corp: Yes
X-IronPort-AV: E=Sophos;i="4.60,204,1291622400"; d="scan'208";a="538667"
Received: from den-vtenf-002.corp.ebay.com (HELO DEN-MEXHT-003.corp.ebay.com) ([10.101.112.213]) by den-mipot-002.corp.ebay.com with ESMTP; 20 Dec 2010 13:59:33 -0800
Received: from DEN-MEXMS-001.corp.ebay.com ([10.241.16.225]) by DEN-MEXHT-003.corp.ebay.com ([10.241.17.54]) with mapi; Mon, 20 Dec 2010 14:59:33 -0700
From: "Steingruebl, Andy"
To: Paul Wouters
Date: Mon, 20 Dec 2010 14:59:31 -0700
Thread-Topic: [keyassure] HTTPS -> HTTP downgrade
Thread-Index: AcugkAMj0nVjlAu/R4y3NKHxqEOcpwAAKpKg
Message-ID: <[email-masked]>
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To:
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A==
x-ems-stamp: I2s+ucHIKDpkVTGW70mutQ==
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter: Scanned
Cc: "[email-masked]" , Phillip Hallam-Baker
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 20 Dec 2010 21:57:39 -0000

> -----Original Message-----
> From: Paul Wouters [mailto:[email-masked]]
>=20
> The browser vendor CA policy does or will have constraints that prevent
> unvalidated information from being present in all CA-issued certificates.

OK, but in this case what if it isn't CA-issued?
=20
>=20
> In fact, I was lit. told:
>=20
> That means the cert shouldn't contain anything
> except (roughly) the key and key usage restrictions. I do not
> understand why you would want to allow any more (AFAICT,
> useless and/or misleading) information in the cert anyway.
>=20
> I am not sure what incompatibilities it would create if we would now have
> certificates with an empty CN=3D. How do current browers deal with that? =
To
> prevent interoperability issues and implementation differences, I suggest=
ed
> using a TLSA type that explicitely states this goal.

Sure. This makes some decent sense. At the same time, we have two "choices=
".

1. TLSA records make the cert itself a trust-anchor, or chained off the DNS=
Root (or some other)
2. TLSA records aren't signed by a CA, but can be trusted to safely bootstr=
ap TLS.

In the case of #2 btw, where we have raw public keys, what is the impact on=
SNI? In some cases having "raw" public keys lets us avoid SNI, because th=
e same virtual host can present the same public key for all virtual hosts, =
advertise them in DNS, but not need SNI. Especially if we don't have to do=
usual PKIX validation, like checking CN, or following any/all of the rules=
in http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-12

- Andy

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18F193A6AE1 for ; Mon, 20 Dec 2010 13:54:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRxhCXgxDPE8 for ; Mon, 20 Dec 2010 13:54:07 -0800 (PST)
Received: from homiemail-a1.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by core3.amsl.com (Postfix) with ESMTP id 47E0B3A6903 for ; Mon, 20 Dec 2010 13:54:07 -0800 (PST)
Received: from homiemail-a1.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a1.g.dreamhost.com (Postfix) with ESMTP id B7F54348073; Mon, 20 Dec 2010 13:56:01 -0800 (PST)
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=rlH13u/U1/75xGy3servx2toeaMnMhhxKRz3TdcUXCk d7KPxpCUSzELQUT6L+8WAb1DEAH9Jxjg6qfQQ5VUIk1qq/45TJexmOl7Z1gJhsDT pBxbx/shMQVk+QkBATGg98YgeQh4B5Ly3x9aeBOjq8NGm1uejvT6LK/TJ1ki151M =
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=a4X/ogUfBYOJiemfALYKK4bUnGc=; b=fRV+igpkcf 85bzJP2qpYvp1LkTucaPT1bOqr1SZkG4sAVrtwh/nz8Qydh2RMp9HyT/QOsqE2kO DqNF7teIQhPmIBePzFiPZpjC4yVj6DmFRthFbjgJ8yYve0PXb20rARcxMTQWTZna T4mHVenqtkZCBbBzCrCinsYOBaP4Rgtdc=
Received: from [192.168.1.40] (pool-96-231-10-176.washdc.east.verizon.net [96.231.10.176]) (Authenticated sender: [email-masked]) by homiemail-a1.g.dreamhost.com (Postfix) with ESMTPA id 398AF348072; Mon, 20 Dec 2010 13:56:01 -0800 (PST)
From: Matt McCutchen
To: "W.C.A. Wijngaards"
In-Reply-To: <[email-masked]>
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 20 Dec 2010 16:55:59 -0500
Message-ID: <[email-masked]>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.1
Content-Transfer-Encoding: 7bit
Cc: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 20 Dec 2010 21:54:08 -0000

On Mon, 2010-12-20 at 19:59 +0100, W.C.A. Wijngaards wrote:
> I want to split 2 into two parts.
> 2.1) DNSSEC-secured domains that have zero TLSA records.
> 2.2) DNSSEC-secured domains that have non-matching TLSA records.
>
> 2.1 MAY choose to fall back on PKIX.

Correct.

> 2.2 MUST be access denied, otherwise you have a 'downgrade to PKIX'.

Correct, assuming the TLSA records are exclusive. Phillip has argued
that it should be possible to use TLSA non-exclusively. I don't find
the example of two protocols on the same host compelling (the right way
to handle that is to put the TLSA at a name specific to the protocol),
but it seems easy enough to have a flag, unless there's an argument that
doing so is harmful.

> So, an operator can 'opt-in' by deploying DNSSEC-signed TLSA records.

Exactly.

--
Matt

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE0B63A6AEC for ; Mon, 20 Dec 2010 13:49:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.587
X-Spam-Level:
X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 IDZj1-9W88AE for ; Mon, 20 Dec 2010 13:49:09 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 9FC0B3A6AE3 for ; Mon, 20 Dec 2010 13:49:08 -0800 (PST)
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 A5109C412; Mon, 20 Dec 2010 16:51:02 -0500 (EST)
Date: Mon, 20 Dec 2010 16:51:02 -0500 (EST)
From: Paul Wouters
To: "Steingruebl, Andy"
In-Reply-To: <[email-masked]>
Message-ID:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: "[email-masked]" , Phillip Hallam-Baker
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 20 Dec 2010 21:49:09 -0000

On Mon, 20 Dec 2010, Steingruebl, Andy wrote:

>> My self signed cert containing CN=www.paypal.com

> What do you mean "reach the end user"?
>
> 1. Show up in the location bar?
> 2. Show up when I click "certificate details"?
> 3. Something else?

The browser vendor CA policy does or will have constraints that prevent
unvalidated information from being present in all CA-issued certificates.

They highly recommend being consistent with that policy to clear
DNSSEC-based cert chain validation for inclusion in their browser.

In fact, I was lit. told:

That means the cert shouldn't contain anything
except (roughly) the key and key usage restrictions. I do not
understand why you would want to allow any more (AFAICT,
useless and/or misleading) information in the cert anyway.

I am not sure what incompatibilities it would create if we would now have
certificates with an empty CN=. How do current browers deal with that? To
prevent interoperability issues and implementation differences, I suggested
using a TLSA type that explicitely states this goal.

Paul

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 446B53A68E5 for ; Mon, 20 Dec 2010 13:41:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.694
X-Spam-Level:
X-Spam-Status: No, score=-7.694 tagged_above=-999 required=5 tests=[AWL=1.423, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, 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 jC8ITj2w+rTQ for ; Mon, 20 Dec 2010 13:41:39 -0800 (PST)
Received: from den-mipot-001.corp.ebay.com (den-mipot-001.corp.ebay.com [216.113.175.152]) by core3.amsl.com (Postfix) with ESMTP id E2F513A6AE3 for ; Mon, 20 Dec 2010 13:41:38 -0800 (PST)
DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:CC: Date:Subject:Thread-Topic:Thread-Index:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: x-ems-proccessed:x-ems-stamp:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=DLiTAAvWogVve3hWIsywLaFklUH3LBiii3+Pqss5gRozqreHRmbcq4HL Zx717RNXuDZFf+HDEyBevvnHHg4F9GwFudHziHKHgpWg8xhjacoqGvV+x Lc66JZxuHZfhKTi;
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=[email-masked]; q=dns/txt; s=ppinc; t=1292881414; x=1324417414; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; z=From:=20"Steingruebl,=20Andy"=20|To:=20Paul=20Wouters=20,=20Phil lip=20Hallam-Baker=20|CC:=20"keyassure@ ietf.org"=20|Date:=20Mon,=2020=20Dec =202010=2014:42:58=20-0700|Subject:=20RE:=20[keyassure] =20HTTPS=20->=20HTTP=20downgrade|Message-ID:=20<5EE049BA3 [email-masked] .com>|References:=20<20101213220001.24500.52050.idtracker @localhost>=0D=0A=09=0D=0A=09=0D=0A=09=0D=0A=09=0D=0A=09<1292800354.1885.7. [email-masked]>=0D=0A=09=0D=0A=09<1292803814.18 [email-masked]>=0D=0A=09=0D=0A=09=0D=0A=09=0D=0A=09=0D =0A=09<[email-masked]>=0D=0A =09=0D=0A=09=0D=0A=09=0D=0A=20|In-Reply-To: =20|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=vLudny6qnHF/c2ex9zKwnPTjFtmxO7egaTw9iC8tsRg=; b=W9zRaF0NsuAAcHA5XIuL1V6xbo2EKOYDzyK+yQiUjFaUjbeDne4etVjR p9Gf/UAs62FKhwmTl7oLD2Sg9G64uqYgzi9lcQ1z8Ekn7rXgxy2W9MJfQ N2yxNqB7R3698mD;
X-EBay-Corp: Yes
X-IronPort-AV: E=Sophos;i="4.60,204,1291622400"; d="scan'208";a="53760"
Received: from den-vtenf-001.corp.ebay.com (HELO DEN-MEXHT-003.corp.ebay.com) ([10.101.112.212]) by den-mipot-001.corp.ebay.com with ESMTP; 20 Dec 2010 13:43:30 -0800
Received: from DEN-MEXMS-001.corp.ebay.com ([10.241.16.225]) by DEN-MEXHT-003.corp.ebay.com ([10.241.17.54]) with mapi; Mon, 20 Dec 2010 14:43:00 -0700
From: "Steingruebl, Andy"
To: Paul Wouters , Phillip Hallam-Baker
Date: Mon, 20 Dec 2010 14:42:58 -0700
Thread-Topic: [keyassure] HTTPS -> HTTP downgrade
Thread-Index: Acugjqi9kTWg7uhJQLS51hpqx2FMUQAABuqQ
Message-ID: <[email-masked]>
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To:
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A==
x-ems-stamp: CoBrYgG7gbrb8oDwgorsUw==
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter: Scanned
Cc: "[email-masked]"
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 20 Dec 2010 21:41:40 -0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Paul Wouters
>=20
> My self signed cert containing CN=3Dwww.paypal.com
>=20
> Browser vendors do not want to display that when there was a self signed
> cert without CA/EV backing and only the pubkey was validated via DNSSEC.
>=20
> So it would have to be a very specific kind of self signed cert to pass. =
Instead
> of adding X.509 policy on the various certificate bits that SHOULD NOT be
> used for DNSSEC validated self-signed certs, I proposed the "ignore all t=
hese
> bits and treat as a "bare public key". This means no CN=3D would ever rea=
ch the
> enduser.

What do you mean "reach the end user"? =20

1. Show up in the location bar?
2. Show up when I click "certificate details"?
3. Something else?

- Andy

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1FCE3A68EC for ; Mon, 20 Dec 2010 13:39:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.587
X-Spam-Level:
X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 e9-3lSTNB-80 for ; Mon, 20 Dec 2010 13:39:17 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 1226D3A68E5 for ; Mon, 20 Dec 2010 13:39:17 -0800 (PST)
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 95670C412; Mon, 20 Dec 2010 16:41:09 -0500 (EST)
Date: Mon, 20 Dec 2010 16:41:09 -0500 (EST)
From: Paul Wouters
To: Phillip Hallam-Baker
In-Reply-To:
Message-ID:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: [email-masked]
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 20 Dec 2010 21:39:18 -0000

On Mon, 20 Dec 2010, Phillip Hallam-Baker wrote:

> Indeed. And deployment can go up dramatically as well if we can work around the hostname/CN= limitation
> of SSL, hence the desire for a "bare public key" as well.
>
> Just wrap the key in an X.509 self signed cert and it is done.
>
> I don't see why you think this is an issue.

My self signed cert containing CN=www.paypal.com

Browser vendors do not want to display that when there was a self signed
cert without CA/EV backing and only the pubkey was validated via DNSSEC.

So it would have to be a very specific kind of self signed cert to
pass. Instead of adding X.509 policy on the various certificate bits that
SHOULD NOT be used for DNSSEC validated self-signed certs, I proposed the
"ignore all these bits and treat as a "bare public key". This means no
CN= would ever reach the enduser.

Paul

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D41B03A6AE4 for ; Mon, 20 Dec 2010 13:28:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.689
X-Spam-Level:
X-Spam-Status: No, score=0.689 tagged_above=-999 required=5 tests=[AWL=-2.681, BAYES_20=-0.74, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, SARE_OBFU_AMP2B=2.555]
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 QDw8XY3+EgBA for ; Mon, 20 Dec 2010 13:28:03 -0800 (PST)
Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id A33903A68EE for ; Mon, 20 Dec 2010 13:28:03 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=kUVFXC02qoOKZFSo/1qN5K0gec8veZO9GKHR7vGzIgxDfYm7YkkZ08tRNmQeLUgC; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Transfer-Encoding:X-Mailer:Content-Type:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.51] (helo=mswamui-thinleaf.atl.sa.earthlink.net) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1PUnIr-0000iv-F4; Mon, 20 Dec 2010 16:29:57 -0500
Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Mon, 20 Dec 2010 16:29:57 -0500
Message-ID: <[email-masked]>
Date: Mon, 20 Dec 2010 15:29:57 -0600 (GMT-06:00)
From: "Jeffrey A. Williams"
To: Phillip Hallam-Baker , Matt McCutchen
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
X-Mailer: EarthLink Zoo Mail 1.0
Content-Type: text/html; charset=UTF-8
X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688edeaaf30da666129e5416febe6ed0fef350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.51
Cc: [email-masked]
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: "Jeffrey A. Williams"
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 20 Dec 2010 21:28:04 -0000

Phillip and all,

Yeah this is a very good business and enterprise security case th=
at will/should be

or become popular IMO.

-----Original Message-----
From: Phillip Hallam-Baker
Sent: Dec 20, 2010 2:50 PM
To: Matt McCutchen
Cc: [email-masked]
Subject: Re: [keyassure] =
HTTPS -> HTTP downgrade

Must use TLS is only one use case and no=
t necessarily the most interesting.

TLS is always offered is rather more interesting to me. Particularly w=
hen combined with lightweight DNSSEC validated keys.

As of today 0% of browsers support DANE. And it will be ten years or s=
o before the proportion supporting DANE is above 90%. If all DANE offers is=
a 'cheap' substitute for CA issued certs it is probably going to fail. Who=
is going to deploy such a scheme at a server? It is certainly not going to=
work for any commercial application that requires security since nobody is=
going to accept a 10% drop in sales as the price of using a 'free' cert.

Now consider what is possible when a site has a way of saying 'TLS is =
always offered, here is the key'.

Deployment now becomes a no-downside option for any server which would=
not normally have used security.

On Mon, Dec 20, 2010 at 8:32 PM, Matt McCutchen <[email-masked]> wrote:

On Mon, 2010-12-20 at 11:35 -0800, Zack Weinberg wrote:
=
> On Mon, Dec 20, 2010 at 10:24 AM, Paul Wouters <[email-masked]> wrote:
>=
; > On Mon, 20 Dec 2010, Paul Hoffman wrote:
> >> ... If you=
are running
> >> a server on port 80, you *cannot* prevent sss=
lstrip attacks: that is the
> >> whole point of the HASTLS docu=
ment.
> >
> > - for clients not supporting HASTLS/TLSA, w=
e can do nothing to prevent
> >   sslstrip
> > - for=
clients supporting HASTLS/TLSA, we can prevent sslstrip, if we can
>=
>   convey this by either the presence of HAS/TLSA or an option in=
those records.
> >
> > It would be a common deployment t=
o leave port 80 running for old clients not
> > supporting  t=
hese records to continue to work (and be vulnerable to sslstrip)
>> Why would you not simply turn off port 80?  Users of older clien=
ts
> would have to manually type https://, and inbound links might br=
eak,
> but I don't see any other negative consequences.

=
Those are pretty significant consequences!  I'd imagine the last thing=
a
major online business wants is for a significant fraction of its
c=
ustomers to suddenly get an error page when they type in the name of
the=
site.  It would take a massive PR effort to get everyone to upgradetheir browsers or type https: .  Yes, that's eventually needed anywa=
y to
realize the security benefits, but for now I strongly prefer a sche=
me
that can be adopted without breaking legacy clients.  (Perhaps t=
he
PayPal folks would offer their perspective?)

--
Matt

_______________________________________________
keya=
ssure mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/keyassure=

--
Websi=
te: http://hallambaker.=
com/

Kindest regards,
Jeffrey A. Williams
"Obedience of th=
e law is the greatest freedom" -
Abraham Lincoln

"Cr=
edit should go with the performance of duty and not with what is very
of=
ten the accident of glory" - Theodore Roosevelt

"If the probability =
be called P; the injury, L; and the burden, B; liability
depends upon wh=
ether B is less than L multiplied by
P: i.e., whether B is less than PL.=
"
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Updated 1/26/04
Network secur=
ity Eng. SR. Eng. Network data security,
IT/information security.
ABA=
member in good standing member ID 01257402
E-Mail [email-masked]=
om
Phone: 214-244-4827

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98DD53A68D9 for ; Mon, 20 Dec 2010 13:03:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.587
X-Spam-Level:
X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 489nvEXnmlrV for ; Mon, 20 Dec 2010 13:03:17 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id C04533A68C1 for ; Mon, 20 Dec 2010 13:03:17 -0800 (PST)
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 0484DC45B; Mon, 20 Dec 2010 16:05:11 -0500 (EST)
Date: Mon, 20 Dec 2010 16:05:10 -0500 (EST)
From: Paul Wouters
To: Phillip Hallam-Baker
In-Reply-To:
Message-ID:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT
Cc: [email-masked]
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 20 Dec 2010 21:03:18 -0000

On Mon, 20 Dec 2010, Phillip Hallam-Baker wrote:

> As of today 0% of browsers support DANE. And it will be ten years or so before the proportion supporting DANE is
> above 90%.

I've talked to one major browser vendor and with our help they want
to try and get it into their next major release. Which would be in the
order of 3-6 months. Not 10 years.

> Now consider what is possible when a site has a way of saying 'TLS is always offered, here is the key'.�
>
> Deployment now becomes a no-downside option for any server which would not normally have used security.�

Indeed. And deployment can go up dramatically as well if we can work around the hostname/CN= limitation
of SSL, hence the desire for a "bare public key" as well.

Paul

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFAEE3A6AEC for ; Mon, 20 Dec 2010 12:51:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 h43nBj5GbdiL for ; Mon, 20 Dec 2010 12:50:59 -0800 (PST)
Received: from homiemail-a1.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by core3.amsl.com (Postfix) with ESMTP id D24023A6AF0 for ; Mon, 20 Dec 2010 12:50:54 -0800 (PST)
Received: from homiemail-a1.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a1.g.dreamhost.com (Postfix) with ESMTP id 3568234806E for ; Mon, 20 Dec 2010 12:52:49 -0800 (PST)
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=CLSla2BL1/OVo6qFchGZM0ti+hB1usOGwiTbdw750tA pas/V4Zj/BUNQOspbsdaqXqpYtpLCj72XoeP2butxZW28mYddo8VQw6bpTXe4Hdh Wfu+H2mxMGp+966gkbFzkahzNK5HThuSdMGfwy5Nu4IyJ5p24xmnF9ZtSjXt4pt8 =
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=2982dFRzVKu5Ydbr146Lw56okjI=; b=RgBi+4btdV IPYIDbcddv4osp++94yS7ZEwN227KxvjNdzlpY43mdsu5JMTFPwQ2nRAyNdZ8K0e La46lDsWaPPUtucFufxQRezuwYlAnyza1ETC0E3F4sSQFKPCiCl/UwmcfduvfVc7 MMwmikH8L4TXZoP/uqqzzpJtnhdk9cjTM=
Received: from [192.168.1.40] (pool-96-231-10-176.washdc.east.verizon.net [96.231.10.176]) (Authenticated sender: [email-masked]) by homiemail-a1.g.dreamhost.com (Postfix) with ESMTPA id D36EE34806C for ; Mon, 20 Dec 2010 12:52:48 -0800 (PST)
From: Matt McCutchen
To: [email-masked]
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 20 Dec 2010 15:52:47 -0500
Message-ID: <[email-masked]>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.1
Content-Transfer-Encoding: 7bit
Subject: [keyassure] Goals of DANE
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 20 Dec 2010 20:51:00 -0000

On Mon, 2010-12-20 at 15:30 -0500, Paul Wouters wrote:
> DANE is about reducing errors to users, not adding to them.

Mmm... there's not much of an excuse for errors now, with at least one
public CA offering certificates free of charge. Why some site admins
are happy to register with ICANN but claim a philosophical objection to
getting a free cert from a public CA is beyond me. Though for large
organizations, DANE may be more convenient than requesting lots of
certificates individually from a public CA.

The major draw for me is to not be exposed to the public CAs.

--
Matt

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1715C3A6AC8 for ; Mon, 20 Dec 2010 12:48:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.606
X-Spam-Level:
X-Spam-Status: No, score=-7.606 tagged_above=-999 required=5 tests=[AWL=1.512, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, 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 bHxONGDYFUfF for ; Mon, 20 Dec 2010 12:48:48 -0800 (PST)
Received: from den-mipot-001.corp.ebay.com (den-mipot-001.corp.ebay.com [216.113.175.152]) by core3.amsl.com (Postfix) with ESMTP id BDD743A68C1 for ; Mon, 20 Dec 2010 12:48:48 -0800 (PST)
DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:CC: Date:Subject:Thread-Topic:Thread-Index:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: x-ems-proccessed:x-ems-stamp:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=Iv8qOaboqMxZsWu4tIRCSio5/EqjOi9rINzRFYk/9H4Ev1Lf1bPB/WI/ geK3jc4JK5yfsvk8GiWzT3fYkcFqbiGZd1s8U7Sf8Q8REbCbF8dgs1RfX 2KoKcRuCgWvnrz4;
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=[email-masked]; q=dns/txt; s=ppinc; t=1292878244; x=1324414244; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; z=From:=20"Steingruebl,=20Andy"=20|To:=20Matt=20McCutchen=20, =20Zack=20Weinberg=0D=0A=09|CC: =20"[email-masked]"=20|Date:=20Mo n,=2020=20Dec=202010=2013:50:41=20-0700|Subject:=20RE:=20 [keyassure]=20HTTPS=20->=20HTTP=20downgrade|Message-ID: =20<5EE049BA3C6538409BBE6F1760F328ABEB19A2D39B@DEN-MEXMS- 001.corp.ebay.com>|References:=20<20101213220001.24500.52 050.idtracker@localhost>=0D=0A=09=0D=0A=09=0D=0A=09=0D=0A=09=0D=0A=09<12928 [email-masked]>=0D=0A=09=0D=0A=09< [email-masked]>=0D=0A=09=0D =0A=09=0D=0A=09=0D =0A=09=0D=0A=20<1292877142.1913.13.camel@mattlaptop2 .local>|In-Reply-To:=20<1292877142.1913.13.camel@mattlapt op2.local>|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=T3jGXWZrzEd1UAJF/OPv+VX1PB2eb5fBrcEQX/hjvkg=; b=WgpFh5T4Cjy/jFffsBouo0wrEXvHglmd4sTFrd6ji2haS9DE+Atxaob9 CbaKCuNuU3HxjNn+9uK0NLnWv+z/Wcj17u6nxza5Y4PLA5LD2IxOSDM7k VXzy1XJ+XztpYaA;
X-EBay-Corp: Yes
X-IronPort-AV: E=Sophos;i="4.60,203,1291622400"; d="scan'208";a="52443"
Received: from den-vtenf-002.corp.ebay.com (HELO DEN-MEXHT-002.corp.ebay.com) ([10.101.112.213]) by den-mipot-001.corp.ebay.com with ESMTP; 20 Dec 2010 12:50:43 -0800
Received: from DEN-MEXMS-001.corp.ebay.com ([10.241.16.225]) by DEN-MEXHT-002.corp.ebay.com ([10.241.17.53]) with mapi; Mon, 20 Dec 2010 13:50:42 -0700
From: "Steingruebl, Andy"
To: Matt McCutchen , Zack Weinberg
Date: Mon, 20 Dec 2010 13:50:41 -0700
Thread-Topic: [keyassure] HTTPS -> HTTP downgrade
Thread-Index: AcughSIIfizq2zDbRya+oNorifXdCQAAODdQ
Message-ID: <[email-masked]>
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A==
x-ems-stamp: 6unyRJL6TAhVYq5dPVwrVQ==
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter: Scanned
Cc: "[email-masked]"
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 20 Dec 2010 20:48:50 -0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Matt McCutchen
> > >
> > > It would be a common deployment to leave port 80 running for old
> > > clients not supporting these records to continue to work (and be
> > > vulnerable to sslstrip)
> >
> > Why would you not simply turn off port 80? Users of older clients
> > would have to manually type https://, and inbound links might break,
> > but I don't see any other negative consequences.

Actually, you'd shut off tons of traffic to your site. I don't have total =
numbers, but I can try to get them.

> Those are pretty significant consequences! I'd imagine the last thing a =
major
> online business wants is for a significant fraction of its customers to s=
uddenly
> get an error page when they type in the name of the site. It would take =
a
> massive PR effort to get everyone to upgrade their browsers or type https=
: .
> Yes, that's eventually needed anyway to realize the security benefits, bu=
t for
> now I strongly prefer a scheme that can be adopted without breaking legac=
y
> clients. (Perhaps the PayPal folks would offer their perspective?)

Since you asked :)

1. The current HSTS header isn't a problem for clients that don't understan=
d it.

2. The current design does require potentially insecure bootstrapping. We'=
re well aware of that. We wanted it out there sooner rather than later to p=
rotect better than was currently possible against sslstrip-type attacks. W=
ith a proper max-age parameter, you're pretty safe against sslstrip if your=
whole site is HTTPS, *and* users don't get attacked (MITM)the first time =
they visit you. In advance of the DNSSEC approach, Google also has the STS=
-preloaded list stuffed into Chrome, and www.paypal.com is on the list.

3. We don't want to shut off legacy clients that don't understand HSTS, so =
we have to leave port-80 running. We try very hard though to only redirect =
to HTTPS from HTTP, and never serve any content over HTTP.

4. Somewhere in a previous thread was the suggestion of browses simply tryi=
ng port-443 first, and only if they don't get a response to downgrade. The=
problem here is than an active attacker can spoof the RST for port-443, an=
d then MITM port-80.

5. Most of our links in search engines also show as HTTPS these days, so a =
lot of traffic doesn't come over port-80 anymore. I wish I had some statis=
tics though.

6. As long as I'm randomly brain-dumping, OOB STS policy delivery helps to =
solve the slight privacy problem currently present with HSTS. A server can=
detect whether it has seen you before by testing whether you have HSTS in =
effect for a given domain. With OOB signaling, we avoid this bootstrapping =
problem, though I suppose if clients cache they can still have a problem. =
Privacy-mode though doesn't have to cache anymore, but can still get HSTS b=
enefits, and non-private mode can cache for performance reasons if necessar=
y.

Sorry for the brain-dump, I was on vacation for a week and just catching up=
...

- Andy

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CB3D3A68C1 for ; Mon, 20 Dec 2010 12:48:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.124
X-Spam-Level:
X-Spam-Status: No, score=-2.124 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_OBFU_AMP2B=2.555]
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 fjdKg-6E5xY0 for ; Mon, 20 Dec 2010 12:48:25 -0800 (PST)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id EC1323A68C7 for ; Mon, 20 Dec 2010 12:48:24 -0800 (PST)
Received: by gyd12 with SMTP id 12so1483397gyd.31 for ; Mon, 20 Dec 2010 12:50:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=nPhGuF1JOk2QNENOCH0rAv26o4acaVKUYw6t8FHt5Ds=; b=ikHlIlxq2844wx085EIX5qrj40XKTXQniy5V5dv052ixjhyh+KWT9Qo87rlng2kNxa LHzfennpMRVzmkGN5Lnrq8vkdLBqyPv1bYjZA0anI/kVNbFRAygGf4qM3dbLDtNEYCG2 4bAiSvD/KWZU/xqfxTWxykrgyw1YSe2wNHMus=
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=xcZ+ag20Ct9sVUXuof6Osn/JD4MSOTaiYtX+xktWSJEXn6S9UC0MX5S5gI+496dn+P BiPZ3D4QbnII3u9NbMZZHqbBfHYxvfzEgr56/cNLz+n54qImbEEyg1GegUcASRZLm4WQ pyG666XgEEQ2FmWxmV0hAdcznpl0viKc5BZ4k=
MIME-Version: 1.0
Received: by 10.100.93.11 with SMTP id q11mr1203013anb.35.1292878217907; Mon, 20 Dec 2010 12:50:17 -0800 (PST)
Received: by 10.100.31.8 with HTTP; Mon, 20 Dec 2010 12:50:17 -0800 (PST)
In-Reply-To: <[email-masked]>
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Mon, 20 Dec 2010 20:50:17 +0000
Message-ID:
From: Phillip Hallam-Baker
To: Matt McCutchen
Content-Type: multipart/alternative; boundary=0016e642d388ea8de50497ddaa40
Cc: [email-masked]
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 20 Dec 2010 20:48:30 -0000

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

Must use TLS is only one use case and not necessarily the most interesting.

TLS is always offered is rather more interesting to me. Particularly when
combined with lightweight DNSSEC validated keys.

As of today 0% of browsers support DANE. And it will be ten years or so
before the proportion supporting DANE is above 90%. If all DANE offers is a
'cheap' substitute for CA issued certs it is probably going to fail. Who is
going to deploy such a scheme at a server? It is certainly not going to work
for any commercial application that requires security since nobody is going
to accept a 10% drop in sales as the price of using a 'free' cert.

Now consider what is possible when a site has a way of saying 'TLS is always
offered, here is the key'.

Deployment now becomes a no-downside option for any server which would not
normally have used security.

On Mon, Dec 20, 2010 at 8:32 PM, Matt McCutchen wrote:

> On Mon, 2010-12-20 at 11:35 -0800, Zack Weinberg wrote:
> > On Mon, Dec 20, 2010 at 10:24 AM, Paul Wouters
> wrote:
> > > On Mon, 20 Dec 2010, Paul Hoffman wrote:
> > >> ... If you are running
> > >> a server on port 80, you *cannot* prevent ssslstrip attacks: that is
> the
> > >> whole point of the HASTLS document.
> > >
> > > - for clients not supporting HASTLS/TLSA, we can do nothing to prevent
> > > sslstrip
> > > - for clients supporting HASTLS/TLSA, we can prevent sslstrip, if we
> can
> > > convey this by either the presence of HAS/TLSA or an option in those
> records.
> > >
> > > It would be a common deployment to leave port 80 running for old
> clients not
> > > supporting these records to continue to work (and be vulnerable to
> sslstrip)
> >
> > Why would you not simply turn off port 80? Users of older clients
> > would have to manually type https://, and inbound links might break,
> > but I don't see any other negative consequences.
>
> Those are pretty significant consequences! I'd imagine the last thing a
> major online business wants is for a significant fraction of its
> customers to suddenly get an error page when they type in the name of
> the site. It would take a massive PR effort to get everyone to upgrade
> their browsers or type https: . Yes, that's eventually needed anyway to
> realize the security benefits, but for now I strongly prefer a scheme
> that can be adopted without breaking legacy clients. (Perhaps the
> PayPal folks would offer their perspective?)
>
> --
> Matt
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

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

Must use TLS is only one use case and not necessarily the most interesting.=

TLS is always offered is rather more interesting to me.=
Particularly when combined with lightweight DNSSEC validated keys.

As of today 0% of browsers support DANE. And it will be=
ten years or so before the proportion supporting DANE is above 90%. If all=
DANE offers is a 'cheap' substitute for CA issued certs it is prob=
ably going to fail. Who is going to deploy such a scheme at a server? It is=
certainly not going to work for any commercial application that requires s=
ecurity since nobody is going to accept a 10% drop in sales as the price of=
using a 'free' cert.

Now consider what is possible when a sit=
e has a way of saying 'TLS is always offered, here is the key'.=A0<=
/div>

Deployment now becomes a no-downside option for an=
y server which would not normally have used security.=A0

On Mon, D=
ec 20, 2010 at 8:32 PM, Matt McCutchen <[email-masked]> wrote:

On Mon, 2010-12-20 at 11:35 -0800, Zack Weinberg wrote:
> On Mon, Dec 20, 2010 at 10:24 AM, Paul Wouters <[email-masked]> wrote:

> > On Mon, 20 Dec 2010, Paul Hoffman wrote:

> >> ... If you are running

> >> a server on port 80, you *cannot* prevent ssslstrip attacks: =
that is the

> >> whole point of the HASTLS document.

> >

> > - for clients not supporting HASTLS/TLSA, we can do nothing to pr=
event

> > =A0 sslstrip

> > - for clients supporting HASTLS/TLSA, we can prevent sslstrip, if=
we can

> > =A0 convey this by either the presence of HAS/TLSA or an option i=
n those records.

> >

> > It would be a common deployment to leave port 80 running for old =
clients not

> > supporting =A0these records to continue to work (and be vulnerabl=
e to sslstrip)

>

> Why would you not simply turn off port 80? =A0Users of older clients
> would have to manually type https://, and inbound links might break,
> but I don't see any other negative consequences.

Those are pretty significant consequences! =A0I'd imagine the las=
t thing a

major online business wants is for a significant fraction of its

customers to suddenly get an error page when they type in the name of

the site. =A0It would take a massive PR effort to get everyone to upgrade
their browsers or type https: . =A0Yes, that's eventually needed anyway=
to

realize the security benefits, but for now I strongly prefer a scheme

that can be adopted without breaking legacy clients. =A0(Perhaps the

PayPal folks would offer their perspective?)

--

Matt

_______________________________________________

keyassure mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/keyassure

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

--0016e642d388ea8de50497ddaa40--

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F20E3A6AC4 for ; Mon, 20 Dec 2010 12:30:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVkFlKaxgxNv for ; Mon, 20 Dec 2010 12:30:30 -0800 (PST)
Received: from homiemail-a37.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by core3.amsl.com (Postfix) with ESMTP id 54B5B3A6AC3 for ; Mon, 20 Dec 2010 12:30:30 -0800 (PST)
Received: from homiemail-a37.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTP id 9CA771D006B; Mon, 20 Dec 2010 12:32:24 -0800 (PST)
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=hcTgShGU64TmjbS2x/emIVDwG3GP8R5T7nHBiXBqb98 LMe/Nle1NCYaMtvUFVXiCc0QWYKRCZirG0PWnCl5MlgGqf5Q+8B8DKu+TqJZT5r0 ynCrL/MMHt5YeLtXoyUlc2/X7WRrpnOVWyrMAW0q15YyHH3raEMdISNVAwhohWDA =
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=A0t2/e+nov+gd447PpWGczSglgY=; b=oQ0VxvUXEY /pGLy+G7MjGOf+50snvbjd7FXSEI/kLl48tj1XUQ5g9R9Mp0ojX0qx3a+Cf2IHK7 tBozCuwXj5OH7/FYYLCU3YyqyC/HP5jaYMUWna8lGNSzAV96G0kTQV4RX+yfIUcS qMvKjHnbi330LFrrHtAGD2AK18ZFk5Q9E=
Received: from [192.168.1.40] (pool-96-231-10-176.washdc.east.verizon.net [96.231.10.176]) (Authenticated sender: [email-masked]) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTPA id 277C61D0065; Mon, 20 Dec 2010 12:32:24 -0800 (PST)
From: Matt McCutchen
To: Zack Weinberg
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 20 Dec 2010 15:32:22 -0500
Message-ID: <[email-masked]>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.1
Content-Transfer-Encoding: 7bit
Cc: [email-masked]
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 20 Dec 2010 20:30:31 -0000

On Mon, 2010-12-20 at 11:35 -0800, Zack Weinberg wrote:
> On Mon, Dec 20, 2010 at 10:24 AM, Paul Wouters wrote:
> > On Mon, 20 Dec 2010, Paul Hoffman wrote:
> >> ... If you are running
> >> a server on port 80, you *cannot* prevent ssslstrip attacks: that is the
> >> whole point of the HASTLS document.
> >
> > - for clients not supporting HASTLS/TLSA, we can do nothing to prevent
> > sslstrip
> > - for clients supporting HASTLS/TLSA, we can prevent sslstrip, if we can
> > convey this by either the presence of HAS/TLSA or an option in those records.
> >
> > It would be a common deployment to leave port 80 running for old clients not
> > supporting these records to continue to work (and be vulnerable to sslstrip)
>
> Why would you not simply turn off port 80? Users of older clients
> would have to manually type https://, and inbound links might break,
> but I don't see any other negative consequences.

Those are pretty significant consequences! I'd imagine the last thing a
major online business wants is for a significant fraction of its
customers to suddenly get an error page when they type in the name of
the site. It would take a massive PR effort to get everyone to upgrade
their browsers or type https: . Yes, that's eventually needed anyway to
realize the security benefits, but for now I strongly prefer a scheme
that can be adopted without breaking legacy clients. (Perhaps the
PayPal folks would offer their perspective?)

--
Matt

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42FD43A6AB9 for ; Mon, 20 Dec 2010 12:28:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.586
X-Spam-Level:
X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 1yKkuayekn0N for ; Mon, 20 Dec 2010 12:28:29 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 71AC53A6887 for ; Mon, 20 Dec 2010 12:28:29 -0800 (PST)
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 6CC3AC45B; Mon, 20 Dec 2010 15:30:23 -0500 (EST)
Date: Mon, 20 Dec 2010 15:30:23 -0500 (EST)
From: Paul Wouters
To: Zack Weinberg
In-Reply-To:
Message-ID:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: [email-masked], Paul Hoffman
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 20 Dec 2010 20:28:30 -0000

On Mon, 20 Dec 2010, Zack Weinberg wrote:

> Why would you not simply turn off port 80? Users of older clients
> would have to manually type https://, and inbound links might break,
> but I don't see any other negative consequences.

You are suggesting breaking everyone's browser. That seems like the worst
thing we can do. DANE is about reducing errors to users, not adding to them.

It also implies users are aware of http vs https. They should not need to be.

Paul

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FA233A6887 for ; Mon, 20 Dec 2010 12:25:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.586
X-Spam-Level:
X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 5uMaW+-uYhvX for ; Mon, 20 Dec 2010 12:25:05 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 0CF4C3A68B6 for ; Mon, 20 Dec 2010 12:25:05 -0800 (PST)
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 D6AC5C45B; Mon, 20 Dec 2010 15:26:58 -0500 (EST)
Date: Mon, 20 Dec 2010 15:26:58 -0500 (EST)
From: Paul Wouters
To: Paul Hoffman
In-Reply-To:
Message-ID:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: [email-masked]
Subject: Re: [keyassure] TLSA and HASTLS
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 20 Dec 2010 20:25:06 -0000

On Mon, 20 Dec 2010, Paul Hoffman wrote:

>>> Just to be clear: are you are proposing DANE adding "bare public key" *before* any version of TLS allows that? That means that DANE will be changing the TLS semantics for all current versions of TLS. It is possible we could do that, but that seems a bit daunting given the low value of the first three items on your list.
>>
>> Is there a technical reason why it can't?
>
> I don't think so. I said "daunting" because having a new WG like DANE say "we're changing the semantics of all existing versions of TLS" is procedurally, er, interesting.

Okay. How about adding a private use type so we have something to code
against while we look into adding a new "bare public key" option to TLS?

> Using PKIX certificates for TLS is a "policy" that every vendor that uses TLS has chosen to do already.

We could limit the flag/option to the non-PKIX case? So we would in no
way alter the policy of PKIX as implemented to date.

Paul

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E4D43A68B6 for ; Mon, 20 Dec 2010 12:21:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.589
X-Spam-Level:
X-Spam-Status: No, score=-101.589 tagged_above=-999 required=5 tests=[AWL=0.457, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 s8gfJGCXP76X for ; Mon, 20 Dec 2010 12:21:07 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 847703A68A4 for ; Mon, 20 Dec 2010 12:21:07 -0800 (PST)
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 oBKKMxnx061626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Dec 2010 13:23:01 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]>
Date: Mon, 20 Dec 2010 12:22:58 -0800
To: Zack Weinberg , Paul Wouters
From: Paul Hoffman
Content-Type: text/plain; charset="us-ascii"
Cc: [email-masked]
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 20 Dec 2010 20:21:08 -0000

At 11:35 AM -0800 12/20/10, Zack Weinberg wrote:
>On Mon, Dec 20, 2010 at 10:24 AM, Paul Wouters wrote:
>> On Mon, 20 Dec 2010, Paul Hoffman wrote:
>>> ... If you are running
>>> a server on port 80, you *cannot* prevent ssslstrip attacks: that is the
>>> whole point of the HASTLS document.
>>
>> - for clients not supporting HASTLS/TLSA, we can do nothing to prevent
>> sslstrip
>> - for clients supporting HASTLS/TLSA, we can prevent sslstrip, if we can
>> convey this by either the presence of HAS/TLSA or an option in those records.
>>
>> It would be a common deployment to leave port 80 running for old clients not
>> supporting these records to continue to work (and be vulnerable to sslstrip)
>
>Why would you not simply turn off port 80? Users of older clients
>would have to manually type https://, and inbound links might break,
>but I don't see any other negative consequences.

If the client doesn't have the right trust anchor, they will get dire warnings and possibly be prevented from getting to the site. This is a prime motivator for the DANE work.

--Paul Hoffman, Director
--VPN Consortium

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F9693A68BE for ; Mon, 20 Dec 2010 12:19:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.586
X-Spam-Level:
X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 tfKfIFs2UuxS for ; Mon, 20 Dec 2010 12:19:54 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 41D913A68B6 for ; Mon, 20 Dec 2010 12:19:53 -0800 (PST)
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 354F4C412; Mon, 20 Dec 2010 15:21:47 -0500 (EST)
Date: Mon, 20 Dec 2010 15:21:46 -0500 (EST)
From: Paul Wouters
To: Paul Hoffman
In-Reply-To:
Message-ID:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: [email-masked]
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 20 Dec 2010 20:19:55 -0000

On Mon, 20 Dec 2010, Paul Hoffman wrote:

> At 1:24 PM -0500 12/20/10, Paul Wouters wrote:
>> We would need to signal to new clients "ignore unseured port".
>
> This, again, is you saying to a client "I could care less what your policy is, you must do what I say". That's a model of security that has not been widely accepted, to say the least.

How is that different from telling the client what SSL version, ciphers,
keysizes, hashing algos are accepted for a specific TLS connection? See
port 80 as "SSL0, null cipher, hash md5, keysize 0" :P

>> A current "hack" would be to specify "0 443", while in fact keeping things running on port 80.
>> This would tell new clients to never fallback on port 80, while older clients could still use
>> it (while of course remaining vulnerable to sslstrip)
>
> ...and that goes directly against the purpose of the expanded semantics of HASTLS over the current draft of HSTS: it tells the client in a secure fashion what is reality and assumes that the client will use the client's policy in the face of known reality.

Then give me an alternative to accomplish protection against
sslstrip. HSTS does not do any good because the attacker can perform a
MITM by taking in the clients HTTP and starting its own HTTPS to the
remote server, and mangle/attack everything. You cannot really leave
this attack out of scope.

>> My proposal was for some kind of change to formalise this, so that the most common deployment
>> would not be something not part of the original design (the lying about port 80)
>
> You can propose lying; I would object and instead continue to propose honesty. It really comes down to that.

How do we protect the user that implements DANE protocols from
sslstrip? For this exercise, you may not use PKIX based trust.

It's an obvious hole in the drafts. I've made suggestions you don't
like. Your only alternative offered has been a "design a totally new draft
for that". Your objection is based on "DNSSEC cannot dictate policy, only
PKIX may do that". Yet DANE is meant to provide an alternative to PKIX.

If we can't even use these new drafts to protect browsers, why ARE we
writing new drafts?

Paul

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DE1D3A68A6 for ; Mon, 20 Dec 2010 11:41:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.586
X-Spam-Level:
X-Spam-Status: No, score=-101.586 tagged_above=-999 required=5 tests=[AWL=0.460, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 s4oyog6XSQyC for ; Mon, 20 Dec 2010 11:41:26 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id DBAFB3A688B for ; Mon, 20 Dec 2010 11:41:26 -0800 (PST)
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 oBKJhJhk059814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Dec 2010 12:43:20 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]>
Date: Mon, 20 Dec 2010 11:43:18 -0800
To: Paul Wouters
From: Paul Hoffman
Content-Type: text/plain; charset="us-ascii"
Cc: [email-masked]
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 20 Dec 2010 19:41:27 -0000

At 1:24 PM -0500 12/20/10, Paul Wouters wrote:
>We would need to signal to new clients "ignore unseured port".

This, again, is you saying to a client "I could care less what your policy is, you must do what I say". That's a model of security that has not been widely accepted, to say the least.

>A current "hack" would be to specify "0 443", while in fact keeping things running on port 80.
>This would tell new clients to never fallback on port 80, while older clients could still use
>it (while of course remaining vulnerable to sslstrip)

...and that goes directly against the purpose of the expanded semantics of HASTLS over the current draft of HSTS: it tells the client in a secure fashion what is reality and assumes that the client will use the client's policy in the face of known reality.

>My proposal was for some kind of change to formalise this, so that the most common deployment
>would not be something not part of the original design (the lying about port 80)

You can propose lying; I would object and instead continue to propose honesty. It really comes down to that.

--Paul Hoffman, Director
--VPN Consortium

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18AA83A68A6 for ; Mon, 20 Dec 2010 11:33:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sMqX9UToIJWI for ; Mon, 20 Dec 2010 11:33:49 -0800 (PST)
Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by core3.amsl.com (Postfix) with ESMTP id 1E38E3A6892 for ; Mon, 20 Dec 2010 11:33:48 -0800 (PST)
Received: by wwi17 with SMTP id 17so3182513wwi.1 for ; Mon, 20 Dec 2010 11:35:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=s8QPiev5J9IXl0UjjzZbEtIx1qBbBxuYxbDPPFf2uxI=; b=fjmf8DAxyOMM/dtsJIOr7IXmEoYbAENkB+Ht6ci/K9kOV4HHcWkFJtnsuJ0Rxj7q3Z uRTFzrboARS6GECtNpngvyoPl54VgsIG3OQarwbDwq98xgZg30eTMqW9bX/5n8rP32AP 4Gt1Vf1ySSWJXDnv4ie41USJaCYmxY/n94cvo=
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=MCGHLvsSNDb73yslVNAnReb6ZB4qUCXHswMeo4qdGYDN8mGz21l8LOCnqdbjGZj7eF Jom43uG+Evn6uWLCyoKxkL3uu8t07e0+A7HeME9XHeC6349QDg/eCZTfLPyFdkldhr89 /68s7NwCU7wq1nsaDHtZls6FbuDNJQVJWFrDE=
MIME-Version: 1.0
Received: by 10.227.32.129 with SMTP id c1mr2814241wbd.186.1292873742844; Mon, 20 Dec 2010 11:35:42 -0800 (PST)
Sender: [email-masked]
Received: by 10.227.133.149 with HTTP; Mon, 20 Dec 2010 11:35:42 -0800 (PST)
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]>
Date: Mon, 20 Dec 2010 11:35:42 -0800
X-Google-Sender-Auth: Ii73QFtfATUWuZzht0D-lH97gPw
Message-ID:
From: Zack Weinberg
To: Paul Wouters
Content-Type: text/plain; charset=UTF-8
Cc: [email-masked], Paul Hoffman
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 20 Dec 2010 19:33:50 -0000

On Mon, Dec 20, 2010 at 10:24 AM, Paul Wouters wrote:
> On Mon, 20 Dec 2010, Paul Hoffman wrote:
>> ... If you are running
>> a server on port 80, you *cannot* prevent ssslstrip attacks: that is the
>> whole point of the HASTLS document.
>
> - for clients not supporting HASTLS/TLSA, we can do nothing to prevent
> sslstrip
> - for clients supporting HASTLS/TLSA, we can prevent sslstrip, if we can
> convey this by either the presence of HAS/TLSA or an option in those records.
>
> It would be a common deployment to leave port 80 running for old clients not
> supporting these records to continue to work (and be vulnerable to sslstrip)

Why would you not simply turn off port 80? Users of older clients
would have to manually type https://, and inbound links might break,
but I don't see any other negative consequences.

zw

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CB783A685C for ; Mon, 20 Dec 2010 10:57:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.494
X-Spam-Level:
X-Spam-Status: No, score=-1.494 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, 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 3UP4ondN50AT for ; Mon, 20 Dec 2010 10:57:49 -0800 (PST)
Received: from rotring.dds.nl (rotring.dds.nl [85.17.178.138]) by core3.amsl.com (Postfix) with ESMTP id 3F39D3A67F4 for ; Mon, 20 Dec 2010 10:57:49 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by rotring.dds.nl (Postfix) with ESMTP id 8A1A658580 for ; Mon, 20 Dec 2010 19:59:42 +0100 (CET)
Received: from vylkir.localdomain (195-241-9-117.adsl.dds.nl [195.241.9.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rotring.dds.nl (Postfix) with ESMTPSA id 3D23758621 for ; Mon, 20 Dec 2010 19:59:36 +0100 (CET)
Message-ID: <[email-masked]>
Date: Mon, 20 Dec 2010 19:59:33 +0100
From: "W.C.A. Wijngaards"
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc13 Thunderbird/3.1.7
MIME-Version: 1.0
To: [email-masked]
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.96.4 at rotring
X-Virus-Status: Clean
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 20 Dec 2010 18:57:50 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Steve,

On 12/20/2010 07:10 PM, Steve Schultze wrote:
> As Matt's text helps to make explicit, there are two points at which the
> client MAY choose to fall back on PKIX:
> 1) Non-DNSSEC secured domains
> 2) DNSSEC-secured domains that do not have a matching TLSA record

I want to split 2 into two parts.
2.1) DNSSEC-secured domains that have zero TLSA records.
2.2) DNSSEC-secured domains that have non-matching TLSA records.

2.1 MAY choose to fall back on PKIX.
2.2 MUST be access denied, otherwise you have a 'downgrade to PKIX'.

And yes, in DNSSEC you can securely detect that there are 0 records.

> Thus, this is all a question what the domain operators have implemented
> rather than a MITM scenario.

So, an operator can 'opt-in' by deploying DNSSEC-signed TLSA records.

Best regards,
Wouter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk0Pp5UACgkQkDLqNwOhpPgedgCgorgz9IMxo7texRQLJKQuTtsW
/Z0An3uZ8Sw5vMpTVIkmWBsM+vOkDRdi
=6FVW
-----END PGP SIGNATURE-----

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 315FC3A6998 for ; Mon, 20 Dec 2010 10:30:57 -0800 (PST)
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.464, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 EJg4c8366Yvx for ; Mon, 20 Dec 2010 10:30:56 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 10EEF3A6856 for ; Mon, 20 Dec 2010 10:30:55 -0800 (PST)
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 oBKIWm22056494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Dec 2010 11:32:49 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]>
Date: Mon, 20 Dec 2010 10:32:47 -0800
To: Paul Wouters
From: Paul Hoffman
Content-Type: text/plain; charset="us-ascii"
Cc: [email-masked]
Subject: Re: [keyassure] TLSA and HASTLS
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 20 Dec 2010 18:30:57 -0000

At 1:18 PM -0500 12/20/10, Paul Wouters wrote:
>>Just to be clear: are you are proposing DANE adding "bare public key" *before* any version of TLS allows that? That means that DANE will be changing the TLS semantics for all current versions of TLS. It is possible we could do that, but that seems a bit daunting given the low value of the first three items on your list.
>
>Is there a technical reason why it can't?

I don't think so. I said "daunting" because having a new WG like DANE say "we're changing the semantics of all existing versions of TLS" is procedurally, er, interesting.

>>In specific, your #1 is "you must use what I am telling you regardless of your policy", and the WG has not decided it wants to do that. There was wide disagreement during our BoF phase, and we have not had a consensus call on this yet. Further, if we did decide we want to do that, it could be achieved with a flag, not with a change to TLS.
>
>But you now have policy enforced too, namely the certificate contents,
>such as CN= or O= or Expiry etc. And they bring in a whole branch of
>dependancies on non-DNSSEC trust.

If we choose to go the "you must use what I am telling you regardless of your policy" route, and do it with a flag instead of an inherent policy, there no more semantics to the PKIX certificate.

>>From what I understood from browser vendors, is that it is important
>that non-validated data is limited because it does not fit well into
>their model. So a CN= that is not validated will fail to skip the
>CA validation chain. Having an explicite type that allows them to
>pick just the public key and nothing else would help tremendously.
>Whether you call this "policy" or not is somewhat semantec.

Using PKIX certificates for TLS is a "policy" that every vendor that uses TLS has chosen to do already.

>>Your #2 and #2 are, in my opinion, FUD. If there is a preimage attack on a signature algorithm, it affects much more than just the signature used in the TLSA record: it affects both DNSSEC and TLS as well. Using preimage strength of one tiny part of a system as an argument for us changing TLS is false security. Similarly, if you think TLS is open to error attacks from PKIX, change TLS. You haven't tried to do so (at least from my brief review of the TLS WG archives), and trying to do it through DANE seems really inappropriate.
>
>What I was referring to the attack class from the md5 rapidssl hack from
>CCC two years ago
>
>https://blogs.verisign.com/ssl-blog/2008/12/on_md5_vulnerabilities_and_mit.php
>http://www.win.tue.nl/hashclash/rogue-ca/
>

You said "preimage", and this is a collision-reduction attack, so I misunderstood what you were talking about. Now, instead of a preimage attack, you are talking about trying to prevent careless (and/or clueless) CAs in your trust anchor pile from doing the wrong thing. That is a completely different attack, one that no protocol that has trust anchors (including DNSSEC!) can prevent.

>Yes, this one got plugged, but why have DNSSEC based trust exposed to
>these kind of attacks at all?

Your proposed solution doesn't prevent the attack: it just (silently) shifts it to the DNSSEC chain.

>DANE/keyassure is about using DNSSEC for trust, alongside fixing up the
>PKIX model by reducing some weaknesses addressed by proposals such as
>the CAA record and draft-saintandre-tls-server-id-check-12.
>
>I don't agree with you calling DNSSEC related issues "policy" but not
>applying the same words to PKIX related matters. Isn't making a distiction
>between type 2 and type 4 a policy?

You are mixing up two different policies. The one I said this WG had not dealt with is "you must do what I say"; the one you are talking about in PKIX is "your trust anchor pile is out of control".

--Paul Hoffman, Director
--VPN Consortium

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7928B3A6A92 for ; Mon, 20 Dec 2010 10:23:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.585
X-Spam-Level:
X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 kBBt6CEvD9X2 for ; Mon, 20 Dec 2010 10:23:06 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 8C9C03A6A07 for ; Mon, 20 Dec 2010 10:23:06 -0800 (PST)
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 5239FC45B; Mon, 20 Dec 2010 13:25:00 -0500 (EST)
Date: Mon, 20 Dec 2010 13:24:59 -0500 (EST)
From: Paul Wouters
To: Paul Hoffman
In-Reply-To:
Message-ID:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: [email-masked]
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 20 Dec 2010 18:23:08 -0000

On Mon, 20 Dec 2010, Paul Hoffman wrote:

>> But draft-hoffman-server-has-tls states:
>>
>> The HASTLS resource record type, whose value is TBD1, lists all of
>> the pairs of insecure/secure port pairs that are served on the host
>> named by the domain name.
>>
>> Which means that to support clients without TLSA/HASTLS suport (every
>> web browser), while protecting clients with TLSA/HASTLS support from
>> ssltrip attacks (a practical, not theoretical attack), I need to lie in
>> my HASTLS record and state I'm not running on port 80.
>
> I don't see how you got to that conclusion; can you state it again? I think the first clause is irrelevant: if they do not support either record type, you don't need to do anything different in HASTLS. If you are running a server on port 80, you *cannot* prevent ssslstrip attacks: that is the whole point of the HASTLS document.

- for clients not supporting HASTLS/TLSA, we can do nothing to prevent sslstrip
- for clients supporting HASTLS/TLSA, we can prevent sslstrip, if we can convey
this by either the presence of HAS/TLSA or an option in those records.

It would be a common deployment to leave port 80 running for old clients not supporting
these records to continue to work (and be vulnerable to sslstrip)

It would be highly desirable that we can have new clients protected from sslstrip
even if we are forced to leave port 80 on in the forseeable future to support
older clients.

We would need to signal to new clients "ignore unseured port".

A current "hack" would be to specify "0 443", while in fact keeping things running on port 80.
This would tell new clients to never fallback on port 80, while older clients could still use
it (while of course remaining vulnerable to sslstrip)

My proposal was for some kind of change to formalise this, so that the most common deployment
would not be something not part of the original design (the lying about port 80)

Paul

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2CA13A6AAB for ; Mon, 20 Dec 2010 10:16:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.41
X-Spam-Level:
X-Spam-Status: No, score=-3.41 tagged_above=-999 required=5 tests=[AWL=-1.411, BAYES_00=-2.599, J_CHICKENPOX_42=0.6]
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 C17nnhpLlYaA for ; Mon, 20 Dec 2010 10:16:55 -0800 (PST)
Received: from ppa01.Princeton.EDU (ppa01.Princeton.EDU [128.112.128.213]) by core3.amsl.com (Postfix) with ESMTP id E97A93A6AA1 for ; Mon, 20 Dec 2010 10:16:54 -0800 (PST)
Received: from csgsmtp201l.Princeton.EDU (csgsmtp201l.Princeton.EDU [128.112.134.60]) by ppa01.Princeton.EDU (8.14.3/8.14.3) with ESMTP id oBKIImhT015719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 20 Dec 2010 13:18:48 -0500
Received: from new-host.home (pool-173-71-100-208.cmdnnj.fios.verizon.net [173.71.100.208]) (authenticated bits=0) by csgsmtp201l.Princeton.EDU (8.13.8/8.12.9) with ESMTP id oBKIIm5Y000445 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 20 Dec 2010 13:18:48 -0500
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Apple Message framework v1082)
From: Steve Schultze
In-Reply-To: <[email-masked]>
Date: Mon, 20 Dec 2010 13:18:47 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <[email-masked]>
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
To: [email-masked]
X-Mailer: Apple Mail (2.1082)
X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6202 signatures=655220
X-Proofpoint-Spam-Details: rule=quarantine_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-1010190000 definitions=main-1012200097
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 20 Dec 2010 18:16:56 -0000

On Dec 18, 2010, at 1:13 PM, Matt McCutchen wrote:
> On Sat, 2010-12-18 at 12:54 -0500, James Cloos wrote:
>>>>>>> "MM" =3D=3D Matt McCutchen writes:
>>=20
>>>>> Unless the client previously noted that a given remote uses DANE,
>>>>> how can it tell that a non-secure DNS lookup is a MITM attack and
>>>>> not just a legacy site?
>>>>=20
>>>> SS> It can't. According to Matt's suggested text:
>>=20
>> Which of course was my point. =E2=98=BA
>>=20
>> MM> It can, because legacy sites have a NSEC for the DS record in the
>> MM> parent zone. That was our point here:
>>=20
>> MM> =
http://www.ietf.org/mail-archive/web/keyassure/current/msg01196.html
>>=20
>> Why do you think that a MITM would only munge a child zone and not =
also
>> its parents?
>=20
> By configuring a trust anchor for the root zone, you are telling the
> client to demand that the zone be signed with that key. It will not
> allow the entire DNSSEC to be downgraded away. For it to accept a =
site
> as legacy ("insecure"), there must be an NSEC for DS somewhere above =
the
> site that chains to the trust anchor.
>=20
> This is basic DNSSEC stuff explained in RFC 4033. I would rather not
> keep rehashing it here.

Yes, it is not possible to MITM at the DNSSEC layer by removing DNSSEC
validation (as I now understand). However, if you presume that the
domain truly is not DNSSEC secured, then one can certainly MITM the site
by substituting rogue PKIX credentials. In the case of a DNSSEC result
that gives an "insecure" result, the client can be sure that the zone is
not DNSSEC secured (because there was an NSEC for DS somewhere above
that zone), but it cannot know that it is not being PKIX MITM'ed. =
Perhaps this=20
was self-evident to everybody already given that it's largely the reason =
that this=20
WG exists. ;)=

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAA393A6AA4 for ; Mon, 20 Dec 2010 10:16:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.585
X-Spam-Level:
X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 XUHGLm+vqxha for ; Mon, 20 Dec 2010 10:16:22 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 2BDCE3A6A93 for ; Mon, 20 Dec 2010 10:16:22 -0800 (PST)
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 1376DC412; Mon, 20 Dec 2010 13:18:15 -0500 (EST)
Date: Mon, 20 Dec 2010 13:18:14 -0500 (EST)
From: Paul Wouters
To: Paul Hoffman
In-Reply-To:
Message-ID:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: [email-masked]
Subject: Re: [keyassure] TLSA and HASTLS
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 20 Dec 2010 18:16:23 -0000

On Mon, 20 Dec 2010, Paul Hoffman wrote:

>> 1) A validated message stating that the DNSSEC trust model is used, and no
>> CA/PKIX based trust model should ever be attempted on this host/service
>>
>> 2) Reduced play room for attackers to launch (pre)image attacks against the public
>> key for those not interested in CA/PKIX based trust model. By only hashing the
>> key there is a lot less room to play with then if fields like CN= and O= would
>> be part of the hash
>>
>> 3) Reduced attack room in parsing invalid/bogus CA/PKIX certificate properties
>> (if we define the new type to may only contain the minimum required X.509 fields)
>> I'm thinking here of badly place \0 values and ASN.1 parser errors.
>>
>> 3) As you brought up, perhaps support for a future "bare public key" TLS type
>> that operates purely on DNSSEC validation without any CA/PKIX.
>
> Just to be clear: are you are proposing DANE adding "bare public key" *before* any version of TLS allows that? That means that DANE will be changing the TLS semantics for all current versions of TLS. It is possible we could do that, but that seems a bit daunting given the low value of the first three items on your list.

Is there a technical reason why it can't?

> In specific, your #1 is "you must use what I am telling you regardless of your policy", and the WG has not decided it wants to do that. There was wide disagreement during our BoF phase, and we have not had a consensus call on this yet. Further, if we did decide we want to do that, it could be achieved with a flag, not with a change to TLS.

But you now have policy enforced too, namely the certificate contents,
such as CN= or O= or Expiry etc. And they bring in a whole branch of
dependancies on non-DNSSEC trust.

>From what I understood from browser vendors, is that it is important
that non-validated data is limited because it does not fit well into
their model. So a CN= that is not validated will fail to skip the
CA validation chain. Having an explicite type that allows them to
pick just the public key and nothing else would help tremendously.
Whether you call this "policy" or not is somewhat semantec.

> Your #2 and #2 are, in my opinion, FUD. If there is a preimage attack on a signature algorithm, it affects much more than just the signature used in the TLSA record: it affects both DNSSEC and TLS as well. Using preimage strength of one tiny part of a system as an argument for us changing TLS is false security. Similarly, if you think TLS is open to error attacks from PKIX, change TLS. You haven't tried to do so (at least from my brief review of the TLS WG archives), and trying to do it through DANE seems really inappropriate.

What I was referring to the attack class from the md5 rapidssl hack from
CCC two years ago

https://blogs.verisign.com/ssl-blog/2008/12/on_md5_vulnerabilities_and_mit.php
http://www.win.tue.nl/hashclash/rogue-ca/

Yes, this one got plugged, but why have DNSSEC based trust exposed to
these kind of attacks at all?

DANE/keyassure is about using DNSSEC for trust, alongside fixing up the
PKIX model by reducing some weaknesses addressed by proposals such as
the CAA record and draft-saintandre-tls-server-id-check-12.

I don't agree with you calling DNSSEC related issues "policy" but not
applying the same words to PKIX related matters. Isn't making a distiction
between type 2 and type 4 a policy?

Paul

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 601243A685C for ; Mon, 20 Dec 2010 10:08:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.848
X-Spam-Level:
X-Spam-Status: No, score=-3.848 tagged_above=-999 required=5 tests=[AWL=-1.250, 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 5Qk82T4iOqYa for ; Mon, 20 Dec 2010 10:08:52 -0800 (PST)
Received: from ppa05.princeton.edu (ppa05.Princeton.EDU [128.112.129.74]) by core3.amsl.com (Postfix) with ESMTP id C37BA3A6841 for ; Mon, 20 Dec 2010 10:08:51 -0800 (PST)
Received: from csgsmtp200l.Princeton.EDU (csgsmtp200l.Princeton.EDU [128.112.130.131]) by ppa05.princeton.edu (8.14.3/8.14.3) with ESMTP id oBKIAjGI029720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 20 Dec 2010 13:10:45 -0500
Received: from new-host.home (pool-173-71-100-208.cmdnnj.fios.verizon.net [173.71.100.208]) (authenticated bits=0) by csgsmtp200l.Princeton.EDU (8.13.8/8.12.9) with ESMTP id oBKIAiSC004855 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 20 Dec 2010 13:10:45 -0500
From: Steve Schultze
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: multipart/alternative; boundary=Apple-Mail-3-1028832105
Date: Mon, 20 Dec 2010 13:10:44 -0500
In-Reply-To:
To: [email-masked]
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]>
Message-Id: <[email-masked]>
X-Mailer: Apple Mail (2.1082)
X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6202 signatures=655220
X-Proofpoint-Spam-Details: rule=quarantine_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-1010190000 definitions=main-1012200094
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 20 Dec 2010 18:08:53 -0000

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

On Dec 20, 2010, at 7:44 AM, Ben Laurie wrote:
> On 16 December 2010 15:50, Steve Schultze wrote:
>> On Dec 16, 2010, at 10:45 AM, Ben Laurie wrote:
>>> On 16 December 2010 15:34, Steve Schultze wrote:
>>>> On Dec 16, 2010, at 3:48 AM, W.C.A. Wijngaards wrote:
>>>>> On 12/16/2010 05:54 AM, Steve Schultze wrote:
>>>>>> "If the application receives zero usable certificate =
associations, it
>>>>>> processes TLS in the normal fashion."
>>>>>=20
>>>>>> And, as I noted during our session in Beijing, the motivation for
>>>>>> permitting the client to choose is that if we mandate it one way =
or
>>>>>> the other, we fall into a trap. If the client MUST process TLS =
in
>>>>>> the normal fashion (aka, using PKIX) then we have provided a =
solution
>>>>>> that is no better than the status quo. If the client MUST give =
an
>>>>>> "access_denied" error, then nobody will use the standard early on =
in
>>>>>> deployment because the majority of sites will be unreachable.
>>>>>=20
>>>>> So, it is possible to say instead:
>>>>>=20
>>>>> If there are no TLSA records (this is DNSSEC validated by the =
lookup) or
>>>>> the domain is not signed with DNSSEC (this is signed by the parent
>>>>> domain): process normally (i.e. PKIX). This provides backwards
>>>>> compatibility.
>>>>=20
>>>> But what if the MITM overrides the genuine DNSSEC-signed record =
with a record that is not signed with DNSSEC? Is there some reason why =
this is not possible?
>>>=20
>>> Sure it's possible - and then the result is not DNSSEC-signed, and =
so
>>> should be ignored.
>>=20
>> But what does "ignored" mean? Does it mean the client must give an =
"access_denied" error? If so, you fall into the second of my two traps.
>=20
> No. Your second trap is fallacious: the majority of sites will not be
> DNSSEC enabled and therefore an unsigned response is expected.

Ok, presuming Matt's text (which I think is good):
http://www.ietf.org/mail-archive/web/keyassure/current/msg00923.html

"...if any query gives an "insecure" or "indeterminate" result,
KIDNS cannot be used with this TLS server, and the client MAY use an
alternative certificate validation method."

My point is simple: it is good to have MAY above rather than MUST
or MUST NOT. This allows the client to decide whether or not PKIX is=20
"good enough" in the case in which the server has not yet implemented=20
DANE. Early on, clients may choose not to require a matching TLSA=20
record when DNSSEC or DANE are not widely deployed. A security-
conscious client might eventually choose to require a matching TLSA=20
record. At that point, even if a given domain is not DNSSEC enabled
and an unsigned record is expected, the client may not deem it good
enough.

As Matt's text helps to make explicit, there are two points at which the
client MAY choose to fall back on PKIX:
1) Non-DNSSEC secured domains
2) DNSSEC-secured domains that do not have a matching TLSA record

I should note that when I said earlier in the thread "But what if the =
MITM=20
overrides the genuine DNSSEC-signed record with a record that is not=20
signed with DNSSEC? Is there some reason why this is not possible?"
I didn't understand that DNSSEC would be giving a result of "bogus",
which I admitted here:
http://www.ietf.org/mail-archive/web/keyassure/current/msg01197.html

Thus, this is all a question what the domain operators have implemented
rather than a MITM scenario.=

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

On 16 =
December 2010 15:50, Steve Schultze <[email-masked]> =
wrote:

On Dec 16, 2010, at 10:45 AM, Ben =
Laurie wrote:

On 16 December 2010 15:34, Steve Schultze <[email-masked]> =
wrote:

On Dec 16, 2010, at 3:48 AM, =
W.C.A. Wijngaards =
wrote:

On 12/16/2010 05:54 AM, Steve =
Schultze =
wrote:

"If =
the application receives zero usable certificate associations, =
it

processes TLS in the normal =
fashion."

And, =
as I noted during our session in Beijing, the motivation =
for

permitting the client to choose is that if we mandate it =
one way =
or

the =
other, we fall into a trap.  If the client MUST process TLS =
in

the =
normal fashion (aka, using PKIX) then we have provided a =
solution

that =
is no better than the status quo.  If the client MUST give =
an

"access_denied" error, then nobody will use the standard =
early on =
in

deployment because the majority of sites will be =
unreachable.

So, it is possible to say =
instead:

If there are no TLSA records =
(this is DNSSEC validated by the lookup) =
or

the domain is not signed with =
DNSSEC (this is signed by the =
parent

domain): process normally (i.e. =
PKIX).  This provides =
backwards

compatibility.

But =
what if the MITM overrides the genuine DNSSEC-signed record with a =
record that is not signed with DNSSEC?  Is there some reason why =
this is not =
possible?

Sure it's possible - and then =
the result is not DNSSEC-signed, and =
so

should be =
ignored.

But what does =
"ignored" mean?  Does it mean the client must give an =
"access_denied" error?  If so, you fall into the second of my two =
traps.

No. Your second trap is fallacious: the =
majority of sites will not be
DNSSEC enabled and therefore an =
unsigned response is expected.

Ok, =
presuming Matt's text (which I think is good):

http://www.ietf.org/mail-archive/web/keyassure/current/msg00923.html

"...if any query gives an "insecure" or "indeterminate" =
result,

KIDNS cannot be used with this TLS server, and the =
client MAY use an

alternative certificate validation =
method."

My point is simple: it is good to have =
MAY above rather than MUST

or MUST NOT.  This allows the =
client to decide whether or not PKIX is

"good =
enough" in the case in which the server has not yet =
implemented

DANE.  Early on, clients may choose not =
to require a matching TLSA

record when DNSSEC or =
DANE are not widely deployed.  A security-

conscious =
client might eventually choose to require a matching =
TLSA

record.  At that point, even if a given domain =
is not DNSSEC enabled

and an unsigned record is expected, the =
client may not deem it =
good

enough.

As Matt's text helps to =
make explicit, there are two points at which the

client MAY =
choose to fall back on PKIX:

1) Non-DNSSEC secured =
domains

2) DNSSEC-secured domains that do not have a matching =
TLSA record

I should note that when I said =
earlier in the thread "But what if the MITM

overrides =
the genuine DNSSEC-signed record with a record that is =
not

signed with DNSSEC?  Is there some reason why =
this is not possible?"

I didn't understand that DNSSEC would =
be giving a result of "bogus",

which I admitted =
here:

http://www.ietf.org/mail-archive/web/keyassure/current/msg01197.html

Thus, this is all a question what the domain =
operators have implemented

rather than a MITM =
scenario.
=

--Apple-Mail-3-1028832105--

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C31B3A6A77 for ; Mon, 20 Dec 2010 08:58:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.584
X-Spam-Level:
X-Spam-Status: No, score=-101.584 tagged_above=-999 required=5 tests=[AWL=0.462, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 NDWDKfMwHJXc for ; Mon, 20 Dec 2010 08:58:50 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id CF6053A6A69 for ; Mon, 20 Dec 2010 08:58:50 -0800 (PST)
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 oBKH0gj1052234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Dec 2010 10:00:44 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]>
Date: Mon, 20 Dec 2010 09:00:41 -0800
To: Paul Wouters , Matt McCutchen
From: Paul Hoffman
Content-Type: text/plain; charset="us-ascii"
Cc: [email-masked]
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 20 Dec 2010 16:58:51 -0000

At 4:00 AM -0500 12/20/10, Paul Wouters wrote:
>On Sun, 19 Dec 2010, Matt McCutchen wrote:
>
>>Implementations that do are just plain wrong. Not every site today is
>>interested in preventing the sslstrip attack. Sites should be able to
>>use TLSA for its intended purpose of modifying the set of acceptable TLS
>>certificates without getting this side effect.
>>
>>>If people do insist on a "policy record", next to TLSA and HASTLS, has
>>>any work been done on such a policy record? If this policy record would
>>>be missing when TLSA and HASTLS reach RFC, implementations surely will
>>>treat the presence of any of these records as a policy of "https only".
>>
>>HASTLS is the "policy record". The server just advertises that it
>>offers the protocol only over TLS, and HASTLS-aware clients will not try
>>the non-TLS version.
>
>But draft-hoffman-server-has-tls states:
>
> The HASTLS resource record type, whose value is TBD1, lists all of
> the pairs of insecure/secure port pairs that are served on the host
> named by the domain name.
>
>
>Which means that to support clients without TLSA/HASTLS suport (every
>web browser), while protecting clients with TLSA/HASTLS support from
>ssltrip attacks (a practical, not theoretical attack), I need to lie in
>my HASTLS record and state I'm not running on port 80.

I don't see how you got to that conclusion; can you state it again? I think the first clause is irrelevant: if they do not support either record type, you don't need to do anything different in HASTLS. If you are running a server on port 80, you *cannot* prevent ssslstrip attacks: that is the whole point of the HASTLS document.

>I believe it would be better of we devise a scheme where one does not have
>to lie in new RRTYPE's to give validated DNSSEC protection for new
>clients and keeping backwards compatibily for older clients. Especially
>because port 80 is not going away overnight.

No one has suggested lying in any DNS record; please be clearer about your assumptions and the attack.

--Paul Hoffman, Director
--VPN Consortium

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC1CE3A6A83 for ; Mon, 20 Dec 2010 08:52:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.581
X-Spam-Level:
X-Spam-Status: No, score=-101.581 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 PB1klEC4i7DE for ; Mon, 20 Dec 2010 08:52:50 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 51BA63A6A76 for ; Mon, 20 Dec 2010 08:52:49 -0800 (PST)
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 oBKGsfiK051865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Dec 2010 09:54:42 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]>
Date: Mon, 20 Dec 2010 08:54:15 -0800
To: Paul Wouters , Matt McCutchen
From: Paul Hoffman
Content-Type: text/plain; charset="us-ascii"
Cc: [email-masked]
Subject: Re: [keyassure] TLSA and HASTLS
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 20 Dec 2010 16:52:51 -0000

At 4:11 AM -0500 12/20/10, Paul Wouters wrote:
>On Sun, 19 Dec 2010, Matt McCutchen wrote:
>
>>>Correct. A meaning of "only take the public key, and nothing else". I find
>>>that option is missing currently from draft-ietf-dane-protocol-00.txt, which
>>>only states:
>>>
>>> 1 -- Hash of an end-entity certificate
>>> 2 -- Full end-entity certificate
>>> 3 -- Hash of an certification authority's certificate
>>> 4 -- Full certification authority's certificate
>>
>>I'm not sure you understood what I meant. The TLS protocol with server
>>authentication requires a Certificate message, which can contain an
>>X.509 certificate or a "certificate" of some other type negotiated via
>>the cert_type extension (RFC 5081). So unless a new certificate type of
>>"bare public key" is added to TLS, the server has to send a certificate.
>
>>What do you gain by publishing the public key in TLSA rather than that
>>certificate?
>
>1) A validated message stating that the DNSSEC trust model is used, and no
> CA/PKIX based trust model should ever be attempted on this host/service
>
>2) Reduced play room for attackers to launch (pre)image attacks against the public
> key for those not interested in CA/PKIX based trust model. By only hashing the
> key there is a lot less room to play with then if fields like CN= and O= would
> be part of the hash
>
>3) Reduced attack room in parsing invalid/bogus CA/PKIX certificate properties
> (if we define the new type to may only contain the minimum required X.509 fields)
> I'm thinking here of badly place \0 values and ASN.1 parser errors.
>
>3) As you brought up, perhaps support for a future "bare public key" TLS type
> that operates purely on DNSSEC validation without any CA/PKIX.

Just to be clear: are you are proposing DANE adding "bare public key" *before* any version of TLS allows that? That means that DANE will be changing the TLS semantics for all current versions of TLS. It is possible we could do that, but that seems a bit daunting given the low value of the first three items on your list.

In specific, your #1 is "you must use what I am telling you regardless of your policy", and the WG has not decided it wants to do that. There was wide disagreement during our BoF phase, and we have not had a consensus call on this yet. Further, if we did decide we want to do that, it could be achieved with a flag, not with a change to TLS.

Your #2 and #2 are, in my opinion, FUD. If there is a preimage attack on a signature algorithm, it affects much more than just the signature used in the TLSA record: it affects both DNSSEC and TLS as well. Using preimage strength of one tiny part of a system as an argument for us changing TLS is false security. Similarly, if you think TLS is open to error attacks from PKIX, change TLS. You haven't tried to do so (at least from my brief review of the TLS WG archives), and trying to do it through DANE seems really inappropriate.

--Paul Hoffman, Director
--VPN Consortium

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E1983A6876 for ; Mon, 20 Dec 2010 04:42:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.325
X-Spam-Level:
X-Spam-Status: No, score=-104.325 tagged_above=-999 required=5 tests=[AWL=-2.348, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 PYCPFF7hWv1x for ; Mon, 20 Dec 2010 04:42:41 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 652063A686D for ; Mon, 20 Dec 2010 04:42:41 -0800 (PST)
Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [172.25.149.12]) by smtp-out.google.com with ESMTP id oBKCiY6N024152 for ; Mon, 20 Dec 2010 04:44:34 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1292849074; bh=mZWSsYXlEXeFWZgthwhTYs85Dh8=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=E9x3zvbYVLAEjBBDx5VECLAhavlICVKmCrtPLfqq6CMVsyfHCTmBBQycKpWpgeC2T M7HuMaPxEr2wdML8hO4Uw==
Received: from pxi19 (pxi19.prod.google.com [10.243.27.19]) by hpaq12.eem.corp.google.com with ESMTP id oBKCiWTv030952 for ; Mon, 20 Dec 2010 04:44:33 -0800
Received: by pxi19 with SMTP id 19so991574pxi.29 for ; Mon, 20 Dec 2010 04:44:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=jZudk6vqK1O25k02RNjbC12kcoyJQrEiJPoVPgH/JrE=; b=h75zc27p/C78jyfTGvJIH/qoAzgoJ8ETIQvYtwnp0S6/UU/YVlsejSHtT1/qz/Yjcc qCFrBjUkooRMbzUtaDDQ==
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=GMoTzOxB/bVu73+nr4pbOjn8+SkiU9Sm1pkVd1MNZKqCkHB9c9QFqzff1kS/McGUK5 xxfNxX0BTyahVyXsqn0A==
MIME-Version: 1.0
Received: by 10.142.233.6 with SMTP id f6mr3292533wfh.305.1292849071899; Mon, 20 Dec 2010 04:44:31 -0800 (PST)
Received: by 10.142.47.14 with HTTP; Mon, 20 Dec 2010 04:44:31 -0800 (PST)
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Mon, 20 Dec 2010 12:44:31 +0000
Message-ID:
From: Ben Laurie
To: Steve Schultze
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
Cc: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 20 Dec 2010 12:42:42 -0000

On 16 December 2010 15:50, Steve Schultze wrote:
> On Dec 16, 2010, at 10:45 AM, Ben Laurie wrote:
>> On 16 December 2010 15:34, Steve Schultze wrote:
>>> On Dec 16, 2010, at 3:48 AM, W.C.A. Wijngaards wrote:
>>>> On 12/16/2010 05:54 AM, Steve Schultze wrote:
>>>>> "If the application receives zero usable certificate associations, it
>>>>> processes TLS in the normal fashion."
>>>>
>>>>> And, as I noted during our session in Beijing, the motivation for
>>>>> permitting the client to choose is that if we mandate it one way or
>>>>> the other, we fall into a trap. =A0If the client MUST process TLS in
>>>>> the normal fashion (aka, using PKIX) then we have provided a solution
>>>>> that is no better than the status quo. =A0If the client MUST give an
>>>>> "access_denied" error, then nobody will use the standard early on in
>>>>> deployment because the majority of sites will be unreachable.
>>>>
>>>> So, it is possible to say instead:
>>>>
>>>> If there are no TLSA records (this is DNSSEC validated by the lookup) =
or
>>>> the domain is not signed with DNSSEC (this is signed by the parent
>>>> domain): process normally (i.e. PKIX). =A0This provides backwards
>>>> compatibility.
>>>
>>> But what if the MITM overrides the genuine DNSSEC-signed record with a =
record that is not signed with DNSSEC? =A0Is there some reason why this is =
not possible?
>>
>> Sure it's possible - and then the result is not DNSSEC-signed, and so
>> should be ignored.
>
> But what does "ignored" mean? =A0Does it mean the client must give an "ac=
cess_denied" error? =A0If so, you fall into the second of my two traps.

No. Your second trap is fallacious: the majority of sites will not be
DNSSEC enabled and therefore an unsigned response is expected.

> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64AC13A6878 for ; Mon, 20 Dec 2010 03:59:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.396
X-Spam-Level:
X-Spam-Status: No, score=-3.396 tagged_above=-999 required=5 tests=[AWL=0.202, 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 a-dSMxdT-VIz for ; Mon, 20 Dec 2010 03:59:07 -0800 (PST)
Received: from mail-gw0-f42.google.com (mail-gw0-f42.google.com [74.125.83.42]) by core3.amsl.com (Postfix) with ESMTP id C9C043A6877 for ; Mon, 20 Dec 2010 03:59:06 -0800 (PST)
Received: by gwb20 with SMTP id 20so3064456gwb.15 for ; Mon, 20 Dec 2010 04:00:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=S63lkYK3trAkqrMhbphAUoEZ5lR6ilUOBqMf+4ThCRc=; b=UasVoLLDS7W/pHhofvJG07+f+v2zhFJROHT9kMYsbkXkOAAaew04/glPYSX9hqF69m XUuredh0RNKaq/9JIQr2LRUgNxbf60/oHBCTFxsa2j/ujwECJxkIiv3Wi0wSbXCu7bOl QNXPE8/WwuYmHY/URZ/0p3+2ueAJM50zPqPr4=
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=yDUrVqJIhdh8DCgufxeoIFddOeg5HDtynOF89C2U8V2MZyPVx8lQjxNJUAaWhGDomi kdOFYhR6p2EcAad7GffSPuFIz00TK68N+qx7RJxHo+djD5o71tdUDDRURDkf6XEW+JVv 6sP28uAOp7S45LcYQQTuWoJCMIhZ+i21rSXj0=
MIME-Version: 1.0
Received: by 10.100.122.9 with SMTP id u9mr2375753anc.171.1292846459811; Mon, 20 Dec 2010 04:00:59 -0800 (PST)
Received: by 10.100.31.8 with HTTP; Mon, 20 Dec 2010 04:00:59 -0800 (PST)
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost>
Date: Mon, 20 Dec 2010 12:00:59 +0000
Message-ID:
From: Phillip Hallam-Baker
To: Paul Wouters
Content-Type: multipart/alternative; boundary=0016e6407e80fc77820497d645f5
Cc: [email-masked], Paul Hoffman
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 20 Dec 2010 11:59:08 -0000

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

On Sun, Dec 19, 2010 at 10:42 PM, Paul Wouters wrote:

> On Fri, 17 Dec 2010, Paul Hoffman wrote:
>
> Subject: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
>>>>>
>>>>
>>> I actually had one more comment. I realised that the TLSA record can
>>> protect
>>> against Moxy's sslstrip (http://www.thoughtcrime.org/software/sslstrip/)
>>>
>>> Could we add something like:
>>>
>>> If a client detects a validated TLSA record, it MUST only use
>>> https (not http)
>>> to connect to the target site to prevent SSL stripping attacks.
>>>
>>
>> Probably not. That is, if the user is not going to TLS (because the server
>> doesn't do TLS or a MITM has done a downgrade to non-TLS), they should not
>> be looking for TLSA records.
>>
>
> That would suggest an implicit policy of "If a TLSA record exists, only do
> https". If that
> is meant, you should state so in the draft? right now, there is an implicit
> "http first, perhaps https later".

I don't like implicit policy.

First off, the TLSA record is not specific to the HTTP protocol. So does
putting up a TLSA record imply strict security for IMAP, POP?

But policy is what this whole project should be about. Right now we have a
situation where security is the exception. We need to change that to a
situation where security is the default. Or rather where minimal security in
the form of encryption and authentication anchored to the DNS name is the
default.

Without a policy layer it will be ten years before people can use DNSSEC
validated keys in any case.

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

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

On Sun, Dec 19, 2010 at 10:42 PM, Paul W=
outers <paul@xel=
erance.com> wrote:

On Fri, 17 Dec 2010, Paul Hoffman wrote:

Subject: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt

I actually had one more comment. I realised that the TLSA record can protec=
t

against Moxy's sslstrip (http://www.thoughtcrime.org/software/sslstri=
p/)

Could we add something like:

=A0 =A0 =A0 =A0If a client detects a validated TLSA record, it MUST only u=
se https (not http)

=A0 =A0 =A0 =A0to connect to the target site to prevent SSL stripping atta=
cks.

Probably not. That is, if the user is not going to TLS (because the server =
doesn't do TLS or a MITM has done a downgrade to non-TLS), they should =
not be looking for TLSA records.

That would suggest an implicit policy of "If a TLSA record exists, onl=
y do https". If that

is meant, you should state so in the draft? right now, there is an implicit=
"http first, perhaps https later".

I don't like implicit policy.

First off, the TLS=
A record is not specific to the HTTP protocol. So does putting up a TLSA re=
cord imply strict security for IMAP, POP?

But policy is what this whole project should be about. =
Right now we have a situation where security is the exception. We need to c=
hange that to a situation where security is the default. Or rather where mi=
nimal security in the form of encryption and authentication anchored to the=
DNS name is the default.

Without a policy layer it will be ten ye=
ars before people can use DNSSEC validated keys in any case.

--
Website: http://hal=
lambaker.com/

--0016e6407e80fc77820497d645f5--

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFA903A6A3D for ; Mon, 20 Dec 2010 03:44:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.962
X-Spam-Level:
X-Spam-Status: No, score=-2.962 tagged_above=-999 required=5 tests=[AWL=-0.248, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, 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 vXZpQQhcgrgN for ; Mon, 20 Dec 2010 03:44:55 -0800 (PST)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 052513A6A3A for ; Mon, 20 Dec 2010 03:44:54 -0800 (PST)
Received: by yxt33 with SMTP id 33so1360642yxt.31 for ; Mon, 20 Dec 2010 03:46:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=MbJdsViN43mu7ELAZBs0wMk/ThP4zc/E0BT4Zn1pej0=; b=Y6R9KHcJbR2QdLh4Me3tfrePbdpU9Jj7YwFlaqyB+7uKPjEw3nJQtofaTICv8+mrKt R5bsqfXOdwMqde2fL75IrDGdQn74zsOgKPHTgmHbuYpRyIh7JNPQfsPRWPYP2c2AYNlm 0tny7cWtbQhRM/l1TS2yKBUidxM6vMtny6rgg=
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=V9FZ5GHz3jY6WdblQAVJAzusJ++Kx6II3FhPMazIr4+wNyH76GMOqptc8KD6z7fSCp K8a1lCJjOpvypgbJHRAM/Ixyd09MzY8oC/L0P66h2bF7iUHBd2fWmJvF6WID1KDHus1u +15Jqg8KqzygM92Yx5X5PEDs1297C61de+fwE=
MIME-Version: 1.0
Received: by 10.100.96.1 with SMTP id t1mr2364395anb.137.1292844936893; Mon, 20 Dec 2010 03:35:36 -0800 (PST)
Received: by 10.100.31.8 with HTTP; Mon, 20 Dec 2010 03:35:36 -0800 (PST)
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost>
Date: Mon, 20 Dec 2010 11:35:36 +0000
Message-ID:
From: Phillip Hallam-Baker
To: Paul Wouters
Content-Type: multipart/alternative; boundary=0016e644caf03696d80497d5ebb2
Cc: [email-masked], Paul Hoffman
Subject: Re: [keyassure] TLSA and HASTLS
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 20 Dec 2010 11:44:57 -0000

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

On Sun, Dec 19, 2010 at 10:35 PM, Paul Wouters wrote:

> On Fri, 17 Dec 2010, Paul Hoffman wrote:
>
> Hmm, so draft-hoffman-server-has-tls-01 defines a HASTLS record. Execsum:
>>>
>>> www.example.com IN HASTLS (25 25 0 443)
>>>
>>> But we have no method defined anyway to get all this information at once.
>>> So now this becomes two full roundtrip DNS queries
>>> to get enough information about the pubkey used on a website.
>>>
>>
>> Not at all. If you are about to do TLS and only TLS, then you don't need
>> to query for HASTLS: it is only if you want to do TLS but cannot get there
>> that you need to do HASTLS.
>>
>> Is there any work being done on optimising this with an EDNS
>>> option?
>>>
>>
>> It's a thought, but one that has not garnered much interest in the past.
>>
>
> So am I right that the consensus seems to be to continue with TLSA and
> HASTLS now, and look into
> an EDNS method later to optimise?
>

That was definitely the sense I got from the remote feed of the WEBSEC WG.

Their problem with strict security divides into two. The first is how to
signal that strict security is to be employed. The second is to define what
strict security is and how it should affect browser security. The first
problem is fairly straightforward, the second is hard.

I think it makes a lot of sense to do the HTTP header approach as an interim
measure. But in the long term the signaling mechanism for the Internet is
DNS.

Here is how I see squaring the circle:

I see a three layer scheme that allows for protocol information to be
expressed with increasing specificity as discovery progresses.

RR-A
Expresses information that binds to the entire domain.
Is never the target of a prefixed query
May be wildcarded, resolution may be aliased.
May have a flag to state 'use SRV/URI/NAPTR discovery' and continue the
discovery chain

RR-B
Expresses information that binds to a specific protocol or a specific
host/protocol
Is always prefixed using a protocol prefix
Must not be wildcarded.
Resolution is always for a known canonical name
Protocol level record may have a flag to state that there is yet more
detail at the host level.

So a simple RR set might be:

$origin example.com
www CNAME example.com
. RR-A "Root cert is X"

A more detailed RR set might be:
$origin example.com
www CNAME example.com
. RR-A "Root cert is X"
. RR-A "Protocol detail"
_http._tcp RR-B "Always use TLS"

Here the discovery chain starting from either www.example.com or
example.comwill result in the client collecting the pair of RR-As and
then make a
second, protocol specific lookup for the RR-B.

The reason that two separate RRs are needed here is that a RR type can be
used with wildcards or with prefixes but not both.

A yet more detailed version would introduce SRV or URI discovery (I am not a
fan of NAPTR).

$origin example.com
www CNAME example.com
. RR-A "Root cert is X"
. RR-A "SRV Discovery"
. RR-A "Host detail
_http._tcp SRV 1 1 443 h1.example.com
_http._tcp SRV 1 1 443 h2.example.com
_http._tcp.h1 RR-B "Always use TLS"
_http._tcp.h1 RR-B "EE key is Y"
_http._tcp.h2 RR-B "Always use TLS"
_http._tcp.h2 RR-B "EE key is Z"

Since we are using SRV discovery with meta-discovery here, there are
inescapably three separate names that will be queried; general, protocol and
host. There are a minimum of three round trips unless we introduce a
meta-discovery mechanism.

One possibility here is that servers automatically know that they need to
push out the entire RR chain as additional records when a RR-A query is
made. That fails in the general case as the protocol prefix is required for
resolution.

I would prefer a new meta query record that the server advertises support
for. This would be advertised as being supported using EDNS0 and would take
an extensible tag-value separated list of properties.

MEGA-Q www.example.com _http._tcp
source-ip = 10.1.1.1
ipv6=yes

The reason for these additional parameter slots is that I would like to
introduce new and better discovery mechanisms over time.

The main point of comparison here is to the NAPTR DDS scheme. The difference
in my mind is that NAPTR introduces Regular Expressions and my scheme does
not. I think evaluating REs is too powerful a tool at this layer in the
stack. They are tantamount to being a Turing complete programming language.

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

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

On Sun, Dec 19, 2010 at 10:35 PM, Paul W=
outers <paul@xel=
erance.com> wrote:

On Fri, 17 Dec 2010, Paul Hoffman wrote:

Hmm, so draft-hoffman-server-has-tls-01 defines a HASTLS record. Execsum:

=A0 =A0 =A0 =A0www.ex=
ample.com IN HASTLS (25 25 0 443)

But we have no method defined anyway to get all this information at once. S=
o now this becomes two full roundtrip DNS queries

to get enough information about the pubkey used on a website.

Not at all. If you are about to do TLS and only TLS, then you don't nee=
d to query for HASTLS: it is only if you want to do TLS but cannot get ther=
e that you need to do HASTLS.

Is there any work being done on optimising this with an EDNS

option?

It's a thought, but one that has not garnered much interest in the past=
.

So am I right that the consensus seems to be to continue with TLSA and HAST=
LS now, and look into

an EDNS method later to optimise?

That =
was definitely the sense I got from the remote feed of the WEBSEC WG.
=

Their problem with strict security divides into two. Th=
e first is how to signal that strict security is to be employed. The second=
is to define what strict security is and how it should affect browser secu=
rity. The first problem is fairly straightforward, the second is hard.

I think it makes a lot of sense to do the HTTP header a=
pproach as an interim measure. But in the long term the signaling mechanism=
for the Internet is DNS.

Here is h=
ow I see squaring the circle:

I see a three layer scheme that allows for protocol inf=
ormation to be expressed with increasing specificity as discovery progresse=
s.

RR-A =A0

=A0=A0 =A0Expresses informat=
ion that binds to the entire domain.

=A0=A0 =A0Is never the target of a prefixed query

=A0=A0 =A0=
May be wildcarded, resolution may be aliased.

=A0=A0 =A0May have =
a flag to state 'use SRV/URI/NAPTR discovery' and continue the disc=
overy chain

RR-B

=A0=A0 =A0Expresses information that bin=
ds to a specific protocol or a specific host/protocol

=A0=A0 =A0I=
s always prefixed using a protocol prefix

=A0=A0 =A0Must not be w=
ildcarded.

=A0=A0 =A0Resolution is always for a known canonical name

=
=A0=A0 =A0Protocol level record may have a flag to state that there is yet =
more detail at the host level.

So a simple RR set =
might be:

$origin example.com<=
/font>

www =A0 =A0 =A0 =A0 =A0 CNAME example.com

. =A0 =A0 =A0 =A0 =A0 =A0 RR-A =A0"Root cert is X"

A more detailed RR set might be:

=
$origin example.com

www=
=A0 =A0 =A0 =A0 =A0 CNAME example.com

. =A0 =A0 =A0 =A0 =A0 =A0 RR-A =A0"Root cert is X"

. =A0 =A0 =A0 =A0 =A0 =A0 RR-A =A0"Protocol detail"=

_http._tcp =A0 =A0RR-B =A0"Always use TLS"

=

Here the discovery chain starting from either www.example.com or =
example.com will result in the client collecting the pair of RR-As and =
then make a second, protocol specific lookup for the RR-B.

The reason that two separate RRs are needed here is tha=
t a RR type can be used with wildcards or with prefixes but not both.
=

A yet more detailed version would introduce SRV or URI =
discovery (I am not a fan of NAPTR).

$origin example.com

www =A0 =A0 =A0 =A0 =A0 =
CNAME example.com

. =A0 =A0 =A0 =A0 =A0 =A0 RR-A =A0"Root cert is X"

. =A0 =A0 =A0 =A0 =A0 =A0 RR-A =A0"SRV Discovery"

. =A0 =A0 =A0 =A0 =A0 =A0 RR-A =A0"Host detail

<=
font class=3D"Apple-style-span" face=3D"'courier new', monospace">_=
http._tcp =A0 =A0SRV =A0 1 1 443 h1.examp=
le.com

_http._tcp =A0 =A0SRV =A0 1 1 443 h2.example.com

_http._tcp.h1 RR-=
B =A0"Always use TLS"

_http._tcp.h1 RR-B =A0"EE key is Y&=
quot;

_http._tcp.h2 RR-B =A0"Always use TLS"

_http._tcp.h2 RR-B =A0"EE key is Z"

=

Since we are using SRV discovery with meta-discovery he=
re, there are inescapably three separate names that will be queried; genera=
l, protocol and host. There are a minimum of three round trips unless we in=
troduce a meta-discovery mechanism.

One possibility here is that servers automatically know=
that they need to push out the entire RR chain as additional records when =
a RR-A query is made. That fails in the general case as the protocol prefix=
is required for resolution.=A0

I would prefer a new meta query record that the server =
advertises support for. This would be advertised as being supported using E=
DNS0 and would take an extensible tag-value separated list of properties.

MEGA-Q =A0www.exampl=
e.com _http._tcp=A0

=A0=A0 =A0source-ip =3D 10.1.1.1
=A0=A0 =A0ipv6=3Dyes

The reason for these additi=
onal parameter slots is that I would like to introduce new and better disco=
very mechanisms over time.

The main point of comparison here is to =
the NAPTR DDS scheme. The difference in my mind is that NAPTR introduces Re=
gular Expressions and my scheme does not. I think evaluating REs is too pow=
erful a tool at this layer in the stack. They are tantamount to being a Tur=
ing complete programming language.

--=A0

Website: http://hallambaker.com/

--0016e644caf03696d80497d5ebb2--

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CD7C3A67CF for ; Mon, 20 Dec 2010 01:09:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.585
X-Spam-Level:
X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 lGRH4fiA2Tbj for ; Mon, 20 Dec 2010 01:09:38 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 1E7123A6A20 for ; Mon, 20 Dec 2010 01:09:38 -0800 (PST)
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 D8E70C412; Mon, 20 Dec 2010 04:11:30 -0500 (EST)
Date: Mon, 20 Dec 2010 04:11:30 -0500 (EST)
From: Paul Wouters
To: Matt McCutchen
In-Reply-To: <[email-masked]>
Message-ID:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: [email-masked]
Subject: Re: [keyassure] TLSA and HASTLS
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 20 Dec 2010 09:09:39 -0000

On Sun, 19 Dec 2010, Matt McCutchen wrote:

>> Correct. A meaning of "only take the public key, and nothing else". I find
>> that option is missing currently from draft-ietf-dane-protocol-00.txt, which
>> only states:
>>
>> 1 -- Hash of an end-entity certificate
>> 2 -- Full end-entity certificate
>> 3 -- Hash of an certification authority's certificate
>> 4 -- Full certification authority's certificate
>
> I'm not sure you understood what I meant. The TLS protocol with server
> authentication requires a Certificate message, which can contain an
> X.509 certificate or a "certificate" of some other type negotiated via
> the cert_type extension (RFC 5081). So unless a new certificate type of
> "bare public key" is added to TLS, the server has to send a certificate.

> What do you gain by publishing the public key in TLSA rather than that
> certificate?

1) A validated message stating that the DNSSEC trust model is used, and no
CA/PKIX based trust model should ever be attempted on this host/service

2) Reduced play room for attackers to launch (pre)image attacks against the public
key for those not interested in CA/PKIX based trust model. By only hashing the
key there is a lot less room to play with then if fields like CN= and O= would
be part of the hash

3) Reduced attack room in parsing invalid/bogus CA/PKIX certificate properties
(if we define the new type to may only contain the minimum required X.509 fields)
I'm thinking here of badly place \0 values and ASN.1 parser errors.

3) As you brought up, perhaps support for a future "bare public key" TLS type
that operates purely on DNSSEC validation without any CA/PKIX.

Paul

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 444A73A6A22 for ; Mon, 20 Dec 2010 00:58:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.584
X-Spam-Level:
X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 9HbJg9CXBXSL for ; Mon, 20 Dec 2010 00:58:37 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 50F3D3A6A1F for ; Mon, 20 Dec 2010 00:58:36 -0800 (PST)
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 9F622C412; Mon, 20 Dec 2010 04:00:28 -0500 (EST)
Date: Mon, 20 Dec 2010 04:00:27 -0500 (EST)
From: Paul Wouters
To: Matt McCutchen
In-Reply-To: <[email-masked]>
Message-ID:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: [email-masked]
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 20 Dec 2010 08:58:38 -0000

On Sun, 19 Dec 2010, Matt McCutchen wrote:

> Implementations that do are just plain wrong. Not every site today is
> interested in preventing the sslstrip attack. Sites should be able to
> use TLSA for its intended purpose of modifying the set of acceptable TLS
> certificates without getting this side effect.
>
>> If people do insist on a "policy record", next to TLSA and HASTLS, has
>> any work been done on such a policy record? If this policy record would
>> be missing when TLSA and HASTLS reach RFC, implementations surely will
>> treat the presence of any of these records as a policy of "https only".
>
> HASTLS is the "policy record". The server just advertises that it
> offers the protocol only over TLS, and HASTLS-aware clients will not try
> the non-TLS version.

But draft-hoffman-server-has-tls states:

The HASTLS resource record type, whose value is TBD1, lists all of
the pairs of insecure/secure port pairs that are served on the host
named by the domain name.

Which means that to support clients without TLSA/HASTLS suport (every
web browser), while protecting clients with TLSA/HASTLS support from
ssltrip attacks (a practical, not theoretical attack), I need to lie in
my HASTLS record and state I'm not running on port 80.

I believe it would be better of we devise a scheme where one does not have
to lie in new RRTYPE's to give validated DNSSEC protection for new
clients and keeping backwards compatibily for older clients. Especially
because port 80 is not going away overnight.

Paul

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00C463A6965 for ; Sun, 19 Dec 2010 16:13:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMEHhfn1LDij for ; Sun, 19 Dec 2010 16:13:38 -0800 (PST)
Received: from homiemail-a37.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by core3.amsl.com (Postfix) with ESMTP id A05F43A6967 for ; Sun, 19 Dec 2010 16:13:34 -0800 (PST)
Received: from homiemail-a37.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTP id 1086B1D0065; Sun, 19 Dec 2010 16:15:27 -0800 (PST)
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=V1F6UgYNGJRZZSUgmWeSB2eWhRpYUrylxcIOryeT2sI d9B4VqYibMNDoIJabQvUJaZZcX0CxAuUn9Zf1Ky9nKQ+IsSMppUMdOHwDDHIsTir m8MzrjusPRPlTix6hYAc3SySE34j0ofz8l+E8JYuFk/AUOek6yiTBHmik9gQwxGI =
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=hL/COlw8FIg+PwfLu7U05w7TI/4=; b=dcEKR39W1K tHFdf7+gemeeagfwBfqpi5z1a5JvYxcwKZeIJxs4hV+LPpcffKO1SXsjTCk6uR7z Vqft0FbhCicpN95jj3uTXuEjPtP44Kjy49o1L2uXN0Ny7fjqcGydR2sWme5wc3kv qOWOTaMkZKiwumYT7Sg4vIK2a6ik3gpTI=
Received: from [192.168.1.40] (pool-96-231-10-176.washdc.east.verizon.net [96.231.10.176]) (Authenticated sender: [email-masked]) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTPA id 808431D0063; Sun, 19 Dec 2010 16:15:26 -0800 (PST)
From: Matt McCutchen
To: Paul Wouters
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]>
Content-Type: text/plain; charset="UTF-8"
Date: Sun, 19 Dec 2010 19:15:24 -0500
Message-ID: <[email-masked]>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.1
Content-Transfer-Encoding: 7bit
Cc: [email-masked]
Subject: Re: [keyassure] TLSA and HASTLS
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 20 Dec 2010 00:13:39 -0000

On Sun, 2010-12-19 at 18:37 -0500, Paul Wouters wrote:
> On Sun, 19 Dec 2010, Matt McCutchen wrote:
>
> > How much will that help, given that TLS itself requires a certificate?
> > (Or do you propose a new TLS certificate type of "bare public key"?)
>
> Correct. A meaning of "only take the public key, and nothing else". I find
> that option is missing currently from draft-ietf-dane-protocol-00.txt, which
> only states:
>
> 1 -- Hash of an end-entity certificate
> 2 -- Full end-entity certificate
> 3 -- Hash of an certification authority's certificate
> 4 -- Full certification authority's certificate

I'm not sure you understood what I meant. The TLS protocol with server
authentication requires a Certificate message, which can contain an
X.509 certificate or a "certificate" of some other type negotiated via
the cert_type extension (RFC 5081). So unless a new certificate type of
"bare public key" is added to TLS, the server has to send a certificate.
What do you gain by publishing the public key in TLSA rather than that
certificate?

--
Matt

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A036E3A6965 for ; Sun, 19 Dec 2010 16:08:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iyk2hGTwf1Uq for ; Sun, 19 Dec 2010 16:08:24 -0800 (PST)
Received: from homiemail-a62.g.dreamhost.com (mx1.spunky.mail.dreamhost.com [208.97.132.47]) by core3.amsl.com (Postfix) with ESMTP id 9AC8F3A6964 for ; Sun, 19 Dec 2010 16:08:24 -0800 (PST)
Received: from homiemail-a62.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTP id 1C83463406E; Sun, 19 Dec 2010 16:10:17 -0800 (PST)
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=HAyOQzfEiCdWb5s+MKXjLK3ZCQ6Ynm2Lz4gb0depWQe psAQGHQyn6dJ9WYvGt5wQFnZ5y9DHlaUmCan2tvPpP30G89dtTZAjU7bTKPV+vJl zCjxwY+i6/ntChyzvH4NhP5b1mxpVvt8tUHD3X7/RFoKNKgGXGReHYYiRKA80TQs =
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=vttRelrInmMrrtEW8GzcJNik+6M=; b=SplG5pEya1 FJCQwRQ7GSNFrEdZ9j/lVqauBm5qgh/iTPFjtxVfq0ZN2bjyKspzMXuzSez5YSdE YI2G5jbNMbD8Oukfw2vKL0IcMPg5Ff1MWc7f2HD7vuZI9QJlJyoe/Gb9wPnE7cHJ APbrTmv0gd/IunpJiVhXHN3jGRdB/mOXA=
Received: from [192.168.1.40] (pool-96-231-10-176.washdc.east.verizon.net [96.231.10.176]) (Authenticated sender: [email-masked]) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTPA id A133863406C; Sun, 19 Dec 2010 16:10:16 -0800 (PST)
From: Matt McCutchen
To: Paul Wouters
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]>
Content-Type: text/plain; charset="UTF-8"
Date: Sun, 19 Dec 2010 19:10:14 -0500
Message-ID: <[email-masked]>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.1
Content-Transfer-Encoding: 7bit
Cc: [email-masked]
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 20 Dec 2010 00:08:25 -0000

On Sun, 2010-12-19 at 18:32 -0500, Paul Wouters wrote:
> I'd argue that you'll find different implementations, where some do and
> some don't treat the TLSA as a "policy" to start with https - because
> frankly it makes no sense to publish a TLSA record and still have https
> as an "optional" on your site. It does not prevent the SSLstrip attack,
> and I'd rather not advocate people implement TLSA without "must do
> https first".

Implementations that do are just plain wrong. Not every site today is
interested in preventing the sslstrip attack. Sites should be able to
use TLSA for its intended purpose of modifying the set of acceptable TLS
certificates without getting this side effect.

> If people do insist on a "policy record", next to TLSA and HASTLS, has
> any work been done on such a policy record? If this policy record would
> be missing when TLSA and HASTLS reach RFC, implementations surely will
> treat the presence of any of these records as a policy of "https only".

HASTLS is the "policy record". The server just advertises that it
offers the protocol only over TLS, and HASTLS-aware clients will not try
the non-TLS version.

--
Matt

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D139E3A6954 for ; Sun, 19 Dec 2010 15:36:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.584
X-Spam-Level:
X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 W-sW8pd1lZhO for ; Sun, 19 Dec 2010 15:36:04 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id CD4653A694F for ; Sun, 19 Dec 2010 15:36:03 -0800 (PST)
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 7D79DC412; Sun, 19 Dec 2010 18:37:55 -0500 (EST)
Date: Sun, 19 Dec 2010 18:37:54 -0500 (EST)
From: Paul Wouters
To: Matt McCutchen
In-Reply-To: <[email-masked]>
Message-ID:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: [email-masked]
Subject: Re: [keyassure] TLSA and HASTLS
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Sun, 19 Dec 2010 23:36:04 -0000

On Sun, 19 Dec 2010, Matt McCutchen wrote:

> How much will that help, given that TLS itself requires a certificate?
> (Or do you propose a new TLS certificate type of "bare public key"?)

Correct. A meaning of "only take the public key, and nothing else". I find
that option is missing currently from draft-ietf-dane-protocol-00.txt, which
only states:

1 -- Hash of an end-entity certificate
2 -- Full end-entity certificate
3 -- Hash of an certification authority's certificate
4 -- Full certification authority's certificate

Paul

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED8093A6954 for ; Sun, 19 Dec 2010 15:30:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.584
X-Spam-Level:
X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 18Aba8b45H33 for ; Sun, 19 Dec 2010 15:30:57 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 076103A6953 for ; Sun, 19 Dec 2010 15:30:57 -0800 (PST)
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 7D39FC412; Sun, 19 Dec 2010 18:32:48 -0500 (EST)
Date: Sun, 19 Dec 2010 18:32:48 -0500 (EST)
From: Paul Wouters
To: Matt McCutchen
In-Reply-To: <[email-masked]>
Message-ID:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Cc: [email-masked]
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Sun, 19 Dec 2010 23:30:58 -0000

On Sun, 19 Dec 2010, Matt McCutchen wrote:

> On Sun, 2010-12-19 at 17:42 -0500, Paul Wouters wrote:
>> The key issue here is the decision point to do "https only". If you make that after connecting to http,
>> then moxie's attack can change the http traffic to remove any sign for "must go to https". So anything
>> on port 80 cannot give us authenticated proof to only use port 443. An out of bound DNSSEC validated
>> record can.
>
> Right.
>
>> Which is why I'm suggesting the policy of "if TLSA, then only do https". Or at least "start with https"
>> to allow for (not recommended) https/http mixed content.
>
> A separate record would be better design as Paul Hoffman has explained.

I'd argue that you'll find different implementations, where some do and
some don't treat the TLSA as a "policy" to start with https - because
frankly it makes no sense to publish a TLSA record and still have https
as an "optional" on your site. It does not prevent the SSLstrip attack,
and I'd rather not advocate people implement TLSA without "must do
https first".

If people do insist on a "policy record", next to TLSA and HASTLS, has
any work been done on such a policy record? If this policy record would
be missing when TLSA and HASTLS reach RFC, implementations surely will
treat the presence of any of these records as a policy of "https only".

Paul

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 693663A694E for ; Sun, 19 Dec 2010 15:12:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJxBTEDbh+GQ for ; Sun, 19 Dec 2010 15:12:15 -0800 (PST)
Received: from homiemail-a61.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by core3.amsl.com (Postfix) with ESMTP id 46EC93A694A for ; Sun, 19 Dec 2010 15:12:15 -0800 (PST)
Received: from homiemail-a61.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a61.g.dreamhost.com (Postfix) with ESMTP id A0205578069; Sun, 19 Dec 2010 15:14:07 -0800 (PST)
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=h5NkGQ50ewY4sf8EMIHv65IeTFpg55Kok9r5cKwqibL HZPeB1BhU7grE2ivV49dkaZnLDzMhQLzEbKP7aKnVuNJfdDjOKa+i1+2qFLYXVOZ y99N8sF0cgEfV+c7sV8BuWe8iZy/QWSLDeOseJOqSsjs60ATw7cUaRkiRLLqC2ak =
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=V4dxuUXfyKqWGuuq5UqDYPt3AOw=; b=Hd0QpWwfRr PzJoo9DhaC6HBrm2Hr2jiWrCVquLuRAEHrC7qSbw6n61+5YhXQJrmocQcxjTOyKq 8fnYZlYGC3ocz6n+Y27+PxJyXhLVHzYLOnL8i9ZgyI9+lRY4dku/qZq14C9pxbxG SzhaTdYVPhfEj8mxfbp86P/jZChqHORHw=
Received: from [192.168.1.40] (pool-96-231-10-176.washdc.east.verizon.net [96.231.10.176]) (Authenticated sender: [email-masked]) by homiemail-a61.g.dreamhost.com (Postfix) with ESMTPA id 34DA9578059; Sun, 19 Dec 2010 15:14:07 -0800 (PST)
From: Matt McCutchen
To: Paul Wouters
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost>
Content-Type: text/plain; charset="UTF-8"
Date: Sun, 19 Dec 2010 18:14:05 -0500
Message-ID: <[email-masked]>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.1
Content-Transfer-Encoding: 7bit
Cc: [email-masked]
Subject: Re: [keyassure] TLSA and HASTLS
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Sun, 19 Dec 2010 23:12:16 -0000

On Sun, 2010-12-19 at 17:35 -0500, Paul Wouters wrote:
> But I would
> also really like to see a "pubkey only" type being added to the TLSA draft to satisfy those who
> do not want to deal with any certificate information. This might go a long way to make TLSA a
> complete solution for those who want to minimize and maximize CA/cert usage.

How much will that help, given that TLS itself requires a certificate?
(Or do you propose a new TLS certificate type of "bare public key"?)

--
Matt

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 038E73A694E for ; Sun, 19 Dec 2010 15:10:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8lZ1zIVSOuXM for ; Sun, 19 Dec 2010 15:10:43 -0800 (PST)
Received: from homiemail-a1.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by core3.amsl.com (Postfix) with ESMTP id C57363A694A for ; Sun, 19 Dec 2010 15:10:43 -0800 (PST)
Received: from homiemail-a1.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a1.g.dreamhost.com (Postfix) with ESMTP id 0FB2134806B; Sun, 19 Dec 2010 15:12:36 -0800 (PST)
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=JrkhmEUneAAsaHBfrLCjoPqwMCP10Z6y75KMTawtkDI h+LWt9QxTpjQIXepCleG51dISX8Io5AGVcAU+pcMqRyAUuMRYafpNAEnrxq73Lpz 4RW5h4Jr0iNzwFrOard4E4SaEVOCTruMnfeW2Wh/LgARXJVPiM4CxBh7WyoBrsjE =
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=KUug10k3Ur8hCcjcjQT1uICtb7A=; b=bJLpHoiO/l l9W+M0A15cppB9eOiOpiyUeq2b0pwVQEzwlb/MKWI8NS4EdkY+fxm29OA8MQVFlN fXvtF0+U4fSEcOf41EEJoFxntrmu/l69EhX75gn6McIPKKumA5MRV9JTeQby04Sl 8ewFbhq2AVcQP9Gw+PB8NS+08JeaH9HEY=
Received: from [192.168.1.40] (pool-96-231-10-176.washdc.east.verizon.net [96.231.10.176]) (Authenticated sender: [email-masked]) by homiemail-a1.g.dreamhost.com (Postfix) with ESMTPA id 9840B348062; Sun, 19 Dec 2010 15:12:35 -0800 (PST)
From: Matt McCutchen
To: Paul Wouters
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost>
Content-Type: text/plain; charset="UTF-8"
Date: Sun, 19 Dec 2010 18:12:34 -0500
Message-ID: <[email-masked]>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.1
Content-Transfer-Encoding: 7bit
Cc: [email-masked]
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Sun, 19 Dec 2010 23:10:45 -0000

On Sun, 2010-12-19 at 17:42 -0500, Paul Wouters wrote:
> The key issue here is the decision point to do "https only". If you make that after connecting to http,
> then moxie's attack can change the http traffic to remove any sign for "must go to https". So anything
> on port 80 cannot give us authenticated proof to only use port 443. An out of bound DNSSEC validated
> record can.

Right.

> Which is why I'm suggesting the policy of "if TLSA, then only do https". Or at least "start with https"
> to allow for (not recommended) https/http mixed content.

A separate record would be better design as Paul Hoffman has explained.

--
Matt

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E24633A693B for ; Sun, 19 Dec 2010 14:41:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.583
X-Spam-Level:
X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 1xr02qD5Ueco for ; Sun, 19 Dec 2010 14:41:06 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 1FC6E3A693A for ; Sun, 19 Dec 2010 14:41:06 -0800 (PST)
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 E7118C45B; Sun, 19 Dec 2010 17:42:57 -0500 (EST)
Date: Sun, 19 Dec 2010 17:42:57 -0500 (EST)
From: Paul Wouters
To: Paul Hoffman
In-Reply-To:
Message-ID:
References: <20101213220001.24500.52050.idtracker@localhost>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: [email-masked]
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Sun, 19 Dec 2010 22:41:08 -0000

On Fri, 17 Dec 2010, Paul Hoffman wrote:

>>>> Subject: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
>>
>> I actually had one more comment. I realised that the TLSA record can protect
>> against Moxy's sslstrip (http://www.thoughtcrime.org/software/sslstrip/)
>>
>> Could we add something like:
>>
>> If a client detects a validated TLSA record, it MUST only use https (not http)
>> to connect to the target site to prevent SSL stripping attacks.
>
> Probably not. That is, if the user is not going to TLS (because the server doesn't do TLS or a MITM has done a downgrade to non-TLS), they should not be looking for TLSA records.

That would suggest an implicit policy of "If a TLSA record exists, only do https". If that
is meant, you should state so in the draft? right now, there is an implicit "http first, perhaps https later".

> The attack you are concerned with is being dealt with in the WEBSEC WG (for the HTTP case) and hopefully by draft-hoffman-server-has-tls (depending on how the WEBSEC WG moves forwards).

The key issue here is the decision point to do "https only". If you make that after connecting to http,
then moxie's attack can change the http traffic to remove any sign for "must go to https". So anything
on port 80 cannot give us authenticated proof to only use port 443. An out of bound DNSSEC validated
record can.

Which is why I'm suggesting the policy of "if TLSA, then only do https". Or at least "start with https"
to allow for (not recommended) https/http mixed content.

Paul

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD2C13A692F for ; Sun, 19 Dec 2010 14:34:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.583
X-Spam-Level:
X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 jlAZjhMF5b6o for ; Sun, 19 Dec 2010 14:34:08 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id B86A43A692E for ; Sun, 19 Dec 2010 14:34:07 -0800 (PST)
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 9452FC45B; Sun, 19 Dec 2010 17:35:58 -0500 (EST)
Date: Sun, 19 Dec 2010 17:35:57 -0500 (EST)
From: Paul Wouters
To: Paul Hoffman
In-Reply-To:
Message-ID:
References: <20101213220001.24500.52050.idtracker@localhost>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: [email-masked]
Subject: Re: [keyassure] TLSA and HASTLS
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Sun, 19 Dec 2010 22:34:09 -0000

On Fri, 17 Dec 2010, Paul Hoffman wrote:

>> Hmm, so draft-hoffman-server-has-tls-01 defines a HASTLS record. Execsum:
>>
>> www.example.com IN HASTLS (25 25 0 443)
>>
>> But we have no method defined anyway to get all this information at once. So now this becomes two full roundtrip DNS queries
>> to get enough information about the pubkey used on a website.
>
> Not at all. If you are about to do TLS and only TLS, then you don't need to query for HASTLS: it is only if you want to do TLS but cannot get there that you need to do HASTLS.
>
>> Is there any work being done on optimising this with an EDNS
>> option?
>
> It's a thought, but one that has not garnered much interest in the past.

So am I right that the consensus seems to be to continue with TLSA and HASTLS now, and look into
an EDNS method later to optimise?

I would be okay with that, and willing to take on the EDNS work to produce a draft. But I would
also really like to see a "pubkey only" type being added to the TLSA draft to satisfy those who
do not want to deal with any certificate information. This might go a long way to make TLSA a
complete solution for those who want to minimize and maximize CA/cert usage. And would probably
be enough to avoid Kaminsky/Gilmore and co to not deploy more TXT record overloads.

>> Is there any reason why the TLSA and HASTLS records could not be merged into one RRTYPE to save a roundtrip?
>> Why aren't we doing something like:
>>
>> www.example.com IN HASTLS (25 25 KeyType FingerPrint 0 443 KeyType FingerPrint)
>
> Because the "this host serves TLS and non-TLS" and "when we serve TLS, this is the key we will use" semantics are orthogonal. Having orthogonal semantics in the same record often leads to implementations that do not interoperate.

Understood. I'll worry about the optimisation step later.

Paul

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 781453A69F5 for ; Sat, 18 Dec 2010 16:10:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.402
X-Spam-Level:
X-Spam-Status: No, score=-3.402 tagged_above=-999 required=5 tests=[AWL=0.196, 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 9qZGL5rYJkeW for ; Sat, 18 Dec 2010 16:10:44 -0800 (PST)
Received: from mail-gx0-f170.google.com (mail-gx0-f170.google.com [209.85.161.170]) by core3.amsl.com (Postfix) with ESMTP id 44B503A69D5 for ; Sat, 18 Dec 2010 16:10:44 -0800 (PST)
Received: by gxk20 with SMTP id 20so1156101gxk.15 for ; Sat, 18 Dec 2010 16:12:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=pDP4/ztOKJ20rHfvajLxEn0vvD3RXaz/WoLmNWRCg6I=; b=mpWvKmU+PSnokIJURoIoa/JcRpGBaQZ1qfIh/UFMG+tDEedR/jIUGm8L/UrMfzKTJc AJcLNStvl7g8N+pM2cy4zgoFe2ShEs1wTyPhFq3QzHhMvjgMuyMVMk8L96R6noDaHc82 zN0PaIg+kC7yGvnsFCv4EjxcllCggeCmCCPuc=
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=HndydZo8Z4mm/0cmcBmVcETlSewGESQ2UHU3/hA/RdU3PYdzaRclO2LAbnlqzwhMRe P2qNZKjLUDv/WNfXYk2lJwsVLh9Izj9Uj1xgNCnlm3oLLI0LpmJRZTq75k6ARfCjcBQk XbeJgKpbciE2cwY80RDPoQjhxtxKsDK97kCKU=
MIME-Version: 1.0
Received: by 10.100.110.16 with SMTP id i16mr1522875anc.103.1292717553974; Sat, 18 Dec 2010 16:12:33 -0800 (PST)
Received: by 10.100.31.8 with HTTP; Sat, 18 Dec 2010 16:12:33 -0800 (PST)
In-Reply-To: <[email-masked]>
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]>
Date: Sun, 19 Dec 2010 00:12:33 +0000
Message-ID:
From: Phillip Hallam-Baker
To: Jakob Schlyter
Content-Type: multipart/alternative; boundary=0016e645ab9a997fae0497b84255
Cc: [email-masked], Paul Hoffman
Subject: Re: [keyassure] TLSA and HASTLS
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Sun, 19 Dec 2010 00:10:45 -0000

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

Make it work first.

Only optimize after you make it work.

The number of DNS round trips should be out of scope, not the functionality
necessary to do the necessary job.

I can fix the number of round trips to one, but we simply should not
consider it at this point.

On Sat, Dec 18, 2010 at 11:05 PM, Jakob Schlyter wrote:

> On 17 dec 2010, at 20.07, Paul Wouters wrote:
>
> > But we have no method defined anyway to get all this information at once.
> So now this becomes two full roundtrip DNS queries
> > to get enough information about the pubkey used on a website.
>
> You could make both queries in parallel, so I would not say this is a big
> problem.
>
> jakob
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

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

Make it work first.

Only optimize after you make it work=
.

The number of DNS round trips should be out of s=
cope, not the functionality necessary to do the necessary job.

I can fix the number of round trips to one, b=
ut we simply should not consider it at this point.

On Sat, Dec 18, 2010 at 11:05 PM, Jakob Schlyter <[email-masked]> wrote:

On 17 dec 2010, at 20.07,=
Paul Wouters wrote:

> But we have no method defined anyway to get all this information at on=
ce. So now this becomes two full roundtrip DNS queries

> to get enough information about the pubkey used on a website.

You could make both queries in parallel, so I would not say this is a=
big problem.

=A0 =A0 =A0 =A0jakob

_______________________________________________

keyassure mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/keyassure

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

--0016e645ab9a997fae0497b84255--

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74C4D3A6BDF for ; Sat, 18 Dec 2010 15:04:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level:
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, 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 tEefAMTRXDKD for ; Sat, 18 Dec 2010 15:04:01 -0800 (PST)
Received: from spg.kirei.se (gomi.kirei.se [91.206.174.9]) by core3.amsl.com (Postfix) with ESMTP id D93DE3A6B49 for ; Sat, 18 Dec 2010 15:04:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=uiUMNpNJo3P5o098UCTFLCXOifXO9alp1/GmB3NC/EY=; b=F5DmLYv7X7rhnirU9LEjBdUux1flXzQSGEhVPZc08aV/7frW3FBWNqnBiWqQMNn9elvgScf1c63JI 5ImnTPqtAa4DI69erE+9H+ChKJVXfI4p6zEys1iYTw8hYwCPOtdmKXFxdkmoEgc1AiR4kMjpj+sR7a pb+4nfirBTytQlFo=
Received: from mail.kirei.se (unknown [91.206.174.10]) by spg.kirei.se (Halon Mail Gateway) with ESMTPS; Sun, 19 Dec 2010 00:05:47 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: Jakob Schlyter
In-Reply-To:
Date: Sun, 19 Dec 2010 00:05:44 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <[email-masked]>
References: <20101213220001.24500.52050.idtracker@localhost>
To: Paul Wouters
X-Mailer: Apple Mail (2.1082)
Cc: [email-masked], Paul Hoffman
Subject: Re: [keyassure] TLSA and HASTLS
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Sat, 18 Dec 2010 23:04:02 -0000

On 17 dec 2010, at 20.07, Paul Wouters wrote:

> But we have no method defined anyway to get all this information at =
once. So now this becomes two full roundtrip DNS queries
> to get enough information about the pubkey used on a website.

You could make both queries in parallel, so I would not say this is a =
big problem.

jakob

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DED573A6BA9 for ; Sat, 18 Dec 2010 12:07:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.468
X-Spam-Level:
X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.131, 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 tFYYYr9Au53b for ; Sat, 18 Dec 2010 12:07:23 -0800 (PST)
Received: from homiemail-a7.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by core3.amsl.com (Postfix) with ESMTP id A75033A6BAC for ; Sat, 18 Dec 2010 12:07:23 -0800 (PST)
Received: from homiemail-a7.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a7.g.dreamhost.com (Postfix) with ESMTP id 7497B25C06B; Sat, 18 Dec 2010 12:09:13 -0800 (PST)
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=NbkddmdqDbB03FjulVWv5QIvPPTw/9DXbDNRJes8uOI BHWGm+7fL078D/kqFWiQ6th2gsoJr0s4EQ4FDBHcdGhS1/3YXjXrqzaNFlQDHIfI +9U1wtIsFw7Bxm4UHKzWshr/XOqkZVLHWmSxJzxXC5LauvLt4wV4wj/Kwm7KTYXE =
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=d62Z2/ckvpyicqgMgfyV9lr7AFI=; b=FK+j3ME5/q bJv1afkpkwF8P9GISV/NAgQIzihPUqmV42xOzyNda24FIsKmukzaa9TAp96kK/gS pRFa4eTs85mv+0krllPPB40sWZLiJwqxm8wDy9rBTra5Ys1i2tUEQ0H4wckJXBtP pHi4BQvzrptcHXzPH5L3pKrRnITr3p/oQ=
Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: [email-masked]) by homiemail-a7.g.dreamhost.com (Postfix) with ESMTPA id 2C9ED25C063; Sat, 18 Dec 2010 12:09:13 -0800 (PST)
From: Matt McCutchen
To: "Jeffrey A. Williams"
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Content-Type: text/plain; charset="UTF-8"
Date: Sat, 18 Dec 2010 15:09:11 -0500
Message-ID: <[email-masked]>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.1
Content-Transfer-Encoding: 7bit
Cc: "[email-masked]"
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Sat, 18 Dec 2010 20:07:25 -0000

On Sat, 2010-12-18 at 12:32 -0600, Jeffrey A. Williams wrote:
> -----Original Message-----
> >From: Matt McCutchen
> >Sent: Dec 18, 2010 12:13 PM
> >To: James Cloos
> >Cc: [email-masked]
> >Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
> >
> >By configuring a trust anchor for the root zone, you are telling the
> >client to demand that the zone be signed with that key. It will not
> >allow the entire DNSSEC to be downgraded away. For it to accept a site
> >as legacy ("insecure"), there must be an NSEC for DS somewhere above the
> >site that chains to the trust anchor.
> >
> >This is basic DNSSEC stuff explained in RFC 4033. I would rather not
> >keep rehashing it here.
>
> What RFC 4033 does say is in regards to this is the following:
> "Even a security-oblivious stub resolver may benefit from DNSSEC if
> the recursive name servers it uses are security-aware, but for the
> stub resolver to place any real reliance on DNSSEC services, the stub
> resolver must trust both the recursive name servers in question and
> the communication channels between itself and those name servers.
> The first of these issues is a local policy issue: in essence, a
> security-oblivious stub resolver has no choice but to place itself at
> the mercy of the recursive name servers that it uses, as it does not
> perform DNSSEC validity checks on its own. The second issue requires
> some kind of channel security mechanism; proper use of DNS
> transaction authentication mechanisms such as SIG(0) ([RFC2931]) or
> TSIG ([RFC2845]) would suffice, as would appropriate use of IPsec.
> Particular implementations may have other choices available, such as
> operating system specific interprocess communication mechanisms.
> Confidentiality is not needed for this channel, but data integrity
> and message authentication are."

That is a separate issue. We assume the client does not enable DNSSEC
unless it performs the validation itself or has a secure connection to a
resolver it trusts, as is implicit in the definition of a
"Security-Aware Stub Resolver" in RFC 4033 section 2.

The relevant text is this:

Insecure: The validating resolver has a trust anchor, a chain of
trust, and, at some delegation point, signed proof of the
non-existence of a DS record. This indicates that subsequent
branches in the tree are provably insecure. A validating resolver
may have a local policy to mark parts of the domain space as
insecure.

Bogus: The validating resolver has a trust anchor and a secure
delegation indicating that subsidiary data is signed, but the
response fails to validate for some reason: missing signatures,
expired signatures, signatures with unsupported algorithms, data
missing that the relevant NSEC RR says should be present, and so
forth.

If a query gives an "insecure" result, a DANE client can fall back to an
alternative method without risk of a downgrade attack.

--
Matt

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C59403A6B72 for ; Sat, 18 Dec 2010 10:30:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.281
X-Spam-Level:
X-Spam-Status: No, score=-2.281 tagged_above=-999 required=5 tests=[AWL=0.318, 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 83-Z5QBqMPvD for ; Sat, 18 Dec 2010 10:30:20 -0800 (PST)
Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by core3.amsl.com (Postfix) with ESMTP id 90CE23A6B12 for ; Sat, 18 Dec 2010 10:30:20 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=AGoU5SbOL4mYc5T50WkHgv3PcKO1WqgUSrNBpY6PLYwzWJQ12Nf80y7+q4MhZAbH; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.52] (helo=mswamui-valley.atl.sa.earthlink.net) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1PU1Zi-0001F4-2I for [email-masked]; Sat, 18 Dec 2010 13:32:10 -0500
Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Sat, 18 Dec 2010 13:32:09 -0500
Message-ID: <[email-masked]>
Date: Sat, 18 Dec 2010 12:32:09 -0600 (GMT-06:00)
From: "Jeffrey A. Williams"
To: "[email-masked]"
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688279e94c525a544ed650e86543a9c5980350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.52
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: "Jeffrey A. Williams"
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Sat, 18 Dec 2010 18:30:21 -0000

Matt and all,

-----Original Message-----
>From: Matt McCutchen
>Sent: Dec 18, 2010 12:13 PM
>To: James Cloos
>Cc: [email-masked]
>Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
>
>On Sat, 2010-12-18 at 12:54 -0500, James Cloos wrote:
>> >>>>> "MM" =3D=3D Matt McCutchen writes:
>>=20
>> >>> Unless the client previously noted that a given remote uses DANE,
>> >>> how can it tell that a non-secure DNS lookup is a MITM attack and
>> >>> not just a legacy site?
>> >>=20
>> >> It can't. According to Matt's suggested text:
>>=20
>> Which of course was my point. =E2=98=BA
>>=20
>> MM> It can, because legacy sites have a NSEC for the DS record in the
>> MM> parent zone. That was our point here:
>>=20
>> MM> http://www.ietf.org/mail-archive/web/keyassure/current/msg01196.html
>>=20
>> Why do you think that a MITM would only munge a child zone and not also
>> its parents?
>
>By configuring a trust anchor for the root zone, you are telling the
>client to demand that the zone be signed with that key. It will not
>allow the entire DNSSEC to be downgraded away. For it to accept a site
>as legacy ("insecure"), there must be an NSEC for DS somewhere above the
>site that chains to the trust anchor.
>
>This is basic DNSSEC stuff explained in RFC 4033. I would rather not
>keep rehashing it here.

What RFC 4033 does say is in regards to this is the following:
"Even a security-oblivious stub resolver may benefit from DNSSEC if
the recursive name servers it uses are security-aware, but for the
stub resolver to place any real reliance on DNSSEC services, the stub
resolver must trust both the recursive name servers in question and
the communication channels between itself and those name servers.
The first of these issues is a local policy issue: in essence, a
security-oblivious stub resolver has no choice but to place itself at
the mercy of the recursive name servers that it uses, as it does not
perform DNSSEC validity checks on its own. The second issue requires
some kind of channel security mechanism; proper use of DNS
transaction authentication mechanisms such as SIG(0) ([RFC2931]) or
TSIG ([RFC2845]) would suffice, as would appropriate use of IPsec.
Particular implementations may have other choices available, such as
operating system specific interprocess communication mechanisms.
Confidentiality is not needed for this channel, but data integrity
and message authentication are."

Regards,
Jeffrey A. Williams
"Obedience of the law is the greatest freedom" -
Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liabilit=
y
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947]
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Updated 1/26/04
Network Eng. SR. Eng. Network data security
ABA member in good standing member ID 01257402=20
E-Mail [email-masked]
Phone: 214-244-4827

>
>--=20
>Matt
>
>_______________________________________________
>keyassure mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/keyassure

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B45993A6B75 for ; Sat, 18 Dec 2010 10:11:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.463
X-Spam-Level:
X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.136, 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 TCtdyfg6lKqG for ; Sat, 18 Dec 2010 10:11:42 -0800 (PST)
Received: from homiemail-a6.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by core3.amsl.com (Postfix) with ESMTP id 27E7F3A6B79 for ; Sat, 18 Dec 2010 10:11:37 -0800 (PST)
Received: from homiemail-a6.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTP id 07AD4598076; Sat, 18 Dec 2010 10:13:24 -0800 (PST)
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=akjocnCS6oK+s020It4bq/09VHQLwFapWY0xmq2DtrA 3ghEgumPlzDXeAJIPpPEHQp45YgKA2eNACqEWwciNTRj5g87IF/ywEpcxQJ1nlDj olcoIscmCJyqFOC9QjaYkWiKZcyNzWjFDJrw8iwRophLtGQk6/hpQSBYameGNbhs =
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=cHG+/ZYVtv2xePKAsKOMbVvz/ws=; b=GrkauqOQCF S3CHY10UH4G4WvVZrQ6bi4Z0bW0925WbD4JI1Adr43reWd4+whoN52mwdVVWo2vN IW5m42IsemxuL0DxJ9OjBNCi4xGFp/LQn+K5ABwpOZqNm4b5rTrb/0+mDoPW60FG o38P0TtdGWpOeAsHET+MQFu+CSvfDCyv4=
Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: [email-masked]) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTPA id A425559806C; Sat, 18 Dec 2010 10:13:23 -0800 (PST)
From: Matt McCutchen
To: James Cloos
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset="UTF-8"
Date: Sat, 18 Dec 2010 13:13:22 -0500
Message-ID: <[email-masked]>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.1
Content-Transfer-Encoding: quoted-printable
Cc: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Sat, 18 Dec 2010 18:11:52 -0000

On Sat, 2010-12-18 at 12:54 -0500, James Cloos wrote:
> >>>>> "MM" =3D=3D Matt McCutchen writes:
>=20
> >>> Unless the client previously noted that a given remote uses DANE,
> >>> how can it tell that a non-secure DNS lookup is a MITM attack and
> >>> not just a legacy site?
> >>=20
> >> It can't. According to Matt's suggested text:
>=20
> Which of course was my point. =E2=98=BA
>=20
> MM> It can, because legacy sites have a NSEC for the DS record in the
> MM> parent zone. That was our point here:
>=20
> MM> http://www.ietf.org/mail-archive/web/keyassure/current/msg01196.htm=
l
>=20
> Why do you think that a MITM would only munge a child zone and not also
> its parents?

By configuring a trust anchor for the root zone, you are telling the
client to demand that the zone be signed with that key. It will not
allow the entire DNSSEC to be downgraded away. For it to accept a site
as legacy ("insecure"), there must be an NSEC for DS somewhere above the
site that chains to the trust anchor.

This is basic DNSSEC stuff explained in RFC 4033. I would rather not
keep rehashing it here.

--=20
Matt

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18C853A6B62 for ; Sat, 18 Dec 2010 09:55:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.958
X-Spam-Level:
X-Spam-Status: No, score=-1.958 tagged_above=-999 required=5 tests=[AWL=0.641, 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 sKMEqcYu+J2E for ; Sat, 18 Dec 2010 09:55:20 -0800 (PST)
Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by core3.amsl.com (Postfix) with ESMTP id A50A73A6B60 for ; Sat, 18 Dec 2010 09:55:20 -0800 (PST)
Received: by eagle.jhcloos.com (Postfix, from userid 10) id 318B6400FF; Sat, 18 Dec 2010 17:56:45 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1292695029; bh=huW+oOCYFqFJb44gKGwCLyT9jwZGRG4DmnOuKSEjBJQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=DT3bd7xJv67WLM+sux85V56CkxSTkdNOZv+ulRZgQdATc4oCLaO0cL17d/gG3cYnh ea9z+tcfdT2/kVky2teuUqMe56PUqNjRt+dfgHOHs2dkF+Axuh9Ot8t4nMZLBCtUyY JKJkJ+jHKSf4nFcmnS2UG1utstdLV/f2NCVqCmDs=
Received: from carbon (localhost [127.0.0.1]) by carbon.jhcloos.org (Postfix) with ESMTP id C4E5330002A; Sat, 18 Dec 2010 17:54:25 +0000 (UTC)
From: James Cloos
To: Matt McCutchen
In-Reply-To: <[email-masked]> (Matt McCutchen's message of "Sat, 18 Dec 2010 00:32:34 -0500")
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux)
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABHNCSVQICAgIfAhkiAAAAI1J REFUOE+lU9ESgCAIg64P1y+ngUdxhl5H8wFbbM0OmUiEhKkCYaZThXCo6KE5sCbA1DDX3genvO4d eBQgEMaM5qy6uWk4SfBYfdu9jvBN9nSVDOKRtwb+I3epboOsOX5pZbJNsBJFvmQQ05YMfieIBnYX FK2N6dOawd97r/e8RjkTLzmMsiVgrAoEugtviCM3v2WzjgAAAABJRU5ErkJggg==
Copyright: Copyright 2009 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: Sat, 18 Dec 2010 12:54:25 -0500
Message-ID:
Lines: 22
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Hashcash: 1:30:101218:[email-masked]::zj1OVAPiznNNjOc3:00000000000000000000000000000000000000BwtfP
X-Hashcash: 1:30:101218:[email-masked]::kbwubMqXK7FHXDdf:00000000000000000000000000000000000000000005CZev
X-Hashcash: 1:30:101218:[email-masked]::whaHSJJa2lr3Unzc:000000000000000000000000000000000000000000YF9WI
Cc: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Sat, 18 Dec 2010 17:55:22 -0000

>>>>> "MM" == Matt McCutchen writes:

>>> Unless the client previously noted that a given remote uses DANE,
>>> how can it tell that a non-secure DNS lookup is a MITM attack and
>>> not just a legacy site?
>>
>> It can't. According to Matt's suggested text:

Which of course was my point. ☺

MM> It can, because legacy sites have a NSEC for the DS record in the
MM> parent zone. That was our point here:

MM> http://www.ietf.org/mail-archive/web/keyassure/current/msg01196.html

Why do you think that a MITM would only munge a child zone and not also
its parents?

-JimC
--
James Cloos OpenPGP: 1024D/ED7DAEA6

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 738CC3A6B54 for ; Sat, 18 Dec 2010 09:29:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.265
X-Spam-Level:
X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=0.334, 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 ZIn4kybs5xU5 for ; Sat, 18 Dec 2010 09:29:33 -0800 (PST)
Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 54FB53A692C for ; Sat, 18 Dec 2010 09:29:33 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=sQYHlPXwnGqPrl7dlW9aeb/mwtg6nVTLQgvYXkrvkmEwLlUUayHLSYr3pc97O+GG; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.30] (helo=mswamui-chipeau.atl.sa.earthlink.net) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1PU0cE-0006vK-El; Sat, 18 Dec 2010 12:30:42 -0500
Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Sat, 18 Dec 2010 12:30:17 -0500
Message-ID: <[email-masked]>
Date: Sat, 18 Dec 2010 11:30:17 -0600 (GMT-06:00)
From: "Jeffrey A. Williams"
To: Steve Schultze , [email-masked]
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688747c79b5f1947280bd71531907d190b7350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.30
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: "Jeffrey A. Williams"
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Sat, 18 Dec 2010 17:29:34 -0000

Steve and all,

-----Original Message-----
>From: Steve Schultze
>Sent: Dec 17, 2010 5:55 PM
>To: [email-masked]
>Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
>
>On Dec 17, 2010, at 4:27 PM, James Cloos wrote:
>>>>>>> "MM" == Matt McCutchen writes:
>>
>>>> For that to work, a lack of dns trust has to fall back to the collection
>>>> of root CAs model.
>>
>> MM> And that works fine when the client gets a "secure" DNSSEC result with
>> MM> zero TLSA records or an "insecure" result. On the other hand, a "bogus"
>> MM> result means the system is misconfigured or under attack. I don't see
>> MM> why there is a demand that the system continue to function in such an event.
>>
>> Unless the client previously noted that a given remote uses DANE, how
>> can it tell that a non-secure DNS lookup is a MITM attack and not just
>> a legacy site?
>
>It can't. According to Matt's suggested text:
>
>'...if any query gives an "insecure" or "indeterminate" result, KIDNS cannot be used with this TLS server, and the client MAY use an alternative certificate validation method.'

Right! And this IMO proposes a problem in that a the PKI method
vis "Trust Anchors" leaves some in a no win or no operation position
which seems extremely odd to me. So what other standardized certification
validation method will there be?
>_______________________________________________
>keyassure mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/keyassure

Regards,
Jeffrey A. Williams
"Obedience of the law is the greatest freedom" -
Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
Network Eng. SR. Eng. Network data security
ABA member in good standing member ID 01257402
E-Mail [email-masked]
Phone: 214-244-4827

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D32E3A69BA for ; Fri, 17 Dec 2010 21:30:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.458
X-Spam-Level:
X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.141, 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 NU-GthFZsq8V for ; Fri, 17 Dec 2010 21:30:47 -0800 (PST)
Received: from homiemail-a3.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by core3.amsl.com (Postfix) with ESMTP id 83EF83A69A9 for ; Fri, 17 Dec 2010 21:30:47 -0800 (PST)
Received: from homiemail-a3.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a3.g.dreamhost.com (Postfix) with ESMTP id EE22328406A; Fri, 17 Dec 2010 21:32:35 -0800 (PST)
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=vm7Lb4WIIiDJ49ScYxhMGTrDtru72/jpyx/haaMpMhm tI7i+9rP+YSORf9LKv1UJppp/40EHYulvmDwvOfNG7TO19hnQgK8MNkSdoVOdBD2 xXdOTJ/o7PnyOvMZcjKJWhVN/hSejTZ8yYdbbdBgwoVpw0qNNDjsuV67R+h7a0Bw =
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=lH6K3Ozu/tGSUoMlCdGANsedRBY=; b=rwYG6PoJlw rFaonr7e2EgUXYYrd9ZhdIPPJ4+hwaJ7VbgJmXenDCSI/D7jSt5q1YJDgnGmvsR6 oTfjkuA+VNnCTJMFIbxHAPbGvHIpKw6b0oqaSR7F84cG4AJGIp6cvLXnekjxgVdH 6ADWo1pVKTE7EpRn0dwjUmo/wUIu5g5Kk=
Received: from [129.2.140.46] (129-2-140-46.wireless.umd.edu [129.2.140.46]) (Authenticated sender: [email-masked]) by homiemail-a3.g.dreamhost.com (Postfix) with ESMTPA id A52CE28406E; Fri, 17 Dec 2010 21:32:35 -0800 (PST)
From: Matt McCutchen
To: Steve Schultze
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset="UTF-8"
Date: Sat, 18 Dec 2010 00:32:34 -0500
Message-ID: <[email-masked]>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.1
Content-Transfer-Encoding: 7bit
Cc: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Sat, 18 Dec 2010 05:30:49 -0000

On Fri, 2010-12-17 at 18:55 -0500, Steve Schultze wrote:
> On Dec 17, 2010, at 4:27 PM, James Cloos wrote:
> >>>>>> "MM" == Matt McCutchen writes:
> >
> >>> For that to work, a lack of dns trust has to fall back to the collection
> >>> of root CAs model.
> >
> > MM> And that works fine when the client gets a "secure" DNSSEC result with
> > MM> zero TLSA records or an "insecure" result. On the other hand, a "bogus"
> > MM> result means the system is misconfigured or under attack. I don't see
> > MM> why there is a demand that the system continue to function in such an event.
> >
> > Unless the client previously noted that a given remote uses DANE, how
> > can it tell that a non-secure DNS lookup is a MITM attack and not just
> > a legacy site?
>
> It can't. According to Matt's suggested text:
>
> '...if any query gives an "insecure" or "indeterminate" result, KIDNS
> cannot be used with this TLS server, and the client MAY use an
> alternative certificate validation method.'

It can, because legacy sites have a NSEC for the DS record in the parent
zone. That was our point here:

http://www.ietf.org/mail-archive/web/keyassure/current/msg01196.html

--
Matt

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECF613A6C57 for ; Fri, 17 Dec 2010 15:53:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.027
X-Spam-Level:
X-Spam-Status: No, score=-4.027 tagged_above=-999 required=5 tests=[AWL=-1.429, 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 zxSpvgWvOYzR for ; Fri, 17 Dec 2010 15:53:54 -0800 (PST)
Received: from ppa05.princeton.edu (ppa05.Princeton.EDU [128.112.129.74]) by core3.amsl.com (Postfix) with ESMTP id 2C6943A6A1B for ; Fri, 17 Dec 2010 15:53:54 -0800 (PST)
Received: from csgsmtp201l.Princeton.EDU (csgsmtp201l.Princeton.EDU [128.112.134.60]) by ppa05.princeton.edu (8.14.3/8.14.3) with ESMTP id oBHNtfrs018841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 17 Dec 2010 18:55:41 -0500
Received: from new-host.home (pool-173-71-100-208.cmdnnj.fios.verizon.net [173.71.100.208]) (authenticated bits=0) by csgsmtp201l.Princeton.EDU (8.13.8/8.12.9) with ESMTP id oBHNtfce030747 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 17 Dec 2010 18:55:41 -0500
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1082)
From: Steve Schultze
In-Reply-To:
Date: Fri, 17 Dec 2010 18:55:40 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
To: [email-masked]
X-Mailer: Apple Mail (2.1082)
X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6200 signatures=655071
X-Proofpoint-Spam-Details: rule=quarantine_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-1010190000 definitions=main-1012170185
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 17 Dec 2010 23:53:55 -0000

On Dec 17, 2010, at 4:27 PM, James Cloos wrote:
>>>>>> "MM" =3D=3D Matt McCutchen writes:
>=20
>>> For that to work, a lack of dns trust has to fall back to the =
collection
>>> of root CAs model.
>=20
> MM> And that works fine when the client gets a "secure" DNSSEC result =
with
> MM> zero TLSA records or an "insecure" result. On the other hand, a =
"bogus"
> MM> result means the system is misconfigured or under attack. I don't =
see
> MM> why there is a demand that the system continue to function in such =
an event.
>=20
> Unless the client previously noted that a given remote uses DANE, how
> can it tell that a non-secure DNS lookup is a MITM attack and not just
> a legacy site?

It can't. According to Matt's suggested text:

'...if any query gives an "insecure" or "indeterminate" result, KIDNS =
cannot be used with this TLS server, and the client MAY use an =
alternative certificate validation method.'=

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0A8E3A6C3B for ; Fri, 17 Dec 2010 13:32:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[AWL=0.694, 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 aChz+cps5379 for ; Fri, 17 Dec 2010 13:32:45 -0800 (PST)
Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by core3.amsl.com (Postfix) with ESMTP id 698FE3A6C3A for ; Fri, 17 Dec 2010 13:32:45 -0800 (PST)
Received: by eagle.jhcloos.com (Postfix, from userid 10) id 228F3400BD; Fri, 17 Dec 2010 21:34:07 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1292621672; bh=EzMx5t57+NlgRMuEljZOrs6v7Lj+vER1k2DNe3Ebs6M=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=Ril7dqSTvbPn1IZwAUScwXncpdEuggyjhhCXMfl0PWdZ42XKh5g4dwM3+cdoGk74x 0ZNF+yLC13gD+qIgkHYOrUTRLknGX92D8ze5qtHeAkcSunJXwYcNboUT3ZjgyeAFSs 2SND2NFMvfZ8frSqKOyCb/XqT09J8dkGdN90RaaQ=
Received: from carbon (localhost [127.0.0.1]) by carbon.jhcloos.org (Postfix) with ESMTP id 931B530002A; Fri, 17 Dec 2010 21:27:15 +0000 (UTC)
From: James Cloos
To: Matt McCutchen
In-Reply-To: <[email-masked]> (Matt McCutchen's message of "Thu, 16 Dec 2010 16:31:19 -0500")
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux)
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABHNCSVQICAgIfAhkiAAAAI1J REFUOE+lU9ESgCAIg64P1y+ngUdxhl5H8wFbbM0OmUiEhKkCYaZThXCo6KE5sCbA1DDX3genvO4d eBQgEMaM5qy6uWk4SfBYfdu9jvBN9nSVDOKRtwb+I3epboOsOX5pZbJNsBJFvmQQ05YMfieIBnYX FK2N6dOawd97r/e8RjkTLzmMsiVgrAoEugtviCM3v2WzjgAAAABJRU5ErkJggg==
Copyright: Copyright 2009 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, 17 Dec 2010 16:27:15 -0500
Message-ID:
Lines: 17
MIME-Version: 1.0
Content-Type: text/plain
X-Hashcash: 1:30:101217:[email-masked]::LpnTCiCFX72gu15l:0000000000000000000000000000000000000098sjz
X-Hashcash: 1:30:101217:[email-masked]::gfsHfoEsHNDTcUB7:000000000000000000000000000000000000000000PDFe9
Cc: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 17 Dec 2010 21:32:46 -0000

>>>>> "MM" == Matt McCutchen writes:

>> For that to work, a lack of dns trust has to fall back to the collection
>> of root CAs model.

MM> And that works fine when the client gets a "secure" DNSSEC result with
MM> zero TLSA records or an "insecure" result. On the other hand, a "bogus"
MM> result means the system is misconfigured or under attack. I don't see
MM> why there is a demand that the system continue to function in such an event.

Unless the client previously noted that a given remote uses DANE, how
can it tell that a non-secure DNS lookup is a MITM attack and not just
a legacy site?

-JimC
--
James Cloos OpenPGP: 1024D/ED7DAEA6

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA9103A6C04 for ; Fri, 17 Dec 2010 13:18:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.877
X-Spam-Level:
X-Spam-Status: No, score=-2.877 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VeYHkARC9Zsa for ; Fri, 17 Dec 2010 13:18:10 -0800 (PST)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id CFB6A3A6C2E for ; Fri, 17 Dec 2010 13:18:10 -0800 (PST)
Received: by iwn40 with SMTP id 40so1230391iwn.31 for ; Fri, 17 Dec 2010 13:19:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=NEdwvb+WhpZ92PUnooZesAhfNUlgPPXqP9V4trNuogg=; b=KSL9estF2NvvNwRxupfFsnl7A1OuiMkBp/Lgw1QRvAeKmfnpXhGsq3XLkqjEf3gFra 8VxL+e6WvjBoUQ0b8X+fSX8Qr1M3R8is9ky+Y8yUz7589EB0Vw5JX4jGBWF5chhszLT3 ai253zoPWs/u3mZTYNWkf9sdAXRSqcc5Jnw/w=
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=a8NHb3DlpoN0HbARZe6fHIM4K1GYCT4reAq192U+MxIGWkOHRGPGjyswAGgIR+VoGz g8opLh+9t9zX/bsv4uabXG1VMGHLTd6GyMBlFTKCs/Voj6mUsBM+wuh+HNHgHMQW0E/S WHKTDcXsvoQZDxEBMkv2m8pH/WC7kTNLPi45s=
MIME-Version: 1.0
Received: by 10.42.175.136 with SMTP id ba8mr325936icb.395.1292620797318; Fri, 17 Dec 2010 13:19:57 -0800 (PST)
Sender: [email-masked]
Received: by 10.42.218.131 with HTTP; Fri, 17 Dec 2010 13:19:57 -0800 (PST)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Date: Fri, 17 Dec 2010 16:19:57 -0500
X-Google-Sender-Auth: CYRUmeWqtPxbxe0wj2-AclbXWyA
Message-ID:
From: Adam Langley
To: Matt McCutchen
Content-Type: text/plain; charset=UTF-8
Cc: [email-masked]
Subject: Re: [keyassure] TLSA and HASTLS
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 17 Dec 2010 21:18:12 -0000

On Fri, Dec 17, 2010 at 3:41 PM, Matt McCutchen wrote:
> For Snap Start to work, the ServerSnapStart extension will need to be
> published in DNS too.

Snap Start is still experimental, even within Google. (I have been
dealing with other stuff that has delayed it.)

In short, I wouldn't worry about Snap Start in this scope. If we
wished to be able to do it, unseen, with data from TLS then we would
need the server's certificate, as well as knowledge about its exact
behaviour in response to TLS extensions. In the interests of size, we
would probably define the extension behaviour precisely and publish an
ECDH point in DNS. Then we could define the X509 gubbins around the
ECDH public key.

But Snap Start is already terribly complex so let's see if the
performance data justifies it first :)

Cheers

AGL

--
Adam Langley [email-masked] http://www.imperialviolet.org

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 384B33A6C0E for ; Fri, 17 Dec 2010 12:43:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.452
X-Spam-Level:
X-Spam-Status: No, score=-2.452 tagged_above=-999 required=5 tests=[AWL=0.147, 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 HqC2HCKKlMD0 for ; Fri, 17 Dec 2010 12:43:08 -0800 (PST)
Received: from homiemail-a62.g.dreamhost.com (mx1.spunky.mail.dreamhost.com [208.97.132.47]) by core3.amsl.com (Postfix) with ESMTP id 2963C3A6C1A for ; Fri, 17 Dec 2010 12:43:08 -0800 (PST)
Received: from homiemail-a62.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTP id E7616634075; Fri, 17 Dec 2010 12:44:55 -0800 (PST)
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=I/BIAuSpWDRaKcyt5lBCW0jPdhVRSwdC7F/evjv4Bwn ZdUoaSCn7Ax23badJczzmY9pK9T1A7yQtasFPQnJtkg7EZu29YMrqCplPdZQFl1X MJxOgd0QOHb61xVhtA3zhIRLnQjTAAyo7CjmDt+DeMw9IHZGqUrqHtENwJgGdFgE =
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=N3FF5b/VzUY5vtEgbZsIP5YmqBQ=; b=s7ulVeK5Ab j8FXQJccPTHnK5GUveTRr3jhLqKpg3IVEsJyyVjirKemkekhmHv1R3W8fqDCaohi b2b7awA4GIuszIY+miSEZFXtQYc0Ci59kN96i9OVpJvLTEKa/1Y65+psn5J0+tTa toSI8MIqxDKXU3/IxwWJOiBPW7PvEeYII=
Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: [email-masked]) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTPA id 9D91E63406C; Fri, 17 Dec 2010 12:44:55 -0800 (PST)
From: Matt McCutchen
To: Paul Wouters
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost>
Content-Type: text/plain; charset="UTF-8"
Date: Fri, 17 Dec 2010 15:44:54 -0500
Message-ID: <[email-masked]>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.1
Content-Transfer-Encoding: 7bit
Cc: [email-masked]
Subject: Re: [keyassure] TLSA and HASTLS
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 17 Dec 2010 20:43:09 -0000

On Fri, 2010-12-17 at 14:42 -0500, Paul Wouters wrote:
> On Fri, 17 Dec 2010, Paul Hoffman wrote:
>
> >> Is there any work being done on optimising this with an EDNS
> >> option?
> >
> > It's a thought, but one that has not garnered much interest in the past.
>
> I'd be interested on working on that, ideally with more then just these specific options.
> But I have not figured out how to be able to trust the lack of additional records with
> a validatable response those other records were not there.

It should be easy enough: in any case in which the server would have
returned a record had it existed, return the NSEC record instead.

I guess there are two approaches: the server could add records it thinks
the client wants, or the client could ask for all records it wants. For
the second approach, there is an old draft for queries with multiple
questions:

http://tools.ietf.org/html/draft-ietf-dnsext-edns1-03#section-4

Unfortunately, existing servers seem to reject queries with QDCOUNT > 1
with a format error. So to minimize the number of round trips, we would
need a different mechanism with the property that servers that don't
support it will still give one answer.

--
Matt

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13AD63A6C03 for ; Fri, 17 Dec 2010 12:40:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.387
X-Spam-Level:
X-Spam-Status: No, score=-3.387 tagged_above=-999 required=5 tests=[AWL=0.211, 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 f-mkWtX+8FEa for ; Fri, 17 Dec 2010 12:40:04 -0800 (PST)
Received: from mail-gw0-f42.google.com (mail-gw0-f42.google.com [74.125.83.42]) by core3.amsl.com (Postfix) with ESMTP id C93553A6998 for ; Fri, 17 Dec 2010 12:40:03 -0800 (PST)
Received: by gwb20 with SMTP id 20so1046994gwb.15 for ; Fri, 17 Dec 2010 12:41:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=CoSg6hJUP93n364bXvwzDwn4pQNKysJbCQzVmmUazVI=; b=dK11+lvomO327k/UptHg/yDh4U5MVOr1lLV+MZolxZjH3YnuIpX1kmQc+lhiBrnTAQ ogmvurFIalxIOGiwb/aoV+ExUMIjj3noPnKgNtBw0Pv0WZQLhXyoL17q8e5LEAw+zR8B 1lbiLggqfr0BQK+a2kYWuKPwB6Z4BMsl+dyek=
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=KP/oQHmQw1Vbwb3juk9FwWIea5nR2ctnqOdtRTZ4kF8oYLBxtNjaq9bgPU2lmheHD8 8mzfXSfORdVrsv/v8K/5IwPa+Qq7iONCXjIrGpUx7OjINuCsqTv7mGVryBqzY9DBK0lU lrysvegHUTRrj5E4LtdMhi3DxaCfCyeeMVbnA=
MIME-Version: 1.0
Received: by 10.100.122.9 with SMTP id u9mr889152anc.171.1292618511224; Fri, 17 Dec 2010 12:41:51 -0800 (PST)
Received: by 10.100.31.8 with HTTP; Fri, 17 Dec 2010 12:41:51 -0800 (PST)
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost>
Date: Fri, 17 Dec 2010 20:41:51 +0000
Message-ID:
From: Phillip Hallam-Baker
To: Paul Wouters
Content-Type: multipart/alternative; boundary=0016e6407e80310f6b0497a13398
Cc: [email-masked], Paul Hoffman
Subject: Re: [keyassure] TLSA and HASTLS
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 17 Dec 2010 20:40:05 -0000

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

If you are going to say 'must use TLS' you are going to have to specify the
protocol.

HTTP is not the only protocol that uses TLS, it is used on SMTP, POP3, IMAP,
etc.

So any useful security policy mechanism is going to have to allow for
protocol specific statements to be made. The natural mechanism to use for
this is SRV style prefixes.

_http._tcp.example.com POLICY "Always use TLS and use key X"
_pop3._tcp.example.com POLICY "Hey use TLS if you like man, the key is Y"

Protocol level granularity is essential, but if you combine with SRV
processing, you can address protocol-host level granularity.

This one actually makes automating management very clean. A host offering a
service can specify its keys and security parameters at the same time.

On Fri, Dec 17, 2010 at 8:25 PM, Paul Wouters wrote:

> On Fri, 17 Dec 2010, Phillip Hallam-Baker wrote:
>
> I will just point out that you have come essentially to the scheme I
>> proposed six months back at the start of all this.
>> It makes perfect sense to combine 'must use TLS' with 'must use this key'.
>>
>> However to make that work you need to have protocol level granularity. And
>> then you hit the problem that protocol prefixes only work
>> for canonical names.
>>
>
> Can you explain this to me in some concrete terms? I don't understand
> "protocol level granularity" nor "protocol prefixes"?
>
> I think with "protocol level granularity" you mean specifying
> services/ports?
> I'm not sure what "protocol prefix" would be?
>
> Paul
>

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

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

If you are going to say 'must use TLS' you are going to have to spe=
cify the protocol.

HTTP is not the only protocol that us=
es TLS, it is used on SMTP, POP3, IMAP, etc.

So an=
y useful security policy mechanism is going to have to allow for protocol s=
pecific statements to be made. The natural mechanism to use for this is SRV=
style prefixes.

_http._tcp.example.c=
om POLICY "Always use TLS and use key X"

_pop3._tcp.example.com POLICY "Hey use TL=
S if you like man, the key is Y"

Protocol level granularity is essential,=
but if you combine with SRV processing, you can address protocol-host leve=
l granularity.

This one actually makes automating =
management very clean. A host offering a service can specify its keys and s=
ecurity parameters at the same time.

On Fri, Dec 17,=
2010 at 8:25 PM, Paul Wouters <[email-masked]> wrote:

On Fri, 17 Dec 2010, Phillip Hallam-Baker wrote:

I will just point out that you have come essentially to the scheme I propos=
ed six months back at the start of all this.

It makes perfect sense to combine 'must use TLS' with 'must use=
this key'.

However to make that work you need to have protocol level granularity. And =
then you hit the problem that protocol prefixes only work

for canonical names.

Can you explain this to me in some concrete terms? I don't understand &=
quot;protocol level granularity" nor "protocol prefixes"?

I think with "protocol level granularity" you mean specifying ser=
vices/ports?

I'm not sure what "protocol prefix" would be?

Paul

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

--0016e6407e80310f6b0497a13398--

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3660B3A6C15 for ; Fri, 17 Dec 2010 12:39:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.446
X-Spam-Level:
X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[AWL=0.153, 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 VmP-23OtzWOZ for ; Fri, 17 Dec 2010 12:39:16 -0800 (PST)
Received: from homiemail-a60.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by core3.amsl.com (Postfix) with ESMTP id 585073A6C13 for ; Fri, 17 Dec 2010 12:39:16 -0800 (PST)
Received: from homiemail-a60.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a60.g.dreamhost.com (Postfix) with ESMTP id 172EB3BC06B; Fri, 17 Dec 2010 12:41:04 -0800 (PST)
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=fGwKIdahFlR2FR8EsUN8y65IzkaQUgedc28cAvavjFg d8twmPjjbN/ge/iF+4+NWE80Vzfuat4pkhbfjyGjJiz/5s1cpmcd79OD7F827jdZ eLF3f7pqXhNw/VRwuoaa1HitHUgEWorcEoQJpZZgB3OwhS5/JYIRcyOfGeoU9VfM =
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=zYBb52AuNwOCDm/PmtC17qo8+c8=; b=TuZOI2Ygty GHBzoS65mGJMFrMou86gCTyw7ZVWqC4bxB6dD3Soray8aYzeou+ZTPvRQZaqCi2z GZNH/p+NxFVn1RmNQl8ItWVArE2o29RjJmvlpInmhOKUqJunPEyLxiz+jgLAXXsX a3fCNLejmS1v8+9V5kuOQzN1YsQ1drsps=
Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: [email-masked]) by homiemail-a60.g.dreamhost.com (Postfix) with ESMTPA id ADC903BC059; Fri, 17 Dec 2010 12:41:03 -0800 (PST)
From: Matt McCutchen
To: Brian Smith
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Content-Type: text/plain; charset="UTF-8"
Date: Fri, 17 Dec 2010 15:41:02 -0500
Message-ID: <[email-masked]>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.1
Content-Transfer-Encoding: 7bit
Cc: [email-masked]
Subject: Re: [keyassure] TLSA and HASTLS
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 17 Dec 2010 20:39:17 -0000

On Fri, 2010-12-17 at 11:52 -0800, Brian Smith wrote:
> Yes, this is exactly the right case to optimize for. DNS should
> immediately give us enough information to know whether to try HTTPS
> on port 443 or HTTP on port 80. And, in the HTTPS-is-available case,
> we should the authenticated (ephemeral) public key material before
> making the TCP connection so that we can use something like TLS Snap
> Start for servers we've never even contacted.

For Snap Start to work, the ServerSnapStart extension will need to be
published in DNS too.

--
Matt

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AC0F3A69B8 for ; Fri, 17 Dec 2010 12:24:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.582
X-Spam-Level:
X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 1zH0dEdTXkpn for ; Fri, 17 Dec 2010 12:24:13 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 841F33A69B3 for ; Fri, 17 Dec 2010 12:24:13 -0800 (PST)
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 66F1CC4D9; Fri, 17 Dec 2010 15:25:59 -0500 (EST)
Date: Fri, 17 Dec 2010 15:25:58 -0500 (EST)
From: Paul Wouters
To: Phillip Hallam-Baker
In-Reply-To:
Message-ID:
References: <20101213220001.24500.52050.idtracker@localhost>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: [email-masked], Paul Hoffman
Subject: Re: [keyassure] TLSA and HASTLS
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 17 Dec 2010 20:24:14 -0000

On Fri, 17 Dec 2010, Phillip Hallam-Baker wrote:

> I will just point out that you have come essentially to the scheme I proposed six months back at the start of all this.
> It makes perfect sense to combine 'must use TLS' with 'must use this key'.
>
> However to make that work you need to have protocol level granularity. And then you hit the problem that protocol prefixes only work
> for canonical names.

Can you explain this to me in some concrete terms? I don't understand "protocol level granularity" nor "protocol prefixes"?

I think with "protocol level granularity" you mean specifying services/ports?
I'm not sure what "protocol prefix" would be?

Paul

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 477CB3A6BE7 for ; Fri, 17 Dec 2010 11:51:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.348
X-Spam-Level:
X-Spam-Status: No, score=-3.348 tagged_above=-999 required=5 tests=[AWL=0.250, 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 0q2JlqzF9A74 for ; Fri, 17 Dec 2010 11:51:31 -0800 (PST)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id E9D203A6BE2 for ; Fri, 17 Dec 2010 11:51:30 -0800 (PST)
Received: by gyd12 with SMTP id 12so393971gyd.31 for ; Fri, 17 Dec 2010 11:53:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=he8H8m3CYWT5ZwizL+diJy6vprmvkpn8Wk5k1wQ/d3U=; b=aYm3az2Lmt4bNJPw7W1unBeJ1U7Pl1Y2hksOgfNxIFqGrswgCs+XBC/wOSbatuSe7W M2ubfcKLD6LbRNPswlf+pTekq58x84xRzyy9E1L+VLwL2UaJGSyeHQvwAaRGIk9S4oz1 9dK+qxmuWhJAM3GMI/Ax8INjPFTAHPDkHv1J0=
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=f+AbpWenTTShQqzuwre9AhPSZ79UKOr6dIv2K1bl2p062Llg+UgoyrLBdHpP+IQa/6 xP0+ZmdCe+wUnaqq1SdA2P8dCfKIXL1gppeUUrIQbVUHDK5549NkAHcwcactFvwv4cIk OY6WWcF+lYbsf3q4f9EEZHP+jzJHjaB+Pq5oc=
MIME-Version: 1.0
Received: by 10.100.208.14 with SMTP id f14mr833629ang.205.1292615598334; Fri, 17 Dec 2010 11:53:18 -0800 (PST)
Received: by 10.100.31.8 with HTTP; Fri, 17 Dec 2010 11:53:18 -0800 (PST)
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost>
Date: Fri, 17 Dec 2010 19:53:18 +0000
Message-ID:
From: Phillip Hallam-Baker
To: Paul Wouters
Content-Type: multipart/alternative; boundary=001636af022f91e4820497a08573
Cc: [email-masked], Paul Hoffman
Subject: Re: [keyassure] TLSA and HASTLS
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 17 Dec 2010 19:51:33 -0000

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

I will just point out that you have come essentially to the scheme I
proposed six months back at the start of all this.

It makes perfect sense to combine 'must use TLS' with 'must use this key'.

However to make that work you need to have protocol level granularity. And
then you hit the problem that protocol prefixes only work for canonical
names.

Hence, I think that you will find that to meet the full set of use cases you
would want to support, you need to address discovery as well.

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

I will just point out that you have come essentially to the scheme I propos=
ed six months back at the start of all this.

It makes perfect sense to combine 'must use TLS'=
; with 'must use this key'.

However to mak=
e that work you need to have protocol level granularity. And then you hit t=
he problem that protocol prefixes only work for canonical names.

Hence, I think that you will find that to meet the full=
set of use cases you would want to support, you need to address discovery =
as well.

--001636af022f91e4820497a08573--

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D439D3A6BE3 for ; Fri, 17 Dec 2010 11:50:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYy6c0llS7uo for ; Fri, 17 Dec 2010 11:50:37 -0800 (PST)
Received: from mail.mozilla.com (corp01.sj.mozilla.com [63.245.208.141]) by core3.amsl.com (Postfix) with ESMTP id DE8BC3A6BC1 for ; Fri, 17 Dec 2010 11:50:36 -0800 (PST)
Received: from mail.mozilla.com (mail.mozilla.com [10.2.72.15]) by mail.mozilla.com (Postfix) with ESMTP id 75F3D17FEB59; Fri, 17 Dec 2010 11:52:24 -0800 (PST)
Date: Fri, 17 Dec 2010 11:52:24 -0800 (PST)
From: Brian Smith
To: Paul Wouters
Message-ID: <[email-masked]>
In-Reply-To:
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Originating-IP: [63.245.220.240]
X-Mailer: Zimbra 6.0.8_GA_2678 (ZimbraWebClient - FF3.0 (Win)/6.0.8_GA_2661)
Cc: [email-masked], Paul Hoffman
Subject: Re: [keyassure] TLSA and HASTLS
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 17 Dec 2010 19:50:38 -0000

Paul Wouters wrote:
> Paul Hoffman wrote:
> >Paul Wouters wrote:
> >> www.example.com IN HASTLS (25 25 0 443)
> >>
> >> But we have no method defined anyway to get all this information at
> >> once. So now this becomes two full roundtrip DNS queries
> >> to get enough information about the pubkey used on a website.
> >
> > Not at all. If you are about to do TLS and only TLS, then you don't
> > need to query for HASTLS: it is only if you want to do TLS but
> > cannot get there that you need to do HASTLS.
>
> But how do you start? Attempting 443 before going to 80? That would
> also be a roundtrip to detect. And then after you got a connect on
> port 443, you need to do the lookup for TLSA. We could still safe
> a round trip here. Ideally, one DNS lookup and get the TLS
> information (hastls+tlsa) and one tcp connection to the right port.
> And in absense of TLSA/HASTLS, go to port 80 (and perhaps get an
> HTTP STS header to go to port 443 and use PCIX CA chains)

Yes, this is exactly the right case to optimize for. DNS should
immediately give us enough information to know whether to try HTTPS
on port 443 or HTTP on port 80. And, in the HTTPS-is-available case,
we should the authenticated (ephemeral) public key material before
making the TCP connection so that we can use something like TLS Snap
Start for servers we've never even contacted.

Cheers,
Brian

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3380D3A69A4 for ; Fri, 17 Dec 2010 11:42:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.579
X-Spam-Level:
X-Spam-Status: No, score=-101.579 tagged_above=-999 required=5 tests=[AWL=0.467, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 hpPAidma9FVz for ; Fri, 17 Dec 2010 11:42:23 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id EE9F33A6BDF for ; Fri, 17 Dec 2010 11:42:22 -0800 (PST)
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 oBHJi8Nn008522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Dec 2010 12:44:10 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost>
Date: Fri, 17 Dec 2010 11:44:07 -0800
To: Paul Wouters
From: Paul Hoffman
Content-Type: text/plain; charset="us-ascii"
Cc: Adam Langley , [email-masked]
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 17 Dec 2010 19:42:24 -0000

At 2:17 PM -0500 12/17/10, Paul Wouters wrote:
>On Fri, 17 Dec 2010, Paul Hoffman wrote:
>
>>At 1:38 PM -0500 12/17/10, Adam Langley wrote:
>>>On Fri, Dec 17, 2010 at 1:27 PM, Paul Hoffman wrote:
>>>>The attack you are concerned with is being dealt with in the WEBSEC WG (for the HTTP case)
>>>
>>>Indeed. HSTS appears to be the emerging standard around this for
>>>browsers: http://dev.chromium.org/sts
>>
>>Hopefully so, but note that HSTS is far from settled technically. It will probably be the next big discussion once the WEBSEC WG gets a bit more active.
>
>Also, this does not address the issue where we can shut off port 80 completely. We need a non-http/https
>based piece of information for that. HASTLS or TLSA would do - a combination record might do better!

Again, that's what will be being discussed in WEBSEC. Note that that WG *only* cares about HTTP (80 and 443), whereas TLSA is for all TLS-using applications. If that turns out to be a problem, we may need to move this to the Apps Area mailing list.

--Paul Hoffman, Director
--VPN Consortium

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CE063A69A4 for ; Fri, 17 Dec 2010 11:40:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.582
X-Spam-Level:
X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 Otx8XmeK1z1g for ; Fri, 17 Dec 2010 11:40:37 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 0D5D33A6BC5 for ; Fri, 17 Dec 2010 11:40:37 -0800 (PST)
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 AD8A0C412; Fri, 17 Dec 2010 14:42:23 -0500 (EST)
Date: Fri, 17 Dec 2010 14:42:23 -0500 (EST)
From: Paul Wouters
To: Paul Hoffman
In-Reply-To:
Message-ID:
References: <20101213220001.24500.52050.idtracker@localhost>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: [email-masked]
Subject: Re: [keyassure] TLSA and HASTLS
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 17 Dec 2010 19:40:38 -0000

On Fri, 17 Dec 2010, Paul Hoffman wrote:

>> www.example.com IN HASTLS (25 25 0 443)
>>
>> But we have no method defined anyway to get all this information at once. So now this becomes two full roundtrip DNS queries
>> to get enough information about the pubkey used on a website.
>
> Not at all. If you are about to do TLS and only TLS, then you don't need to query for HASTLS: it is only if you want to do TLS but cannot get there that you need to do HASTLS.

But how do you start? Attempting 443 before going to 80? That would also be a roundtrip to detect.
And then after you got a connect on port 443, you need to do the lookup for TLSA. We could still
safe a round trip here. Ideally, one DNS lookup and get the TLS information (hastls+tlsa) and
one tcp connection to the right port. And in absense of TLSA/HASTLS, go to port 80 (and perhaps
get an HTTP STS header to go to port 443 and use PCIX CA chains)

>> Is there any work being done on optimising this with an EDNS
>> option?
>
> It's a thought, but one that has not garnered much interest in the past.

I'd be interested on working on that, ideally with more then just these specific options.
But I have not figured out how to be able to trust the lack of additional records with
a validatable response those other records were not there.

>> Is there any reason why the TLSA and HASTLS records could not be merged into one RRTYPE to save a roundtrip?
>> Why aren't we doing something like:
>>
>> www.example.com IN HASTLS (25 25 KeyType FingerPrint 0 443 KeyType FingerPrint)
>
> Because the "this host serves TLS and non-TLS" and "when we serve TLS, this is the key we will use" semantics are orthogonal. Having orthogonal semantics in the same record often leads to implementations that do not interoperate.

Less prone to interop issues then giving them TLSA/HASTLS records in the additional section of
an A record lookup?

Paul

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 009E23A69C6 for ; Fri, 17 Dec 2010 11:39:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.576
X-Spam-Level:
X-Spam-Status: No, score=-101.576 tagged_above=-999 required=5 tests=[AWL=0.470, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 w5cDvrWyJYHC for ; Fri, 17 Dec 2010 11:39:42 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 4EAAC3A69A4 for ; Fri, 17 Dec 2010 11:39:42 -0800 (PST)
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 oBHJfSL2008420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Dec 2010 12:41:29 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost>
Date: Fri, 17 Dec 2010 11:41:26 -0800
To: Paul Wouters
From: Paul Hoffman
Content-Type: text/plain; charset="us-ascii"
Cc: [email-masked]
Subject: Re: [keyassure] TLSA and HASTLS
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 17 Dec 2010 19:39:43 -0000

A quick followup: I do not mean to sound that it is bad or not possible to do what you are asking, just that it had been discussed a bit before we were a WG.

Jakob and I have an agreement with Warren and Ondrej that we are document editors, not authors. We take direction from the chairs about what major changes should be made. We will do editorial changes and non-controversial "please add a sentence explaining this better" without making the chairs tell us, but technical changes come from the WG through the consensus process.

You might find Jakob or I arguing one way or another on technical suggestions in the WG. We are doing so as WG members, not document authors.

--Paul Hoffman, Director
--VPN Consortium

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AF113A69A4 for ; Fri, 17 Dec 2010 11:37:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.439
X-Spam-Level:
X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[AWL=0.160, 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 nhj061adaQSD for ; Fri, 17 Dec 2010 11:37:32 -0800 (PST)
Received: from homiemail-a2.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by core3.amsl.com (Postfix) with ESMTP id 851DA3A69C3 for ; Fri, 17 Dec 2010 11:37:31 -0800 (PST)
Received: from homiemail-a2.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a2.g.dreamhost.com (Postfix) with ESMTP id 1273F28006D; Fri, 17 Dec 2010 11:39:19 -0800 (PST)
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=YsYLYFjUyPdTfIbXTSHMNLTneGnvvkdDgoyWoTMiAsx Udr+6RhvfC9MDrgdt/9PSaBR3ylqRLq1YLQPxQmDAGZTr0FP9zybx/K8IpFmwIt6 lVTWGVefljbAF7o5oB4SfuuDThEm8Nx1paeWRaTI74pS+m6ra5Rkcii3IQaJoLWI =
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=OvKVCRFscGmwFed+DLNfJHKo78M=; b=Z+3BlFtbhs 78rgJmlmBlX2v7AXQ8f2TrM8Uu4dbjIQh2fKhcgwpK2u7119NkeHce9l2rAFxVrW fZmdmMQ87deR/ENdOkCRoIlRJP5defA/ezHwbByai1xadW6rEOiVxAi5Ni2LR5wx u+6JQot9AVwetTRJzfqDJju5gyE1JhTT8=
Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: [email-masked]) by homiemail-a2.g.dreamhost.com (Postfix) with ESMTPA id A5E5F280069; Fri, 17 Dec 2010 11:39:18 -0800 (PST)
From: Matt McCutchen
To: Paul Hoffman
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost>
Content-Type: text/plain; charset="UTF-8"
Date: Fri, 17 Dec 2010 14:39:17 -0500
Message-ID: <[email-masked]>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.1
Content-Transfer-Encoding: 7bit
Cc: [email-masked]
Subject: Re: [keyassure] TLSA and HASTLS
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 17 Dec 2010 19:37:33 -0000

On Fri, 2010-12-17 at 11:32 -0800, Paul Hoffman wrote:
> At 2:07 PM -0500 12/17/10, Paul Wouters wrote:
> > Is there any work being done on optimising this with an EDNS
> >option?
>
> It's a thought, but one that has not garnered much interest in the past.

Too bad. This issue is going to come up every time we want browsers to
get some new piece of information from DNSSEC. E.g., it would be nice
to move the public suffix list (http://publicsuffix.org) that is
currently shipped with browsers into DNSSEC.

--
Matt

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9733F3A6BDD for ; Fri, 17 Dec 2010 11:30:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.572
X-Spam-Level:
X-Spam-Status: No, score=-101.572 tagged_above=-999 required=5 tests=[AWL=0.474, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 WEdgmqdPW7cr for ; Fri, 17 Dec 2010 11:30:41 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id C724A3A6BDB for ; Fri, 17 Dec 2010 11:30:41 -0800 (PST)
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 oBHJWR9A008097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Dec 2010 12:32:29 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost>
Date: Fri, 17 Dec 2010 11:32:26 -0800
To: Paul Wouters
From: Paul Hoffman
Content-Type: text/plain; charset="us-ascii"
Cc: [email-masked]
Subject: Re: [keyassure] TLSA and HASTLS
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 17 Dec 2010 19:30:42 -0000

At 2:07 PM -0500 12/17/10, Paul Wouters wrote:
>On Fri, 17 Dec 2010, Paul Hoffman wrote:
>
>>>Could we add something like:
>>>
>>> If a client detects a validated TLSA record, it MUST only use https (not http)
>>> to connect to the target site to prevent SSL stripping attacks.
>>
>>Probably not. That is, if the user is not going to TLS (because the server doesn't do TLS or a MITM has done a downgrade to non-TLS), they should not be looking for TLSA records.
>>
>>The attack you are concerned with is being dealt with in the WEBSEC WG (for the HTTP case) and hopefully by draft-hoffman-server-has-tls (depending on how the WEBSEC WG moves forwards).
>
>Hmm, so draft-hoffman-server-has-tls-01 defines a HASTLS record. Execsum:
>
> www.example.com IN HASTLS (25 25 0 443)
>
>But we have no method defined anyway to get all this information at once. So now this becomes two full roundtrip DNS queries
>to get enough information about the pubkey used on a website.

Not at all. If you are about to do TLS and only TLS, then you don't need to query for HASTLS: it is only if you want to do TLS but cannot get there that you need to do HASTLS.

> Is there any work being done on optimising this with an EDNS
>option?

It's a thought, but one that has not garnered much interest in the past.

>Is there any reason why the TLSA and HASTLS records could not be merged into one RRTYPE to save a roundtrip?
>Why aren't we doing something like:
>
> www.example.com IN HASTLS (25 25 KeyType FingerPrint 0 443 KeyType FingerPrint)

Because the "this host serves TLS and non-TLS" and "when we serve TLS, this is the key we will use" semantics are orthogonal. Having orthogonal semantics in the same record often leads to implementations that do not interoperate.

--Paul Hoffman, Director
--VPN Consortium

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EBC03A6BCA for ; Fri, 17 Dec 2010 11:17:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.581
X-Spam-Level:
X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 7K2H-uo20g8c for ; Fri, 17 Dec 2010 11:17:24 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 3ED3D3A6BB2 for ; Fri, 17 Dec 2010 11:17:24 -0800 (PST)
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 53F8BC4D9; Fri, 17 Dec 2010 14:19:11 -0500 (EST)
Date: Fri, 17 Dec 2010 14:19:11 -0500 (EST)
From: Paul Wouters
To: Matt McCutchen
In-Reply-To: <[email-masked]>
Message-ID:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 17 Dec 2010 19:17:26 -0000

On Fri, 17 Dec 2010, Matt McCutchen wrote:

>> Could we add something like:
>>
>> If a client detects a validated TLSA record, it MUST only use https (not http)
>> to connect to the target site to prevent SSL stripping attacks.
>
> No. The sole purpose of TLSA is to determine which keys/certificates
> are valid for a TLS connection. What you describe is Strict Transport
> Security, which is being pursued separately. It will probably have its
> own record in DNSSEC.

A quick read, it looked more like an HTTP header then a DNS record?

So that would be THREE records to lookup before we know how to properly and safely
contact a website with a pubkey placed in dns......

Paul

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ADFE3A6BC7 for ; Fri, 17 Dec 2010 11:15:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.581
X-Spam-Level:
X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 yfkBA+vc1w-X for ; Fri, 17 Dec 2010 11:15:54 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 012DA3A6BB2 for ; Fri, 17 Dec 2010 11:15:54 -0800 (PST)
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 E6CC0C4D9; Fri, 17 Dec 2010 14:17:40 -0500 (EST)
Date: Fri, 17 Dec 2010 14:17:40 -0500 (EST)
From: Paul Wouters
To: Paul Hoffman
In-Reply-To:
Message-ID:
References: <20101213220001.24500.52050.idtracker@localhost>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: Adam Langley , [email-masked]
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 17 Dec 2010 19:15:55 -0000

On Fri, 17 Dec 2010, Paul Hoffman wrote:

> At 1:38 PM -0500 12/17/10, Adam Langley wrote:
>> On Fri, Dec 17, 2010 at 1:27 PM, Paul Hoffman wrote:
>>> The attack you are concerned with is being dealt with in the WEBSEC WG (for the HTTP case)
>>
>> Indeed. HSTS appears to be the emerging standard around this for
>> browsers: http://dev.chromium.org/sts
>
> Hopefully so, but note that HSTS is far from settled technically. It will probably be the next big discussion once the WEBSEC WG gets a bit more active.

Also, this does not address the issue where we can shut off port 80 completely. We need a non-http/https
based piece of information for that. HASTLS or TLSA would do - a combination record might do better!

Paul

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E4503A6BC3 for ; Fri, 17 Dec 2010 11:12:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.568
X-Spam-Level:
X-Spam-Status: No, score=-101.568 tagged_above=-999 required=5 tests=[AWL=0.478, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 l6A7iPkfliCo for ; Fri, 17 Dec 2010 11:12:25 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 87BAB3A6977 for ; Fri, 17 Dec 2010 11:12:25 -0800 (PST)
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 oBHJEADh007508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Dec 2010 12:14:12 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost>
Date: Fri, 17 Dec 2010 11:14:09 -0800
To: Adam Langley
From: Paul Hoffman
Content-Type: text/plain; charset="us-ascii"
Cc: [email-masked]
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 17 Dec 2010 19:12:26 -0000

At 1:38 PM -0500 12/17/10, Adam Langley wrote:
>On Fri, Dec 17, 2010 at 1:27 PM, Paul Hoffman wrote:
>> The attack you are concerned with is being dealt with in the WEBSEC WG (for the HTTP case)
>
>Indeed. HSTS appears to be the emerging standard around this for
>browsers: http://dev.chromium.org/sts

Hopefully so, but note that HSTS is far from settled technically. It will probably be the next big discussion once the WEBSEC WG gets a bit more active.

--Paul Hoffman, Director
--VPN Consortium

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AA843A6BBF for ; Fri, 17 Dec 2010 11:05:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.58
X-Spam-Level:
X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 J8f3io2msFwA for ; Fri, 17 Dec 2010 11:05:47 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 8ECAB3A6992 for ; Fri, 17 Dec 2010 11:05:47 -0800 (PST)
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 1E116C4D9; Fri, 17 Dec 2010 14:07:34 -0500 (EST)
Date: Fri, 17 Dec 2010 14:07:33 -0500 (EST)
From: Paul Wouters
To: Paul Hoffman
In-Reply-To:
Message-ID:
References: <20101213220001.24500.52050.idtracker@localhost>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: [email-masked]
Subject: [keyassure] TLSA and HASTLS
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 17 Dec 2010 19:05:50 -0000

On Fri, 17 Dec 2010, Paul Hoffman wrote:

>> Could we add something like:
>>
>> If a client detects a validated TLSA record, it MUST only use https (not http)
>> to connect to the target site to prevent SSL stripping attacks.
>
> Probably not. That is, if the user is not going to TLS (because the server doesn't do TLS or a MITM has done a downgrade to non-TLS), they should not be looking for TLSA records.
>
> The attack you are concerned with is being dealt with in the WEBSEC WG (for the HTTP case) and hopefully by draft-hoffman-server-has-tls (depending on how the WEBSEC WG moves forwards).

Hmm, so draft-hoffman-server-has-tls-01 defines a HASTLS record. Execsum:

www.example.com IN HASTLS (25 25 0 443)

But we have no method defined anyway to get all this information at once. So now this becomes two full roundtrip DNS queries
to get enough information about the pubkey used on a website. Is there any work being done on optimising this with an EDNS
option?

Is there any reason why the TLSA and HASTLS records could not be merged into one RRTYPE to save a roundtrip?
Why aren't we doing something like:

www.example.com IN HASTLS (25 25 KeyType FingerPrint 0 443 KeyType FingerPrint)

Paul

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 364BF3A6BBC for ; Fri, 17 Dec 2010 10:36:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.852
X-Spam-Level:
X-Spam-Status: No, score=-2.852 tagged_above=-999 required=5 tests=[AWL=0.125, 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 yvyGGF4NH8Q4 for ; Fri, 17 Dec 2010 10:36:45 -0800 (PST)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 2C6E13A68EB for ; Fri, 17 Dec 2010 10:36:45 -0800 (PST)
Received: by iwn40 with SMTP id 40so1082666iwn.31 for ; Fri, 17 Dec 2010 10:38:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=FL+G7LIX/9pFF3RK7Qgq/jAWuEafGlvLks6AK2kBEtU=; b=XaP+D7BlsZU/vHDML5JRrJ2KJywv2PJ+ZX4427ssCosIkHlqhj53C/3Z7NaEhAMsyK zIGTylXhJ0PqX/NKlpawz5DRJnTD8Hd7N95qM/JeMLxTdbafhE6vMHvssMFNSQr+YOr9 4ILwPTmkm6KfDmR4lxYBKXvbvzlDgSuDiWiJs=
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=YE2hvFZHTEqGe72p82TjLYYQ5tbUO5QstKJt4vLBGxKkaL+NWTu7qiYURz1iodxFWP uSwFfSwfBqtyUjN4qpiJRiYo4LTWmolnEhMNEJhvWoqwNbQQuE5ZrqaJdecKSQzvc66N sBcLhERCAhzQ48/5/5jM42vcxi4YpEjNk4bms=
MIME-Version: 1.0
Received: by 10.42.241.135 with SMTP id le7mr1173180icb.328.1292611112327; Fri, 17 Dec 2010 10:38:32 -0800 (PST)
Sender: [email-masked]
Received: by 10.42.218.131 with HTTP; Fri, 17 Dec 2010 10:38:32 -0800 (PST)
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost>
Date: Fri, 17 Dec 2010 13:38:32 -0500
X-Google-Sender-Auth: 60WETMZIF98sbgAJJnf8fgqBLwM
Message-ID:
From: Adam Langley
To: Paul Hoffman
Content-Type: text/plain; charset=UTF-8
Cc: [email-masked]
Subject: Re: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 17 Dec 2010 18:36:46 -0000

On Fri, Dec 17, 2010 at 1:27 PM, Paul Hoffman wrote:
> The attack you are concerned with is being dealt with in the WEBSEC WG (for the HTTP case)

Indeed. HSTS appears to be the emerging standard around this for
browsers: http://dev.chromium.org/sts

AGL

--
Adam Langley [email-masked] http://www.imperialviolet.org

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B8B33A6911 for ; Fri, 17 Dec 2010 10:26:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.565
X-Spam-Level:
X-Spam-Status: No, score=-101.565 tagged_above=-999 required=5 tests=[AWL=0.481, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 yVJzjSBtzHpu for ; Fri, 17 Dec 2010 10:25:58 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id EE9293A68EB for ; Fri, 17 Dec 2010 10:25:57 -0800 (PST)
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 oBHIRhFb005725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Dec 2010 11:27:44 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost>
Date: Fri, 17 Dec 2010 10:27:41 -0800
To: Paul Wouters
From: Paul Hoffman
Content-Type: text/plain; charset="us-ascii"
Cc: [email-masked]
Subject: [keyassure] HTTPS -> HTTP downgrade
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 17 Dec 2010 18:26:00 -0000

At 12:57 PM -0500 12/17/10, Paul Wouters wrote:
>On Tue, 14 Dec 2010, Paul Wouters wrote:
>
>>>Subject: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
>
>I actually had one more comment. I realised that the TLSA record can protect
>against Moxy's sslstrip (http://www.thoughtcrime.org/software/sslstrip/)
>
>Could we add something like:
>
> If a client detects a validated TLSA record, it MUST only use https (not http)
> to connect to the target site to prevent SSL stripping attacks.

Probably not. That is, if the user is not going to TLS (because the server doesn't do TLS or a MITM has done a downgrade to non-TLS), they should not be looking for TLSA records.

The attack you are concerned with is being dealt with in the WEBSEC WG (for the HTTP case) and hopefully by draft-hoffman-server-has-tls (depending on how the WEBSEC WG moves forwards).

--Paul Hoffman, Director
--VPN Consortium

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CBC43A6BB5 for ; Fri, 17 Dec 2010 10:11:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.431
X-Spam-Level:
X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[AWL=0.168, 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 EqznxpCLiATV for ; Fri, 17 Dec 2010 10:11:03 -0800 (PST)
Received: from homiemail-a2.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by core3.amsl.com (Postfix) with ESMTP id 2A8893A691F for ; Fri, 17 Dec 2010 10:10:56 -0800 (PST)
Received: from homiemail-a2.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a2.g.dreamhost.com (Postfix) with ESMTP id CA2D4280089; Fri, 17 Dec 2010 10:12:41 -0800 (PST)
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=NSXGk9TIz1M65xY0HcEFlg3+ooqrAG5uEOoR+XbGmaU RfwLY3NyAG0PO4Y2lkA8JKC5I+Cs6u43G4cQtzhnZqiV8zxq/ha9UCxqIJPAYtoX bUp21BA6y0P8KCc3K263ztwfqjcJhtwgZHNZE147+zRplD4OJjF8WzljhVb02Afs =
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=JPeBUMBckYD3nlAPv4nd/7DvFgc=; b=sy7adQT2E0 85NXekHUr5jwo1wiDkS27yqBExmKR7gJdR0Im7INyaoKydynGvQDNLPDgqAtFzep 70H5oLpf1tkeSWF+lJLwpalD++r4+vSi25X2uaiSXjWMG/DF9QTzdM/K7Xn5WIGD Y4W7Z0+JLS99Ck0FXq6qkA5Kz6Kcv2aJ4=
Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: [email-masked]) by homiemail-a2.g.dreamhost.com (Postfix) with ESMTPA id 7C0E728008C; Fri, 17 Dec 2010 10:12:41 -0800 (PST)
From: Matt McCutchen
To: Paul Wouters
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost>
Content-Type: text/plain; charset="UTF-8"
Date: Fri, 17 Dec 2010 13:12:39 -0500
Message-ID: <[email-masked]>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.1
Content-Transfer-Encoding: 7bit
Cc: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 17 Dec 2010 18:11:09 -0000

On Fri, 2010-12-17 at 12:57 -0500, Paul Wouters wrote:
> On Tue, 14 Dec 2010, Paul Wouters wrote:
>
> >> Subject: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
>
> I actually had one more comment. I realised that the TLSA record can protect
> against Moxy's sslstrip (http://www.thoughtcrime.org/software/sslstrip/)
>
> Could we add something like:
>
> If a client detects a validated TLSA record, it MUST only use https (not http)
> to connect to the target site to prevent SSL stripping attacks.

No. The sole purpose of TLSA is to determine which keys/certificates
are valid for a TLS connection. What you describe is Strict Transport
Security, which is being pursued separately. It will probably have its
own record in DNSSEC.

http://www.ietf.org/mail-archive/web/websec/current/msg00003.html

--
Matt

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 769263A6B91 for ; Fri, 17 Dec 2010 09:56:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.58
X-Spam-Level:
X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 MUNGZ5TIcj0h for ; Fri, 17 Dec 2010 09:56:10 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 4E39A3A6941 for ; Fri, 17 Dec 2010 09:56:09 -0800 (PST)
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 ACA4AC4BE; Fri, 17 Dec 2010 12:57:55 -0500 (EST)
Date: Fri, 17 Dec 2010 12:57:55 -0500 (EST)
From: Paul Wouters
To: Paul Hoffman
In-Reply-To:
Message-ID:
References: <20101213220001.24500.52050.idtracker@localhost>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 17 Dec 2010 17:56:11 -0000

On Tue, 14 Dec 2010, Paul Wouters wrote:

>> Subject: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt

I actually had one more comment. I realised that the TLSA record can protect
against Moxy's sslstrip (http://www.thoughtcrime.org/software/sslstrip/)

Could we add something like:

If a client detects a validated TLSA record, it MUST only use https (not http)
to connect to the target site to prevent SSL stripping attacks.

Paul

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C90623A6A2E for ; Thu, 16 Dec 2010 16:17:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.144
X-Spam-Level:
X-Spam-Status: No, score=-10.144 tagged_above=-999 required=5 tests=[AWL=0.105, 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 vznZrAwU9tta for ; Thu, 16 Dec 2010 16:17:08 -0800 (PST)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id BF8203A6A2A for ; Thu, 16 Dec 2010 16:17:07 -0800 (PST)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id oBH0IlS3013152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 Dec 2010 01:18:52 +0100 (MET)
From: Martin Rex
Message-Id: <[email-masked]>
To: [email-masked] (Mark Andrews)
Date: Fri, 17 Dec 2010 01:18:45 +0100 (MET)
In-Reply-To: <[email-masked]> from "Mark Andrews" at Dec 17, 10 10:58:11 am
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal04
X-SAP: out
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: [email-masked]
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 17 Dec 2010 00:17:08 -0000

Mark Andrews wrote:
>
> Martin Rex wrote:
> >
> > I am definitely _no_ DNSSEC expert, but
> > the way I interpret the architecture described here:
> >
> > http://tools.ietf.org/html/rfc4034#section-3.1
> > http://tools.ietf.org/html/rfc4035#section-5.3.2
> >
> > an attacker should be able to replay a DNSSEC response with an
> > attacker-chosen TTL (0 < TTL <= Orig-TTL) arbitrarily within the
> > RRSET lifetime specified through Signature Expiration and Inception Fields
>
> Correct. That doesn't however mean the TTL is not covered. It is.

Orig-TTL is covered by the RRSET signature, but Orig-TTL is
irrelevant to the caching. The TTL provided by nameservers
and relevant to the caching by other name server and clients
is _not_ protected at all. Therefore it is futile to think
of TTL as a security feature.

A sensibly bounded OrigTTL is security-relevant.
The enforcement of TTL < OrigTTL is security-relevant

The acutal value TTL or TTL=0 is _not_ security relevant
and is _not_ covered by the DNSSEC protection

-Martin

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC1133A6A28 for ; Thu, 16 Dec 2010 15:56:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.494
X-Spam-Level:
X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 dpYgWwI6wc7G for ; Thu, 16 Dec 2010 15:56:45 -0800 (PST)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id 172603A6A12 for ; Thu, 16 Dec 2010 15:56:45 -0800 (PST)
Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id D765C5F98A2; Thu, 16 Dec 2010 23:58:15 +0000 (UTC) (envelope-from [email-masked])
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by farside.isc.org (Postfix) with ESMTP id 0194AE60AB; Thu, 16 Dec 2010 23:58:14 +0000 (UTC) (envelope-from [email-masked])
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id B66607F623E; Fri, 17 Dec 2010 10:58:11 +1100 (EST)
To: [email-masked]
From: Mark Andrews
References: <[email-masked]>
In-reply-to: Your message of "Fri, 17 Dec 2010 00:33:40 BST." <[email-masked]>
Date: Fri, 17 Dec 2010 10:58:11 +1100
Message-Id: <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 23:56:46 -0000

In message <[email-masked]>, Martin Rex writes:
> Mark Andrews wrote:
> >
> >
> > In message <[email-masked]>, Martin Rex writ
> es:
> > > > I would say that TTL and RRSIG expiry time fall within what the DNSSEC
> > > > authority (signer) security stated about the TLSA record. A TLSA enabled
> > > > client MUST adhere to those obtained values.
> > >
> > > That is not how DNS works. The TTL relevant for caching is not
> > > even covered by the DNSSEC signature.
> >
> > Actually it is. The SIG record contains a upper bound and that value is
> > part of what is signed.
>
> I am definitely _no_ DNSSEC expert, but
> the way I interpret the architecture described here:
>
> http://tools.ietf.org/html/rfc4034#section-3.1
> http://tools.ietf.org/html/rfc4035#section-5.3.2
>
> an attacker should be able to replay a DNSSEC response with an
> attacker-chosen TTL (0 < TTL <= Orig-TTL) arbitrarily within the
> RRSET lifetime specified through Signature Expiration and Inception Fields

Correct. That doesn't however mean the TTL is not covered. It is.

Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [email-masked]

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EC053A6A12 for ; Thu, 16 Dec 2010 15:32:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.141
X-Spam-Level:
X-Spam-Status: No, score=-10.141 tagged_above=-999 required=5 tests=[AWL=0.108, 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 r70RndGvAFGD for ; Thu, 16 Dec 2010 15:32:00 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 910DF3A6979 for ; Thu, 16 Dec 2010 15:32:00 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id oBGNXhuF008810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 Dec 2010 00:33:43 +0100 (MET)
From: Martin Rex
Message-Id: <[email-masked]>
To: [email-masked] (Mark Andrews)
Date: Fri, 17 Dec 2010 00:33:40 +0100 (MET)
In-Reply-To: <[email-masked]> from "Mark Andrews" at Dec 17, 10 09:51:43 am
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal03
X-SAP: out
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: [email-masked]
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 23:32:01 -0000

Mark Andrews wrote:
>
>
> In message <[email-masked]>, Martin Rex writes:
> > > I would say that TTL and RRSIG expiry time fall within what the DNSSEC
> > > authority (signer) security stated about the TLSA record. A TLSA enabled
> > > client MUST adhere to those obtained values.
> >
> > That is not how DNS works. The TTL relevant for caching is not
> > even covered by the DNSSEC signature.
>
> Actually it is. The SIG record contains a upper bound and that value is
> part of what is signed.

I am definitely _no_ DNSSEC expert, but
the way I interpret the architecture described here:

http://tools.ietf.org/html/rfc4034#section-3.1
http://tools.ietf.org/html/rfc4035#section-5.3.2

an attacker should be able to replay a DNSSEC response with an
attacker-chosen TTL (0 < TTL <= Orig-TTL) arbitrarily within the
RRSET lifetime specified through Signature Expiration and Inception Fields

-Martin

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D24753A6A2B for ; Thu, 16 Dec 2010 15:28:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.488
X-Spam-Level:
X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=0.111, 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 svW76TmiG+Xe for ; Thu, 16 Dec 2010 15:28:57 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id A66F53A6A2A for ; Thu, 16 Dec 2010 15:28:56 -0800 (PST)
Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 00C4EC941A; Thu, 16 Dec 2010 23:30:32 +0000 (UTC) (envelope-from [email-masked])
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by farside.isc.org (Postfix) with ESMTP id 48647E6030; Thu, 16 Dec 2010 23:30:31 +0000 (UTC) (envelope-from [email-masked])
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 097147F5E9A; Fri, 17 Dec 2010 10:30:29 +1100 (EST)
To: "Jeffrey A. Williams"
From: Mark Andrews
References: <[email-masked]>
In-reply-to: Your message of "Thu, 16 Dec 2010 17:00:08 MDT." <[email-masked]>
Date: Fri, 17 Dec 2010 10:30:28 +1100
Message-Id: <[email-masked]>
Cc: "[email-masked]"
Subject: Re: [keyassure] "Trusted third parties"
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 23:28:57 -0000

In message <[email-masked]
.net>, "Jeffrey A. Williams" writes:
> Mark and all,
>
>
> -----Original Message-----
> >From: Mark Andrews
> >Sent: Dec 16, 2010 4:19 PM
> >To: Matt McCutchen
> >Cc: [email-masked]
> >Subject: Re: [keyassure] "Trusted third parties"
> >
> >
> >In message <[email-masked]>, Matt McCutchen writes
> :
> >> On Thu, 2010-12-16 at 14:23 -0500, Paul Wouters wrote:
> >> > On Thu, 16 Dec 2010, Matt McCutchen wrote:
> >> >
> >> > > Let no one miss that DANE as it is to be commonly practiced still
> >> > > depends on third parties: ICANN/Verisign and whoever else is on the path
> >> > > to one's zone. Hopefully they will be less unruly than the public CAs,
> >> > > but people who are serious about not trusting third parties will still
> >> > > need something else.
> >> >
> >> > The big difference is that if you are mobile, attackers will have to falsi
> fy
> >> > the public's view of DNS(SEC), so this becomes very obvious.
> >>
> >> Really? I remember someone describing how a rogue registrar could
> >> target a false answer to one user, but I haven't been able to find the
> >> message now.
> >
> >A rogue registry that controls all of the DNS servers for the zone
> >could do this. A registrar could not as they just add data to the
> >zone without control of to whom it is being sent.
>
> This is essentially correct, but a hosting company that is
> closely associated with a registrar that controls all of the
> above mentione DNS servers for the zone could also do the
> same at the insistance of the parent/owning registrar and likely
> would in some instances without know for certain that they should
> or for other rogue/nafarious purposes.

The zone maintainer should be generating the DNSKEY records and
pushing DS records into the parent zone. It should NEVER be accepting
DNSKEYs from the parent. It should also not be accepting changes
from the parent either and this applies to plain DNS as well so it
is nothing new.

There really isn't a way for this to be done without active collusion
when more than one party is involved.

Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [email-masked]

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 373E63A6919 for ; Thu, 16 Dec 2010 14:58:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.247
X-Spam-Level:
X-Spam-Status: No, score=-2.247 tagged_above=-999 required=5 tests=[AWL=0.352, 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 7SGZQFlWJIV3 for ; Thu, 16 Dec 2010 14:58:23 -0800 (PST)
Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id 068653A6915 for ; Thu, 16 Dec 2010 14:58:23 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=TKHqvIUi6aTJi/mFFquRII2gurt8W5IzkMK5C7BYnJPZg/S2l/KemKOQaSOqsAFa; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.42] (helo=elwamui-muscovy.atl.sa.earthlink.net) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1PTMnw-00079X-Kq for [email-masked]; Thu, 16 Dec 2010 18:00:08 -0500
Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Thu, 16 Dec 2010 18:00:08 -0500
Message-ID: <[email-masked]>
Date: Thu, 16 Dec 2010 17:00:08 -0600 (GMT-06:00)
From: "Jeffrey A. Williams"
To: "[email-masked]"
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e5196068890bba10de7a824890cbb1300d6319d9b350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.42
Subject: Re: [keyassure] "Trusted third parties"
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: "Jeffrey A. Williams"
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 22:58:24 -0000

Mark and all,

-----Original Message-----
>From: Mark Andrews
>Sent: Dec 16, 2010 4:19 PM
>To: Matt McCutchen
>Cc: [email-masked]
>Subject: Re: [keyassure] "Trusted third parties"
>
>
>In message <[email-masked]>, Matt McCutchen writes:
>> On Thu, 2010-12-16 at 14:23 -0500, Paul Wouters wrote:
>> > On Thu, 16 Dec 2010, Matt McCutchen wrote:
>> >
>> > > Let no one miss that DANE as it is to be commonly practiced still
>> > > depends on third parties: ICANN/Verisign and whoever else is on the path
>> > > to one's zone. Hopefully they will be less unruly than the public CAs,
>> > > but people who are serious about not trusting third parties will still
>> > > need something else.
>> >
>> > The big difference is that if you are mobile, attackers will have to falsify
>> > the public's view of DNS(SEC), so this becomes very obvious.
>>
>> Really? I remember someone describing how a rogue registrar could
>> target a false answer to one user, but I haven't been able to find the
>> message now.
>
>A rogue registry that controls all of the DNS servers for the zone
>could do this. A registrar could not as they just add data to the
>zone without control of to whom it is being sent.

This is essentially correct, but a hosting company that is
closely associated with a registrar that controls all of the
above mentione DNS servers for the zone could also do the
same at the insistance of the parent/owning registrar and likely
would in some instances without know for certain that they should
or for other rogue/nafarious purposes.
>
>Mark
>--
>Mark Andrews, ISC
>1 Seymour St., Dundas Valley, NSW 2117, Australia
>PHONE: +61 2 9871 4742 INTERNET: [email-masked]
>_______________________________________________
>keyassure mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/keyassure

Regards,
Jeffrey A. Williams
"Obedience of the law is the greatest freedom" -
Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
Network Eng. SR. Eng. Network data security
ABA member in good standing member ID 01257402
E-Mail [email-masked]
Phone: 214-244-4827

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53E083A6979 for ; Thu, 16 Dec 2010 14:50:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.482
X-Spam-Level:
X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 eeeDy2jnVeNT for ; Thu, 16 Dec 2010 14:50:09 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id C1DC13A6A0B for ; Thu, 16 Dec 2010 14:50:08 -0800 (PST)
Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 2D5F5C941A; Thu, 16 Dec 2010 22:51:46 +0000 (UTC) (envelope-from [email-masked])
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by farside.isc.org (Postfix) with ESMTP id D638BE6030; Thu, 16 Dec 2010 22:51:45 +0000 (UTC) (envelope-from [email-masked])
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 995007F5777; Fri, 17 Dec 2010 09:51:43 +1100 (EST)
To: [email-masked]
From: Mark Andrews
References: <[email-masked]>
In-reply-to: Your message of "Thu, 16 Dec 2010 22:17:32 BST." <[email-masked]>
Date: Fri, 17 Dec 2010 09:51:43 +1100
Message-Id: <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 22:50:10 -0000

In message <[email-masked]>, Martin Rex writes:
> > I would say that TTL and RRSIG expiry time fall within what the DNSSEC
> > authority (signer) security stated about the TLSA record. A TLSA enabled
> > client MUST adhere to those obtained values.
>
> That is not how DNS works. The TTL relevant for caching is not
> even covered by the DNSSEC signature.

Actually it is. The SIG record contains a upper bound and that value is
part of what is signed.

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [email-masked]

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 107CA3A69E2 for ; Thu, 16 Dec 2010 14:46:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.475
X-Spam-Level:
X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 YVUaXEFPUh-I for ; Thu, 16 Dec 2010 14:46:06 -0800 (PST)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id 1C4383A6919 for ; Thu, 16 Dec 2010 14:46:06 -0800 (PST)
Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 54A465F9861; Thu, 16 Dec 2010 22:47:36 +0000 (UTC) (envelope-from [email-masked])
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by farside.isc.org (Postfix) with ESMTP id 310D8E6030; Thu, 16 Dec 2010 22:47:34 +0000 (UTC) (envelope-from [email-masked])
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 49A707F56E5; Fri, 17 Dec 2010 09:47:31 +1100 (EST)
To: "W.C.A. Wijngaards"
From: Mark Andrews
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
In-reply-to: Your message of "Thu, 16 Dec 2010 22:16:17 BST." <[email-masked]>
Date: Fri, 17 Dec 2010 09:47:31 +1100
Message-Id: <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 22:46:07 -0000

In message <[email-masked]>, "W.C.A. Wijngaards" writes:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Stephen,
>
> On 12/16/2010 07:12 PM, Stephen Schultze wrote:
> >>> But what if the MITM overrides the genuine DNSSEC-signed record with a
> >>> record that is not signed with DNSSEC? Is there some reason why this
> >>> is not possible?
>
> You can detect this, the result is DNSSEC bogus: access denied.
>
> > Yes, but evidently we didn't come to a conclusion. Wouter's proposal
> > (which I take to be "MUST process TLS in the normal fashion") creates
> > the sort of downgrade attack I was describing here and in that thread.
> > The current draft likewise does so:
>
> No, I mean something different, see below.
>
> > "If the application receives zero usable certificate associations, it
> > processes TLS in the normal fashion."
> >
> > Or am I missing something?
>
> Distinguish zero TLSA objects (DNSSEC signed): no TLSA configured, so do
> the 'usual' (no TLS or normal TLS).
>
> And some TLSA objects. Malformed ones are not usable, mismatches are
> not usable. If none are usable, since TLSA is configured, no downgrade
> with TLS processing: access denied.
>
> If usable TLSA objects: you have a match, yay. Do what the draft says.
>
> If domain not DNSSEC signed (insecure): normal TLS (or no TLS).
>
> If TLSA query fails (no reply from network, all traffic disappears):
> access denied. (This is the part where I think your trap still applies,
> but it is much smaller than before: not many DNSSEC-signed domains will
> fail to resolve a TLSA query; they usually upgrade software and thus
> also support the unknown-RR-types RFC).
>
> Would that come out of the trap?

Additionally the validators also usually support unknown types.

Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [email-masked]

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FD5A3A6919 for ; Thu, 16 Dec 2010 14:22:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.423
X-Spam-Level:
X-Spam-Status: No, score=-2.423 tagged_above=-999 required=5 tests=[AWL=0.176, 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 8mTLWrC97KLQ for ; Thu, 16 Dec 2010 14:22:10 -0800 (PST)
Received: from homiemail-a7.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by core3.amsl.com (Postfix) with ESMTP id 488123A6915 for ; Thu, 16 Dec 2010 14:22:10 -0800 (PST)
Received: from homiemail-a7.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a7.g.dreamhost.com (Postfix) with ESMTP id BA77B25C06A; Thu, 16 Dec 2010 14:23:55 -0800 (PST)
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=I935yKS0amnGLiFEQc8c/9lZ7mMD34wcS6rm+r08uDP WRc5CtAEDuIngZpyVu8deat0pPOInR2NKgHg8BgqbzEiiq8q7gOSLbTIqTyBsVMF QzztquMrLnxq8jV00QbRBolywMqEJKFtSNe7YZpG1E6upqI+XdzmTxDk7ld307ks =
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=9SWMTNn10pHzZEC5FumecOLNPbA=; b=qnAlAharbw TVCEt8ecbM/1cCBJK+Ssi3AQHfhHfOHTf1kymqrY7zSgMAt77n/nPrZf1KO3cOQD mMilBR4hgMBEdLrhRVrukZKZoFF12DO5sEbxOihjoKbeSBpF1fFtDyYgJoJ/0xXL iIGOXZBSEMCfkqjoj+NEc3lFKfFXcH4ZA=
Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: [email-masked]) by homiemail-a7.g.dreamhost.com (Postfix) with ESMTPA id 735BC25C063; Thu, 16 Dec 2010 14:23:55 -0800 (PST)
From: Matt McCutchen
To: Mark Andrews
In-Reply-To: <[email-masked]>
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 16 Dec 2010 17:23:54 -0500
Message-ID: <[email-masked]>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.1
Content-Transfer-Encoding: 7bit
Cc: [email-masked]
Subject: Re: [keyassure] "Trusted third parties"
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 22:22:11 -0000

On Fri, 2010-12-17 at 09:19 +1100, Mark Andrews wrote:
> In message <[email-masked]>, Matt McCutchen writes:
> > On Thu, 2010-12-16 at 14:23 -0500, Paul Wouters wrote:
> > > On Thu, 16 Dec 2010, Matt McCutchen wrote:
> > >
> > > > Let no one miss that DANE as it is to be commonly practiced still
> > > > depends on third parties: ICANN/Verisign and whoever else is on the path
> > > > to one's zone. Hopefully they will be less unruly than the public CAs,
> > > > but people who are serious about not trusting third parties will still
> > > > need something else.
> > >
> > > The big difference is that if you are mobile, attackers will have to falsify
> > > the public's view of DNS(SEC), so this becomes very obvious.
> >
> > Really? I remember someone describing how a rogue registrar could
> > target a false answer to one user, but I haven't been able to find the
> > message now.
>
> A rogue registry that controls all of the DNS servers for the zone
> could do this. A registrar could not as they just add data to the
> zone without control of to whom it is being sent.

I guess I meant the registry. Pardon my sloppy terminology. The
registrar is on the path and could substitute a false DS but has no way
to target individual clients.

--
Matt

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DD413A69D5 for ; Thu, 16 Dec 2010 14:17:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.468
X-Spam-Level:
X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.131, 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 VjU1MN5djt4c for ; Thu, 16 Dec 2010 14:17:34 -0800 (PST)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id 1A3163A6953 for ; Thu, 16 Dec 2010 14:17:34 -0800 (PST)
Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id E1FB45F98EA; Thu, 16 Dec 2010 22:19:04 +0000 (UTC) (envelope-from [email-masked])
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by farside.isc.org (Postfix) with ESMTP id DF3A4E60B3; Thu, 16 Dec 2010 22:19:02 +0000 (UTC) (envelope-from [email-masked])
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 9ABE27F50A2; Fri, 17 Dec 2010 09:19:00 +1100 (EST)
To: Matt McCutchen
From: Mark Andrews
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
In-reply-to: Your message of "Thu, 16 Dec 2010 14:45:02 CDT." <[email-masked]>
Date: Fri, 17 Dec 2010 09:19:00 +1100
Message-Id: <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] "Trusted third parties"
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 22:17:35 -0000

In message <[email-masked]>, Matt McCutchen writes:
> On Thu, 2010-12-16 at 14:23 -0500, Paul Wouters wrote:
> > On Thu, 16 Dec 2010, Matt McCutchen wrote:
> >
> > > Let no one miss that DANE as it is to be commonly practiced still
> > > depends on third parties: ICANN/Verisign and whoever else is on the path
> > > to one's zone. Hopefully they will be less unruly than the public CAs,
> > > but people who are serious about not trusting third parties will still
> > > need something else.
> >
> > The big difference is that if you are mobile, attackers will have to falsify
> > the public's view of DNS(SEC), so this becomes very obvious.
>
> Really? I remember someone describing how a rogue registrar could
> target a false answer to one user, but I haven't been able to find the
> message now.

A rogue registry that controls all of the DNS servers for the zone
could do this. A registrar could not as they just add data to the
zone without control of to whom it is being sent.

Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [email-masked]

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60EB83A695B for ; Thu, 16 Dec 2010 13:52:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 UBiOh2CGTrxH for ; Thu, 16 Dec 2010 13:52:35 -0800 (PST)
Received: from ppa03.princeton.edu (ppa03.Princeton.EDU [128.112.128.214]) by core3.amsl.com (Postfix) with ESMTP id 93AFF3A6A03 for ; Thu, 16 Dec 2010 13:52:34 -0800 (PST)
Received: from csgsmtp200l.Princeton.EDU (csgsmtp200l.Princeton.EDU [128.112.130.131]) by ppa03.princeton.edu (8.14.3/8.14.3) with ESMTP id oBGLsJBX001007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 16 Dec 2010 16:54:19 -0500
Received: from mayflower-ad.Princeton.EDU (mayflower-ad.Princeton.EDU [128.112.224.246]) (authenticated bits=0) by csgsmtp200l.Princeton.EDU (8.13.8/8.12.9) with ESMTP id oBGLsEwc011006 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 16 Dec 2010 16:54:15 -0500
Message-Id: <[email-masked]>
From: Stephen Schultze
To: [email-masked]
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Thu, 16 Dec 2010 16:54:14 -0500
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
X-Mailer: Apple Mail (2.936)
X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6199 signatures=655053
X-Proofpoint-Spam-Details: rule=quarantine_notspam policy=quarantine score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1010190000 definitions=main-1012160162
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 21:52:37 -0000

On Dec 16, 2010, at 4:46 PM, Matt McCutchen wrote:
> On Thu, 2010-12-16 at 16:43 -0500, Stephen Schultze wrote:
>> On Dec 16, 2010, at 4:16 PM, W.C.A. Wijngaards wrote:
>>> On 12/16/2010 07:12 PM, Stephen Schultze wrote:
>>>>>> But what if the MITM overrides the genuine DNSSEC-signed record
>>>>>> with a
>>>>>> record that is not signed with DNSSEC? Is there some reason why
>>>>>> this
>>>>>> is not possible?
>>>
>>> You can detect this, the result is DNSSEC bogus: access denied.
>>
>> Upon re-reading RFC 4033, you seem to be correct. Am I correct in
>> understanding that once you put a DS record in your parent zone, any
>> non-signed response from your own zone gives a DNSSEC bogus status?
>
> Yep. Isn't it great?

It is, and I now understand and wholeheartedly support the entirety of
your suggested text as a complete solution to my concerns.

http://www.ietf.org/mail-archive/web/keyassure/current/msg00923.html

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD37E3A69EB for ; Thu, 16 Dec 2010 13:44:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.413
X-Spam-Level:
X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLiskIxbqF3A for ; Thu, 16 Dec 2010 13:44:22 -0800 (PST)
Received: from homiemail-a37.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by core3.amsl.com (Postfix) with ESMTP id 366003A69E5 for ; Thu, 16 Dec 2010 13:44:22 -0800 (PST)
Received: from homiemail-a37.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTP id CCF4D1D006E; Thu, 16 Dec 2010 13:46:07 -0800 (PST)
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=CMS+5QImypJnjfVR76aMXRj20Z+SkjGPrjZh9ZC2WvM oZaqhfDZb5uik+eVtb5IaM46KYF2tc4dWhBZcS1MhUP3OT2Kln0PxaKFR68wHvk5 3KNjXdhHI2I9bR7ssyQ+RqUVwlZ/Uu2eA9Qr6j7CqkY/9fzl20uJOxjS3goeigRg =
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=zJT930aB/fiBUDcNdr+p59xH8yo=; b=JjdcFxKfly Mvr2lIUbomkpdj7BjTubfwWoXMXb5hUb6bHKS/h8ww1dDwo7aKEs8Q2btphdP9FB j5WyiVLPfdHCCwyhsgeqhY64nQ3c3SxebscgKHO1ZU2P8/g7mwgDd5cfTIdwgYwT DfVy+/eoBiK1OJwUeUaqw9M6Hq+8JJoh4=
Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: [email-masked]) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTPA id 6245E1D006C; Thu, 16 Dec 2010 13:46:07 -0800 (PST)
From: Matt McCutchen
To: Stephen Schultze
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 16 Dec 2010 16:46:06 -0500
Message-ID: <[email-masked]>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.1
Content-Transfer-Encoding: 7bit
Cc: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 21:44:23 -0000

On Thu, 2010-12-16 at 16:43 -0500, Stephen Schultze wrote:
> On Dec 16, 2010, at 4:16 PM, W.C.A. Wijngaards wrote:
> > On 12/16/2010 07:12 PM, Stephen Schultze wrote:
> >>>> But what if the MITM overrides the genuine DNSSEC-signed record
> >>>> with a
> >>>> record that is not signed with DNSSEC? Is there some reason why
> >>>> this
> >>>> is not possible?
> >
> > You can detect this, the result is DNSSEC bogus: access denied.
>
> Upon re-reading RFC 4033, you seem to be correct. Am I correct in
> understanding that once you put a DS record in your parent zone, any
> non-signed response from your own zone gives a DNSSEC bogus status?

Yep. Isn't it great?

--
Matt

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 261AA3A69F8 for ; Thu, 16 Dec 2010 13:41:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdXEQLqVzXOu for ; Thu, 16 Dec 2010 13:41:37 -0800 (PST)
Received: from ppa02.Princeton.EDU (ppa02.Princeton.EDU [128.112.128.216]) by core3.amsl.com (Postfix) with ESMTP id 399A63A69F3 for ; Thu, 16 Dec 2010 13:41:37 -0800 (PST)
Received: from csgsmtp200l.Princeton.EDU (csgsmtp200l.Princeton.EDU [128.112.130.131]) by ppa02.Princeton.EDU (8.14.3/8.14.3) with ESMTP id oBGLhM0S030204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 16 Dec 2010 16:43:22 -0500
Received: from mayflower-ad.Princeton.EDU (mayflower-ad.Princeton.EDU [128.112.224.246]) (authenticated bits=0) by csgsmtp200l.Princeton.EDU (8.13.8/8.12.9) with ESMTP id oBGLhLvg006012 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 16 Dec 2010 16:43:22 -0500
Message-Id:
From: Stephen Schultze
To: [email-masked]
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Thu, 16 Dec 2010 16:43:21 -0500
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
X-Mailer: Apple Mail (2.936)
X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6199 signatures=655053
X-Proofpoint-Spam-Details: rule=quarantine_notspam policy=quarantine score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1010190000 definitions=main-1012160160
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 21:41:38 -0000

On Dec 16, 2010, at 4:16 PM, W.C.A. Wijngaards wrote:
> On 12/16/2010 07:12 PM, Stephen Schultze wrote:
>>>> But what if the MITM overrides the genuine DNSSEC-signed record
>>>> with a
>>>> record that is not signed with DNSSEC? Is there some reason why
>>>> this
>>>> is not possible?
>
> You can detect this, the result is DNSSEC bogus: access denied.

Upon re-reading RFC 4033, you seem to be correct. Am I correct in
understanding that once you put a DS record in your parent zone, any
non-signed response from your own zone gives a DNSSEC bogus status?

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 521AB3A69F0 for ; Thu, 16 Dec 2010 13:30:24 -0800 (PST)
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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id acKYhSKCZzyF for ; Thu, 16 Dec 2010 13:30:23 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 6D8903A69EF for ; Thu, 16 Dec 2010 13:30:23 -0800 (PST)
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 6D0B0C4BE; Thu, 16 Dec 2010 16:32:08 -0500 (EST)
Date: Thu, 16 Dec 2010 16:32:05 -0500 (EST)
From: Paul Wouters
To: Martin Rex
In-Reply-To: <[email-masked]>
Message-ID:
References: <[email-masked]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 21:30:24 -0000

On Thu, 16 Dec 2010, Martin Rex wrote:

> That is not how DNS works. The TTL relevant for caching is not
> even covered by the DNSSEC signature.

I was wrong. Thanks for pointing it out....

>> The "leap of faith" with ssh was based on doing this because there was no
>> concept of expiry. But if you now set "VerifyHostKeyDNS yes" for ssh, then
>> if the SSHFP record is not a match, and you have the old key in your
>> knwon hosts file, it WILL warn you before using that key - as it should!
>
> That "VerifyHostKeyDNS" looks like a security vulnerability to me.

It adds information to your prompt. I'm not sure how that could be a
security vulnerability. Instead of "yes" you can also configure "ask".

Paul

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47FC33A69EC for ; Thu, 16 Dec 2010 13:29:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.403
X-Spam-Level:
X-Spam-Status: No, score=-2.403 tagged_above=-999 required=5 tests=[AWL=0.196, 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 al9lBqaaBNsz for ; Thu, 16 Dec 2010 13:29:35 -0800 (PST)
Received: from homiemail-a2.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by core3.amsl.com (Postfix) with ESMTP id 4C3CE3A69E5 for ; Thu, 16 Dec 2010 13:29:35 -0800 (PST)
Received: from homiemail-a2.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a2.g.dreamhost.com (Postfix) with ESMTP id BD3EA280072; Thu, 16 Dec 2010 13:31:20 -0800 (PST)
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=qQvGRSQAlrhQFIeK+mqQt0wc7rF/abTk5lN9RnU+rFY +/i6FUDD9Wdm27B6G6vl/UmLdyYPXCNh2h/MoY/4Ad1v8TabTcadJcL6cYsJ/KS0 J7x8FDByrTnpVC9MvaSNH2MgXrll7/dUYRP8o8qsCm+mmf4uCGWorSvn8HTz3VRE =
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=TfEIvDR6L8WyrBDJ3cv6V1BsDkk=; b=rOlllht4B3 IBmg4rEW8ojAXxO5b46vw1jvpuzQ0Mn7R4xAlgcdRJw22ppUmkmDHemMpEVNVUPQ k6WwHwQ2SpYCrMJiRVIuFVvJj25XU3/YQVMgCJRjngBaqd+eP/g1kl1QaJ3BY/ZN UmYMPgnVOBfLolfzc6rbJlpg6dzWS3zfw=
Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: [email-masked]) by homiemail-a2.g.dreamhost.com (Postfix) with ESMTPA id 6BEDE280071; Thu, 16 Dec 2010 13:31:20 -0800 (PST)
From: Matt McCutchen
To: James Cloos
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 16 Dec 2010 16:31:19 -0500
Message-ID: <[email-masked]>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.1
Content-Transfer-Encoding: 7bit
Cc: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 21:29:36 -0000

On Thu, 2010-12-16 at 16:16 -0500, James Cloos wrote:
> >>>>> "SS" == Steve Schultze writes:
>
> >> If there are no TLSA records (this is DNSSEC validated by the lookup)
> >> or the domain is not signed with DNSSEC (this is signed by the parent
> >> domain): process normally (i.e. PKIX). This provides backwards
> >> compatibility.
>
> SS> But what if the MITM overrides the genuine DNSSEC-signed record with
> SS> a record that is not signed with DNSSEC? Is there some reason why
> SS> this is not possible?
>
> The bottom line is that the policy in that case needs to be user-specific.
>
> A flag day between the current regime and the use of the dns root key as
> the universal trust anchor will never fly. The only thing which will is
> to allow some users to upgrade to the new mechanism while the rest stick
> for a while with the current.
>
> For that to work, a lack of dns trust has to fall back to the collection
> of root CAs model.

And that works fine when the client gets a "secure" DNSSEC result with
zero TLSA records or an "insecure" result. On the other hand, a "bogus"
result means the system is misconfigured or under attack. I don't see
why there is a demand that the system continue to function in such an
event.

--
Matt

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55D973A6953 for ; Thu, 16 Dec 2010 13:23:53 -0800 (PST)
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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81l9zFhSLNJu for ; Thu, 16 Dec 2010 13:23:52 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 7E49E3A68E1 for ; Thu, 16 Dec 2010 13:23:51 -0800 (PST)
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 7406FC4BE; Thu, 16 Dec 2010 16:25:36 -0500 (EST)
Date: Thu, 16 Dec 2010 16:25:36 -0500 (EST)
From: Paul Wouters
To: "W.C.A. Wijngaards"
In-Reply-To: <[email-masked]>
Message-ID:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 21:23:53 -0000

On Thu, 16 Dec 2010, W.C.A. Wijngaards wrote:

> If TLSA query fails (no reply from network, all traffic disappears):
> access denied. (This is the part where I think your trap still applies,
> but it is much smaller than before: not many DNSSEC-signed domains will
> fail to resolve a TLSA query;

In fact, either the entire zone broke, in which case you couldn't resolve
the website there to begin with, and are not attempting a TLSA record, or
the TLSA record is specifically filtered/modified, in which case it is an
active attack you want to protect against.

Paul

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC5FC3A691D for ; Thu, 16 Dec 2010 13:21:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.842
X-Spam-Level:
X-Spam-Status: No, score=-1.842 tagged_above=-999 required=5 tests=[AWL=0.757, 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 RG0XuPLJfmwk for ; Thu, 16 Dec 2010 13:20:58 -0800 (PST)
Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by core3.amsl.com (Postfix) with ESMTP id 146DC3A68E1 for ; Thu, 16 Dec 2010 13:20:58 -0800 (PST)
Received: by eagle.jhcloos.com (Postfix, from userid 10) id B0654400C0; Thu, 16 Dec 2010 21:22:18 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1292534562; bh=BAQo+zhwPwQ6s148AJ1B6NqMCkKdwe2ZglPL7mz4NAc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=KBwnnec/EG2uwJAFOWjW2N/th68Hq7XmQNDIkWgch/rffClD96KuEJKnh2N2Qt6xd hkTf2E0zA2AY1BCq9C7PIagBkcrvN8Bm6akMOc/moSjDG7GCPlDqsbVKkS59PIFc7h mlNvGfUNKgK2QCinwonnWOYU1yF9vQpaExwVlWKY=
Received: from carbon (localhost [127.0.0.1]) by carbon.jhcloos.org (Postfix) with ESMTP id 2C50030002A; Thu, 16 Dec 2010 21:16:41 +0000 (UTC)
From: James Cloos
To: [email-masked]
In-Reply-To: <[email-masked]> (Steve Schultze's message of "Thu, 16 Dec 2010 10:34:40 -0500")
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux)
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABHNCSVQICAgIfAhkiAAAAI1J REFUOE+lU9ESgCAIg64P1y+ngUdxhl5H8wFbbM0OmUiEhKkCYaZThXCo6KE5sCbA1DDX3genvO4d eBQgEMaM5qy6uWk4SfBYfdu9jvBN9nSVDOKRtwb+I3epboOsOX5pZbJNsBJFvmQQ05YMfieIBnYX FK2N6dOawd97r/e8RjkTLzmMsiVgrAoEugtviCM3v2WzjgAAAABJRU5ErkJggg==
Copyright: Copyright 2009 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, 16 Dec 2010 16:16:41 -0500
Message-ID:
Lines: 42
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Hashcash: 1:30:101216:[email-masked]::LYAmCN6hvLoD+ngC:0000000000000000000000000000000000000000004viAm
X-Hashcash: 1:30:101216:[email-masked]::YmbFvBogBjBz5Ien:0000000000000000000000000000000000000000000WoT3p
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 21:21:00 -0000

>>>>> "SS" == Steve Schultze writes:

>> If there are no TLSA records (this is DNSSEC validated by the lookup)
>> or the domain is not signed with DNSSEC (this is signed by the parent
>> domain): process normally (i.e. PKIX). This provides backwards
>> compatibility.

SS> But what if the MITM overrides the genuine DNSSEC-signed record with
SS> a record that is not signed with DNSSEC? Is there some reason why
SS> this is not possible?

The bottom line is that the policy in that case needs to be user-specific.

A flag day between the current regime and the use of the dns root key as
the universal trust anchor will never fly. The only thing which will is
to allow some users to upgrade to the new mechanism while the rest stick
for a while with the current.

For that to work, a lack of dns trust has to fall back to the collection
of root CAs model.

DAME does need to document the risk that a MITM can degrade the dns to
unsecured and trick a user into using the old model.

In theory, it would help were apps to keep track of secure remotes which
were trusted because of the root dns key, and complain whenever that trust
path disappears. Or, when it comes to that, when it changes in any way.

But experience shows that most people tend to ignore that kind of warning.

There is little DANE can do beyond documenting the risks.

Personally, I'd prefer that UIs always let me know why something which
appears to be secure is trusted. And I'd like to track any transition
from one global trust policy to another. In the case of a GUI browser,
a different background colour for the URL bar and a slightly different
padlock appearance would be ideal. (At least when the trust path is
homogeneous. ☺)

-JimC
--
James Cloos OpenPGP: 1024D/ED7DAEA6

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 518B63A69D1 for ; Thu, 16 Dec 2010 13:15:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.137
X-Spam-Level:
X-Spam-Status: No, score=-10.137 tagged_above=-999 required=5 tests=[AWL=0.112, 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 4OxikvRvLhZm for ; Thu, 16 Dec 2010 13:15:49 -0800 (PST)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 3F29F3A6934 for ; Thu, 16 Dec 2010 13:15:49 -0800 (PST)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id oBGLHX1v029950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 Dec 2010 22:17:33 +0100 (MET)
From: Martin Rex
Message-Id: <[email-masked]>
To: [email-masked] (Paul Wouters)
Date: Thu, 16 Dec 2010 22:17:32 +0100 (MET)
In-Reply-To: from "Paul Wouters" at Dec 16, 10 02:28:41 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal07
X-SAP: out
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: [email-masked]
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 21:15:50 -0000

Paul Wouters wrote:
>
> On Thu, 16 Dec 2010, Martin Rex wrote:
>
> > You may want to distinguish two types of "old values":
> >
> > - Caching RRs beyond TTL expiration should not be a problem and is IMHO
> > permitted by the spec as a fallback.
>
> That would be dangerous - you might miss the purposeful removal of some
> TLSA (eg after the private key of the webserver got compromised)

No, that would not be dangerous at all.
TTL is a suggested, soft expiration for the purpose of cache management.

There is no revocation mechanism in DNS, and the time of expiration
for a signed record is explicitly given in the Signature expiration.

But even when the time advances beyond signature expiration,
that doesn't mean that a cached record, obtained and added to the
cache while it was still valid (both signature and TTL) will
automatically become malicious.

>
> I would say that TTL and RRSIG expiry time fall within what the DNSSEC
> authority (signer) security stated about the TLSA record. A TLSA enabled
> client MUST adhere to those obtained values.

That is not how DNS works. The TTL relevant for caching is not
even covered by the DNSSEC signature.

>
> The "leap of faith" with ssh was based on doing this because there was no
> concept of expiry. But if you now set "VerifyHostKeyDNS yes" for ssh, then
> if the SSHFP record is not a match, and you have the old key in your
> knwon hosts file, it WILL warn you before using that key - as it should!

That "VerifyHostKeyDNS" looks like a security vulnerability to me.

Keys do not expire. If anything, they get compromised (or if they're
extremely weak, they might get brute-forced).

-Martin

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 591013A6934 for ; Thu, 16 Dec 2010 13:14:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.491
X-Spam-Level:
X-Spam-Status: No, score=-1.491 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, 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 L5z5-r6MkbUa for ; Thu, 16 Dec 2010 13:14:45 -0800 (PST)
Received: from rotring.dds.nl (rotring.dds.nl [85.17.178.138]) by core3.amsl.com (Postfix) with ESMTP id 0FD243A697D for ; Thu, 16 Dec 2010 13:14:45 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by rotring.dds.nl (Postfix) with ESMTP id 893AB58653 for ; Thu, 16 Dec 2010 22:16:29 +0100 (CET)
Received: from vylkir.localdomain (195-241-9-117.adsl.dds.nl [195.241.9.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rotring.dds.nl (Postfix) with ESMTPSA id AA999585F8 for ; Thu, 16 Dec 2010 22:16:17 +0100 (CET)
Message-ID: <[email-masked]>
Date: Thu, 16 Dec 2010 22:16:17 +0100
From: "W.C.A. Wijngaards"
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc13 Thunderbird/3.1.7
MIME-Version: 1.0
To: [email-masked]
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To:
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.96.4 at rotring
X-Virus-Status: Clean
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 21:14:46 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Stephen,

On 12/16/2010 07:12 PM, Stephen Schultze wrote:
>>> But what if the MITM overrides the genuine DNSSEC-signed record with a
>>> record that is not signed with DNSSEC? Is there some reason why this
>>> is not possible?

You can detect this, the result is DNSSEC bogus: access denied.

> Yes, but evidently we didn't come to a conclusion. Wouter's proposal
> (which I take to be "MUST process TLS in the normal fashion") creates
> the sort of downgrade attack I was describing here and in that thread.
> The current draft likewise does so:

No, I mean something different, see below.

> "If the application receives zero usable certificate associations, it
> processes TLS in the normal fashion."
>
> Or am I missing something?

Distinguish zero TLSA objects (DNSSEC signed): no TLSA configured, so do
the 'usual' (no TLS or normal TLS).

And some TLSA objects. Malformed ones are not usable, mismatches are
not usable. If none are usable, since TLSA is configured, no downgrade
with TLS processing: access denied.

If usable TLSA objects: you have a match, yay. Do what the draft says.

If domain not DNSSEC signed (insecure): normal TLS (or no TLS).

If TLSA query fails (no reply from network, all traffic disappears):
access denied. (This is the part where I think your trap still applies,
but it is much smaller than before: not many DNSSEC-signed domains will
fail to resolve a TLSA query; they usually upgrade software and thus
also support the unknown-RR-types RFC).

Would that come out of the trap?

Best regards,
Wouter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk0KgaEACgkQkDLqNwOhpPgjbACbBCoSEi4fgwyFhPhnECVkwk91
4bQAn3fZKI+Ko74vIhj/ndVZtNkKo1VQ
=aBSf
-----END PGP SIGNATURE-----

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B8C13A6953 for ; Thu, 16 Dec 2010 12:42:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.391
X-Spam-Level:
X-Spam-Status: No, score=-2.391 tagged_above=-999 required=5 tests=[AWL=0.208, 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 EcX3pldAEywL for ; Thu, 16 Dec 2010 12:42:21 -0800 (PST)
Received: from homiemail-a62.g.dreamhost.com (mx1.spunky.mail.dreamhost.com [208.97.132.47]) by core3.amsl.com (Postfix) with ESMTP id 8D5D33A6934 for ; Thu, 16 Dec 2010 12:42:21 -0800 (PST)
Received: from homiemail-a62.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTP id C706263406F; Thu, 16 Dec 2010 12:44:06 -0800 (PST)
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=dvjLT0L1sYVVPxdGhxjyxm4ON7X7mq5YUK+szQXrQS6 MjQFGfK4NzElRAMtnOh8pBwvTY1rkjEccWMC+MsvS2n7OLAQUd4gskB7n2XJVKWS 8aQCOKoSClPz4qPbUA0XY9eB0p+SzLnwt4vJkRxa01c70mYHi6MEcLqiMkQ9vgj0 =
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=NRcsCc/jMpGCqG/Ed2Vy/EMWwAY=; b=jk/chWeaoq NOXPlrytm4gy6R1eba32MyZaUc1vO0tRhgqEtLtsDqfOAnfVSJR+mYNq4toO8uYI TXy2sLBxCPDJ++LDlusGUQdzXhAw4+gTovckMOhX3ZTF0zodOA3s8cbb7hHjUdmc pFBaa8FgjtcxZUG0ytZKFVb3Y5JuzPlFs=
Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: [email-masked]) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTPA id 63009634064; Thu, 16 Dec 2010 12:44:06 -0800 (PST)
From: Matt McCutchen
To: Phillip Hallam-Baker
In-Reply-To: <[email-masked]>
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 16 Dec 2010 15:44:05 -0500
Message-ID: <[email-masked]>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.1
Content-Transfer-Encoding: 7bit
Cc: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 20:42:22 -0000

On Thu, 2010-12-16 at 14:59 -0500, Matt McCutchen wrote:
> On Thu, 2010-12-16 at 18:50 +0000, Phillip Hallam-Baker wrote:
> > On Thu, Dec 16, 2010 at 6:24 PM, Stephen Schultze
> > wrote:
> >
> >
> > Feel free to publish that standard, and it can potentially be
> > compatible with the DANE spec's requirement that answers be
> > DNSSEC-validated. It will always have the disadvantage of
> > requiring end users to delegate security responsibility to a
> > third party. Furthermore, for it to have the advantages you
> > described in the case of non-DNSSEC-validated responses, it
> > will also have to have some squishy heuristics around when to
> > trust past/alternative results and the like. Building such
> > indeterminacy into our spec be default doesn't seem like a
> > path to a strong security protocol, but offering it as an
> > option to users seems reasonable.
> >
> >
> > Since the purpose of the standard would be to enable that exact model,
> > it can hardly be seen as a 'disadvantage'.
>
> I assume you're referring to the delegation of security responsibility
> to the registrars on the path? Yes, the purpose of the standard is to
> enable delegation -- to the parties authoritative for the resolution of
> the name, not providers of DNSSEC resolution services.

Phillip has pointed out to me that I misunderstood, and the "standard"
there is the one for external resolvers, not DANE. Never mind my
remark.

I'll agree with Stephen that exposure to a third party, compared to no
exposure, is a disadvantage, but of course that has to be put in
context. Some clients may find that an external resolver meets their
needs well.

--
Matt

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E62E93A69B1 for ; Thu, 16 Dec 2010 12:07:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.228
X-Spam-Level:
X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=0.371, 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 xtMd4osduRRg for ; Thu, 16 Dec 2010 12:07:44 -0800 (PST)
Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id BCBDD3A6919 for ; Thu, 16 Dec 2010 12:07:44 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=WTjRe1h5F6gyyUcmFfL7Rlq0XWHZjqsznemuLtA2ifBhfoSXaleT5TgGbfGI4DzP; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.40] (helo=elwamui-milano.atl.sa.earthlink.net) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1PTK8n-0002nn-UL for [email-masked]; Thu, 16 Dec 2010 15:09:29 -0500
Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Thu, 16 Dec 2010 15:09:29 -0500
Message-ID: <[email-masked]>
Date: Thu, 16 Dec 2010 14:09:29 -0600 (GMT-06:00)
From: "Jeffrey A. Williams"
To: [email-masked]
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688b83a218240a35fb917728e99324e8693350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.40
Subject: Re: [keyassure] "Trusted third parties"
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: "Jeffrey A. Williams"
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 20:07:46 -0000

Matt and all,

-----Original Message-----
>From: Matt McCutchen
>Sent: Dec 16, 2010 1:45 PM
>To: Paul Wouters
>Cc: [email-masked]
>Subject: Re: [keyassure] "Trusted third parties"
>
>On Thu, 2010-12-16 at 14:23 -0500, Paul Wouters wrote:
>> On Thu, 16 Dec 2010, Matt McCutchen wrote:
>>
>> > Let no one miss that DANE as it is to be commonly practiced still
>> > depends on third parties: ICANN/Verisign and whoever else is on the path
>> > to one's zone. Hopefully they will be less unruly than the public CAs,
>> > but people who are serious about not trusting third parties will still
>> > need something else.
>>
>> The big difference is that if you are mobile, attackers will have to falsify
>> the public's view of DNS(SEC), so this becomes very obvious.
>
>Really? I remember someone describing how a rogue registrar could
>target a false answer to one user, but I haven't been able to find the
>message now.

I've seen this occurance and there have been several rogue
registrars in the past 2 years as has been reported. Should any
of them be considered as or for "Trusted Third parties"?
>
>--
>Matt
>
>_______________________________________________
>keyassure mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/keyassure
Regards,
Jeffrey A. Williams
"Obedience of the law is the greatest freedom" -
Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
Network Eng. SR. Eng. Network data security
ABA member in good standing member ID 01257402
E-Mail [email-masked]
Phone: 214-244-4827

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65AE03A6920 for ; Thu, 16 Dec 2010 12:04:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.206
X-Spam-Level:
X-Spam-Status: No, score=-2.206 tagged_above=-999 required=5 tests=[AWL=0.393, 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 QieigYAtxZgB for ; Thu, 16 Dec 2010 12:04:39 -0800 (PST)
Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id 404BE3A6919 for ; Thu, 16 Dec 2010 12:04:39 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=owcT2/Go9b7mMyPIV00A5KP4KQ/zwYVIwTEi2Cw4mTRteKNRNaT6QY3seM8n4Hfw; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.40] (helo=elwamui-milano.atl.sa.earthlink.net) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1PTK5o-0000d1-FZ for [email-masked]; Thu, 16 Dec 2010 15:06:24 -0500
Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Thu, 16 Dec 2010 15:06:24 -0500
Message-ID: <[email-masked]>
Date: Thu, 16 Dec 2010 14:06:24 -0600 (GMT-06:00)
From: "Jeffrey A. Williams"
To: [email-masked]
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e519606881b80c43892355c6b19c4564d17078faa350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.40
Subject: Re: [keyassure] "Trusted third parties"
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: "Jeffrey A. Williams"
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 20:04:40 -0000

Paul and all,

-----Original Message-----
>From: Paul Wouters
>Sent: Dec 16, 2010 1:53 PM
>To: Matt McCutchen
>Cc: [email-masked]
>Subject: Re: [keyassure] "Trusted third parties"
>
>On Thu, 16 Dec 2010, Matt McCutchen wrote:
>
>>> The big difference is that if you are mobile, attackers will have to falsify
>>> the public's view of DNS(SEC), so this becomes very obvious.
>>
>> Really? I remember someone describing how a rogue registrar could
>> target a false answer to one user, but I haven't been able to find the
>> message now.
>
>I am not sure how they would distinguish me from someone else's DNS query?

This IMO is a good point and question. Trusted third parties are
an anacranism in many ways. How is such a determination of a Trusted
third party to be defined and therefore determined? What are the
criterion?
>
>Also, I would recommend to preload your own zone's trust anchor in your local
>resolver, so that outages and possibly subversion attempts will at least fail
>for all of the resoures under your own (zone) control.

Good idea. But doesn't this then sort of thwart the 'Trusted Third
parties" approach as well?
>
>Paul
>(yes my resolvers have xelerance.com/xelerance.net DNSKEY's preloaded)
>_______________________________________________
>keyassure mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/keyassure

Regards,
Jeffrey A. Williams
"Obedience of the law is the greatest freedom" -
Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
Network Eng. SR. Eng. Network data security
ABA member in good standing member ID 01257402
E-Mail [email-masked]
Phone: 214-244-4827

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F6333A6920 for ; Thu, 16 Dec 2010 11:58:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.378
X-Spam-Level:
X-Spam-Status: No, score=-2.378 tagged_above=-999 required=5 tests=[AWL=0.221, 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 Sg49bxCNZQzT for ; Thu, 16 Dec 2010 11:58:17 -0800 (PST)
Received: from homiemail-a61.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by core3.amsl.com (Postfix) with ESMTP id 9885F3A68E1 for ; Thu, 16 Dec 2010 11:58:17 -0800 (PST)
Received: from homiemail-a61.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a61.g.dreamhost.com (Postfix) with ESMTP id 1373C57806C; Thu, 16 Dec 2010 12:00:03 -0800 (PST)
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=gxlaWP8Sy9YGxzZvCeIQTdoK3ARKsRtmxiPnBnyMfej dyZsk9V4bW0X7cLUSZNy/DhGh1YMBl0O5ZIKTyXbO3XnAFUhopqqHgM1MpbiZ0VK D3sVkB9qV0KVUC6h9I+1jBmu8DtPD1hI0iRAs4Go1p9J8qpAlNGxkQLXQcQDFlFM =
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=J3ubHtzI2IlD1Jr0gQgc1cJMyWc=; b=QVSqSObPI6 tjuMowlMn8ZLDQQ+esHUWqVE52s8nyuAqv8nJDXK1/QJz+YDnMrJODG3ZRwytKBl cK5QZGE9XGadJg+JzIp6lRxdVDGtu/EBBEBFh6mOrdfcwquismdjlLBMFbcyu/UC OXZNnnt8AOwt5Lto0zijniYk1tZzQmp2o=
Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: [email-masked]) by homiemail-a61.g.dreamhost.com (Postfix) with ESMTPA id 4BCCF578073; Thu, 16 Dec 2010 12:00:00 -0800 (PST)
From: Matt McCutchen
To: Phillip Hallam-Baker
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 16 Dec 2010 14:59:59 -0500
Message-ID: <[email-masked]>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.1
Content-Transfer-Encoding: 7bit
Cc: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 19:58:18 -0000

On Thu, 2010-12-16 at 18:50 +0000, Phillip Hallam-Baker wrote:
> On Thu, Dec 16, 2010 at 6:24 PM, Stephen Schultze
> wrote:
>
>
> Feel free to publish that standard, and it can potentially be
> compatible with the DANE spec's requirement that answers be
> DNSSEC-validated. It will always have the disadvantage of
> requiring end users to delegate security responsibility to a
> third party. Furthermore, for it to have the advantages you
> described in the case of non-DNSSEC-validated responses, it
> will also have to have some squishy heuristics around when to
> trust past/alternative results and the like. Building such
> indeterminacy into our spec be default doesn't seem like a
> path to a strong security protocol, but offering it as an
> option to users seems reasonable.
>
>
> Since the purpose of the standard would be to enable that exact model,
> it can hardly be seen as a 'disadvantage'.

I assume you're referring to the delegation of security responsibility
to the registrars on the path? Yes, the purpose of the standard is to
enable delegation -- to the parties authoritative for the resolution of
the name, not providers of DNSSEC resolution services.

> In the long term we can expect deployment of DNSSEC to stabilize to
> the point that it may become practical to employ the strong end-to-end
> approach on certain clients. But any scheme that relies on that
> approach is going to prove brittle in deployment.

What is unstable now? If today I sign my zone and my friend sets up his
hypothetical DANE client to use some working DNSSEC server and connects
to my TLS server, what do you envision going wrong?

> Attacks change over time. A security measure that is entirely
> deterministic has no capability to adapt to respond to new attacks.

> Having some degree of play in the system can be a very good thing,
> provided that is that the control over the degree of play is properly
> accountable.

TLS seeks to achieve complete integrity modulo the security of the
endpoints and cryptographic algorithms and leaves availability to the
network operators. It seems that a server authentication method that
seeks to achieve complete integrity (with respect to the registrars) and
leaves availability to the DNS operators would be a good complement.

Assuming a focus on integrity, I don't see how your specific proposal to
accept old keys in some cases when the DNSSEC signature has disappeared
would help. More generally, one can imagine that a resolution service
might be able to respond to certain classes of new attacks on behalf of
its users.

In any case, I agree with Stephen that such things don't belong in the
DANE spec.

--
Matt

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB4143A69B3 for ; Thu, 16 Dec 2010 11:52:15 -0800 (PST)
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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjn-1ZswqyVE for ; Thu, 16 Dec 2010 11:52:14 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id A10A53A6949 for ; Thu, 16 Dec 2010 11:52:14 -0800 (PST)
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 E0867C4BE; Thu, 16 Dec 2010 14:53:58 -0500 (EST)
Date: Thu, 16 Dec 2010 14:53:58 -0500 (EST)
From: Paul Wouters
To: Matt McCutchen
In-Reply-To: <[email-masked]>
Message-ID:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: [email-masked]
Subject: Re: [keyassure] "Trusted third parties"
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 19:52:15 -0000

On Thu, 16 Dec 2010, Matt McCutchen wrote:

>> The big difference is that if you are mobile, attackers will have to falsify
>> the public's view of DNS(SEC), so this becomes very obvious.
>
> Really? I remember someone describing how a rogue registrar could
> target a false answer to one user, but I haven't been able to find the
> message now.

I am not sure how they would distinguish me from someone else's DNS query?

Also, I would recommend to preload your own zone's trust anchor in your local
resolver, so that outages and possibly subversion attempts will at least fail
for all of the resoures under your own (zone) control.

Paul
(yes my resolvers have xelerance.com/xelerance.net DNSKEY's preloaded)

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38C763A6924 for ; Thu, 16 Dec 2010 11:43:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.364
X-Spam-Level:
X-Spam-Status: No, score=-2.364 tagged_above=-999 required=5 tests=[AWL=0.235, 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 jX7dhbWmBEkF for ; Thu, 16 Dec 2010 11:43:18 -0800 (PST)
Received: from homiemail-a6.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by core3.amsl.com (Postfix) with ESMTP id 4C87A3A6968 for ; Thu, 16 Dec 2010 11:43:18 -0800 (PST)
Received: from homiemail-a6.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTP id B38D159807C; Thu, 16 Dec 2010 11:45:03 -0800 (PST)
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=f9AXbHo399WZkEuioLFcAJhXNTQWZiFg5XyIMyXVeG/ 48Q6VI4dTO5UtdtGnaIXB3VKg5EOma/2ISpXsl8pROorTo6cJyDsD/MtVE/jOYHu V9U9wCIxsGe4S1Ot+NltxdE2dZQVfie0UryUX9IRl/9FT1zE4LwOImyjTr/mvFxA =
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=1X+6UWi38F9iWYTkRp3K7NKxGpM=; b=jXn1uYPzUk PkGlFBXmD01lHyj2P+C8grMghwps2k/C1yMXtuDw/gzNmwsz8YFlTeyyM40D99yh uL3mUuuzAzqU0sJW3RgtWITm0aGTHV5H20tsUN8MCs9YEkaO/h1sY12CKXGnF1Eo VE7H7UyGRxv0rCfTaa+7wiQbHmfgoz7tU=
Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: [email-masked]) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTPA id 6324459807D; Thu, 16 Dec 2010 11:45:03 -0800 (PST)
From: Matt McCutchen
To: Paul Wouters
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 16 Dec 2010 14:45:02 -0500
Message-ID: <[email-masked]>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.1
Content-Transfer-Encoding: 7bit
Cc: [email-masked]
Subject: Re: [keyassure] "Trusted third parties"
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 19:43:19 -0000

On Thu, 2010-12-16 at 14:23 -0500, Paul Wouters wrote:
> On Thu, 16 Dec 2010, Matt McCutchen wrote:
>
> > Let no one miss that DANE as it is to be commonly practiced still
> > depends on third parties: ICANN/Verisign and whoever else is on the path
> > to one's zone. Hopefully they will be less unruly than the public CAs,
> > but people who are serious about not trusting third parties will still
> > need something else.
>
> The big difference is that if you are mobile, attackers will have to falsify
> the public's view of DNS(SEC), so this becomes very obvious.

Really? I remember someone describing how a rogue registrar could
target a false answer to one user, but I haven't been able to find the
message now.

--
Matt

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29C553A69A3 for ; Thu, 16 Dec 2010 11:26:59 -0800 (PST)
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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KBn5W-ebZjjy for ; Thu, 16 Dec 2010 11:26:58 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 4FC4D3A6968 for ; Thu, 16 Dec 2010 11:26:58 -0800 (PST)
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 1DD34C4BE; Thu, 16 Dec 2010 14:28:42 -0500 (EST)
Date: Thu, 16 Dec 2010 14:28:41 -0500 (EST)
From: Paul Wouters
To: Martin Rex
In-Reply-To: <[email-masked]>
Message-ID:
References: <[email-masked]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 19:26:59 -0000

On Thu, 16 Dec 2010, Martin Rex wrote:

> You may want to distinguish two types of "old values":
>
> - Caching RRs beyond TTL expiration should not be a problem and is IMHO
> permitted by the spec as a fallback.

That would be dangerous - you might miss the purposeful removal of some
TLSA (eg after the private key of the webserver got compromised)

I would say that TTL and RRSIG expiry time fall within what the DNSSEC
authority (signer) security stated about the TLSA record. A TLSA enabled
client MUST adhere to those obtained values.

The "leap of faith" with ssh was based on doing this because there was no
concept of expiry. But if you now set "VerifyHostKeyDNS yes" for ssh, then
if the SSHFP record is not a match, and you have the old key in your
knwon hosts file, it WILL warn you before using that key - as it should!

Paul

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6A343A69B1 for ; Thu, 16 Dec 2010 11:21:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.576
X-Spam-Level:
X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 L4aTRFBSVR0m for ; Thu, 16 Dec 2010 11:21:50 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id B168C3A69A3 for ; Thu, 16 Dec 2010 11:21:46 -0800 (PST)
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 78AE3C4BE; Thu, 16 Dec 2010 14:23:31 -0500 (EST)
Date: Thu, 16 Dec 2010 14:23:30 -0500 (EST)
From: Paul Wouters
To: Matt McCutchen
In-Reply-To: <[email-masked]>
Message-ID:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: Stephen Schultze , [email-masked]
Subject: Re: [keyassure] "Trusted third parties"
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 19:21:50 -0000

On Thu, 16 Dec 2010, Matt McCutchen wrote:

> Let no one miss that DANE as it is to be commonly practiced still
> depends on third parties: ICANN/Verisign and whoever else is on the path
> to one's zone. Hopefully they will be less unruly than the public CAs,
> but people who are serious about not trusting third parties will still
> need something else.

The big difference is that if you are mobile, attackers will have to falsify
the public's view of DNS(SEC), so this becomes very obvious. Contrary to using
one of many CA's to sign something bad, knowing your laptop is preloading with
trust to that CA (one of 1500+, so you can't realisticly audit your laptop for
CA trust)

Paul

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C1743A69B7 for ; Thu, 16 Dec 2010 11:19:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.287
X-Spam-Level:
X-Spam-Status: No, score=-2.287 tagged_above=-999 required=5 tests=[AWL=-0.288, BAYES_00=-2.599, J_CHICKENPOX_34=0.6]
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 jGehzsBBrmoO for ; Thu, 16 Dec 2010 11:19:25 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 27B7C3A69B1 for ; Thu, 16 Dec 2010 11:19:24 -0800 (PST)
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 CD0E5C436; Thu, 16 Dec 2010 14:21:07 -0500 (EST)
Date: Thu, 16 Dec 2010 14:21:07 -0500 (EST)
From: Paul Wouters
To: Simon Josefsson
In-Reply-To: <[email-masked]>
Message-ID:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 19:19:26 -0000

On Thu, 16 Dec 2010, Simon Josefsson wrote:

>>> limit the circumstances in which certificates validate, it does not
>>> matter if TLSA was received over DNSSEC or not.
>>
>> How, other than DNSSEC validation, would you receive a TLSA record
>> that you would trust?
>
> DNS+TSIG?

That would be "DNS+TSIG from a trusted soure". If you don't use DNSSEC
and the server you have a TSIG-like trust relationship with is not the
authoratative server, then you still don't know if they got it securely
(and you're not validating it).

One more reason of course for end to end DNSSEC.

Paul

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 665963A69AC for ; Thu, 16 Dec 2010 11:14:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.347
X-Spam-Level:
X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[AWL=0.252, 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 b1cFOo83aaW2 for ; Thu, 16 Dec 2010 11:14:08 -0800 (PST)
Received: from homiemail-a10.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by core3.amsl.com (Postfix) with ESMTP id 5EE353A69A7 for ; Thu, 16 Dec 2010 11:14:08 -0800 (PST)
Received: from homiemail-a10.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a10.g.dreamhost.com (Postfix) with ESMTP id BFEFC28006C; Thu, 16 Dec 2010 11:15:53 -0800 (PST)
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=BKElHbfIoc8nyMZbtDCJrQGXZLtDc51dajKCVNC1ROA L8eED+P4ufw+jZT2bkHwBIBX4npBlZYYwtr4RKcIo4i1t5SGkrLxpxY17/S0nIBr LyQY2u7B0Z+o/Uv50dNnLKb3qfVEHHo+1fV7ZrHYO38mjuL5cGs5o7/86zbuziFY =
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=qcwOHL5ed68mNCTBoReNDTedvGI=; b=HjXnrKc9Ao Wibmqi6qwQkHSaHDbs2f9WuZONXLnjxnak3xsXb4t4tFELtfYu9gE/k40wFsvmfp tka2sjAxqIOBEQXboTZWr03GD+oqosHeMKyoiyYo3hbPMwljkLO31tSym77veBVm dRyV+9TsphMS0Xful9ok5NWHXpdaIdink=
Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: [email-masked]) by homiemail-a10.g.dreamhost.com (Postfix) with ESMTPA id 7A7AE280063; Thu, 16 Dec 2010 11:15:53 -0800 (PST)
From: Matt McCutchen
To: Stephen Schultze
In-Reply-To: <[email-masked]>
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 16 Dec 2010 14:15:52 -0500
Message-ID: <[email-masked]>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.1
Content-Transfer-Encoding: 7bit
Cc: [email-masked]
Subject: Re: [keyassure] "Trusted third parties"
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 19:14:09 -0000

On Thu, 2010-12-16 at 13:56 -0500, Stephen Schultze wrote:
> I think that the past 10
> years has demonstrated a constant degradation of the "trusted third
> party" model in the context of PKIX (as a cryptographic, operational,
> and governance matter).

Let no one miss that DANE as it is to be commonly practiced still
depends on third parties: ICANN/Verisign and whoever else is on the path
to one's zone. Hopefully they will be less unruly than the public CAs,
but people who are serious about not trusting third parties will still
need something else.

--
Matt

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B326F3A69A4 for ; Thu, 16 Dec 2010 10:59:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.328
X-Spam-Level:
X-Spam-Status: No, score=-2.328 tagged_above=-999 required=5 tests=[AWL=0.271, 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 TO4E97rvijCL for ; Thu, 16 Dec 2010 10:59:21 -0800 (PST)
Received: from homiemail-a37.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by core3.amsl.com (Postfix) with ESMTP id A53E73A69A3 for ; Thu, 16 Dec 2010 10:59:21 -0800 (PST)
Received: from homiemail-a37.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTP id E38EA1D0072; Thu, 16 Dec 2010 11:01:06 -0800 (PST)
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=Q2WoR4UmraZX4+XzuhXciRDEBNZ8w6qBW5Tpk3u2weJ 7HYEsSuKmVsamZvsjvYDchB/xJVvVF8bYPL5/zcBAifhKEozCEogSLBBCrYOCfLj 8cQlU5inTHl6EkOiz8m0O7TzsoJbvXJ9aJQY2fydG3tJ7WwULm9l6LyC9Iql7Z8U =
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=hY/PTnBURXzroVuWiue0Nj8WqeE=; b=UkB/GpdQcv Ns5xjDAMI9N7W0CLm8r7RyklM7MYcEzQEI0DwPiKpRscelD2OSPMzJVhPmrF7Z5A JQrl4NWFeSMyWQSqNIW0eGuqTq8lXEvqqF/IMnJzrO3fCLbr/Ek3abxfiDXSbgQP 3uab3Eaj52+OYjSAWlGwqgbFWvetbaAzA=
Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: [email-masked]) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTPA id 574B81D006E; Thu, 16 Dec 2010 11:01:06 -0800 (PST)
From: Matt McCutchen
To: Stephen Schultze
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 16 Dec 2010 14:01:00 -0500
Message-ID: <[email-masked]>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.1
Content-Transfer-Encoding: 7bit
Cc: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 18:59:22 -0000

On Thu, 2010-12-16 at 13:32 -0500, Stephen Schultze wrote:
> On Dec 16, 2010, at 1:20 PM, Matt McCutchen wrote:
> > AIUI, that line is within the case in which the DNSSEC query has
> > succeeded.
>
> That's not how I read it. All that section says is "In order to use
> one or more TLS certificate associations described in this document
> obtained from the DNS, an application MUST assure that the
> certificates were obtained using DNS protected by DNSSEC." In the
> case of no DNSSEC validation, and fallback to standard PKIX, the
> client would not be "us[ing] one or more TLS certificate
> associations... obtained from the DNS." It would be using the
> contents of the cert provided by the TLS handshake.

You are right. That has to be a mistake.

> > That could be clarified by changing the paragraph to:
> >
> > ---
> > An application that performs a successful DNSSEC query for TLS
> > certificate associations using the method described in this document
> > obtains zero or more usable certificate associations. If the
> > application receives zero usable certificate associations, it
> > processes
> > TLS in the normal fashion.
> > ---
>
> But what if the client does not want to fall back on PKIX TLS even if
> the site operator has not yet deployed DANE? Should that not be an
> option for the client? This would argue for a MAY, rather than the
> implied MUST above.

Right, I think the fallback method should be unspecified. It's useful
to be able to speak of DANE-compliant clients that fall back to PKIX,
something else, or nothing at all. But this is a separate issue, so I
didn't address it in giving a small fix for the downgrade issue.

--
Matt

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EBED3A69A7 for ; Thu, 16 Dec 2010 10:57:22 -0800 (PST)
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.087, 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 5T+Qj0iPnPPb for ; Thu, 16 Dec 2010 10:57:21 -0800 (PST)
Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id EC57F3A6933 for ; Thu, 16 Dec 2010 10:57:20 -0800 (PST)
Received: from latte.josefsson.org (c80-216-27-64.bredband.comhem.se [80.216.27.64]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id oBGIwkrw001754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 16 Dec 2010 19:58:48 +0100
From: Simon Josefsson
To: Steve Schultze
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:101216:[email-masked]::E7DzkTSEcYVDAolg:6/Ja
X-Hashcash: 1:22:101216:[email-masked]::tt4+fA8ZdqRGlLxw:Ebiv
Date: Thu, 16 Dec 2010 19:58:45 +0100
In-Reply-To: <[email-masked]> (Steve Schultze's message of "Thu, 16 Dec 2010 11:42:17 -0500")
Message-ID: <[email-masked]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Virus-Scanned: clamav-milter 0.96.5 at yxa-v
X-Virus-Status: Clean
Cc: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 18:57:22 -0000

Steve Schultze writes:

> On Dec 16, 2010, at 11:03 AM, Florian Weimer wrote:
>> For instance, if you use TLSA to
>> limit the circumstances in which certificates validate, it does not
>> matter if TLSA was received over DNSSEC or not.
>
> How, other than DNSSEC validation, would you receive a TLSA record
> that you would trust?

DNS+TSIG?

/Simon

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 407293A6933 for ; Thu, 16 Dec 2010 10:55:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YH7QfkBAwxTk for ; Thu, 16 Dec 2010 10:55:05 -0800 (PST)
Received: from ppa03.princeton.edu (ppa03.Princeton.EDU [128.112.128.214]) by core3.amsl.com (Postfix) with ESMTP id 421963A691B for ; Thu, 16 Dec 2010 10:55:05 -0800 (PST)
Received: from csgsmtp200l.Princeton.EDU (csgsmtp200l.Princeton.EDU [128.112.130.131]) by ppa03.princeton.edu (8.14.3/8.14.3) with ESMTP id oBGIuoep006317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 16 Dec 2010 13:56:50 -0500
Received: from mayflower-ad.Princeton.EDU (mayflower-ad.Princeton.EDU [128.112.224.246]) (authenticated bits=0) by csgsmtp200l.Princeton.EDU (8.13.8/8.12.9) with ESMTP id oBGIunXU006671 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 16 Dec 2010 13:56:49 -0500
Message-Id: <[email-masked]>
From: Stephen Schultze
To: [email-masked]
In-Reply-To:
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Thu, 16 Dec 2010 13:56:49 -0500
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
X-Mailer: Apple Mail (2.936)
X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6199 signatures=655053
X-Proofpoint-Spam-Details: rule=quarantine_notspam policy=quarantine score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1010190000 definitions=main-1012160127
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 18:55:06 -0000

On Dec 16, 2010, at 1:50 PM, Phillip Hallam-Baker wrote:
> On Thu, Dec 16, 2010 at 6:24 PM, Stephen Schultze
> wrote:
>
> Feel free to publish that standard, and it can potentially be
> compatible with the DANE spec's requirement that answers be DNSSEC-
> validated. It will always have the disadvantage of requiring end
> users to delegate security responsibility to a third party.
> Furthermore, for it to have the advantages you described in the case
> of non-DNSSEC-validated responses, it will also have to have some
> squishy heuristics around when to trust past/alternative results and
> the like. Building such indeterminacy into our spec be default
> doesn't seem like a path to a strong security protocol, but offering
> it as an option to users seems reasonable.
>
> Since the purpose of the standard would be to enable that exact
> model, it can hardly be seen as a 'disadvantage'.
>
> In the long term we can expect deployment of DNSSEC to stabilize to
> the point that it may become practical to employ the strong end-to-
> end approach on certain clients. But any scheme that relies on that
> approach is going to prove brittle in deployment.
>
> There is a very important difference between security features and
> security. The academic approach to cryptography tends to over-
> emphasize security features and concentrate on a small,
> unrepresentative set of attacks, it ignores the complexity that
> makes real security hard.
>
>
> Attacks change over time. A security measure that is entirely
> deterministic has no capability to adapt to respond to new attacks.
>
> Having some degree of play in the system can be a very good thing,
> provided that is that the control over the degree of play is
> properly accountable.

We are going to have to agree to disagree. I think that the past 10
years has demonstrated a constant degradation of the "trusted third
party" model in the context of PKIX (as a cryptographic, operational,
and governance matter). One of DANE's comparative advantages is that
it makes it possible to push control to the edges. Re-introducing
centralized dependencies and ambiguities is a disadvantage in my
view. It is also mismatched with the thrust of all of this groups
efforts so far, but if I'm wrong I'm sure someone other than you will
pipe up in support.

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 016EC3A69A6 for ; Thu, 16 Dec 2010 10:48:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.345
X-Spam-Level:
X-Spam-Status: No, score=-3.345 tagged_above=-999 required=5 tests=[AWL=0.253, 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 6izP-lsoCbLX for ; Thu, 16 Dec 2010 10:48:22 -0800 (PST)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id B8FE23A69A3 for ; Thu, 16 Dec 2010 10:48:22 -0800 (PST)
Received: by gyd12 with SMTP id 12so1927455gyd.31 for ; Thu, 16 Dec 2010 10:50:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=mnTKNutqHG+cg2B6QByHs2/11EoJCnEJo6Zm+rN1+0E=; b=mkseL1PonzOwfALNuU6yGKPUVh6DICgEo+F5zhyBnCc9CCTZMcEVwAD/Fq7QG2zu9i 5QUQNzgXyKt/YVKuLvjl+nJxiRdlRTYi3jFYp+RcjapTecDyuaYe3yDxyN7VYYOFKizo LtZte9Shl8M/uf2I35pNeOEPx8hNZHu3pEwhs=
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=mB7JWXe3wVD7fJYdgHaGLfU9XLvn/Tx/0BY/7lB6cwV/x9GSVkKstmfyWSZly03o7L yLGaloF1NIs2PJIgnEYqOhPtiNq1C9lCtv4q+A+7axm3CPQa1DlnAkGgRcezy/cIp0E8 ZdRRaNsw2zfYwhS7Uja8lN/qOK1f0sTAWo6+g=
MIME-Version: 1.0
Received: by 10.100.195.2 with SMTP id s2mr38408anf.35.1292525407200; Thu, 16 Dec 2010 10:50:07 -0800 (PST)
Received: by 10.100.31.8 with HTTP; Thu, 16 Dec 2010 10:50:07 -0800 (PST)
In-Reply-To: <[email-masked]>
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Thu, 16 Dec 2010 18:50:07 +0000
Message-ID:
From: Phillip Hallam-Baker
To: Stephen Schultze
Content-Type: multipart/alternative; boundary=0016e644ba16c268b304978b85dc
Cc: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 18:48:24 -0000

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

On Thu, Dec 16, 2010 at 6:24 PM, Stephen Schultze wrote:

>
> Feel free to publish that standard, and it can potentially be compatible
> with the DANE spec's requirement that answers be DNSSEC-validated. It will
> always have the disadvantage of requiring end users to delegate security
> responsibility to a third party. Furthermore, for it to have the advantages
> you described in the case of non-DNSSEC-validated responses, it will also
> have to have some squishy heuristics around when to trust past/alternative
> results and the like. Building such indeterminacy into our spec be default
> doesn't seem like a path to a strong security protocol, but offering it as
> an option to users seems reasonable.

Since the purpose of the standard would be to enable that exact model, it
can hardly be seen as a 'disadvantage'.

In the long term we can expect deployment of DNSSEC to stabilize to the
point that it may become practical to employ the strong end-to-end approach
on certain clients. But any scheme that relies on that approach is going to
prove brittle in deployment.

There is a very important difference between security features and security.
The academic approach to cryptography tends to over-emphasize security
features and concentrate on a small, unrepresentative set of attacks, it
ignores the complexity that makes real security hard.

Attacks change over time. A security measure that is entirely deterministic
has no capability to adapt to respond to new attacks.

Having some degree of play in the system can be a very good thing, provided
that is that the control over the degree of play is properly accountable.

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

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

On Thu, Dec 16, 2010 at 6:24 PM, Stephen Schultze <[email-masked]> wrote:

Feel free to publish that standard, and it can potentially be compatible wi=
th the DANE spec's requirement that answers be DNSSEC-validated. =A0It =
will always have the disadvantage of requiring end users to delegate securi=
ty responsibility to a third party. =A0Furthermore, for it to have the adva=
ntages you described in the case of non-DNSSEC-validated responses, it will=
also have to have some squishy heuristics around when to trust past/altern=
ative results and the like. =A0Building such indeterminacy into our spec be=
default doesn't seem like a path to a strong security protocol, but of=
fering it as an option to users seems reasonable.

Since the purpose of the standard would be to enable th=
at exact model, it can hardly be seen as a 'disadvantage'.=A0
=

In the long term we can expect deployment of DNSSEC=
to stabilize to the point that it may become practical to employ the stron=
g end-to-end approach on certain clients. But any scheme that relies on tha=
t approach is going to prove brittle in deployment.

There is a very important difference between security featur=
es and security. The academic approach to cryptography tends to over-emphas=
ize security features and concentrate on a small, unrepresentative set of a=
ttacks, it ignores the complexity that makes real security hard.

Attacks change over time. A securit=
y measure that is entirely deterministic has no capability to adapt to resp=
ond to new attacks.=A0

Having some degree of play =
in the system can be a very good thing, provided that is that the control o=
ver the degree of play is properly accountable.

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

--0016e644ba16c268b304978b85dc--

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 516D43A6977 for ; Thu, 16 Dec 2010 10:44:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.135
X-Spam-Level:
X-Spam-Status: No, score=-10.135 tagged_above=-999 required=5 tests=[AWL=0.114, 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 buK2cfB7qXs9 for ; Thu, 16 Dec 2010 10:44:15 -0800 (PST)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 225A43A691B for ; Thu, 16 Dec 2010 10:44:14 -0800 (PST)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id oBGIjwW5019304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 Dec 2010 19:45:58 +0100 (MET)
From: Martin Rex
Message-Id: <[email-masked]>
To: [email-masked] (Paul Wouters)
Date: Thu, 16 Dec 2010 19:45:56 +0100 (MET)
In-Reply-To: from "Paul Wouters" at Dec 16, 10 12:31:00 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal08
X-SAP: out
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: [email-masked]
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 18:44:16 -0000

Paul Wouters wrote:
>
> On Thu, 16 Dec 2010, Phillip Hallam-Baker wrote:
> >
> > So the best course of action is probably to tell the client to use
> > the old values and tell the admin that they seem to have goofed up.
> > Hopefully by some automated means.
>
> That is the most dangerous action to take, and would seriously devalue
> the trust in DNSSEC.

You may want to distinguish two types of "old values":

- Caching RRs beyond TTL expiration should not be a problem and is IMHO
permitted by the spec as a fallback.

- Using a signed RR beyond the Signature Expiration Date is undesirable,
though.

-Martin

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D66AB3A6995 for ; Thu, 16 Dec 2010 10:31:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqIqMWKtd79s for ; Thu, 16 Dec 2010 10:30:50 -0800 (PST)
Received: from ppa04.Princeton.EDU (ppa04.Princeton.EDU [128.112.128.215]) by core3.amsl.com (Postfix) with ESMTP id A9FFE3A6981 for ; Thu, 16 Dec 2010 10:30:50 -0800 (PST)
Received: from csgsmtp201l.Princeton.EDU (csgsmtp201l.Princeton.EDU [128.112.134.60]) by ppa04.Princeton.EDU (8.14.3/8.14.3) with ESMTP id oBGIWZuT022535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 16 Dec 2010 13:32:35 -0500
Received: from mayflower-ad.Princeton.EDU (mayflower-ad.Princeton.EDU [128.112.224.246]) (authenticated bits=0) by csgsmtp201l.Princeton.EDU (8.13.8/8.12.9) with ESMTP id oBGIWZfr009652 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 16 Dec 2010 13:32:35 -0500
Message-Id:
From: Stephen Schultze
To: [email-masked]
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Thu, 16 Dec 2010 13:32:35 -0500
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
X-Mailer: Apple Mail (2.936)
X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6198 signatures=655024
X-Proofpoint-Spam-Details: rule=quarantine_notspam policy=quarantine score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1010190000 definitions=main-1012160116
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 18:31:22 -0000

On Dec 16, 2010, at 1:20 PM, Matt McCutchen wrote:
> On Thu, 2010-12-16 at 13:12 -0500, Stephen Schultze wrote:
>> On Dec 16, 2010, at 12:38 PM, Matt McCutchen wrote:
>>> On Thu, 2010-12-16 at 10:34 -0500, Steve Schultze wrote:
>>>> On Dec 16, 2010, at 3:48 AM, W.C.A. Wijngaards wrote:
>>>>> On 12/16/2010 05:54 AM, Steve Schultze wrote:
>>>>>> "If the application receives zero usable certificate
>>>>>> associations, it
>>>>>> processes TLS in the normal fashion."
>>>>>
>>>>>> And, as I noted during our session in Beijing, the motivation for
>>>>>> permitting the client to choose is that if we mandate it one
>>>>>> way or
>>>>>> the other, we fall into a trap. If the client MUST process TLS
>>>>>> in
>>>>>> the normal fashion (aka, using PKIX) then we have provided a
>>>>>> solution
>>>>>> that is no better than the status quo. If the client MUST give
>>>>>> an
>>>>>> "access_denied" error, then nobody will use the standard early on
>>>>>> in
>>>>>> deployment because the majority of sites will be unreachable.
>>>>>
>>>>> So, it is possible to say instead:
>>>>>
>>>>> If there are no TLSA records (this is DNSSEC validated by the
>>>>> lookup) or
>>>>> the domain is not signed with DNSSEC (this is signed by the parent
>>>>> domain): process normally (i.e. PKIX). This provides backwards
>>>>> compatibility.
>>>>
>>>> But what if the MITM overrides the genuine DNSSEC-signed record
>>>> with a
>>>> record that is not signed with DNSSEC? Is there some reason why
>>>> this
>>>> is not possible?
>>>
>>> We have been through this already...
>>>
>>> http://www.ietf.org/mail-archive/web/keyassure/current/msg00918.html
>>
>> Yes, but evidently we didn't come to a conclusion. Wouter's proposal
>> (which I take to be "MUST process TLS in the normal fashion") creates
>> the sort of downgrade attack I was describing here and in that
>> thread. The current draft likewise does so:
>>
>> "If the application receives zero usable certificate associations, it
>> processes TLS in the normal fashion."
>>
>> Or am I missing something?
>
> AIUI, that line is within the case in which the DNSSEC query has
> succeeded.

That's not how I read it. All that section says is "In order to use
one or more TLS certificate associations described in this document
obtained from the DNS, an application MUST assure that the
certificates were obtained using DNS protected by DNSSEC." In the
case of no DNSSEC validation, and fallback to standard PKIX, the
client would not be "us[ing] one or more TLS certificate
associations... obtained from the DNS." It would be using the
contents of the cert provided by the TLS handshake.

> That could be clarified by changing the paragraph to:
>
> ---
> An application that performs a successful DNSSEC query for TLS
> certificate associations using the method described in this document
> obtains zero or more usable certificate associations. If the
> application receives zero usable certificate associations, it
> processes
> TLS in the normal fashion.
> ---

But what if the client does not want to fall back on PKIX TLS even if
the site operator has not yet deployed DANE? Should that not be an
option for the client? This would argue for a MAY, rather than the
implied MUST above.

> Or adopting my text from:
>
> http://www.ietf.org/mail-archive/web/keyassure/current/msg00923.html

Yes, I think that this part of your text solves the problem I am
raising:
"Otherwise, if any query gives an "insecure" or "indeterminate"
result, KIDNS cannot be used with this TLS server, and the client MAY
use an alternative certificate validation method."

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FCA83A695C for ; Thu, 16 Dec 2010 10:22:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BpVW73Wq5b0v for ; Thu, 16 Dec 2010 10:22:30 -0800 (PST)
Received: from ppa04.Princeton.EDU (ppa04.Princeton.EDU [128.112.128.215]) by core3.amsl.com (Postfix) with ESMTP id 239AA3A6953 for ; Thu, 16 Dec 2010 10:22:30 -0800 (PST)
Received: from csgsmtp201l.Princeton.EDU (csgsmtp201l.Princeton.EDU [128.112.134.60]) by ppa04.Princeton.EDU (8.14.3/8.14.3) with ESMTP id oBGIOEqx015359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 16 Dec 2010 13:24:14 -0500
Received: from mayflower-ad.Princeton.EDU (mayflower-ad.Princeton.EDU [128.112.224.246]) (authenticated bits=0) by csgsmtp201l.Princeton.EDU (8.13.8/8.12.9) with ESMTP id oBGIOELw004697 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 16 Dec 2010 13:24:14 -0500
Message-Id: <[email-masked]>
From: Stephen Schultze
To: [email-masked]
In-Reply-To:
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Thu, 16 Dec 2010 13:24:14 -0500
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
X-Mailer: Apple Mail (2.936)
X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6198 signatures=655024
X-Proofpoint-Spam-Details: rule=quarantine_notspam policy=quarantine score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1010190000 definitions=main-1012160116
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 18:22:31 -0000

On Dec 16, 2010, at 11:42 AM, Phillip Hallam-Baker wrote:
> One of the reasons that I believe that putting the security
> processing at a trusted resolver (and authenticating the client-
> resolver channel) is superior is that such resolvers can build up
> state across multiple lookups and use that to make better choices.

On Thu, Dec 16, 2010 at 4:52 PM, Steve Schultze
wrote:
> But this assumes:
> - a tremendously more intelligent resolver system than we have today
> - an agreement on the standard for authenticating and encrypting
> the client-resolver channel
> - very different behavior about resolver configuration (sticky
> between locations rather than specified by DHCP) for clients that
> move around
>
> And it introduces a regime in which the ability to securely
> communicate is dependent on a large (and possibly) external entity.
>
> That doesn't seem great to me. I think the issues with client
> management of validation are both easier to solve and more desirable
> as a security regime where control is in the hands of the edges.

On Dec 16, 2010, at 12:32 PM, Phillip Hallam-Baker wrote:
> It exists today, quite a large number of people are using it,
> Comodo, Google and OpenDNS are already offering services that will
> obviously evolve into this model over time.
>
> It is rather closer to the original model of DNS than the change
> necessary to adopt an end to end model.
>
> Having had actual experience of deploying end-to-end 'solutions', I
> am rather less impressed by the concept than I was 20 years ago. In
> my experience they tend to turn out to be impossible to deploy and
> difficult to use.
>
> If you want to solve this corner case you need more information than
> you can reasonably expect to be available at the end point.
>
> We already have a spec for securing the connection. It is currently
> proprietary but we are proposing the successor as an open, non-
> proprietary protocol.

Feel free to publish that standard, and it can potentially be
compatible with the DANE spec's requirement that answers be DNSSEC-
validated. It will always have the disadvantage of requiring end
users to delegate security responsibility to a third party.
Furthermore, for it to have the advantages you described in the case
of non-DNSSEC-validated responses, it will also have to have some
squishy heuristics around when to trust past/alternative results and
the like. Building such indeterminacy into our spec be default
doesn't seem like a path to a strong security protocol, but offering
it as an option to users seems reasonable.

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F82B3A6964 for ; Thu, 16 Dec 2010 10:19:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.305
X-Spam-Level:
X-Spam-Status: No, score=-2.305 tagged_above=-999 required=5 tests=[AWL=0.294, 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 N6dZjcqh+09X for ; Thu, 16 Dec 2010 10:19:07 -0800 (PST)
Received: from homiemail-a38.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by core3.amsl.com (Postfix) with ESMTP id 737C73A695C for ; Thu, 16 Dec 2010 10:19:07 -0800 (PST)
Received: from homiemail-a38.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a38.g.dreamhost.com (Postfix) with ESMTP id AB53B10AFA5; Thu, 16 Dec 2010 10:20:52 -0800 (PST)
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=Ihrs8kBsC4rlpGAeExTrBFM1Qx5oTBMw80n6pOBZsMm dxJFG76wpVVGFR0yKo/gW64FCa0aS4OqrtSnpKrhAceMnqJ+ljSk1UqtSEmkVXbv 5nx3Y6YtPclaQZ0p9I0X+guuJ/eeQb2ak1AzfXrS/ljaJ+67Ic3pOYtRSJjM+2KQ =
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=37CQNY9JsO9AlVDMHsE7TDo77+8=; b=qr39YaHS99 wwcAPJGUNUxdASfR3u/JLWgv5mWsb6ZzCprpDzkSVq1qU88Kh2DhEo/VjOn9ixoX sdeUDz6z3gfVbR1kK5moJ5mcx+Av4NNaVC3lCPJoss4MXjDtifjZbSsQbZAOQhfm YfvJwlbv+VwxPFo2Y+4gF4ImHE2gz8ScY=
Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: [email-masked]) by homiemail-a38.g.dreamhost.com (Postfix) with ESMTPA id 5369610AFA1; Thu, 16 Dec 2010 10:20:52 -0800 (PST)
From: Matt McCutchen
To: Stephen Schultze
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 16 Dec 2010 13:20:51 -0500
Message-ID: <[email-masked]>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.1
Content-Transfer-Encoding: 7bit
Cc: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 18:19:08 -0000

On Thu, 2010-12-16 at 13:12 -0500, Stephen Schultze wrote:
> On Dec 16, 2010, at 12:38 PM, Matt McCutchen wrote:
> > On Thu, 2010-12-16 at 10:34 -0500, Steve Schultze wrote:
> >> On Dec 16, 2010, at 3:48 AM, W.C.A. Wijngaards wrote:
> >>> On 12/16/2010 05:54 AM, Steve Schultze wrote:
> >>>> "If the application receives zero usable certificate
> >>>> associations, it
> >>>> processes TLS in the normal fashion."
> >>>
> >>>> And, as I noted during our session in Beijing, the motivation for
> >>>> permitting the client to choose is that if we mandate it one way or
> >>>> the other, we fall into a trap. If the client MUST process TLS in
> >>>> the normal fashion (aka, using PKIX) then we have provided a
> >>>> solution
> >>>> that is no better than the status quo. If the client MUST give an
> >>>> "access_denied" error, then nobody will use the standard early on
> >>>> in
> >>>> deployment because the majority of sites will be unreachable.
> >>>
> >>> So, it is possible to say instead:
> >>>
> >>> If there are no TLSA records (this is DNSSEC validated by the
> >>> lookup) or
> >>> the domain is not signed with DNSSEC (this is signed by the parent
> >>> domain): process normally (i.e. PKIX). This provides backwards
> >>> compatibility.
> >>
> >> But what if the MITM overrides the genuine DNSSEC-signed record
> >> with a
> >> record that is not signed with DNSSEC? Is there some reason why this
> >> is not possible?
> >
> > We have been through this already...
> >
> > http://www.ietf.org/mail-archive/web/keyassure/current/msg00918.html
>
> Yes, but evidently we didn't come to a conclusion. Wouter's proposal
> (which I take to be "MUST process TLS in the normal fashion") creates
> the sort of downgrade attack I was describing here and in that
> thread. The current draft likewise does so:
>
> "If the application receives zero usable certificate associations, it
> processes TLS in the normal fashion."
>
> Or am I missing something?

AIUI, that line is within the case in which the DNSSEC query has
succeeded. That could be clarified by changing the paragraph to:

---
An application that performs a successful DNSSEC query for TLS
certificate associations using the method described in this document
obtains zero or more usable certificate associations. If the
application receives zero usable certificate associations, it processes
TLS in the normal fashion.
---

Or adopting my text from:

http://www.ietf.org/mail-archive/web/keyassure/current/msg00923.html

--
Matt

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26EBA3A6977 for ; Thu, 16 Dec 2010 10:13:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.278
X-Spam-Level:
X-Spam-Status: No, score=-2.278 tagged_above=-999 required=5 tests=[AWL=0.321, 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 QtDX+iKK-TDB for ; Thu, 16 Dec 2010 10:13:07 -0800 (PST)
Received: from homiemail-a2.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by core3.amsl.com (Postfix) with ESMTP id 3B0723A6939 for ; Thu, 16 Dec 2010 10:13:07 -0800 (PST)
Received: from homiemail-a2.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a2.g.dreamhost.com (Postfix) with ESMTP id 80290280071; Thu, 16 Dec 2010 10:14:52 -0800 (PST)
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=FMVWzVYoy9N53nraf8dS0fXAMAoHr2QnEouyDy1vX1Q 201MDnBGVklfeadjPmyLf96VyGPAwf8EDotlq2cDQ58WN+ejp/VzTm5HHoazNv2p lk2kbyLVyzuwm3IGgzlF+vYU9cZGC1VasHnpSdkx6R8xaUFgHCB6uIYKlIFBz58k =
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=3NthvtSqUz5+j8t91pi0nFdMzS0=; b=NaMOv6cCtx aeR49R+dypsliIIaoklRfQndwFZMoVuHTVVLVg782o5nAXJYlij/EDUzxCJtPSWW KCdFT7ACLeK+Q16gVSAG06YFUDQyoTEwWdsL0+jbXHS1dtpP1Z/yuenPyd26J0h+ qRZ09MZo3VojgT5zyQ0cSRmFIGnp14Zm4=
Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: [email-masked]) by homiemail-a2.g.dreamhost.com (Postfix) with ESMTPA id 3B30C280063; Thu, 16 Dec 2010 10:14:52 -0800 (PST)
From: Matt McCutchen
To: Phillip Hallam-Baker
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 16 Dec 2010 13:14:51 -0500
Message-ID: <[email-masked]>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.1
Content-Transfer-Encoding: 7bit
Cc: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 18:13:08 -0000

On Thu, 2010-12-16 at 17:46 +0000, Phillip Hallam-Baker wrote:
> On Thu, Dec 16, 2010 at 5:31 PM, Paul Wouters
> wrote:
> On Thu, 16 Dec 2010, Phillip Hallam-Baker wrote:
>
> If we have a zone that is unsigned but the key is
> unchanged, the cause is rather more likely to be a
> mistake than an attack.
>
>
> Is it? That's exactly how an attacked DNSSEC stripped zone
> would look like. You can't have protocol guessing at this
> point.
> The admin broke it, and it is broken until they fix it.
>
>
> If the IAB can't keep their zone signed, what hope for the rest?

Did the IAB have trouble keeping their zone signed? I wasn't aware that
they did.

--
Matt

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 749853A691B for ; Thu, 16 Dec 2010 10:10:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QB-eo1g-jvjp for ; Thu, 16 Dec 2010 10:10:45 -0800 (PST)
Received: from ppa02.Princeton.EDU (ppa02.Princeton.EDU [128.112.128.216]) by core3.amsl.com (Postfix) with ESMTP id 79E903A6986 for ; Thu, 16 Dec 2010 10:10:42 -0800 (PST)
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 oBGICRqq003901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 16 Dec 2010 13:12:27 -0500
Received: from mayflower-ad.Princeton.EDU (mayflower-ad.Princeton.EDU [128.112.224.246]) (authenticated bits=0) by csgsmtp201l.Princeton.EDU (8.13.8/8.12.9) with ESMTP id oBGICQOZ030891 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 16 Dec 2010 13:12:27 -0500
Message-Id:
From: Stephen Schultze
To: [email-masked]
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Thu, 16 Dec 2010 13:12:26 -0500
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
X-Mailer: Apple Mail (2.936)
X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6198 signatures=655024
X-Proofpoint-Spam-Details: rule=quarantine_notspam policy=quarantine score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1010190000 definitions=main-1012160116
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 18:10:47 -0000

On Dec 16, 2010, at 12:38 PM, Matt McCutchen wrote:
> On Thu, 2010-12-16 at 10:34 -0500, Steve Schultze wrote:
>> On Dec 16, 2010, at 3:48 AM, W.C.A. Wijngaards wrote:
>>> On 12/16/2010 05:54 AM, Steve Schultze wrote:
>>>> "If the application receives zero usable certificate
>>>> associations, it
>>>> processes TLS in the normal fashion."
>>>
>>>> And, as I noted during our session in Beijing, the motivation for
>>>> permitting the client to choose is that if we mandate it one way or
>>>> the other, we fall into a trap. If the client MUST process TLS in
>>>> the normal fashion (aka, using PKIX) then we have provided a
>>>> solution
>>>> that is no better than the status quo. If the client MUST give an
>>>> "access_denied" error, then nobody will use the standard early on
>>>> in
>>>> deployment because the majority of sites will be unreachable.
>>>
>>> So, it is possible to say instead:
>>>
>>> If there are no TLSA records (this is DNSSEC validated by the
>>> lookup) or
>>> the domain is not signed with DNSSEC (this is signed by the parent
>>> domain): process normally (i.e. PKIX). This provides backwards
>>> compatibility.
>>
>> But what if the MITM overrides the genuine DNSSEC-signed record
>> with a
>> record that is not signed with DNSSEC? Is there some reason why this
>> is not possible?
>
> We have been through this already...
>
> http://www.ietf.org/mail-archive/web/keyassure/current/msg00918.html

Yes, but evidently we didn't come to a conclusion. Wouter's proposal
(which I take to be "MUST process TLS in the normal fashion") creates
the sort of downgrade attack I was describing here and in that
thread. The current draft likewise does so:

"If the application receives zero usable certificate associations, it
processes TLS in the normal fashion."

Or am I missing something?

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E36FD3A693F for ; Thu, 16 Dec 2010 09:45:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.341
X-Spam-Level:
X-Spam-Status: No, score=-3.341 tagged_above=-999 required=5 tests=[AWL=0.257, 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 CrPmkph3HcUq for ; Thu, 16 Dec 2010 09:45:01 -0800 (PST)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id BEC4B3A6970 for ; Thu, 16 Dec 2010 09:45:01 -0800 (PST)
Received: by yxt33 with SMTP id 33so1909439yxt.31 for ; Thu, 16 Dec 2010 09:46:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=cXH1BKmFVWdwouWtk1haoIR4wqpsW8HFiGZJQm5nLUo=; b=ixpD2SlSuQqwqhSB6nIdZk5rrTTKJdVuV9cjTtxXYTpnRyY19rHCUDtP9U6Ah1yX/G Ml9sXv/ulnzx6kQ6j79MSDuY9f1EmnvgWxdxbhYtH8eLOilXIe+gSPC/PHSN1H8zYPOj VlmLVx8SgHxeg9iOfH0iQugIUy4VxIYbxURiw=
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=HytzRHZYefLd7dUMqOVxnWvapqr/EIGY1PMDwq4kzUqfPTPIiuAHxqeN1WfcW56I9n J4Vnn0Gxe6+Ob6DPCdhJWmK4ryeOQnr5Lx1WeNLtHjUb5BKvnga/isrfH3HVE2nFzCTu TvmQkSCxnTTqxrMpkQL9OEoC6VpITRRgMa3UI=
MIME-Version: 1.0
Received: by 10.100.96.1 with SMTP id t1mr5504836anb.137.1292521606609; Thu, 16 Dec 2010 09:46:46 -0800 (PST)
Received: by 10.100.31.8 with HTTP; Thu, 16 Dec 2010 09:46:46 -0800 (PST)
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Thu, 16 Dec 2010 17:46:46 +0000
Message-ID:
From: Phillip Hallam-Baker
To: Paul Wouters
Content-Type: multipart/alternative; boundary=0016e644caf039fd5c04978aa3f9
Cc: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 17:45:03 -0000

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

On Thu, Dec 16, 2010 at 5:31 PM, Paul Wouters wrote:

> On Thu, 16 Dec 2010, Phillip Hallam-Baker wrote:
>
> If we have a zone that is unsigned but the key is unchanged, the cause is
>> rather more likely to be a mistake than an attack.
>>
>
> Is it? That's exactly how an attacked DNSSEC stripped zone would look like.
> You can't have protocol guessing at this point.
> The admin broke it, and it is broken until they fix it.

If the IAB can't keep their zone signed, what hope for the rest?

Real world users tend to be more interested in functionality than some
abstract notion of what you imagine security to be.

Cryptography is the easy part. Working out how to make use of the
information is hard.

In my scheme, I block the Russian Business Network and other criminal
controlled sites. That is what 98% of Internet users consider to meet their
real security needs.

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

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

On Thu, Dec 16, 2010 at 5:31 PM, Paul Wouters <[email-masked]> wrote:
=

On Thu, 16 Dec 2010, Phillip Hallam-Baker wrote:

If we have a zone that is unsigned but the key is unchanged, the cause is r=
ather more likely to be a mistake than an attack.

Is it? That's exactly how an attacked DNSSEC stripped zone would look l=
ike. You can't have protocol guessing at this point.

The admin broke it, and it is broken until they fix it.

If the IAB can't keep their zone signed, what hope for the=
rest?

Real world users tend to be more interested=
in functionality than some abstract notion of what you imagine security to=
be.

Cryptography is the easy part. Working out how to make =
use of the information is hard.

In =
my scheme, I block the Russian Business Network and other criminal controll=
ed sites. That is what 98% of Internet users consider to meet their real se=
curity needs.

=A0

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

--0016e644caf039fd5c04978aa3f9--

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6218E3A692F for ; Thu, 16 Dec 2010 09:36:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.246
X-Spam-Level:
X-Spam-Status: No, score=-2.246 tagged_above=-999 required=5 tests=[AWL=0.353, 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 QqmeIuWh+l1j for ; Thu, 16 Dec 2010 09:36:39 -0800 (PST)
Received: from homiemail-a37.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by core3.amsl.com (Postfix) with ESMTP id 4EE6F3A6928 for ; Thu, 16 Dec 2010 09:36:39 -0800 (PST)
Received: from homiemail-a37.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTP id 859F91D0065; Thu, 16 Dec 2010 09:38:24 -0800 (PST)
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=SC6oy7PmoAJKlM+kPXSPrkWiAE/kROAPx38N31KP62+ 0I8CivZlfTalmTEORUdNUDwh2P3GqJHoagTI1f5oDLQELiJYpDtM3i0o17Xs5u6r ZtxwW3sDeQ7m2N95hCLszAzyn5BjeoZOA/Ge637LtM3/PeCxGGTfkDb9TPSQU6Dg =
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=HXq1StP+51GohtSWCrxM7c/hZoU=; b=Ph50hSfPyy j6apRYcJGYeucSSEVdcYja3lBu44OD2NSBHF0qkP53FfyvIfhARjLCXcmkrqLnLA GuG+GUyngt1Rd+7R8QRjhqikf4NokCe7x9bA4F2EGJ8vC03kz/GwHwiB/BoyLXkR qSOaWlaHABV2Z+AZiEElLdcJf2rTEW/bo=
Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: [email-masked]) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTPA id 252551D0063; Thu, 16 Dec 2010 09:38:24 -0800 (PST)
From: Matt McCutchen
To: Steve Schultze
In-Reply-To: <[email-masked]>
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 16 Dec 2010 12:38:23 -0500
Message-ID: <[email-masked]>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.1
Content-Transfer-Encoding: 7bit
Cc: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 17:36:40 -0000

On Thu, 2010-12-16 at 10:34 -0500, Steve Schultze wrote:
> On Dec 16, 2010, at 3:48 AM, W.C.A. Wijngaards wrote:
> > On 12/16/2010 05:54 AM, Steve Schultze wrote:
> >> "If the application receives zero usable certificate associations, it
> >> processes TLS in the normal fashion."
> >
> >> And, as I noted during our session in Beijing, the motivation for
> >> permitting the client to choose is that if we mandate it one way or
> >> the other, we fall into a trap. If the client MUST process TLS in
> >> the normal fashion (aka, using PKIX) then we have provided a solution
> >> that is no better than the status quo. If the client MUST give an
> >> "access_denied" error, then nobody will use the standard early on in
> >> deployment because the majority of sites will be unreachable.
> >
> > So, it is possible to say instead:
> >
> > If there are no TLSA records (this is DNSSEC validated by the lookup) or
> > the domain is not signed with DNSSEC (this is signed by the parent
> > domain): process normally (i.e. PKIX). This provides backwards
> > compatibility.
>
> But what if the MITM overrides the genuine DNSSEC-signed record with a
> record that is not signed with DNSSEC? Is there some reason why this
> is not possible?

We have been through this already...

http://www.ietf.org/mail-archive/web/keyassure/current/msg00918.html

--
Matt

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33EC13A6986 for ; Thu, 16 Dec 2010 09:31:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.338
X-Spam-Level:
X-Spam-Status: No, score=-3.338 tagged_above=-999 required=5 tests=[AWL=0.260, 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 zuVsBIO8f8A1 for ; Thu, 16 Dec 2010 09:31:12 -0800 (PST)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id B0A3F3A69A1 for ; Thu, 16 Dec 2010 09:31:11 -0800 (PST)
Received: by yxt33 with SMTP id 33so1899466yxt.31 for ; Thu, 16 Dec 2010 09:32:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=T2xtp3zOxOILWCv50243YrYt/rBbrQOCkqTImgJt7cU=; b=JCI+njzHAPjCLdLwGkBCgIPCX39Pp+L62djbd9bpZzWwKcDUQfzgROSzRYViYZ0ra/ TTIk9qp+OfjIBmzAgSUGbho498igOMO6yGqXf1FlNThRTAk8I/CzRQVV5kVMIWDsLXjw l9Y/+TRRtjgTzBtEMDFNnblOKnMCtsRk15DgI=
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=svwNEHCPHRGFXHZUcSdldXlMw9stlcz0+vKOOQps4avSaos8lkuSYOMS/iytIzVBpr anuebOrh5fnOBCOQKrddPwLG3+PoO/q9cTvgqzronM7xpVkfQCnj8Qd/pBZQH6QbichJ xnVKfBuQ5+O1fwhZ/jWzLNzJuzdEaVya28qZw=
MIME-Version: 1.0
Received: by 10.100.195.2 with SMTP id s2mr3237066anf.35.1292520775279; Thu, 16 Dec 2010 09:32:55 -0800 (PST)
Received: by 10.100.31.8 with HTTP; Thu, 16 Dec 2010 09:32:55 -0800 (PST)
In-Reply-To: <[email-masked]>
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Thu, 16 Dec 2010 17:32:55 +0000
Message-ID:
From: Phillip Hallam-Baker
To: Steve Schultze
Content-Type: multipart/alternative; boundary=0016e644ba16ace3b404978a7181
Cc: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 17:31:13 -0000

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

It exists today, quite a large number of people are using it, Comodo, Google
and OpenDNS are already offering services that will obviously evolve into
this model over time.

It is rather closer to the original model of DNS than the change necessary
to adopt an end to end model.

Having had actual experience of deploying end-to-end 'solutions', I am
rather less impressed by the concept than I was 20 years ago. In my
experience they tend to turn out to be impossible to deploy and difficult to
use.

If you want to solve this corner case you need more information than you can
reasonably expect to be available at the end point.

We already have a spec for securing the connection. It is currently
proprietary but we are proposing the successor as an open, non-proprietary
protocol.

On Thu, Dec 16, 2010 at 4:52 PM, Steve Schultze wrote:

> On Dec 16, 2010, at 11:42 AM, Phillip Hallam-Baker wrote:
> > One of the reasons that I believe that putting the security processing at
> a trusted resolver (and authenticating the client-resolver channel) is
> superior is that such resolvers can build up state across multiple lookups
> and use that to make better choices.
>
> But this assumes:
> - a tremendously more intelligent resolver system than we have today
> - an agreement on the standard for authenticating and encrypting the
> client-resolver channel
> - very different behavior about resolver configuration (sticky between
> locations rather than specified by DHCP) for clients that move around
>
> And it introduces a regime in which the ability to securely communicate is
> dependent on a large (and possibly) external entity.
>
> That doesn't seem great to me. I think the issues with client management
> of validation are both easier to solve and more desirable as a security
> regime where control is in the hands of the edges.
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

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

It exists today, quite a large number of people are using it, Comodo, Googl=
e and OpenDNS are already offering services that will obviously evolve into=
this model over time.

It is rather closer to the origin=
al model of DNS than the change necessary to adopt an end to end model.

Having had actual experience of deploying end-to-end &#=
39;solutions', I am rather less impressed by the concept than I was 20 =
years ago. In my experience they tend to turn out to be impossible to deplo=
y and difficult to use.=A0

If you want to solve this corner case you need more inf=
ormation than you can reasonably expect to be available at the end point.=
=A0

We already have a spec for secu=
ring the connection. It is currently proprietary but we are proposing the s=
uccessor as an open, non-proprietary protocol.

On Thu, Dec 16, 2010 at 4:52 PM, St=
eve Schultze <sjs=
@princeton.edu> wrote:

On Dec 16, 2010, at 11:42 AM, Phillip Hallam-Baker wrote:=

> One of the reasons that I believe that putting the security processing=
at a trusted resolver (and authenticating the client-resolver channel) is =
superior is that such resolvers can build up state across multiple lookups =
and use that to make better choices.

But this assumes:

=A0- a tremendously more intelligent resolver system than we have today

=A0- an agreement on the standard for authenticating and encrypting the cli=
ent-resolver channel

=A0- very different behavior about resolver configuration (sticky between l=
ocations rather than specified by DHCP) for clients that move around

And it introduces a regime in which the ability to securely communicate is =
dependent on a large (and possibly) external entity.

That doesn't seem great to me. =A0I think the issues with client manage=
ment of validation are both easier to solve and more desirable as a securit=
y regime where control is in the hands of the edges.

_________________________________________=
______

keyassure mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/keyassure

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

--0016e644ba16ace3b404978a7181--

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C61A3A694F for ; Thu, 16 Dec 2010 09:31:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.207
X-Spam-Level:
X-Spam-Status: No, score=-2.207 tagged_above=-999 required=5 tests=[AWL=0.392, 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 l2sG4XukjiXQ for ; Thu, 16 Dec 2010 09:31:08 -0800 (PST)
Received: from homiemail-a62.g.dreamhost.com (mx1.spunky.mail.dreamhost.com [208.97.132.47]) by core3.amsl.com (Postfix) with ESMTP id A04963A695D for ; Thu, 16 Dec 2010 09:31:08 -0800 (PST)
Received: from homiemail-a62.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTP id A6345634079; Thu, 16 Dec 2010 09:32:53 -0800 (PST)
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=I7S2o/hI5H7IqZs30WFlFQwtPx+qhaNXYUSOHM/zPe6 +YdstHwYNl4QXx0iVlf7rZQn8TaNQG3GZtmvtbbCBxCUnL8SZ0oUFPUWjvWeAcMz 9QciJNanTSBIsFZOsK09rkppMlpWXwJTAWTkdRQKzGEk2Ly/2phz9H6WSu4c6okM =
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=1cvcoxN86N0Xjv/7f+oVnylouY8=; b=IDBBNbxtS+ 2AxRlrB4UZBXoF4M1+gjCyjLC63CFqHgkm7STHG1YtZ5MXz2+OnA5FtAvIZPupLn rzA3Rxs90XyxntHPWktsHZy2A4XT1IteS1U5d0lh20SwRBUzeFVFUrE+b8N/edbV GTFYDNldpBrGt5yPBKTMo+iNL43W26qPI=
Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: [email-masked]) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTPA id 60C1D63406E; Thu, 16 Dec 2010 09:32:53 -0800 (PST)
From: Matt McCutchen
To: Paul Wouters
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]>
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 16 Dec 2010 12:32:52 -0500
Message-ID: <[email-masked]>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.1
Content-Transfer-Encoding: 7bit
Cc: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 17:31:09 -0000

On Thu, 2010-12-16 at 12:25 -0500, Paul Wouters wrote:
> Openswan currently does this with Opportunistic Encryption for IPsec, but
> again in this age, I think we should move towards DNSSEC proof. Not
> only because it is more readilly available, but also because with the
> advent of wireless interceptable communiation, the harm of easy active
> attacks on last mile wifi is significant over the passive eavesdropping
> protection. eg look at firesheep.

That's not the example you want. Firesheep does passive eavesdropping.

--
Matt

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB45C3A698F for ; Thu, 16 Dec 2010 09:29:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.587
X-Spam-Level:
X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 V9ICi2EidBsN for ; Thu, 16 Dec 2010 09:29:16 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id CC24D3A696A for ; Thu, 16 Dec 2010 09:29:15 -0800 (PST)
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 63E5DC4BE; Thu, 16 Dec 2010 12:31:00 -0500 (EST)
Date: Thu, 16 Dec 2010 12:31:00 -0500 (EST)
From: Paul Wouters
To: Phillip Hallam-Baker
In-Reply-To:
Message-ID:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 17:29:16 -0000

On Thu, 16 Dec 2010, Phillip Hallam-Baker wrote:

> If we have a zone that is unsigned but the key is unchanged, the cause is rather more likely to be a mistake than an attack.

Is it? That's exactly how an attacked DNSSEC stripped zone would look like. You can't have protocol guessing at this point.
The admin broke it, and it is broken until they fix it.

> So the
> best course of action is probably to tell the client to use the old values and tell the admin that they seem to have goofed up.
> Hopefully by some automated means.

That is the most dangerous action to take, and would seriously devalue the trust in DNSSEC.

I'm not a browser vendor, or a UI expert, but I think the course of action would be for this to be a fatal error,
and most likely you don't want the user to be able to click "i dont care, continue"

> Alternatively we might end up defining an additional record that the resolver could attach to the response to say 'this is an error,
> but its probably OK because...'

There can never be an unsigned record that says "its ok to ignore DNSSEC". It's the same as me telling your
browser "Its okay to add my CA to your trust pool" without any trust.

Paul

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44E223A697B for ; Thu, 16 Dec 2010 09:29:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.158
X-Spam-Level:
X-Spam-Status: No, score=-2.158 tagged_above=-999 required=5 tests=[AWL=0.441, 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 6S08CKSTr3jM for ; Thu, 16 Dec 2010 09:29:05 -0800 (PST)
Received: from homiemail-a61.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by core3.amsl.com (Postfix) with ESMTP id 3754C3A696A for ; Thu, 16 Dec 2010 09:29:05 -0800 (PST)
Received: from homiemail-a61.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a61.g.dreamhost.com (Postfix) with ESMTP id 68B8257807B; Thu, 16 Dec 2010 09:30:50 -0800 (PST)
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=UpOxnv0DGM2XxWBTk8PwExRJNkXqwhivxw9io171wBu tmPPNfKnoXHuvUycfEyK3njR4djV7lcu6szWiMe0W34Sl+N2Z9SPzJqaqcD+E1fC bC69T8qjt4A4eWsXGROrEOOyPIfvHxqDczMBjocjYgSkFY+hzvFKrzO/vWZq4ieY =
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=gUA7LbFbR616NuihUuFrQYdbDp8=; b=SEKC+jjR7J XcC6Slf/H7l/mWXJ5rJ9lWK+L+JcqIiYRUeA8E/H3v1isyBHaHc9Kf+WZup25c/e PY1vByWGKNbfMPZAXgsLgVusHkHE7g3LXo+CLRoArAMTWsWQTZSnwVaWIdqLT70T VrXKEI059tQy9uvzMPMJ2dCA3x7bfa7DM=
Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: [email-masked]) by homiemail-a61.g.dreamhost.com (Postfix) with ESMTPA id 220B3578073; Thu, 16 Dec 2010 09:30:50 -0800 (PST)
From: Matt McCutchen
To: Steve Schultze
In-Reply-To: <[email-masked]>
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 16 Dec 2010 12:30:48 -0500
Message-ID: <[email-masked]>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.1
Content-Transfer-Encoding: 7bit
Cc: [email-masked]
Subject: Re: [keyassure] Upgrading http URLs using unsecured TLSA data
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 17:29:06 -0000

On Thu, 2010-12-16 at 11:42 -0500, Steve Schultze wrote:
> On Dec 16, 2010, at 11:03 AM, Florian Weimer wrote:
> > In my opinion, we should give up and use TLSA to
> > restrict the set of eligible certificates, and to transparently
> > upgrade insecure protocols to secure ones (e.g., switch to HTTPS from
> > HTTP, but display "http://" in the URL bar, an open padlock icon, and
> > do not transmit secure cookies).
>
> http://www.ietf.org/mail-archive/web/keyassure/current/msg01086.html

No, Florian's proposal was to opportunistically increase the security of
http URLs (against passive attacks), while my objection was to proposals
that decrease the security of https URLs.

That doesn't mean the idea is useful:

- I don't see the benefit of checking an unsecured TLSA record over
accepting any server certificate. An active attacker can fake the TLSA
record, and a passive attacker can't fake the server certificate.

- For encryption without server authentication in general, maybe some
secrets will in fact be transmitted encrypted when they wouldn't be
otherwise, but it's not clear what assurance we could offer the user,
especially as long as non-upgraded http://example.com is in the same
security origin as upgraded http://example.com .

--
Matt

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5941D3A6917; Thu, 16 Dec 2010 09:24:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.586
X-Spam-Level:
X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 K2xuDigHxx9z; Thu, 16 Dec 2010 09:24:03 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id E36713A6920; Thu, 16 Dec 2010 09:24:02 -0800 (PST)
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 80A98C4BE; Thu, 16 Dec 2010 12:25:47 -0500 (EST)
Date: Thu, 16 Dec 2010 12:25:46 -0500 (EST)
From: Paul Wouters
To: Florian Weimer
In-Reply-To: <[email-masked]>
Message-ID:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 17:24:04 -0000

On Thu, 16 Dec 2010, Florian Weimer wrote:

> do not make much sense together. For instance, if you use TLSA to
> limit the circumstances in which certificates validate, it does not
> matter if TLSA was received over DNSSEC or not. This use case is
> still interesting because there is currently no way the owner of
> example.com can stop browser CAs from issuing certificates for
> example.com.

That would allow for active attacks though, by spoofing TSLA records.
I think it is fair to say (in this age with a signed root and DLV) that
if you want to avoid the impact of CA's signing certs of your domains,
you deploy DNSSEC with TLSA. Pointing to a non-existent CA using CAA
might be possible, (or perhaps CAA can define some null-CA) but that
seems like a waste of a few lookups to me that just delay the user.

> I also don't see how browsers can accept DNSSEC-secured certificate
> association in preference of a chain to a root certificate. It's just
> a mess UI-wise. In my opinion, we should give up and use TLSA to
> restrict the set of eligible certificates, and to transparently
> upgrade insecure protocols to secure ones (e.g., switch to HTTPS from
> HTTP, but display "http://" in the URL bar, an open padlock icon, and
> do not transmit secure cookies). Again, this approach case does not
> depend on DNSSEC at all, and it would have a tremendous impact on
> passive eavesdropping.

Openswan currently does this with Opportunistic Encryption for IPsec, but
again in this age, I think we should move towards DNSSEC proof. Not
only because it is more readilly available, but also because with the
advent of wireless interceptable communiation, the harm of easy active
attacks on last mile wifi is significant over the passive eavesdropping
protection. eg look at firesheep.

I would like to have some EDNS method of signaling what kind of additional
records you are interested in (IPSECKEY, TLSA, SSHFP, etc.) but I don't
think I understand yet if this can be done securely. Eg if these are
stripped away, would I need to do the additional query anyway, or can I
get a proof of non-existence added in the additionals that I can decipher.
I don't know, but I would like some mechanism to bring the latency down
on these extra records which are becoming more and more common and essential
(we hope)

Paul

> --
> Florian Weimer
> BFK edv-consulting GmbH http://www.bfk.de/
> Kriegsstra�e 100 tel: +49-721-96201-1
> D-76133 Karlsruhe fax: +49-721-96201-99
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A58123A691F for ; Thu, 16 Dec 2010 09:14:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.585
X-Spam-Level:
X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 8tyEkSiU8dan for ; Thu, 16 Dec 2010 09:14:55 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id C8C763A6912 for ; Thu, 16 Dec 2010 09:14:54 -0800 (PST)
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 1CF2CC436; Thu, 16 Dec 2010 12:16:38 -0500 (EST)
Date: Thu, 16 Dec 2010 12:16:37 -0500 (EST)
From: Paul Wouters
To: Steve Schultze
In-Reply-To: <[email-masked]>
Message-ID:
References: <[email-masked]> <[email-masked]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 8BIT
Cc: [email-masked]
Subject: Re: [keyassure] Hashing certificates vs hashing keys
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 17:14:55 -0000

On Thu, 16 Dec 2010, Steve Schultze wrote:

> label for name constraints) then there seems to be no reason not to do it there. �Indeed, if it turns out that there good reasons to
> stick the hash of the key in DNS instead of the hash of the cert (for example, Adam's reasons), the DNS record is the most secure
> place to put it.
>
> But what about my original question? �What constraints other than domain name constraints do we envision being relevant?

Looking at "constraints" is more the CA/X.509 way. The DNSSEC way is
more binary. It's either OK or not OK to trust and use this.

There is no value judgement on anything else. If you need value judgements
(strength, expiry, proprerties, EV, etc) you end up in CA space. I think
people here mostly want the simple DNSSEC case to work, and trust on CA's
for any extended type of constraints.

The corner case here is if someone wants to use TLSA and perhaps also wants to
use their own CA that's not recognised by browser/software vendors, because
those vendors don't want to seem to vouch for any data from a "rogue" CA.

Paul

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B7E43A696E for ; Thu, 16 Dec 2010 08:52:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wX7sIOX6ciBo for ; Thu, 16 Dec 2010 08:52:47 -0800 (PST)
Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by core3.amsl.com (Postfix) with ESMTP id 4F7F43A6925 for ; Thu, 16 Dec 2010 08:52:47 -0800 (PST)
Received: from albook.hsd1.ca.comcast.net (c-67-164-126-174.hsd1.ca.comcast.net [67.164.126.174]) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id 6A59D36A424; Thu, 16 Dec 2010 08:54:32 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: Nicholas Weaver
In-Reply-To: <[email-masked]>
Date: Thu, 16 Dec 2010 08:54:31 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
To: Steve Schultze
X-Mailer: Apple Mail (2.1082)
Cc: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 16:52:48 -0000

AND don't forget, it relies on the premise of a trusted resolver, when =
we have a large body of evidence that says external resolvers MUST NOT =
BE TRUSTED.

On Dec 16, 2010, at 8:52 AM, Steve Schultze wrote:

> On Dec 16, 2010, at 11:42 AM, Phillip Hallam-Baker wrote:
>> One of the reasons that I believe that putting the security =
processing at a trusted resolver (and authenticating the client-resolver =
channel) is superior is that such resolvers can build up state across =
multiple lookups and use that to make better choices.
>=20
> But this assumes:
> - a tremendously more intelligent resolver system than we have today
> - an agreement on the standard for authenticating and encrypting the =
client-resolver channel
> - very different behavior about resolver configuration (sticky between =
locations rather than specified by DHCP) for clients that move around
>=20
> And it introduces a regime in which the ability to securely =
communicate is dependent on a large (and possibly) external entity.
>=20
> That doesn't seem great to me. I think the issues with client =
management of validation are both easier to solve and more desirable as =
a security regime where control is in the hands of the edges.
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 195AD3A6955 for ; Thu, 16 Dec 2010 08:50:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.932
X-Spam-Level:
X-Spam-Status: No, score=-5.932 tagged_above=-999 required=5 tests=[AWL=0.667, 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 vqb2f1i8u4Rd for ; Thu, 16 Dec 2010 08:50:28 -0800 (PST)
Received: from ppa04.Princeton.EDU (ppa04.Princeton.EDU [128.112.128.215]) by core3.amsl.com (Postfix) with ESMTP id 352073A691B for ; Thu, 16 Dec 2010 08:50:28 -0800 (PST)
Received: from csgsmtp201l.Princeton.EDU (csgsmtp201l.Princeton.EDU [128.112.134.60]) by ppa04.Princeton.EDU (8.14.3/8.14.3) with ESMTP id oBGGqCNb030404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 16 Dec 2010 11:52:12 -0500
Received: from new-host.home (pool-173-71-100-208.cmdnnj.fios.verizon.net [173.71.100.208]) (authenticated bits=0) by csgsmtp201l.Princeton.EDU (8.13.8/8.12.9) with ESMTP id oBGGqB4L019501 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 16 Dec 2010 11:52:12 -0500
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1081)
From: Steve Schultze
In-Reply-To:
Date: Thu, 16 Dec 2010 11:52:11 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <[email-masked]>
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]>
To: [email-masked]
X-Mailer: Apple Mail (2.1081)
X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6198 signatures=655024
X-Proofpoint-Spam-Details: rule=quarantine_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-1010190000 definitions=main-1012160099
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 16:50:29 -0000

On Dec 16, 2010, at 11:42 AM, Phillip Hallam-Baker wrote:
> One of the reasons that I believe that putting the security processing =
at a trusted resolver (and authenticating the client-resolver channel) =
is superior is that such resolvers can build up state across multiple =
lookups and use that to make better choices.

But this assumes:
- a tremendously more intelligent resolver system than we have today
- an agreement on the standard for authenticating and encrypting the =
client-resolver channel
- very different behavior about resolver configuration (sticky between =
locations rather than specified by DHCP) for clients that move around

And it introduces a regime in which the ability to securely communicate =
is dependent on a large (and possibly) external entity.

That doesn't seem great to me. I think the issues with client =
management of validation are both easier to solve and more desirable as =
a security regime where control is in the hands of the edges.=

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3C463A6911 for ; Thu, 16 Dec 2010 08:41:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.334
X-Spam-Level:
X-Spam-Status: No, score=-3.334 tagged_above=-999 required=5 tests=[AWL=0.264, 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 Ue7NrtovCPB4 for ; Thu, 16 Dec 2010 08:41:11 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 1CCC53A6910 for ; Thu, 16 Dec 2010 08:41:11 -0800 (PST)
Received: by ywk9 with SMTP id 9so1860059ywk.31 for ; Thu, 16 Dec 2010 08:42:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=GqQLbSYB3uTCmt4BiCQWshEWOOnHmqdYDdejJkoW284=; b=OmA+DtOSUyW3k0R4z27Gq6/fQxewvK9OpMb6CALdYIA5JYuqkJ8QpuxXE1pmAPVTfy N++u1AF/tbO9yeXWzyWqt0pXGjZjoKtzCvcA0ssNxhAO7G7fUqQFdDFYhP2ShjI0fGIz yYm+Vq2F5Fv5rBlB6RynYCSRgczrdxKF7qTzE=
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=U8M8KQgpabs6abLB2KDvwb9YK1jkpBgxWjWLez037YdU57m6F/yE7WZmpxUW1jsLRG TQ6wPo6YnjSxpM8jvTbwQBCBlO9SSU9IVlSP3s2z68zzexzP2hBLfefzCoJMl9vCqHY8 eq3YmXUf74JT94Mj2bY3JGaaqaHAinwMtScTg=
MIME-Version: 1.0
Received: by 10.100.110.16 with SMTP id i16mr1430669anc.103.1292517775926; Thu, 16 Dec 2010 08:42:55 -0800 (PST)
Received: by 10.100.31.8 with HTTP; Thu, 16 Dec 2010 08:42:55 -0800 (PST)
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Thu, 16 Dec 2010 16:42:55 +0000
Message-ID:
From: Phillip Hallam-Baker
To: Steve Schultze
Content-Type: multipart/alternative; boundary=0016e645ab9ae6658a049789bea8
Cc: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 16:41:12 -0000

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

These traps are real, but the reason they are difficult to address is that
there is too little information provided in one individual response to make
the ideal choice.

One of the reasons that I believe that putting the security processing at a
trusted resolver (and authenticating the client-resolver channel) is
superior is that such resolvers can build up state across multiple lookups
and use that to make better choices.

For example, consider the range of circumstances that can give rise to an
absent signature:-

1) Man in the middle attack
2) Cache poisoning against non-validating resolver
3) Administrator mistake

A trusted and trustworthy resolver can eliminate the first two attack
vectors. If the signature is invalid then a large scale resolver can make a
query from a different source point. Such a resolver is going to be
validating so cache poisoning can be eliminated.

The risk in doing so is that the resolver will react in the same way to
'attacks' and 'mistakes'. To avoid this the resolver can look at the
previous config details and look to see what has changed.

If we have a zone that is unsigned but the key is unchanged, the cause is
rather more likely to be a mistake than an attack. So the best course of
action is probably to tell the client to use the old values and tell the
admin that they seem to have goofed up. Hopefully by some automated means.

Alternatively we might end up defining an additional record that the
resolver could attach to the response to say 'this is an error, but its
probably OK because...'

Of course, if anyone starts to use these mechanisms on an extended scale
there is a risk that it becomes impossible to rely on implicit revocation by
simply delisting the key. And we might have to start thinking about explicit
revocation list processing.

On Thu, Dec 16, 2010 at 3:50 PM, Steve Schultze wrote:

> On Dec 16, 2010, at 10:45 AM, Ben Laurie wrote:
> > On 16 December 2010 15:34, Steve Schultze wrote:
> >> On Dec 16, 2010, at 3:48 AM, W.C.A. Wijngaards wrote:
> >>> On 12/16/2010 05:54 AM, Steve Schultze wrote:
> >>>> "If the application receives zero usable certificate associations, it
> >>>> processes TLS in the normal fashion."
> >>>
> >>>> And, as I noted during our session in Beijing, the motivation for
> >>>> permitting the client to choose is that if we mandate it one way or
> >>>> the other, we fall into a trap. If the client MUST process TLS in
> >>>> the normal fashion (aka, using PKIX) then we have provided a solution
> >>>> that is no better than the status quo. If the client MUST give an
> >>>> "access_denied" error, then nobody will use the standard early on in
> >>>> deployment because the majority of sites will be unreachable.
> >>>
> >>> So, it is possible to say instead:
> >>>
> >>> If there are no TLSA records (this is DNSSEC validated by the lookup)
> or
> >>> the domain is not signed with DNSSEC (this is signed by the parent
> >>> domain): process normally (i.e. PKIX). This provides backwards
> >>> compatibility.
> >>
> >> But what if the MITM overrides the genuine DNSSEC-signed record with a
> record that is not signed with DNSSEC? Is there some reason why this is not
> possible?
> >
> > Sure it's possible - and then the result is not DNSSEC-signed, and so
> > should be ignored.
>
> But what does "ignored" mean? Does it mean the client must give an
> "access_denied" error? If so, you fall into the second of my two traps.
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

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

These traps are real, but the reason they are difficult to address is that =
there is too little information provided in one individual response to make=
the ideal choice.

One of the reasons that I believe tha=
t putting the security processing at a trusted resolver (and authenticating=
the client-resolver channel) is superior is that such resolvers can build =
up state across multiple lookups and use that to make better choices.

For example, consider the range of circumstances that c=
an give rise to an absent signature:-

1) Man in th=
e middle attack

2) Cache poisoning against non-validating resolve=
r

3) Administrator mistake

A trusted and trustw=
orthy resolver can eliminate the first two attack vectors. If the signature=
is invalid then a large scale resolver can make a query from a different s=
ource point. Such a resolver is going to be validating so cache poisoning c=
an be eliminated.

The risk in doing so is that the resolver will react in=
the same way to 'attacks' and 'mistakes'. To avoid this th=
e resolver can look at the previous config details and look to see what has=
changed.=A0

If we have a zone that is unsigned but the key is uncha=
nged, the cause is rather more likely to be a mistake than an attack. So th=
e best course of action is probably to tell the client to use the old value=
s and tell the admin that they seem to have goofed up. Hopefully by some au=
tomated means.

Alternatively we might end up defining an additional re=
cord that the resolver could attach to the response to say 'this is an =
error, but its probably OK because...'

Of course, if anyone starts to use these mechanisms on an extend=
ed scale there is a risk that it becomes impossible to rely on implicit rev=
ocation by simply delisting the key. And we might have to start thinking ab=
out explicit revocation list processing.

On Thu, Dec 16, 2010=
at 3:50 PM, Steve Schultze <[email-masked]> wrote:

On Dec 16, 2010, at 10:45 AM, Ben Laurie =
wrote:

> On 16 December 2010 15:34, Steve Schultze <[email-masked]> wrote:

>> On Dec 16, 2010, at 3:48 AM, W.C.A. Wijngaards wrote:

>>> On 12/16/2010 05:54 AM, Steve Schultze wrote:

>>>> "If the application receives zero usable certificate =
associations, it

>>>> processes TLS in the normal fashion."

>>>

>>>> And, as I noted during our session in Beijing, the motivat=
ion for

>>>> permitting the client to choose is that if we mandate it o=
ne way or

>>>> the other, we fall into a trap. =A0If the client MUST proc=
ess TLS in

>>>> the normal fashion (aka, using PKIX) then we have provided=
a solution

>>>> that is no better than the status quo. =A0If the client MU=
ST give an

>>>> "access_denied" error, then nobody will use the =
standard early on in

>>>> deployment because the majority of sites will be unreachab=
le.

>>>

>>> So, it is possible to say instead:

>>>

>>> If there are no TLSA records (this is DNSSEC validated by the =
lookup) or

>>> the domain is not signed with DNSSEC (this is signed by the pa=
rent

>>> domain): process normally (i.e. PKIX). =A0This provides backwa=
rds

>>> compatibility.

>>

>> But what if the MITM overrides the genuine DNSSEC-signed record wi=
th a record that is not signed with DNSSEC? =A0Is there some reason why thi=
s is not possible?

>

> Sure it's possible - and then the result is not DNSSEC-signed, and=
so

> should be ignored.

But what does "ignored" mean? =A0Does it mean the cli=
ent must give an "access_denied" error? =A0If so, you fall into t=
he second of my two traps.

_________________________________________=
______

keyassure mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/keyassure

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

--0016e645ab9ae6658a049789bea8--

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48F493A6911 for ; Thu, 16 Dec 2010 08:40:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.799
X-Spam-Level:
X-Spam-Status: No, score=-5.799 tagged_above=-999 required=5 tests=[AWL=0.800, 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 xvlCwkA0Hydt for ; Thu, 16 Dec 2010 08:40:34 -0800 (PST)
Received: from ppa03.princeton.edu (ppa03.Princeton.EDU [128.112.128.214]) by core3.amsl.com (Postfix) with ESMTP id B518C3A6910 for ; Thu, 16 Dec 2010 08:40:34 -0800 (PST)
Received: from csgsmtp200l.Princeton.EDU (csgsmtp200l.Princeton.EDU [128.112.130.131]) by ppa03.princeton.edu (8.14.3/8.14.3) with ESMTP id oBGGgIQn014759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 16 Dec 2010 11:42:18 -0500
Received: from new-host.home (pool-173-71-100-208.cmdnnj.fios.verizon.net [173.71.100.208]) (authenticated bits=0) by csgsmtp200l.Princeton.EDU (8.13.8/8.12.9) with ESMTP id oBGGgION029828 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 16 Dec 2010 11:42:18 -0500
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1081)
From: Steve Schultze
In-Reply-To: <[email-masked]>
Date: Thu, 16 Dec 2010 11:42:17 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <[email-masked]>
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]>
To: [email-masked]
X-Mailer: Apple Mail (2.1081)
X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6198 signatures=655024
X-Proofpoint-Spam-Details: rule=quarantine_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-1010190000 definitions=main-1012160099
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 16:40:36 -0000

On Dec 16, 2010, at 11:03 AM, Florian Weimer wrote:
> For instance, if you use TLSA to
> limit the circumstances in which certificates validate, it does not
> matter if TLSA was received over DNSSEC or not.=20

How, other than DNSSEC validation, would you receive a TLSA record that =
you would trust?

> I also don't see how browsers can accept DNSSEC-secured certificate
> association in preference of a chain to a root certificate.

You mean a PKIX-provided root certificate?

> It's just a mess UI-wise. =20

I disagree. If we give the user the option up-front about how to =
configure their trust, then there is no need to change the rest of the =
UI at all. However, the UI *could* be altered to show TLSA-validated =
sites as "more special" somehow if this was seen as valuable and doable.

> In my opinion, we should give up and use TLSA to
> restrict the set of eligible certificates, and to transparently
> upgrade insecure protocols to secure ones (e.g., switch to HTTPS from
> HTTP, but display "http://" in the URL bar, an open padlock icon, and
> do not transmit secure cookies).

http://www.ietf.org/mail-archive/web/keyassure/current/msg01086.html

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 682A03A68FC for ; Thu, 16 Dec 2010 08:16:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.099
X-Spam-Level:
X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[AWL=-1.501, 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 DIYgyCzqr1TZ for ; Thu, 16 Dec 2010 08:16:36 -0800 (PST)
Received: from ppa01.Princeton.EDU (ppa01.Princeton.EDU [128.112.128.213]) by core3.amsl.com (Postfix) with ESMTP id A325A3A6860 for ; Thu, 16 Dec 2010 08:16:36 -0800 (PST)
Received: from csgsmtp200l.Princeton.EDU (csgsmtp200l.Princeton.EDU [128.112.130.131]) by ppa01.Princeton.EDU (8.14.3/8.14.3) with ESMTP id oBGGIL3U021742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 16 Dec 2010 11:18:21 -0500
Received: from new-host.home (pool-173-71-100-208.cmdnnj.fios.verizon.net [173.71.100.208]) (authenticated bits=0) by csgsmtp200l.Princeton.EDU (8.13.8/8.12.9) with ESMTP id oBGGIKuu014602 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 16 Dec 2010 11:18:21 -0500
From: Steve Schultze
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/alternative; boundary=Apple-Mail-8-676487781
Date: Thu, 16 Dec 2010 11:18:20 -0500
In-Reply-To:
To: [email-masked]
References: <[email-masked]>
Message-Id: <[email-masked]>
X-Mailer: Apple Mail (2.1081)
X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6198 signatures=655024
X-Proofpoint-Spam-Details: rule=quarantine_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-1010190000 definitions=main-1012160093
Subject: Re: [keyassure] Hashing certificates vs hashing keys
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 16:16:38 -0000

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

The question is not either-or, it is how. If it can be done well within =
the DNS record itself (for example, as it is done via the DNS label for =
name constraints) then there seems to be no reason not to do it there. =
Indeed, if it turns out that there good reasons to stick the hash of the =
key in DNS instead of the hash of the cert (for example, Adam's =
reasons), the DNS record is the most secure place to put it.

But what about my original question? What constraints other than domain =
name constraints do we envision being relevant?

On Dec 16, 2010, at 12:57 AM, Phillip Hallam-Baker wrote:
> Well the draft is wrong then.
>=20
> These certs are signed under the DNSSEC trust path, they are not =
equivalent to a self-signed cert.
>=20
> Limitations on the use of a cert have always been valid when using =
self-signed certs.
>=20
>=20
> On Thu, Dec 16, 2010 at 5:00 AM, Steve Schultze =
wrote:
> I wanted to highlight the following set of comments and flag a =
potential issue:
>=20
> Phillip said:
> > But the attributes in the EE cert are still important. for example, =
critical flagged attributes.
>=20
> The current draft says:
> "All data in a self-signed certificate other than the key itself can =
be ignored as untrusted unless a client validates the self-signed =
certificate to a trust anchor that is identical to the certificate."
>=20
> Then Jim Schaad said:
> > Hashing just the public key does not fix the problem if you care =
about
> > statements being made in the certificate besides just the key. I.e. =
name
> > constraints and so forth.
>=20
> And Paul W said:
> > You don't. The name constrains are in the DNS label.
>=20
> If we are sticking with the language in the draft (which I think we =
should), and anybody can suggest other constraints or attributes that =
might be necessary, we need to consider them as we work on the structure =
of the RR. If we don't think that we can predict all future =
constraints/attributes, then we need some flexible way of specifying =
them. This might lead down the path of (gasp) the Kaminsky =
TXT-record-with-key-value-pairs approach:
> http://dankaminsky.com/2010/12/14/dnssec-ch2/
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>=20
>=20
>=20
> --=20
> Website: http://hallambaker.com/
>=20

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

Well the draft is =
wrong then.

These certs are signed under the DNSSEC =
trust path, they are not equivalent to a self-signed =
cert.

Limitations on the use of a cert have =
always been valid when using self-signed certs.

On Thu, Dec 16, 2010 at 5:00 AM, =
Steve Schultze <[email-masked]> =
wrote:

I wanted to highlight the following set of comments and flag a potential =
issue:

Phillip said:

> But the attributes in the EE cert are still important. for example, =
critical flagged attributes.

The current draft says:

"All data in a self-signed certificate other than the key itself can be =
ignored as untrusted unless a client validates the self-signed =
certificate to a trust anchor that is identical to the certificate."

Then Jim Schaad said:

> Hashing just the public key does not fix the problem if you care =
about

> statements being made in the certificate besides just the key. =
I.e. name

> constraints and so forth.

And Paul W said:

> You don't. The name constrains are in the DNS label.

If we are sticking with the language in the draft (which I think =
we should), and anybody can suggest other constraints or attributes that =
might be necessary, we need to consider them as we work on the structure =
of the RR.  If we don't think that we can predict all future =
constraints/attributes, then we need some flexible way of specifying =
them.  This might lead down the path of (gasp) the Kaminsky =
TXT-record-with-key-value-pairs approach:

http://dankaminsky.com/2010/12/14/dnssec-ch2/

_______________________________________________

keyassure mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/keyassure

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

=

--Apple-Mail-8-676487781--

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A9743A68A8; Thu, 16 Dec 2010 08:02:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.067
X-Spam-Level:
X-Spam-Status: No, score=-2.067 tagged_above=-999 required=5 tests=[AWL=0.182, 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 jmeHml45Lcjk; Thu, 16 Dec 2010 08:02:06 -0800 (PST)
Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id 08A253A67EB; Thu, 16 Dec 2010 08:02:06 -0800 (PST)
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 1PTGJ4-0008Sr-MR; Thu, 16 Dec 2010 16:03:50 +0000
Received: by bfk.de with local id 1PTGJ4-0007JL-Gy; Thu, 16 Dec 2010 16:03:50 +0000
To: [email-masked]
References: <20101213220001.24500.52050.idtracker@localhost>
From: Florian Weimer
Date: Thu, 16 Dec 2010 16:03:50 +0000
In-Reply-To: <20101213220001.24500.52050.idtracker@localhost> ([email-masked]'s message of "Mon\, 13 Dec 2010 14\:00\:01 -0800")
Message-ID: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 16:02:07 -0000

> Title : Using Secure DNS to Associate Certificates with Domain=
Names For TLS
> Author(s) : P. Hoffman, J. Schlyter
> Filename : draft-ietf-dane-protocol-00.txt
> Pages : 9
> Date : 2010-12-12

I think that this

In order to use one or more TLS certificate associations described in
this document obtained from the DNS, an application MUST assure that
the certificates were obtained using DNS protected by DNSSEC.

and this

TLS client policy is deliberately not prescribed by this
specification. A client MAY choose to trust a DNSSEC-secured
certificate association, depending on its local policy.

do not make much sense together. For instance, if you use TLSA to
limit the circumstances in which certificates validate, it does not
matter if TLSA was received over DNSSEC or not. This use case is
still interesting because there is currently no way the owner of
example.com can stop browser CAs from issuing certificates for
example.com.

I also don't see how browsers can accept DNSSEC-secured certificate
association in preference of a chain to a root certificate. It's just
a mess UI-wise. In my opinion, we should give up and use TLSA to
restrict the set of eligible certificates, and to transparently
upgrade insecure protocols to secure ones (e.g., switch to HTTPS from
HTTP, but display "http://" in the URL bar, an open padlock icon, and
do not transmit secure cookies). Again, this approach case does not
depend on DNSSEC at all, and it would have a tremendous impact on
passive eavesdropping.

--=20
Florian Weimer
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstra=DFe 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AF703A68DF for ; Thu, 16 Dec 2010 07:48:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.932
X-Spam-Level:
X-Spam-Status: No, score=-5.932 tagged_above=-999 required=5 tests=[AWL=0.667, 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 Uaajwa2U7W8N for ; Thu, 16 Dec 2010 07:48:55 -0800 (PST)
Received: from ppa04.Princeton.EDU (ppa04.Princeton.EDU [128.112.128.215]) by core3.amsl.com (Postfix) with ESMTP id 8C7EC3A68DC for ; Thu, 16 Dec 2010 07:48:55 -0800 (PST)
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 oBGFoemx005782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 16 Dec 2010 10:50:40 -0500
Received: from new-host.home (pool-173-71-100-208.cmdnnj.fios.verizon.net [173.71.100.208]) (authenticated bits=0) by csgsmtp200l.Princeton.EDU (8.13.8/8.12.9) with ESMTP id oBGFodXc029352 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 16 Dec 2010 10:50:39 -0500
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1081)
From: Steve Schultze
In-Reply-To:
Date: Thu, 16 Dec 2010 10:50:39 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]>
To: [email-masked]
X-Mailer: Apple Mail (2.1081)
X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6198 signatures=655024
X-Proofpoint-Spam-Details: rule=quarantine_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-1010190000 definitions=main-1012160086
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 15:48:56 -0000

On Dec 16, 2010, at 10:45 AM, Ben Laurie wrote:
> On 16 December 2010 15:34, Steve Schultze wrote:
>> On Dec 16, 2010, at 3:48 AM, W.C.A. Wijngaards wrote:
>>> On 12/16/2010 05:54 AM, Steve Schultze wrote:
>>>> "If the application receives zero usable certificate associations, =
it
>>>> processes TLS in the normal fashion."
>>>=20
>>>> And, as I noted during our session in Beijing, the motivation for
>>>> permitting the client to choose is that if we mandate it one way or
>>>> the other, we fall into a trap. If the client MUST process TLS in
>>>> the normal fashion (aka, using PKIX) then we have provided a =
solution
>>>> that is no better than the status quo. If the client MUST give an
>>>> "access_denied" error, then nobody will use the standard early on =
in
>>>> deployment because the majority of sites will be unreachable.
>>>=20
>>> So, it is possible to say instead:
>>>=20
>>> If there are no TLSA records (this is DNSSEC validated by the =
lookup) or
>>> the domain is not signed with DNSSEC (this is signed by the parent
>>> domain): process normally (i.e. PKIX). This provides backwards
>>> compatibility.
>>=20
>> But what if the MITM overrides the genuine DNSSEC-signed record with =
a record that is not signed with DNSSEC? Is there some reason why this =
is not possible?
>=20
> Sure it's possible - and then the result is not DNSSEC-signed, and so
> should be ignored.

But what does "ignored" mean? Does it mean the client must give an =
"access_denied" error? If so, you fall into the second of my two traps.=

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D40E3A68E5 for ; Thu, 16 Dec 2010 07:43:58 -0800 (PST)
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 apKaeT6d+Gde for ; Thu, 16 Dec 2010 07:43:57 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 784E13A68E8 for ; Thu, 16 Dec 2010 07:43:57 -0800 (PST)
Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id oBGFjgGh021404 for ; Thu, 16 Dec 2010 07:45:42 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1292514342; bh=yTZn/3qA6QSk+5Tpp7/ybH3xCeY=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=Hq8wzPDOzzEtaSv+GB8qgAz1oA2O9l6pC8vWn+9NBdZM4pqgk9ya52787pUcW8YOp d4WWZpOBu7KK0hG5liAiw==
Received: from qyk29 (qyk29.prod.google.com [10.241.83.157]) by wpaz33.hot.corp.google.com with ESMTP id oBGFiwnP002276 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 16 Dec 2010 07:45:41 -0800
Received: by qyk29 with SMTP id 29so3296690qyk.18 for ; Thu, 16 Dec 2010 07:45:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Jw8rjI1HKZBvDBbjF2RR/7CYxm3oLVA3nym5w8z4j1Y=; b=GaQ+AHY+bCNKJ8h/ZQtwcSWCb22Jbvli0U1Zrrfyu9t3y5DnyOzWz3OC/2qD8JJI3w lP0gmKfJBf/47fGn4U/A==
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=so27yV/tjTkFg3hE4xxbtPCYGC/MvuCrBVR2qwpMGv37aZtaQSx7Grq5MHpSUD1tmd p2wAR5thbem/bxy9jT7g==
MIME-Version: 1.0
Received: by 10.224.11.12 with SMTP id r12mr7499686qar.288.1292514340923; Thu, 16 Dec 2010 07:45:40 -0800 (PST)
Received: by 10.220.126.219 with HTTP; Thu, 16 Dec 2010 07:45:40 -0800 (PST)
In-Reply-To: <[email-masked]>
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Thu, 16 Dec 2010 15:45:40 +0000
Message-ID:
From: Ben Laurie
To: Steve Schultze
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
Cc: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 15:43:58 -0000

On 16 December 2010 15:34, Steve Schultze wrote:
> On Dec 16, 2010, at 3:48 AM, W.C.A. Wijngaards wrote:
>> On 12/16/2010 05:54 AM, Steve Schultze wrote:
>>> "If the application receives zero usable certificate associations, it
>>> processes TLS in the normal fashion."
>>
>>> And, as I noted during our session in Beijing, the motivation for
>>> permitting the client to choose is that if we mandate it one way or
>>> the other, we fall into a trap. =A0If the client MUST process TLS in
>>> the normal fashion (aka, using PKIX) then we have provided a solution
>>> that is no better than the status quo. =A0If the client MUST give an
>>> "access_denied" error, then nobody will use the standard early on in
>>> deployment because the majority of sites will be unreachable.
>>
>> So, it is possible to say instead:
>>
>> If there are no TLSA records (this is DNSSEC validated by the lookup) or
>> the domain is not signed with DNSSEC (this is signed by the parent
>> domain): process normally (i.e. PKIX). =A0This provides backwards
>> compatibility.
>
> But what if the MITM overrides the genuine DNSSEC-signed record with a re=
cord that is not signed with DNSSEC? =A0Is there some reason why this is no=
t possible?

Sure it's possible - and then the result is not DNSSEC-signed, and so
should be ignored.

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21D943A68E7 for ; Thu, 16 Dec 2010 07:32:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.599
X-Spam-Level:
X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.000, 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 RXV5a22lEB9q for ; Thu, 16 Dec 2010 07:32:57 -0800 (PST)
Received: from ppa04.Princeton.EDU (ppa04.Princeton.EDU [128.112.128.215]) by core3.amsl.com (Postfix) with ESMTP id 33BF83A68DC for ; Thu, 16 Dec 2010 07:32:57 -0800 (PST)
Received: from csgsmtp201l.Princeton.EDU (csgsmtp201l.Princeton.EDU [128.112.134.60]) by ppa04.Princeton.EDU (8.14.3/8.14.3) with ESMTP id oBGFYf7Z023838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 16 Dec 2010 10:34:41 -0500
Received: from new-host.home (pool-173-71-100-208.cmdnnj.fios.verizon.net [173.71.100.208]) (authenticated bits=0) by csgsmtp201l.Princeton.EDU (8.13.8/8.12.9) with ESMTP id oBGFYfqF002760 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 16 Dec 2010 10:34:41 -0500
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1081)
From: Steve Schultze
In-Reply-To: <[email-masked]>
Date: Thu, 16 Dec 2010 10:34:40 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <[email-masked]>
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]>
To: [email-masked]
X-Mailer: Apple Mail (2.1081)
X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6198 signatures=655024
X-Proofpoint-Spam-Details: rule=quarantine_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-1010190000 definitions=main-1012160083
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 15:32:58 -0000

On Dec 16, 2010, at 3:48 AM, W.C.A. Wijngaards wrote:
> On 12/16/2010 05:54 AM, Steve Schultze wrote:
>> "If the application receives zero usable certificate associations, it
>> processes TLS in the normal fashion."
>=20
>> And, as I noted during our session in Beijing, the motivation for
>> permitting the client to choose is that if we mandate it one way or
>> the other, we fall into a trap. If the client MUST process TLS in
>> the normal fashion (aka, using PKIX) then we have provided a solution
>> that is no better than the status quo. If the client MUST give an
>> "access_denied" error, then nobody will use the standard early on in
>> deployment because the majority of sites will be unreachable.=20
>=20
> So, it is possible to say instead:
>=20
> If there are no TLSA records (this is DNSSEC validated by the lookup) =
or
> the domain is not signed with DNSSEC (this is signed by the parent
> domain): process normally (i.e. PKIX). This provides backwards
> compatibility.

But what if the MITM overrides the genuine DNSSEC-signed record with a =
record that is not signed with DNSSEC? Is there some reason why this is =
not possible?=

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02A5B3A6875 for ; Thu, 16 Dec 2010 07:05:57 -0800 (PST)
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 QpJbBaf3ak4o for ; Thu, 16 Dec 2010 07:05:56 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id BD5413A6877 for ; Thu, 16 Dec 2010 07:05:56 -0800 (PST)
Received: from hpaq11.eem.corp.google.com (hpaq11.eem.corp.google.com [172.25.149.11]) by smtp-out.google.com with ESMTP id oBGF7ffh015330 for ; Thu, 16 Dec 2010 07:07:41 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1292512061; bh=4gBTEtJztDnxOEuZVcGoyZXx/TQ=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=vT2fDmmc6W3IlcWeZVVsBRN7GNtfHfOfl1Sfk2plrLODmScJ9AKZYCiWIhH9ogd9d TKcuNw71SXTlybKpEI7lg==
Received: from qyj19 (qyj19.prod.google.com [10.241.83.83]) by hpaq11.eem.corp.google.com with ESMTP id oBGF7cuT011812 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 16 Dec 2010 07:07:39 -0800
Received: by qyj19 with SMTP id 19so3344092qyj.10 for ; Thu, 16 Dec 2010 07:07:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=552dl+J69S5aT30J7R/sS3CZQ6EDKXoE4vx9uVpHheo=; b=uLqKumHu59zUSAtwDUXRt4TkLFjRv+7LenFq51CjVvdiOXoHGLNOEKNomIkb8pq/mN DwFiSkN2gVN+K5JF/K4g==
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=J5QzRQZAcFGIHqa63z58cjsuhr0xKJACsZZsutblaMIOE2kTmQ6W2I8rEMukMXLbaR 84l0i4geJSLi5/NXZkiw==
MIME-Version: 1.0
Received: by 10.224.11.12 with SMTP id r12mr7471165qar.288.1292512058430; Thu, 16 Dec 2010 07:07:38 -0800 (PST)
Received: by 10.220.126.219 with HTTP; Thu, 16 Dec 2010 07:07:38 -0800 (PST)
In-Reply-To: <20101213220001.24500.52050.idtracker@localhost>
References: <20101213220001.24500.52050.idtracker@localhost>
Date: Thu, 16 Dec 2010 15:07:38 +0000
Message-ID:
From: Ben Laurie
To: [email-masked]
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 15:05:57 -0000

Looking good. Some comments:

* You don't describe the presentation format

* I don't like "A variable-length set of bytes containing the
certificate or the hash", it makes me wonder how the length is
encoded. Perhaps just "The bytes of the certificate or hash"?

* MD5 should be deprecated.

* "The certificate association is valid if the first certificate in
the certificate bundle can be validly chained to the certificate from
the TLSA data" is theoretically putting a high demand on the client
(where do the certs come from that might chain?). Should say "using
certificates in the bundle"?

* 3.1 confuses me. It seems to say that 3 isn't really there.

* 3.1.1 I don't understand what this means - surely you should process
the cert to ensure it is valid? How can you even use a cert in a
handshake without processing it?

* 3.1.2 should probably be titled "Ignorning Host Names in Self-Signed
Certificates" or be numbered 3.1.1.1.

* 3.1.2 might perhaps usefully refer to virtual hosting, and also
possible relationship with the SNI TLS extension.

* 3.1.4 should probably say "as well as performing TLSA validation".

* 5 - perhaps mention that a rogue domain admin can probably get a
cert issued anyway, so this is not an additional threat.

* "an man-in-the-middle" -> "a man-in-the-middle".

* as someone already mentioned, need to specify what happens when
invalid records are seen.

Cheers,

Ben.

On 13 December 2010 22:00, wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
> This draft is a work item of the DNS-based Authentication of Named Entiti=
es Working Group of the IETF.
>
>
> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Using Secure DNS to Associate =
Certificates with Domain Names For TLS
> =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : P. Hoffman, J. Schlyter
> =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-dane-protocol-00.txt
> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 9
> =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2010-12-12
>
> TLS and DTLS use certificates for authenticating the server. =A0Users
> want their applications to verify that the certificate provided by
> the TLS server is in fact associated with the domain name they
> expect. =A0Instead 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. =A0This document describes how to use secure DNS to
> associate the TLS server's certificate with the the intended domain
> name.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-dane-protocol-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.
>
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>
>

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F001E3A70A5 for ; Thu, 16 Dec 2010 00:46:38 -0800 (PST)
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.030, 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 7LPS9AshGvKv for ; Thu, 16 Dec 2010 00:46:37 -0800 (PST)
Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by core3.amsl.com (Postfix) with ESMTP id 693623A70A0 for ; Thu, 16 Dec 2010 00:46:37 -0800 (PST)
Received: from gary.nlnetlabs.nl (gary.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:1853]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id oBG8mJbr030200 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 16 Dec 2010 09:48:19 +0100 (CET) (envelope-from [email-masked])
Message-ID: <[email-masked]>
Date: Thu, 16 Dec 2010 09:48:19 +0100
From: "W.C.A. Wijngaards"
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc13 Lightning/1.0b3pre Thunderbird/3.1.7
MIME-Version: 1.0
To: [email-masked]
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]>
In-Reply-To: <[email-masked]>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Thu, 16 Dec 2010 09:48:19 +0100 (CET)
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 08:46:39 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Steve,

It is possible with DNSSEC to distinguish between a failure to lookup
and receiving zero TLSA records DNSSEC secured. It is also possible to
securely determine if a domain is signed or insecure.

On 12/16/2010 05:54 AM, Steve Schultze wrote:
> "If the application receives zero usable certificate associations, it
> processes TLS in the normal fashion."

> And, as I noted during our session in Beijing, the motivation for
> permitting the client to choose is that if we mandate it one way or
> the other, we fall into a trap. If the client MUST process TLS in
> the normal fashion (aka, using PKIX) then we have provided a solution
> that is no better than the status quo. If the client MUST give an
> "access_denied" error, then nobody will use the standard early on in
> deployment because the majority of sites will be unreachable.

So, it is possible to say instead:

If there are no TLSA records (this is DNSSEC validated by the lookup) or
the domain is not signed with DNSSEC (this is signed by the parent
domain): process normally (i.e. PKIX). This provides backwards
compatibility.

Then if the TLSA lookup fails entirely, you have the tradeoff you
mention. But that means the DNS reply did not arrive, the authority
server fails to answer TLSA lookups or that DNSSEC signatures failed or
something along those lines.

If the TLSA contains malformed entries, (Hi Ilari), the client considers
malformed entries to be a mismatch. (and then follows normal processing).

Best regards,
Wouter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk0J0lMACgkQkDLqNwOhpPgPfwCfTgfx3EuHhGhFTPF8OnTTewxQ
AK0AnijC4+o6FIxV2drcL+bKFqzdDDeT
=6ZJ2
-----END PGP SIGNATURE-----

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F17EA3A6E01 for ; Wed, 15 Dec 2010 21:55:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.331
X-Spam-Level:
X-Spam-Status: No, score=-3.331 tagged_above=-999 required=5 tests=[AWL=0.267, 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 nFJRjboX5GXr for ; Wed, 15 Dec 2010 21:55:18 -0800 (PST)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 9C7EC3A67B8 for ; Wed, 15 Dec 2010 21:55:18 -0800 (PST)
Received: by yxt33 with SMTP id 33so1598404yxt.31 for ; Wed, 15 Dec 2010 21:57:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=OI686WvIHEwoTZ8CMLphaDnOwF8W1Eee//a3bsYxtcw=; b=ZMUSirf6/wS/E7BclzpD/C8zLIFYxEpGBY4CjTf/X4MnYziMU2QzMMr338cE0cX5ZU SYTvn/xaBCjrZ14OqPztAazm8RcwlIBKPvPwNRgS/q+2rOD6YtrzNZxzYCOMttYTZgx3 Ks7pAq8dsMnMXjZ0WT07vkvLVn/6ZVa2zb/E8=
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=INltHxdp0I0LorNovvuiMJCq5LYVJGQ8Vx9jfRfc6L49VEbzIkEo8Fhe3Arqtgwg/P Nic7waZdCffdke+iLNclKfV7i+YV5SdIM7wYqVicCVmMiEsGJicIW8BFDohq3+Q3ctMU bIvcvrVewZP5fcY7pmlHea+wHaTR4+gEeVaRM=
MIME-Version: 1.0
Received: by 10.100.122.9 with SMTP id u9mr725756anc.171.1292479022312; Wed, 15 Dec 2010 21:57:02 -0800 (PST)
Received: by 10.100.31.8 with HTTP; Wed, 15 Dec 2010 21:57:02 -0800 (PST)
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Thu, 16 Dec 2010 05:57:02 +0000
Message-ID:
From: Phillip Hallam-Baker
To: Steve Schultze
Content-Type: multipart/alternative; boundary=0016e6407e80012c02049780b96b
Cc: [email-masked]
Subject: Re: [keyassure] Hashing certificates vs hashing keys
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 05:55:20 -0000

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

Well the draft is wrong then.

These certs are signed under the DNSSEC trust path, they are not equivalent
to a self-signed cert.

Limitations on the use of a cert have always been valid when using
self-signed certs.

On Thu, Dec 16, 2010 at 5:00 AM, Steve Schultze wrote:

> I wanted to highlight the following set of comments and flag a potential
> issue:
>
> Phillip said:
> > But the attributes in the EE cert are still important. for example,
> critical flagged attributes.
>
> The current draft says:
> "All data in a self-signed certificate other than the key itself can be
> ignored as untrusted unless a client validates the self-signed certificate
> to a trust anchor that is identical to the certificate."
>
> Then Jim Schaad said:
> > Hashing just the public key does not fix the problem if you care about
> > statements being made in the certificate besides just the key. I.e. name
> > constraints and so forth.
>
> And Paul W said:
> > You don't. The name constrains are in the DNS label.
>
> If we are sticking with the language in the draft (which I think we
> should), and anybody can suggest other constraints or attributes that might
> be necessary, we need to consider them as we work on the structure of the
> RR. If we don't think that we can predict all future
> constraints/attributes, then we need some flexible way of specifying them.
> This might lead down the path of (gasp) the Kaminsky
> TXT-record-with-key-value-pairs approach:
> http://dankaminsky.com/2010/12/14/dnssec-ch2/
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

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

Well the draft is wrong then.

These certs are signed und=
er the DNSSEC trust path, they are not equivalent to a self-signed cert.

Limitations on the use of a cert have always been va=
lid when using self-signed certs.

On Thu, Dec 16, 2010 at 5:00 AM, St=
eve Schultze <sjs=
@princeton.edu> wrote:

I wanted to highlight the following set of comments and flag a potential is=
sue:

Phillip said:

> But the attributes in the EE cert are still important. for example, cr=
itical flagged attributes.

The current draft says:

"All data in a self-signed certificate other than the key itself can b=
e ignored as untrusted unless a client validates the self-signed certificat=
e to a trust anchor that is identical to the certificate."

Then Jim Schaad said:

> Hashing just the public key does not fix the problem if you care about=

> statements being made in the certificate besides just the key. =A0I.e.=
name

> constraints and so forth.

And Paul W said:

> You don't. The name constrains are in the DNS label.

If we are sticking with the language in the draft (which I think we s=
hould), and anybody can suggest other constraints or attributes that might =
be necessary, we need to consider them as we work on the structure of the R=
R. =A0If we don't think that we can predict all future constraints/attr=
ibutes, then we need some flexible way of specifying them. =A0This might le=
ad down the path of (gasp) the Kaminsky TXT-record-with-key-value-pairs app=
roach:

http://dankaminsky.com/2010/12/14/dnssec-ch2/

_________________________________________=
______

keyassure mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/keyassure

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

--0016e6407e80012c02049780b96b--

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E539328C14F for ; Wed, 15 Dec 2010 21:18:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.585
X-Spam-Level:
X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 guZLzIOrwzzi for ; Wed, 15 Dec 2010 21:18:06 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 01E1328C121 for ; Wed, 15 Dec 2010 21:18:06 -0800 (PST)
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 F1613C436; Thu, 16 Dec 2010 00:19:47 -0500 (EST)
Date: Thu, 16 Dec 2010 00:19:47 -0500 (EST)
From: Paul Wouters
To: Steve Schultze , Paul Hoffman
In-Reply-To: <[email-masked]>
Message-ID:
References: <[email-masked]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: [email-masked]
Subject: Re: [keyassure] Hashing certificates vs hashing keys
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 05:18:07 -0000

On Thu, 16 Dec 2010, Steve Schultze wrote:

> The current draft says:
> "All data in a self-signed certificate other than the key itself can be ignored as untrusted unless a client validates the self-signed certificate to a trust anchor that is identical to the certificate."

> If we are sticking with the language in the draft (which I think we should),

So the issue with this that was brought to my attention by a browser
vendor, is that their CA policies don't allow them to "take in" unverified
data. So having a CN and then not vouching for it cannot work, because
they would end up displaying unvouched data to the user if TLSA checks
were done over just the key and not the CN. So I think we need something
besides "can be ignored", because its a real problem we cannot ignore.

I think we can address this with adding the new TLSA cert type that only
vouches for the public key. For any other TLSA cert type, I believe the
the above test could then remain, but perhaps a warning should be added:

"Some client policy might not allow unverified certificate data in
self-signed certificates and might reject the TLSA record in such cases
and fall back to non-TLSA certificate validations"

Perhaps a pointer to not using a CN= allowing TLS vhosting with one certificate
could be useful as well.

Paul

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23B6728C13B for ; Wed, 15 Dec 2010 20:58:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.599
X-Spam-Level:
X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, 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 EUiZB+YCxp8z for ; Wed, 15 Dec 2010 20:58:27 -0800 (PST)
Received: from ppa01.Princeton.EDU (ppa01.Princeton.EDU [128.112.128.213]) by core3.amsl.com (Postfix) with ESMTP id 1AE6D28C121 for ; Wed, 15 Dec 2010 20:58:27 -0800 (PST)
Received: from csgsmtp201l.Princeton.EDU (csgsmtp201l.Princeton.EDU [128.112.134.60]) by ppa01.Princeton.EDU (8.14.3/8.14.3) with ESMTP id oBG50AxN002945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 16 Dec 2010 00:00:10 -0500
Received: from new-host.home (pool-173-71-100-208.cmdnnj.fios.verizon.net [173.71.100.208]) (authenticated bits=0) by csgsmtp201l.Princeton.EDU (8.13.8/8.12.9) with ESMTP id oBG509k9029714 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 16 Dec 2010 00:00:09 -0500
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1081)
From: Steve Schultze
In-Reply-To:
Date: Thu, 16 Dec 2010 00:00:09 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <[email-masked]>
References:
To: [email-masked]
X-Mailer: Apple Mail (2.1081)
X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6198 signatures=655024
X-Proofpoint-Spam-Details: rule=quarantine_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-1010190000 definitions=main-1012150230
Subject: Re: [keyassure] Hashing certificates vs hashing keys
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 04:58:28 -0000

I wanted to highlight the following set of comments and flag a potential =
issue:

Phillip said:
> But the attributes in the EE cert are still important. for example, =
critical flagged attributes.

The current draft says:
"All data in a self-signed certificate other than the key itself can be =
ignored as untrusted unless a client validates the self-signed =
certificate to a trust anchor that is identical to the certificate."

Then Jim Schaad said:
> Hashing just the public key does not fix the problem if you care about
> statements being made in the certificate besides just the key. I.e. =
name
> constraints and so forth.

And Paul W said:
> You don't. The name constrains are in the DNS label.

If we are sticking with the language in the draft (which I think we =
should), and anybody can suggest other constraints or attributes that =
might be necessary, we need to consider them as we work on the structure =
of the RR. If we don't think that we can predict all future =
constraints/attributes, then we need some flexible way of specifying =
them. This might lead down the path of (gasp) the Kaminsky =
TXT-record-with-key-value-pairs approach:
http://dankaminsky.com/2010/12/14/dnssec-ch2/=

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9018828C13B for ; Wed, 15 Dec 2010 20:52:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjhEBVXiGnL3 for ; Wed, 15 Dec 2010 20:52:37 -0800 (PST)
Received: from ppa03.princeton.edu (ppa03.Princeton.EDU [128.112.128.214]) by core3.amsl.com (Postfix) with ESMTP id 1575028C121 for ; Wed, 15 Dec 2010 20:52:32 -0800 (PST)
Received: from csgsmtp200l.Princeton.EDU (csgsmtp200l.Princeton.EDU [128.112.130.131]) by ppa03.princeton.edu (8.14.3/8.14.3) with ESMTP id oBG4sGG4032249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 15 Dec 2010 23:54:16 -0500
Received: from new-host.home (pool-173-71-100-208.cmdnnj.fios.verizon.net [173.71.100.208]) (authenticated bits=0) by csgsmtp200l.Princeton.EDU (8.13.8/8.12.9) with ESMTP id oBG4sF8L010907 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 15 Dec 2010 23:54:16 -0500
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1081)
From: Steve Schultze
In-Reply-To: <20101213220001.24500.52050.idtracker@localhost>
Date: Wed, 15 Dec 2010 23:54:15 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <[email-masked]>
References: <20101213220001.24500.52050.idtracker@localhost>
To: [email-masked]
X-Mailer: Apple Mail (2.1081)
X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6198 signatures=655024
X-Proofpoint-Spam-Details: rule=quarantine_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-1010190000 definitions=main-1012150228
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 16 Dec 2010 04:52:39 -0000

"If the application receives zero usable certificate associations, it =
processes TLS in the normal fashion."

I think that this should read:
"If the application receives zero usable certificate associations, it =
[MAY process] TLS in the normal fashion."

I originally made this suggestion on =
draft-hoffman-keys-linkage-from-dns-03 (see the follow-on discussion =
here for background):
http://www.ietf.org/mail-archive/web/keyassure/current/msg00890.html

And, as I noted during our session in Beijing, the motivation for =
permitting the client to choose is that if we mandate it one way or the =
other, we fall into a trap. If the client MUST process TLS in the =
normal fashion (aka, using PKIX) then we have provided a solution that =
is no better than the status quo. If the client MUST give an =
"access_denied" error, then nobody will use the standard early on in =
deployment because the majority of sites will be unreachable.=

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88E6E28C180 for ; Wed, 15 Dec 2010 09:58:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.584
X-Spam-Level:
X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 dmOHHV6-nJ00 for ; Wed, 15 Dec 2010 09:58:52 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id A8B6228C163 for ; Wed, 15 Dec 2010 09:58:52 -0800 (PST)
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 38B24C4BE; Wed, 15 Dec 2010 13:00:34 -0500 (EST)
Date: Wed, 15 Dec 2010 13:00:33 -0500 (EST)
From: Paul Wouters
To: "Steingruebl, Andy"
In-Reply-To: <[email-masked]>
Message-ID:
References: <[email-masked]> <[email-masked]> <[email-masked]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: Jim Schaad , "[email-masked]"
Subject: Re: [keyassure] Hashing certificates vs hashing keys
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 15 Dec 2010 17:58:53 -0000

On Wed, 15 Dec 2010, Steingruebl, Andy wrote:

>> I'm not sure I see why you would use different private keys (or certs) on
>> different load balancers for the same website?
>
> At least one large financial institution is rumored to require private key generation in hardware for all use cases, and its easier to make them unique, than transport them between multiple hardware-security-modules. Regardless of whether they are typical, are you saying you view this is an invalid practice (generating separate private keys for each server/load-balancer) or that you simply don't want to support it in this spec?

I have no issue supporting it.

Paul

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB90C28C107 for ; Wed, 15 Dec 2010 09:58:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.181
X-Spam-Level:
X-Spam-Status: No, score=-2.181 tagged_above=-999 required=5 tests=[AWL=0.418, 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 6kY6tL5euPnm for ; Wed, 15 Dec 2010 09:58:42 -0800 (PST)
Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 81C8728C0F2 for ; Wed, 15 Dec 2010 09:58:42 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=cgFfAl7zifO0eFFalOm1habidHAirL4BjMvzIayPC3e57FA8OVM2wp8uSCwdD9LX; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.38] (helo=elwamui-lapwing.atl.sa.earthlink.net) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1PSveK-00005V-8N; Wed, 15 Dec 2010 13:00:24 -0500
Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Wed, 15 Dec 2010 13:00:24 -0500
Message-ID: <[email-masked]>
Date: Wed, 15 Dec 2010 12:00:24 -0600 (GMT-06:00)
From: "Jeffrey A. Williams"
To: [email-masked], Adam Langley
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e5196068822de440204f0f3987df7793b6508640b350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.38
Cc: [email-masked]
Subject: Re: [keyassure] Hashing certificates vs hashing keys
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: "Jeffrey A. Williams"
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 15 Dec 2010 17:58:43 -0000

Martin and all,

More and more there are org's that are desiring
to do more through the browser. But as you rightly
point out it's often done wrong or poorly. Still
this trend is not going away.

-----Original Message-----
>From: Martin Rex
>Sent: Dec 14, 2010 4:04 PM
>To: Adam Langley
>Cc: [email-masked]
>Subject: Re: [keyassure] Hashing certificates vs hashing keys
>
>Adam Langley wrote:
>>
>> On Tue, Dec 14, 2010 at 2:18 PM, Martin Rex wrote:
>> > TLS implementations that send out incomplete or unordered certificate
>> > chains are clearly violating the TLS protocol specification and
>> > those that are sending expired certificate deserve to face a
>> > fatal certficate expired alert.
>>
>> Yes, I agree. However all the economic incentives push clients towards
>> maximum compatibility and don't encourage server operators to fix
>> anything.
>
>If Browsers implement the "workarounds" that you described in a
>completely covert fashion, then they are actually making the problem
>MUCH worse _and_ make it last MUCH longer.
>
>There are a number of folks that do black-box testing with browsers
>only, and what the particular browser that is used does not report
>as an error is considered "fine".
>
>Silently forgiving just about _everything_ with a smile is a sure way
>to spoil kids and technologies.
>
>
>More and more often I'm seeing support calls "but it works in the browser",
>and I'll have to ask for a network trace -- in order to confirm that
>our TLS client in compliance with the spec and that they need to
>get the server fixed if they want to connect/interoperate. And our
>client is pretty conservative in what it sends out (e.g. no TLS extensions).
>
>
>
>-Martin
>_______________________________________________
>keyassure mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/keyassure

Regards,
Jeffrey A. Williams
"Obedience of the law is the greatest freedom" -
Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
Network Eng. SR. Eng. Network data security
ABA member in good standing member ID 01257402
E-Mail [email-masked]
Phone: 214-244-4827

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE38C28C196 for ; Wed, 15 Dec 2010 08:35:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.565
X-Spam-Level:
X-Spam-Status: No, score=-101.565 tagged_above=-999 required=5 tests=[AWL=0.481, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 yckO1OpCK5nZ for ; Wed, 15 Dec 2010 08:35:23 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 1DF0428C191 for ; Wed, 15 Dec 2010 08:35:23 -0800 (PST)
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 oBFGb3XK084503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Dec 2010 09:37:05 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References: <[email-masked]> <[email-masked]>
Date: Wed, 15 Dec 2010 08:37:02 -0800
To: Paul Wouters
From: Paul Hoffman
Content-Type: text/plain; charset="us-ascii"
Cc: [email-masked]
Subject: Re: [keyassure] Hashing certificates vs hashing keys
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 15 Dec 2010 16:35:23 -0000

At 1:41 AM -0500 12/15/10, Paul Wouters wrote:
>I'm not sure I see why you would use different private keys (or certs) on different
>load balancers for the same website?

This was covered in our pre-WG drafts: some CAs actually require it (although the requirement is often ignored). Regardless, if the TLSA record can say "this is my CA", that is sufficient for the use case.

--Paul Hoffman, Director
--VPN Consortium

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69C3A28C1A0 for ; Wed, 15 Dec 2010 08:27:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.505
X-Spam-Level:
X-Spam-Status: No, score=-7.505 tagged_above=-999 required=5 tests=[AWL=1.612, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, 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 R3TdfO-IDVaL for ; Wed, 15 Dec 2010 08:27:06 -0800 (PST)
Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) by core3.amsl.com (Postfix) with ESMTP id 3505B28C147 for ; Wed, 15 Dec 2010 08:27:06 -0800 (PST)
DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:CC: Date:Subject:Thread-Topic:Thread-Index:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: x-ems-proccessed:x-ems-stamp:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=WUUMuRUFnEv83uam+RsTSkPDKPF/De7WSd0yoUDzjq4K+BY2hZ1SFk0s tC5I27R9TohhIeRb/jAFc23Byyj7E25mOi0miA/eEqqnsQrSzbXOSeBSe 6Lx4xxNaN6xRsDJ;
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=[email-masked]; q=dns/txt; s=ppinc; t=1292430529; x=1323966529; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; z=From:=20"Steingruebl,=20Andy"=20|To:=20Paul=20Wouters=20,=20Jim =20Schaad=20|CC:=20"keyassure@iet f.org"=20|Date:=20Wed,=2015=20Dec=202 010=2009:24:52=20-0700|Subject:=20RE:=20[keyassure]=20Has hing=20certificates=20vs=20hashing=20keys|Message-ID:=20< 5EE049BA3C6538409BBE6F1760F328ABEB19963FF9@DEN-MEXMS-001. corp.ebay.com>|References:=20=0D=0A=09<030301cb9bee$ [email-masked]>=0D=0A=09=0D=0A=09< [email-masked]>=0D=0A =20|In-Reply-To:=20|Content-Transfer-Encoding:=20quoted -printable|MIME-Version:=201.0; bh=6W6jg7fobjZSmYy1IyJVzUcfs3wMoCZvtO61bqgowlQ=; b=I0JkBXX+KXzqkCJwYU10rle+RUpi+ei+xQXoUxlMwIyBRH54bCZMGbZK sxo7nBOvqrLGYQmfmtihWbqbth7lGIv6bnql4dOfnqCE+GatQRO81jfW/ m4f5IxXvjquIlMu;
X-EBay-Corp: Yes
X-IronPort-AV: E=Sophos;i="4.59,349,1288594800"; d="scan'208";a="468301"
Received: from den-vtenf-002.corp.ebay.com (HELO DEN-MEXHT-001.corp.ebay.com) ([10.101.112.213]) by den-mipot-002.corp.ebay.com with ESMTP; 15 Dec 2010 08:28:48 -0800
Received: from DEN-MEXMS-001.corp.ebay.com ([10.241.16.225]) by DEN-MEXHT-001.corp.ebay.com ([10.241.17.52]) with mapi; Wed, 15 Dec 2010 09:24:52 -0700
From: "Steingruebl, Andy"
To: Paul Wouters , Jim Schaad
Date: Wed, 15 Dec 2010 09:24:52 -0700
Thread-Topic: [keyassure] Hashing certificates vs hashing keys
Thread-Index: AcucI0cJTnu50KGDQhuV67yOTSqC6QAUPqkw
Message-ID: <[email-masked]>
References: <[email-masked]> <[email-masked]>
In-Reply-To:
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A==
x-ems-stamp: lULCVltltQ18/2ZWKBBjqA==
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter: Scanned
Cc: "[email-masked]"
Subject: Re: [keyassure] Hashing certificates vs hashing keys
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 15 Dec 2010 16:27:07 -0000

> Behalf Of Paul Wouters

> I'm not sure I see why you would use different private keys (or certs) on
> different load balancers for the same website?

At least one large financial institution is rumored to require private key =
generation in hardware for all use cases, and its easier to make them uniqu=
e, than transport them between multiple hardware-security-modules. Regardl=
ess of whether they are typical, are you saying you view this is an invalid=
practice (generating separate private keys for each server/load-balancer) =
or that you simply don't want to support it in this spec? =20
=20
- Andy

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99B363A6FEF for ; Tue, 14 Dec 2010 22:40:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_53=0.6]
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 EB0qKbbs5dXw for ; Tue, 14 Dec 2010 22:40:56 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id D25C33A6FD8 for ; Tue, 14 Dec 2010 22:40:01 -0800 (PST)
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 27819C4D7; Wed, 15 Dec 2010 01:41:41 -0500 (EST)
Date: Wed, 15 Dec 2010 01:41:40 -0500 (EST)
From: Paul Wouters
To: Jim Schaad
In-Reply-To: <[email-masked]>
Message-ID:
References: <[email-masked]> <[email-masked]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: [email-masked]
Subject: Re: [keyassure] Hashing certificates vs hashing keys
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 15 Dec 2010 06:40:57 -0000

On Tue, 14 Dec 2010, Jim Schaad wrote:

>> needed to have more then 1 TLSA. From the draft:
>>
>> 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.
>
> This is the first and simplest way to look at things. And even in this case
> you could have more than one TLSA in the DNS. If you are running an array
> of load-balanced servers and each has its own private key, then you could be
> setup to have n self-signed certificates to place in TLSA records.

I'm not sure I see why you would use different private keys (or certs) on different
load balancers for the same website?

> Another
> case where you would do this is to advance publish a new certificate in the
> event the certificate is getting ready to expire or the key is to be
> changed.

That would be only if those certificate properties are used at all. I think the
most basic and simple case for this draft should be to only take the minimum key
material, and not take anything else, including a certificate lifetime. The whole
idea is that this is now controlled with DNS TTL and RRSIG.

> After you have done the publication and caches have timed out then
> you change the private key on the server and remove the old TLSA record.

But I can see the use case here for multiple TLSA records.

> This is where the addition the chain validation comes in. What is the
> reason for having the types 3 and 4 certificate types if this is not
> allowed. I don't know if you were at the f2f, but Paul talked extensively
> about using a CA certificate and having a chain of certificates that passed
> through the certificate marked in the TLSA record - potentially with the
> certificate in the DNS being treated as a trust anchor for this one name
> space.

I could live with these, if there would be at least one sub type that would
be the type where all this information is not used, for those with no interest
in any CA validation, but just want to validate the public key from the cert
with the fingerprint in the TLSA.

> NEW ISSUE: If you have a CA certificate in the TLSA record, and don't have
> an EE certificate in a TLSA record do you ignore the set of names in the
> published certificate and assume that the DNS name is correct?

This is why redundant in tricky. With DNS the DNS name is known already outside
the certificate, so in the most "basic" type certificate, you could have an empty CN.
Which would work better for vhost'ing and SSL as well, as there is no hostname
mismatch.

Paul

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C99A128C121 for ; Tue, 14 Dec 2010 18:59:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level:
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.151, 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 9XaOBf04SRIU for ; Tue, 14 Dec 2010 18:59:12 -0800 (PST)
Received: from emh05.mail.saunalahti.fi (emh05.mail.saunalahti.fi [62.142.5.111]) by core3.amsl.com (Postfix) with ESMTP id D7B3828C144 for ; Tue, 14 Dec 2010 18:59:11 -0800 (PST)
Received: from saunalahti-vams (vs3-11.mail.saunalahti.fi [62.142.5.95]) by emh05-2.mail.saunalahti.fi (Postfix) with SMTP id EEA348C6CB for ; Wed, 15 Dec 2010 05:00:51 +0200 (EET)
Received: from emh07.mail.saunalahti.fi ([62.142.5.117]) by vs3-11.mail.saunalahti.fi ([62.142.5.95]) with SMTP (gateway) id A02681EB218; Wed, 15 Dec 2010 05:00:51 +0200
Received: from LK-Perkele-V2 (a88-112-50-174.elisa-laajakaista.fi [88.112.50.174]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id E1CA71C6383 for ; Wed, 15 Dec 2010 05:00:50 +0200 (EET)
Date: Wed, 15 Dec 2010 05:01:20 +0200
From: Ilari Liusvaara
To: [email-masked]
Message-ID: <[email-masked]>
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <[email-masked]>
User-Agent: Mutt/1.5.20 (2009-06-14)
Sender: Ilari Liusvaara
X-Antivirus: VAMS
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 15 Dec 2010 02:59:12 -0000

On Tue, Dec 14, 2010 at 09:38:18AM +0200, Ilari Liusvaara wrote:

> - What protects against app managing to load junk keys out of wrong format
> certificate (those junk keys might matematically work an be weak)?

Ah, apparently the spec limits to certifying PKIX keys. That deals with
this question.

> - Since hash #0 is identity anyway, is there reason not to merge 1 and 2
> (and also 3 and 4)?
> - Do type 3/4 entries match end entity certificate as well, or only other
> certificates?
>
> And then what to do on encountering various kinds nonsense, what should
> happen when encountering:
>
> - Record with first two bytes of 01 00?
> - Record with first two bytes of 02 02?
> - SHA-1 record that is 21 bytes total (truncated record)?
> - SHA-1 record that is 23 bytes total (extra stuff after the end)?

But these other questions still look relevant.

-Ilari

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AC1D3A6FD2 for ; Tue, 14 Dec 2010 18:34:48 -0800 (PST)
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 MuilV8+CN3KC for ; Tue, 14 Dec 2010 18:34:47 -0800 (PST)
Received: from new-smtp01.pacifier.net (new-smtp01.pacifier.net [64.255.237.177]) by core3.amsl.com (Postfix) with ESMTP id 26BD83A6FD1 for ; Tue, 14 Dec 2010 18:34:47 -0800 (PST)
Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: [email-masked]) by new-smtp01.pacifier.net (Postfix) with ESMTPSA id EF2782CA07; Tue, 14 Dec 2010 18:36:27 -0800 (PST)
From: "Jim Schaad"
To: , "'Paul Wouters'"
References: from "Paul Wouters" at Dec 14, 10 07:55:32 pm <[email-masked]>
In-Reply-To: <[email-masked]>
Date: Tue, 14 Dec 2010 18:52:00 -0800
Message-ID: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFJfHh3QZsj3UbBhnRlzvtSdD9xLpSlDPfw
Content-Language: en-us
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] Hashing certificates vs hashing keys
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 15 Dec 2010 02:34:48 -0000

> -----Original Message-----
> From: Martin Rex [mailto:[email-masked]]
> Sent: Tuesday, December 14, 2010 6:08 PM
> To: Paul Wouters
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [keyassure] Hashing certificates vs hashing keys
>
> Paul Wouters wrote:
> >
> > The TLSA is not meant to validate CA chains. It is meant to validate
> > the algorithm and pubkey of the dns entry it is associated with. It
> > should never be needed to have more then 1 TLSA. From the draft:
> >
> > 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.
>
> Two issues come to mind why a single cert is insufficient.
>
> - key rollover for your server (same algorithm, new keypair)
> - support for two different crypto algorithm during migration
> at some point in the future (e.g. from RSA-cert to EC-DSA cert)
>
>
> I don't think the "I could build different cert chains for validation"
> bears any relevance. The TLS protocol provides room for exactly ONE chain
> that the server _MUST_ send, and the TLSA(s) should match the chain(s)
that
> the server is (capable of) sending.

I would agree. If a single full chain is provided then that would be the
one chain that I would expect to be able to validate via the TLSA record(s).

Jim
>
> -Martin

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 107D628C14F for ; Tue, 14 Dec 2010 18:06:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.133
X-Spam-Level:
X-Spam-Status: No, score=-10.133 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQZQs87I3gKc for ; Tue, 14 Dec 2010 18:06:35 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 0195428C146 for ; Tue, 14 Dec 2010 18:06:34 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id oBF28Brc013856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 15 Dec 2010 03:08:11 +0100 (MET)
From: Martin Rex
Message-Id: <[email-masked]>
To: [email-masked] (Paul Wouters)
Date: Wed, 15 Dec 2010 03:08:09 +0100 (MET)
In-Reply-To: from "Paul Wouters" at Dec 14, 10 07:55:32 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal04
X-SAP: out
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [keyassure] Hashing certificates vs hashing keys
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: [email-masked]
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 15 Dec 2010 02:06:36 -0000

Paul Wouters wrote:
>
> The TLSA is not meant to validate CA chains. It is meant to validate the
> algorithm and pubkey of the dns entry it is associated with. It should never
> be needed to have more then 1 TLSA. From the draft:
>
> 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.

Two issues come to mind why a single cert is insufficient.

- key rollover for your server (same algorithm, new keypair)
- support for two different crypto algorithm during migration
at some point in the future (e.g. from RSA-cert to EC-DSA cert)

I don't think the "I could build different cert chains for validation"
bears any relevance. The TLS protocol provides room for exactly
ONE chain that the server _MUST_ send, and the TLSA(s) should match
the chain(s) that the server is (capable of) sending.

-Martin

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DC7028C163 for ; Tue, 14 Dec 2010 17:37:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.555
X-Spam-Level:
X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 ERrRrfF1db3V for ; Tue, 14 Dec 2010 17:37:49 -0800 (PST)
Received: from new-smtp01.pacifier.net (new-smtp01.pacifier.net [64.255.237.177]) by core3.amsl.com (Postfix) with ESMTP id 94CB128C13D for ; Tue, 14 Dec 2010 17:37:49 -0800 (PST)
Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: [email-masked]) by new-smtp01.pacifier.net (Postfix) with ESMTPSA id C243B2CA0E; Tue, 14 Dec 2010 17:39:30 -0800 (PST)
From: "Jim Schaad"
To: "'Paul Wouters'"
References: <[email-masked]>
In-Reply-To:
Date: Tue, 14 Dec 2010 17:55:03 -0800
Message-ID: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJN16yxeY0RglGAiDhSf1CcXcrBrwHAJdVgAbJpKqOSgKw8IA==
Content-Language: en-us
Cc: [email-masked]
Subject: Re: [keyassure] Hashing certificates vs hashing keys
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 15 Dec 2010 01:37:50 -0000

It is my belief that you are not picking up the entirety of the proposal.

> -----Original Message-----
> From: Paul Wouters [mailto:[email-masked]]
> Sent: Tuesday, December 14, 2010 4:56 PM
> To: Jim Schaad
> Cc: 'Adam Langley'; [email-masked]
> Subject: Re: [keyassure] Hashing certificates vs hashing keys
>
> On Tue, 14 Dec 2010, Jim Schaad wrote:
>
> > There may be more than one valid chain. If this is the case then both
> > (all) of the currently valid intermediate certificates should be
> > contained in TLSA records. The TLSA record would be removed if the CA
> > certificate became
>
> The TLSA is not meant to validate CA chains. It is meant to validate the
> algorithm and pubkey of the dns entry it is associated with. It should
never be
> needed to have more then 1 TLSA. From the draft:
>
> 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.

This is the first and simplest way to look at things. And even in this case
you could have more than one TLSA in the DNS. If you are running an array
of load-balanced servers and each has its own private key, then you could be
setup to have n self-signed certificates to place in TLSA records. Another
case where you would do this is to advance publish a new certificate in the
event the certificate is getting ready to expire or the key is to be
changed. After you have done the publication and caches have timed out then
you change the private key on the server and remove the old TLSA record.
Again in this case you are doing the simple thing but would have more than
one TLSA record in the DNS.

>
> Though I realise this is somewhat at odds later on with the certificate
type.

This is where the addition the chain validation comes in. What is the
reason for having the types 3 and 4 certificate types if this is not
allowed. I don't know if you were at the f2f, but Paul talked extensively
about using a CA certificate and having a chain of certificates that passed
through the certificate marked in the TLSA record - potentially with the
certificate in the DNS being treated as a trust anchor for this one name
space.

NEW ISSUE: If you have a CA certificate in the TLSA record, and don't have
an EE certificate in a TLSA record do you ignore the set of names in the
published certificate and assume that the DNS name is correct?

>
> > Hashing just the public key does not fix the problem if you care about
> > statements being made in the certificate besides just the key. I.e.
> > name constraints and so forth.
>
> You don't. The name constrains are in the DNS label.
>
> Paul

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF58728C167 for ; Tue, 14 Dec 2010 17:30:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U56RWZV7LliT for ; Tue, 14 Dec 2010 17:30:17 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 6AF1528C13D for ; Tue, 14 Dec 2010 17:30:17 -0800 (PST)
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 6C1EFC4D8; Tue, 14 Dec 2010 20:31:57 -0500 (EST)
Date: Tue, 14 Dec 2010 20:31:56 -0500 (EST)
From: Paul Wouters
To: Paul Hoffman
In-Reply-To: <20101213220001.24500.52050.idtracker@localhost>
Message-ID:
References: <20101213220001.24500.52050.idtracker@localhost>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Cc: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 15 Dec 2010 01:30:18 -0000

On Mon, 13 Dec 2010, [email-masked] wrote:

> Subject: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt

My comments below,

Section 2.

This section lists various certificate types. Could we add a type that
just concerns itself with just the pubkey parameters - leaving out as much
of the X.509 as we can. Perhaps the hash would have to cover algorithm,
keysize, pubkey bits. This would strongly point to the certificate just
being a container for the public key, and nothing else. It would also
reduce the "play space" people have for various preimage/hash attacks or
\0 attacks, as the X.509 container has a LOT of scribbling space.

Section 3.1

This section states:

TLS client policy is deliberately not prescribed by this
specification. A client MAY choose to trust a DNSSEC-secured
certificate association, depending on its local policy.

Perhaps something like:

A client SHOULD treat DNSSEC-validated certificates as much as possible
as DV validated certificates.

Section 3.1.1

Some browsers have a CA policy that prevent unvalidated information from
being present in all CA-issued certificates. For DNSSEC validated certs,
the equivalent would be that the certs contain nothing except (roughly)
the key and key usage restrictions. This could also mean leaving blank
the CN, O, OU, etc (as compared to the draft that states "ignore" in
section 3.1.4)

3.1.3. Use of Local Trust Anchors

See section 3.1.1. This might not match the CA policy for some browsers.

Missing bits.

This might be controversial, but it might be useful to specify some policy
bits. While I'd suggest putting policy in a separate document, it might be
worth having a field here stating there there is additional policy. Later on,
this could be used by DNS servers to send the policy in an new RRTYPE as
additional data. An example policy could be "https preferred" to avoid
the whole http level Strict-Transport-Security roundtrips. Though this
could probably also be done using a new EDNS option where the client can
request "TLSA and supporting data" along with an A record.

Paul

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E42D83A6E1F for ; Tue, 14 Dec 2010 16:53:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7Qfh2wIotQv for ; Tue, 14 Dec 2010 16:53:54 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 1EF533A6E1D for ; Tue, 14 Dec 2010 16:53:54 -0800 (PST)
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 0CF34C4D7; Tue, 14 Dec 2010 19:55:33 -0500 (EST)
Date: Tue, 14 Dec 2010 19:55:32 -0500 (EST)
From: Paul Wouters
To: Jim Schaad
In-Reply-To: <[email-masked]>
Message-ID:
References: <[email-masked]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: 'Adam Langley' , [email-masked]
Subject: Re: [keyassure] Hashing certificates vs hashing keys
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 15 Dec 2010 00:53:55 -0000

On Tue, 14 Dec 2010, Jim Schaad wrote:

> There may be more than one valid chain. If this is the case then both (all)
> of the currently valid intermediate certificates should be contained in TLSA
> records. The TLSA record would be removed if the CA certificate became

The TLSA is not meant to validate CA chains. It is meant to validate the
algorithm and pubkey of the dns entry it is associated with. It should never
be needed to have more then 1 TLSA. From the draft:

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.

Though I realise this is somewhat at odds later on with the certificate
type.

> Hashing just the public key does not fix the problem if you care about
> statements being made in the certificate besides just the key. I.e. name
> constraints and so forth.

You don't. The name constrains are in the DNS label.

Paul

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F37963A6E14 for ; Tue, 14 Dec 2010 16:05:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.547
X-Spam-Level:
X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 L75fZkZMmfBM for ; Tue, 14 Dec 2010 16:05:21 -0800 (PST)
Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by core3.amsl.com (Postfix) with ESMTP id F1CFA3A6EC7 for ; Tue, 14 Dec 2010 16:05:20 -0800 (PST)
Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: [email-masked]) by smtp1.pacifier.net (Postfix) with ESMTP id E8AD36EF0C; Tue, 14 Dec 2010 16:07:01 -0800 (PST)
From: "Jim Schaad"
To: "'Adam Langley'" ,
References:
In-Reply-To:
Date: Tue, 14 Dec 2010 16:22:33 -0800
Message-ID: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJN16yxeY0RglGAiDhSf1CcXcrBr5KcKmsw
Content-Language: en-us
Subject: Re: [keyassure] Hashing certificates vs hashing keys
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 15 Dec 2010 00:05:22 -0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Adam Langley
> Sent: Tuesday, December 14, 2010 8:19 AM
> To: [email-masked]
> Subject: [keyassure] Hashing certificates vs hashing keys
>
> When connecting with HTTPS, browsers validate certificates using a
`certificate
> pool' model. Initially the pool consists of the root CAs.
> Once the server's certificate chain has been received, intermediate
certificates
> are added to the pool. (Intermediate certificates from previous
connections
> may, or may not be retained in the pool. Firefox does this, Chrome
doesn't.)
> Then the browser attempts to build a chain from the leaf certificate,
upwards.
> If no valid steps can be taken then the browser will try AIA fetches to
fill in the
> blanks.
>
> This differs from the PKIX standards, but it's needed in order to function
with
> the existing set of HTTPS servers in the world.

You have lost me here, PKIX says how to validate a chain. I don't remember
anything that says this is how you construct the one or more possible chains
that need to be validated.
>
> There is also the reality that CA certificates (intermediate or root) get
> `renewed' from time to time. The expiry date of the old certificate is
advanced
> whilst maintaining the same Subject, SubjectPublicKeyInfo, etc fields.
This
> means that signatures from the old certificate are also valid signatures
for the
> new certificate.

But also means that you may or may not have a valid PKIX chain using the old
certificate.

>
> These two behaviours, in combination, mean that one cannot know what chain
> a browser will build for a given connection. There often several possible,
and
> equally valid, chains from a leaf certificate to a root CA.

There may be more than one valid chain. If this is the case then both (all)
of the currently valid intermediate certificates should be contained in TLSA
records. The TLSA record would be removed if the CA certificate became
invalidate for any of a number of reasons. But if it is considered to be
invalidate by the domain administrator it would generally have been rendered
invalid by the issuing CA as well.

The interesting question that comes up - but does not necessarily appear to
be addressed in the document is the question of this affecting the PKIX
validation protocol in the case of multiple valid chains. If the processing
is done serially rather than in parallel, the chain validation code could
return only one of the many valid chains which would then be disallowed by
the TLSA record. This might be an issue if cross certificates are created
which produce additional valid chains. I don't think that either of these
cases would be common but they might need to be addressed in the document.

>
> Therefore, if a domain were to claim that "valid chains for this domain
will
> contain a certificate with hash $h", then that may not be true for all
valid
> chains. Clients may randomly fail depending on the order of sites
previously
> visited (as that affects the contents of the pool).
>
> Hashing the SubjectPublicKeyInfo, rather than the full certificate, solves
this
> issue.

Hashing just the public key does not fix the problem if you care about
statements being made in the certificate besides just the key. I.e. name
constraints and so forth. This means that there may be additional
information in the certificate that would affect validation that could
possibly be ignored.

Jim

>
>
> Cheers
>
> AGL
>
> --
> Adam Langley [email-masked] http://www.imperialviolet.org
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 466B13A6E12 for ; Tue, 14 Dec 2010 15:59:22 -0800 (PST)
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 SklvLQ2u9cWK for ; Tue, 14 Dec 2010 15:59:21 -0800 (PST)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 378D13A6E0E for ; Tue, 14 Dec 2010 15:59:21 -0800 (PST)
Received: by iwn40 with SMTP id 40so1480635iwn.31 for ; Tue, 14 Dec 2010 16:01:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=SpojLIzHF3fC6bvE4ygr1R4IhXxgu0TTgIKi901oX6o=; b=J7uF65zNwM/uMXlpBLjNCW1Ep/si0mXZxPHBr0rlK2Jt2ZzPe7xQTEpfMh4+FCu6UV vXobRK2c9+1TsZwgPR3lXibDfxix1iz2zZ8USyP6+Fgy7RSiTo1y0SdS0Wssllev1b1H kRg397orTlwqukRT4C1/KhhWIe0dkdrlI6Y9c=
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=hiDyhJeAha+Wu/A+dzgTC0xk1AHQGWLmlo2fF3efuN5UoBLs70CML+MQqE7ZnWhNz0 ZaaojdXCEZHt5eu90RWydOSxxZJ711yZZyIJpoJKRBy6xn2C1AYSEtGVzBVRHSt74ENF stHtbGAYN3o/DmoVmGelZ5Ba3tEXjvD3kGn20=
MIME-Version: 1.0
Received: by 10.42.241.135 with SMTP id le7mr5033293icb.328.1292371262284; Tue, 14 Dec 2010 16:01:02 -0800 (PST)
Sender: [email-masked]
Received: by 10.42.218.131 with HTTP; Tue, 14 Dec 2010 16:01:02 -0800 (PST)
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Tue, 14 Dec 2010 19:01:02 -0500
X-Google-Sender-Auth: rwQSQBvPbf7u9-bfzinTF71B9rM
Message-ID:
From: Adam Langley
To: [email-masked]
Content-Type: text/plain; charset=UTF-8
Cc: [email-masked], Paul Hoffman
Subject: Re: [keyassure] Hashing certificates vs hashing keys
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 14 Dec 2010 23:59:22 -0000

On Tue, Dec 14, 2010 at 5:36 PM, Martin Rex wrote:
> Curiously, public key fingerprints and (Subject/Authority)KeyIdentifiers
> are calculated over the "SubjectPublicKey" BitString _contents_ only, rather
> than the entire SubjectPublicKeyInfo structure that includes the AlgId and
> and ASN.1 sequence container.

I believe that OpenSSL calculates fingerprints over the
subjectPublicKey while NSS calculates over the whole
SubjectPublicKeyInfo.

But I do think that hashing SubjectPublicKeyInfo is better. Maybe an
elliptic curve (x,y) pair will never be interpreted as an RSA (e, n)
pair but, rather than have to verify that, I'd hash the algorithm in.

AGL

--
Adam Langley [email-masked] http://www.imperialviolet.org

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 971393A6EC6 for ; Tue, 14 Dec 2010 15:55:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.542
X-Spam-Level:
X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 bVZ9vQyUKNd3 for ; Tue, 14 Dec 2010 15:55:14 -0800 (PST)
Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by core3.amsl.com (Postfix) with ESMTP id DD3973A6EB3 for ; Tue, 14 Dec 2010 15:55:14 -0800 (PST)
Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: [email-masked]) by smtp1.pacifier.net (Postfix) with ESMTP id 9F9F66EF1E; Tue, 14 Dec 2010 15:56:55 -0800 (PST)
From: "Jim Schaad"
To: , "'Paul Hoffman'"
References: from "Paul Hoffman" at Dec 14, 10 10:36:16 am <[email-masked]>
In-Reply-To: <[email-masked]>
Date: Tue, 14 Dec 2010 16:12:27 -0800
Message-ID: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKeD/9BKzzq5pf/8khO957GDoXruZH7uODw
Content-Language: en-us
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] Hashing certificates vs hashing keys
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 14 Dec 2010 23:55:15 -0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Martin Rex
> Sent: Tuesday, December 14, 2010 2:37 PM
> To: Paul Hoffman
> Cc: [email-masked]; [email-masked]
> Subject: Re: [keyassure] Hashing certificates vs hashing keys
>
> Paul Hoffman wrote:
> >
> > At 11:19 AM -0500 12/14/10, Adam Langley wrote:
> > >
> > >Hashing the SubjectPublicKeyInfo, rather than the full certificate,
> > >solves this issue.
> >
> > Sounds right.
>
> Curiously, public key fingerprints and (Subject/Authority)KeyIdentifiers
are
> calculated over the "SubjectPublicKey" BitString _contents_ only, rather
than
> the entire SubjectPublicKeyInfo structure that includes the AlgId and and
ASN.1
> sequence container.
>
> SubjectPublicKeyInfo ::= SEQUENCE {
> algorithm AlgorithmIdentifier,
> subjectPublicKey BIT STRING }

I don't know about public key fingerprints, (which might or might not be in
X.509 certificates and therefore would not have the structure) but the fact
that one suggested way of maybe computing SKI/AKI values which is supposed
to result in a value (not necessarily even random value) uses only the most
random portion of the input I find as being not the list bit interesting.

Jim

>
> -Martin
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D49AE28C127 for ; Tue, 14 Dec 2010 14:34:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.131
X-Spam-Level:
X-Spam-Status: No, score=-10.131 tagged_above=-999 required=5 tests=[AWL=0.118, 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 p8gTsXDU0FHS for ; Tue, 14 Dec 2010 14:34:53 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id E449428C115 for ; Tue, 14 Dec 2010 14:34:52 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id oBEMaXk2015774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 Dec 2010 23:36:33 +0100 (MET)
From: Martin Rex
Message-Id: <[email-masked]>
To: [email-masked] (Paul Hoffman)
Date: Tue, 14 Dec 2010 23:36:31 +0100 (MET)
In-Reply-To: from "Paul Hoffman" at Dec 14, 10 10:36:16 am
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal04
X-SAP: out
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] Hashing certificates vs hashing keys
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: [email-masked]
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 14 Dec 2010 22:34:53 -0000

Paul Hoffman wrote:
>
> At 11:19 AM -0500 12/14/10, Adam Langley wrote:
> >
> >Hashing the SubjectPublicKeyInfo, rather than the full certificate,
> >solves this issue.
>
> Sounds right.

Curiously, public key fingerprints and (Subject/Authority)KeyIdentifiers
are calculated over the "SubjectPublicKey" BitString _contents_ only, rather
than the entire SubjectPublicKeyInfo structure that includes the AlgId and
and ASN.1 sequence container.

SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING }

-Martin

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 231E728C160 for ; Tue, 14 Dec 2010 14:12:14 -0800 (PST)
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]
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 IvCMsK-02X0f for ; Tue, 14 Dec 2010 14:12:13 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 191D928C133 for ; Tue, 14 Dec 2010 14:12:10 -0800 (PST)
Received: by iyi42 with SMTP id 42so574434iyi.31 for ; Tue, 14 Dec 2010 14:13:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=VFfMs+4j1dEJXThghx0wgtOFkM0gio4wED8ErinYtP4=; b=px+gtR4zjheAyvpNN41usUa8NKipjmtMUvCsvisbpMuIsnxKAh9w0Ndw2qPsNBjKMW ghBiDQP09j1LaAJzaVyLXMZV6hjzz27GppinUl+PQ2BadYFeTqGWv2z4Dv8edRyQFCwN IDhyiHqUypVFc9eJX/bFwvvvI4NNJGnpy6kAo=
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=txufEm0h2GccrjCK99t+nPTYzNQU6sIvQxKaseE06h3i4lrJg7xO7PJKrgNpsS3oW0 jLdmpLJd+odF73ShoS6jo+5uJN53DnEDYzuFGOwfpG0oKn1cmIvBt4qloCtukwTiytsd bAFGY4XCPIZikkQZNZ2cnhWlD62Bij14lRfCU=
MIME-Version: 1.0
Received: by 10.42.241.135 with SMTP id le7mr4936960icb.328.1292364830831; Tue, 14 Dec 2010 14:13:50 -0800 (PST)
Sender: [email-masked]
Received: by 10.42.218.131 with HTTP; Tue, 14 Dec 2010 14:13:50 -0800 (PST)
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Tue, 14 Dec 2010 17:13:50 -0500
X-Google-Sender-Auth: axEpe_tWW5ZHVFj6f6UeAjBeSYA
Message-ID:
From: Adam Langley
To: [email-masked]
Content-Type: text/plain; charset=UTF-8
Cc: [email-masked]
Subject: Re: [keyassure] Hashing certificates vs hashing keys
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 14 Dec 2010 22:12:14 -0000

On Tue, Dec 14, 2010 at 5:04 PM, Martin Rex wrote:
> If Browsers implement the "workarounds" that you described in a
> completely covert fashion, then they are actually making the problem
> MUCH worse _and_ make it last MUCH longer.

I still agree :)

Chrome will not add workarounds to TLS because they are a proven
failure. We're also willing to take some pain to enforce this.

(For example, some servers were found to be misconfigured and
negotiating DHE with a 256-bit multiplicative group. Chrome made this
a hard error and we've had some negative press[1] and user anger
because of that. It's good to see that Firefox will be removing their
workaround for this and making it a hard error in Firefox 4.)

But we were too late to the game to do anything about the many
workarounds which are too common to ignore.

[1] http://www.theage.com.au/business/theres-no-space-like-chrome-20101209-18rj8.html

AGL

--
Adam Langley [email-masked] http://www.imperialviolet.org

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08E9828C133 for ; Tue, 14 Dec 2010 14:03:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.129
X-Spam-Level:
X-Spam-Status: No, score=-10.129 tagged_above=-999 required=5 tests=[AWL=0.120, 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 FX5l3Hz+sPsz for ; Tue, 14 Dec 2010 14:03:16 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id DCD6028C151 for ; Tue, 14 Dec 2010 14:03:15 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id oBEM4uHd010671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 Dec 2010 23:04:56 +0100 (MET)
From: Martin Rex
Message-Id: <[email-masked]>
To: [email-masked] (Adam Langley)
Date: Tue, 14 Dec 2010 23:04:54 +0100 (MET)
In-Reply-To: from "Adam Langley" at Dec 14, 10 02:30:25 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal08
X-SAP: out
Cc: [email-masked]
Subject: Re: [keyassure] Hashing certificates vs hashing keys
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: [email-masked]
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 14 Dec 2010 22:03:17 -0000

Adam Langley wrote:
>
> On Tue, Dec 14, 2010 at 2:18 PM, Martin Rex wrote:
> > TLS implementations that send out incomplete or unordered certificate
> > chains are clearly violating the TLS protocol specification and
> > those that are sending expired certificate deserve to face a
> > fatal certficate expired alert.
>
> Yes, I agree. However all the economic incentives push clients towards
> maximum compatibility and don't encourage server operators to fix
> anything.

If Browsers implement the "workarounds" that you described in a
completely covert fashion, then they are actually making the problem
MUCH worse _and_ make it last MUCH longer.

There are a number of folks that do black-box testing with browsers
only, and what the particular browser that is used does not report
as an error is considered "fine".

Silently forgiving just about _everything_ with a smile is a sure way
to spoil kids and technologies.

More and more often I'm seeing support calls "but it works in the browser",
and I'll have to ask for a network trace -- in order to confirm that
our TLS client in compliance with the spec and that they need to
get the server fixed if they want to connect/interoperate. And our
client is pretty conservative in what it sends out (e.g. no TLS extensions).

-Martin

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59F8328C127 for ; Tue, 14 Dec 2010 13:14:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.999
X-Spam-Level:
X-Spam-Status: No, score=-102.999 tagged_above=-999 required=5 tests=[AWL=-0.400, 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 i44DgMDwfN-D for ; Tue, 14 Dec 2010 13:14:32 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id E378228C11B for ; Tue, 14 Dec 2010 13:14:31 -0800 (PST)
Received: from [192.1.255.188] (port=53415 helo=col-dhcp-192-1-255-188.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PScEF-000Jg2-Nh; Tue, 14 Dec 2010 16:16:11 -0500
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: "Richard L. Barnes"
In-Reply-To:
Date: Tue, 14 Dec 2010 16:16:10 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id:
References:
To: Phillip Hallam-Baker
X-Mailer: Apple Mail (2.1082)
Cc: Adam Langley , [email-masked]
Subject: Re: [keyassure] Hashing certificates vs hashing keys
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 14 Dec 2010 21:14:33 -0000

+1 for a single mechanism that works for both CA certs and EE certs.

--Richard

On Dec 14, 2010, at 1:33 PM, Phillip Hallam-Baker wrote:

> Agree for Cert Signing certs, strongly disagree for end entity certs.
>=20
> If we are hashing an end entity cert then there is no path ambiguity. =
The path is DNSSEC->EE.
>=20
> But the attributes in the EE cert are still important. for example, =
critical flagged attributes.
>=20
>=20
> I don't care about the cert signing certs as I have never had any real =
confidence that the policy constraint mechanism works anyway.=20
>=20
> On Tue, Dec 14, 2010 at 11:19 AM, Adam Langley =
wrote:
> When connecting with HTTPS, browsers validate certificates using a
> `certificate pool' model. Initially the pool consists of the root CAs.
> Once the server's certificate chain has been received, intermediate
> certificates are added to the pool. (Intermediate certificates from
> previous connections may, or may not be retained in the pool. Firefox
> does this, Chrome doesn't.) Then the browser attempts to build a chain
> from the leaf certificate, upwards. If no valid steps can be taken
> then the browser will try AIA fetches to fill in the blanks.
>=20
> This differs from the PKIX standards, but it's needed in order to
> function with the existing set of HTTPS servers in the world.
>=20
> There is also the reality that CA certificates (intermediate or root)
> get `renewed' from time to time. The expiry date of the old
> certificate is advanced whilst maintaining the same Subject,
> SubjectPublicKeyInfo, etc fields. This means that signatures from the
> old certificate are also valid signatures for the new certificate.
>=20
> These two behaviours, in combination, mean that one cannot know what
> chain a browser will build for a given connection. There often several
> possible, and equally valid, chains from a leaf certificate to a root
> CA.
>=20
> Therefore, if a domain were to claim that "valid chains for this
> domain will contain a certificate with hash $h", then that may not be
> true for all valid chains. Clients may randomly fail depending on the
> order of sites previously visited (as that affects the contents of the
> pool).
>=20
> Hashing the SubjectPublicKeyInfo, rather than the full certificate,
> solves this issue.
>=20
>=20
> Cheers
>=20
> AGL
>=20
> --
> Adam Langley [email-masked] http://www.imperialviolet.org
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>=20
>=20
>=20
> --=20
> Website: http://hallambaker.com/
>=20
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6381428C0E6 for ; Tue, 14 Dec 2010 11:28:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5FcnctxS-YT for ; Tue, 14 Dec 2010 11:28:46 -0800 (PST)
Received: from mail-gx0-f170.google.com (mail-gx0-f170.google.com [209.85.161.170]) by core3.amsl.com (Postfix) with ESMTP id 50BFC28C0E1 for ; Tue, 14 Dec 2010 11:28:46 -0800 (PST)
Received: by gxk20 with SMTP id 20so754510gxk.15 for ; Tue, 14 Dec 2010 11:30:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=fzEk77Nkp17il7Xjmxr+lBo8I95t1HiJtJMQOsVdfNY=; b=DD1YYjEXqI8dJXHSmKw2stI7Wv9ltr2aMcxLDS23jw8Wf8Rh/5Q5jICKqMTadYbR+D nUVTUkBNgx6uYHXBnHx7LXFdBXw9Mqp7i9vk/qLLpxMM3uTA/Gf4ZiTkozH3bxn/3UF6 cIfjASmkwwr4G2o8ZqEsydMFMu2IvHUTaXV/g=
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=QO6NsQyVF5c5PBaAZNgbTUXFBiULL1l5jZtDUGD0Fa3c7N8XDQdXkHVTSh40aezqxp T+/IX7ZtpNt0x3Si31+UvPaVa1Kvflu74J6qiu79blvZtbPr1HGebiI5W1xNggjsCMYP n5AeHH4vtU382PzsefxoHfImd4HTE8EwsBCEs=
MIME-Version: 1.0
Received: by 10.42.219.66 with SMTP id ht2mr1781927icb.60.1292355025157; Tue, 14 Dec 2010 11:30:25 -0800 (PST)
Sender: [email-masked]
Received: by 10.42.218.131 with HTTP; Tue, 14 Dec 2010 11:30:25 -0800 (PST)
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Tue, 14 Dec 2010 14:30:25 -0500
X-Google-Sender-Auth: j2MZpAW8VLqw21IuJq2bbBIVVvk
Message-ID:
From: Adam Langley
To: [email-masked]
Content-Type: text/plain; charset=UTF-8
Cc: [email-masked]
Subject: Re: [keyassure] Hashing certificates vs hashing keys
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 14 Dec 2010 19:28:47 -0000

On Tue, Dec 14, 2010 at 2:18 PM, Martin Rex wrote:
> TLS implementations that send out incomplete or unordered certificate
> chains are clearly violating the TLS protocol specification and
> those that are sending expired certificate deserve to face a
> fatal certficate expired alert.

Yes, I agree. However all the economic incentives push clients towards
maximum compatibility and don't encourage server operators to fix
anything.

That's why browsers still have workarounds for SSLv3 implementations
which don't ignore extensions, for servers which claim DEFALTE support
but can't actually do it, for stacks which can't handle fragmented
handshake messages etc

AGL

--
Adam Langley [email-masked] http://www.imperialviolet.org

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99BB33A6FC2 for ; Tue, 14 Dec 2010 11:17:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.127
X-Spam-Level:
X-Spam-Status: No, score=-10.127 tagged_above=-999 required=5 tests=[AWL=0.122, 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 AvaHcprIjzcP for ; Tue, 14 Dec 2010 11:17:23 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 895993A6FBE for ; Tue, 14 Dec 2010 11:17:23 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id oBEJIwDk012629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 Dec 2010 20:19:03 +0100 (MET)
From: Martin Rex
Message-Id: <[email-masked]>
To: [email-masked] (Adam Langley)
Date: Tue, 14 Dec 2010 20:18:54 +0100 (MET)
In-Reply-To: from "Adam Langley" at Dec 14, 10 11:19:07 am
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal08
X-SAP: out
Cc: [email-masked]
Subject: Re: [keyassure] Hashing certificates vs hashing keys
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: [email-masked]
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 14 Dec 2010 19:17:24 -0000

Adam Langley wrote:
>
> When connecting with HTTPS, browsers validate certificates using a
> `certificate pool' model. Initially the pool consists of the root CAs.
> Once the server's certificate chain has been received, intermediate
> certificates are added to the pool. (Intermediate certificates from
> previous connections may, or may not be retained in the pool. Firefox
> does this, Chrome doesn't.) Then the browser attempts to build a chain
> from the leaf certificate, upwards. If no valid steps can be taken
> then the browser will try AIA fetches to fill in the blanks.
>
> This differs from the PKIX standards, but it's needed in order to
> function with the existing set of HTTPS servers in the world.

Yuck! I would _never_ do something like that in my software.
Pooling certs from other requests makes your software behaviour
non-deterministic and chasing AIA is a serious security problem.
Personally, I do not consider this reasonable behaviour.

TLS implementations that send out incomplete or unordered certificate
chains are clearly violating the TLS protocol specification and
those that are sending expired certificate deserve to face a
fatal certficate expired alert.

-Martin

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B827028C0E7 for ; Tue, 14 Dec 2010 11:00:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.327
X-Spam-Level:
X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[AWL=0.271, 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 hGXWReqCU+Gx for ; Tue, 14 Dec 2010 11:00:27 -0800 (PST)
Received: from mail-gx0-f170.google.com (mail-gx0-f170.google.com [209.85.161.170]) by core3.amsl.com (Postfix) with ESMTP id 6B43228C0EC for ; Tue, 14 Dec 2010 11:00:27 -0800 (PST)
Received: by gxk20 with SMTP id 20so726522gxk.15 for ; Tue, 14 Dec 2010 11:02:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=hToU2L+CAw2jucAGI6JJoIYoRL4zjsP1D3QZZDnsLuE=; b=rk2Alz4e+1o9gMiCSOpIFrJIg8Y/1L2tX+5uqhYcXq77wLRm2iZyguMvVgpEkvqoGk kO9apGYMLoNtwhDNObnF/EFcHimTzhu8H6E/Si4cjRM7SxwVBuRTO33RALB/1vn6irRd 3KOkSN0P2+UycwnKil/9baiAV6jZRSHA/sW5E=
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=wUA6LRLtQE0w9A3RS/MJXw3xebFhSYfEH1aeCTVcFvke3PYwDFxwVEQqIbnaGgnVmm Fx1MKuUBwlj8QUv8hSS1lSS/DXdjrGNDXHKcRW6XiOIH1UxWaTi8O4q+PqhFl9BXvm2g 6XvTkorU0FD1ln412qC/tUAlf/lHxSPlE5rqs=
MIME-Version: 1.0
Received: by 10.100.167.20 with SMTP id p20mr3765840ane.103.1292353326991; Tue, 14 Dec 2010 11:02:06 -0800 (PST)
Received: by 10.100.31.8 with HTTP; Tue, 14 Dec 2010 11:02:06 -0800 (PST)
In-Reply-To:
References: <[email-masked]> <[email-masked]>
Date: Tue, 14 Dec 2010 14:02:06 -0500
Message-ID:
From: Phillip Hallam-Baker
To: Paul Hoffman
Content-Type: multipart/alternative; boundary=0016e644d0a2fac9a90497637416
Cc: [email-masked]
Subject: Re: [keyassure] Object Digest Reference
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 14 Dec 2010 19:00:28 -0000

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

GOST has soaked up at least a thousand hours of people's time.

Under my proposal, that would be zero.

Expert review is not a cost free option, it is a permanent overhead.

On Tue, Dec 14, 2010 at 1:33 PM, Paul Hoffman wrote:

> At 1:25 PM -0500 12/14/10, Phillip Hallam-Baker wrote:
> >Vanity crypto is proposed at least once a week.
> >
> >My proposal has zero admin overhead for vanity crypto.
>
> Wow, that's a really great selling point!
>
> >The only time that there is an admin overhead is on the rare occasion when
> an alg is being considered as a MUST.
>
> And the same is true for using an IANA registry. In fact, if someone who
> does a vanity hash algorithm wants a code point, they can get it by doing
> the work themselves.
>
> >Any IANA based registry means that there will be an admin overhead to
> respond to requests, even if the answer is 'no'. In fact saying 'no' is more
> effort than 'yes'.
>
> Another baseless grand assertion. If the WG consensus is to use a new IANA
> registry, we get to write the rules. "Expert reviewer" as a rule means that
> it takes less effort to say "no" than "yes".
>
> --Paul Hoffman, Director
> --VPN Consortium
>

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

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

GOST has soaked up at least a thousand hours of people's time.

=

Under my proposal, that would be zero.=A0

Expert review is not a cost free option, it is a permanent overhead.

On Tue, Dec 14, 2010 at 1:33 PM, Paul Hoffma=
n <paul.hoffm=
[email-masked]> wrote:

At 1:25 PM -0500 12/14/10, Phillip Hallam-Baker wrote:
>Vanity crypto is proposed at least once a week.

>

>My proposal has zero admin overhead for vanity crypto.

Wow, that's a really great selling point!

>The only time that there is an admin overhead is on the rare occasion w=
hen an alg is being considered as a MUST.

And the same is true for using an IANA registry. In fact, if someone =
who does a vanity hash algorithm wants a code point, they can get it by doi=
ng the work themselves.

>Any IANA based registry means that there will be an admin overhead to r=
espond to requests, even if the answer is 'no'. In fact saying '=
;no' is more effort than 'yes'.

Another baseless grand assertion. If the WG consensus is to use a new=
IANA registry, we get to write the rules. "Expert reviewer" as a=
rule means that it takes less effort to say "no" than "yes&=
quot;.

--Paul Hoffman, Director

--VPN Consortium

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

--0016e644d0a2fac9a90497637416--

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 579413A6FBA for ; Tue, 14 Dec 2010 10:34:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.561
X-Spam-Level:
X-Spam-Status: No, score=-101.561 tagged_above=-999 required=5 tests=[AWL=0.485, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 MmwDinR2F2+w for ; Tue, 14 Dec 2010 10:34:37 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id A82E83A6EBA for ; Tue, 14 Dec 2010 10:34:37 -0800 (PST)
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 oBEIaHRg035708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Dec 2010 11:36:18 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References:
Date: Tue, 14 Dec 2010 10:36:16 -0800
To: Adam Langley , [email-masked]
From: Paul Hoffman
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [keyassure] Hashing certificates vs hashing keys
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 14 Dec 2010 18:34:38 -0000

At 11:19 AM -0500 12/14/10, Adam Langley wrote:
>There often several
>possible, and equally valid, chains from a leaf certificate to a root
>CA.
>
>Therefore, if a domain were to claim that "valid chains for this
>domain will contain a certificate with hash $h", then that may not be
>true for all valid chains. Clients may randomly fail depending on the
>order of sites previously visited (as that affects the contents of the
>pool).
>
>Hashing the SubjectPublicKeyInfo, rather than the full certificate,
>solves this issue.

Sounds right.

--Paul Hoffman, Director
--VPN Consortium

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5210F28C0E6 for ; Tue, 14 Dec 2010 10:32:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.557
X-Spam-Level:
X-Spam-Status: No, score=-101.557 tagged_above=-999 required=5 tests=[AWL=0.489, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 VBanEEFY7M7j for ; Tue, 14 Dec 2010 10:32:15 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 9C0D928C0E4 for ; Tue, 14 Dec 2010 10:32:15 -0800 (PST)
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 oBEIXrHL035625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Dec 2010 11:33:54 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References: <[email-masked]> <[email-masked]>
Date: Tue, 14 Dec 2010 10:33:52 -0800
To: Phillip Hallam-Baker
From: Paul Hoffman
Content-Type: text/plain; charset="us-ascii"
Cc: [email-masked]
Subject: Re: [keyassure] Object Digest Reference
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 14 Dec 2010 18:32:16 -0000

At 1:25 PM -0500 12/14/10, Phillip Hallam-Baker wrote:
>Vanity crypto is proposed at least once a week.
>
>My proposal has zero admin overhead for vanity crypto.

Wow, that's a really great selling point!

>The only time that there is an admin overhead is on the rare occasion when an alg is being considered as a MUST.

And the same is true for using an IANA registry. In fact, if someone who does a vanity hash algorithm wants a code point, they can get it by doing the work themselves.

>Any IANA based registry means that there will be an admin overhead to respond to requests, even if the answer is 'no'. In fact saying 'no' is more effort than 'yes'.

Another baseless grand assertion. If the WG consensus is to use a new IANA registry, we get to write the rules. "Expert reviewer" as a rule means that it takes less effort to say "no" than "yes".

--Paul Hoffman, Director
--VPN Consortium

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 872BA28B23E for ; Tue, 14 Dec 2010 10:32:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.323
X-Spam-Level:
X-Spam-Status: No, score=-3.323 tagged_above=-999 required=5 tests=[AWL=0.275, 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 rBOZwhWYDsYg for ; Tue, 14 Dec 2010 10:32:00 -0800 (PST)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id E64073A6FBA for ; Tue, 14 Dec 2010 10:31:59 -0800 (PST)
Received: by gyd12 with SMTP id 12so589145gyd.31 for ; Tue, 14 Dec 2010 10:33:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=YYBIcjoUNo7iDfKmxLJG1Wun2zEizzYGIEMaBeRikaM=; b=gk3DpKUNkvCyCHdXceHu1pM2YBdmY3R1+aDRyTwnPSAMsMLR0MK3BfK6Ht+ZrS7Uvd 1NZTF2KN5hPVibyk+DKkWH+E1ZlpP9gkrjwfa38Ss5aH7goO+m+VVIk8460PE9TDlpHQ cNXakiWqVai0TzSNV260LE/87gjpBYch6Euu8=
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=qzB7UeohGm9vgXx/L553+oPEAPfWtoY2GHWjDGRog+YaE1hPAsOzNjfTwKeWGw1iuJ X/bJI2sEy6CDf8qMuLx585RqMtCE1Bd+i5k6ZDjh5W7FtArO5rarx4dzvIjuAa8PfZ6M NfPZ7hmn3S63yjyEpn0QUnQbbl5DpF7aNt5Aw=
MIME-Version: 1.0
Received: by 10.100.195.2 with SMTP id s2mr1570046anf.35.1292351620223; Tue, 14 Dec 2010 10:33:40 -0800 (PST)
Received: by 10.100.31.8 with HTTP; Tue, 14 Dec 2010 10:33:40 -0800 (PST)
In-Reply-To:
References:
Date: Tue, 14 Dec 2010 13:33:40 -0500
Message-ID:
From: Phillip Hallam-Baker
To: Adam Langley
Content-Type: multipart/alternative; boundary=0016e644ba163f926c0497630f40
Cc: [email-masked]
Subject: Re: [keyassure] Hashing certificates vs hashing keys
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 14 Dec 2010 18:32:01 -0000

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

Agree for Cert Signing certs, strongly disagree for end entity certs.

If we are hashing an end entity cert then there is no path ambiguity. The
path is DNSSEC->EE.

But the attributes in the EE cert are still important. for example, critical
flagged attributes.

I don't care about the cert signing certs as I have never had any real
confidence that the policy constraint mechanism works anyway.

On Tue, Dec 14, 2010 at 11:19 AM, Adam Langley wrote:

> When connecting with HTTPS, browsers validate certificates using a
> `certificate pool' model. Initially the pool consists of the root CAs.
> Once the server's certificate chain has been received, intermediate
> certificates are added to the pool. (Intermediate certificates from
> previous connections may, or may not be retained in the pool. Firefox
> does this, Chrome doesn't.) Then the browser attempts to build a chain
> from the leaf certificate, upwards. If no valid steps can be taken
> then the browser will try AIA fetches to fill in the blanks.
>
> This differs from the PKIX standards, but it's needed in order to
> function with the existing set of HTTPS servers in the world.
>
> There is also the reality that CA certificates (intermediate or root)
> get `renewed' from time to time. The expiry date of the old
> certificate is advanced whilst maintaining the same Subject,
> SubjectPublicKeyInfo, etc fields. This means that signatures from the
> old certificate are also valid signatures for the new certificate.
>
> These two behaviours, in combination, mean that one cannot know what
> chain a browser will build for a given connection. There often several
> possible, and equally valid, chains from a leaf certificate to a root
> CA.
>
> Therefore, if a domain were to claim that "valid chains for this
> domain will contain a certificate with hash $h", then that may not be
> true for all valid chains. Clients may randomly fail depending on the
> order of sites previously visited (as that affects the contents of the
> pool).
>
> Hashing the SubjectPublicKeyInfo, rather than the full certificate,
> solves this issue.
>
>
> Cheers
>
> AGL
>
> --
> Adam Langley [email-masked] http://www.imperialviolet.org
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

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

Agree for Cert Signing certs, strongly disagree for end entity certs.
<=
br>

If we are hashing an end entity cert then there is no path am=
biguity. The path is DNSSEC->EE.

But the attrib=
utes in the EE cert are still important. for example, critical flagged attr=
ibutes.

I don't care about the cert signing =
certs as I have never had any real confidence that the policy constraint me=
chanism works anyway.=A0

On Tue, Dec 14, =
2010 at 11:19 AM, Adam Langley <[email-masked]> wrote:

When connecting with HTTPS, browsers valida=
te certificates using a

`certificate pool' model. Initially the pool consists of the root CAs.<=
br>
Once the server's certificate chain has been received, intermediate

certificates are added to the pool. (Intermediate certificates from

previous connections may, or may not be retained in the pool. Firefox

does this, Chrome doesn't.) Then the browser attempts to build a chain<=
br>
from the leaf certificate, upwards. If no valid steps can be taken

then the browser will try AIA fetches to fill in the blanks.

This differs from the PKIX standards, but it's needed in order to

function with the existing set of HTTPS servers in the world.

There is also the reality that CA certificates (intermediate or root)

get `renewed' from time to time. The expiry date of the old

certificate is advanced whilst maintaining the same Subject,

SubjectPublicKeyInfo, etc fields. This means that signatures from the

old certificate are also valid signatures for the new certificate.

These two behaviours, in combination, mean that one cannot know what

chain a browser will build for a given connection. There often several

possible, and equally valid, chains from a leaf certificate to a root

CA.

Therefore, if a domain were to claim that "valid chains for this

domain will contain a certificate with hash $h", then that may not be<=
br>
true for all valid chains. Clients may randomly fail depending on the

order of sites previously visited (as that affects the contents of the

pool).

Hashing the SubjectPublicKeyInfo, rather than the full certificate,

solves this issue.

Cheers

AGL

--

Adam Langley [email-masked]=
rg http://w=
ww.imperialviolet.org

_______________________________________________

keyassure mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/keyassure

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

--0016e644ba163f926c0497630f40--

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF9283A6FB2 for ; Tue, 14 Dec 2010 10:28:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.376
X-Spam-Level:
X-Spam-Status: No, score=-3.376 tagged_above=-999 required=5 tests=[AWL=0.222, 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 Crj5DffSXXEs for ; Tue, 14 Dec 2010 10:28:02 -0800 (PST)
Received: from mail-gw0-f42.google.com (mail-gw0-f42.google.com [74.125.83.42]) by core3.amsl.com (Postfix) with ESMTP id CA10D3A6EBA for ; Tue, 14 Dec 2010 10:28:01 -0800 (PST)
Received: by gwb20 with SMTP id 20so866098gwb.15 for ; Tue, 14 Dec 2010 10:29:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=SVbxOiHhNm+EStpFRhbLt8P4ti9skxfFA/JWfrFvvn0=; b=IALtySFf6FvBk9FFZpA0kauOA1V9gEYTJLsazdfgO4GMWkdh9AoZ9jT8dXqgMPyFKm aQ75I3Vgk4amzXxsl2iVFqKZf6isnOzOfXZ3W5uG37r4XQB0lV9jZnZThO5C9ILB7V8d +kJ4xeM40zbMHnGAjhumIeoQ5vwToGU3MO7PU=
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=DyvdOafo6gL/0InLYhSiNEBQRt9BOnLIVO0Sbx1zx/4Brr8Ibms0vM70YgjMMbuKZX 6V1LAGJ6zSo7q10aotlJNkroUSvVft5vlHfOWkWzQQ/9JKF19U1CSiQ4roiT3bocKijv UfQ3c89SHZYGpZK6yn16fRxt+4gYZ19Zxrbac=
MIME-Version: 1.0
Received: by 10.100.58.15 with SMTP id g15mr1907241ana.171.1292351382235; Tue, 14 Dec 2010 10:29:42 -0800 (PST)
Received: by 10.100.31.8 with HTTP; Tue, 14 Dec 2010 10:29:42 -0800 (PST)
In-Reply-To:
References: <[email-masked]> <[email-masked]>
Date: Tue, 14 Dec 2010 13:29:42 -0500
Message-ID:
From: Phillip Hallam-Baker
To: Paul Hoffman
Content-Type: multipart/alternative; boundary=0016e645abf210293b0497630102
Cc: [email-masked]
Subject: Re: [keyassure] Object Digest Reference
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 14 Dec 2010 18:28:03 -0000

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

On Tue, Dec 14, 2010 at 10:24 AM, Paul Hoffman wrote:

>
> If this idea had any practical merit, it would have been adopted 15 years
> ago when OIDs hit the IETF full-force. It's failure should be an indication
> of its practical value, even though it makes complete sense from a semantics
> standpoint.

Utter nonsense.

If the IETF had had its act together it would have done plenty of things 15
years ago - including DNSSEC.

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

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

On Tue, Dec 14, 2010 at 10:24 AM, Paul H=
offman <paul.=
[email-masked]> wrote:

If this idea had any practical merit, it would have been adopted 15 years a=
go when OIDs hit the IETF full-force. It's failure should be an indicat=
ion of its practical value, even though it makes complete sense from a sema=
ntics standpoint.

Utter nonsense.=A0

If th=
e IETF had had its act together it would have done plenty of things 15 year=
s ago - including DNSSEC.

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

--0016e645abf210293b0497630102--

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 069203A6EB8 for ; Tue, 14 Dec 2010 10:24:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.319
X-Spam-Level:
X-Spam-Status: No, score=-3.319 tagged_above=-999 required=5 tests=[AWL=0.279, 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 BVRTjBoYTOf0 for ; Tue, 14 Dec 2010 10:24:06 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id AC7843A6FC2 for ; Tue, 14 Dec 2010 10:24:06 -0800 (PST)
Received: by ywk9 with SMTP id 9so582882ywk.31 for ; Tue, 14 Dec 2010 10:25:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=tPpb3/eisDzqIHWFY6Ivuab+zVne/Zoi9y3lywHFjQc=; b=FXzMR0AOvEhTMgKWkaqghHa7n3wde3ayKkNUKvHu5Mak0nO3l4beLU2InRpi7EWCm/ mpeEMVmU7d8qKF9kNpgn26KkTgRhJP6+9i7ZeoTurBkCw5HptArtvywlMxV6KP0frY7I igD/Zjy9jp/uds+/mk0H+xXVcVvdQkrfPXc3E=
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=aZ3gMJYxp8kbEFpRkHKHUB8axnzXM2o6joHQP7aOnGREf9nsBJYiGQHNRVChKIW4Ub FHlHk/HkTstAO+CCeqj2E/kETe8DtXl83MQbigRrI4jhU8UW4Pqkxky+ottqIVaX3n1r EJ3BHG7qOj1FflaP5w3MgyTDKppnxc/tjkVeY=
MIME-Version: 1.0
Received: by 10.100.167.20 with SMTP id p20mr3738450ane.103.1292351146793; Tue, 14 Dec 2010 10:25:46 -0800 (PST)
Received: by 10.100.31.8 with HTTP; Tue, 14 Dec 2010 10:25:46 -0800 (PST)
In-Reply-To:
References: <[email-masked]> <[email-masked]>
Date: Tue, 14 Dec 2010 13:25:46 -0500
Message-ID:
From: Phillip Hallam-Baker
To: Paul Hoffman
Content-Type: multipart/alternative; boundary=0016e644d0a2079a4b049762f307
Cc: [email-masked]
Subject: Re: [keyassure] Object Digest Reference
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 14 Dec 2010 18:24:08 -0000

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

Vanity crypto is proposed at least once a week.

My proposal has zero admin overhead for vanity crypto. The only time that
there is an admin overhead is on the rare occasion when an alg is being
considered as a MUST.

Any IANA based registry means that there will be an admin overhead to
respond to requests, even if the answer is 'no'. In fact saying 'no' is more
effort than 'yes'.

On Tue, Dec 14, 2010 at 10:24 AM, Paul Hoffman wrote:

> At 11:25 PM -0500 12/13/10, Phillip Hallam-Baker wrote:
> >Well it is certainly a lot more overhead than my proposal.
>
> "A lot more"?!?! Be serious.
>
> New hash algorithms are defined once every few years. It takes someone a
> couple of hours to write and pus through a two-page RFC that says "look here
> for the formal definition of the algorithm; now give me a number". In your
> model, you have to do essentially as much work to say "here is the OID that
> people should use to interoperably specify this hash algorithm". Where is
> the extra overhead?
>
> As for your "every object that is hashed should have an OID" idea: that's a
> fine idea that turns out to be just as high overhead in practice. Imagine
> that it was already an IETF standard, and for DANE we need to come up with a
> small handful of OIDs for it to put in the draft. How is that any less
> overhead than us saying "use the integers 1 through 4"?
>
> If this idea had any practical merit, it would have been adopted 15 years
> ago when OIDs hit the IETF full-force. It's failure should be an indication
> of its practical value, even though it makes complete sense from a semantics
> standpoint.
>
> --Paul Hoffman, Director
> --VPN Consortium
>

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

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

Vanity crypto is proposed at least once a week.

My propo=
sal has zero admin overhead for vanity crypto. The only time that there is =
an admin overhead is on the rare occasion when an alg is being considered a=
s a MUST.

Any IANA based registry means that there will be an adm=
in overhead to respond to requests, even if the answer is 'no'. In =
fact saying 'no' is more effort than 'yes'.

On Tue, Dec 14, 2010 at 10:24 AM, Paul =
Hoffman <paul=
[email-masked]> wrote:

At 11:25 PM -0500 12/13/10, Phillip Hallam-Baker wrote:
>Well it is certainly a lot more overhead than my proposal.

"A lot more"?!?! Be serious.

New hash algorithms are defined once every few years. It takes someone a co=
uple of hours to write and pus through a two-page RFC that says "look =
here for the formal definition of the algorithm; now give me a number"=
. In your model, you have to do essentially as much work to say "here =
is the OID that people should use to interoperably specify this hash algori=
thm". Where is the extra overhead?

As for your "every object that is hashed should have an OID" idea=
: that's a fine idea that turns out to be just as high overhead in prac=
tice. Imagine that it was already an IETF standard, and for DANE we need to=
come up with a small handful of OIDs for it to put in the draft. How is th=
at any less overhead than us saying "use the integers 1 through 4"=
;?

If this idea had any practical merit, it would have been adopted 15 years a=
go when OIDs hit the IETF full-force. It's failure should be an indicat=
ion of its practical value, even though it makes complete sense from a sema=
ntics standpoint.

--Paul Hoffman, Director

--VPN Consortium

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

--0016e644d0a2079a4b049762f307--

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAE953A6FB4 for ; Tue, 14 Dec 2010 08:42:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 04RSPMFnklQD for ; Tue, 14 Dec 2010 08:42:08 -0800 (PST)
Received: from mail76.messagelabs.com (mail76.messagelabs.com [216.82.242.131]) by core3.amsl.com (Postfix) with SMTP id C7CAE3A6EA9 for ; Tue, 14 Dec 2010 08:42:07 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [email-masked]
X-Msg-Ref: server-7.tower-76.messagelabs.com!1292345026!115095348!1
X-StarScan-Version: 6.2.9; banners=-,-,-
X-Originating-IP: [65.242.48.8]
Received: (qmail 17143 invoked from network); 14 Dec 2010 16:43:46 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (65.242.48.8) by server-7.tower-76.messagelabs.com with SMTP; 14 Dec 2010 16:43:46 -0000
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, 14 Dec 2010 11:43:45 -0500
Message-ID:
In-Reply-To:
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [keyassure] Hashing certificates vs hashing keys
Thread-Index: Acubqrbl94SHDgVaRruBE4dr4Mz4ygAAvIPA
References:
From: "Carl Wallace"
To:
Subject: Re: [keyassure] Hashing certificates vs hashing keys
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 14 Dec 2010 16:42:08 -0000

=20
> Hashing the SubjectPublicKeyInfo, rather than the full certificate,
solves this
> issue.

+1

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80FBC28C0E0 for ; Tue, 14 Dec 2010 08:17:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sj2t60Sp6oQ3 for ; Tue, 14 Dec 2010 08:17:28 -0800 (PST)
Received: from mail-gw0-f42.google.com (mail-gw0-f42.google.com [74.125.83.42]) by core3.amsl.com (Postfix) with ESMTP id 1A23828C0DE for ; Tue, 14 Dec 2010 08:17:27 -0800 (PST)
Received: by gwb20 with SMTP id 20so722982gwb.15 for ; Tue, 14 Dec 2010 08:19:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=CVH9KIZ15wOXRuZJzECkl813vOcsI6nACf8oEUT+gxo=; b=qsYLzdNmRceCW0qlRUcbwlXsTEjj7P3Chcnibqgw/hjKesaHbQvA9KMWSZufd1og35 gTEoW/RgIQr9vuVVF6k1d8ttRqwum2HsYDgeYPtquYHcoph9j7IUdAf2vXNLQrdyU7t/ +I7DjhKc6l4VYbhqD3yk8FI86loD8i68SbE9Y=
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=Qq7UEOFVV6yNi7LSLyLIbwOlonCddLqFSQxDIK9arOsYmlWAT07Wj9OCpAmWKDFHxm xmLJE1vNi/XkYzudJQ8obA9vwSUUZn7uyHpzwUPRcLujnGS6gED9qM16g3HpgA5HpAMN /q40ur34UgKS+9ZH4y9/vZFRmdhG0S0JJCUcI=
MIME-Version: 1.0
Received: by 10.42.241.135 with SMTP id le7mr4459468icb.328.1292343547914; Tue, 14 Dec 2010 08:19:07 -0800 (PST)
Sender: [email-masked]
Received: by 10.42.218.131 with HTTP; Tue, 14 Dec 2010 08:19:07 -0800 (PST)
Date: Tue, 14 Dec 2010 11:19:07 -0500
X-Google-Sender-Auth: 2LUL5iaZQRZXPqa92Xff9i6nfHw
Message-ID:
From: Adam Langley
To: [email-masked]
Content-Type: text/plain; charset=UTF-8
Subject: [keyassure] Hashing certificates vs hashing keys
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 14 Dec 2010 16:17:29 -0000

When connecting with HTTPS, browsers validate certificates using a
`certificate pool' model. Initially the pool consists of the root CAs.
Once the server's certificate chain has been received, intermediate
certificates are added to the pool. (Intermediate certificates from
previous connections may, or may not be retained in the pool. Firefox
does this, Chrome doesn't.) Then the browser attempts to build a chain
from the leaf certificate, upwards. If no valid steps can be taken
then the browser will try AIA fetches to fill in the blanks.

This differs from the PKIX standards, but it's needed in order to
function with the existing set of HTTPS servers in the world.

There is also the reality that CA certificates (intermediate or root)
get `renewed' from time to time. The expiry date of the old
certificate is advanced whilst maintaining the same Subject,
SubjectPublicKeyInfo, etc fields. This means that signatures from the
old certificate are also valid signatures for the new certificate.

These two behaviours, in combination, mean that one cannot know what
chain a browser will build for a given connection. There often several
possible, and equally valid, chains from a leaf certificate to a root
CA.

Therefore, if a domain were to claim that "valid chains for this
domain will contain a certificate with hash $h", then that may not be
true for all valid chains. Clients may randomly fail depending on the
order of sites previously visited (as that affects the contents of the
pool).

Hashing the SubjectPublicKeyInfo, rather than the full certificate,
solves this issue.

Cheers

AGL

--
Adam Langley [email-masked] http://www.imperialviolet.org

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DDA93A6FA1 for ; Tue, 14 Dec 2010 07:45:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.553
X-Spam-Level:
X-Spam-Status: No, score=-101.553 tagged_above=-999 required=5 tests=[AWL=0.493, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 GAI2OfaS1NVz for ; Tue, 14 Dec 2010 07:45:53 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 6268E3A6EAE for ; Tue, 14 Dec 2010 07:45:53 -0800 (PST)
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 oBEFY9dd026391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Dec 2010 08:34:11 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To: <[email-masked]>
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]>
Date: Tue, 14 Dec 2010 07:34:07 -0800
To: Simon Josefsson , [email-masked]
From: Paul Hoffman
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [keyassure] PKIX-only draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 14 Dec 2010 15:45:54 -0000

At 8:39 AM +0100 12/14/10, Simon Josefsson wrote:
>Thanks for the new document. The protocol is now hard coded for PKIX,
>so that OpenPGP in TLS is not supported. Is this intentional? Why was
>this changed from earlier documents? I don't see anything in WG charter
>to support this change.

1) There are no standards for OpenPGP certificate use in TLS. RFC 5081 is an Experimental RFC. It is inappropriate for a standards-track protocol to try to support non-standard security technologies.

2) There are no good semantics for how to specify the equivalent of a CA in OpenPGP. This would mean that the only useful semantic for DANE would be "a self-signed OpenPGP end-entity certificate". The practical value of that over a self-signed PKIX end-entity certificate is zero.

If those two get fixed in the future, someone can update the protocol to add a new certificate type.

--Paul Hoffman, Director
--VPN Consortium

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CB723A6FAA for ; Tue, 14 Dec 2010 07:36:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ZdQLcth+5Fhm for ; Tue, 14 Dec 2010 07:36:05 -0800 (PST)
Received: from mail165.messagelabs.com (mail165.messagelabs.com [216.82.253.147]) by core3.amsl.com (Postfix) with SMTP id 902CF3A6EB0 for ; Tue, 14 Dec 2010 07:36:04 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [email-masked]
X-Msg-Ref: server-15.tower-165.messagelabs.com!1292340957!36626829!1
X-StarScan-Version: 6.2.9; banners=-,-,-
X-Originating-IP: [65.242.48.8]
Received: (qmail 32567 invoked from network); 14 Dec 2010 15:35:59 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (65.242.48.8) by server-15.tower-165.messagelabs.com with SMTP; 14 Dec 2010 15:35:59 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB9BA4.984B7E6C"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Tue, 14 Dec 2010 10:35:53 -0500
Message-ID:
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: draft-ietf-dane-protocol-00
Thread-Index: AcubjHHxMx8KqlocTEeBmVJqzHBz/Q==
From: "Carl Wallace"
To:
Subject: [keyassure] draft-ietf-dane-protocol-00
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 14 Dec 2010 15:36:09 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CB9BA4.984B7E6C
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Here are a few comments on the new draft:

=20

Section 1.1 should be clear that the hash covers the binary DER encoded
certificate. =20

=20

It may be worth including a length check to avoid potential issues with
appended data (i.e., ensure the client calculated hash does not cover
junk appended to a binary certificate). A security or implementation
consideration would suffice too.

=20

In 2.1, the current text allows an intermediate CA certificate to match
the hash when it is in the certificate bundle but seems to require a
trust anchor match when no match is found in the bundle. Was this
intentional? If I build a path to a trust anchor using a certificate
not in the bundle that matches the hash that should be OK too. =20

=20

The reliance on a hash of a trust anchor creates a need to install the
trust anchor in your browser store, which should probably be mentioned
in the security considerations. Ideally usage of this spec would not
result in even more cluttered TA stores. This mechanism creates a
potential scenario where one could build a path to a self-signed
certificate retrieved from an AIA pointer that is not in your trust
anchor store provided the certificate matches the Type 3 hash (though
the current text precludes this). =20

=20

In 2.1, do "valid up to" and "chains to" mean full RFC 5280 path
processing including revocation status checking?

=20

Section 3.1.2 might benefit from the addition of a SHOULD NOT cautioning
against including domain names in shared certificates, just to avoid
confusion.

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

=20

------_=_NextPart_001_01CB9BA4.984B7E6C
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Here are a =
few comments on the new draft:

Section 1.1 =
should be clear that the hash covers the binary DER encoded =
certificate.

It may be =
worth including a length check to avoid potential issues with appended =
data (i.e., ensure the client calculated hash does not cover junk =
appended to a binary certificate).  A security or implementation =
consideration would suffice too.

In 2.1, the =
current text allows an intermediate CA certificate to match the hash =
when it is in the certificate bundle but seems to require a trust anchor =
match when no match is found in the bundle.  Was this =
intentional?  If I build a path to a trust anchor using a =
certificate not in the bundle that matches the hash that should be OK =
too.

The reliance on a hash of a trust anchor creates a =
need to install the trust anchor in your browser store, which should =
probably be mentioned in the security considerations.  Ideally =
usage of this spec would not result in even more cluttered TA =
stores.  This mechanism creates a potential scenario where one =
could build a path to a self-signed certificate retrieved from an AIA =
pointer that is not in your trust anchor store provided the certificate =
matches the Type 3 hash (though the current text precludes this).  =

In 2.1, do “valid up to” and “chains =
to” mean full RFC 5280 path processing including revocation status =
checking?

Section 3.1.2 might benefit from the addition of a =
SHOULD NOT cautioning against including domain names in shared =
certificates, just to avoid confusion.

------_=_NextPart_001_01CB9BA4.984B7E6C--

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 356813A6F6E for ; Tue, 14 Dec 2010 07:32:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.548
X-Spam-Level:
X-Spam-Status: No, score=-101.548 tagged_above=-999 required=5 tests=[AWL=0.498, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 lLO1B1XUPYM0 for ; Tue, 14 Dec 2010 07:32:32 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 774C43A6EB0 for ; Tue, 14 Dec 2010 07:32:32 -0800 (PST)
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 oBEFY9db026391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Dec 2010 08:34:10 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References: <[email-masked]> <[email-masked]>
Date: Tue, 14 Dec 2010 07:24:08 -0800
To: Phillip Hallam-Baker
From: Paul Hoffman
Content-Type: text/plain; charset="us-ascii"
Cc: [email-masked]
Subject: Re: [keyassure] Object Digest Reference
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 14 Dec 2010 15:32:33 -0000

At 11:25 PM -0500 12/13/10, Phillip Hallam-Baker wrote:
>Well it is certainly a lot more overhead than my proposal.

"A lot more"?!?! Be serious.

New hash algorithms are defined once every few years. It takes someone a couple of hours to write and pus through a two-page RFC that says "look here for the formal definition of the algorithm; now give me a number". In your model, you have to do essentially as much work to say "here is the OID that people should use to interoperably specify this hash algorithm". Where is the extra overhead?

As for your "every object that is hashed should have an OID" idea: that's a fine idea that turns out to be just as high overhead in practice. Imagine that it was already an IETF standard, and for DANE we need to come up with a small handful of OIDs for it to put in the draft. How is that any less overhead than us saying "use the integers 1 through 4"?

If this idea had any practical merit, it would have been adopted 15 years ago when OIDs hit the IETF full-force. It's failure should be an indication of its practical value, even though it makes complete sense from a semantics standpoint.

--Paul Hoffman, Director
--VPN Consortium

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FE4528C119 for ; Tue, 14 Dec 2010 05:16:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.315
X-Spam-Level:
X-Spam-Status: No, score=-3.315 tagged_above=-999 required=5 tests=[AWL=0.283, 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 PtUgw+MMOQ+6 for ; Tue, 14 Dec 2010 05:16:43 -0800 (PST)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id F117828C126 for ; Tue, 14 Dec 2010 05:16:42 -0800 (PST)
Received: by yxt33 with SMTP id 33so352362yxt.31 for ; Tue, 14 Dec 2010 05:18:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=hYUzvEfq2eLJvtT0ZgbYBIx35rxUcJ2pg+JriUgcKFE=; b=eKG48zJUzVDivjn5kN0PrFN1fnmg3Krgy0dk/ZQviQ/wyiHWnPo3CIWBDKsINa9lDK dxLFphl6oOASxiKJ32bH/6K3VkF66slfLZl10LriFNx0QRRLVcYxwToLfiRFuSEDujL2 46vvyW3krrARo65yeH4Mkw3n3Grk/GBtuJHSo=
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=LJkVOFgV1LN+66FIyfN2+gX0B8jBsFuXTItY4utGZwKSKnLpJ7RhxQfifYL6LF+81d xvXEh1doLQ28yVXO2FXx/PTMkY81nDAjr14Y72KzomTa4DhrnBj9ftTpjZ4CcPlzCd9j ARUEIISWE89Iaku43O+3HTGXB2mfJynQ9di2I=
MIME-Version: 1.0
Received: by 10.100.58.15 with SMTP id g15mr1663437ana.171.1292332702835; Tue, 14 Dec 2010 05:18:22 -0800 (PST)
Received: by 10.100.31.8 with HTTP; Tue, 14 Dec 2010 05:18:22 -0800 (PST)
In-Reply-To: <[email-masked]>
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]>
Date: Tue, 14 Dec 2010 08:18:22 -0500
Message-ID:
From: Phillip Hallam-Baker
To: Simon Josefsson
Content-Type: multipart/alternative; boundary=0016e645abf2af264004975ea756
Cc: [email-masked]
Subject: Re: [keyassure] PKIX-only draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 14 Dec 2010 13:16:44 -0000

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

I think that is the right decision.

The only reason to support an additional format should be that people intend
to use it and there is an advantage to doing so.

The PGP key format is designed to support Web of Trust. There is no
established Web of Trust for servers and the whole point of this project is
to key off DNSSEC in any case.

If not for the fact that SSL implementations are de facto built on the
assumption of using X.509 certs, there might be an argument to use raw keys.

Using PGP properly in this context is not simply dropping in an additional
format. It would require people to actually build stuff and think about how
it is going to work.

Absent any real world use case for doing so, we should not support PGP or
any other format. If people actually want to use them they can use a
different certificate type identifier, it is what they are there for.

On Tue, Dec 14, 2010 at 2:39 AM, Simon Josefsson wrote:

> Thanks for the new document. The protocol is now hard coded for PKIX,
> so that OpenPGP in TLS is not supported. Is this intentional? Why was
> this changed from earlier documents? I don't see anything in WG charter
> to support this change.
>
> Regards,
> /Simon
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

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

I think that is the right decision.

The only reason to s=
upport an additional format should be that people intend to use it and ther=
e is an advantage to doing so.

The =
PGP key format is designed to support Web of Trust. There is no established=
Web of Trust for servers and the whole point of this project is to key off=
DNSSEC in any case.

If not for the fact that SSL implementations are de fac=
to built on the assumption of using X.509 certs, there might be an argument=
to use raw keys.

Using PGP properly in this conte=
xt is not simply dropping in an additional format. It would require people =
to actually build stuff and think about how it is going to work.

Absent any real world use case for doing=
so, we should not support PGP or any other format. If people actually want=
to use them they can use a different certificate type identifier, it is wh=
at they are there for.

On Tue, Dec 14, 2010=
at 2:39 AM, Simon Josefsson <[email-masked]> wrote:

Thanks for the new document. =A0The protocol is now hard coded for PKIX,
so that OpenPGP in TLS is not supported. =A0Is this intentional? =A0Why was=

this changed from earlier documents? =A0I don't see anything in WG char=
ter

to support this change.

Regards,

/Simon

_______________________________________________

keyassure mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/keyassure

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

--0016e645abf2af264004975ea756--

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA34A3A6E64 for ; Tue, 14 Dec 2010 00:59:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level:
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_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 hge7IqNa+sfP for ; Tue, 14 Dec 2010 00:59:51 -0800 (PST)
Received: from spg.kirei.se (gomi.kirei.se [91.206.174.9]) by core3.amsl.com (Postfix) with ESMTP id 45D7A3A6CE5 for ; Tue, 14 Dec 2010 00:59:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=x6H7m47LlTg/XbsCOCTwrhU2nrpotgaBSDDZnUM5sPM=; b=uP3pJraS5sa/wtOrUshu7zZ9ALi++jZ50xfFhkfoySw04L0vfZfsKeFChRp13zY0lhliuNXP4FaWN 2u1Y/xvj5crMs0Capaqu1gVq4tZgf04/sSGGJ3e8CdJNotNibfKue3OPYAwARzZeZ3achmhL62Xq38 ZintQtJ2ahEMQ9A8=
Received: from mail.kirei.se (unknown [91.206.174.10]) by spg.kirei.se (Halon Mail Gateway) with ESMTPS; Tue, 14 Dec 2010 10:01:27 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: Jakob Schlyter
In-Reply-To: <[email-masked]>
Date: Tue, 14 Dec 2010 10:01:25 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]> <[email-masked]>
To: Warren Kumari
X-Mailer: Apple Mail (2.1082)
Cc: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 14 Dec 2010 08:59:52 -0000

On 14 dec 2010, at 02.56, Warren Kumari wrote:

> a: there is no simple, clean and interoperable way for the application =
to get useful dnssec status from the resolver routines.

getrrsetbyname(3) is implemented by some operating systems, e.g. =
OpenBSD.

jakob

--=20
Jakob Schlyter
Kirei AB - www.kirei.se

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E0CA3A6F55 for ; Mon, 13 Dec 2010 23:38:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqWdx4H0ysY2 for ; Mon, 13 Dec 2010 23:38:14 -0800 (PST)
Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id 363A23A6E5F for ; Mon, 13 Dec 2010 23:38:13 -0800 (PST)
Received: from latte.josefsson.org (c80-216-27-64.bredband.comhem.se [80.216.27.64]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id oBE7dlU1025994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 14 Dec 2010 08:39:49 +0100
From: Simon Josefsson
To: [email-masked]
References: <20101213220001.24500.52050.idtracker@localhost>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:101214:[email-masked]::XLUXMIoiaUDIJ4r6:edc
X-Hashcash: 1:22:101214:[email-masked]::eT14kkM5iy4rkZfM:6uIg
X-Hashcash: 1:22:101214:[email-masked]::guVmc1y/bO0UT45n:fx41
Date: Tue, 14 Dec 2010 08:39:15 +0100
In-Reply-To: <20101213220001.24500.52050.idtracker@localhost> ([email-masked]'s message of "Mon, 13 Dec 2010 14:00:01 -0800")
Message-ID: <[email-masked]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Virus-Scanned: clamav-milter 0.96.5 at yxa-v
X-Virus-Status: Clean
Subject: [keyassure] PKIX-only draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 14 Dec 2010 07:38:15 -0000

Thanks for the new document. The protocol is now hard coded for PKIX,
so that OpenPGP in TLS is not supported. Is this intentional? Why was
this changed from earlier documents? I don't see anything in WG charter
to support this change.

Regards,
/Simon

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EA3D3A6F5D; Mon, 13 Dec 2010 23:36:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.427
X-Spam-Level:
X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[AWL=0.172, 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 GsgjytNsWNLc; Mon, 13 Dec 2010 23:36:21 -0800 (PST)
Received: from emh02.mail.saunalahti.fi (emh02.mail.saunalahti.fi [62.142.5.108]) by core3.amsl.com (Postfix) with ESMTP id 899FF3A6F55; Mon, 13 Dec 2010 23:36:21 -0800 (PST)
Received: from saunalahti-vams (vs3-11.mail.saunalahti.fi [62.142.5.95]) by emh02-2.mail.saunalahti.fi (Postfix) with SMTP id 76B42EF411; Tue, 14 Dec 2010 09:37:59 +0200 (EET)
Received: from emh03.mail.saunalahti.fi ([62.142.5.109]) by vs3-11.mail.saunalahti.fi ([62.142.5.95]) with SMTP (gateway) id A073426D2BE; Tue, 14 Dec 2010 09:37:59 +0200
Received: from LK-Perkele-V2 (a88-112-50-174.elisa-laajakaista.fi [88.112.50.174]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id B9149158A63; Tue, 14 Dec 2010 09:37:55 +0200 (EET)
Date: Tue, 14 Dec 2010 09:38:18 +0200
From: Ilari Liusvaara
To: [email-masked]
Message-ID: <[email-masked]>
References: <20101213220001.24500.52050.idtracker@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20101213220001.24500.52050.idtracker@localhost>
User-Agent: Mutt/1.5.20 (2009-06-14)
Sender: Ilari Liusvaara
X-Antivirus: VAMS
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 14 Dec 2010 07:36:22 -0000

On Mon, Dec 13, 2010 at 02:00:01PM -0800, [email-masked] 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 : Using Secure DNS to Associate Certificates with Domain Names For TLS
> Author(s) : P. Hoffman, J. Schlyter
> Filename : draft-ietf-dane-protocol-00.txt
> Pages : 9
> Date : 2010-12-12

Various unclear things:

- What protects against app managing to load junk keys out of wrong format
certificate (those junk keys might matematically work an be weak)[1][2]?
- Since hash #0 is identity anyway, is there reason not to merge 1 and 2
(and also 3 and 4)?
- Do type 3/4 entries match end entity certificate as well, or only other
certificates?

And then what to do on encountering various kinds nonsense, what should
happen when encountering:

- Record with first two bytes of 01 00?
- Record with first two bytes of 02 02?
- SHA-1 record that is 21 bytes total (truncated record)?
- SHA-1 record that is 23 bytes total (extra stuff after the end)?

[1] draft-hoffman-keys-linkage-from-dns-03 had protection against this.

[2] Granted, it seems pretty unlikely that application can pull anything
out of wrong format certificate. But if there ever will be another
certificate format using ASN.1, that might not hold anymore...

-Ilari

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B12E3A6DFD for ; Mon, 13 Dec 2010 20:23:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.31
X-Spam-Level:
X-Spam-Status: No, score=-3.31 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxQmHRDn5L+L for ; Mon, 13 Dec 2010 20:23:53 -0800 (PST)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 271E43A6D5F for ; Mon, 13 Dec 2010 20:23:52 -0800 (PST)
Received: by yxt33 with SMTP id 33so125028yxt.31 for ; Mon, 13 Dec 2010 20:25:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=8CGkwlE4i/038oU3Wdywy3I3kJezqFPaMm5aC/D8YiE=; b=l3wTbrEOSOeqMazBtMQvhYUI5yWfGb+VPo+L7WHuaFkYt4Uz2iLGUqemXj/pektzaV jCOGmSZ3pYDIoTkLD46g/71992Buo4zVTwNVZTH0narUUl08VJ493t9GltH+UrOxX240 LTVMWhlA6h0OxUVTVIy/XIER1t08i+cxcCfHg=
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=n1JKnlfCX4JYNaWyMJnt1AzmOJ66XGoViienIc+DlJNpwmdQfURGM7OeukZAJybjcK 3h9VugmVTwA/dacLZ7+qq3NdZ7K7NFA2wykrxeHv/XBuI+Arj9njB3koB8U+iSWnTQ3i PZGlWMpZMRUqfPdeAw/B+MM69BD+xlexn0ycY=
MIME-Version: 1.0
Received: by 10.100.195.2 with SMTP id s2mr1005799anf.35.1292300732142; Mon, 13 Dec 2010 20:25:32 -0800 (PST)
Received: by 10.100.31.8 with HTTP; Mon, 13 Dec 2010 20:25:32 -0800 (PST)
In-Reply-To:
References: <[email-masked]> <[email-masked]>
Date: Mon, 13 Dec 2010 23:25:32 -0500
Message-ID:
From: Phillip Hallam-Baker
To: Paul Hoffman
Content-Type: multipart/alternative; boundary=0016e644ba1615141f0497573664
Cc: [email-masked]
Subject: Re: [keyassure] Object Digest Reference
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 14 Dec 2010 04:23:54 -0000

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

Well it is certainly a lot more overhead than my proposal.

And where a registry is concerned, that would be my only real consideration.

On Mon, Dec 13, 2010 at 10:57 PM, Paul Hoffman wrote:

> At 10:38 PM -0500 12/13/10, Phillip Hallam-Baker wrote:
> >Using OIDs means that the code space is effectively infinite, anyone can
> get a code point and doing so means nothing at all.
>
> For hash algorithms, isn't "more than 100" effectively infinite? Isn't the
> bar of "must write a permanently available reference" the minimum anyone
> would want, except for private use?
>
> You are making it sound like the registry that we have chosen in onerous
> without presenting any evidence.
>
> --Paul Hoffman, Director
> --VPN Consortium
>

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

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

Well it is certainly a lot more overhead than my proposal.

And where a registry is concerned, that would be my only real considerat=
ion.

On Mon, Dec 13, 2010 at 1=
0:57 PM, Paul Hoffman <[email-masked]> wrote:

At 10:38 PM -0500 12/13/1=
0, Phillip Hallam-Baker wrote:

>Using OIDs means that the code space is effectively infinite, anyone ca=
n get a code point and doing so means nothing at all.

For hash algorithms, isn't "more than 100" effectively =
infinite? Isn't the bar of "must write a permanently available ref=
erence" the minimum anyone would want, except for private use?

You are making it sound like the registry that we have chosen in onerous wi=
thout presenting any evidence.

--Paul Hoffman, Director

--VPN Consortium

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

--0016e644ba1615141f0497573664--

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F370C3A6DE9 for ; Mon, 13 Dec 2010 19:56:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.54
X-Spam-Level:
X-Spam-Status: No, score=-101.54 tagged_above=-999 required=5 tests=[AWL=0.506, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 2s8jPe6hiHLu for ; Mon, 13 Dec 2010 19:56:09 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 5F5143A6D5F for ; Mon, 13 Dec 2010 19:56:09 -0800 (PST)
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 oBE3vj6j093379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Dec 2010 20:57:46 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References: <[email-masked]> <[email-masked]>
Date: Mon, 13 Dec 2010 19:57:43 -0800
To: Phillip Hallam-Baker , Warren Kumari
From: Paul Hoffman
Content-Type: text/plain; charset="us-ascii"
Cc: [email-masked]
Subject: Re: [keyassure] Object Digest Reference
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 14 Dec 2010 03:56:10 -0000

At 10:38 PM -0500 12/13/10, Phillip Hallam-Baker wrote:
>Using OIDs means that the code space is effectively infinite, anyone can get a code point and doing so means nothing at all.

For hash algorithms, isn't "more than 100" effectively infinite? Isn't the bar of "must write a permanently available reference" the minimum anyone would want, except for private use?

You are making it sound like the registry that we have chosen in onerous without presenting any evidence.

--Paul Hoffman, Director
--VPN Consortium

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 775B83A6D9B for ; Mon, 13 Dec 2010 19:37:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.364
X-Spam-Level:
X-Spam-Status: No, score=-3.364 tagged_above=-999 required=5 tests=[AWL=0.234, 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 BVH56ocFsu7i for ; Mon, 13 Dec 2010 19:37:07 -0800 (PST)
Received: from mail-gw0-f42.google.com (mail-gw0-f42.google.com [74.125.83.42]) by core3.amsl.com (Postfix) with ESMTP id 7CE2D3A6DA4 for ; Mon, 13 Dec 2010 19:37:06 -0800 (PST)
Received: by gwb20 with SMTP id 20so171331gwb.15 for ; Mon, 13 Dec 2010 19:38:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=QgsFwEYqQsE47VyDxvcadGe8/3cnAVS1Ov4VqXQGo5k=; b=lK5Vm6OhPvXtvvMy64vtGl2W4vFwGBcnvImdKuWG/pIGTpwLd8qm6CpNEFlivUgiEf RHxP4VD2NqLSXutNngpACanIwKJOOzOXZai232Lk0v0v/+KYUNs/WPAeyKhwI8OPXVpY eCr9iyoMUUAeHtLw82Ul/ZZaRpLQnrOx37ymc=
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=xF2qUyS/AlAcJ8gYbbmMkGRGWemmRXCuJPDU5NIf9x2zDXjCrAh5KrITVVNPNyGSsM IuSwSwUoG/T0YX6in3gQiYFk87+sfo22tiFrtEbEWXxEzh9Bq4dhHw+5YiPngMuWf6Fy z5Guv1h9NPBmLaCUBmvGtDOnqfBpi4Hp34NMM=
MIME-Version: 1.0
Received: by 10.100.195.2 with SMTP id s2mr984321anf.35.1292297925374; Mon, 13 Dec 2010 19:38:45 -0800 (PST)
Received: by 10.100.31.8 with HTTP; Mon, 13 Dec 2010 19:38:45 -0800 (PST)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Date: Mon, 13 Dec 2010 22:38:45 -0500
Message-ID:
From: Phillip Hallam-Baker
To: Warren Kumari
Content-Type: multipart/alternative; boundary=0016e644ba16c93a540497568e38
Cc: [email-masked], Paul Hoffman
Subject: Re: [keyassure] Object Digest Reference
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 14 Dec 2010 03:37:08 -0000

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

On Mon, Dec 13, 2010 at 9:43 PM, Warren Kumari wrote:

>
> On Dec 13, 2010, at 4:01 PM, Ilari Liusvaara wrote:
>
> > On Mon, Dec 13, 2010 at 01:59:28PM -0500, Phillip Hallam-Baker wrote:
> >> On Mon, Dec 13, 2010 at 11:04 AM, Paul Hoffman >wrote:
> >>
> >> Some folk on this list doubted that a semantic substitution attack was
> an
> >> issue for the KEYASSURE/CERT proposal.
> >
> > I can't find any way to perform semantic substution attack against
> > draft-hoffman-keys-linkage-from-dns-03 even in the most pathological
> > situations (that don't involve much easier attacks anyway).
> >
> > BTW: TLS itself can't defend against such attacks, it just relies that
> > attacker doesn't have such capabilites.
> >
> >> Now absent some really clear indication to the contrary, using ASN.1
> OIDs
> >> for identifying cryptographic algs and formats is pretty much a slam
> dunk. I
> >> can't see how anyone could say that it is not an acceptable way to go
> for
> >> any application layer design.
> >
> > Programming complexity. Which is big deal when you are writting this
> stuff
> > in C or C++ for practical end applications.
> >
> > And yes, I'm assuming prefixes are precomputed.
> >
> > I looked at piece of code I have written that handles ASN.1-encoded
> hashes.
> > All I can say is "yuck". I'd much rather deal with small integers (even
> > if the set has gaps).
>
> + a really large number.
>
> ASN.1 handling is notoriously bad and horribly broken -- we should be
> aiming for simplicity wherever possible, both so that this actually get
> implemented, and because overly complex code leads to bugs and security
> issues...

Then how are you going to be able to use the X.509v3 encoded certificates at
all?

> > I haven't seen any overly bad stuff with DNSSEC (granted, how many
> > implementations support GOST, but the problem). But I have seen _PLENTY_
> of
> > bad stuff with X.509.
>
> Yes (and, some would say that the lack of GOST support is a feature, not a
> bug :-))

The people behind GOST will ensure that they get a code point one way or the
other.

If they get it through an IANA assignment they will claim an IETF
endorsement for their algorithm regardless of merit. Worst case they get an
RFC to boot.

If an IANA assignment is made essential, they will assign one themselves and
tell IANA what number they will be using. That sets a bad precedent in more
than one way.

If the assignment is through ASN.1 OIDs there is no reason that the IETF
need be involved in any way at all unless there is an IETF consensus to
actually support use of GOST.

The best way to control vanity crypto is to make it as easy as possible to
slot it into the spec. Let anyone use any algorithm they like.

If GOST is the only vanity crypto option that has a code point there is a
chance people might think about implementing as a matter of course.
Particularly if there is a registry of algorithms with 2 or 3 defined code
points.

If there is only SHA2 specified as MUST in the doc and no mention of
anything else whatsoever, then implementers are going to have to go to some
effort to cause problems.

The harder you try to make getting a code point, the more significant the
ones that are assigned will be. And trying to be restrictive requires
effort.

Using OIDs means that the code space is effectively infinite, anyone can get
a code point and doing so means nothing at all.

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

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

On Mon, Dec 13, 2010 at 9:43 PM, Warren =
Kumari <warren@ku=
mari.net> wrote:

On Dec 13, 2010, at 4:01 PM, Ilari Liusvaara wrote:

> On Mon, Dec 13, 2010 at 01:59:28PM -0500, Phillip Hallam-Baker wrote:<=
br>
>> On Mon, Dec 13, 2010 at 11:04 AM, Paul Hoffman <[email-masked]>wrote:

>>

>> Some folk on this list doubted that a semantic substitution attack=
was an

>> issue for the KEYASSURE/CERT proposal.

>

> I can't find any way to perform semantic substution attack against=

> draft-hoffman-keys-linkage-from-dns-03 even in the most pathological
> situations (that don't involve much easier attacks anyway).

>

> BTW: TLS itself can't defend against such attacks, it just relies =
that

> attacker doesn't have such capabilites.

>

>> Now absent some really clear indication to the contrary, using ASN=
.1 OIDs

>> for identifying cryptographic algs and formats is pretty much a sl=
am dunk. I

>> can't see how anyone could say that it is not an acceptable wa=
y to go for

>> any application layer design.

>

> Programming complexity. Which is big deal when you are writting this s=
tuff

> in C or C++ for practical end applications.

>

> And yes, I'm assuming prefixes are precomputed.

>

> I looked at piece of code I have written that handles ASN.1-encoded ha=
shes.

> All I can say is "yuck". I'd much rather deal with small=
integers (even

> if the set has gaps).

+ a really large number.

ASN.1 handling is notoriously bad and horribly broken -- we should be aimin=
g for simplicity wherever possible, both so that this actually get implemen=
ted, and because overly complex code leads to bugs and security issues...

Then how are you going to be able to use the X.509v3 en=
coded certificates at all?

> I haven't seen any overly bad stuff with DNSSEC (granted, how many=

> implementations support GOST, but the problem). But I have seen _PLENT=
Y_ of

> bad stuff with X.509.

Yes (and, some would say that the lack of GOST support is a feature, =
not a bug :-))

The people behind GOST will =
ensure that they get a code point one way or the other.

If they get it through an IANA assignment they will claim an IET=
F endorsement for their algorithm regardless of merit. Worst case they get =
an RFC to boot.

If an IANA assignment is made esse=
ntial, they will assign one themselves and tell IANA what number they will =
be using. That sets a bad precedent in more than one way.=A0

If the assignment is through ASN.1 OIDs there is no rea=
son that the IETF need be involved in any way at all unless there is an IET=
F consensus to actually support use of GOST.

The best way to control vanity crypto is to make it as easy as p=
ossible to slot it into the spec. Let anyone use any algorithm they like.

If GOST is the only vanity crypto option that has a=
code point there is a chance people might think about implementing as a ma=
tter of course. Particularly if there is a registry of algorithms with 2 or=
3 defined code points.

If there is only SHA2 specified as MUST in the doc and =
no mention of anything else whatsoever, then implementers are going to have=
to go to some effort to cause problems.

The harder you try to make getting a code point, the more significant =
the ones that are assigned will be. And trying to be restrictive requires e=
ffort.

Using OIDs means that the code space is eff=
ectively infinite, anyone can get a code point and doing so means nothing a=
t all.

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

--0016e644ba16c93a540497568e38--

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9205028C12D for ; Mon, 13 Dec 2010 18:37:20 -0800 (PST)
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 JvOnhyvw-YjU for ; Mon, 13 Dec 2010 18:37:19 -0800 (PST)
Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id 58E9C28C124 for ; Mon, 13 Dec 2010 18:37:19 -0800 (PST)
Received: from [192.168.0.221] (unknown [64.13.52.115]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id 9BD4C22846EC; Mon, 13 Dec 2010 21:35:53 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=utf-8
From: Warren Kumari
In-Reply-To: <[email-masked]>
Date: Mon, 13 Dec 2010 21:43:14 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <[email-masked]>
References: <[email-masked]>
To: Ilari Liusvaara
X-Mailer: Apple Mail (2.1081)
Cc: Phillip Hallam-Baker , Paul Hoffman , [email-masked]
Subject: Re: [keyassure] Object Digest Reference
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 14 Dec 2010 02:37:20 -0000

On Dec 13, 2010, at 4:01 PM, Ilari Liusvaara wrote:

> On Mon, Dec 13, 2010 at 01:59:28PM -0500, Phillip Hallam-Baker wrote:
>> On Mon, Dec 13, 2010 at 11:04 AM, Paul Hoffman =
wrote:
>>=20
>> Some folk on this list doubted that a semantic substitution attack =
was an
>> issue for the KEYASSURE/CERT proposal.
>=20
> I can't find any way to perform semantic substution attack against=20
> draft-hoffman-keys-linkage-from-dns-03 even in the most pathological
> situations (that don't involve much easier attacks anyway).
>=20
> BTW: TLS itself can't defend against such attacks, it just relies that
> attacker doesn't have such capabilites.
>=20
>> Now absent some really clear indication to the contrary, using ASN.1 =
OIDs
>> for identifying cryptographic algs and formats is pretty much a slam =
dunk. I
>> can't see how anyone could say that it is not an acceptable way to go =
for
>> any application layer design.
>=20
> Programming complexity. Which is big deal when you are writting this =
stuff
> in C or C++ for practical end applications.
>=20
> And yes, I'm assuming prefixes are precomputed.
>=20
> I looked at piece of code I have written that handles ASN.1-encoded =
hashes.
> All I can say is "yuck". I'd much rather deal with small integers =
(even
> if the set has gaps).

+ a really large number.

ASN.1 handling is notoriously bad and horribly broken -- we should be =
aiming for simplicity wherever possible, both so that this actually get =
implemented, and because overly complex code leads to bugs and security =
issues...

>=20
>> They are bad within DNSSEC. But unavoidable at the upper layers. I =
would
>> prefer not to have to support PGP and other key formats in this =
scheme, but
>> they are going to be unavoidable politically.
>=20
> I haven't seen any overly bad stuff with DNSSEC (granted, how many
> implementations support GOST, but the problem). But I have seen =
_PLENTY_ of
> bad stuff with X.509.

Yes (and, some would say that the lack of GOST support is a feature, not =
a bug :-))

w

>=20
>> I don't like having to deal with all that. But what I really, really =
want to
>> avoid is having application layer crypto impact DNSSEC.
>=20
> his is just about how to denote hash algorithms. And what about fairly
> reasonable hash algorithms that seeming have no OID?
>=20
>> OK, how about on a web page. Imagine that we have a web page that is
>> downloaded from a TLS site but the images are stored on a separate =
image
>> server that does not have TLS.
>>=20
>> At the moment this is such a common use case that it is really =
difficult to
>> get enforcement on because it is so common. And there is another =
variation
>> where the data linked to is not even in the same domain.
>>=20
>> Imagine we can create a link of the form:
>>=20
>> > odr=3D"odr:woei2oqur02que0o2quefoiqwefouqwefoiu=3D=3D"/>
>>=20
>> Packaging it up as a URI is not strictly necessary but that is what =
it is
>> functionally.
>>=20
>> One could even have a cache of content referenced by ODR lookup. So =
if the
>> content is not locatable, it can be pulled from cache.
>>=20
>> > odr=3D"odr:woqi12o3o12hroiqhweoiqhwe=3D=3D">RFC 6666
>=20
> What does that ODR encode about the semantics in both cases? That the =
file
> is a GIF in above case (what's the OID of GIF?) and that it is text =
file
> (what character set=E2=80=BD; what is say, OID of ASCII text file?).
>=20
> -Ilari
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DA2028C124 for ; Mon, 13 Dec 2010 17:51:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BI+2Nv3acYt7 for ; Mon, 13 Dec 2010 17:51:39 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id EF37128C0CF for ; Mon, 13 Dec 2010 17:51:38 -0800 (PST)
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 3CCFCC412; Mon, 13 Dec 2010 20:53:17 -0500 (EST)
Date: Mon, 13 Dec 2010 20:53:16 -0500 (EST)
From: Paul Wouters
To: Stephen Farrell
In-Reply-To: <[email-masked]>
Message-ID:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: [email-masked], Paul Hoffman
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 14 Dec 2010 01:51:40 -0000

On Tue, 14 Dec 2010, Stephen Farrell wrote:

> So I don't know the details of the SSH RR type. I guess
> I ought look. This WG however has IPsec-related milestones
> and so the question will need answering ("can the TLSA RR
> work for IPsec?"). I happen to think it ought be clear
> whether or not the TLSA RR is (D)TLS-only or not before
> it gets finished. For me, the answer to that only gets
> interesting for protocols that could work with bare
> keys. Again, this is one its ok to figure out a bit
> later.

I don't think this should be used for IPSEC, as we have IPSECKEY.

One advantage of IPSECKEY for instance, is that you can tell it
to go to a designated third part ipsec gateway. So for example
you could have an IPSECKEY record stating "for www.xelerance.com,
use IPsec with this key/hash using gateway ipsec.xelerance.com".

That way, you can redirect your encrypted traffic to a specifically
designed crypto gateway. And you could enable/disable the crypto
infrastructure by simply removing the DNS IPSECKEY without redesigning
your network.

It also allows "MX style" priorities for load balancing.

These features don't really apply to TLS though, so I don't think it
makes sense incorporating these here. But similarly, it means it
does not make much sense incorporating IPSEC within TLSA either.

Paul

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1FC728C124 for ; Mon, 13 Dec 2010 17:50:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.554
X-Spam-Level:
X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, 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 EyLxFXk2Bt1x for ; Mon, 13 Dec 2010 17:50:49 -0800 (PST)
Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id 797CB28C0CF for ; Mon, 13 Dec 2010 17:50:49 -0800 (PST)
Received: from [192.168.0.221] (unknown [64.13.52.115]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id 1A682DEE310; Mon, 13 Dec 2010 20:49:23 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Warren Kumari
In-Reply-To: <[email-masked]>
Date: Mon, 13 Dec 2010 20:56:43 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <[email-masked]>
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]>
To: Stephen Farrell
X-Mailer: Apple Mail (2.1081)
Cc: [email-masked], Paul Hoffman
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 14 Dec 2010 01:50:50 -0000

On Dec 13, 2010, at 8:24 PM, Stephen Farrell wrote:

>=20
>=20
> On 14/12/10 01:18, Paul Wouters wrote:
>> On Mon, 13 Dec 2010, Paul Hoffman wrote:
>>=20
>>> I'm interested in how we can say "must use last-hop technology X" =
when
>>> X doesn't exist. Wording suggestions appreciated.
>>=20
>> TLSA records must only be trusted if they were obtained from a =
trusted
>> source. This could be a localhost resolver answer with the AD bit =
set,=20
>=20
> (As an aside, I think web browsers are a good demonstration that
> localhost is no longer considered as good as it once was, in =
particular,
> if some browser vendors are considering re-implementing DNSSEC in the
> browser process(es) in order to do DANE well, that would seem to imply
> a lack of trust in localhost.)

I think that it is partially a lack of trust in localhost, but more the =
fact that:
a: there is no simple, clean and interoperable way for the application =
to get useful dnssec status from the resolver routines.
b: in almost all cases the local resolver is not (yet) dnssec aware.

What will eventually be needed is something like gethostbyname(), that =
returns the validation state as well as the address, etc.

W

>=20
>> an
>> inline validating resolver library primed with the proper trust =
anchors,
>> or obtained from a remote nameserver to which one has a secured =
channel
>> of communication.
>=20
> Which "secured channel of cummunication" and defined where, so that we
> get interop? My private magic way of doing this is not IMO good enough
> for DANE.
>=20
> S.
>=20
>>=20
>> [ perhaps they got be stored with TTL in the app too, so that =
frequent
>> network moves would not invalida the data, but possible this is
>> already covered in the application usage of DNS in general ]
>>=20
>> Paul
>> _______________________________________________
>> keyassure mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/keyassure
>>=20
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98DD628C0F3 for ; Mon, 13 Dec 2010 17:23:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9od8S7SyUrr for ; Mon, 13 Dec 2010 17:22:59 -0800 (PST)
Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:21b:21ff:fe3a:3d50]) by core3.amsl.com (Postfix) with ESMTP id DCD5828C0F8 for ; Mon, 13 Dec 2010 17:22:57 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 822DE3E40BB; Tue, 14 Dec 2010 01:24:36 +0000 (GMT)
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=1292289876; bh=wadZ14lrRiQV4l ZjxPqT57vXfIPkt4FoqJzp2ZMMFJU=; b=GaA2xbygsaTcuPW563Vn8/KDo5xcjE LxBNuNw/ivJ8iP5W9KB4gkK/v8tXX2TIbM6X1DSXMq9dSgzdS6sgFyG3hZaywkTl S/WDs/0NV7Q5kK09vlY70vTnK7idTYSWDeeiSBJPXDtPMGPUg98rkvpqHjlG0cco wR9d0+A1p9evxUpYvjNxM6sh8kMOifbcDqrILIDoXjArDam0z+3aNVKaJQTKgTm2 d2L3sNzUTyMe/gmrM8SIjPtJsa2JmMQ9rjxmqDlETI4FUVXCE5NscJUculEEZT5T E473R5xumw930yKsb9BrFlXq3mGN9EsacubG70jSJYLSGtbDmpdqsWbQ==
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 ASUbflrWXw7d; Tue, 14 Dec 2010 01:24:36 +0000 (GMT)
Received: from [10.87.48.6] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 19C893E40B0; Tue, 14 Dec 2010 01:24:36 +0000 (GMT)
Message-ID: <[email-masked]>
Date: Tue, 14 Dec 2010 01:24:35 +0000
From: Stephen Farrell
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7
MIME-Version: 1.0
To: Paul Wouters
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]>
In-Reply-To:
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: [email-masked], Paul Hoffman
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 14 Dec 2010 01:23:00 -0000

On 14/12/10 01:18, Paul Wouters wrote:
> On Mon, 13 Dec 2010, Paul Hoffman wrote:
>
>> I'm interested in how we can say "must use last-hop technology X" when
>> X doesn't exist. Wording suggestions appreciated.
>
> TLSA records must only be trusted if they were obtained from a trusted
> source. This could be a localhost resolver answer with the AD bit set,

(As an aside, I think web browsers are a good demonstration that
localhost is no longer considered as good as it once was, in particular,
if some browser vendors are considering re-implementing DNSSEC in the
browser process(es) in order to do DANE well, that would seem to imply
a lack of trust in localhost.)

> an
> inline validating resolver library primed with the proper trust anchors,
> or obtained from a remote nameserver to which one has a secured channel
> of communication.

Which "secured channel of cummunication" and defined where, so that we
get interop? My private magic way of doing this is not IMO good enough
for DANE.

S.

>
> [ perhaps they got be stored with TTL in the app too, so that frequent
> network moves would not invalida the data, but possible this is
> already covered in the application usage of DNS in general ]
>
> Paul
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F11C3A6E21 for ; Mon, 13 Dec 2010 17:17:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m0RuN+PVGnnb for ; Mon, 13 Dec 2010 17:17:39 -0800 (PST)
Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:21b:21ff:fe3a:3d50]) by core3.amsl.com (Postfix) with ESMTP id 7DF343A6E25 for ; Mon, 13 Dec 2010 17:17:38 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 730A03E40B0; Tue, 14 Dec 2010 01:19:15 +0000 (GMT)
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=1292289555; bh=S3xXaqzLB1j4Rw C4vGysbNAFp1zKAPx4UpY8lBgKfW4=; b=DUW87ivFkx4W9XxFaAjH/H4o2tpaok z2/Wd89/5W6DdScDE+MWfA0FOyhFbnmv0bAuM/qMvT3trCBrU+WaSd1U9AaqVUDF xzmrp9Is0Tb7YzsJVKf2gbwFH+v4cMtClRwKoAlVO878F56g4bn6B6gwqUJRRkJc vcAfu6aMcR/yrAv5gN2UoaCB2CkWBymuU6GF1Gnlac1sVvjCKWMSqkvNv1XBQrT4 RQSasQlHSGqmnI8uleQVdRf3m+C32K9MwjZHq/P8LU13foNhMRzF3LxgFrYPqnae tExGj7UQnksnQpNho9jkIAydnOP2DYbe1AVTIVc1tmQvDXqCqWE73PPQ==
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 Bz2M0GqgKOFy; Tue, 14 Dec 2010 01:19:15 +0000 (GMT)
Received: from [10.87.48.6] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id F28553E40AD; Tue, 14 Dec 2010 01:19:14 +0000 (GMT)
Message-ID: <[email-masked]>
Date: Tue, 14 Dec 2010 01:19:12 +0000
From: Stephen Farrell
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7
MIME-Version: 1.0
To: Paul Hoffman
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]>
In-Reply-To:
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 14 Dec 2010 01:17:41 -0000

Hiya,

On 14/12/10 00:20, Paul Hoffman wrote:
> At 11:25 PM +0000 12/13/10, Stephen Farrell wrote:
>> Pretty good.
>
> C'mon, you're usually pricklier than that! :-)

Seriously - I think this is good, as was your BoF
presentation. (He honestly said, knowing that the
comment might engender a subtle sense of unease
nonetheless:-)

>> Questions below. Not expecting fully worked our answers now,
>> but am expecting them at some point.
>
> As Warren said earlier, we have a WG secretary, and he'll be opening issues on the WG issue tracker. We can tackle them at any time.

WG volunteers are wonderful under-appreciated things.

>
>> - How are self-signed certs handled? Are they type 1/2 or 3/4? I
>> think picking one and explicitly saying that's how its done would
>> be best. (I don't care which, I just care that we say exactly how
>> to use self-signed certs with DANE.)
>
> Yes. That is, if it is a self-signed cert used as an end-entity cert, it is 1/2; if it is used as a CA cert, it is 3/4. That's why we differentiated by semantics, not the format.

Sorry. You've not helped me at least. Why leave self-signed to be
ambiguous between 1/2 and 3/4? There is, IMO, no interesting way
in which a self-signed cert (SSC) is an EE cert and not a CA cert.
That is, an SSC is both. But (even randomly) picking one here is
better than a result where different people make different bad
assumptions as to whether an SSC is an EE or CA cert.

I'll volunteer to honestly toss an honest coin if that helps:-)

>> - How is a hash (or certificate) compared to a trust anchor? 5280
>> doesn't specify a TA format, though we mostly use self-signed certs.
>> (Does anything use something else? Does anyone really use rfc 5914
>> for this?) Might be a bit of a barney to be had about that since
>> its hard to pick a format that everyone could use, unless everyone
>> has self-signed certs or you go to the bare public key.
>
> Good point. We should say "...as long as your trust anchors are stored as self-signed certs".

And if they're not? Then there are a class of TLSA values that
just don't work and shouldn't make things worse and that need
to be identified I guess. That is, I think you need to say "if
TA!=SSC then ignore all TLSA values that..."

>
>> - If an intermediate CA were compromised, then a DNS admin could
>> obviate the revocation of the relevant CA cert by adding an RR.
>> Not that likely, and detectable, but maybe worth a security
>> consideration paragraph since such a case might be fairly
>> catastrophic as-is, but would be made worse with DANE.
>
> Good call, yes.
>
>> - Practically, we do have an informal partial-order of hash
>> function strength (md5,sha-1,sha-2). I don't think so, but
>> would be it worthwhile recommending commensurate-or-better
>> strength for the hash in this RR compared with the hash used
>> in the x.509 cert signing alg?
>
> I would want to see a security analysis first. In fact, as long as the hash used in the protecting DNSSEC is "strong enough", I'm not sure that there any attack, is there?

I'm ok with no such rule, but think it ought be thrashed a
bit, so I'm happy to just open the discussion and let anyone
else that cares take it up.

>> - "If DANE fails then fallback to TLS," seems to open up a
>> way for an active attacker (say someone who's taken over
>> my home AP) and who's gotten a faked cert and inserted that
>> into a TLS handshake to win the game by simply buggering
>> up the DANE RR bits. Maybe differentiate between DANE
>> matching failure vs. DNSSEC failures? (Not sure myself
>> since we start to leak over into policy quickly with
>> rules in this area.)
>
> Urrrgh. Worthy discussion and probably will turn into paragraphs in the doc.

I think that'll be needed.

>> - Sort-of editorial: there are too many "if the client
>> trusts..." type statements. I'm sure that'll get better
>> over time.
>
> Wording suggestions greatly appreciated.

I'm sure you'll get 'em. I think its a form better avoided
though wherever possible since each occurrence is a way to
break interop. In order to make a suggestion, maybe think
about phrasing these as "clients SHOULD do unless
" if possible. I'm ok waiting to see what you come
up with and commenting on that again later if that helps.

>> - I'd argue to drop the discussion about exclusion. I
>> think it only confuses.
>
> It's the term we still hear used, however.

Not IMO a good term to use. s/that// would be fine by me.
Can be dealt with later.

>> - I'd like to understand how or whether I can use this
>> RR for bare-key protocols. I'm not asking that that all
>> be worked out now, but only to be convinced that it can
>> be done later if useful, and to know whether it'd work
>> based solely on new registry entries for the IANA
>> registries defined in this document or if I'd need a
>> new RR or whatever.
>
> No, it's for TLS only, which requires a PKIX cert. If there is consensus in the WG to extend it to other protocols, and the extra flexibility is worth it, we can extend it; up to now, no one has shown interest, given that the most obvious bare-key target, SSH, already has its own RRType.

So I don't know the details of the SSH RR type. I guess
I ought look. This WG however has IPsec-related milestones
and so the question will need answering ("can the TLSA RR
work for IPsec?"). I happen to think it ought be clear
whether or not the TLSA RR is (D)TLS-only or not before
it gets finished. For me, the answer to that only gets
interesting for protocols that could work with bare
keys. Again, this is one its ok to figure out a bit
later.

>> - And lastly, the big one: the -00 version is silent on
>> the "last hop" problem. At minimum I expected a TBD, and
>> I sure hope that'll be there in a later version. Right?
>
> Wrong. That work is happening in the DNSEXT WG. Well, it isn't yet, but there is now a draft and a discussion.

So I guess my eyes passed over the non-existent reference to
that possibly existent draft and got fixated on the DANE
charter. That's liable to keep happening, my eyes reliably
inform me:-)

Seriously though, this is needed if DANE is not to be a
way to weaken TLS. (Which I-D do you mean?)

>> Other than that last point, this is pretty good.
>
> I'm interested in how we can say "must use last-hop technology X" when X doesn't exist. Wording suggestions appreciated.

I think the charter text is good here - reference "X" if
it exists or else document it if necessary. Some satisfactory
"X" is clearly, (by my take on the last BoF), necessary
before this WG can meet the "don't make it worse" goal you
yourself posited for the WG, right?

(I could understand if you didn't want to have to write
all the text describing "X" in this I-D, and I guess that's
one for the chairs.)

S.

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03D333A6E1E for ; Mon, 13 Dec 2010 17:17:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOSaxTn6hmka for ; Mon, 13 Dec 2010 17:17:02 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 227BE3A6D4F for ; Mon, 13 Dec 2010 17:17:02 -0800 (PST)
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 C427EC4D0; Mon, 13 Dec 2010 20:18:40 -0500 (EST)
Date: Mon, 13 Dec 2010 20:18:40 -0500 (EST)
From: Paul Wouters
To: Paul Hoffman
In-Reply-To:
Message-ID:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 14 Dec 2010 01:17:03 -0000

On Mon, 13 Dec 2010, Paul Hoffman wrote:

> I'm interested in how we can say "must use last-hop technology X" when X doesn't exist. Wording suggestions appreciated.

TLSA records must only be trusted if they were obtained from a trusted
source. This could be a localhost resolver answer with the AD bit set, an
inline validating resolver library primed with the proper trust anchors,
or obtained from a remote nameserver to which one has a secured channel
of communication.

[ perhaps they got be stored with TTL in the app too, so that frequent
network moves would not invalida the data, but possible this is
already covered in the application usage of DNS in general ]

Paul

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EE923A6E1A for ; Mon, 13 Dec 2010 17:10:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxKwKnkSd5PU for ; Mon, 13 Dec 2010 17:10:28 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 06A3E3A6D4F for ; Mon, 13 Dec 2010 17:10:27 -0800 (PST)
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 8227DC4CA; Mon, 13 Dec 2010 20:12:05 -0500 (EST)
Date: Mon, 13 Dec 2010 20:12:05 -0500 (EST)
From: Paul Wouters
To: Ilari Liusvaara
In-Reply-To: <[email-masked]>
Message-ID:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]> <[email-masked]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 14 Dec 2010 01:10:29 -0000

On Tue, 14 Dec 2010, Ilari Liusvaara wrote:

Have not gone through the entire draf yet, but:

>> - If an intermediate CA were compromised, then a DNS admin could
>> obviate the revocation of the relevant CA cert by adding an RR.
>> Not that likely, and detectable, but maybe worth a security
>> consideration paragraph since such a case might be fairly
>> catastrophic as-is, but would be made worse with DANE.
>
> That's admins doing stupid things then. The webmaster would for
> sure hear about the compromise (required for key rollover!)
> and get the DNS updated.

Yes. This is the counter-example of the CAA record. I still think
it is best to limit the interactions of the two authentication
schemes (CAs and dnssec) as much as possible. And while I would
lik the CA not to make statements about dnssec, so should dnssec
not make statement about (intermediate) CA's.

>> - "If DANE fails then fallback to TLS," seems to open up a
>> way for an active attacker (say someone who's taken over
>> my home AP) and who's gotten a faked cert and inserted that
>> into a TLS handshake to win the game by simply buggering
>> up the DANE RR bits.
>
> Only possible by downgrading entiere DNSSEC away (which makes
> client expecting signed root to scream really loud).

The question is what to do with the TLSA record if:

1) the record does not validate (servfail)
2) the record validates but the content does not match the
deployed key/cert
3) the record is there, but we did not get last-mile dnssec

1) includes a "stripping DNSSEC" rogue nameserver, or a nameserver
that is dnssec-unaware. Sometimes this will fail further up the
chain (eg if RRSIG for root data is already stripped) so this
could also influence the clients ability to look up the A record
to begin with. If dnssec works for everything else in the same
zone but not the TLSA record, I'd throw an obvious error, as that
would most likely be an active attack. If it fails higher up in the
chain, perhaps ignore (but not complain) about the TLSA record.

2) is either a sysadmin mistake, or a MITM, and I think an error should
also be thrown notifying the user. Alternatively, one could silently
fail here and let the CA policies do something, but that might be more
dangerous in the case of a rogue/bad CA/cert that is used (eg the * cert
via a MITM attack)

3) here I think we should completely ignore the TLSA record. Even though
it has some value against active attacks only using an IP redirector,
it is just too dangerous that the attacker also modified the TLSA record.

>> - I'd like to understand how or whether I can use this
>> RR for bare-key protocols. I'm not asking that that all
>> be worked out now, but only to be convinced that it can
>> be done later if useful, and to know whether it'd work
>> based solely on new registry entries for the IANA
>> registries defined in this document or if I'd need a
>> new RR or whatever.
>
> This is for TLS, where bare-key would only be possible if there was
> a bare-key certificate type. For IPSEC, which has one, one would
> follow its certificate type numbers.

I'm not sure I follow this. This does not refer to IPSECKEY (RFC4025)

Paul

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAA7C3A6E21 for ; Mon, 13 Dec 2010 17:01:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.306
X-Spam-Level:
X-Spam-Status: No, score=-3.306 tagged_above=-999 required=5 tests=[AWL=0.292, 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 Ffjuj1-ZCsS8 for ; Mon, 13 Dec 2010 17:01:21 -0800 (PST)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id D71633A6D4F for ; Mon, 13 Dec 2010 17:01:20 -0800 (PST)
Received: by yxt33 with SMTP id 33so52301yxt.31 for ; Mon, 13 Dec 2010 17:02:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=GQ/zUUI642WcmXx0khj1i3ID/Unjh+eMRK78fmJmhCg=; b=sIY5xnOJn+oLqeXUS5ofYzUUhwpOpx/IST6HeN1hgn/xUl2udBr6uVFzoaxe085dTu +/N1lM01wdcsUXRe9/HnTiXqkMHOHxnNFuHnRvAnIqasaffKpRHmN3nbfUBpR5rzFq7u 21/tAsqctedY7qRX2DokUGdrnBBA0UagBpHnY=
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=ujyWFkpQejExacoGOgDzaNdc/AZEOJ8IjDffq4cnN1M3F2EtcDBKTDDvFh1l617ddk M8ddln3tk2tH5X1uL7bzi4v5j3iPRfsWUnaenA/Fht0Wz0kTn5poY2wjM+eO5TE9t2ey +mn8Z6LATOzbXkgBOwgnUbltQWRwIGlk6RACY=
MIME-Version: 1.0
Received: by 10.100.195.2 with SMTP id s2mr914084anf.35.1292288579264; Mon, 13 Dec 2010 17:02:59 -0800 (PST)
Received: by 10.100.31.8 with HTTP; Mon, 13 Dec 2010 17:02:59 -0800 (PST)
In-Reply-To:
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]>
Date: Mon, 13 Dec 2010 20:02:59 -0500
Message-ID:
From: Phillip Hallam-Baker
To: Paul Hoffman
Content-Type: multipart/mixed; boundary=0016e644ba16b6e38a04975461d5
Cc: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 14 Dec 2010 01:01:24 -0000

--0016e644ba16b6e38a04975461d5
Content-Type: multipart/alternative; boundary=0016e644ba16b6e37e04975461d3

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

Oh, security considerations, I have some text that may be useful. See
attached.

This is pretty pessimistic and relates to the design I was working on at the
time. But most should carry over.

On Mon, Dec 13, 2010 at 7:20 PM, Paul Hoffman wrote:

> At 11:25 PM +0000 12/13/10, Stephen Farrell wrote:
> >Pretty good.
>
> C'mon, you're usually pricklier than that! :-)
>
> >Questions below. Not expecting fully worked our answers now,
> >but am expecting them at some point.
>
> As Warren said earlier, we have a WG secretary, and he'll be opening issues
> on the WG issue tracker. We can tackle them at any time.
>
> >- How are self-signed certs handled? Are they type 1/2 or 3/4? I
> >think picking one and explicitly saying that's how its done would
> >be best. (I don't care which, I just care that we say exactly how
> >to use self-signed certs with DANE.)
>
> Yes. That is, if it is a self-signed cert used as an end-entity cert, it is
> 1/2; if it is used as a CA cert, it is 3/4. That's why we differentiated by
> semantics, not the format.
>
> >- How is a hash (or certificate) compared to a trust anchor? 5280
> >doesn't specify a TA format, though we mostly use self-signed certs.
> >(Does anything use something else? Does anyone really use rfc 5914
> >for this?) Might be a bit of a barney to be had about that since
> >its hard to pick a format that everyone could use, unless everyone
> >has self-signed certs or you go to the bare public key.
>
> Good point. We should say "...as long as your trust anchors are stored as
> self-signed certs".
>
> >- If an intermediate CA were compromised, then a DNS admin could
> >obviate the revocation of the relevant CA cert by adding an RR.
> >Not that likely, and detectable, but maybe worth a security
> >consideration paragraph since such a case might be fairly
> >catastrophic as-is, but would be made worse with DANE.
>
> Good call, yes.
>
> >- Practically, we do have an informal partial-order of hash
> >function strength (md5,sha-1,sha-2). I don't think so, but
> >would be it worthwhile recommending commensurate-or-better
> >strength for the hash in this RR compared with the hash used
> >in the x.509 cert signing alg?
>
> I would want to see a security analysis first. In fact, as long as the hash
> used in the protecting DNSSEC is "strong enough", I'm not sure that there
> any attack, is there?
>
> >- "If DANE fails then fallback to TLS," seems to open up a
> >way for an active attacker (say someone who's taken over
> >my home AP) and who's gotten a faked cert and inserted that
> >into a TLS handshake to win the game by simply buggering
> >up the DANE RR bits. Maybe differentiate between DANE
> >matching failure vs. DNSSEC failures? (Not sure myself
> >since we start to leak over into policy quickly with
> >rules in this area.)
>
> Urrrgh. Worthy discussion and probably will turn into paragraphs in the
> doc.
>
> >- Sort-of editorial: there are too many "if the client
> >trusts..." type statements. I'm sure that'll get better
> >over time.
>
> Wording suggestions greatly appreciated.
>
> >- I'd argue to drop the discussion about exclusion. I
> >think it only confuses.
>
> It's the term we still hear used, however.
>
> >- I'd like to understand how or whether I can use this
> >RR for bare-key protocols. I'm not asking that that all
> >be worked out now, but only to be convinced that it can
> >be done later if useful, and to know whether it'd work
> >based solely on new registry entries for the IANA
> >registries defined in this document or if I'd need a
> >new RR or whatever.
>
> No, it's for TLS only, which requires a PKIX cert. If there is consensus in
> the WG to extend it to other protocols, and the extra flexibility is worth
> it, we can extend it; up to now, no one has shown interest, given that the
> most obvious bare-key target, SSH, already has its own RRType.
>
> >- And lastly, the big one: the -00 version is silent on
> >the "last hop" problem. At minimum I expected a TBD, and
> >I sure hope that'll be there in a later version. Right?
>
> Wrong. That work is happening in the DNSEXT WG. Well, it isn't yet, but
> there is now a draft and a discussion.
>
> >Other than that last point, this is pretty good.
>
> I'm interested in how we can say "must use last-hop technology X" when X
> doesn't exist. Wording suggestions appreciated.
>
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

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

Oh, security considerations, I have some text that may be useful. See attac=
hed.

This is pretty pessimistic and relates to the desig=
n I was working on at the time. But most should carry over.

On Mon, Dec 13, 2010 at 7:20 PM, Paul Hoffma=
n <paul.hoffm=
[email-masked]> wrote:

At 11:25 PM +0000 12/13/10, Stephen Farrell wrote:

>Pretty good.

C'mon, you're usually pricklier than that! :-)

>Questions below. Not expecting fully worked our answers now,

>but am expecting them at some point.

As Warren said earlier, we have a WG secretary, and he'll be open=
ing issues on the WG issue tracker. We can tackle them at any time.

>- How are self-signed certs handled? Are they type 1/2 or 3/4? I

>think picking one and explicitly saying that's how its done would
>be best. (I don't care which, I just care that we say exactly how
>to use self-signed certs with DANE.)

Yes. That is, if it is a self-signed cert used as an end-entity cert,=
it is 1/2; if it is used as a CA cert, it is 3/4. That's why we differ=
entiated by semantics, not the format.

>- How is a hash (or certificate) compared to a trust anchor? 5280

>doesn't specify a TA format, though we mostly use self-signed certs=
.

>(Does anything use something else? Does anyone really use rfc 5914

>for this?) Might be a bit of a barney to be had about that since

>its hard to pick a format that everyone could use, unless everyone

>has self-signed certs or you go to the bare public key.

Good point. We should say "...as long as your trust anchors are =
stored as self-signed certs".

>- If an intermediate CA were compromised, then a DNS admin could

>obviate the revocation of the relevant CA cert by adding an RR.

>Not that likely, and detectable, but maybe worth a security

>consideration paragraph since such a case might be fairly

>catastrophic as-is, but would be made worse with DANE.

Good call, yes.

>- Practically, we do have an informal partial-order of hash

>function strength (md5,sha-1,sha-2). I don't think so, but

>would be it worthwhile recommending commensurate-or-better

>strength for the hash in this RR compared with the hash used

>in the x.509 cert signing alg?

I would want to see a security analysis first. In fact, as long as th=
e hash used in the protecting DNSSEC is "strong enough", I'm =
not sure that there any attack, is there?

>- "If DANE fails then fallback to TLS," seems to open up a
>way for an active attacker (say someone who's taken over

>my home AP) and who's gotten a faked cert and inserted that

>into a TLS handshake to win the game by simply buggering

>up the DANE RR bits. Maybe differentiate between DANE

>matching failure vs. DNSSEC failures? (Not sure myself

>since we start to leak over into policy quickly with

>rules in this area.)

Urrrgh. Worthy discussion and probably will turn into paragraphs in t=
he doc.

>- Sort-of editorial: there are too many "if the client

>trusts..." type statements. I'm sure that'll get better
>over time.

Wording suggestions greatly appreciated.

>- I'd argue to drop the discussion about exclusion. I

>think it only confuses.

It's the term we still hear used, however.

>- I'd like to understand how or whether I can use this

>RR for bare-key protocols. I'm not asking that that all

>be worked out now, but only to be convinced that it can

>be done later if useful, and to know whether it'd work

>based solely on new registry entries for the IANA

>registries defined in this document or if I'd need a

>new RR or whatever.

No, it's for TLS only, which requires a PKIX cert. If there is co=
nsensus in the WG to extend it to other protocols, and the extra flexibilit=
y is worth it, we can extend it; up to now, no one has shown interest, give=
n that the most obvious bare-key target, SSH, already has its own RRType.

>- And lastly, the big one: the -00 version is silent on

>the "last hop" problem. At minimum I expected a TBD, and

>I sure hope that'll be there in a later version. Right?

Wrong. That work is happening in the DNSEXT WG. Well, it isn't ye=
t, but there is now a draft and a discussion.

>Other than that last point, this is pretty good.

I'm interested in how we can say "must use last-hop technolo=
gy X" when X doesn't exist. Wording suggestions appreciated.

--Paul Hoffman, Director

--VPN Consortium

__________________________________=
_____________

keyassure mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/keyassure

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

--0016e644ba16b6e37e04975461d3--
--0016e644ba16b6e38a04975461d5
Content-Type: text/xml; charset=US-ASCII; name="draft-hallambaker-certhash-01.xml"
Content-Disposition: attachment;
filename="draft-hallambaker-certhash-01.xml"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_gho37evd0

PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVMtQVNDSUkiPz4KCjwhRE9DVFlQRSByZmMg
U1lTVEVNICJyZmMyNjI5LmR0ZCIgWwoKCiAgICA8IUVOVElUWSBSRkMyMTE5IFNZU1RFTSAiaHR0
cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3JmYy9iaWJ4bWwvcmVmZXJlbmNlLlJGQy4yMTE5
LnhtbCI+CiAgICA8IUVOVElUWSBSRkMyNjI5IFNZU1RFTSAiaHR0cDovL3htbC5yZXNvdXJjZS5v
cmcvcHVibGljL3JmYy9iaWJ4bWwvcmVmZXJlbmNlLlJGQy4yNjI5LnhtbCI+CiAgICA8IUVOVElU
WSBSRkMzNTUyIFNZU1RFTSAiaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3JmYy9iaWJ4
bWwvcmVmZXJlbmNlLlJGQy4zNTUyLnhtbCI+CiAgICA8IUVOVElUWSBSRkM0MDI1IFNZU1RFTSAi
aHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3JmYy9iaWJ4bWwvcmVmZXJlbmNlLlJGQy40
MDI1LnhtbCI+CiAgICA8IUVOVElUWSBSRkM0MDMzIFNZU1RFTSAiaHR0cDovL3htbC5yZXNvdXJj
ZS5vcmcvcHVibGljL3JmYy9iaWJ4bWwvcmVmZXJlbmNlLlJGQy40MDMzLnhtbCI+CiAgICA8IUVO
VElUWSBSRkM0MDM0IFNZU1RFTSAiaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3JmYy9i
aWJ4bWwvcmVmZXJlbmNlLlJGQy40MDM0LnhtbCI+CiAgICA8IUVOVElUWSBSRkM0MDM1IFNZU1RF
TSAiaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3JmYy9iaWJ4bWwvcmVmZXJlbmNlLlJG
Qy40MDM1LnhtbCI+CiAgICA8IUVOVElUWSBSRkM0MjU1IFNZU1RFTSAiaHR0cDovL3htbC5yZXNv
dXJjZS5vcmcvcHVibGljL3JmYy9iaWJ4bWwvcmVmZXJlbmNlLlJGQy40MjU1LnhtbCI+CiAgICA8
IUVOVElUWSBSRkM0Mzk4IFNZU1RFTSAiaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3Jm
Yy9iaWJ4bWwvcmVmZXJlbmNlLlJGQy40Mzk4LnhtbCI+CiAgICA8IUVOVElUWSBSRkM1MjQ2IFNZ
U1RFTSAiaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3JmYy9iaWJ4bWwvcmVmZXJlbmNl
LlJGQy41MjQ2LnhtbCI+Cl0+Cjw/eG1sLXN0eWxlc2hlZXQgdHlwZT0ndGV4dC94c2wnIGhyZWY9
J3JmYzI2MjkueHNsdCcgPz4KPD9yZmMgc3RyaWN0PSJ5ZXMiID8+Cjw/cmZjIHRvYz0ieWVzIj8+
Cjw/cmZjIHRvY2RlcHRoPSI0Ij8+Cjw/cmZjIHN5bXJlZnM9InllcyI/Pgo8P3JmYyBzb3J0cmVm
cz0ieWVzIiA/Pgo8P3JmYyBjb21wYWN0PSJ5ZXMiID8+Cjw/cmZjIHN1YmNvbXBhY3Q9Im5vIiA/
Pgo8cmZjIGNhdGVnb3J5PSJpbmZvIiBkb2NOYW1lPSJkcmFmdC1oYWxsYW1iYWtlci1jZXJ0aGFz
aC0wMSIgaXByPSJub01vZGlmaWNhdGlvblRydXN0MjAwOTAyIj4KCiAgICA8ZnJvbnQ+CiAgICAg
ICAgPHRpdGxlIGFiYnJldj0iRE5TIENFUlQgUmVjb3JkcyBmb3IgS2V5IEFzc3VyYW5jZSI+VXNl
IG9mIEROUyBDRVJUIFJlY29yZHMgZm9yIEtleSBBc3NlcnRpb25mPC90aXRsZT4KICAgICAgICA8
YXV0aG9yIGZ1bGxuYW1lPSJQaGlsbGlwIEhhbGxhbS1CYWtlciIgaW5pdGlhbHM9IlAuIE0uIgog
ICAgICAgICAgICAgICAgc3VybmFtZT0iSGFsbGFtLUJha2VyIj4KICAgICAgICAgICAgPG9yZ2Fu
aXphdGlvbj5Db21vZG8gSW5jLjwvb3JnYW5pemF0aW9uPgogICAgICAgICAgICA8YWRkcmVzcz4K
ICAgICAgICAgICAgICAgIDxlbWFpbD5waGlsbGlwaEBjb21vZG8uY29tPC9lbWFpbD4KICAgICAg
ICAgICAgPC9hZGRyZXNzPgogICAgICAgIDwvYXV0aG9yPgogICAgICAgIDxhdXRob3IgZnVsbG5h
bWU9IkJyaWFuIFNtaXRoIiBpbml0aWFscz0iQi4iCiAgICAgICAgICAgICAgICAgICAgIHN1cm5h
bWU9IlNtaXRoIj4KICAgICAgICAgICAgPG9yZ2FuaXphdGlvbj5ETlMuY29tPC9vcmdhbml6YXRp
b24+CiAgICAgICAgICAgIDxhZGRyZXNzPgogICAgICAgICAgICAgICAgPGVtYWlsPmJyaWFuQGRu
cy5jb208L2VtYWlsPgogICAgICAgICAgICA8L2FkZHJlc3M+CiAgICAgICAgPC9hdXRob3I+CiAg
ICAKCiAgICAgICAgPGRhdGUgbW9udGg9IlNlcHRlbWJlciIgeWVhcj0iMjAxMCIgLz4KICAgICAg
ICA8YXJlYT5HZW5lcmFsPC9hcmVhPgogICAgICAgIDx3b3JrZ3JvdXA+SW50ZXJuZXQgRW5naW5l
ZXJpbmcgVGFzayBGb3JjZTwvd29ya2dyb3VwPgogICAgICAgIDxrZXl3b3JkPkROUzwva2V5d29y
ZD4KICAgICAgICA8YWJzdHJhY3Q+CiAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgRGVw
bG95bWVudCBvZiBETlNTRUMgb3BlbnMgdXAgdGhlIHBvc3NpYmlsaXR5IG9mIG5ldyBtZWNoYW5p
c21zIGZvciBhc3N1cmluZwogICAgICAgICAgICAgICAgYXBwbGljYXRpb24ga2V5cy4gVGhpcyBk
b2N1bWVudCBleHRlbmRzIHRoZSB1c2Ugb2YgdGhlIEROUyBDRVJUIHJlc291cmNlCiAgICAgICAg
ICAgICAgICByZWNvcmQgYW5kIGRlZmluZXMgWC41MDl2MyBleHRlbnN1aW9ucyB0byBzdXBwb3J0
IGtleSBhc3N1cmFuY2UgbWVjaGFuaXNtcwogICAgICAgICAgICAgICAgZm9yIHVzZSB3aXRoIFRM
UyBhbmQgb3RoZXIgY2VydGlmaWNhdGUgYmFzZWQgc2VjdXJpdHkgcHJvdG9jb2xzIGFuZAogICAg
ICAgICAgICAgICAgcHJvdmlkZXMgYSBjb21wcmVoZW5zaXZlIGFzc2Vzc21lbnQgb2YgdGhlIHNl
Y3VyaXR5IHRodXMgYWNoaWV2ZWQuCiAgICAgICAgICAgIDwvdD4KICAgICAgICA8L2Fic3RyYWN0
PgogICAgPC9mcm9udD4KCiAgICA8bWlkZGxlPgogICAgICAgIDxzZWN0aW9uIHRpdGxlPSJSZXF1
aXJlbWVudHMgTGFuZ3VhZ2UiPgogICAgICAgICAgICA8dD4KICAgICAgICAgICAgICAgIFRoZSBr
ZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwg
Tk9UIiwKICAgICAgICAgICAgICAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRF
RCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzCiAgICAgICAgICAgICAgICBkb2N1bWVu
dCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIDx4cmVmIHRhcmdldD0iUkZD
MjExOSI+UkZDIDIxMTk8L3hyZWY+LgogICAgICAgICAgICA8L3Q+CiAgICAgICAgPC9zZWN0aW9u
PgoKICAgICAgICA8c2VjdGlvbiB0aXRsZT0iSW50cm9kdWN0aW9uIj4KICAgICAgICAgICAgPHQ+
CiAgICAgICAgICAgICAgICBUaGUgRE5TIENFUlQgcmVzb3VyY2UgcmVjb3JkIGRlZmluZWQgaW4g
PHhyZWYgdGFyZ2V0PSJSRkM0Mzk4Ij5SRkMgNDM5ODwveHJlZj4KICAgICAgICAgICAgICAgIHNw
ZWNpZmllcyBhIG1lYW5zIG9mIHVzaW5nIHRoZSBETlMgZm9yIGRpc2NvdmVyeSBvZiBwdWJsaWMg
a2V5IGluZm9ybWF0aW9uCiAgICAgICAgICAgICAgICBpbmNsdWRpbmcgY2VydGlmaWNhdGVzLCBj
ZXJ0aWZpY2F0ZSByZXZvY2F0aW9uIGxpc3RzIGFuZCB2YXJpb3VzIGtleSBzaWduaW5nCiAgICAg
ICAgICAgICAgICBmb3JtYXRzLgogICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgIDx0PgogICAg
ICAgICAgICAgICAgSW4gdGhlIG1vZGUgb2YgdXNlIG9yaWdpbmFsbHkgc3BlY2lmaWVkLCB0aGUg
RE5TIGRpZCBub3QgcHJvdmlkZSBhdXRoZW50aWNhdGlvbgogICAgICAgICAgICAgICAgc2Vydmlj
ZXMgYW5kIHRodXMgZGlzdHJpYnV0aW9uIG9mIHB1YmxpYyBrZXkgaW5mb3JtYXRpb24gd2FzIGxp
bWl0ZWQgdG8KICAgICAgICAgICAgICAgIGZvcm1hdHMgdGhhdCB3ZXJlIHNlbGYtYXV0aGVudGlj
YXRpbmcuIEl0IHdhcyBzdHJvbmdseSBpbXBsaWVkIGJ1dCBuZXZlcgogICAgICAgICAgICAgICAg
Z3VhcmFudGVlZCB0aGF0CiAgICAgICAgICAgICAgICBhIENFUlQgcmVjb3JkIGF0IHRoZSBETlMg
c2VydmljZSBsYWJlbCAnd3d3LmV4YW1wbGUuY29tJyBjb250YWluaW5nIGEKICAgICAgICAgICAg
ICAgIFBLSVggY2VydGlmaWNhdGUgdHlwZSB3b3VsZCBjb250YWluIGEgdmFsaWQgY2VydGlmaWNh
dGUgdGhhdCB0aGUgZG9tYWluIG5hbWUKICAgICAgICAgICAgICAgIG93bmVyIG9mIGV4YW1wbGUu
Y29tIGRpZCAgaW50ZW5kIHRvIHByb3ZpZGUgYSB0cnVzdGVkIHN1YmplY3Qga2V5IHRvIGJlIHVz
ZWQKICAgICAgICAgICAgICAgIHRvIHNlY3VyZSBhY2Nlc3MgdG8gd3d3LmV4YW1wbGUuY29tLiBB
IHJlbHlpbmcgcGFydHkgdGhhdCByZXRyZWl2ZWQgdGhlIGNlcnRpZmljYXRlCiAgICAgICAgICAg
ICAgICBkYXRhIGZyb20gdGhlIEROUyBDRVJUIHJlY29yZCB3YXMgc3RpbGwgcmVxdWlyZWQgdG8g
cGVyZm9ybSBQS0lYCiAgICAgICAgICAgICAgICBwYXRoIHZhbGlkYXRpb24gYmVmb3JlIHJlbHlp
bmcgb24gaXQuCiAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAg
ICBUaGUgZGVwbG95bWVudCBvZiBETlMgU2VjdXJpdHkgRXh0ZW5zaW9ucwogICAgICAgICAgICAg
ICAgPHhyZWYgdGFyZ2V0PSJSRkM0MDMzIj48L3hyZWY+LDx4cmVmIHRhcmdldD0iUkZDNDAzNCI+
PC94cmVmPiBwZXJtaXRzCiAgICAgICAgICAgICAgICBzaWduaW5nIG9mIEROUyBSZXNvdXJjZSBS
ZWNvcmRzIChSUikgaW5jbHVkaW5nIENFUlQuIEl0IGlzIHRodXMgbm93IHBvc3NpYmxlCiAgICAg
ICAgICAgICAgICB0byB1c2UgdGhlIEROUyBmb3IgYm90aCBjZXJ0aWZpY2F0ZSBwdWJsaWNhdGlv
biB1c2luZyB0aGUgZXhpc3RpbmcKICAgICAgICAgICAgICAgIGNlcnRpZmljYXRlIHR5cGVzIGFu
ZCBjZXJ0aWZpY2F0ZSBhc3N1cmFuY2UgdGhyb3VnaCB0aGUgQVNTRVJUIGFuZCBEUFRSCiAgICAg
ICAgICAgICAgICByZWNvcmRzIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50LgogICAgICAgICAg
ICA8L3Q+CiAgICAgICAgICAgIDxzZWN0aW9uIHRpdGxlPSJUaGUgQVNTVVJFIENlcnRpZmljYXRl
IFR5cGUiPgoKICAgICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgICAgIFVzZSBvZiB0
aGUgQVNTVVJFIGNlcnRpZmljYXRlIHR5cGUgaW4gYSBETlMgQ0VSVCBSUgogICAgICAgICAgICAg
ICAgICAgIGFsbG93cyBhIGJpbmRpbmcgdG8gYmUgYXNzZXJ0ZWQgYmV0d2VlbgogICAgICAgICAg
ICAgICAgICAgIGEgRE5TIFNlcnZpY2UgTGFiZWwgYW5kIGEgUEtJWCBwdWJsaWMga2V5IENlcnRp
ZmljYXRlLgogICAgICAgICAgICAgICAgICAgIEFzIHdpdGggYW55IGFzc2VydGlvbiBjb25jZXJu
aW5nIHB1YmxpYyBrZXkgaW5mb3JtYXRpb24sCiAgICAgICAgICAgICAgICAgICAgdGhlIHRydXN0
d29ydGhpbmVzcyBvZiB0aGUgYXNzZXJ0aW9uIGlzIGRlcGVuZGVudCBvbiB0aGUKICAgICAgICAg
ICAgICAgICAgICB0cnVzdHdvcnRoaW5lc3Mgb2YgdGhlIHBhcnR5IHB1cnBvcnRlZGx5IG1ha2lu
ZyB0aGUgYXNzZXJ0aW9uLAogICAgICAgICAgICAgICAgICAgIHRoZSB0cnVzdHdvcnRoaW5lc3Mg
b2YgdGhlIG1lY2hhbmlzbSBieSB3aGljaCB0aGUgYXNzZXJ0aW9uCiAgICAgICAgICAgICAgICAg
ICAgaXMgYXV0aGVudGljYXRlZCBhbmQgdGhlIGNpcmN1bXN0YW5jZXMgaW4gd2hpY2ggdGhlIGFz
c2VydGlvbiBpcyBtYWRlLgogICAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgICAgPHNl
Y3Rpb24gdGl0bGU9IlB1Ymxpc2hlciBJbnRlbnRpb24iPgogICAgICAgICAgICAgICAgICAgIDx0
PgogICAgICAgICAgICAgICAgICAgICAgICBXaGVuIGEgRE5TIENFUlQgUlIgY29udGFpbmluZyBk
YXRhIGZvciB0aGUgQVNTVVJFIGNlcnRpZmljYXRlCiAgICAgICAgICAgICAgICAgICAgICAgIHR5
cGUgaXMgcHVibGlzaGVkIGluIGEgem9uZSBzaWduZWQgdXNpbmcgRE5TU0VDLCBhIHJlbHlpbmcg
cGFydHkKICAgICAgICAgICAgICAgICAgICAgICAgU0hPVUxEIGluZmVyIHRoYXQgaXQgd2FzIHRo
ZSBpbnRlbnRpb24gb2YgdGhlIHB1Ymxpc2hlciB0bwogICAgICAgICAgICAgICAgICAgICAgICBl
c3RhYmxpc2ggYW4gYXNzdXJhbmNlIGZvciBhIGNlcnRpZmljYXRlIGluIHRoZSBzYW1lIGZvcm1h
dCBhcwogICAgICAgICAgICAgICAgICAgICAgICB0aGUgY2VydGlmaWNhdGUgd2hvc2UgZGlnZXN0
IHZhbHVlIG1hdGNoZXMgdGhhdCBzcGVjaWZpZWQgaW4KICAgICAgICAgICAgICAgICAgICAgICAg
dGhlIGNlcnRpZmljYXRlIGRhdGEgZmllbGQgaW4gd2hpY2g6CiAgICAgICAgICAgICAgICAgICAg
PC90PgogICAgICAgICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgICAgICAgICA8bGlz
dCBzdHlsZT0iaGFuZ2luZyI+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICA8dCBoYW5nVGV4
dD0iSXNzdWVyOiI+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVGhlIGlzc3VlciBp
ZGVudGl0eSBpcyB0aGUgaWRlbnRpdHkgb2YKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICB0aGUgcHVibGlzaGVyIG9mIHRoZSBETlMgWm9uZS4KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIDwvdD4KICAgICAgICAgICAgICAgICAgICAgICAgICAgIDx0IGhhbmdUZXh0PSJTdWJqZWN0
OiI+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVGhlIHN1YmplY3QgaWRlbnRpdHkg
aXMgdGhlIGRvbWFpbgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNlcnZpY2UgbGFi
ZWwgY29ycmVzcG9uZGluZyB0byB0aGUgQ0VSVCBSUi4KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIDwvdD4KICAgICAgICAgICAgICAgICAgICAgICAgICAgIDx0IGhhbmdUZXh0PSJTaWduYXR1
cmUgRGF0YToiPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIElmIHRoZSBjb3JyZXNw
b25kaW5nIEROUyBTSUcKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSUiBoYXMgYSB2
YWxpZCBzaWduYXR1cmUgaXQgaXMgZXF1aXZhbGVudCB0byBhIHZhbGlkCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgc2lnbmF0dXJlIHVuZGVyIHRoZSBzYW1lIHNpZ25hdHVyZSBrZXkg
b24gdGhlIGFzc2VydGVkCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY2VydGlmaWNh
dGUuCiAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICA8dCBoYW5nVGV4dD0iT3RoZXIgRGF0YSI+CiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgQWxsIG90aGVyIGRhdGEgaXMgY2FycmllZCBhY3Jvc3MKICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBmcm9tIHRoZSBjZXJ0aWZpY2F0ZSB3aG9zZSBkaWdlc3QgdmFsdWUg
bWF0Y2hlcyB0aGF0CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3BlY2lmaWVkIGlu
IHRoZSBjZXJ0aWZpY2F0ZSBkYXRhIGZpZWxkCiAgICAgICAgICAgICAgICAgICAgICAgICAgICA8
L3Q+CiAgICAgICAgICAgICAgICAgICAgICAgIDwvbGlzdD4KICAgICAgICAgICAgICAgICAgICA8
L3Q+CiAgICAgICAgICAgICAgICA8L3NlY3Rpb24+CiAgICAgICAgICAgICAgICA8c2VjdGlvbiB0
aXRsZT0iUmVseWluZyBQYXJ0eSBJbnRlcnByZXRhdGlvbiI+CiAgICAgICAgICAgICAgICAgICAg
PHQ+CiAgICAgICAgICAgICAgICAgICAgICAgIEEgcmVseWluZyBwYXJ0eSBNVVNUIE5PVCBpbmZl
ciBhbnkgaW50ZW50aW9uIG9uIHRoZSBwYXJ0IG9mCiAgICAgICAgICAgICAgICAgICAgICAgIHRo
ZSBwdWJsaXNoZXIgb3RoZXIgdGhhbiB0aG9zZSBzcGVjaWZpZWQgZm9yIHRoZSBBU1NVUkUgcmVj
b3JkLgogICAgICAgICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICAgICAgICA8dD4KICAg
ICAgICAgICAgICAgICAgICAgICAgVGhlIGRlZ3JlZSBvZiB0cnVzdCB0aGF0IGEgcmVseWluZyBw
YXJ0eSBNQVkgcGxhY2UgaW4gdGhlCiAgICAgICAgICAgICAgICAgICAgICAgIGFzc3VyYW5jZSBh
c3NlcnRlZCBpcyBsaW1pdGVkIGJ5IHRoZSByZWx5aW5nIHBhcnR5J3Mga25vd2xlZGdlCiAgICAg
ICAgICAgICAgICAgICAgICAgIG9mIHRoZSB0cnVzdHdvcnRoaW5lc3Mgb2YgdGhlIHNpZ25lciBh
bmQgdGhlIHNpZ25pbmcga2V5LgogICAgICAgICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAg
ICAgICAgICA8dD4KICAgICAgICAgICAgICAgICAgICAgICAgSW4KICAgICAgICAgICAgICAgICAg
ICAgICAgdGhlIGNhc2UgaW4gd2hpY2ggdGhlIHNpZ25lciBpZGVudGl0eSBhbmQgc2lnbmluZyBp
cyBvbmx5CiAgICAgICAgICAgICAgICAgICAgICAgIGVzdGFibGlzaGVkIHRocm91Z2ggdGhlIHVz
ZSBvZiBETlNTRUMsIHRoYXQgYXNzdXJhbmNlIGlzCiAgICAgICAgICAgICAgICAgICAgICAgIGVm
ZmVjdGl2ZWx5IGxpbWl0ZWQgdGhlIGVzdGFibGlzaG1lbnQgb2YgdGhlIGlzc3VlciBhbmQgc3Vi
amVjdAogICAgICAgICAgICAgICAgICAgICAgICBhcyBkZXNjcmliZWQgYWJvdmUgYW5kIG90aGVy
IGRhdGEgdGhhdCByZXN0cmljdHMgdGhlIHZhbGlkaXR5CiAgICAgICAgICAgICAgICAgICAgICAg
IG9yIHNjb3BlIG9mIHVzZSBvZiB0aGUgY2VydGlmaWNhdGUuCiAgICAgICAgICAgICAgICAgICAg
PC90PgoKICAgICAgICAgICAgICAgIDwvc2VjdGlvbj4KICAgICAgICAgICAgICAgIDxzZWN0aW9u
IHRpdGxlPSJDZXJ0aWZpY2F0ZSBGb3JtYXRzIFN1cHBvcnRlZCI+CiAgICAgICAgICAgICAgICAg
ICAgPHQ+CiAgICAgICAgICAgICAgICAgICAgICAgIEFsdGhvdWdoIHRoZSBBU1NVUkUgY2VydGlm
aWNhdGUgdHlwZSBNQVkgaW4gcHJpbmNpcGxlIGJlIHVzZWQKICAgICAgICAgICAgICAgICAgICAg
ICAgdG8gZXN0YWJsaXNoIGFuIGFzc3VyYW5jZSBmb3IgYW55IHB1YmxpYyBrZXkgY2VydGlmaWNh
dGUgdHlwZQogICAgICAgICAgICAgICAgICAgICAgICB0aGF0IGNvbnRhaW5zIGFuIGlzc3Vlciwg
c3ViZWN0IGFuZCBzaW5nYXR1cmUgZGF0YSBmaWVsZCwKICAgICAgICAgICAgICAgICAgICAgICAg
dGhpcyBkb2N1bWVudCBvbmx5IGRlc2NyaWJlcyB0aGUgdXNlIG9mIHRoZSBBU1NVUkUgdHlwZSB3
aXRoCiAgICAgICAgICAgICAgICAgICAgICAgIFBLSVggcHVibGljIGtleSBjZXJ0aWZpY2F0ZXMu
CiAgICAgICAgICAgICAgICAgICAgPC90PgoKICAgICAgICAgICAgICAgICAgICA8dD4KICAgICAg
ICAgICAgICAgICAgICAgICAgUEtJWCBjZXJ0aWZpY2F0ZXMgd2VyZSBjaG9zZW4gYXMgdGhlIGRl
ZmF1bHQgbWVkaXVtIGZvciBleHByZXNzaW5nIHB1YmxpYwogICAgICAgICAgICAgICAgICAgICAg
ICBrZXkgaW5mb3JtYXRpb24gYmVjYXVzZSB0aGV5IGFyZSBib3RoIG5lY2Vzc2FyeSBhbmQgc3Vm
ZmljaWVudC4KICAgICAgICAgICAgICAgICAgICAgICAgU3VwcG9ydCBmb3IgUEtJWCBjZXJ0aWZp
Y2F0ZXMgaXMgbmVjZXNzYXJ5IGJlY2F1c2UKICAgICAgICAgICAgICAgICAgICAgICAgVHJhbnNw
b3J0IExheWVyIFNlY3VyaXR5LCB0aGUgbW9zdCB3aWRlbHkgdXNlZCBjcnlwdG9ncmFwaGljIHBy
b3RvY29sCiAgICAgICAgICAgICAgICAgICAgICAgIHdhcyBkZXNpZ25lZCBmcm9tIHRoZSBvdXRz
ZXQgZm9yIHVzZSB3aXRoIFguNTA5IGNlcnRpZmljYXRlcy4KICAgICAgICAgICAgICAgICAgICAg
ICAgV2hpbGUgdGhlIFRMUyBzcGVjaWZpY2F0aW9uIGhhcyBwcm92aXNpb24gZm9yIG90aGVyIGNl
cnRpZmljYXRlIGZvcm1hdHMsCiAgICAgICAgICAgICAgICAgICAgICAgIGltcGxlbWVudGF0aW9u
IGFuZCB1c2Ugb2YgdGhlc2UgYWx0ZXJuYXRpdmVzIGlzIG5lZ2xpZ2libGUuCiAgICAgICAgICAg
ICAgICAgICAgICAgIFN1cHBvcnQgZm9yIFBLSVggY2VydGlmaWNhdGVzIGlzIHN1ZmZpY2llbnQg
YmVjYXVzZQogICAgICAgICAgICAgICAgICAgICAgICBldmVyeSBwdWJsaWMga2V5IGVuYWJsZWQg
YXBwbGljYXRpb24gb2YgYW55IGNvbnNlcXVlbmNlIGFuZCBldmVyeQogICAgICAgICAgICAgICAg
ICAgICAgICB3aWRlbHkgdXNlZCBjcnlwdG9ncmFwaGljIGNvZGUgYmFzZSBwcm92aWRlcyBzdXBw
b3J0IGZvcgogICAgICAgICAgICAgICAgICAgICAgICBnZW5lcmF0aW5nIGFuZCB1c2luZyBYLjUw
OXYzIGNlcnRpZmljYXRlcyBhY2NvcmRpbmcgdG8gdGhlIFBLSVgKICAgICAgICAgICAgICAgICAg
ICAgICAgcHJvZmlsZS4KICAgICAgICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgICA8
L3NlY3Rpb24+CiAgICAgICAgICAgIDwvc2VjdGlvbj4KICAgICAgICAgICAgPHNlY3Rpb24gdGl0
bGU9IlRoZSBEUFRSIENlcnRpZmljYXRlIFR5cGUiPgoKICAgICAgICAgICAgICAgIDx0PgogICAg
ICAgICAgICAgICAgICAgIExhcmdlIHNjYWxlCiAgICAgICAgICAgICAgICAgICAgW0RQVFIgcmVj
b3JkIG5lZWRlZCB0byBzdXBwb3J0IGxhcmdlIGRlcGxveW1lbnRzIHdpdGggbWFueSBob3N0cyBh
bmQKICAgICAgICAgICAgICAgICAgICBwb3NzaWJsZSB1c2Ugb2Ygd2lsZGNhcmRzXQogICAgICAg
ICAgICAgICAgPC90PgogICAgICAgICAgICA8L3NlY3Rpb24+CiAgICAgICAgPC9zZWN0aW9uPgoK
ICAgICAgICA8c2VjdGlvbiB0aXRsZT0iTWVjaGFuaXNtIj4KICAgICAgICAgICAgPHQ+CiAgICAg
ICAgICAgIDwvdD4KCiAgICAgICAgICAgIDxzZWN0aW9uIHRpdGxlPSJDRVJUIFJlc291cmNlIFJl
Y29yZCBQYXJhbWV0ZXJzIj4KICAgICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgICAg
IFR3byBuZXcgQ0VSVCBjZXJ0aWZpY2F0ZSB0eXBlcyBhcmUgZGVmaW5lZDoKICAgICAgICAgICAg
ICAgIDwvdD4KCiAgICAgICAgICAgICAgICA8dD4KICAgICAgICAgICAgICAgICAgICA8bGlzdD4K
ICAgICAgICAgICAgICAgICAgICAgICAgPHQ+QVNTVVJFPC90PgogICAgICAgICAgICAgICAgICAg
ICAgICA8dD5EUFRSPC90PgogICAgICAgICAgICAgICAgICAgIDwvbGlzdD4KICAgICAgICAgICAg
ICAgIDwvdD4KICAgICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgICAgIFRoZSBDRVJU
IHJlc291cmNlIHJlY29yZCAoUlIpIGhhcyB0aGUgc3RydWN0dXJlIGdpdmVuIGJlbG93LiAgSXRz
IFJSCiAgICAgICAgICAgICAgICAgICAgdHlwZSBjb2RlIGlzIDM3LgogICAgICAgICAgICAgICAg
PC90PgogICAgICAgICAgICAgICAgPGZpZ3VyZT4KICAgICAgICAgICAgICAgICAgICA8YXJ0d29y
az4KPCFbQ0RBVEFbICAgICAgICAgICAgICAgICAgICAxIDEgMSAxIDEgMSAxIDEgMSAxIDIgMiAy
IDIgMiAyIDIgMiAyIDIgMyAzCjAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDgg
OSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQorLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwp8ICAgICAgICAgICAgIHR5cGUgICAg
ICAgICAgICAgIHwgICAgICAgICAgICAga2V5IHRhZyAgICAgICAgICAgfAorLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwp8ICAg
YWxnb3JpdGhtICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgLworLS0tLS0tLS0tLS0tLS0tKyAgICAgICAgICAgIGNlcnRpZmljYXRlIGRhdGEgICAgICAg
ICAgICAgICAgICAgLwovICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgLworLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstfF1dPgogICAgICAgICAgICAgICAgICAgIDwv
YXJ0d29yaz4KICAgICAgICAgICAgICAgIDwvZmlndXJlPgogICAgICAgICAgICAgICAgPHQ+CiAg
ICAgICAgICAgICAgICAgICAgVGhlIHR5cGUgZmllbGQgaXMgdGhlIGNlcnRpZmljYXRlIHR5cGUg
YXMgZGVmaW5lZCBiZWxvdy4KICAgICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICAgIDx0
PgogICAgICAgICAgICAgICAgICAgIFRoZSBrZXkgdGFnIGZpZWxkIHVzZWQgZm9yIGtleSBzZWxl
Y3Rpb24gYXMgc3BlY2lmaWVkIGluCiAgICAgICAgICAgICAgICAgICAgPHhyZWYgdGFyZ2V0PSJS
RkM0MDM0Ij5SRkMgNDAzNDwveHJlZj4gU2VjdGlvbiA1LjEuMS4KICAgICAgICAgICAgICAgIDwv
dD4KICAgICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgICAgIFRoZSBhbGdvcml0aG0g
ZmllbGQgaXMgdGhlIGFsZ29yaXRobSBjb2RlIGZvciB0aGUgZGlnZXN0IGFsZ29yaXRobQogICAg
ICAgICAgICAgICAgICAgIGFzIHNwZWNpZmllZCBpbiB0aGUgSUFOQSByZWdpc3RyeQogICAgICAg
ICAgICAgICAgICAgIERlbGVnYXRpb24gU2lnbmVyIChEUykgUmVzb3VyY2UgUmVjb3JkIChSUikg
VHlwZSBEaWdlc3QgQWxnb3JpdGhtcy4KICAgICAgICAgICAgICAgIDwvdD4KCgogICAgICAgICAg
ICAgICAgPHNlY3Rpb24gdGl0bGU9IkFTU1VSRSI+CiAgICAgICAgICAgICAgICAgICAgPHQ+CiAg
ICAgICAgICAgICAgICAgICAgICAgIFRoZSBBU1NVUkUgY2VydGlmaWNhdGUgdHlwZSBhc3NlcnRz
IGEgYmluZGluZyBiZXR3ZWVuIHRoZSBETlMgZG9tYWluCiAgICAgICAgICAgICAgICAgICAgICAg
IGluIHdoaWNoIGl0IGlzIHB1Ymxpc2hlZCBhbmQgdGhlIHN1YmplY3QKICAgICAgICAgICAgICAg
ICAgICAgICAga2V5IHNwZWNpZmllZCBpbiBhIFBLSVggY2VydGlmaWNhdGUgaWRlbnRpZmllZCBi
eSBtZWFucyBvZiBhCiAgICAgICAgICAgICAgICAgICAgICAgIGNyeXB0b2dyYXBoaWMgZGlnZXN0
IGZ1bmN0aW9uLgogICAgICAgICAgICAgICAgICAgIDwvdD4KCiAgICAgICAgICAgICAgICAgICAg
PHQ+CiAgICAgICAgICAgICAgICAgICAgICAgIFRoZSBhc3NlcnRpb24gbWFkZSBieSBtZWFucyBv
ZiB0aGUgQVNTVVJFIGNlcnRpZmljYXRlIHR5cGUgaXMKICAgICAgICAgICAgICAgICAgICAgICAg
b25seSBhcyBzZWN1cmUgYXMgdGhlIHRydXN0IGNoYWluIHRoYXQgYXV0aGVudGljYXRlcyBpdC4K
ICAgICAgICAgICAgICAgICAgICAgICAgVHJ1c3QgY2hhaW4gcHJvY2Vzc2luZyBydWxlcyBhcmUg
c3BlY2lmaWVkIGluIFNlY3Rpb24gWFhYIGJlbG93LgogICAgICAgICAgICAgICAgICAgIDwvdD4K
ICAgICAgICAgICAgICAgICAgICA8dD4KICAgICAgICAgICAgICAgICAgICAgICAgSW4gcGFydGlj
dWxhciB0aGUgcHJlc2VuY2Ugb2YgYSBBU1NVUkUgcmVjb3JkIGluIGEgRE5TIGRvbWFpbgogICAg
ICAgICAgICAgICAgICAgICAgICB0aGF0IGlzIG5vdCBzaWduZWQgdXNpbmcgRE5TU0VDIG9yIG90
aGVyIHNlY3VyaXR5IG1lY2hhbmlzbQogICAgICAgICAgICAgICAgICAgICAgICBTSE9VTEQgTk9U
IGJlIGNvbnNpZGVyZWQgdG8gcHJvdmlkZSBhbnkgYWRkaXRpb25hbCBhc3N1cmFuY2UKICAgICAg
ICAgICAgICAgICAgICAgICAgdGhhdCB3b3VsZCBub3QgYmUgcHJvdmlkZWQgYnkgdGhlIGNlcnRp
ZmljYXRlIG9uIGl0cyBvd24uCiAgICAgICAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAg
ICAgICAgIDx0PgogICAgICAgICAgICAgICAgICAgICAgICBJbiB0aGUgY2FzZSB0aGF0IGEgQVNT
VVJFIHJlY29yZCBleGlzdHMgYW5kIGNvbnRhaW5zIGEgZGlnZXN0IHZhbHVlCiAgICAgICAgICAg
ICAgICAgICAgICAgIHRoYXQgbWF0Y2hlcyB0aGUgZGlnZXN0IHZhbHVlIG9mIHRoZSBjZXJ0aWZp
Y2F0ZSBhbmQgaXMgc2lnbmVkCiAgICAgICAgICAgICAgICAgICAgICAgIGJ5IGEgdmVyaWZpZWQg
c2lnbmF0dXJlLCBhIHJlbHlpbmcgcGFydHkgTUFZIGluZmVyIGFuIGFzc2VydGlvbgogICAgICAg
ICAgICAgICAgICAgICAgICBvbiB0aGUgcGFydCBvZiB0aGUgZG9tYWluIG5hbWUgaG9sZGVyIHRo
YXQgdGhlIHNwZWNpZmllZCBrZXkKICAgICAgICAgICAgICAgICAgICAgICAgaXMgYm91bmQgdG8g
dGhlIHNwZWNpZmllZCBjZXJ0aWZpY2F0ZSBzdWJqZWN0IGtleS4gTm8gb3RoZXIKICAgICAgICAg
ICAgICAgICAgICAgICAgcHJvcGVydGllcyBvZiB0aGUgY2VydGlmaWNhdGUgbWF5IGJlIGNvbnNp
ZGVyZWQgdG8gaGF2ZSBiZWVuCiAgICAgICAgICAgICAgICAgICAgICAgIGFzc2VydGVkIGV4Y2Vw
dGluZyB0aG9zZSB0aGF0IGxpbWl0IHRoZSB1c2Ugb2YgdGhlIGNlcnRpZmljYXRlCiAgICAgICAg
ICAgICAgICAgICAgICAgIHdoaWNoIE1VU1QgYmUgb2JzZXJ2ZWQgYXMgd2l0aCBhbnkgb3RoZXIg
UEtJWCBjZXJ0aWZpY2F0ZS4KICAgICAgICAgICAgICAgICAgICAgICAgU3VjaCBwcm9wZXJ0aWVz
IGluY2x1ZGUgdGhlIG5vdEJlZm9yZSBhbmQgbm90QWZ0ZXIgZmllbGRzLAogICAgICAgICAgICAg
ICAgICAgICAgICB0aGUga2V5IFVzYWdlIGJpdHMgYW5kIGFsbCBYLjUwOXYzIGV4dGVuc2lvbnMg
Zm9yIHdoaWNoIHRoZQogICAgICAgICAgICAgICAgICAgICAgICBjcml0aWNhbCBiaXQgaXMgc2V0
LgogICAgICAgICAgICAgICAgICAgIDwvdD4KCiAgICAgICAgICAgICAgICAgICAgPHQ+CiAgICAg
ICAgICAgICAgICAgICAgICAgIFRoZSBDRVJUIHJlY29yZCBmaWVsZCB2YWx1ZXMgYXJlIGRlZmlu
ZWQgZm9yIEFTU0VSVCBhcyBmb2xsb3dzOgogICAgICAgICAgICAgICAgICAgIDwvdD4KICAgICAg
ICAgICAgICAgICAgICA8dD4KICAgICAgICAgICAgICAgICAgICAgICAgPGxpc3Qgc3R5bGU9Imhh
bmdpbmciPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgPHQgaGFuZ1RleHQ9IlR5cGUiPiBp
cyBzZXQgdG8gdGhlIHZhbHVlIChUQlMgSUFOQSkgPC90PgogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgPHQgaGFuZ1RleHQ9IktleSB0YWciPiBpcyBpZ25vcmVkPC90PgogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgPHQgaGFuZ1RleHQ9IkFsZ29yaXRobSAiPiBpcyBpZ25vcmVkCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICA8
dCBoYW5nVGV4dD0iQ2VydGlmaWNhdGUgZGF0YSI+CiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgY29udGFpbnMgdGhlIG9iamVjdCBkaWdlc3QgaWRlbnRpZmllcgogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIHZhbHVlIG9mIHRoZSBjZXJ0aWZpY2F0ZSBmb3Igd2hpY2ggYSBi
aW5kaW5nIGJldHdlZW4gdGhlCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3ViamVj
dCBrZXkgYW5kIHRoZSBkb21haW4gbmFtZSBpcyBhc3NlcnRlZAogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgPC90PgogICAgICAgICAgICAgICAgICAgICAgICA8L2xpc3Q+CiAgICAgICAgICAg
ICAgICAgICAgPC90PgogICAgICAgICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgICAg
IFRoZSBPYmplY3QgRGlnZXN0ICBJZGVudGlmaWVyIChPREkpIGlzIGZvcm1lZCBieSBjb25jYXRl
bmF0aW5nIHRoZSAKICAgICAgICAgICAgICAgICAgICBBU04uMSBPSUQgb2YgdGhlIG9iamVjdCB0
eXBlLCB0aGUgQVNOLjEgT0lEIG9mIHRoZSBkaWdlc3QgYWxnb3JpdGhtCiAgICAgICAgICAgICAg
ICAgICAgYW5kIHRoZSBkaWdlc3QgdmFsdWUKICAgICAgICAgICAgICAgICAgICA8L3Q+CiAgICAg
ICAgICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgICAgICAgICAgIFRoZSBmb2xsb3dpbmcg
ZXhhbXBsZSBzaG93cyBhIENFUlQgcmVjb3JkIGluIHdoaWNoIGEga2V5IGFzc3VyYW5jZQogICAg
ICAgICAgICAgICAgICAgICAgICBpcyBnaXZlbiBmb3IgdGhlIGRvbWFpbiBleGFtcGxlLmNvbSBm
b3IgdGhlIFguNTA5djMvUEtJWCBjZXJ0aWZpY2F0ZQogICAgICAgICAgICAgICAgICAgICAgICB3
aXRoIGFuIE9ESSB2YWx1ZSBvZiBLUjFMMEdib2NhSU9PaW0xK3FkSHRPU3JEY09zR2lJMk5DY3h1
WDIvVHFjLgogICAgICAgICAgICAgICAgICAgIDwvdD4KCiAgICAgICAgICAgICAgICAgICAgPGZp
Z3VyZT4KICAgICAgICAgICAgICAgICAgICAgICAgPGFydHdvcms+CjwhW0NEQVRBW2V4YW1wbGUu
Y29tICAgICBDRVJUIEFTU0VSVCAwIFNIQTI1NiAKICAgICAgICAgICAgICAgIEtSMUwwR2JvY2FJ
T09pbTErcWRIdE9TckRjT3NHaUkyTkNjeHVYMi9UcWNdXT4KICAgICAgICAgICAgICAgICAgICAg
ICAgPC9hcnR3b3JrPgogICAgICAgICAgICAgICAgICAgIDwvZmlndXJlPgoKICAgICAgICAgICAg
ICAgICAgICA8dD4KICAgICAgICAgICAgICAgICAgICAgICAgVGhlIG9yaWdpbmFsIGNlcnRpZmlj
YXRlIGRhdGEgaXM6CiAgICAgICAgICAgICAgICAgICAgPC90PgoKPGZpZ3VyZT4KICAgICAgICAg
ICAgICAgICAgICAgICAgPGFydHdvcms+CjwhW0NEQVRBWyB7VEJTfSBdXT4KICAgICAgICAgICAg
ICAgICAgICAgICAgPC9hcnR3b3JrPgogICAgICAgICAgICAgICAgICAgIDwvZmlndXJlPgoKICAg
ICAgICAgICAgICAgICAgICA8dD4KICAgICAgICAgICAgICAgICAgICAgICAgQW4gYXNzdXJhbmNl
IGlzIGdpdmVuIGZvciB0aGUgZm9sbG93aW5nIGNlcnRpZmljYXRlIGRhdGE6CiAgICAgICAgICAg
ICAgICAgICAgPC90PgoKICAgICAgICAgICAgICAgICAgICA8ZmlndXJlPgogICAgICAgICAgICAg
ICAgICAgICAgICA8YXJ0d29yaz4KPCFbQ0RBVEFbIHtUQlN9IF1dPgogICAgICAgICAgICAgICAg
ICAgICAgICA8L2FydHdvcms+CiAgICAgICAgICAgICAgICAgICAgPC9maWd1cmU+CgoKICAgICAg
ICAgICAgICAgICAgICA8dD4KICAgICAgICAgICAgICAgICAgICAgICAgVGhlIEtleSBUYWcgZmll
bGQgaXMgdXNlZCB0byBzcGVjaWZ5IGFzc3VyYW5jZSBvcHRpb25zIGFzIGZvbGxvd3M6CiAgICAg
ICAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAg
ICAgICAgICAgICA8bGlzdCBzdHlsZT0iaGFuZ2luZyI+CiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICA8dCBoYW5nVGV4dD0iMCI+Tm9uZTwvdD4KICAgICAgICAgICAgICAgICAgICAgICAgICAg
IDx0IGhhbmdUZXh0PSIxIj5TdWJvcmRpbmF0ZTwvdD4KICAgICAgICAgICAgICAgICAgICAgICAg
PC9saXN0PgogICAgICAgICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICAgICAgICA8dD4K
ICAgICAgICAgICAgICAgICAgICAgICAgSWYgdGhlIGtleSB0YWcgZmllbGQgaXMgc2V0IHRvIHRo
ZSB2YWx1ZSAxLCB0aGUga2V5IGFzc3VyYW5jZSBwcm92aWRlZAogICAgICAgICAgICAgICAgICAg
ICAgICBieSB0aGUgQ0VSVCByZXNvdXJjZSByZWNvcmQgaXMgc3Vib3JkaW5hdGUgdG8gdGhhdCBw
cm92aWRlZCBieSB0aGUKICAgICAgICAgICAgICAgICAgICAgICAgY2VydGlmaWNhdGUgZGF0YS4g
SWYgdGhpcyB2YWx1ZSBpcyBzcGVjaWZpZWQgUkVMWUlORyBQYXJ0aWVzIFNIT1VMRCBOT1QKICAg
ICAgICAgICAgICAgICAgICAgICAgcmVseSBvbiB0aGUgYXNzdXJhbmNlIHByb3ZpZGVkIGJ5IHRo
ZSBjb3JyZXNwb25kaW5nIENFUlQgcmVjb3JkIHVubGVzcyB0aGUKICAgICAgICAgICAgICAgICAg
ICAgICAgY2VydGlmaWNhdGUgZGF0YSBtZWV0cyB0aGUgbm9ybWFsIHZhbGlkYXRpb24gY3JpdGVy
aWEgaW4gaXRzIG93biByaWdodC4KICAgICAgICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAg
ICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgICAgICAgICAgIFRoZSBzdWJvcmRpbmF0ZSBiaXQg
d291bGQgYmUgc3BlY2lmaWVkIGluIHRoZSBwcmV2aW91cyBleGFtcGxlIGFzIGZvbGxvd3MuCiAg
ICAgICAgICAgICAgICAgICAgPC90PgoKICAgICAgICAgICAgICAgICAgICA8ZmlndXJlPgogICAg
ICAgICAgICAgICAgICAgICAgICA8YXJ0d29yaz4KPCFbQ0RBVEFbZXhhbXBsZS5jb20gICAgIENF
UlQgQVNTRVJUIDAgU0hBMjU2IAogICAgICAgICAgICAgICAgS1IxTDBHYm9jYUlPT2ltMStxZEh0
T1NyRGNPc0dpSTJOQ2N4dVgyL1RxY11dPgogICAgICAgICAgICAgICAgICAgICAgICA8L2FydHdv
cms+CiAgICAgICAgICAgICAgICAgICAgPC9maWd1cmU+CgogICAgICAgICAgICAgICAgICAgIDx0
PgogICAgICAgICAgICAgICAgICAgICAgICBObyBhc3N1cmFuY2UgaXMgZ2l2ZW4gZm9yIHRoZSBl
cXVpdmFsZW50IGNlcnRpZmljYXRlIGRhdGEgdW5sZXNzCiAgICAgICAgICAgICAgICAgICAgICAg
IGEgdmFsaWQgUEtJWCBjZXJ0aWZpY2F0ZSBjaGFpbiBjYW4gYmUgZXN0YWJsaXNoZWQgZm9yIHRo
ZSBvcmlnaW5hbAogICAgICAgICAgICAgICAgICAgICAgICBjZXJ0aWZpY2F0ZSB0byBhIHRydXN0
ZWQgcm9vdCB0aGF0IHBhc3NlcyBhbGwgdGhlIG5vcm1hbCByZXZvY2F0aW9uIGNoZWNraW4KICAg
ICAgICAgICAgICAgICAgICAgICAgbWVjaGFuaXNtcy4KICAgICAgICAgICAgICAgICAgICA8L3Q+
CgogICAgICAgICAgICAgICAgPC9zZWN0aW9uPgogICAgICAgICAgICAgICAgPHNlY3Rpb24gdGl0
bGU9IkRQVFIiPgogICAgICAgICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgICAgICAg
ICBUaGUgRFBUUiBjZXJ0aWZpY2F0ZSB0eXBlIGFsbG93cyBhbiB1bmxpbWl0ZWQgbnVtYmVyIG9m
IGNlcnRpZmljYXRlcwogICAgICAgICAgICAgICAgICAgICAgICB0byBiZSBib3VuZCB0byBhIHNp
bmdsZSBETlMgZG9tYWluIG5hbWUgb3ZlcmNvbW1pbmcgdGhlCiAgICAgICAgICAgICAgICAgICAg
ICAgIGxpbWl0YXRpb25zIHRoYXQgdGhlIEROUyBwcm90b2NvbCBpbXBvc2VzIG9uIHRoZSBudW1i
ZXIKICAgICAgICAgICAgICAgICAgICAgICAgb2YgQ0VSVCByZWNvcmRzIHRoYXQgY2FuIGJlIGJv
dW5kIHRvIGEgc2luZ2xlIEROUyBkb21haW4KICAgICAgICAgICAgICAgICAgICAgICAgbmFtZSBp
biBhIHByYWN0aWNhbCBkZXBsb3ltZW50LgoKICAgICAgICAgICAgICAgICAgICA8L3Q+CiAgICAg
ICAgICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgICAgICAgICAgIFRoZSBDRVJUIHJlY29y
ZCBmaWVsZCB2YWx1ZXMgYXJlIGRlZmluZWQgZm9yIERQVFIgYXMgZm9sbG93czoKICAgICAgICAg
ICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgICAg
ICAgICAgIDxsaXN0IHN0eWxlPSJoYW5naW5nIj4KICAgICAgICAgICAgICAgICAgICAgICAgICAg
IDx0IGhhbmdUZXh0PSJUeXBlIj4gaXMgc2V0IHRvIHRoZSB2YWx1ZSAoVEJTIElBTkEpIDwvdD4K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDx0IGhhbmdUZXh0PSJLZXkgdGFnIj4gTVVTVCBi
ZSBzZXQgdG8gMTwvdD4KICAgICAgICAgICAgICAgICAgICAgICAgICAgIDx0IGhhbmdUZXh0PSJB
bGdvcml0aG0gIj4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb250YWlucyB0aGUg
YWxnb3JpdGhtCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29kZSBmb3IgdGhlIGRp
Z2VzdCBhbGdvcml0aG0gdG8gYmUgdXNlZCB0bwogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIGNhbGN1bGF0ZSBDc2VsZWN0b3IgcHJlZml4ZXMuCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICA8L3Q+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0iQ2VydGlm
aWNhdGUgZGF0YSI+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29udGFpbnMgdGhl
IEROUyBuYW1lIHRvIGJlIHVzZWQgYXMgdGhlIHJvb3Qgbm9kZQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHRvIHdoaWNoIHRoZSBjYWxjdWxhdGVkIHNlbGVjdG9ybiBwcmVmaXggaXMg
cHJlcGVuZGVkLgogICAgICAgICAgICAgICAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAg
ICAgICAgICAgICA8L2xpc3Q+CiAgICAgICAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAg
ICAgICAgIDx0PgogICAgICAgICAgICAgICAgICAgICAgICBUaGUgUEtJWCBjZXJ0aWZpY2F0ZSBm
b3Igd2hpY2ggdGhlIGFzc3VyYW5jZSBpcyBiZWluZwogICAgICAgICAgICAgICAgICAgICAgICBz
YXVnaHQgaXMgcHJvY2Vzc2VkIHVzaW5nIHRoZSBzcGVjaWZpZWQgZGlnZXN0IGFsZ29yaXRobQog
ICAgICAgICAgICAgICAgICAgICAgICB0byBwcm9kdWNlIGEgZGlnZXN0IHZhbHVlIHdoaWNoIGlz
IGNvbnZlcnRlZCB0byBoZXhhZGVjaW1hbAogICAgICAgICAgICAgICAgICAgICAgICBhbmQgaGFz
IGFuCiAgICAgICAgICAgICAgICAgICAgICAgIHVuZGVyc2NvcmUgY2hhcmFjdGVyICdfJyBwcmVw
ZW5kZWQgdG8gZm9ybSBhIHNlbGVjdG9yIGxhYmVsIGFzIGZvbGxvd3M6CiAgICAgICAgICAgICAg
ICAgICAgPC90PgogICAgICAgICAgICAgICAgICAgIDxmaWd1cmU+CiAgICAgICAgICAgICAgICAg
ICAgICAgIDxhcnR3b3JrPgo8IVtDREFUQVtzZWxlY3RvciA9ICJfIiArIGhleCAoIGRpZ2VzdCAo
IGNlcnRpZmljYXRlKSldXT4KICAgICAgICAgICAgICAgICAgICAgICAgPC9hcnR3b3JrPgogICAg
ICAgICAgICAgICAgICAgIDwvZmlndXJlPgogICAgICAgICAgICAgICAgICAgIDx0PgogICAgICAg
ICAgICAgICAgICAgICAgICBUaGUga2V5IHNlbGVjdG9yIGxhYmVsIGlzIHByZXBlbmRlZCB0byB0
aGUgZG9tYWluIG5hbWUgc3BlY2lmaWVkIHRvCiAgICAgICAgICAgICAgICAgICAgICAgIGZvcm0g
YSBETlMgZG9tYWluIG5hbWUgb24gd2hpY2ggYSBETlMgcXVlcnkgZm9yIGEgQ0VSVCByZXNvdXJj
ZSByZWNvcmQKICAgICAgICAgICAgICAgICAgICAgICAgaXMgdG8gYmUgcGVyZm9ybWVkLgogICAg
ICAgICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICAgICAgICA8ZmlndXJlPgogICAgICAg
ICAgICAgICAgICAgICAgICA8YXJ0d29yaz4KPCFbQ0RBVEFbcXVlcnlfbmFtZSA9IHNlbGVjdG9y
ICsgIi4iICsgZG9tYWluX25hbWVdXT4KICAgICAgICAgICAgICAgICAgICAgICAgPC9hcnR3b3Jr
PgogICAgICAgICAgICAgICAgICAgIDwvZmlndXJlPgogICAgICAgICAgICAgICAgICAgIDx0Pgog
ICAgICAgICAgICAgICAgICAgICAgICBUaGUgZm9sbG93aW5nIGV4YW1wbGUgc2hvd3MgdGhlIHVz
ZSBvZiB0aGUgRFBUUiBjZXJ0aWZpY2F0ZQogICAgICAgICAgICAgICAgICAgICAgICB0eXBlIHRv
IHByb3ZpZGUgYW4gYXNzdXJhbmNlIGZvciB0aGUgc2FtZSBjZXJ0aWZpY2F0ZSBzcGVjaWZpZWQK
ICAgICAgICAgICAgICAgICAgICAgICAgZWFybGllci4KICAgICAgICAgICAgICAgICAgICA8L3Q+
CgogICAgICAgICAgICAgICAgICAgIDxmaWd1cmU+CiAgICAgICAgICAgICAgICAgICAgICAgIDxh
cnR3b3JrPgo8IVtDREFUQVtleGFtcGxlLmNvbSAgICAgQ0VSVCBEUFRSIDEgU0hBMjU2ICJjZXJ0
LmV4YW1wbGUuY29tIgpfODYyYWYzOGVhMjRhNzQ1MTc1ODkzY2UwZjJkZGU5YmM3NmM1Y2E3Nzhm
YmQyMjY0YTIyNTRlYjU4ODczOWI4Yy5jZXJ0LmV4YW1wbGUuY29tIEFTU0VSVAogICAgICAgICAg
ICAgICAxIFNIQTI1NiBLUjFMMEdib2NhSU9PaW0xK3FkSHRPU3JEY09zR2lJMk5DY3h1WDIvVHFj
XV0+CiAgICAgICAgICAgICAgICAgICAgICAgIDwvYXJ0d29yaz4KICAgICAgICAgICAgICAgICAg
ICA8L2ZpZ3VyZT4KCgogICAgICAgICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgICAg
ICAgICBUaGUgRFBUUiBjZXJ0aWZpY2F0ZSB0eXBlIGNhbiBvbmx5IGJlCiAgICAgICAgICAgICAg
ICAgICAgICAgIHJlc29sdmVkIGFmdGVyIHRoZSBjZXJ0aWZpY2F0ZSBmb3Igd2hpY2ggdGhlIGFz
c3VyYW5jZSBpcwogICAgICAgICAgICAgICAgICAgICAgICByZXF1aXJlZCBpcyBrbm93bi4gSXQg
aXMgdGh1cyBub3QgcG9zc2libGUgdG8gcHJlLWZldGNoCiAgICAgICAgICAgICAgICAgICAgICAg
IHRoZSBjZXJ0aWZpY2F0ZSBhdCB0aGUgc2FtZSB0aW1lIHRoYXQgQSBvciBBQUFBIHJlY29yZCBp
cwogICAgICAgICAgICAgICAgICAgICAgICBwZXJmb3JtZWQgYXMgaXMgdGhlIGNhc2Ugd2hlbiB0
aGUgQVNTRVJUIGNlcnRpZmljYXRlIHR5cGUKICAgICAgICAgICAgICAgICAgICAgICAgaXMgcG9w
dWxhdGVkIGF0IHRoZSBkb21haW4gbmFtZSBmb3Igd2hpY2ggdGhlIGFzc3VyYW5jZQogICAgICAg
ICAgICAgICAgICAgICAgICBpcyBiZWluZyBtYWRlLgogICAgICAgICAgICAgICAgICAgIDwvdD4K
CiAgICAgICAgICAgICAgICA8L3NlY3Rpb24+CgogICAgICAgICAgICA8L3NlY3Rpb24+CiAgICAg
ICAgICAgIDxzZWN0aW9uIHRpdGxlPSJYLjUwOXYzIEV4dGVuc2lvbiI+CiAgICAgICAgICAgICAg
ICA8dD4KICAgICAgICAgICAgICAgICAgICBUaGUgWC41MDl2MyBjZXJ0aWZpY2F0ZSBleHRlbnNp
b24gJ0ROUy1DRVJUJyBNQVkgYmUgaW5jbHVkZWQgaW4KICAgICAgICAgICAgICAgICAgICBhbiBY
LjUwOXYzIGNlcnRpZmljYXRlIHRvIG5vdGlmeSByZWx5aW5nIHBhcnRpZXMgdGhhdCBhIEROUyBr
ZXkKICAgICAgICAgICAgICAgICAgICBhc3N1cmFuY2UgTUFZIG9yIE1VU1QgYmUgZW1wbG95ZWQu
CiAgICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgICA8dD4KICAgICAgICAgICAgICAg
ICAgICBJZiB0aGUgRE5TLUNFUlQgZXh0ZW5zaW9uIGlzIHByZXNlbnQgYW5kIHRoZSBjcml0aWNh
bCBmbGFnIGJpdAogICAgICAgICAgICAgICAgICAgIGlzIG5vdCBzZXQsIGl0IHNlcnZlcyBhcyBh
IG5vdGljZSB0byBhIHJlbHlpbmcgcGFydHkgYXBwbGljYXRpb25zCiAgICAgICAgICAgICAgICAg
ICAgdGhhdCB0aGV5IE1BWSBhdHRlbXB0IHRvIHVzZSB0aGUga2V5IGFzc3VyYW5jZSBtZWNoYW5p
c20gc3BlY2lmaWVkCiAgICAgICAgICAgICAgICAgICAgaW4gdGhpcyBkb2N1bWVudC4KICAgICAg
ICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgICAgIElm
IHRoZSBETlMtQ0VSVCBleHRlbnNpb24gY3JpdGljYWwgZmxhZyBiaXQgaXMgc2V0LCBhIHJlbHlp
bmcgcGFydHkgYXBwbGljYXRpb24KICAgICAgICAgICAgICAgICAgICBNVVNUIHN1cHBvcnQgdGhl
IGtleSBhc3N1cmFuY2UgbWVjaGFuaXNtIHNwZWNpZmllZAogICAgICAgICAgICAgICAgICAgIGlu
IHRoaXMgZG9jdW1lbnQgYW5kIE1VU1QgTk9UIGNvbnNpZGVyIHRoZSBjZXJ0aWZpY2F0ZSB2YWxp
ZAogICAgICAgICAgICAgICAgICAgIHVubGVzcyB0aGUgb3V0Y29tZSBvZiB0aGUgdmVyaWZpY2F0
aW9uIHByb2NlZHVyZSBpcyAndmVyaWZpZWQnLgogICAgICAgICAgICAgICAgPC90PgogICAgICAg
ICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgICAgICAgU2luY2UgYXBwbGljYXRpb25zIE1VU1Qg
Tk9UIG1ha2UgdXNlIG9mIFguNTA5djMgY3JpdGljYWwgZXh0ZW5zaW9ucwogICAgICAgICAgICAg
ICAgICAgIHRoYXQgYXJlIG5vdCB1bmRlcnN0b29kLCB1c2Ugb2YgdGhlIGNyaXRpY2FsIGZsYWcg
Yml0IHZhbHVlICdzZXQnCiAgICAgICAgICAgICAgICAgICAgaXMgc3Ryb25nbHkgZGlzY291cmFn
ZWQuCiAgICAgICAgICAgICAgICAgICAgQ2VydGlmaWNhdGUgaXNzdWVycyBTSE9VTEQgTk9UIHNl
dCB0aGUgY3JpdGljYWwgZmxhZyBiaXQgb24gYQogICAgICAgICAgICAgICAgICAgIEROUy1DRVJU
IHVubGVzcyB0aGlzIGlzIHRoZSBkZXJpc3JlZCBiZWhhdmlvcgogICAgICAgICAgICAgICAgPC90
PgoKICAgICAgICAgICAgPC9zZWN0aW9uPgogICAgICAgICAgICA8c2VjdGlvbiB0aXRsZT0iUHJv
Y2Vzc2luZyBSdWxlcyI+CiAgICAgICAgICAgICAgICA8dD4KICAgICAgICAgICAgICAgICAgICBQ
cm9jZXNzaW5nIG9mIGNlcnRpZmljYXRlIGFzc3VyYW5jZSBjaGFpbnMgZm9ybWVkIHdpdGggQVNT
RVJUCiAgICAgICAgICAgICAgICAgICAgYW5kIERQVFIgcmVjb3JkcyBpcyBzaW1pbGFyIHRvIHBy
b2Nlc3Npbmcgb2YgUEtJWCBjZXJ0aWZpY2F0ZQogICAgICAgICAgICAgICAgICAgIGNoYWlucy4g
VGhlIG1haW4gZGlmZmVyZW5jZSBiZWluZyB0aGF0IHRoZSBhc3N1cmFuY2VzIHRoYXQKICAgICAg
ICAgICAgICAgICAgICBjYW4gYmUgZXhwcmVzc2VkIGFyZSBjb25zaWRlcmFibHkgbW9yZSBsaW1p
dGVkLgogICAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgICAgPHQ+CiAgICAgICAgICAg
ICAgICAgICAgV2hlbiBhIERlbGVnYXRpb24gU2lnbmVyIChEUykKICAgICAgICAgICAgICAgICAg
ICByZWNvcmQgaXMgaW5zZXJ0ZWQgaW50byBhIHBhcmVudCB6b25lLCB0aGUgc2lnbmVyIGlzIG1h
a2luZwogICAgICAgICAgICAgICAgICAgIG5vIGFzc2VydGlvbiBiZXlvbmQgc3RhdGluZyB0aGF0
IHRoZSBkZWxlZ2F0ZSB6b25lIGlzIHNpZ25lZAogICAgICAgICAgICAgICAgICAgIHVuZGVyIGEg
c3BlY2lmaWMga2V5LiBJdCBpcyBub3QgcG9zc2libGUgdG8ga25vdyB3aG8gc3BlY2lmaWVkCiAg
ICAgICAgICAgICAgICAgICAgdGhlIGtleSBkYXRhLCB3aGF0IHByb2Nlc3MgKGlmIGFueSkgd2Fz
IHVzZWQgdG8gdmVyaWZ5IHRoZSBrZXkKICAgICAgICAgICAgICAgICAgICBvciB3aG8gbWlnaHQg
YmVhciBsaWFiaWxpdHkgaW4gdGhlIGNhc2Ugb2YgYSBkZWZhdWx0LgogICAgICAgICAgICAgICAg
PC90PgogICAgICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgICAgICAgSW4gdGhlIGNhc2Ug
d2hlcmUgdGhlIG9ubHkgY2VydGlmaWNhdGUgYXNzdXJhbmNlIGluZm9ybWF0aW9uCiAgICAgICAg
ICAgICAgICAgICAgYXZhaWxhYmxlIGlzIHRoYXQgcHJvdmlkZWQgYnkgdGhlIEROU0VDIHNpZ25h
dHVyZSBjaGFpbiwgdGhlCiAgICAgICAgICAgICAgICAgICAgb25seSBwb3NpdGl2ZSBhc3N1cmFu
Y2UgdGhhdCBNQVkgYmUgZHJhd24gaXMgdGhhdCB0aGUgc3ViamVjdCBrZXkKICAgICAgICAgICAg
ICAgICAgICBzcGVjaWZpZWQgdG8gdGhlIGNlcnRpZmljYXRlIGlzIGJvdW5kIHRvIHRoZSBjb3Jy
ZXNwb25kaW5nCiAgICAgICAgICAgICAgICAgICAgZG9tYWluIG5hbWUgc2VydmljZSBsYWJlbCBl
eHByZXNzZWQgYnkgdGhlIHNpZ25lZCBBU1NFUlQgYW5kIERQVFIKICAgICAgICAgICAgICAgICAg
ICByZWNvcmRzLiBSZWx5aW5nIHBhcnRpZXMgTVVTVCBob3dldmVyIHJlY29nbml6ZSBhbmQgYXBw
bHkgYWxsCiAgICAgICAgICAgICAgICAgICAgcmVzdHJpY3Rpb25zIG9uIHRoZSB1c2Ugb2YgdGhl
IHN1YmplY3Qga2V5LiBJbiBwYXJ0aWN1bGFyCiAgICAgICAgICAgICAgICAgICAgdGhlIFZhbGlk
aXR5IHBlcmlvZCBhbmQgYWxsIGV4dGVuc2lvbnMgbWFya2VkIGNyaXRpY2FsLgogICAgICAgICAg
ICAgICAgPC90PgogICAgICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgICAgICAgQWRkaXRp
b25hbCBhc3N1cmFuY2VzIE1BWSBiZSBpbmZlcmVkIGluIHRoZSBjYXNlIHRoYXQgYWRkaXRpb25h
bAogICAgICAgICAgICAgICAgICAgIGluZm9ybWF0aW9uIGlzIGF2YWlsYWJsZSBvdXQtb2YtYmFu
ZCB3aXRoIHJlc3BlY3QgdG8gdGhlIEROU1NFQwogICAgICAgICAgICAgICAgICAgIHNpZ25hdHVy
ZSBjaGFpbi4gU3VjaCBwcm9jZXNzaW5nIGlzIG91dCBvZiBzY29wZSBmb3IgdGhpcwogICAgICAg
ICAgICAgICAgICAgIGRvY3VtZW50LgogICAgICAgICAgICAgICAgPC90PgoKICAgICAgICAgICAg
ICAgIDxzZWN0aW9uIHRpdGxlPSJHZW5lcmFsIj4KICAgICAgICAgICAgICAgICAgICA8dD4KICAg
ICAgICAgICAgICAgICAgICAgICAgUHJvY2Vzc2luZyBvZiBjZXJ0aWZpY2F0ZSBhc3N1cmFuY2Ug
Y2hhaW5zIGZvcm1lZCB3aXRoCiAgICAgICAgICAgICAgICAgICAgICAgIEFTU0VSVCBhbmQgRFBU
UiByZWNvcmRzIGJlZ2lucyB3aXRoIGEgZG9tYWluIG5hbWUgYW5kIGNlcnRpZmljYXRlCiAgICAg
ICAgICAgICAgICAgICAgICAgIGFuZCByZXN1bHRzIGluIHRoZSBvdXRjb21lcyBWZXJpZmllZCwg
RmFpbGVkIGFuZCBJbmRldGVybWluYXRlLgogICAgICAgICAgICAgICAgICAgIDwvdD4KICAgICAg
ICAgICAgICAgICAgICA8dD4KICAgICAgICAgICAgICAgICAgICAgICAgSW4gdGhlIGNhc2UgdGhh
dCB0aGUgcHJvY2Vzc2luZyBydWxlcyByZXN1bHQgaW4gdGhlIHZhbHVlCiAgICAgICAgICAgICAg
ICAgICAgICAgICdWZXJpZmllZCcgdGhlIHJlbHlpbmcgcGFydHkgTUFZIGNvbnNpZGVyIHRoZSBm
b2xsb3dpbmcKICAgICAgICAgICAgICAgICAgICAgICAgZWxlbWVudHMgdG8gaGF2ZSBiZWVuIGFz
c2VydGVkOgogICAgICAgICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICAgICAgICA8dD4K
ICAgICAgICAgICAgICAgICAgICAgICAgPGxpc3Qgc3R5bGU9ImhhbmdpbmciPgogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgPHQgaGFuZ1RleHQ9IlN1YmplY3QgUHVibGljIEtleSBJbmZvIj4K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUaGUgU3ViamVjdCBQdWJsaWMgS2V5IElu
Zm8gc3BlY2lmaWVkIGluIHRoZQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNlcnRp
ZmljYXRlLgogICAgICAgICAgICAgICAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgPHQgaGFuZ1RleHQ9IlN1YmplY3QgQWx0ZXJuYXRpdmUgTmFtZSI+CiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgVGhlIGRvbWFpbiBuYW1lIGZvciB3aGljaCB0aGUg
YXNzdXJhbmNlIHdhcwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHZlcmlmaWVkLgog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgPHQgaGFuZ1RleHQ9IlZhbGlkaXR5Ij4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBUaGUgYXNzdXJhbmNlIGlzIHZhbGlkIGZyb20gdGhlIG1vbWVudCB0aGF0CiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgdGhlIGFzc3VyYW5jZSBpcyBvYnRhaW5lZCBhbmQgZXhwaXJl
cyBubwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGxhdGVyIHRoYW4gdGhlIGVhcmxp
ZXN0IHRpbWUgc3BlY2lmaWVkIGluIHRoZQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IGNlcnRpZmljYXRlIG5vdEFmdGVyIGRhdGUgYW5kIHRoZSBlYXJsaWVzdAogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIGV4cGlyeSB0aW1lIGZvciB0aGUgc2lnbmF0dXJlIHJlY29yZHMg
aW4gdGhlCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRE5TU0VDIHNpZ25hdHVyZSBj
aGFpbi4KICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICAgICAg
ICAgICAgPC9saXN0PgogICAgICAgICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICAgICAg
ICA8dD4KICAgICAgICAgICAgICAgICAgICAgICAgVGhlIHJlbHlpbmcgcGFydHkgTVVTVCBOT1Qg
Y29uc2lkZXIgdGhlIGZvbGxvd2luZwogICAgICAgICAgICAgICAgICAgICAgICBlbGVtZW50cyB0
byBoYXZlIGJlZW4gYXNzZXJ0ZWQgb24gdGhlIGJhc2lzIG9mIEROU1NFQwogICAgICAgICAgICAg
ICAgICAgICAgICBzaW5nYXR1cmUgdmFsaWRhdGlvbiBhbG9uZS4KICAgICAgICAgICAgICAgICAg
ICA8L3Q+CiAgICAgICAgICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgICAgICAgICAgIDxs
aXN0IHN0eWxlPSJoYW5naW5nIj4KICAgICAgICAgICAgICAgICAgICAgICAgICAgIDx0IGhhbmdU
ZXh0PSJJc3N1ZXIiPjwvdD4KICAgICAgICAgICAgICAgICAgICAgICAgICAgIDx0IGhhbmdUZXh0
PSJTdWJqZWN0Ij48L3Q+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICA8dCBoYW5nVGV4dD0i
WDUwOXYzIGV4dGVuc2lvbnMiPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEhvd2V2
ZXIsIFRoZSByZWx5aW5nIHBhcnR5CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTVVT
VCB1bmRlcnN0YW5kIGFsbCBleHRlbnNpb25zIG1hcmtlZCBjcml0aWNhbCBhbmQKICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBNVVNUIG9ic2VydmUgYWxsIHJlc3RyaWN0aW9ucyBvbiB0
aGUgdXNlIG9mIHRoZQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNlcnRpZmljYXRl
IGluZm9ybWF0aW9uIHRoYXQgdGhleSByZXF1aXJlLgogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgPC90PgogICAgICAgICAgICAgICAgICAgICAgICA8L2xpc3Q+CiAgICAgICAgICAgICAgICAg
ICAgPC90PgogICAgICAgICAgICAgICAgPC9zZWN0aW9uPgogICAgICAgICAgICAgICAgPHNlY3Rp
b24gdGl0bGU9IlNlcnZpY2UgRGlzY292ZXJ5IChTUlYsIE5BUFRSKSI+CiAgICAgICAgICAgICAg
ICAgICAgPHQ+CiAgICAgICAgICAgICAgICAgICAgICAgIFtXaGF0IHRvIGRvIHdpdGggU1JWIHJl
Y29yZHMsIGRvIHdlIGdvIGZvciB0aGUgb3JpZ2luYWwKICAgICAgICAgICAgICAgICAgICAgICAg
ZG9tYWluIHNlcnZpY2UgbGFiZWwgb3IgdGhlIGhvc3QgaW5kaWNhdGVkIGluIHRoZQogICAgICAg
ICAgICAgICAgICAgICAgICBTUlYgcmVjb3JkXQogICAgICAgICAgICAgICAgICAgIDwvdD4KICAg
ICAgICAgICAgICAgIDwvc2VjdGlvbj4KICAgICAgICAgICAgPC9zZWN0aW9uPgogICAgICAgIDwv
c2VjdGlvbj4KCiAgICAgICAgPHNlY3Rpb24gdGl0bGU9IlNlY3VyaXR5IENvbnNpZGVyYXRpb25z
Ij4KICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgICBTZWN1cml0eSBjb25zaWRlcmF0aW9u
cyBmb3IgdGhlIHVzZSBvZiBETlMgYmFzZWQga2V5IGFzc3VyYW5jZSBoYXZlCiAgICAgICAgICAg
ICAgICBiZWVuIGRldmVsb3BlZCBhY2NvcmRpbmcgdG8gYW4gQXNzZXQvUmlzay9UaHJlYXQgYXNz
ZXNzbWVudC4KICAgICAgICAgICAgPC90PgoKCiAgICAgICAgICAgIDxzZWN0aW9uIHRpdGxlPSJU
cnVzdCBDaGFpbiBBc3N1cmFuY2UiPgoKICAgICAgICAgICAgICAgIDxzZWN0aW9uIHRpdGxlPSJS
b290IG9mIFRydXN0Ij4KICAgICAgICAgICAgICAgICAgICA8dD4KICAgICAgICAgICAgICAgICAg
ICAgICAgRE5TIGJhc2VkIEtleSBBc3N1cmFuY2UgbWF5IGJlIHVzZWQgdG8gZXN0YWJsaXNoIGEg
dHJ1c3QKICAgICAgICAgICAgICAgICAgICAgICAgY2hhaW4gdG8gYW55IHJvb3Qgb2YgdHJ1c3Qg
dGhhdCBpcyBjYXBhYmxlIG9mIHByb3ZpZGluZwogICAgICAgICAgICAgICAgICAgICAgICBhIGtl
eSBhc3N1cmFuY2UgZm9yIGEgRE5TU0VDIFpvbmUgU2lnbmluZyBLZXkgb3IgS2V5IFNpZ25pbmcK
ICAgICAgICAgICAgICAgICAgICAgICAgS2V5LgogICAgICAgICAgICAgICAgICAgIDwvdD4KCiAg
ICAgICAgICAgICAgICA8L3NlY3Rpb24+CgogICAgICAgICAgICAgICAgPHNlY3Rpb24gdGl0bGU9
IktleSBSZXZvY2F0aW9uIj4KICAgICAgICAgICAgICAgICAgICA8dD4KICAgICAgICAgICAgICAg
ICAgICAgICAgRE5TIGJhc2VkIGtleSBhc3N1cmFuY2UgcHJvdmlkZXMgb25seSBsaW1pdGVkIGtl
eSByZXZvY2F0aW9uCiAgICAgICAgICAgICAgICAgICAgICAgIGNhcGFiaWxpdGllcy4gQSBwdWJs
aXNoZXIgY2FuIGNlYXNlIHB1YmxpY2F0aW9uIG9mIGEga2V5CiAgICAgICAgICAgICAgICAgICAg
ICAgIGFzc3VyYW5jZSBidXQgaXMgdW5hYmxlIHRvIGdpdmUgcmVhc29ucyBmb3IgZG9pbmcgc28u
IEl0IGlzCiAgICAgICAgICAgICAgICAgICAgICAgIHRodXMgaW1wb3NzaWJsZSBmb3IgYSByZWx5
aW5nIHBhcnR5IHRvIGRpc3Rpbmd1aXNoIGJldHdlZW4KICAgICAgICAgICAgICAgICAgICAgICAg
dGhlIGNhc2UgaW4gd2hpY2ggYSBrZXkgYXNzdXJhbmNlIGlzIHdpdGhkcmF3biBiZWNhdXNlCiAg
ICAgICAgICAgICAgICAgICAgICAgIG9mIGEgY29tcHJvbWlzZSBhbmQgdGhlIGNhc2UgdGhhdCBp
dCBpcyB3aXRoZHJhd24gZm9yIG90aGVyCiAgICAgICAgICAgICAgICAgICAgICAgIHJlYXNvbnMu
CiAgICAgICAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAgICAgPC9zZWN0aW9uPgoKICAg
ICAgICAgICAgICAgIDxzZWN0aW9uIHRpdGxlPSJOb24gUmVwdWRpYXRpb24iPgogICAgICAgICAg
ICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgICAgICAgICBETlMgYmFzZWQga2V5IGFzc3Vy
YW5jZSBkb2VzIG5vdCBhbmQgY2Fubm90IHByb3ZpZGUgYXNzdXJhbmNlCiAgICAgICAgICAgICAg
ICAgICAgICAgIG9mIGtleXMgZm9yIHRoZSBwdXJwb3NlIG9mIGVzdGFibGlzaGluZyBub24tcmVw
dWRpYWJsZQogICAgICAgICAgICAgICAgICAgICAgICBhc3NlcnRpb25zLgogICAgICAgICAgICAg
ICAgICAgIDwvdD4KCiAgICAgICAgICAgICAgICA8L3NlY3Rpb24+CgoKCiAgICAgICAgICAgIDwv
c2VjdGlvbj4KICAgICAgICAgICAgPHNlY3Rpb24gdGl0bGU9IkROU1NFQyBPcGVyYXRpb25zIj4K
ICAgICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgICAgIFVzZSBvZiB0aGUgQVNTVVJF
IGFuZCBEUFRSIG1lY2hhbmlzbXMgaW4gYSBETlMgem9uZSBoYXMKICAgICAgICAgICAgICAgICAg
ICBpbXBsaWNhdGlvbnMgZm9yIGFkbWluaXN0cmF0aW9uIG9mIEROUyBTZWN1cml0eSBpbiB0aGF0
IHpvbmUuCiAgICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgICA8c2VjdGlvbiB0aXRs
ZT0iU2lnbmF0dXJlIFRpbWUgVG8gTGl2ZSI+CiAgICAgICAgICAgICAgICAgICAgPHQ+CiAgICAg
ICAgICAgICAgICAgICAgICAgIFRoZSBETlNTRUMgc2lnbmF0dXJlIHRpbWUgdG8gbGl2ZSB3aWxs
IGRldGVybWluZSB0aGUKICAgICAgICAgICAgICAgICAgICAgICAgdmFsaWRpdHkgcGVyaW9kIGZv
ciBrZXkgYXNzdXJhbmNlIHN0YXRlbWVudHMgYW5kIHRodXMgdGhlCiAgICAgICAgICAgICAgICAg
ICAgICAgIHRpbWUgdGhhdCBpdCB0YWtlcyBmb3Iga2V5IGFzc3VyYW5jZXMgdG8gYmVjb21lIHZv
aWQgaW4KICAgICAgICAgICAgICAgICAgICAgICAgdGhlIGNhc2Ugb2YgYSBjb21wcm9taXNlLgog
ICAgICAgICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICAgICAgICA8dD4KICAgICAgICAg
ICAgICAgICAgICAgICAgU2V0dGluZyBhIHNob3J0IGV4cGlyeSB0aW1lIHdpbGwgcmVxdWlyZSBy
ZWNvcmRzIHRvIGJlCiAgICAgICAgICAgICAgICAgICAgICAgIHNpZ25lZCBtb3JlIGZyZXF1ZW50
bHkgYW5kIHdpbGwgZGVjcmVhc2UgdGhlIGVmZmljaWVuY3kKICAgICAgICAgICAgICAgICAgICAg
ICAgb2YgY2FjaGluZyBib3RoIEROUyBSUnMgdGhlbXNlbHZlcyBhbmQgdmFsaWRhdGlvbiByZXN1
bHRzLgogICAgICAgICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICAgIDwvc2VjdGlvbj4K
ICAgICAgICAgICAgICAgIDxzZWN0aW9uIHRpdGxlPSJab25lIFNpZ25pbmcgS2V5IENvbXByb21p
c2UiPgogICAgICAgICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgICAgICAgICBDb21w
cm9taXNlIG9mIGEgWm9uZSBTaWduaW5nIEtleSAoWlNLKSBkb2VzIG5vdCBieSBpdHNlbGYKICAg
ICAgICAgICAgICAgICAgICAgICAgY29tcHJvbWlzZSB0aGUgc2VjdXJpdHkgb2YgYSBETlMgYmFz
ZWQga2V5IGFzc3VyYW5jZSB1bmxlc3MKICAgICAgICAgICAgICAgICAgICAgICAgdGhlIHBhcnR5
IHRoYXQgZ2FpbnMgYWNjZXNzIHRvIHRoZSBaU0sgYWxzbyBoYXMgdGhlIGFiaWxpdHkKICAgICAg
ICAgICAgICAgICAgICAgICAgdG8gZGlzdHJpYnV0ZSBib2d1cyBETlMgcmVjb3JkcyB0byBhIHRh
cmdldC4KICAgICAgICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgICAgICAgPHQ+CiAg
ICAgICAgICAgICAgICAgICAgICAgIElmIGFuIGF0dGFja2VyIGhhcyB0aGUgYWJpbGl0eSB0byBj
b21wcm9taXNlIHRoZSBaU0sgYW5kCiAgICAgICAgICAgICAgICAgICAgICAgIGRpc3RyaWJ1dGUg
Ym9ndXMgRE5TIHJlY29yZHMsIHRoZSBETlMgem9uZSBpcyBjb21wcm9taXNlZAogICAgICAgICAg
ICAgICAgICAgICAgICBhbmQgdGhlIFpTSyBNVVNUIGJlIGRlYWN0aXZhdGVkIGFuZCBTSE9VTEQg
YmUgcmVwbGFjZWQuCiAgICAgICAgICAgICAgICAgICAgPC90PgoKICAgICAgICAgICAgICAgIDwv
c2VjdGlvbj4KICAgICAgICAgICAgICAgIDxzZWN0aW9uIHRpdGxlPSJLZXkgU2lnbmluZyBLZXkg
Q29tcHJvbWlzZSI+CiAgICAgICAgICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgICAgICAg
ICAgIFRoZSBjb25zZXF1ZW5jZXMgb2YgY29tcHJvbWlzZSBvZiBhIHpvbmUgS2V5IFNpZ25pbmcg
S2V5IGFyZQogICAgICAgICAgICAgICAgICAgICAgICBpZGVudGljYWwgdG8gdGhlIGNvbnNlcXVl
bmNlcyBvZiBhIFpTSyBhcyBmYXIgYXMgdGhlIGtleSBhc3N1cmFuY2UKICAgICAgICAgICAgICAg
ICAgICAgICAgaXMgY29uY2VybmVkLgogICAgICAgICAgICAgICAgICAgIDwvdD4KICAgICAgICAg
ICAgICAgICAgICA8dD4KICAgICAgICAgICAgICAgICAgICAgICAgUmVjb3ZlcnkgZnJvbSBjb21w
cm9taXNlIG9mIGEgS1NLIGlzIG1vcmUgaW52b2xlZCB0aGFuCiAgICAgICAgICAgICAgICAgICAg
ICAgIGNvbXByb21pc2Ugb2YgYSBaU0sgYXMgaXQgcmVxdWlyZXMgbm90IG9ubHkgdGhlIGdlbmVy
YXRpb24KICAgICAgICAgICAgICAgICAgICAgICAgb2YgYSBuZXcga2V5IHBhaXIgYnV0IGFsc28g
Z2VuZXJhdGlvbiBvZiBhIG5ldyBEZWxlZ2F0aW9uCiAgICAgICAgICAgICAgICAgICAgICAgIFNp
Z25lciBSZXNvdXJjZSBSZWNvcmQgaW4gdGhlIHBhcmVudCB6b25lLgogICAgICAgICAgICAgICAg
ICAgIDwvdD4KICAgICAgICAgICAgICAgIDwvc2VjdGlvbj4KICAgICAgICAgICAgPC9zZWN0aW9u
PgogICAgICAgICAgICA8c2VjdGlvbiB0aXRsZT0iQXR0YWNrcyI+CiAgICAgICAgICAgICAgICA8
dD4KICAgICAgICAgICAgICAgICAgICBXZSBoYXZlIGNvbnNpZGVyZWQgcG9zc2libGUgcHJvdG9j
b2wgYXR0YWNrcyBieSBpZGVudGlmeWluZwogICAgICAgICAgICAgICAgICAgIHByb3RvY29sIGFz
c2V0cywgdGhlIGFic3RyYWN0IHJpc2tzIHRvIHdoaWNoIHN1Y2ggYXNzZXRzIG1heSBiZQogICAg
ICAgICAgICAgICAgICAgIGV4cG9zZWQgYW5kIGhvdyBzdWNoIHJpc2tzIG1heSBiZSBtYW5pZmVz
dCBpbiBjb25jcmV0ZSB0aHJlYXRzLgogICAgICAgICAgICAgICAgPC90PgogICAgICAgICAgICAg
ICAgPHQ+CiAgICAgICAgICAgICAgICAgICAgVGhlIGFzc2V0cyBjb25zaWRlcmVkIGFyZSB0aGUg
RE5TU0VDIHByaXZhdGUga2V5cyBoZWxkIGJ5IHRoZQogICAgICAgICAgICAgICAgICAgIGRvbWFp
biBuYW1lIGhvbGRlciwgRE5TIHpvbmUgaW4gd2hpY2ggdGhlIHJlc29yY2UgcmVjb3JkcyBhcmUK
ICAgICAgICAgICAgICAgICAgICBwcmVzZW50ZWQgYW5kIHRoZSBhcHBsaWNhdGlvbiBwdWJsaWMg
a2V5IHBhaXIuCiAgICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgICA8dD4KICAgICAg
ICAgICAgICAgICAgICBUaGUgRE5TIGlzIGEgbGFyZ2UgaW5mcmFzdHJ1Y3R1cmUgYW5kIG1hbmFn
ZW1lbnQgb2YgYSBzcGVjaWZpYwogICAgICAgICAgICAgICAgICAgIEROUyB6b25lIGlzIG5ldmVy
IHdpdGhpbiB0aGUgdW5pcXVlIGNvbnRyb2wgb2Ygb25lIHBhcnR5LgogICAgICAgICAgICAgICAg
ICAgIEluIGFkZGl0aW9uIHRvIGNvbnNpZGVyaW5nIG1lYW5zIG9mIHByZXZlbnRpbmcgY29tcHJv
bWlzZSB3ZQogICAgICAgICAgICAgICAgICAgIGNvbnNpZGVyIHRoZSBzdGVwcyByZXF1aXJlZCB0
byByZWNvdmVyIGZyb20gYSBjb21wcm9taXNlLgogICAgICAgICAgICAgICAgPC90PgogICAgICAg
ICAgICAgICAgPHNlY3Rpb24gdGl0bGU9IlN1cHByZXNzZWQgRE5TIHJlY29yZHMiPgogICAgICAg
ICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgICAgICAgICBUaGUgRE5TU0VDIHByb3Rv
Y29sIGluY29ycG9yYXRlcyBjb250cm9scyB0aGF0IHBlcm1pdAogICAgICAgICAgICAgICAgICAg
ICAgICB2ZXJpZmllcnMgdG8gZGV0ZWN0IG1pc3NpbmcgRE5TU0VDIG5vZGVzIGFuZC9vciBtaXNz
aW5nCiAgICAgICAgICAgICAgICAgICAgICAgIEROU1NFQyByZWNvcmRzLgogICAgICAgICAgICAg
ICAgICAgIDwvdD4KICAgICAgICAgICAgICAgICAgICA8dD4KICAgICAgICAgICAgICAgICAgICAg
ICAgU2luY2UgdGhlIHVzZSBvZiBDRVJUIHNwZWNpZmllZCBpbiB0aGlzIGRvY3VtZW50IG9ubHkg
cGVybWl0cwogICAgICAgICAgICAgICAgICAgICAgICB0aGUgZXhwcmVzc2lvbiBvZiBwb3NpdGl2
ZSB0cnVzdCBzdGF0ZW1lbnRzLCB0aGUgc3VwcHJlc3Npb24KICAgICAgICAgICAgICAgICAgICAg
ICAgb2YgRE5TIHJlY29yZHMgb25seSBhbGxvd3MgYW4gYXR0YWNrZXIgdG8gcGVyZm9ybSBhIGRl
dGVjdGFibGUKICAgICAgICAgICAgICAgICAgICAgICAgRGVuaWFsIG9mIFNlcnZpY2UgYXR0YWNr
IGF0IHdvcnN0LiBTaW5jZSB0aGUgYWJpbGl0eSB0byBzdXByZXNzCiAgICAgICAgICAgICAgICAg
ICAgICAgIEROUyByZWNvcmRzIGFsbG93cyBhbiBhdHRhY2tlciB0byBwZXJmb3JtIGFuIHVuZGV0
ZWN0YWJsZQogICAgICAgICAgICAgICAgICAgICAgICBEZW5pYWwgb2YgU2VydmljZSBhdHRhY2ss
IG5vIGFkZGl0aW9uYWwgdnVsbmVyYWJpbGl0eSBpcyBjcmVhdGVkLgogICAgICAgICAgICAgICAg
ICAgIDwvdD4KICAgICAgICAgICAgICAgIDwvc2VjdGlvbj4KICAgICAgICAgICAgICAgIDxzZWN0
aW9uIHRpdGxlPSJSZXBsYXkgQXR0YWNrIG9mIEROU1NFQyByZWNvcmRzIj4KICAgICAgICAgICAg
ICAgICAgICA8dD4KICAgICAgICAgICAgICAgICAgICAgICAgVGhlIEROU1NFQyBwcm90b2NvbCBp
cyBkZXNpZ25lZCB0byBhbGxvdyBjYWNoaW5nIG9mIHNpZ25lZAogICAgICAgICAgICAgICAgICAg
ICAgICBkYXRhIHdpdGhpbiBhIHNwZWNpZmllZCAndGltZSB0byBsaXZlJyBhbmQgdG8gZW5zdXJl
IHJlamVjdGlvbgogICAgICAgICAgICAgICAgICAgICAgICBvZiBhbGwgZGF0YSBvbmNlIHRoZSB0
aW1lIHRvIGxpdmUgaGFzIGV4cGlyZWQuCiAgICAgICAgICAgICAgICAgICAgPC90PgogICAgICAg
ICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgICAgICAgICBUaGUgdGltZSB3aW5kb3cg
aW4gd2hpY2ggYSByZXBsYXkgYXR0YWNrIG1pZ2h0IGJlIHN1Y2Nlc3NmdWxsIGlzCiAgICAgICAg
ICAgICAgICAgICAgICAgIHRodXMgdGhlIHNhbWUgYXMgdGhlIHRpbWUgd2luZG93IGluIHdoaWNo
IHRoZSByZWxldmFudCBhZG1pbmlzdHJhdGlvbgogICAgICAgICAgICAgICAgICAgICAgICBhdXRo
b3JpdHkgaGFzIGFscmVhZHkgZGV0ZXJtaW5lZCB0aGF0IHJlbHlpbmcgb24gcG9zc2libHkgc3Rh
bGUKICAgICAgICAgICAgICAgICAgICAgICAgZGF0YSBpcyBhY2NlcHRhYmxlLgogICAgICAgICAg
ICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICAgIDwvc2VjdGlvbj4KICAgICAgICAgICAgICAg
IDxzZWN0aW9uIHRpdGxlPSJab25lIEhpamFjayI+CiAgICAgICAgICAgICAgICAgICAgPHQ+CiAg
ICAgICAgICAgICAgICAgICAgICAgIEluIHRoZSBjYXNlIHRoYXQgYW4gYXR0YWNrZXIgZ2FpbnMg
ZnVsbCBjb250cm9sIG92ZXIgYSBETlMgem9uZSwKICAgICAgICAgICAgICAgICAgICAgICAgdGhl
IGF0dGFja2VyIHdpbGwgYmUgYWJsZSB0byBpbW1lZGlhdGVseSBnZW5lcmF0ZSBhc3N1cmFuY2Vz
IGZvcgogICAgICAgICAgICAgICAgICAgICAgICBlbmQtZW50aXRpZXMgdW5kZXIgdGhlaXIgY29u
dHJvbCB3aXRob3V0IHRoZSBpbnZvbHZlbWVudCBvZiBhbnkKICAgICAgICAgICAgICAgICAgICAg
ICAgYWRkaXRpb25hbCBwYXJ0eSB3aGF0c29ldmVyLgogICAgICAgICAgICAgICAgICAgIDwvdD4K
CiAgICAgICAgICAgICAgICA8L3NlY3Rpb24+CgogICAgICAgICAgICAgICAgPHNlY3Rpb24gdGl0
bGU9IkRpc2Nsb3N1cmUgb2YgRW5kIEVudGl0eSBQcml2YXRlIEtleSI+CiAgICAgICAgICAgICAg
ICAgICAgPHQ+CiAgICAgICAgICAgICAgICAgICAgICAgIEluIHRoZSBjYXNlIHRoYXQgYW4gZW5k
LWVudGl0eSBwcml2YXRlIGtleSBpcyBrbm93biB0byBiZSBvciBzdXNwZWN0ZWQgb2YgYmVpbmcK
ICAgICAgICAgICAgICAgICAgICAgICAgZGlzY2xvc2VkLCB0aGUKICAgICAgICAgICAgICAgICAg
ICAgICAgRE5TIGRvbWFpbiBuYW1lIGhvbGRlciBTSE9VTEQgcmVtb3ZlIGFsbCBjb3JyZXNwb25k
aW5nCiAgICAgICAgICAgICAgICAgICAgICAgIENFUlQgUlJzIHdpdGggdGhlIEFTU1VSRSBjZXJ0
aWZpY2F0ZSB0eXBlIGFzIHNvb24gYXMgaXMgcG9zc2libGUuCiAgICAgICAgICAgICAgICAgICAg
PC90PgoKICAgICAgICAgICAgICAgIDwvc2VjdGlvbj4KICAgICAgICAgICAgICAgIDxzZWN0aW9u
IHRpdGxlPSJEaXNjbG9zdXJlIG9mIEROU1NFQyBTaWduaW5nIEtleSI+CiAgICAgICAgICAgICAg
ICAgICAgPHQ+CiAgICAgICAgICAgICAgICAgICAgICAgIEluIHRoZSBjYXNlIHRoYXQgYSBETlNT
RUMgU2lnbmluZyBLZXkgZm9yIGEgem9uZSBpcyBrbm93biB0byBiZSBvciBzdXNwZWN0ZWQKICAg
ICAgICAgICAgICAgICAgICAgICAgb2YgYmVpbmcgZGlzY2xvc2VkLCB0aGUgRE5TIGRvbWFpbiBu
YW1lIGhvbGRlciBTSE9VTEQgZm9sbG93IHRoZSBhZG1pbmlzdHJhdGl2ZQogICAgICAgICAgICAg
ICAgICAgICAgICBwcm9jZXNzZXMgc3BlY2lmaWVkIGZvciByZWNvdmVyeSBmcm9tIHRoaXMgc2l0
dWF0aW9uOiBpLmUuIGVzdGFibGlzaCBuZXcKICAgICAgICAgICAgICAgICAgICAgICAgc2lnbmlu
ZyBrZXlzIGZvciB0aGUgem9uZSBhbmQgcmVzaWduIGl0LgogICAgICAgICAgICAgICAgICAgIDwv
dD4KICAgICAgICAgICAgICAgIDwvc2VjdGlvbj4KICAgICAgICAgICAgICAgIDxzZWN0aW9uIHRp
dGxlPSJNYWxpY2lvdXMgRG9tYWluIE5hbWUgSG9sZGVyIj4KICAgICAgICAgICAgICAgICAgICA8
dD4KICAgICAgICAgICAgICAgICAgICAgICAgQSBzaWduZWQgQ0VSVCByZWNvcmQgb25seSBkZW1v
bnN0cmF0ZXMgdGhhdCB0aGUgcGFydHkgaW4gY29udHJvbAogICAgICAgICAgICAgICAgICAgICAg
ICBvZiB0aGUgYXV0aG9yaXRhdGl2ZSBETlMgemVydmVyIGZvciB0aGUgc3BlY2lmaWVkIHpvbmUg
aGFzIGF1dGhvcml6ZWQKICAgICAgICAgICAgICAgICAgICAgICAgdGhlIHVzZSBvZiBhIHBhcnRp
Y3VsYXIgcHVibGljIGtleSBmb3IgYXV0aGVudGljYXRpbmcgY29tbXVuaWNhdGlvbgogICAgICAg
ICAgICAgICAgICAgICAgICB3aXRoIHRoZSBzZXJ2ZXIuCiAgICAgICAgICAgICAgICAgICAgPC90
PgogICAgICAgICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgICAgICAgICBBIHNpZ25l
ZCBDRVJUIHJlY29yZCAgZG9lcyBub3QgYW5kIGNhbm5vdCBleHByZXNzIGFueSBhc3NlcnRpb24K
ICAgICAgICAgICAgICAgICAgICAgICAgY29uY2VybmluZyB0aGUgZXhpc3RlbmNlLCB0cnVzdHdv
cnRoaW5lc3Mgb3IgYWNjb3VudGFiaWxpdHkgb2YKICAgICAgICAgICAgICAgICAgICAgICAgZWl0
aGVyIHRoZSBrZXkgaG9sZGVyIG9yIHRoZSBkb21haW4gbmFtZSBob2xkZXIuCiAgICAgICAgICAg
ICAgICAgICAgPC90PgogICAgICAgICAgICAgICAgPC9zZWN0aW9uPgogICAgICAgICAgICAgICAg
PHNlY3Rpb24gdGl0bGU9IlByb3RvY29sIFN1YnN0aXR1dGlvbiBBdHRhY2siPgogICAgICAgICAg
ICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgICAgICAgICBmb3IgdGhlIHB1cnBvc2VzIG9m
IGVzdGFibGlzaGluZyBhIHNlY3VyZSBjb25uZWN0aW9uLCBhbiBlbmQKICAgICAgICAgICAgICAg
ICAgICAgICAgZW50aXR5IGNlcnRpZmljYXRlIGFzc2VydGVkIGJ5IG1lYW5zIG9mIGEgc2lnbmVk
IENFUlQKICAgICAgICAgICAgICAgICAgICAgICAgcmVjb3JkIE1VU1QgbWVldCBhbGwgdGhlIHJl
cXVpcmVtZW50cyB0aGF0IGFueSBvdGhlciBlbmQgZW50aXR5CiAgICAgICAgICAgICAgICAgICAg
ICAgIGNlcnRpZmljYXRlIGlzIHJlcXVpcmVkIHRvIG1lZWQgZm9yIHVzZSB3aXRoIHRoYXQgcHJv
dG9jb2wuCgogICAgICAgICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICAgICAgICA8dD4K
ICAgICAgICAgICAgICAgICAgICAgICAgSWYgcHJvdGVjdGlvbiBhZ2FpbnN0IGEgcHJvdG9jb2wg
c3Vic3RpdHV0aW9uIGF0dGFjayBpcyByZXF1aXJlZCwKICAgICAgICAgICAgICAgICAgICAgICAg
dGhlIHNpZ25lciBvZiB0aGUgZW5kIGVudGl0eSBjZXJ0aWZpY2F0ZSBTSE9VTEQgZW5zdXJlIHRo
YXQgdGhlCiAgICAgICAgICAgICAgICAgICAgICAgIGFwcHJvcHJpYXRlIFguNTA5IEtleSBVc2Fn
ZSwgRXh0ZW5kZWQgS2V5IFVzYWdlIGFuZC9vciBleHRlbnNpb25zCiAgICAgICAgICAgICAgICAg
ICAgICAgIGFyZSBhcHByb3ByaWF0ZWx5IGNvbmZpZ3VyZWQuCiAgICAgICAgICAgICAgICAgICAg
PC90PgoKICAgICAgICAgICAgICAgIDwvc2VjdGlvbj4KICAgICAgICAgICAgICAgIDxzZWN0aW9u
IHRpdGxlPSJQcm90b2NvbCBEb3duZ3JhZGUgQXR0YWNrIj4KICAgICAgICAgICAgICAgICAgICA8
dD4KICAgICAgICAgICAgICAgICAgICAgICAgVGhlIENFUlQgcmVjb3JkIG9ubHkgcHJvdmlkZXMg
bm90aWNlIHRoYXQgYSBwdWJsaWMga2V5IGlzIGFzc29jaWF0ZWQKICAgICAgICAgICAgICAgICAg
ICAgICAgd2l0aCBhIEROUyBkb21haW4gbmFtZS4gVGhlIG1lcmUgcHJlc2VuY2Ugb2YgYSBDRVJU
IHJlY29yZCBhdCBhCiAgICAgICAgICAgICAgICAgICAgICAgIEROUyBub2RlIGRvZXMgbm90IGlt
cGx5IHRoYXQgaXRzIHVzZSBpcyBzdXBwb3J0ZWQgaW4gY29uanVuY3Rpb24KICAgICAgICAgICAg
ICAgICAgICAgICAgd2l0aCBhIHNwZWNpZmljIHByb3RvY29sLgogICAgICAgICAgICAgICAgICAg
IDwvdD4KICAgICAgICAgICAgICAgICAgICA8dD4KICAgICAgICAgICAgICAgICAgICAgICAgQWNj
b3JkaW5nbHksIHVzZSBvZiBDRVJUIHJlY29yZHMgZG9lcyBub3QgYW5kIGNhbm5vdCBwcm92aWRl
CiAgICAgICAgICAgICAgICAgICAgICAgIHByb3RlY3Rpb24gYWdhaW5zdCBwcm90b2NvbCBkb3du
Z3JhZGUgYXR0YWNrcy4KICAgICAgICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgICA8
L3NlY3Rpb24+CiAgICAgICAgICAgIDwvc2VjdGlvbj4KICAgICAgICAgICAgPHNlY3Rpb24gdGl0
bGU9IlVzZXIgTm90aWZpY2F0aW9uIj4KICAgICAgICAgICAgICAgIDx0PgogICAgICAgICAgICAg
ICAgICAgIFJlbHlpbmcgcGFydHkgYXBwbGNpYXRpb25zIE1BWSBub3RpZnkgdGhlIHVzZXIgdGhh
dCBhIGNyeXB0b2dyYXBoaWMKICAgICAgICAgICAgICAgICAgICBzZWN1cml0eSBwcm90b2NvbCBp
cyBpbiB1c2UgdG8gcHJvdGVjdCB0aGUgY29uZmlkZW50aWFsaXR5IGFuZAogICAgICAgICAgICAg
ICAgICAgIGludGVncml0eSBvZiBjb21tdW5pY2F0aW9uIHdpdGggdGhlIGRvbWFpbiBuYW1lIGhv
bGRlci4KICAgICAgICAgICAgICAgIDwvdD4KICAgICAgICAgICAgICAgIDx0PgogICAgICAgICAg
ICAgICAgICAgIEtleSBhc3N1cmFuY2UgYnkgbWVhbnMgb2YgdGhlIENFUlQgbWVjaGFuaXNtIG9u
bHkgZXh0ZW5kcyB0byB0aGUKICAgICAgICAgICAgICAgICAgICBwcm9wZXJ0aWVzIG9mIHRoZSBr
ZXkgaXRzZWxmIGFuZCB0aGUgc2VjdXJpdHkgb2YgdGhlIGNvbm5lY3Rpb24KICAgICAgICAgICAg
ICAgICAgICBlc3RhYmxpc2hlZCB0byB0aGUgSW50ZXJuZXQgc2VydmljZSBwcm92aWRlZCBieSB0
aGUga2V5IGhvbGRlci4KICAgICAgICAgICAgICAgICAgICBLZXkgQXNzdXJhbmNlIGJ5IG1lYW5z
IG9mIHRoZSBDRVJUIG1lY2hhbmlzbSBkb2VzIG5vdCBhbmQgY2Fubm90CiAgICAgICAgICAgICAg
ICAgICAgc3VwcG9ydCBhbnkgYXNzZXJ0aW9uIHJlZ2FyZGluZyB0aGUgdHJ1c3R3b3J0aGluZXNz
IG9mIGVpdGhlciB0aGUKICAgICAgICAgICAgICAgICAgICBrZXkgaG9sZGVyIG9yIHRoZSBkb21h
aW4gbmFtZSBob2xkZXIuCiAgICAgICAgICAgICAgICA8L3Q+CiAgICAgICAgICAgICAgICA8dD4K
ICAgICAgICAgICAgICAgICAgICBBIHNlY3VyZSBjb25uZWN0aW9uIHRvIGFuIGVuZHBvaW50IGlk
ZW50aWZpZWQgYnkgYSBkb21haW4gbmFtZSBhbG9uZQogICAgICAgICAgICAgICAgICAgIGRvZXMg
bm90IGltcGx5IGEgc2VjdXJlIHRyYW5zYWN0aW9uLiBJZiBwcm92aWRlZCwgYQogICAgICAgICAg
ICAgICAgICAgIHVzZXIgbm90aWZpY2F0aW9uIE1VU1QgTk9UIGltcGx5IHRoYXQgYSB1c2VyIGlz
ICdzYWZlJyBvbiB0aGUgYmFzaXMgb2YKICAgICAgICAgICAgICAgICAgICBDRVJUIGtleSBhc3N1
cmFuY2UgYWxvbmUuCiAgICAgICAgICAgICAgICA8L3Q+CgoKICAgICAgICAgICAgPC9zZWN0aW9u
PgogICAgICAgIDwvc2VjdGlvbj4KCiAgICAgICAgPHNlY3Rpb24gdGl0bGU9IklBTkEgQ29uc2lk
ZXJhdGlvbnMiPgogICAgICAgICAgICA8dD4KICAgICAgICAgICAgICAgIFRoZSBJQU5BIG1haW50
YWlucyB0aGVyZWdpc3RyeSBmb3IgQ0VSVCBSUjogY2VydGlmaWNhdGUgdHlwZXMuCiAgICAgICAg
ICAgICAgICBUaGUgZm9sbG93aW5nIGFkZGl0aW9uYWwgY2VydGlmaWNhdGUgdHlwZXMgc2hvdWxk
IGJlIGFkZGVkIHRvIHRoZQogICAgICAgICAgICAgICAgcmVnaXN0cnkgYXQgdGhlIG5leHQgYXZh
aWxhYmxlIGNvZGUgcG9pbnQ6CiAgICAgICAgICAgIDwvdD4KCgo8ZmlndXJlPgogICAgICAgICAg
ICAgICAgPGFydHdvcms+CiAgICAgICAgICAgICAgICAgICAgPCFbQ0RBVEFbRGVjaW1hbCAgIFR5
cGUgICAgIE1lYW5pbmcgICAgICAgICAgICAgICAgICAgICAgICAgICBSZWZlcmVuY2UKLS0tLS0t
LSAgIC0tLS0gICAgIC0tLS0tLS0gICAgICAgICAgICAgICAgICAgICAgICAgICAtLS0tLS0tLS0K
ICAgICAgOSAgIEFTU1VSRSAgIERpZ2VzdCB2YWx1ZSBvZiBDZXJ0aWZpY2F0ZSAgICAgICBbVGhp
c10KICAgICAxMCAgIERQVFIgICAgIEluZGlyZWN0aW9uIFBvaW50ZXIgICAgICAgICAgICAgICBb
VGhpc10KXV0+CiAgICAgICAgICAgICAgICA8L2FydHdvcms+CiAgICAgICAgICAgIDwvZmlndXJl
PgogICAgICAgIDwvc2VjdGlvbj4KCgoKICAgICAgICA8c2VjdGlvbiB0aXRsZT0iQWNrbm93bGVk
Z2VtZW50cyI+CiAgICAgICAgICAgIDx0PgoKICAgICAgICAgICAgPC90PgoKICAgICAgICA8L3Nl
Y3Rpb24+CgogICAgPC9taWRkbGU+CgoKCiAgICA8YmFjaz4KCgogICAgICAgIDxyZWZlcmVuY2Vz
IHRpdGxlPSJOb3JtYXRpdmUgUmVmZXJlbmNlcyI+CiAgICAgICAgICAgICZSRkMyMTE5OwogICAg
ICAgICAgICAmUkZDNDAzMzsKICAgICAgICAgICAgJlJGQzQwMzQ7CiAgICAgICAgICAgICZSRkM0
MDM1OwogICAgICAgICAgICAmUkZDNDM5ODsKICAgICAgICAgICAgJlJGQzUyNDY7CgogICAgICAg
IDwvcmVmZXJlbmNlcz4KICAgICAgICA8cmVmZXJlbmNlcyB0aXRsZT0iTm9uLU5vcm1hdGl2ZSBS
ZWZlcmVuY2VzIj4KCiAgICAgICAgICAgICZSRkM0MDI1OwogICAgICAgICAgICAmUkZDNDI1NTsK
ICAgICAgICA8L3JlZmVyZW5jZXM+CgoKICAgICAgICA8c2VjdGlvbiB0aXRsZT0iQXBwZW5kaXgg
LSBEZXNpZ24gQ2hvaWNlcyI+CiAgICAgICAgICAgIDx0PgogICAgICAgICAgICAgICAgVGhpcyBz
ZWN0aW9uIHByb3ZpZGVzIHJhdGlvbmFsZXMgZm9yIGRlc2lnbiBjaG9pY2VzIGFkb3B0ZWQgaW4g
dGhpcyBkcmFmdC4KICAgICAgICAgICAgPC90PgoKICAgICAgICAgICAgPHNlY3Rpb24gdGl0bGU9
IktleSBEaWdlc3QiPgogICAgICAgICAgICAgICAgPHQ+CiAgICAgICAgICAgICAgICAgICAgVGhl
IHVzZSBvZiBDRVJUIHR5cGUgZm9yIGRpZ2VzdHMgb2Yga2V5cyBhcyBvcHBvc2VkIHRvIGNvbXBs
ZXRlIGNlcnRpZmljYXRlcyB3YXMgY29uc2lkZXJlZCBhbmQgcmVqZWN0ZWQuCiAgICAgICAgICAg
ICAgICA8L3Q+CgogICAgICAgICAgICA8L3NlY3Rpb24+CgogICAgICAgIDwvc2VjdGlvbj4KICAg
IDwvYmFjaz4KPC9yZmM+Cg==
--0016e644ba16b6e38a04975461d5--

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C849E3A6E1E for ; Mon, 13 Dec 2010 16:19:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.519
X-Spam-Level:
X-Spam-Status: No, score=-101.519 tagged_above=-999 required=5 tests=[AWL=0.527, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 qeewpozW9CIM for ; Mon, 13 Dec 2010 16:18:59 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id A627B3A6D4F for ; Mon, 13 Dec 2010 16:18:59 -0800 (PST)
Received: from [10.20.30.150] (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id oBE0KUxV085630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Dec 2010 17:20:32 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To: <[email-masked]>
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]>
Date: Mon, 13 Dec 2010 16:20:29 -0800
To: Stephen Farrell , [email-masked]
From: Paul Hoffman
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 14 Dec 2010 00:19:00 -0000

At 11:25 PM +0000 12/13/10, Stephen Farrell wrote:
>Pretty good.

C'mon, you're usually pricklier than that! :-)

>Questions below. Not expecting fully worked our answers now,
>but am expecting them at some point.

As Warren said earlier, we have a WG secretary, and he'll be opening issues on the WG issue tracker. We can tackle them at any time.

>- How are self-signed certs handled? Are they type 1/2 or 3/4? I
>think picking one and explicitly saying that's how its done would
>be best. (I don't care which, I just care that we say exactly how
>to use self-signed certs with DANE.)

Yes. That is, if it is a self-signed cert used as an end-entity cert, it is 1/2; if it is used as a CA cert, it is 3/4. That's why we differentiated by semantics, not the format.

>- How is a hash (or certificate) compared to a trust anchor? 5280
>doesn't specify a TA format, though we mostly use self-signed certs.
>(Does anything use something else? Does anyone really use rfc 5914
>for this?) Might be a bit of a barney to be had about that since
>its hard to pick a format that everyone could use, unless everyone
>has self-signed certs or you go to the bare public key.

Good point. We should say "...as long as your trust anchors are stored as self-signed certs".

>- If an intermediate CA were compromised, then a DNS admin could
>obviate the revocation of the relevant CA cert by adding an RR.
>Not that likely, and detectable, but maybe worth a security
>consideration paragraph since such a case might be fairly
>catastrophic as-is, but would be made worse with DANE.

Good call, yes.

>- Practically, we do have an informal partial-order of hash
>function strength (md5,sha-1,sha-2). I don't think so, but
>would be it worthwhile recommending commensurate-or-better
>strength for the hash in this RR compared with the hash used
>in the x.509 cert signing alg?

I would want to see a security analysis first. In fact, as long as the hash used in the protecting DNSSEC is "strong enough", I'm not sure that there any attack, is there?

>- "If DANE fails then fallback to TLS," seems to open up a
>way for an active attacker (say someone who's taken over
>my home AP) and who's gotten a faked cert and inserted that
>into a TLS handshake to win the game by simply buggering
>up the DANE RR bits. Maybe differentiate between DANE
>matching failure vs. DNSSEC failures? (Not sure myself
>since we start to leak over into policy quickly with
>rules in this area.)

Urrrgh. Worthy discussion and probably will turn into paragraphs in the doc.

>- Sort-of editorial: there are too many "if the client
>trusts..." type statements. I'm sure that'll get better
>over time.

Wording suggestions greatly appreciated.

>- I'd argue to drop the discussion about exclusion. I
>think it only confuses.

It's the term we still hear used, however.

>- I'd like to understand how or whether I can use this
>RR for bare-key protocols. I'm not asking that that all
>be worked out now, but only to be convinced that it can
>be done later if useful, and to know whether it'd work
>based solely on new registry entries for the IANA
>registries defined in this document or if I'd need a
>new RR or whatever.

No, it's for TLS only, which requires a PKIX cert. If there is consensus in the WG to extend it to other protocols, and the extra flexibility is worth it, we can extend it; up to now, no one has shown interest, given that the most obvious bare-key target, SSH, already has its own RRType.

>- And lastly, the big one: the -00 version is silent on
>the "last hop" problem. At minimum I expected a TBD, and
>I sure hope that'll be there in a later version. Right?

Wrong. That work is happening in the DNSEXT WG. Well, it isn't yet, but there is now a draft and a discussion.

>Other than that last point, this is pretty good.

I'm interested in how we can say "must use last-hop technology X" when X doesn't exist. Wording suggestions appreciated.

--Paul Hoffman, Director
--VPN Consortium

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 037343A6E1B for ; Mon, 13 Dec 2010 16:02:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.398
X-Spam-Level:
X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=0.201, 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 U7+QfAWhSMCP for ; Mon, 13 Dec 2010 16:02:40 -0800 (PST)
Received: from emh01.mail.saunalahti.fi (emh01.mail.saunalahti.fi [62.142.5.107]) by core3.amsl.com (Postfix) with ESMTP id B16373A6E19 for ; Mon, 13 Dec 2010 16:02:39 -0800 (PST)
Received: from saunalahti-vams (vs3-11.mail.saunalahti.fi [62.142.5.95]) by emh01-2.mail.saunalahti.fi (Postfix) with SMTP id 36FCE8C59D; Tue, 14 Dec 2010 02:04:17 +0200 (EET)
Received: from emh04.mail.saunalahti.fi ([62.142.5.110]) by vs3-11.mail.saunalahti.fi ([62.142.5.95]) with SMTP (gateway) id A0735E331A1; Tue, 14 Dec 2010 02:04:17 +0200
Received: from LK-Perkele-V2 (a88-112-50-174.elisa-laajakaista.fi [88.112.50.174]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id D5DBD41BE2; Tue, 14 Dec 2010 02:04:13 +0200 (EET)
Date: Tue, 14 Dec 2010 02:04:34 +0200
From: Ilari Liusvaara
To: Stephen Farrell
Message-ID: <[email-masked]>
References: <20101213220001.24500.52050.idtracker@localhost> <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <[email-masked]>
User-Agent: Mutt/1.5.20 (2009-06-14)
Sender: Ilari Liusvaara
X-Antivirus: VAMS
Cc: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 14 Dec 2010 00:02:41 -0000

On Mon, Dec 13, 2010 at 11:25:21PM +0000, Stephen Farrell wrote:
>
> - How are self-signed certs handled? Are they type 1/2 or 3/4? I
> think picking one and explicitly saying that's how its done would
> be best.

AFAICT, Type 1 or 2 (match end-entity certificate, which is the only
one).

> - How is a hash (or certificate) compared to a trust anchor? 5280
> doesn't specify a TA format, though we mostly use self-signed certs.
> (Does anything use something else? Does anyone really use rfc 5914
> for this?) Might be a bit of a barney to be had about that since
> its hard to pick a format that everyone could use, unless everyone
> has self-signed certs or you go to the bare public key.
>
> - If an intermediate CA were compromised, then a DNS admin could
> obviate the revocation of the relevant CA cert by adding an RR.
> Not that likely, and detectable, but maybe worth a security
> consideration paragraph since such a case might be fairly
> catastrophic as-is, but would be made worse with DANE.

That's admins doing stupid things then. The webmaster would for
sure hear about the compromise (required for key rollover!)
and get the DNS updated.

> - "If DANE fails then fallback to TLS," seems to open up a
> way for an active attacker (say someone who's taken over
> my home AP) and who's gotten a faked cert and inserted that
> into a TLS handshake to win the game by simply buggering
> up the DANE RR bits.

Only possible by downgrading entiere DNSSEC away (which makes
client expecting signed root to scream really loud).

> - I'd like to understand how or whether I can use this
> RR for bare-key protocols. I'm not asking that that all
> be worked out now, but only to be convinced that it can
> be done later if useful, and to know whether it'd work
> based solely on new registry entries for the IANA
> registries defined in this document or if I'd need a
> new RR or whatever.

This is for TLS, where bare-key would only be possible if there was
a bare-key certificate type. For IPSEC, which has one, one would
follow its certificate type numbers.

-Ilari

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F17B3A6E0F for ; Mon, 13 Dec 2010 15:43:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.301
X-Spam-Level:
X-Spam-Status: No, score=-3.301 tagged_above=-999 required=5 tests=[AWL=0.297, 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 pLuiFSjR1YSH for ; Mon, 13 Dec 2010 15:43:13 -0800 (PST)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 750A43A6DFA for ; Mon, 13 Dec 2010 15:43:13 -0800 (PST)
Received: by gyd12 with SMTP id 12so16737gyd.31 for ; Mon, 13 Dec 2010 15:44:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=CPXBVLxSYBXD+XTHoZqV3j5ylrwp+n4scvn3rboJblQ=; b=jmWFwgJu0ke4laRreNqKojhzVyuldVv480c65gc7o6VB+7s0CWFbLPuinvOJAJ7fKe 09OJNrKEDtdPtsCQw0gOqMpR/g6dLERkgSgyZUmNYiG2+/izpXSqJhtirJJ74KBG0vyr tNgA67ONUtHiEPgDYHeUOiV4i3fDj8jXZzUHg=
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=MYP/KIFF3jgSSEAsZ6PrfeXPzc7/X3Rc98YqYUXzcasEDvxAdxwDiR72/DdaaX+jEW m7TAnNB1FfgEkaOEZijMufLT7mkXxIym6GTaip7T7bBtw6m7NYs+Z0KRjejjJYCsodty sCUUWd8aJ/NnPleQ2X8eU7SpvT4ChaNAGNV5U=
MIME-Version: 1.0
Received: by 10.100.225.7 with SMTP id x7mr3057909ang.69.1292283891426; Mon, 13 Dec 2010 15:44:51 -0800 (PST)
Received: by 10.100.31.8 with HTTP; Mon, 13 Dec 2010 15:44:51 -0800 (PST)
In-Reply-To:
References: <[email-masked]>
Date: Mon, 13 Dec 2010 18:44:51 -0500
Message-ID:
From: Phillip Hallam-Baker
To: Paul Hoffman
Content-Type: multipart/alternative; boundary=0016369205444c263d0497534afc
Cc: [email-masked]
Subject: Re: [keyassure] Object Digest Reference
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 13 Dec 2010 23:43:14 -0000

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

Assuming that the application is finite, the number of algorithms supported
is going to be finite.

There is no need for any application to know anything about an algorithm it
does not support, other than that it is not supported.

So if the app supports 8 algorithms, a minimal implementation would contain
the 8 prefixes for those algorithms. It would never generate any other
prefix and it would be unable to verify any other prefix. So there would be
no requirement to do anything else.

If you have an application that is built on extensible crypto modules then
you are going to have to write more code anyway if you are going to use
them. But if you are playing that game you are going to have to convert any
identifiers to OIDs in any case.

On Mon, Dec 13, 2010 at 6:10 PM, Paul Hoffman wrote:

> At 5:53 PM -0500 12/13/10, Phillip Hallam-Baker wrote:
> >In response to Paul:
> >
> >There is absolutely no proposal to have a restricted registry of OIDs. You
> keep complaining about people putting words into your mouth and then respond
> to a straw man of your own invention.
>
> I apologize for having made that assumption. I read the following two posts
> from you earlier today:
>
> At 9:57 AM -0500 12/13/10, Phillip Hallam-Baker wrote:
> >I would rather be accused of moderate over-design (ten extra bytes) than
> have to go through WG discussion and then re-litigate the issue with the
> IESG.
>
> At 1:59 PM -0500 12/13/10, Phillip Hallam-Baker wrote:
> >The main reason the CAA draft has the explanation it does is to show that
> a full ASN.1 packer/depacker is not necessary. Everything can be handled off
> fixed pre-calculated prefixes for each supported digest algorithm if that is
> desired.
>
> How can you have unrestricted OIDs and have only ten extra bytes of
> overhead? Some OIDs are longer than that.
>
> If you are using unrestricted OIDs, what does "fixed pre-calculated
> prefixes for each supported digest algorithm" mean?
>
> --Paul Hoffman, Director
> --VPN Consortium
>

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

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

Assuming that the application is finite, the number of algorithms supp=
orted is going to be finite.

There is no need for =
any application to know anything about an algorithm it does not support, ot=
her than that it is not supported.

So if the app supports 8 algorithms, a minimal implemen=
tation would contain the 8 prefixes for those algorithms. It would never ge=
nerate any other prefix and it would be unable to verify any other prefix. =
So there would be no requirement to do anything else.

If you have an application that is built=
on extensible crypto modules then you are going to have to write more code=
anyway if you are going to use them. But if you are playing that game you =
are going to have to convert any identifiers to OIDs in any case.

On Mo=
n, Dec 13, 2010 at 6:10 PM, Paul Hoffman <[email-masked]> wrote:

At 5:53 PM -0500 12/13/10, Phillip Hallam-Baker wrote:
>In response to Paul:

>

>There is absolutely no proposal to have a restricted registry of OIDs. =
You keep complaining about people putting words into your mouth and then re=
spond to a straw man of your own invention.

I apologize for having made that assumption. I read the following two=
posts from you earlier today:

At 9:57 AM -0500 12/13/10, Phillip Hallam-Baker wrote:

>I would rather be accused of moderate over-desi=
gn (ten extra bytes) than have to go through WG discussion and then re-liti=
gate the issue with the IESG.

At 1:59 PM -0500 12/13/10, Phillip Hallam-Baker wro=
te:

>The main reason the CAA draft has the explanation it does is to show th=
at a full ASN.1 packer/depacker is not necessary. Everything can be handled=
off fixed pre-calculated prefixes for each supported digest algorithm if t=
hat is desired.

How can you have unrestricted OIDs and have only ten extra bytes of o=
verhead? Some OIDs are longer than that.

If you are using unrestricted OIDs, what does "fixed pre-calculated pr=
efixes for each supported digest algorithm" mean?

--Paul Hoffman, Director

--VPN Consortium

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

--0016369205444c263d0497534afc--

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 736A43A6E1C for ; Mon, 13 Dec 2010 15:31:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.297
X-Spam-Level:
X-Spam-Status: No, score=-3.297 tagged_above=-999 required=5 tests=[AWL=0.301, 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 z65eM4mNwioY for ; Mon, 13 Dec 2010 15:31:43 -0800 (PST)
Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by core3.amsl.com (Postfix) with ESMTP id 268703A6E1B for ; Mon, 13 Dec 2010 15:31:43 -0800 (PST)
Received: by gxk8 with SMTP id 8so16918gxk.27 for ; Mon, 13 Dec 2010 15:33:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=61BZKPjVWCbD7dkN92S8evcDh/A9lVhb+90lMVYoHzM=; b=YpNa3taVQmVOSDyJYIGO8NOn6BgGMC3qhGWIDFjCHcXqkQ2dxL8mQlX+g4fJ8jPBhB EDaPiWME9+TBxcHGRDkUEGo4zaYjRhMuXCwUL42djSjjfpGjBLjNHhpjcstp6/3xUCdn pqLuVgxOIz9mAsvnIer9HT5iEAwo1LTEgszAo=
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=GO4HQ3ekW+YERlxz75LphyMqX6xAqKQy6wuyqAum5Xj40ltbcMRd3g6nvpoffbe39e bT2YZTPzr4p1uj/brlEeGV9AWaQ0yUpnxeDQSTE7v4xt/n6U13sKq41Ly8/UXES4og0E EYj6Pz7tArxftqWqmvSG79cjeTe3VfyWRaanM=
MIME-Version: 1.0
Received: by 10.100.195.2 with SMTP id s2mr873588anf.35.1292283201258; Mon, 13 Dec 2010 15:33:21 -0800 (PST)
Received: by 10.100.31.8 with HTTP; Mon, 13 Dec 2010 15:33:21 -0800 (PST)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Date: Mon, 13 Dec 2010 18:33:21 -0500
Message-ID:
From: Phillip Hallam-Baker
To: "Richard L. Barnes"
Content-Type: multipart/alternative; boundary=0016e644ba162903fc0497532150
Cc: [email-masked], Paul Hoffman
Subject: Re: [keyassure] Object Digest Reference
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 13 Dec 2010 23:31:44 -0000

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

On Mon, Dec 13, 2010 at 6:03 PM, Richard L. Barnes wrote:

> > The appendix that gives the algorithm IDs merely follows a longstanding
> practice of specifying the small number of values that will actually be used
> in practice and would be specified as MUST. Although it is the intent of the
> IETF to use the NIST values for SHA2, some implementations of certain specs
> did the idiot thing and defined their own.
> >
> > There is not a proposal to create any form of registry whatsoever for
> OIDs, never was. Please do not put words into my mouth and then argue
> against them.
>
> I'm confused. If you're going to "specify a small number of values ... as
> MUST", wouldn't you need a registry to keep track of which values were MUST
> at a given time?
>

No. IANA registries are not normative

Only standards track RFCs are normative. The registries merely track the
status of the normative RFC text.

> I guess the benefit of OIDs in that scenario is that you don't have to
> create registry values for the non-MUSTs, you just use them. But then
> again, you could also use an existing registry for this. For example, are
> you anticipating usage of algorithms that aren't in the TLS registry [1], or
> which won't be added later?
>

I am anticipating use by security applications that are not TLS.

If I have records for IPSEC, TLS and S/MIME, I do not want to have to have
different handling code for each one.

And I certainly don't want to have to track TLS assignments in my IPSEC
code.

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

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

On Mon, Dec 13, 2010 at 6:03 PM, Richard=
L. Barnes <rbarnes=
@bbn.com> wrote:

> The appendix that gives the algorithm IDs merely fol=
lows a longstanding practice of specifying the small number of values that =
will actually be used in practice and would be specified as MUST. Although =
it is the intent of the IETF to use the NIST values for SHA2, some implemen=
tations of certain specs did the idiot thing and defined their own.

>

> There is not a proposal to create any form of registry whatsoever for =
OIDs, never was. Please do not put words into my mouth and then argue again=
st them.

I'm confused. =A0If you're going to "specify a small num=
ber of values ... as MUST", wouldn't you need a registry to keep t=
rack of which values were MUST at a given time?

No. IANA registries are not normative

O=
nly standards track RFCs are normative. The registries merely track the sta=
tus of the normative RFC text.

=A0

I guess the benefit of OIDs in that scenario is that you don't have to =
create registry values for the non-MUSTs, you just use them. =A0But then ag=
ain, you could also use an existing registry for this. =A0For example, are =
you anticipating usage of algorithms that aren't in the TLS registry [1=
], or which won't be added later?

I am anticipating use by security applicat=
ions that are not TLS.

If I have records for IPSEC=
, TLS and S/MIME, I do not want to have to have different handling code for=
each one.=A0

And I certainly don't want to have to track TLS ass=
ignments in my IPSEC code.

=A0

--
W=
ebsite: http://hallambaker.com/

--0016e644ba162903fc0497532150--

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CAE03A6DFF for ; Mon, 13 Dec 2010 15:23:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 0N3nn2DXggQB for ; Mon, 13 Dec 2010 15:23:46 -0800 (PST)
Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:21b:21ff:fe3a:3d50]) by core3.amsl.com (Postfix) with ESMTP id 204033A6D4A for ; Mon, 13 Dec 2010 15:23:44 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id C4E203E4090 for ; Mon, 13 Dec 2010 23:25:22 +0000 (GMT)
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=1292282722; bh=75VjmAC5e7GAWX BVgLrOlOnA4uKC6Apl8tz59yzQaRk=; b=ZVkkUhAcQHH/7nGLK9pZczujOI1ssQ smn6zHETxCY5mEW+fAcZNt1FPIrphJIgVOKlItmVEPs/oylma1lktMQ+f2z+rLvu VcIqOZ+5n7spR9MVUCoxLs7z/cChZnYjlhtnAfTAtOv0ppzVszPbGVKToHyhC//Z 6og/Y/R0uGB37U997AIzVYHCl0RvxSOIacSXwiNPkryjnYWrjPbSrh6k+g82BBoX 4YS3xuRmBetfAD40Lv7PszfQdSyWGpG/KHHS+Kk4sFFM/7PDECbQ1bX0ONPbncOv 0PK2VfAYSuMYTV8dhZg18mcA1KUHl8lk/FyO7/DwJVZKn+9aH9Vl702Q==
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 y-ajAkzY2BZD for ; Mon, 13 Dec 2010 23:25:22 +0000 (GMT)
Received: from [10.87.48.6] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 7DDE53E4076 for ; Mon, 13 Dec 2010 23:25:22 +0000 (GMT)
Message-ID: <[email-masked]>
Date: Mon, 13 Dec 2010 23:25:21 +0000
From: Stephen Farrell
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7
MIME-Version: 1.0
To: [email-masked]
References: <20101213220001.24500.52050.idtracker@localhost>
In-Reply-To: <20101213220001.24500.52050.idtracker@localhost>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 13 Dec 2010 23:23:47 -0000

Pretty good.

Questions below. Not expecting fully worked our answers now,
but am expecting them at some point.

- How are self-signed certs handled? Are they type 1/2 or 3/4? I
think picking one and explicitly saying that's how its done would
be best. (I don't care which, I just care that we say exactly how
to use self-signed certs with DANE.)

- How is a hash (or certificate) compared to a trust anchor? 5280
doesn't specify a TA format, though we mostly use self-signed certs.
(Does anything use something else? Does anyone really use rfc 5914
for this?) Might be a bit of a barney to be had about that since
its hard to pick a format that everyone could use, unless everyone
has self-signed certs or you go to the bare public key.

- If an intermediate CA were compromised, then a DNS admin could
obviate the revocation of the relevant CA cert by adding an RR.
Not that likely, and detectable, but maybe worth a security
consideration paragraph since such a case might be fairly
catastrophic as-is, but would be made worse with DANE.

- Practically, we do have an informal partial-order of hash
function strength (md5,sha-1,sha-2). I don't think so, but
would be it worthwhile recommending commensurate-or-better
strength for the hash in this RR compared with the hash used
in the x.509 cert signing alg?

- "If DANE fails then fallback to TLS," seems to open up a
way for an active attacker (say someone who's taken over
my home AP) and who's gotten a faked cert and inserted that
into a TLS handshake to win the game by simply buggering
up the DANE RR bits. Maybe differentiate between DANE
matching failure vs. DNSSEC failures? (Not sure myself
since we start to leak over into policy quickly with
rules in this area.)

- Sort-of editorial: there are too many "if the client
trusts..." type statements. I'm sure that'll get better
over time.

- I'd argue to drop the discussion about exclusion. I
think it only confuses.

- I'd like to understand how or whether I can use this
RR for bare-key protocols. I'm not asking that that all
be worked out now, but only to be convinced that it can
be done later if useful, and to know whether it'd work
based solely on new registry entries for the IANA
registries defined in this document or if I'd need a
new RR or whatever.

- And lastly, the big one: the -00 version is silent on
the "last hop" problem. At minimum I expected a TBD, and
I sure hope that'll be there in a later version. Right?

Other than that last point, this is pretty good.

S.

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A08A3A6E1B for ; Mon, 13 Dec 2010 15:08:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.514
X-Spam-Level:
X-Spam-Status: No, score=-101.514 tagged_above=-999 required=5 tests=[AWL=0.532, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 LSNVdI-+cYRs for ; Mon, 13 Dec 2010 15:08:33 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 5A2503A6E17 for ; Mon, 13 Dec 2010 15:08:33 -0800 (PST)
Received: from [10.20.30.150] (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id oBDNA9MO083234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Dec 2010 16:10:10 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References: <[email-masked]>
Date: Mon, 13 Dec 2010 15:10:07 -0800
To: Phillip Hallam-Baker
From: Paul Hoffman
Content-Type: text/plain; charset="us-ascii"
Cc: [email-masked]
Subject: Re: [keyassure] Object Digest Reference
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 13 Dec 2010 23:08:34 -0000

At 5:53 PM -0500 12/13/10, Phillip Hallam-Baker wrote:
>In response to Paul:
>
>There is absolutely no proposal to have a restricted registry of OIDs. You keep complaining about people putting words into your mouth and then respond to a straw man of your own invention.

I apologize for having made that assumption. I read the following two posts from you earlier today:

At 9:57 AM -0500 12/13/10, Phillip Hallam-Baker wrote:
>I would rather be accused of moderate over-design (ten extra bytes) than have to go through WG discussion and then re-litigate the issue with the IESG.

At 1:59 PM -0500 12/13/10, Phillip Hallam-Baker wrote:
>The main reason the CAA draft has the explanation it does is to show that a full ASN.1 packer/depacker is not necessary. Everything can be handled off fixed pre-calculated prefixes for each supported digest algorithm if that is desired.

How can you have unrestricted OIDs and have only ten extra bytes of overhead? Some OIDs are longer than that.

If you are using unrestricted OIDs, what does "fixed pre-calculated prefixes for each supported digest algorithm" mean?

--Paul Hoffman, Director
--VPN Consortium

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAECA28C0CF for ; Mon, 13 Dec 2010 15:02:07 -0800 (PST)
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.500, 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 gwAmk98-d6G3 for ; Mon, 13 Dec 2010 15:02:06 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id B706E3A6E08 for ; Mon, 13 Dec 2010 15:02:06 -0800 (PST)
Received: from ros-dhcp192-1-51-22.bbn.com ([192.1.51.22]:49762) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PSHQl-0002M5-Ee; Mon, 13 Dec 2010 18:03:44 -0500
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: "Richard L. Barnes"
In-Reply-To:
Date: Mon, 13 Dec 2010 18:03:40 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <[email-masked]>
References: <[email-masked]>
To: Phillip Hallam-Baker
X-Mailer: Apple Mail (2.1082)
Cc: [email-masked], Paul Hoffman
Subject: Re: [keyassure] Object Digest Reference
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 13 Dec 2010 23:02:08 -0000

> The appendix that gives the algorithm IDs merely follows a =
longstanding practice of specifying the small number of values that will =
actually be used in practice and would be specified as MUST. Although it =
is the intent of the IETF to use the NIST values for SHA2, some =
implementations of certain specs did the idiot thing and defined their =
own.=20
>=20
> There is not a proposal to create any form of registry whatsoever for =
OIDs, never was. Please do not put words into my mouth and then argue =
against them.

I'm confused. If you're going to "specify a small number of values ... =
as MUST", wouldn't you need a registry to keep track of which values =
were MUST at a given time?

I guess the benefit of OIDs in that scenario is that you don't have to =
create registry values for the non-MUSTs, you just use them. But then =
again, you could also use an existing registry for this. For example, =
are you anticipating usage of algorithms that aren't in the TLS registry =
[1], or which won't be added later?

--Richard=20

[1] =

>=20
> On Mon, Dec 13, 2010 at 4:01 PM, Ilari Liusvaara =
wrote:
>=20
> > Now absent some really clear indication to the contrary, using ASN.1 =
OIDs
> > for identifying cryptographic algs and formats is pretty much a slam =
dunk. I
> > can't see how anyone could say that it is not an acceptable way to =
go for
> > any application layer design.
>=20
> Programming complexity. Which is big deal when you are writting this =
stuff
> in C or C++ for practical end applications.
>=20
> And yes, I'm assuming prefixes are precomputed.
>=20
> I looked at piece of code I have written that handles ASN.1-encoded =
hashes.
> All I can say is "yuck". I'd much rather deal with small integers =
(even
> if the set has gaps).
>=20
> I can't quite see where the problem comes in. I have written a full =
X.509v3 decoder in Javascript. Why would C be an issue?=20
>=20
> I can do this in about a screenful of code including the =
documentation.
>=20
>=20
> > They are bad within DNSSEC. But unavoidable at the upper layers. I =
would
> > prefer not to have to support PGP and other key formats in this =
scheme, but
> > they are going to be unavoidable politically.
>=20
> I haven't seen any overly bad stuff with DNSSEC (granted, how many
> implementations support GOST, but the problem). But I have seen =
_PLENTY_ of
> bad stuff with X.509.
>=20
> I am rather concerned about some of the peculiar ways in which X.509 =
has been abused. Often times it seems to be that the main design =
constraint is to produce something that will bring in repeat consulting =
work.=20
>=20
> Granted nothing bad is likely to happen when competent people are =
doing design and implementation. However that is not the real world. We =
recently had a huge issue in XML signature space due to people making =
some very bad implementation decisions.
>=20
> =20
> > I don't like having to deal with all that. But what I really, really =
want to
> > avoid is having application layer crypto impact DNSSEC.
>=20
> his is just about how to denote hash algorithms. And what about fairly
> reasonable hash algorithms that seeming have no OID?
>=20
> Like what?
>=20
> Any hash alg that is used in practice is going to have at least one =
OID defined.
>=20
>=20
> --=20
> Website: http://hallambaker.com/
>=20
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 636DD28C0F8 for ; Mon, 13 Dec 2010 14:52:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.351
X-Spam-Level:
X-Spam-Status: No, score=-3.351 tagged_above=-999 required=5 tests=[AWL=0.247, 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 vcD3Mn4nkHQ5 for ; Mon, 13 Dec 2010 14:52:07 -0800 (PST)
Received: from mail-gw0-f42.google.com (mail-gw0-f42.google.com [74.125.83.42]) by core3.amsl.com (Postfix) with ESMTP id A63C53A6D0C for ; Mon, 13 Dec 2010 14:52:07 -0800 (PST)
Received: by gwb20 with SMTP id 20so6235981gwb.15 for ; Mon, 13 Dec 2010 14:53:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=hU2H6iZG/4aberTVDVZtKYK/7nqt5TRR94V30dj0oqw=; b=Ep0T5R+57vo/lrXlY72EdTgPH2hRC3/8ps2P0wkp7rgpLAE5nPoksdlTZ75cBQYCTc +EuN9Du/M3LLqISMr6NbXdu3lq/qOW1FvSzcatRkAGIVfUufWTRQyV+RgEfjoIIMOhsB W1zVMIB5KjGz8XhB8gtBjmE+wOlca2cCl4Hlo=
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=dcZH8h6e0uBZ0AaRmBA0RXI1J2kd695u9RKndHV0SSmGVBWuuVyRYPhoHECThv3rAx 54KFraziuwegstKfhH+sljdYnKYCSe7MnqjpWWdimUAMTM0WZuCub+uGgyKZwm8MQ6FX A9TyHKWZ7FZgnwKeviMPKMT/Cs807UIXraFE4=
MIME-Version: 1.0
Received: by 10.100.225.7 with SMTP id x7mr3030963ang.69.1292280825977; Mon, 13 Dec 2010 14:53:45 -0800 (PST)
Received: by 10.100.31.8 with HTTP; Mon, 13 Dec 2010 14:53:45 -0800 (PST)
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Mon, 13 Dec 2010 17:53:45 -0500
Message-ID:
From: Phillip Hallam-Baker
To: Ilari Liusvaara
Content-Type: multipart/alternative; boundary=001636920544951c590497529308
Cc: [email-masked], Paul Hoffman
Subject: Re: [keyassure] Object Digest Reference
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 13 Dec 2010 22:52:09 -0000

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

In response to Paul:

There is absolutely no proposal to have a restricted registry of OIDs. You
keep complaining about people putting words into your mouth and then respond
to a straw man of your own invention.

OIDs are OIDs, there is no proposal to restrict them.

If someone puts something in the OID slot that a relying party can't
understand then the RP is not going to be able to use it.

The appendix that gives the algorithm IDs merely follows a longstanding
practice of specifying the small number of values that will actually be used
in practice and would be specified as MUST. Although it is the intent of the
IETF to use the NIST values for SHA2, some implementations of certain specs
did the idiot thing and defined their own.

There is not a proposal to create any form of registry whatsoever for OIDs,
never was. Please do not put words into my mouth and then argue against
them.

On Mon, Dec 13, 2010 at 4:01 PM, Ilari Liusvaara <
[email-masked]> wrote:

> Now absent some really clear indication to the contrary, using ASN.1 OIDs
> > for identifying cryptographic algs and formats is pretty much a slam
> dunk. I
> > can't see how anyone could say that it is not an acceptable way to go for
> > any application layer design.
>
> Programming complexity. Which is big deal when you are writting this stuff
> in C or C++ for practical end applications.
>
> And yes, I'm assuming prefixes are precomputed.
>
> I looked at piece of code I have written that handles ASN.1-encoded hashes.
> All I can say is "yuck". I'd much rather deal with small integers (even
> if the set has gaps).

I can't quite see where the problem comes in. I have written a full X.509v3
decoder in Javascript. Why would C be an issue?

I can do this in about a screenful of code including the documentation.

> They are bad within DNSSEC. But unavoidable at the upper layers. I would
> > prefer not to have to support PGP and other key formats in this scheme,
> but
> > they are going to be unavoidable politically.
>
> I haven't seen any overly bad stuff with DNSSEC (granted, how many
> implementations support GOST, but the problem). But I have seen _PLENTY_ of
> bad stuff with X.509.

I am rather concerned about some of the peculiar ways in which X.509 has
been abused. Often times it seems to be that the main design constraint is
to produce something that will bring in repeat consulting work.

Granted nothing bad is likely to happen when competent people are doing
design and implementation. However that is not the real world. We recently
had a huge issue in XML signature space due to people making some very bad
implementation decisions.

> > I don't like having to deal with all that. But what I really, really want
> to
> > avoid is having application layer crypto impact DNSSEC.
>
> his is just about how to denote hash algorithms. And what about fairly
> reasonable hash algorithms that seeming have no OID?

Like what?

Any hash alg that is used in practice is going to have at least one OID
defined.

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

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

In response to Paul:

There is absolutely no proposal to =
have a restricted registry of OIDs. You keep complaining about people putti=
ng words into your mouth and then respond to a straw man of your own invent=
ion.

OIDs are OIDs, there is no proposal to restrict them.=
=A0

If someone puts something in the OID slot that=
a relying party can't understand then the RP is not going to be able t=
o use it.

The appendix that gives the algorithm IDs merely follow=
s a longstanding practice of specifying the small number of values that wil=
l actually be used in practice and would be specified as MUST. Although it =
is the intent of the IETF to use the NIST values for SHA2, some implementat=
ions of certain specs did the idiot thing and defined their own.=A0

There is not a proposal to create any form of registry =
whatsoever for OIDs, never was. Please do not put words into my mouth and t=
hen argue against them.

On Mon, Dec 13, 2010 at 4:01 PM, Ilari Liusvaara <[email-masked]&=
gt; wrote:

> Now absent some really clear indication to the contrary, using ASN.1 O=
IDs

> for identifying cryptographic algs and formats is pretty much a slam d=
unk. I

> can't see how anyone could say that it is not an acceptable way to=
go for

> any application layer design.

Programming complexity. Which is big deal when you are writting this =
stuff

in C or C++ for practical end applications.

And yes, I'm assuming prefixes are precomputed.

I looked at piece of code I have written that handles ASN.1-encoded hashes.=

All I can say is "yuck". I'd much rather deal with small inte=
gers (even

if the set has gaps).

I can't quite see=
where the problem comes in. I have written a full X.509v3 decoder in Javas=
cript. Why would C be an issue?=A0

I can do this i=
n about a screenful of code including the documentation.

> They are bad within DNSSEC. But unavoidable at the upper layers. I wou=
ld

> prefer not to have to support PGP and other key formats in this scheme=
, but

> they are going to be unavoidable politically.

I haven't seen any overly bad stuff with DNSSEC (granted, how man=
y

implementations support GOST, but the problem). But I have seen _PLENTY_ of=

bad stuff with X.509.

I am rather concerned=
about some of the peculiar ways in which X.509 has been abused. Often time=
s it seems to be that the main design constraint is to produce something th=
at will bring in repeat consulting work.=A0

Granted nothing bad is likely to happen when competent =
people are doing design and implementation. However that is not the real wo=
rld. We recently had a huge issue in XML signature space due to people maki=
ng some very bad implementation decisions.

=A0

> I don't like having to deal with all that. But what I really, real=
ly want to

> avoid is having application layer crypto impact DNSSEC.

his is just about how to denote hash algorithms. And what about fairl=
y

reasonable hash algorithms that seeming have no OID?

<=
/div>
Like what?

Any hash alg that is used in =
practice is going to have at least one OID defined.

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

--001636920544951c590497529308--

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75BB93A6D42; Mon, 13 Dec 2010 14:00:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.326
X-Spam-Level:
X-Spam-Status: No, score=-102.326 tagged_above=-999 required=5 tests=[AWL=0.273, 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 nbBH3YAZVXHs; Mon, 13 Dec 2010 14:00:01 -0800 (PST)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6B273A6D31; Mon, 13 Dec 2010 14:00:01 -0800 (PST)
MIME-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
From: [email-masked]
To: [email-masked]
X-Test-IDTracker: no
X-IETF-IDTracker: 3.10
Message-ID: <20101213220001.24500.52050.idtracker@localhost>
Date: Mon, 13 Dec 2010 14:00:01 -0800
Cc: [email-masked]
Subject: [keyassure] I-D Action:draft-ietf-dane-protocol-00.txt
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 13 Dec 2010 22:00:02 -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 : Using Secure DNS to Associate Certificates with Domain Names For TLS
Author(s) : P. Hoffman, J. Schlyter
Filename : draft-ietf-dane-protocol-00.txt
Pages : 9
Date : 2010-12-12

TLS and DTLS use certificates for authenticating the server. Users
want their applications to verify that the certificate provided by
the TLS server is in fact associated with the domain name they
expect. 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. This document describes how to use secure DNS to
associate the TLS server's certificate with the the intended domain
name.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dane-protocol-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-protocol-00.txt";
site="ftp.ietf.org"; access-type="anon-ftp";
directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--NextPart--

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 252C228C0F3 for ; Mon, 13 Dec 2010 12:59:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.358
X-Spam-Level:
X-Spam-Status: No, score=-2.358 tagged_above=-999 required=5 tests=[AWL=0.241, 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 co3jaoC9UheJ for ; Mon, 13 Dec 2010 12:59:13 -0800 (PST)
Received: from emh06.mail.saunalahti.fi (emh06.mail.saunalahti.fi [62.142.5.116]) by core3.amsl.com (Postfix) with ESMTP id CD32128C0DF for ; Mon, 13 Dec 2010 12:59:12 -0800 (PST)
Received: from saunalahti-vams (vs3-10.mail.saunalahti.fi [62.142.5.94]) by emh06-2.mail.saunalahti.fi (Postfix) with SMTP id DB948C7E4F; Mon, 13 Dec 2010 23:00:50 +0200 (EET)
Received: from emh04.mail.saunalahti.fi ([62.142.5.110]) by vs3-10.mail.saunalahti.fi ([62.142.5.94]) with SMTP (gateway) id A045BED81F8; Mon, 13 Dec 2010 23:00:50 +0200
Received: from LK-Perkele-V2 (a88-112-50-174.elisa-laajakaista.fi [88.112.50.174]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id 5169841BE2; Mon, 13 Dec 2010 23:00:47 +0200 (EET)
Date: Mon, 13 Dec 2010 23:01:07 +0200
From: Ilari Liusvaara
To: Phillip Hallam-Baker
Message-ID: <[email-masked]>
References:
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To:
User-Agent: Mutt/1.5.20 (2009-06-14)
Sender: Ilari Liusvaara
Content-Transfer-Encoding: quoted-printable
X-Antivirus: VAMS
Cc: [email-masked], Paul Hoffman
Subject: Re: [keyassure] Object Digest Reference
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 13 Dec 2010 20:59:14 -0000

On Mon, Dec 13, 2010 at 01:59:28PM -0500, Phillip Hallam-Baker wrote:
> On Mon, Dec 13, 2010 at 11:04 AM, Paul Hoffman w=
rote:
>=20
> Some folk on this list doubted that a semantic substitution attack was =
an
> issue for the KEYASSURE/CERT proposal.

I can't find any way to perform semantic substution attack against=20
draft-hoffman-keys-linkage-from-dns-03 even in the most pathological
situations (that don't involve much easier attacks anyway).

BTW: TLS itself can't defend against such attacks, it just relies that
attacker doesn't have such capabilites.

> Now absent some really clear indication to the contrary, using ASN.1 OI=
Ds
> for identifying cryptographic algs and formats is pretty much a slam du=
nk. I
> can't see how anyone could say that it is not an acceptable way to go f=
or
> any application layer design.

Programming complexity. Which is big deal when you are writting this stuf=
f
in C or C++ for practical end applications.

And yes, I'm assuming prefixes are precomputed.

I looked at piece of code I have written that handles ASN.1-encoded hashe=
s.
All I can say is "yuck". I'd much rather deal with small integers (even
if the set has gaps).

> They are bad within DNSSEC. But unavoidable at the upper layers. I woul=
d
> prefer not to have to support PGP and other key formats in this scheme,=
but
> they are going to be unavoidable politically.

I haven't seen any overly bad stuff with DNSSEC (granted, how many
implementations support GOST, but the problem). But I have seen _PLENTY_ =
of
bad stuff with X.509.

> I don't like having to deal with all that. But what I really, really wa=
nt to
> avoid is having application layer crypto impact DNSSEC.

his is just about how to denote hash algorithms. And what about fairly
reasonable hash algorithms that seeming have no OID?

> OK, how about on a web page. Imagine that we have a web page that is
> downloaded from a TLS site but the images are stored on a separate imag=
e
> server that does not have TLS.
>=20
> At the moment this is such a common use case that it is really difficul=
t to
> get enforcement on because it is so common. And there is another variat=
ion
> where the data linked to is not even in the same domain.
>=20
> Imagine we can create a link of the form:
>=20
> odr=3D"odr:woei2oqur02que0o2quefoiqwefouqwefoiu=3D=3D"/>
>=20
> Packaging it up as a URI is not strictly necessary but that is what it =
is
> functionally.
>=20
> One could even have a cache of content referenced by ODR lookup. So if =
the
> content is not locatable, it can be pulled from cache.
>=20
> odr=3D"odr:woqi12o3o12hroiqhweoiqhwe=3D=3D">RFC 6666
=20
What does that ODR encode about the semantics in both cases? That the fil=
e
is a GIF in above case (what's the OID of GIF?) and that it is text file
(what character set=E2=80=BD; what is say, OID of ASCII text file?).

-Ilari

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECD4328C0EB for ; Mon, 13 Dec 2010 11:43:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.297
X-Spam-Level:
X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[AWL=0.302, 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 nf7qfDA2QcEI for ; Mon, 13 Dec 2010 11:43:08 -0800 (PST)
Received: from emh06.mail.saunalahti.fi (emh06.mail.saunalahti.fi [62.142.5.116]) by core3.amsl.com (Postfix) with ESMTP id 1680428C0DF for ; Mon, 13 Dec 2010 11:43:08 -0800 (PST)
Received: from saunalahti-vams (vs3-11.mail.saunalahti.fi [62.142.5.95]) by emh06-2.mail.saunalahti.fi (Postfix) with SMTP id 5553DC7DD8; Mon, 13 Dec 2010 21:44:45 +0200 (EET)
Received: from emh03.mail.saunalahti.fi ([62.142.5.109]) by vs3-11.mail.saunalahti.fi ([62.142.5.95]) with SMTP (gateway) id A04F3E5119B; Mon, 13 Dec 2010 21:44:45 +0200
Received: from LK-Perkele-V2 (a88-112-50-174.elisa-laajakaista.fi [88.112.50.174]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id C4A55158A63; Mon, 13 Dec 2010 21:44:41 +0200 (EET)
Date: Mon, 13 Dec 2010 21:45:01 +0200
From: Ilari Liusvaara
To: Paul Hoffman
Message-ID: <[email-masked]>
References:
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To:
User-Agent: Mutt/1.5.20 (2009-06-14)
Sender: Ilari Liusvaara
Content-Transfer-Encoding: quoted-printable
X-Antivirus: VAMS
Cc: [email-masked], Phillip Hallam-Baker
Subject: Re: [keyassure] Object Digest Reference
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 13 Dec 2010 19:43:10 -0000

On Mon, Dec 13, 2010 at 08:04:16AM -0800, Paul Hoffman wrote:
> At 9:57 AM -0500 12/13/10, Phillip Hallam-Baker wrote:
> >While some might argue that the ODR construct guards against attacks t=
hat
> > may or may not be relevant,
>=20
> Who is "some" here, and what kind of attacks does "some" claim that an
> ASN.1 sequence guards against that concatenating the three fields
> themselves doesn't?

The attacks guarded against here seem to be:

- Interpretting something as hash to wrong type of thing. Which I'm not
convinced is serious problem in this case (DANE) because if the orignal
is maliscous, all that matters is resistance against invalid input, and
that is required anyway (and is not our responsibility, except for not
designing formats that are overly hard to parse).
- Interpretting the value as wrong hash. Which can't happen anyway becaus=
e
there are quite a lot of hash functions for pretty much any length and =
one
needs to know the hash function to use anyway.=20

E.g. you see a 512-bit hash. Is it:

- SHA-512?
- BLAKE-512?
- Gr=C3=B8stl-512?
- JH-512?
- Keccak-512?
- Skein-512-512 (oh, and there's Skein-1024-512 too...)?
- Whirlpool?

None of those is even close of being broken and all have taken fair amoun=
t
of cryptoanalysis (5 of those 7 are the SHA-3 finalists).

> >the overhead is trivial and as far as I can see there is no room to ar=
gue
> >that it is under-designed.
>=20
> The size overhead is small, the programming overhead maybe not so much.

Even variable-length fixed prefixes can be nontrivial (at least comprared=
to
fixed-length fixed prefixes, especially small-integer).

> >Provided the ODR itself is authentic,
>=20
> What does "authentic" mean in this context?

Presumably means the ODR itself is good (as opposed to bad/maliscous).
Pretty much obvious assumption.
=20
> >it provides a strong cryptographic reference to a specific string
> >of bits with a specified semantic interpretation using a specified dig=
est
> > algorithm.
>=20
> Do you believe that it is a stronger cryptographic reference than
> concatenating the three fields (the first two of which are fixed-length=
)?
> If so, why?

And I'm not convinced the type field is needed anyway, because it is impl=
icit
from surrounding context unless the whole thing is badly designed. And if=
it
is impicit, it will just be duplication of information (which is bad).

> >The OID space is extensible, anyone can register code points. X.509 ce=
rts
> >already use this registry so re-use does not introduce a new registry.
>
> Fully agree. And the free extensibility leads to lack of interoperabili=
ty
> and confusion. Many people consider those to be bad features.

There are basically two problems with such extensibility:
- Strange hash functions that use some very obscure identifiers and are v=
ery
hard to find specs of (not a good thing, furthermore, such hash functio=
ns
are quite often weak or at least of questionable quality).
- Identifier duplication (that is just plain bad and only leads to
interoperability problems, and yes, it really does happen a lot with X.=
509).

As for the "SHA-3 problem", if you want get up and running fast after SHA=
-3
is announced, just reserve the codepoints for its variants, specify that
those codepoints will behave like SHA-2 codepoints, but with SHA-3 hash
functions used instead. Then after NIST annouces SHA-3, publish RFC forma=
lly
allocating those codepoints (that RFC will be like two pages including
broilerplate text, and most of it will be broilerplate text).

> >While it is tempting to re-use the DNSSEC code points, they serve a
> different purpose in my view. Key assure is application level crypto an=
d
> should use an application level identifier registry. That is either the
> ascii label registry or the OIDs.
>=20
> TLS is a protocol used by application-layer clients and servers. Why no=
t
> reuse its registries (which are neither ASCII or OIDs)?

Ah yeah, TLS has HashAlgorithm. Presently it has MD5 (blech!), SHA-1
(hmm...) and SHA-2s (which are OK hash functions, but...).

DNSSEC really has no registry of hash functions, but if one downcasts
those signature-hash pairs into just hashes, it has SHA-1, SHA-256/512
and GOST, which is slightly better...

But on the other hand, it is logical to use TLS registry of hash algorith=
ms
for data to be used with TLS (since you are going to have to support some
of those and have compatible interpretations because otherwise you can
screw up the TLS handshake anyway).

> >In the future I would like to see algorithm management for application
> layer crypto taken over by SAAG or some other group and managed across =
the
> whole application space. I would like DANE to be in that pool and not a=
n
> odd appendage to DNSSEC.
>=20
> If that happens, DANE could certainly be updated.

And SAAG appears to be overkill anyway (assuming I found the right SAAG..=
.)

> >The other reason for having a little more overhead here is that an ODR
> >can be used as a totally generic fingerprint.
>=20
> It is true that an ODR can be used as a totally generic fingerprint;
> so can any binary or ASCII representation.

Even ASCII representations are easier than variable-length fixed-prefix
representations (since most languages have at least somewhat decent
string functions).

> >It is something that we can perhaps expect a cryptographic
> >application to emit as a matter of course. I would like to be able
> >to cut and paste ODRs from one place to another.
>=20
> That sounds good.

I would like to see ASCII hexadecimal hashes together with hash function
specifier, like say "sha1:93c6a49361c7537a25ca44f98625d76537ce6b60", for
that.

> >Having the semantic tag in the digest makes it secure against a semant=
ic
> >substitution attack and enables cut n' paste type use.
>=20
> How would such a substitution attack on an ODR or other blob happen wit=
hout
> there being a serious degredation of the preimage strength of the diges=
t
> algorithm? You claimed otherwise earlier on the list but didn't justify=
your
> argument, and some of us disagreed with you.

As said, semantic interpretations can be app-specific or span application=
s.

In case of DANE, the only possible semantic attack that is forseeable (an=
d
it isn't likely exploitable anyway because it would seem to require getti=
ng
maliscous interpretation out of honest certificate) is confusing diffrent
certifacte types. Any other semantic attack would trivially yield semanti=
c
attack against TLS.

If honesty of originator to themselves can be assumed actually matters.
That's the reason why clients usually don't try to check asymmetric key
crypto except against basic mathematical constraints and just assume the
keys are generated well (there are many ways to totally screw up RSA
or DSA key generation or DSA key usage).

> >If the group wants to go this way, I would suggest that we unhook the
> >ODR component from the CAA draft and make it a standards track WG
> document. It is probably best that it be a separate document as the
> whole point is to make it a generic construct like Base64.
> >
> >In addition to the binary form, I would add in a URI encoding form
> and make the relevant application.
>=20
> Can you give an example of where the URI encoded form could be useful?

There already is proposal for such form (documented in WHATWG Wiki).
Granted, it doesn't have MIME type for data specified, which opens some
theoretical attacks (that don't seem practical).

Basically the intended purpose of that is to validate downloads against
corruption (non-intentional) and tampering (intentional) when downloading
from other servers.

-Ilari

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02DE328C127 for ; Mon, 13 Dec 2010 11:39:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.787
X-Spam-Level:
X-Spam-Status: No, score=-100.787 tagged_above=-999 required=5 tests=[AWL=-0.199, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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 0fyxdwah2UOg for ; Mon, 13 Dec 2010 11:39:52 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 2D82D28C121 for ; Mon, 13 Dec 2010 11:39:52 -0800 (PST)
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 oBDJfQwH075081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Dec 2010 12:41:28 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References:
Date: Mon, 13 Dec 2010 11:41:22 -0800
To: Phillip Hallam-Baker
From: Paul Hoffman
Content-Type: text/html; charset="us-ascii"
Cc: [email-masked]
Subject: Re: [keyassure] Object Digest Reference
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 13 Dec 2010 19:39:54 -0000

At 1:59 PM -0500 12/13/10, Phillip Hallam-Baker wrote:

On Mon, Dec 13, 2010 at 11:04 AM, Paul
Hoffman <[email-masked]>
wrote:

At 9:57 AM -0500 12/13/10, Phillip Hallam-Baker wrote:

>While some might argue that the ODR construct guards against
attacks that may or may not be relevant,

Who is "some" here, and what kind of attacks
does "some" claim that an ASN.1 sequence guards against that
concatenating the three fields themselves doesn't

Some folk on this list doubted that a
semantic substitution attack was an issue for the KEYASSURE/CERT
proposal.

I am pretty sure that a semantic
substitution attack would be a very big deal if multiple cert/key
formats are allowed. In particular, I think we can end up with a
situation where minimal implementations could be attacked if they have
less than full X.509 / SAML / whatever stacks.

If there are only two formats (full PKIX certificates and
hash-of-PKIX certificates), do you still see a substitution
attack?

> the overhead is trivial and as far as I can see there
is no room to argue that it is under-designed.

The size overhead is small, the programming overhead maybe
not so much.

A full ASN.1 stack is a PITA,
agreed.

The main reason the CAA draft has the
explanation it does is to show that a full ASN.1 packer/depacker is
not necessary. Everything can be handled off fixed pre-calculated
prefixes for each supported digest algorithm if that is
desired.

Your "precalculated prefixes" in -caa-01 only works if
the parties use the defined prefixes. What if they use something else
from the OID tree? If the standard does *not* allow the flexibility of
OIDs and requires things from a very narrow part of the OID tree (as
-caa-01 suggests but does not say so clearly), what is the advantage
of using OIDs over a registry?

>I would rather be accused of moderate over-design (ten
extra bytes) than have to go through WG discussion and then
re-litigate the issue with the IESG.

Please define "re-litigate". This is a serious
matter.

Well, in KeyProv we made a bunch of
design decisions that nobody much cared about very much, just provided
that there was a canonical form of password encoding. Then during last
call, we discovered that it was something that people cared very much
was done in the same way that SASL is done and so ended up changing to
reference one of your own RFCs as it happens in order to clear a
DISCUSS.

Now absent some really clear indication
to the contrary, using ASN.1 OIDs for identifying cryptographic algs
and formats is pretty much a slam dunk. I can't see how anyone could
say that it is not an acceptable way to go for any application layer
design.

I can. It wastes space, it allows flexibility where none is
needed, and encoding either requires a full ASN.1 stack *or* the
namespace needs to be restricted so heavily that a registry is
sufficient. These are two opposing views, and there are probably
others.

Here we do have the other option of using
the DNSSEC hash registry and defining appropriate codes for the hash
algs we want to use. But that is going to produce a format that is
only relevant to DANE and is going to have to be managed as an adjunct
to DNSSEC in perpetuity rather than as a part of application layer
crypto management.

That's not the only option: we can also use the TLS hash
registry,
<http://www.iana.org/assignments/tls-parameters/tls-parameters.xml#tls-parameters-17>, which is already in use by the TLS
stacks. Or we could invent our own registry, which is pretty much what
you are suggesting by your constrained-OIDs proposal in -caa-01. There
are many options.

So my view is that the ASN.1 OIDs are the
way to go in this case, even though I really dislike
ASN.1.

>The ODR construct is:

>   DNSCAA DEFINITIONS ::=

>

>   BEGIN

>

>    ObjectDigestReference ::= SEQUENCE {

>
type             OBJECT IDENTIFIER,

>      digestAlgorithm  OBJECT
IDENTIFIER,

>
digest
OCTET STRING

>    }

>

>   END

>Provided the ODR itself is authentic,

What does "authentic" mean in this context?

Should have been 'authenticated'. There
is no digital signature in the ODR itself, it is only useful if
authenticated (e.g. DNSSEC, TLS, cert signature, etc.).

Got it. Correct.

>it provides a strong cryptographic reference to a
specific string of bits with a specified semantic interpretation using
a specified digest algorithm.

Do you believe that it is a stronger cryptographic
reference than concatenating the three fields (the first two of which
are fixed-length)? If so, why?

Nope.

The only reason for adding the enclosing
SEQUENCE is so that there is an atomic unit that can be slotted into
other ASN.1 contexts (e.g. OCSP response, X.509 cert,
whatever).

What is an example where that would actually be useful? (I can't
tell if I'm being dense or you're being very general.)

>The OID space is extensible, anyone can register code
points. X.509 certs already use this registry so re-use does not
introduce a new registry.

Fully agree. And the free extensibility leads to lack of
interoperability and confusion. Many people consider those to be bad
features.

They are bad within DNSSEC. But
unavoidable at the upper layers. I would prefer not to have to support
PGP and other key formats in this scheme, but they are going to be
unavoidable politically.

That has yet to be determined. No one has given usage examples
for PGP or SPKI yet, and I certainly don't want this WG to get bogged
down in trying to work in possible uses for which there is no actual
need.

This is an infrastructure proposal like
XML Signature. We are going to have folk come along and insist that
they need specific crypto. And some are going to be
right.

Sure, but that has nothing to do with using OIDs. Any extensible
namespace would work equivalently, yes?

In particular, we know that we are not
100% happy with the SHA-2 algorithm and anticipate a shift to SHA3.
But there may also be specific requirements from certain
countries.

Right.

I don't like having to deal with all
that. But what I really, really want to avoid is having application
layer crypto impact DNSSEC.

Fully agree, but that seems like a non sequitur.

In practice, this is self regulating. If
everyone supports SHA2 then everything else is just

>While it is tempting to re-use the DNSSEC code points,
they serve a different purpose in my view. Key assure is application
level crypto and should use an application level identifier registry.
That is either the ascii label registry or the OIDs.

TLS is a protocol used by application-layer clients and
servers. Why not reuse its registries (which are neither ASCII or
OIDs)?

We should not tie a PKI scheme to a
protocol level registry. People are going to want to use keys with
IPSEC and all sorts of other protocols.

That might be out of scope at this point,
but that is not carte-blanch to shoot ourselves in the
foot.

We have only two sets of approved
protocol independent crypto registries. One is the PEM codes and the
other is ASN.1.

We should not consider any
others.

I don't agree with that, but even if I did, why are you ignoring
"we create our own IANA registry"? That seems to have the
same weight as "we use OIDs and constrain them in this particular
way".

>In the future I would like to see algorithm management
for application layer crypto taken over by SAAG or some other group
and managed across the whole application space. I would like DANE to
be in that pool and not an odd appendage to DNSSEC.

If that happens, DANE could certainly be updated.

Yes, I want DANE to be on the
applications update schedule and not tied to DNS, TLS or anything
else.

>The other reason for having a little more overhead
here is that an ODR can be used as a totally generic fingerprint.

It is true that an ODR can be used as a totally generic
fingerprint; so can any binary or ASCII representation.

Only if it has the object identifier and
algorithm identifier codes in.

We fully disagree here. Constrained OIDs are no more magic than
an IANA registry.

At the moment, most 'cryptographic
fingerprints' are MD5 hex dumps or they might be SHA-1 but only the
producer knows what they are or what semantics they relate
to.

>Having the semantic tag in the digest makes it secure
against a semantic substitution attack and enables cut n' paste type
use.

How would such a substitution attack on an ODR or other
blob happen without there being a serious degredation of the preimage
strength of the digest algorithm? You claimed otherwise earlier on the
list but didn't justify your argument, and some of us disagreed with
you.

Guarding against this form of attack is
most certainly best practice.

At the moment the chances are that there
will be no issue because the only formats we are likely to use are in
completely different encoding spaces. SAML is in XML, PKIX is in ASN.1
and PGP in something else again.

I think it highly likely that will
continue to be the case and no issue will arise. But there is no way
any of us can predict how key formats are going to evolve and so there
is no way that either of us can guarantee that no problem will arise
in the context of DANE.

I think it is far more likely that
someone will find a way to exploit a semantic attack in the wild than
they will find an attack on SHA2-256. But that does not mean I would
be happy only supporting one digest algorithm.

In the wider context that ODR is designed
to address, the problem quite definitely arises. So the choice is
between a digest format that is a one off for DANE and cannot be
reused or one that maybe has 6 extra bytes that are not absolutely
necessary in DANE.

So, you still have no attack that does not involve a reduced
preimage on the hash algorithm used?

>If the group wants to go this way, I would suggest
that we unhook the ODR component from the CAA draft and make it a
standards track WG document. It is probably best that it be a separate
document as the whole point is to make it a generic construct like
Base64.

>

>In addition to the binary form, I would add in a URI encoding form
and make the relevant application.

Can you give an example of where the URI encoded form
could be useful?

OK, how about on a web page. Imagine that
we have a web page that is downloaded from a TLS site but the images
are stored on a separate image server that does not have
TLS.

At the moment this is such a common use
case that it is really difficult to get enforcement on because it is
so common. And there is another variation where the data linked to is
not even in the same domain.

Imagine we can create a link of the
form:

<img src="http://images.example.com/1.gif"

odr="odr:woei2oqur02que0o2quefoiqwefouqwefoiu=="/>

Packaging it up as a URI is not strictly
necessary but that is what it is functionally.

One could even have a cache of content
referenced by ODR lookup. So if the content is not locatable, it can
be pulled from cache.

<a href="http://tools.ietf.org/rfc6666.txt

odr="odr:woqi12o3o12hroiqhweoiqhwe==">RFC
6666</a>

I'm sorry, but I'm still completely lost. What do the
certificates in those ODRs do in those examples?

--Paul Hoffman, Director

--VPN Consortium

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E480328C0DF for ; Mon, 13 Dec 2010 10:57:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.292
X-Spam-Level:
X-Spam-Status: No, score=-3.292 tagged_above=-999 required=5 tests=[AWL=0.306, 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 LguFfotZLSQI for ; Mon, 13 Dec 2010 10:57:52 -0800 (PST)
Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by core3.amsl.com (Postfix) with ESMTP id 72A9B28C0E9 for ; Mon, 13 Dec 2010 10:57:52 -0800 (PST)
Received: by gxk8 with SMTP id 8so3256891gxk.27 for ; Mon, 13 Dec 2010 10:59:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=bp5MY7Q6by0b0zwO4ume+oFX4QySB4/h4tAcwaxfCFc=; b=FufW415CCXef/hUAQA1ziOdflySHwc2c6I25x3YdvtyxNJtzD4IHw6/wiAKeMdZc1F xB8oXCfFCXh03RhwnuVu7lLOyeTHgoByNvh5QSj4YtJmUobSe2FYqxcNROFsP8EwQK2A yQSZr0eTCsV0V3P6PDYzpNtOapk0e780Fbesk=
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=kK+kz685SfeG9NcLqy94dUY+Nd1ju4/HNRVjzVFsg97vDYbGO8eGrQgcwFr9M896ua dVv8OtTOA1/DNpIrlEfO9OG2PJULbv/snb5jNfxThazxtRF65YqnVzmCcNHxE+m54S88 RmoSMxkb+HOT9s1AUOOXnqABoY5s7fQxdnEPs=
MIME-Version: 1.0
Received: by 10.100.225.7 with SMTP id x7mr2866609ang.69.1292266768961; Mon, 13 Dec 2010 10:59:28 -0800 (PST)
Received: by 10.100.31.8 with HTTP; Mon, 13 Dec 2010 10:59:28 -0800 (PST)
In-Reply-To:
References:
Date: Mon, 13 Dec 2010 13:59:28 -0500
Message-ID:
From: Phillip Hallam-Baker
To: Paul Hoffman
Content-Type: multipart/alternative; boundary=001636920544b810d004974f4d16
Cc: [email-masked]
Subject: Re: [keyassure] Object Digest Reference
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 13 Dec 2010 18:57:55 -0000

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

On Mon, Dec 13, 2010 at 11:04 AM, Paul Hoffman wrote:

> At 9:57 AM -0500 12/13/10, Phillip Hallam-Baker wrote:
> >While some might argue that the ODR construct guards against attacks that
> may or may not be relevant,
>
> Who is "some" here, and what kind of attacks does "some" claim that an
> ASN.1 sequence guards against that concatenating the three fields themselves
> doesn't

Some folk on this list doubted that a semantic substitution attack was an
issue for the KEYASSURE/CERT proposal.

I am pretty sure that a semantic substitution attack would be a very big
deal if multiple cert/key formats are allowed. In particular, I think we can
end up with a situation where minimal implementations could be attacked if
they have less than full X.509 / SAML / whatever stacks.

> > the overhead is trivial and as far as I can see there is no room to argue
> that it is under-designed.
>
> The size overhead is small, the programming overhead maybe not so much.

A full ASN.1 stack is a PITA, agreed.

The main reason the CAA draft has the explanation it does is to show that a
full ASN.1 packer/depacker is not necessary. Everything can be handled off
fixed pre-calculated prefixes for each supported digest algorithm if that is
desired.

> >I would rather be accused of moderate over-design (ten extra bytes) than
> have to go through WG discussion and then re-litigate the issue with the
> IESG.
>
> Please define "re-litigate". This is a serious matter.

Well, in KeyProv we made a bunch of design decisions that nobody much cared
about very much, just provided that there was a canonical form of password
encoding. Then during last call, we discovered that it was something that
people cared very much was done in the same way that SASL is done and so
ended up changing to reference one of your own RFCs as it happens in order
to clear a DISCUSS.

Now absent some really clear indication to the contrary, using ASN.1 OIDs
for identifying cryptographic algs and formats is pretty much a slam dunk. I
can't see how anyone could say that it is not an acceptable way to go for
any application layer design.

Here we do have the other option of using the DNSSEC hash registry and
defining appropriate codes for the hash algs we want to use. But that is
going to produce a format that is only relevant to DANE and is going to have
to be managed as an adjunct to DNSSEC in perpetuity rather than as a part of
application layer crypto management.

So my view is that the ASN.1 OIDs are the way to go in this case, even
though I really dislike ASN.1.

> >The ODR construct is:
> > DNSCAA DEFINITIONS ::=
> >
> > BEGIN
> >
> > ObjectDigestReference ::= SEQUENCE {
> > type OBJECT IDENTIFIER,
> > digestAlgorithm OBJECT IDENTIFIER,
> > digest OCTET STRING
> > }
> >
> > END
> >Provided the ODR itself is authentic,
>
> What does "authentic" mean in this context?

Should have been 'authenticated'. There is no digital signature in the ODR
itself, it is only useful if authenticated (e.g. DNSSEC, TLS, cert
signature, etc.).

> >it provides a strong cryptographic reference to a specific string of bits
> with a specified semantic interpretation using a specified digest algorithm.
>
> Do you believe that it is a stronger cryptographic reference than
> concatenating the three fields (the first two of which are fixed-length)? If
> so, why?
>

Nope.

The only reason for adding the enclosing SEQUENCE is so that there is an
atomic unit that can be slotted into other ASN.1 contexts (e.g. OCSP
response, X.509 cert, whatever).

>
> >The OID space is extensible, anyone can register code points. X.509 certs
> already use this registry so re-use does not introduce a new registry.
>
> Fully agree. And the free extensibility leads to lack of interoperability
> and confusion. Many people consider those to be bad features.

They are bad within DNSSEC. But unavoidable at the upper layers. I would
prefer not to have to support PGP and other key formats in this scheme, but
they are going to be unavoidable politically.

This is an infrastructure proposal like XML Signature. We are going to have
folk come along and insist that they need specific crypto. And some are
going to be right.

In particular, we know that we are not 100% happy with the SHA-2 algorithm
and anticipate a shift to SHA3. But there may also be specific requirements
from certain countries.

I don't like having to deal with all that. But what I really, really want to
avoid is having application layer crypto impact DNSSEC.

In practice, this is self regulating. If everyone supports SHA2 then
everything else is just

> >While it is tempting to re-use the DNSSEC code points, they serve a
> different purpose in my view. Key assure is application level crypto and
> should use an application level identifier registry. That is either the
> ascii label registry or the OIDs.
>
> TLS is a protocol used by application-layer clients and servers. Why not
> reuse its registries (which are neither ASCII or OIDs)?

We should not tie a PKI scheme to a protocol level registry. People are
going to want to use keys with IPSEC and all sorts of other protocols.

That might be out of scope at this point, but that is not carte-blanch to
shoot ourselves in the foot.

We have only two sets of approved protocol independent crypto registries.
One is the PEM codes and the other is ASN.1.

We should not consider any others.

> >In the future I would like to see algorithm management for application
> layer crypto taken over by SAAG or some other group and managed across the
> whole application space. I would like DANE to be in that pool and not an odd
> appendage to DNSSEC.
>
> If that happens, DANE could certainly be updated.

Yes, I want DANE to be on the applications update schedule and not tied to
DNS, TLS or anything else.

> >The other reason for having a little more overhead here is that an ODR can
> be used as a totally generic fingerprint.
>
> It is true that an ODR can be used as a totally generic fingerprint; so can
> any binary or ASCII representation.

Only if it has the object identifier and algorithm identifier codes in.

At the moment, most 'cryptographic fingerprints' are MD5 hex dumps or they
might be SHA-1 but only the producer knows what they are or what semantics
they relate to.

> >Having the semantic tag in the digest makes it secure against a semantic
> substitution attack and enables cut n' paste type use.
>
> How would such a substitution attack on an ODR or other blob happen without
> there being a serious degredation of the preimage strength of the digest
> algorithm? You claimed otherwise earlier on the list but didn't justify your
> argument, and some of us disagreed with you.

Guarding against this form of attack is most certainly best practice.

At the moment the chances are that there will be no issue because the only
formats we are likely to use are in completely different encoding spaces.
SAML is in XML, PKIX is in ASN.1 and PGP in something else again.

I think it highly likely that will continue to be the case and no issue will
arise. But there is no way any of us can predict how key formats are going
to evolve and so there is no way that either of us can guarantee that no
problem will arise in the context of DANE.

I think it is far more likely that someone will find a way to exploit a
semantic attack in the wild than they will find an attack on SHA2-256. But
that does not mean I would be happy only supporting one digest algorithm.

In the wider context that ODR is designed to address, the problem quite
definitely arises. So the choice is between a digest format that is a one
off for DANE and cannot be reused or one that maybe has 6 extra bytes that
are not absolutely necessary in DANE.

> >If the group wants to go this way, I would suggest that we unhook the ODR
> component from the CAA draft and make it a standards track WG document. It
> is probably best that it be a separate document as the whole point is to
> make it a generic construct like Base64.
> >
> >In addition to the binary form, I would add in a URI encoding form and
> make the relevant application.
>
> Can you give an example of where the URI encoded form could be useful?

OK, how about on a web page. Imagine that we have a web page that is
downloaded from a TLS site but the images are stored on a separate image
server that does not have TLS.

At the moment this is such a common use case that it is really difficult to
get enforcement on because it is so common. And there is another variation
where the data linked to is not even in the same domain.

Imagine we can create a link of the form:

Packaging it up as a URI is not strictly necessary but that is what it is
functionally.

One could even have a cache of content referenced by ODR lookup. So if the
content is not locatable, it can be pulled from cache.

RFC 6666

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

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

On Mon, Dec 13, 2010 at 11:04 AM, Paul H=
offman <paul.=
[email-masked]> wrote:

At 9:57 AM -0500 12/13/10, Phillip Hallam-Baker wrote:
>While some might argue that the ODR construct guards against attacks th=
at may or may not be relevant,

Who is "some" here, and what kind of attacks does "som=
e" claim that an ASN.1 sequence guards against that concatenating the =
three fields themselves doesn't

Some fo=
lk on this list doubted that a semantic substitution attack was an issue fo=
r the KEYASSURE/CERT proposal.

I am pretty sure that a semantic substitution attack wo=
uld be a very big deal if multiple cert/key formats are allowed. In particu=
lar, I think we can end up with a situation where minimal implementations c=
ould be attacked if they have less than full X.509 / SAML / whatever stacks=
.

=A0

> the overhead is trivial and as far as I can see there is no room to ar=
gue that it is under-designed.

The size overhead is small, the programming overhead maybe not so muc=
h.

A full ASN.1 stack is a PITA, agreed.=A0=

The main reason the CAA draft has the explanation=
it does is to show that a full ASN.1 packer/depacker is not necessary. Eve=
rything can be handled off fixed pre-calculated prefixes for each supported=
digest algorithm if that is desired.

=A0

>I would rather be accused of moderate over-design (ten extra bytes) tha=
n have to go through WG discussion and then re-litigate the issue with the =
IESG.

Please define "re-litigate". This is a serious matter.

Well, in KeyProv we made a bunch of design deci=
sions that nobody much cared about very much, just provided that there was =
a canonical form of password encoding. Then during last call, we discovered=
that it was something that people cared very much was done in the same way=
that SASL is done and so ended up changing to reference one of your own RF=
Cs as it happens in order to clear a DISCUSS.

Now absent some really clear indication to the contrary=
, using ASN.1 OIDs for identifying cryptographic algs and formats is pretty=
much a slam dunk. I can't see how anyone could say that it is not an a=
cceptable way to go for any application layer design.

Here we do have the other option of using the DNSSEC ha=
sh registry and defining appropriate codes for the hash algs we want to use=
. But that is going to produce a format that is only relevant to DANE and i=
s going to have to be managed as an adjunct to DNSSEC in perpetuity rather =
than as a part of application layer crypto management.

So my view is that the ASN.1 OIDs are the way to go in =
this case, even though I really dislike ASN.1.

=A0=

>The ODR construct is:

> =A0 DNSCAA DEFINITIONS ::=3D

>

> =A0 BEGIN

>

> =A0 =A0ObjectDigestReference ::=3D SEQUENCE {

> =A0 =A0 =A0type =A0 =A0 =A0 =A0 =A0 =A0 OBJECT IDENTIFIER,

> =A0 =A0 =A0digestAlgorithm =A0OBJECT IDENTIFIER,

> =A0 =A0 =A0digest =A0 =A0 =A0 =A0 =A0 OCTET STRING

> =A0 =A0}

>

> =A0 END

>Provided the ODR itself is authentic,

What does "authentic" mean in this context?

Should have been 'authenticated'. There is no digi=
tal signature in the ODR itself, it is only useful if authenticated (e.g. D=
NSSEC, TLS, cert signature, etc.).

=A0

>it provides a strong cryptographic reference to a specific string of bi=
ts with a specified semantic interpretation using a specified digest algori=
thm.

Do you believe that it is a stronger cryptographic reference than con=
catenating the three fields (the first two of which are fixed-length)? If s=
o, why?

Nope.

The only reason for adding the enclosing SEQUENCE is so that there is =
an atomic unit that can be slotted into other ASN.1 contexts (e.g. OCSP res=
ponse, X.509 cert, whatever).

=A0

>The OID space is extensible, anyone can register code points. X.509 cer=
ts already use this registry so re-use does not introduce a new registry.

Fully agree. And the free extensibility leads to lack of interoperabi=
lity and confusion. Many people consider those to be bad features.

They are bad within DNSSEC. But unavoidable at the =
upper layers. I would prefer not to have to support PGP and other key forma=
ts in this scheme, but they are going to be unavoidable politically.

This is an infrastructure proposal like XML Signature. =
We are going to have folk come along and insist that they need specific cry=
pto. And some are going to be right.

In particular=
, we know that we are not 100% happy with the SHA-2 algorithm and anticipat=
e a shift to SHA3. But there may also be specific requirements from certain=
countries.

I don't like having to deal with all that. But what=
I really, really want to avoid is having application layer crypto impact D=
NSSEC.

In practice, this is self regulating. If ev=
eryone supports SHA2 then everything else is just=A0

=A0

>While it is tempting to re-use the DNSSEC code points, they serve a dif=
ferent purpose in my view. Key assure is application level crypto and shoul=
d use an application level identifier registry. That is either the ascii la=
bel registry or the OIDs.

TLS is a protocol used by application-layer clients and servers. Why =
not reuse its registries (which are neither ASCII or OIDs)?

We should not tie a PKI scheme to a protocol level registr=
y. People are going to want to use keys with IPSEC and all sorts of other p=
rotocols.

That might be out of scope at this point, but that is n=
ot carte-blanch to shoot ourselves in the foot.

We=
have only two sets of approved protocol independent crypto registries. One=
is the PEM codes and the other is ASN.1.=A0

We should not consider any others.

=A0
<=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
#ccc solid;padding-left:1ex;">

>In the future I would like to see algorithm management for application =
layer crypto taken over by SAAG or some other group and managed across the =
whole application space. I would like DANE to be in that pool and not an od=
d appendage to DNSSEC.

If that happens, DANE could certainly be updated.

Yes, I want DANE to be on the applications update schedule and=
not tied to DNS, TLS or anything else.

=A0

>The other reason for having a little more overhead here is that an ODR =
can be used as a totally generic fingerprint.

It is true that an ODR can be used as a totally generic fingerprint; =
so can any binary or ASCII representation.

=
Only if it has the object identifier and algorithm identifier codes in.

At the moment, most 'cryptographic fingerprints'=
; are MD5 hex dumps or they might be SHA-1 but only the producer knows what=
they are or what semantics they relate to.

=A0

>Having the semantic tag in the digest makes it secure against a semanti=
c substitution attack and enables cut n' paste type use.

How would such a substitution attack on an ODR or other blob happen w=
ithout there being a serious degredation of the preimage strength of the di=
gest algorithm? You claimed otherwise earlier on the list but didn't ju=
stify your argument, and some of us disagreed with you.

Guarding against this form of attack is most certainly =
best practice.

At the moment the chances are that =
there will be no issue because the only formats we are likely to use are in=
completely different encoding spaces. SAML is in XML, PKIX is in ASN.1 and=
PGP in something else again.

I think it highly likely that will continue to be the c=
ase and no issue will arise. But there is no way any of us can predict how =
key formats are going to evolve and so there is no way that either of us ca=
n guarantee that no problem will arise in the context of DANE.

I think it is far more likely that someone will find a =
way to exploit a semantic attack in the wild than they will find an attack =
on SHA2-256. But that does not mean I would be happy only supporting one di=
gest algorithm.

In the wider context that ODR is designed to address, t=
he problem quite definitely arises. So the choice is between a digest forma=
t that is a one off for DANE and cannot be reused or one that maybe has 6 e=
xtra bytes that are not absolutely necessary in DANE.

=A0

>If the group wants to go this way, I would suggest that we unhook the O=
DR component from the CAA draft and make it a standards track WG document. =
It is probably best that it be a separate document as the whole point is to=
make it a generic construct like Base64.

>

>In addition to the binary form, I would add in a URI encoding form and =
make the relevant application.

Can you give an example of where the URI encoded form could be useful=
?

OK, how about on a web page. Imagine that=
we have a web page that is downloaded from a TLS site but the images are s=
tored on a separate image server that does not have TLS.

At the moment this is such a common use case that it is=
really difficult to get enforcement on because it is so common. And there =
is another variation where the data linked to is not even in the same domai=
n.

Imagine we can create a link of the form:

<img src=3D"http://images.example.com/1.gif"

=A0=A0 =A0odr=3D"=
odr:woei2oqur02que0o2quefoiqwefouqwefoiu=3D=3D"/>

Packaging it up as a URI is not strictly necessary but =
that is what it is functionally.=A0

One could even=
have a cache of content referenced by ODR lookup. So if the content is not=
locatable, it can be pulled from cache.

<a href=3D"http://tools.ietf.org/rfc6666.txt

=A0=A0 =A0odr=3D&=
quot;odr:woqi12o3o12hroiqhweoiqhwe=3D=3D">RFC 6666</a>
<=
/div>

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

--001636920544b810d004974f4d16--

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9A043A6CB5 for ; Mon, 13 Dec 2010 09:01:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[AWL=0.504, 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 msxxIIDX8sMH for ; Mon, 13 Dec 2010 09:01:45 -0800 (PST)
Received: from homiemail-a62.g.dreamhost.com (mx1.spunky.mail.dreamhost.com [208.97.132.47]) by core3.amsl.com (Postfix) with ESMTP id F38783A6EB8 for ; Mon, 13 Dec 2010 09:01:44 -0800 (PST)
Received: from homiemail-a62.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTP id 39B33634075; Mon, 13 Dec 2010 09:03:23 -0800 (PST)
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=DSuv0zQt+IMJrpjgkscXEjUxllM48h9QvFhlIaKJ3xS ZFhcSfIQjLyOBaZ6ELMGCLqSkBbB02w7tRTfGj/TDM7WlIZZl8BYBd2EpE77q4k/ UQpn+u8HCWM5NceyF5hE9RJiaxaDj8JIRYpgbo/Mt8BRQZm1goWBZqjarAIMwXqU =
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=Ute+K9CAhsr6acjrdu5KxjijY4o=; b=ENoD2LMq1+ LvDwRDVDa6/8FvsthO+5W/T2bMTHc8jOgKjCkkRFLw+ZkGO9ETcoK4HyrCTWUHod UQzLtiCI5WN5L81Esx3TPUzhSyI67dt/tWIf6Tv2xyJF88SzyFyO48+5DSPsB4kb 5yuNBY0OvYB5GrjvPLOfUvxuoTf3i/vl8=
Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: [email-masked]) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTPA id DBFEC634073; Mon, 13 Dec 2010 09:03:22 -0800 (PST)
From: Matt McCutchen
To: Phillip Hallam-Baker
In-Reply-To:
References: <[email-masked]>
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 13 Dec 2010 12:03:21 -0500
Message-ID: <[email-masked]>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.1
Content-Transfer-Encoding: 7bit
Cc: [email-masked]
Subject: Re: [keyassure] OT: Browser certificate acceptance
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 13 Dec 2010 17:01:45 -0000

On Tue, 2010-12-07 at 12:38 -0500, Phillip Hallam-Baker wrote:
> The way that I see it, a browser should accept any certificate
> whatsoever without complaint. But it should only ever indicate to the
> user that they are secure if the certificate demonstrates that there
> is accountability. And it should only indicate that there is an error
> if there was a reason to believe that TLS should have been used.

At the risk of going off topic... I hear that approach advocated a lot,
but it fundamentally breaks the semantics that people and web sites
expect of "https" URLs:

https://bugzilla.mozilla.org/show_bug.cgi?id=327181#c14

Are you prepared to solve this?

--
Matt

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5879328C10F for ; Mon, 13 Dec 2010 08:02:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.511
X-Spam-Level:
X-Spam-Status: No, score=-101.511 tagged_above=-999 required=5 tests=[AWL=0.535, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 XwqoI1AzM1d9 for ; Mon, 13 Dec 2010 08:02:44 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 7002828C10E for ; Mon, 13 Dec 2010 08:02:44 -0800 (PST)
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 oBDG4JW7064428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Dec 2010 09:04:20 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References:
Date: Mon, 13 Dec 2010 08:04:16 -0800
To: Phillip Hallam-Baker , [email-masked]
From: Paul Hoffman
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [keyassure] Object Digest Reference
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 13 Dec 2010 16:02:45 -0000

At 9:57 AM -0500 12/13/10, Phillip Hallam-Baker wrote:
>While some might argue that the ODR construct guards against attacks that may or may not be relevant,

Who is "some" here, and what kind of attacks does "some" claim that an ASN.1 sequence guards against that concatenating the three fields themselves doesn't?

> the overhead is trivial and as far as I can see there is no room to argue that it is under-designed.

The size overhead is small, the programming overhead maybe not so much.

>I would rather be accused of moderate over-design (ten extra bytes) than have to go through WG discussion and then re-litigate the issue with the IESG.

Please define "re-litigate". This is a serious matter.

>The ODR construct is:
> DNSCAA DEFINITIONS ::=
>
> BEGIN
>
> ObjectDigestReference ::= SEQUENCE {
> type OBJECT IDENTIFIER,
> digestAlgorithm OBJECT IDENTIFIER,
> digest OCTET STRING
> }
>
> END
>Provided the ODR itself is authentic,

What does "authentic" mean in this context?

>it provides a strong cryptographic reference to a specific string of bits with a specified semantic interpretation using a specified digest algorithm.

Do you believe that it is a stronger cryptographic reference than concatenating the three fields (the first two of which are fixed-length)? If so, why?

>The OID space is extensible, anyone can register code points. X.509 certs already use this registry so re-use does not introduce a new registry.

Fully agree. And the free extensibility leads to lack of interoperability and confusion. Many people consider those to be bad features.

>While it is tempting to re-use the DNSSEC code points, they serve a different purpose in my view. Key assure is application level crypto and should use an application level identifier registry. That is either the ascii label registry or the OIDs.

TLS is a protocol used by application-layer clients and servers. Why not reuse its registries (which are neither ASCII or OIDs)?

>In the future I would like to see algorithm management for application layer crypto taken over by SAAG or some other group and managed across the whole application space. I would like DANE to be in that pool and not an odd appendage to DNSSEC.

If that happens, DANE could certainly be updated.

>The other reason for having a little more overhead here is that an ODR can be used as a totally generic fingerprint.

It is true that an ODR can be used as a totally generic fingerprint; so can any binary or ASCII representation.

>It is something that we can perhaps expect a cryptographic application to emit as a matter of course. I would like to be able to cut and paste ODRs from one place to another.

That sounds good.

>Having the semantic tag in the digest makes it secure against a semantic substitution attack and enables cut n' paste type use.

How would such a substitution attack on an ODR or other blob happen without there being a serious degredation of the preimage strength of the digest algorithm? You claimed otherwise earlier on the list but didn't justify your argument, and some of us disagreed with you.

>If the group wants to go this way, I would suggest that we unhook the ODR component from the CAA draft and make it a standards track WG document. It is probably best that it be a separate document as the whole point is to make it a generic construct like Base64.
>
>In addition to the binary form, I would add in a URI encoding form and make the relevant application.

Can you give an example of where the URI encoded form could be useful?

--Paul Hoffman, Director
--VPN Consortium

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5D8F3A6EAE for ; Mon, 13 Dec 2010 06:55:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.286
X-Spam-Level:
X-Spam-Status: No, score=-3.286 tagged_above=-999 required=5 tests=[AWL=0.312, 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 FXl+8MD0n22S for ; Mon, 13 Dec 2010 06:55:31 -0800 (PST)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 5E0323A6EA8 for ; Mon, 13 Dec 2010 06:55:31 -0800 (PST)
Received: by gyd12 with SMTP id 12so3361963gyd.31 for ; Mon, 13 Dec 2010 06:57:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=/wdEDYdLnJlPUIQwhUZVKMPVbZ4N8GVF6eywuormIZI=; b=FKX5mK+c5BppSwVo0sMzPVOjNgZQIZHw5BorpUMDhKLadr5EI3PjSIJiJQ8qP8h60f 9AFqpII84O6h2Km+JGBmlyzL1qN3Dy0RvmY3MJnRssI3FiIML6E208v73LHGfyS4dES8 9qzrBGSFxof+mvs2c/rcz0leVsE1yj4KnwZ/k=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=lJXk9+aqG5XNCNh44Yk58u3gm+Epm1z86dJrzM5/7WA14sNPkpbc0PhbXEWUekFwtm eeD5pwRtwoDoHTWmrAVXSSk/SNXweLzVEPhWpzb2VYWrVKlhPlK72V5YchpfENmbgYk8 hi1IODqbvhcY4UiyW584fuY7s3oK+P7h4R3w0=
MIME-Version: 1.0
Received: by 10.101.67.16 with SMTP id u16mr2701120ank.1.1292252227340; Mon, 13 Dec 2010 06:57:07 -0800 (PST)
Received: by 10.100.31.8 with HTTP; Mon, 13 Dec 2010 06:57:07 -0800 (PST)
Date: Mon, 13 Dec 2010 09:57:07 -0500
Message-ID:
From: Phillip Hallam-Baker
To: [email-masked]
Content-Type: multipart/alternative; boundary=00163662e65bf88a4104974beaf1
Subject: [keyassure] Object Digest Reference
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 13 Dec 2010 14:55:32 -0000

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

One of the components introduced in CAA-01 is the Object Digest Identifier.
Which people seem to be more comfortable renaming Object Digest Reference to
avoid confusion with OIDs.

I think it would be a good idea to use the ODR construct to identify
certificates in DANE.

While some might argue that the ODR construct guards against attacks that
may or may not be relevant, the overhead is trivial and as far as I can see
there is no room to argue that it is under-designed.

I would rather be accused of moderate over-design (ten extra bytes) than
have to go through WG discussion and then re-litigate the issue with the
IESG.

The ODR construct is:

DNSCAA DEFINITIONS ::=

BEGIN

ObjectDigestReference ::= SEQUENCE {
type OBJECT IDENTIFIER,
digestAlgorithm OBJECT IDENTIFIER,
digest OCTET STRING
}

END

Provided the ODR itself is authentic, it provides a strong cryptographic
reference to a specific string of bits with a specified semantic
interpretation using a specified digest algorithm.

The OID space is extensible, anyone can register code points. X.509 certs
already use this registry so re-use does not introduce a new registry.

While it is tempting to re-use the DNSSEC code points, they serve a
different purpose in my view. Key assure is application level crypto and
should use an application level identifier registry. That is either the
ascii label registry or the OIDs.

In the future I would like to see algorithm management for application layer
crypto taken over by SAAG or some other group and managed across the whole
application space. I would like DANE to be in that pool and not an odd
appendage to DNSSEC.

The other reason for having a little more overhead here is that an ODR can
be used as a totally generic fingerprint. It is something that we can
perhaps expect a cryptographic application to emit as a matter of course. I
would like to be able to cut and paste ODRs from one place to another.

Having the semantic tag in the digest makes it secure against a semantic
substitution attack and enables cut n' paste type use.

If the group wants to go this way, I would suggest that we unhook the ODR
component from the CAA draft and make it a standards track WG document. It
is probably best that it be a separate document as the whole point is to
make it a generic construct like Base64.

In addition to the binary form, I would add in a URI encoding form and make
the relevant application.

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

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

One of the components introduced in CAA-01 is the Object Digest Identifier.=
Which people seem to be more comfortable renaming Object Digest Reference =
to avoid confusion with OIDs.

I think it would be a good=
idea to use the ODR construct to identify certificates in DANE.

While some might argue that the ODR construct guards ag=
ainst attacks that may or may not be relevant, the overhead is trivial and =
as far as I can see there is no room to argue that it is under-designed.

I would rather be accused of moderate over-design (ten =
extra bytes) than have to go through WG discussion and then re-litigate the=
issue with the IESG.

The ODR const=
ruct is:

DNSCAA DEFINITIONS ::=3D

BEGIN

ObjectDigestReference ::=3D SEQUENCE {
type OBJECT IDENTIFIER,
digestAlgorithm OBJECT IDENTIFIER,
digest OCTET STRING
}

END

Provided the ODR itself is authentic, it prov=
ides a strong cryptographic reference to a specific string of bits with a s=
pecified semantic interpretation using a specified digest algorithm.

The OID space is extensible, anyone can register code p=
oints. X.509 certs already use this registry so re-use does not introduce a=
new registry.

While it is tempting to re-use the =
DNSSEC code points, they serve a different purpose in my view. Key assure i=
s application level crypto and should use an application level identifier r=
egistry. That is either the ascii label registry or the OIDs.

In the future I would like to see algorithm management =
for application layer crypto taken over by SAAG or some other group and man=
aged across the whole application space. I would like DANE to be in that po=
ol and not an odd appendage to DNSSEC.=A0

The other reason for having a little mor=
e overhead here is that an ODR can be used as a totally generic fingerprint=
. It is something that we can perhaps expect a cryptographic application to=
emit as a matter of course. I would like to be able to cut and paste ODRs =
from one place to another.=A0

Having the semantic tag in the digest makes it secure a=
gainst a semantic substitution attack and enables cut n' paste type use=
.

If the group wants to go this way=
, I would suggest that we unhook the ODR component from the CAA draft and m=
ake it a standards track WG document. It is probably best that it be a sepa=
rate document as the whole point is to make it a generic construct like Bas=
e64.

In addition to the binary form, I would add in a URI en=
coding form and make the relevant application.

=

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

--00163662e65bf88a4104974beaf1--

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 566D73A6DDC for ; Sun, 12 Dec 2010 07:47:49 -0800 (PST)
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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1s4qjICSf09 for ; Sun, 12 Dec 2010 07:47:48 -0800 (PST)
Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id 48E613A6CAA for ; Sun, 12 Dec 2010 07:47:45 -0800 (PST)
Received: from [192.168.0.221] (unknown [64.13.52.115]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id 4B70822849A0; Sun, 12 Dec 2010 10:46:19 -0500 (EST)
From: Warren Kumari
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Sun, 12 Dec 2010 10:53:32 -0500
Message-Id: <[email-masked]>
To: [email-masked]
Mime-Version: 1.0 (Apple Message framework v1081)
X-Mailer: Apple Mail (2.1081)
Subject: [keyassure] Tools, etc.
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Sun, 12 Dec 2010 15:47:49 -0000

Thanks to all the hard working folk who setup and run the IETF tools, we =
now have a bunch of resources available to us
Most folk already know about them, but for those new to the game (and as =
a reminder / for easy clicking), here is a summary:

A WG status page has just been created for your new working group, at
this URL: http://tools.ietf.org/wg/dane . It will be automatically
updated to show the status of the working group drafts, and will also
mention active related drafts if they contain the string '-dane-' in the
draft name.

Additionally, a Trac environment containing Wiki, Issue Tracker and
other project management tools have been set up for the WG. There are
links to the wiki and issue tracker on the WG's document status page;
you can also reach the Trac environment directly at this URL:
http://tools.ietf.org/wg/dane/trac .=20

Associated with the Trac instance there's also an SVN repository for =
your
working group. It does not require that you use Trac, but the =
repository
commit will be browsable through Trac anyway. The URL for your SVN
repository is http://svn.tools.ietf.org/svn/wg/dane . Repository =
commits
require login, while checkout can be done anonymously.

More details about the IETF-specific features of the Wiki and Issue =
Tracker
is available at =
http://tools.ietf.org/wg/dane/trac/wiki/IetfSpecificFeatures.
If you have any questions, or there is something which doesn't work as
expected, please contact [email-masked].

Thanks again to Henrik and the rest of the tools folk.

W=

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 073C83A6D4D for ; Sat, 11 Dec 2010 14:38:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.543
X-Spam-Level:
X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 BqDjivocsV+F for ; Sat, 11 Dec 2010 14:38:53 -0800 (PST)
Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id 39AD13A6CCB for ; Sat, 11 Dec 2010 14:38:53 -0800 (PST)
Received: from [192.168.0.221] (unknown [64.13.52.115]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id 2707DDEE30E; Sat, 11 Dec 2010 17:37:27 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Warren Kumari
In-Reply-To:
Date: Sat, 11 Dec 2010 17:44:35 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <[email-masked]>
References: <[email-masked]> <[email-masked]>
To: Paul Hoffman
X-Mailer: Apple Mail (2.1081)
Cc: [email-masked]
Subject: Re: [keyassure] Fwd: WG Action: DNS-based Authentication of Named Entities (dane)
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Sat, 11 Dec 2010 22:38:55 -0000

On Dec 11, 2010, at 5:26 PM, Paul Hoffman wrote:

> At 5:15 PM -0500 12/11/10, Warren Kumari wrote:
>> So, as mentioned in an earlier mail, we are planning on hitting the =
round running -- as mentioned in a previous mail, Ondrej and myself have =
already asked Paul Hoffman and Jakob if they would be willing to author =
-00 of the protocol document (starting with the ideas from the three =
documents listed in the charter, augmented by the wide discussion that =
has happened since we submitted the charter) and they have graciously =
agreed to do so.
>=20
> Jakob and I are working on that right now. We expect the -00 to be out =
soon, and are happy to revise it often as the WG makes changes.

Awesome -- glad to hear that the two you are already making progress, =
and, as we have had such an active mailing list Ondrej and myself are =
expecting that you are already incorporating much of the WG's thoughts =
on this.

>=20
>> We have also asked Matt Lepinski to please serve =
as WG Secretary and would like to thank him for taking on this role...
>=20
> This is good news. Matt can run the open issues list so that the =
document authors don't have to. :-)
> Seriously, having an open issues list run by someone other than the =
authors has helped other WGs a lot. We'll toss in a short list of open =
issues in the -00, but once Matt starts the official one, we can take it =
out of the draft.

Excellent.

W

>=20
> --Paul Hoffman, Director
> --VPN Consortium

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AB533A6CCB for ; Sat, 11 Dec 2010 14:25:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.506
X-Spam-Level:
X-Spam-Status: No, score=-101.506 tagged_above=-999 required=5 tests=[AWL=0.540, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 DQAL4m30PWwa for ; Sat, 11 Dec 2010 14:25:28 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 21C433A6BB3 for ; Sat, 11 Dec 2010 14:25:26 -0800 (PST)
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 oBBMQwEJ065162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Dec 2010 15:27:00 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Date: Sat, 11 Dec 2010 14:26:57 -0800
To: Warren Kumari , Ondrej Sury
From: Paul Hoffman
Content-Type: text/plain; charset="us-ascii"
Cc: [email-masked]
Subject: Re: [keyassure] Fwd: WG Action: DNS-based Authentication of Named Entities (dane)
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Sat, 11 Dec 2010 22:25:30 -0000

At 5:15 PM -0500 12/11/10, Warren Kumari wrote:
>So, as mentioned in an earlier mail, we are planning on hitting the round running -- as mentioned in a previous mail, Ondrej and myself have already asked Paul Hoffman and Jakob if they would be willing to author -00 of the protocol document (starting with the ideas from the three documents listed in the charter, augmented by the wide discussion that has happened since we submitted the charter) and they have graciously agreed to do so.

Jakob and I are working on that right now. We expect the -00 to be out soon, and are happy to revise it often as the WG makes changes.

>We have also asked Matt Lepinski to please serve as WG Secretary and would like to thank him for taking on this role...

This is good news. Matt can run the open issues list so that the document authors don't have to. :-) Seriously, having an open issues list run by someone other than the authors has helped other WGs a lot. We'll toss in a short list of open issues in the -00, but once Matt starts the official one, we can take it out of the draft.

--Paul Hoffman, Director
--VPN Consortium

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAFEA3A6D4A for ; Sat, 11 Dec 2010 14:09:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.535
X-Spam-Level:
X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 CYNvzb6vvanX for ; Sat, 11 Dec 2010 14:09:32 -0800 (PST)
Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id 305DA3A6CC1 for ; Sat, 11 Dec 2010 14:09:29 -0800 (PST)
Received: from [192.168.0.221] (unknown [64.13.52.115]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id 41EC0DEE30E; Sat, 11 Dec 2010 17:08:02 -0500 (EST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Apple Message framework v1081)
From: Warren Kumari
Date: Sat, 11 Dec 2010 17:15:10 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <[email-masked]>
References: <[email-masked]>
To: [email-masked]
X-Mailer: Apple Mail (2.1081)
Subject: [keyassure] Fwd: WG Action: DNS-based Authentication of Named Entities (dane)
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Sat, 11 Dec 2010 22:09:33 -0000

Hello everyone...

Well, it is official, we are formally a Working Group -- I'd like to =
start of by thanking everyone for all of their input and help getting =
this formed, hammering out the charter, etc.

So, as mentioned in an earlier mail, we are planning on hitting the =
round running -- as mentioned in a previous mail, Ondrej and myself have =
already asked Paul Hoffman and Jakob if they would be willing to author =
=E2=88=9200 of the protocol document (starting with the ideas from the =
three documents listed in the charter, augmented by the wide discussion =
that has happened since we submitted the charter) and they have =
graciously agreed to do so.

We have also asked Matt Lepinski to please serve as =
WG Secretary and would like to thank him for taking on this role...

Once again, thanks all -- but this is just the beginning and we're =
(eagerly) expecting a bunch more work from y'all :-)

W

(A quick note on the name: Unfortunately KIDNS was viewed as too close =
to KITTEN -- I really wanted PUPPY, but we couldn't come up with a good =
(reverse) acronym, and DONKEY was ruled out -- so, we have settled on =
(great) DANE. Please note that the charter specifies what we work on, =
not the name....).

Begin forwarded message:

> From: IESG Secretary
> Date: December 10, 2010 1:17:05 PM EST
> To: IETF Announcement list
> Cc: [email-masked], [email-masked], [email-masked]
> Subject: WG Action: DNS-based Authentication of Named Entities (dane)=20=

>=20
> A new IETF working group has been formed in the Security Area. =20
> For additional information, please contact the Area Directors or the =
WG
> Chairs.
>=20
> DNS-based Authentication of Named Entities (dane)
> ---------------------------------------------------
> Current Status: Active Working Group
>=20
> Chairs:
> Warren Kumari
> Ondrej Sury
>=20
> WG Secretary:
> Matt Lepinski
>=20
> Security Area Directors:
> Sean Turner
> Tim Polk
>=20
> Security Area Advisor:
> Tim Polk
>=20
> Mailing Lists:
> General Discussion: [email-masked]
> To Subscribe: https://www.ietf.org/mailman/listinfo/keyassure
> Archive:
> http://www.ietf.org/mail-archive/web/keyassure/current/maillist.html
>=20
> Description of Working Group:
>=20
> Objective:
>=20
> Specify mechanisms and techniques that allow Internet applications to
> establish cryptographically secured communications by using =
information
> distributed through DNSSEC for discovering and authenticating public=20=

> keys which are associated with a service located at a domain name.
>=20
> Problem Statement:
>=20
> Entities on the Internet are usually identified using domain names and
> forming a cryptographically secured connection to the entity requires
> the entity to authenticate its name. For instance, in HTTPS, a server
> responding to a query for is expected to
> authenticate as "www.example.com". Security protocols such as TLS and
> IPsec accomplish this authentication by allowing an endpoint to prove
> ownership of a private key whose corresponding public key is somehow
> bound to the name being authenticated. As a pre-requisite for
> authentication, then, these protocols require a mechanism for bindings
> to be asserted between public keys and domain names.
>=20
> DNSSEC provides a mechanism for a zone operator to sign DNS
> information directly, using keys that are bound to the domain by the
> parent domain; relying parties can continue this chain up to any trust
> anchor that they accept. In this way, bindings of keys to domains are
> asserted not by external entities, but by the entities that operate =
the
> DNS. In addition, this technique inherently limits the scope of any
> given entity to the names in zones he controls.
>=20
> This working group will develop mechanisms for zone operators to
> present bindings between names within their control and public keys, =
in
> such a way that these bindings can be integrity-protected (and thus
> shown to be authentically from the zone operator) using DNSSEC and
> used as a basis for authentication in protocols that use domain names =
as
> identifiers. Possible starting points for these deliverables include
> draft-hallambaker-certhash, draft-hoffman-keys-linkage-from-dns, and
> draft-josefsson-keyassure-tls.
>=20
> The mechanisms developed by this group will address bindings between
> domain names and keys, allowing flexibility for all key-transport
> mechanisms supported by the application protocols addressed (e.g., =
both
> self-signed and CA-issued certificates for use in TLS).
>=20
> The solutions specified by this working group rely upon the security =
of
> the DNS to provide source authentication for public keys. The decision
> whether the chain of trust provided by DNSSEC is sufficient to trust =
the
> key, or whether additional mechanisms are required to determine the
> acceptability of a key, is left to the entity that uses the key=20
> material. In addition to the protections afforded by DNSSEC, the=20
> protocols and mechanisms designed by this working group require =
securing=20
> the "last hop" by operating a local DNS resolver or securing the=20
> connection to remote resolver - this WG will not specify new =
mechanisms=20
> to secure that hop, but will reference existing specifications or=20
> document existing methods in order to allow implementations to=20
> interoperate securely.
>=20
> Initial deliverables for this working group are limited to =
distribution=20
> of bindings between names within the zone operator's control and =
public=20
> keys. More general statements of policy for a domain are out of =
scope,=20
> and new tasks in this area may only be adopted through a =
re-chartering.
>=20
> The group may also create documents that describe how protocol =
entities
> can discover and validate these bindings in the execution of specific
> applications. This work would be done in coordination with the IETF
> Working Groups responsible for the protocols.
>=20
> Goals and Milestones:
>=20
> Apr 2011 First WG draft of standards-track protocol for using DNS to=20=

> associate hosts with keys for TLS and DTLS
> May 2011 First WG draft of standards-track protocols for using DNS to=20=

> associate hosts with IPsec
> Sep 2011 Protocol for using DNS to associate domain names with keys =
for=20
> TLS and DTLS to IESG
> Sep 2011 Protocols for using DNS to associate domain names with keys=20=

> for IPsec to IESG
> Nov 2011 Recharter
>=20

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CDD03A6D31 for ; Sat, 11 Dec 2010 08:05:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.337
X-Spam-Level:
X-Spam-Status: No, score=-3.337 tagged_above=-999 required=5 tests=[AWL=0.261, 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 lWDbWdLEz3T4 for ; Sat, 11 Dec 2010 08:05:16 -0800 (PST)
Received: from mail-gw0-f42.google.com (mail-gw0-f42.google.com [74.125.83.42]) by core3.amsl.com (Postfix) with ESMTP id 3A6AA3A6B02 for ; Sat, 11 Dec 2010 08:05:16 -0800 (PST)
Received: by gwb20 with SMTP id 20so4220771gwb.15 for ; Sat, 11 Dec 2010 08:06:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=Itnb9Iiady0XXBCnMoTVulW2TrUpx08s7S97/joyfUQ=; b=Umxg2blfiMKeYqR+PWuaz0Kw4Awv4r7JYvSBjC1tLXT2Mzu3gTHtpmEcudNXOq5MW2 99i6SNY1LXFJG1HQ6k6mpUvlShWEsFZPhD1wk8md5QW7CXsaG3/QEjOJn08ArlrHS30r RwxAROnJvZGm9e8UbYDOS8YZh/H2leb6ahBSg=
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=GVkMTvvz+JRnASYvkJwAOZSLOcFLdsNZR3f63Sv59HX59/vHUBuqFxchKU4XWFNCqo k/HOmt0DkpOajr+sJuYZVD+tZxUHVmR0Of06tSYRqE6yIqkafn9EkRNPv6owoRw7nYnV r5gsb7ckkvCOBOQCxvimejt7e4ywYhphbWhoE=
MIME-Version: 1.0
Received: by 10.100.195.2 with SMTP id s2mr1353814anf.35.1292083609029; Sat, 11 Dec 2010 08:06:49 -0800 (PST)
Received: by 10.101.103.14 with HTTP; Sat, 11 Dec 2010 08:06:48 -0800 (PST)
In-Reply-To:
References: <[email-masked]> <[email-masked]> <[email-masked]>
Date: Sat, 11 Dec 2010 11:06:48 -0500
Message-ID:
From: Phillip Hallam-Baker
To: Jay Daley
Content-Type: multipart/alternative; boundary=0016e644ba16894cf7049724a8dd
Cc: [email-masked]
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Sat, 11 Dec 2010 16:05:17 -0000

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

On Thu, Dec 9, 2010 at 6:25 PM, Jay Daley wrote:

>
> Which is a /policy/ statement and it is having /policy/ like this in the
> DNS that I am objecting to.

Security policy is the alpha and omega of DNSSEC. The only application that
can possibly justify the costs of DNSSEC is security policy.

I see no value in specification by reference for values that are typically
16 bytes per entry or less. If there is such a requirement it is easy enough
to add additional entries.

CAA is only designed to describe security policy at domain level
granularity. If greater detail is required it will be necessary to use
prefix records and those will in turn require a separate RR code. Due to the
design of DNS wildcards and aliasing, it is not possible to get the results
one would desire using the asme record for both domain level statements and
those at finer granularity.

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

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

On Thu, Dec 9, 2010 at 6:25 PM, Jay Daley <[email-masked]> wrote:

Which is a /policy/ statement and it is having =
/policy/ like this in the DNS that I am objecting to.

=

Security policy is the alpha and omega of DNSSEC. The only appli=
cation that can possibly justify the costs of DNSSEC is security policy.=A0=

I see no value i=
n specification by reference for values that are typically 16 bytes per ent=
ry or less. If there is such a requirement it is easy enough to add additio=
nal entries.

CAA is only designed to describe securit=
y policy at domain level granularity. If greater detail is required it will=
be necessary to use prefix records and those will in turn require a separa=
te RR code. Due to the design of DNS wildcards and aliasing, it is not poss=
ible to get the results one would desire using the asme record for both dom=
ain level statements and those at finer granularity.

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

--0016e644ba16894cf7049724a8dd--

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: by core3.amsl.com (Postfix, from userid 30) id EC6933A6CBA; Fri, 10 Dec 2010 10:17:05 -0800 (PST)
From: IESG Secretary
To: IETF Announcement list
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0
Message-Id: <[email-masked]>
Date: Fri, 10 Dec 2010 10:17:05 -0800 (PST)
Cc: [email-masked]
Subject: [keyassure] WG Action: DNS-based Authentication of Named Entities (dane)
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 10 Dec 2010 18:17:06 -0000

A new IETF working group has been formed in the Security Area.
For additional information, please contact the Area Directors or the WG
Chairs.

DNS-based Authentication of Named Entities (dane)
---------------------------------------------------
Current Status: Active Working Group

Chairs:
Warren Kumari
Ondrej Sury

WG Secretary:
Matt Lepinski

Security Area Directors:
Sean Turner
Tim Polk

Security Area Advisor:
Tim Polk

Mailing Lists:
General Discussion: [email-masked]
To Subscribe: https://www.ietf.org/mailman/listinfo/keyassure
Archive:
http://www.ietf.org/mail-archive/web/keyassure/current/maillist.html

Description of Working Group:

Objective:

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.

Problem Statement:

Entities on the Internet are usually identified using domain names and
forming a cryptographically secured connection to the entity requires
the entity to authenticate its name. For instance, in HTTPS, a server
responding to a query for is expected to
authenticate as "www.example.com". Security protocols such as TLS and
IPsec accomplish this authentication by allowing an endpoint to prove
ownership of a private key whose corresponding public key is somehow
bound to the name being authenticated. As a pre-requisite for
authentication, then, these protocols require a mechanism for bindings
to be asserted between public keys and domain names.

DNSSEC provides a mechanism for a zone operator to sign DNS
information directly, using keys that are bound to the domain by the
parent domain; relying parties can continue this chain up to any trust
anchor that they accept. In this way, bindings of keys to domains are
asserted not by external entities, but by the entities that operate the
DNS. In addition, this technique inherently limits the scope of any
given entity to the names in zones he controls.

This working group will develop mechanisms for zone operators to
present bindings between names within their control and public keys, in
such a way that these bindings can be integrity-protected (and thus
shown to be authentically from the zone operator) using DNSSEC and
used as a basis for authentication in protocols that use domain names as
identifiers. Possible starting points for these deliverables include
draft-hallambaker-certhash, draft-hoffman-keys-linkage-from-dns, and
draft-josefsson-keyassure-tls.

The mechanisms developed by this group will address bindings between
domain names and keys, allowing flexibility for all key-transport
mechanisms supported by the application protocols addressed (e.g., both
self-signed and CA-issued certificates for use in TLS).

The solutions specified by this working group rely upon the security of
the DNS to provide source authentication for public keys. The decision
whether the chain of trust provided by DNSSEC is sufficient to trust the
key, or whether additional mechanisms are required to determine the
acceptability of a key, is left to the entity that uses the key
material. In addition to the protections afforded by DNSSEC, the
protocols and mechanisms designed by this working group require securing
the "last hop" by operating a local DNS resolver or securing the
connection to remote resolver - this WG will not specify new mechanisms
to secure that hop, but will reference existing specifications or
document existing methods in order to allow implementations to
interoperate securely.

Initial deliverables for this working group are limited to distribution
of bindings between names within the zone operator's control and public
keys. More general statements of policy for a domain are out of scope,
and new tasks in this area may only be adopted through a re-chartering.

The group may also create documents that describe how protocol entities
can discover and validate these bindings in the execution of specific
applications. This work would be done in coordination with the IETF
Working Groups responsible for the protocols.

Goals and Milestones:

Apr 2011 First WG draft of standards-track protocol for using DNS to
associate hosts with keys for TLS and DTLS
May 2011 First WG draft of standards-track protocols for using DNS to
associate hosts with IPsec
Sep 2011 Protocol for using DNS to associate domain names with keys for
TLS and DTLS to IESG
Sep 2011 Protocols for using DNS to associate domain names with keys
for IPsec to IESG
Nov 2011 Recharter

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6049C28C118 for ; Thu, 9 Dec 2010 15:24:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vx+xhIwrVOFJ for ; Thu, 9 Dec 2010 15:24:32 -0800 (PST)
Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id 6482028C102 for ; Thu, 9 Dec 2010 15:24:30 -0800 (PST)
Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id EB77D2CE004 for ; Fri, 10 Dec 2010 12:26:02 +1300 (NZDT)
Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IiWHLSIKNpr3 for ; Fri, 10 Dec 2010 12:26:02 +1300 (NZDT)
Received: from [192.168.0.216] (cl-col-200-30-70-226.orbitel.net.co [200.30.70.226]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 8DB532DB578 for ; Fri, 10 Dec 2010 12:26:01 +1300 (NZDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1082)
From: Jay Daley
In-Reply-To:
Date: Thu, 9 Dec 2010 18:25:52 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id:
References: <[email-masked]> <[email-masked]> <[email-masked]>
To: [email-masked]
X-Mailer: Apple Mail (2.1082)
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 09 Dec 2010 23:24:36 -0000

On 9/12/2010, at 5:59 PM, Phillip Hallam-Baker wrote:

> It appears that you are assuming that the purpose of this document is
> something completely different to what is described in the document.
> That is not the case so I do not believe that your comments are
> relevant to the proposal made.

Reading that inconjunction with the comments below appears to indicate =
you are ruling out all of my comments on the basis that you disagree =
with my assessment in one area only - the number of CAA records that =
might be published under a single domain.

To remind you, the other areas discussed but still outstanding are:

- the 'null' case - (no certificate can be issued at this domain)
- the algorithm for searching up the tree, with particular reference to =
an empty domain and a parent with a null case
- the general principle of putting policy into the DNS

> The CAA record is intended to express the semantics 'only Comodo is
> authorized to issue certs for this zone' or equivalent for other
> issuers.

Which is a /policy/ statement and it is having /policy/ like this in the =
DNS that I am objecting to.

> I think it rather unlikely that there would be more than two
> or three CAs issuing for one domain.
>=20
> If that does turn out to be an actual use case we can always define
> additional property entries.

Which rather proves my point that this RR as specified could change more =
than a simple redirection pointer.

Jay

>=20
>=20
>=20
> On Thu, Dec 9, 2010 at 3:33 PM, Jay Daley wrote:
>> On 9/12/2010, at 2:44 PM, Phillip Hallam-Baker wrote:
>>=20
>>>> My point was that we do not need to store the policy that an issuer =
or a UA should use (i.e. the Authorisation Entries) in DNS but solely a =
pointer to where it is found. I was not talking about the CP.
>>>=20
>>> The Authorization Entries consist of a flag byte, a tag and an ASN.1
>>> OID, typically 10 bytes long.
>>>=20
>>> This is very clearly explained in the document.
>>>=20
>>> A URI reference would be considerably longer, be less stable, be
>>> different to the existing practice in X.509 and offer no benefit =
that
>>> I can see.
>>=20
>> That again is an orthogonal answer, not answering the point I am =
making. Just to reiterate, my point is two fold:
>>=20
>> 1. The format of a CAA record as specified is likely to change far =
more often that one which is just a pointer.
>>=20
>> 2. The issue of a single CAA record with the current format is not =
an issue, the potential number of them is unbounded. To be quite clear, =
my objection is to putting policy about an external system into DNS. I =
do not think that is what the DNS is for.
>>=20
>>>> Assuming you were talking about that, then I don't agree with the =
need for a hash - we don't provide the hash of the web page pointed to =
by an _http._tcp SRV record. DNSSEC secures the pointer, secure BGP =
secures the route to the IP address and the policy protocol secures the =
transfer of the policy.
>>>=20
>>> Secure BGP is a proposal and not an infrastructure. And attempting =
to
>>> achieve anything more than preventing Denial of Service in a routing
>>> layer solution is probably a mistake.
>>=20
>> That is not relevant. The point was about the RR specifying the =
policy it expects to find when it connects to a policy server. Nobody =
seems to need that for any other service pointed to by DNS.
>>=20
>> Jay
>>=20
>> --
>> Jay Daley
>> Chief Executive
>> .nz Registry Services (New Zealand Domain Name Registry Limited)
>> desk: +64 4 931 6977
>> mobile: +64 21 678840
>>=20
>> _______________________________________________
>> keyassure mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/keyassure
>>=20
>=20
>=20
>=20
> --=20
> Website: http://hallambaker.com/

--=20
Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 678840

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D991A28C144 for ; Thu, 9 Dec 2010 14:58:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.282
X-Spam-Level:
X-Spam-Status: No, score=-3.282 tagged_above=-999 required=5 tests=[AWL=0.317, 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 ifRDTdRRxXR2 for ; Thu, 9 Dec 2010 14:58:17 -0800 (PST)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id AA2D728C118 for ; Thu, 9 Dec 2010 14:58:17 -0800 (PST)
Received: by yxt33 with SMTP id 33so1855660yxt.31 for ; Thu, 09 Dec 2010 14:59:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=xY15pXQlB9mTeyNFH0L+szdGIZ39DFRLeeRffJoL//g=; b=vaIYp1P4A89AkbTRNyFoaDaW8gWkJI0Xop+G6skYRCfpQzWm+bD0JsNwEmvoHMr18X D2iscBK266KYRg0u2iPWhyva2R0R5fW97Ycm15eeN1RVgmVkg8VxeE6qOfVQ1xS0tgOD WteiRYwsLPH9x8G+Q+tCuCup2Xco/hiih+E5I=
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:content-transfer-encoding; b=UIEwWpP4ISoghEls2hAcGGYH+Q/eR1xqOWn06dfbm82yikVV00R1MKszYaIMAEKBCg ZpZ1a/B4bboNWhZFbs/YbSjYDMEIx0HAMVz/MY2GgCF9XkPceNmJfBYrme6kpzVcNlBC mbOAHx9cNSlPYCmOPB6Ir2wCWEkAGsXVYRQ/s=
MIME-Version: 1.0
Received: by 10.100.96.1 with SMTP id t1mr6859346anb.137.1291935587754; Thu, 09 Dec 2010 14:59:47 -0800 (PST)
Received: by 10.101.103.14 with HTTP; Thu, 9 Dec 2010 14:59:47 -0800 (PST)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Date: Thu, 9 Dec 2010 17:59:47 -0500
Message-ID:
From: Phillip Hallam-Baker
To: Jay Daley
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: [email-masked]
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 09 Dec 2010 22:58:18 -0000

It appears that you are assuming that the purpose of this document is
something completely different to what is described in the document.
That is not the case so I do not believe that your comments are
relevant to the proposal made.

The CAA record is intended to express the semantics 'only Comodo is
authorized to issue certs for this zone' or equivalent for other
issuers. I think it rather unlikely that there would be more than two
or three CAs issuing for one domain.

If that does turn out to be an actual use case we can always define
additional property entries.

On Thu, Dec 9, 2010 at 3:33 PM, Jay Daley wrote:
> On 9/12/2010, at 2:44 PM, Phillip Hallam-Baker wrote:
>
>>> My point was that we do not need to store the policy that an issuer or =
a UA should use (i.e. the Authorisation Entries) in DNS but solely a pointe=
r to where it is found. =A0I was not talking about the CP.
>>
>> The Authorization Entries consist of a flag byte, a tag and an ASN.1
>> OID, typically 10 bytes long.
>>
>> This is very clearly explained in the document.
>>
>> A URI reference would be considerably longer, be less stable, be
>> different to the existing practice in X.509 and offer no benefit that
>> I can see.
>
> That again is an orthogonal answer, not answering the point I am making. =
=A0Just to reiterate, my point is two fold:
>
> 1. =A0The format of a CAA record as specified is likely to change far mor=
e often that one which is just a pointer.
>
> 2. =A0The issue of a single CAA record =A0with the current format is not =
an issue, the potential number of them is unbounded. =A0To be quite clear, =
my objection is to putting policy about an external system into DNS. =A0I d=
o not think that is what the DNS is for.
>
>>> Assuming you were talking about that, then I don't agree with the need =
for a hash - we don't provide the hash of the web page pointed to by an _ht=
tp._tcp SRV record. =A0DNSSEC secures the pointer, secure BGP secures the r=
oute to the IP address and the policy protocol secures the transfer of the =
policy.
>>
>> Secure BGP is a proposal and not an infrastructure. And attempting to
>> achieve anything more than preventing Denial of Service in a routing
>> layer solution is probably a mistake.
>
> That is not relevant. =A0The point was about the RR specifying the policy=
it expects to find when it connects to a policy server. =A0Nobody seems to=
need that for any other service pointed to by DNS.
>
> Jay
>
> --
> Jay Daley
> Chief Executive
> .nz Registry Services (New Zealand Domain Name Registry Limited)
> desk: +64 4 931 6977
> mobile: +64 21 678840
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EF8E3A6B4F for ; Thu, 9 Dec 2010 12:32:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WmRKYr4+E9v for ; Thu, 9 Dec 2010 12:32:43 -0800 (PST)
Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id D35D63A6BC2 for ; Thu, 9 Dec 2010 12:32:42 -0800 (PST)
Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 8117F2CE004 for ; Fri, 10 Dec 2010 09:34:14 +1300 (NZDT)
Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmBdlwmsSVTu for ; Fri, 10 Dec 2010 09:34:14 +1300 (NZDT)
Received: from [186.113.247.221] (unknown [186.113.247.221]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 40E682DB578 for ; Fri, 10 Dec 2010 09:34:06 +1300 (NZDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1082)
From: Jay Daley
In-Reply-To:
Date: Thu, 9 Dec 2010 15:33:46 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <[email-masked]>
References: <[email-masked]> <[email-masked]>
To: [email-masked]
X-Mailer: Apple Mail (2.1082)
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 09 Dec 2010 20:32:46 -0000

On 9/12/2010, at 2:44 PM, Phillip Hallam-Baker wrote:

>> My point was that we do not need to store the policy that an issuer =
or a UA should use (i.e. the Authorisation Entries) in DNS but solely a =
pointer to where it is found. I was not talking about the CP.
>=20
> The Authorization Entries consist of a flag byte, a tag and an ASN.1
> OID, typically 10 bytes long.
>=20
> This is very clearly explained in the document.
>=20
> A URI reference would be considerably longer, be less stable, be
> different to the existing practice in X.509 and offer no benefit that
> I can see.

That again is an orthogonal answer, not answering the point I am making. =
Just to reiterate, my point is two fold:

1. The format of a CAA record as specified is likely to change far more =
often that one which is just a pointer. =20

2. The issue of a single CAA record with the current format is not an =
issue, the potential number of them is unbounded. To be quite clear, my =
objection is to putting policy about an external system into DNS. I do =
not think that is what the DNS is for.

>> Assuming you were talking about that, then I don't agree with the =
need for a hash - we don't provide the hash of the web page pointed to =
by an _http._tcp SRV record. DNSSEC secures the pointer, secure BGP =
secures the route to the IP address and the policy protocol secures the =
transfer of the policy.
>=20
> Secure BGP is a proposal and not an infrastructure. And attempting to
> achieve anything more than preventing Denial of Service in a routing
> layer solution is probably a mistake.

That is not relevant. The point was about the RR specifying the policy =
it expects to find when it connects to a policy server. Nobody seems to =
need that for any other service pointed to by DNS.

Jay

--=20
Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 678840

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB3D13A6BB0 for ; Thu, 9 Dec 2010 11:58:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.837
X-Spam-Level:
X-Spam-Status: No, score=-100.837 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, SARE_LWSHORTT=1.24, 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 DLRAnp8HjNM7 for ; Thu, 9 Dec 2010 11:58:20 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id A81653A6B4D for ; Thu, 9 Dec 2010 11:58:20 -0800 (PST)
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 oB9JxmiS045488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Dec 2010 12:59:49 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
Date: Thu, 9 Dec 2010 11:59:46 -0800
To: Phillip Hallam-Baker
From: Paul Hoffman
Content-Type: text/plain; charset="us-ascii"
Cc: [email-masked]
Subject: [keyassure] NUDGE: Re: Where to discuss CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 09 Dec 2010 19:58:21 -0000

[[ A great deal of the recent traffic has nothing to do with client validation and everything to do with CA accountability assumptions. Having that discussion on this list seems quite inappropriate. ]]

At 2:39 PM -0500 12/7/10, Phillip Hallam-Baker wrote:
>When discussing the best approach to bringing security policy work
>into IETF process with the Security Area director, he suggested that
>the best approach would be to submit an Experimental proposal and see
>if we can demonstrate the viability of the proposal first.

You keep speaking for that AD, and he never speaks for himself. That's bad. (And, yes, I have asked him, more than once, to speak for himself on the list.)

There is no such thing as an "Experimental proposal" in the IETF. You might have misunderstood what he said.

There are Experimental RFCs. Those can be published in the IETF stream (after getting IETF consensus) or by the Independent Submissions Editor. (We will assume for the moment that this is not an IAB or IRTF document.)

Which of those two streams are intending with this document? If it is the former, then it is appropriate to ask that AD for a mailing list for this document. If it is the latter, you do not need to discuss this on any IETF mailing list, and it is up to the ISE whether or not whatever you hand him is ready to be published.

>We are currently following that advice, but the long term objective is
>clearly to make a consensus proposal when the ADs are willing to let
>me do so.

Is the short term objective to have an Experimental RFC coming through the ISE?

>Clearly any proposal that has far reaching effects across the industry
>will involve discussions that are outside the scope of IETF.

Indeed. The more of those discussions that can happen on open mailing lists, the better.

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
keyassure mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/keyassure

--Paul Hoffman, Director
--VPN Consortium

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FCF33A6BAB for ; Thu, 9 Dec 2010 11:43:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.276
X-Spam-Level:
X-Spam-Status: No, score=-3.276 tagged_above=-999 required=5 tests=[AWL=0.323, 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 uys1QGanTBIL for ; Thu, 9 Dec 2010 11:43:03 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 525863A6BAD for ; Thu, 9 Dec 2010 11:43:03 -0800 (PST)
Received: by ywk9 with SMTP id 9so1753875ywk.31 for ; Thu, 09 Dec 2010 11:44:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=k+GsFAgy8QRfa/l20QojYOEJQdbQmm0xFZNURcDuf9Y=; b=QXjOPZFP0H5lU7RV3pedOc/5LgdOwK/8jyjCAY7k5DzFBia1FG1tePT64dymteH73s Vu36w4pTU/vmSTy1clFj1P8n/KJDy6q2Fkl68tm1onYj+LXt7aFHOzbaRadC/pGg9ORR hTAD2IEoXIeU+qRRKFZR5476IwyWfclOYIY+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:content-transfer-encoding; b=KdmroNsUEqtskjYekAjBkNEpPm5mn5wgV8cpPb5BLZaP/Te35JvJXVoGCV5b8OtCF8 1GAIeERrWInczFaA1iu8YfRX6P2PyVvl6cmguAIuv/2ym0E7ApC4nWbgebNWJlxe7HX1 EkE4HCrCGD7WlNpc5xDRntBKa6PuWmXOKxs+E=
MIME-Version: 1.0
Received: by 10.100.195.2 with SMTP id s2mr6100685anf.35.1291923872501; Thu, 09 Dec 2010 11:44:32 -0800 (PST)
Received: by 10.101.103.14 with HTTP; Thu, 9 Dec 2010 11:44:32 -0800 (PST)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Date: Thu, 9 Dec 2010 14:44:32 -0500
Message-ID:
From: Phillip Hallam-Baker
To: Jay Daley
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: [email-masked]
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 09 Dec 2010 19:43:04 -0000

On Thu, Dec 9, 2010 at 2:24 PM, Jay Daley wrote:
> On 9/12/2010, at 7:46 AM, Ben Laurie wrote:
>
>>> 1. =A0This would be better as a pointer to where the policy can be foun=
d rather than the contents of the policy itself, because:
>>> - the policy specification can be changed independently of the RR spec,=
thereby reducing the frequency of changes to the RR
>>> - it puts an upper boundary on the amount of data added to the DNS for =
any specific host
>>>
>>> =A0(As an aside, a standardised protocol for pulling policy would be ve=
ry useful in a number of places).
>>
>> If you are going to point at the policy then you'll need a way to
>> validate that the retrieved policy is indeed the one intended. A hash
>> of the policy in the DNS would be one way to achieve this - I am not
>> against the idea, but it needs to be optional.
>
> I'm not sure we are talking about the same thing, probably as I was not s=
pecific enough.
>
> My point was that we do not need to store the policy that an issuer or a =
UA should use (i.e. the Authorisation Entries) in DNS but solely a pointer =
to where it is found. =A0I was not talking about the CP.

The Authorization Entries consist of a flag byte, a tag and an ASN.1
OID, typically 10 bytes long.

This is very clearly explained in the document.

A URI reference would be considerably longer, be less stable, be
different to the existing practice in X.509 and offer no benefit that
I can see.

> Assuming you were talking about that, then I don't agree with the need fo=
r a hash - we don't provide the hash of the web page pointed to by an _http=
._tcp SRV record. =A0DNSSEC secures the pointer, secure BGP secures the rou=
te to the IP address and the policy protocol secures the transfer of the po=
licy.

Secure BGP is a proposal and not an infrastructure. And attempting to
achieve anything more than preventing Denial of Service in a routing
layer solution is probably a mistake.

I do not care about end to end connectivity to IP addresses, I only
care about end-to-end connectivity to Internet endpoints identified by
DNS names. Hence with a means of assuring keys in the DNS, I don't
need the BGP layer to provide protection against anything other than
service attacks.

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

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08B3F3A698A for ; Thu, 9 Dec 2010 11:35:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Py68glm-QGEI for ; Thu, 9 Dec 2010 11:35:25 -0800 (PST)
Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id 032243A6986 for ; Thu, 9 Dec 2010 11:35:25 -0800 (PST)
Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 2E0CE2CE005 for ; Fri, 10 Dec 2010 08:36:58 +1300 (NZDT)
Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWbPEO8Z66el for ; Fri, 10 Dec 2010 08:36:58 +1300 (NZDT)
Received: from [186.113.247.221] (unknown [186.113.247.221]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 18F882CE004 for ; Fri, 10 Dec 2010 08:36:56 +1300 (NZDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1082)
From: Jay Daley
In-Reply-To:
Date: Thu, 9 Dec 2010 14:36:52 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id:
References: <[email-masked]> <[email-masked]>
To: [email-masked]
X-Mailer: Apple Mail (2.1082)
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 09 Dec 2010 19:35:28 -0000

On 9/12/2010, at 7:48 AM, Ben Laurie wrote:

> On 9 December 2010 04:33, Jay Daley wrote:
>>=20
>> On 8/12/2010, at 6:39 PM, Phillip Hallam-Baker wrote:
>>> No, a CA ignores the CAA records unless the Extended Issuer
>>> Authorization Set is non-empty. So a site can advertise client
>>> restrictions without CA issue restrictions (or vice-versa)
>>=20
>> Then the draft should say that.
>=20
> I am not sure why people seem to have such difficulty reading this
> draft, and I welcome suggestions for alternative wording, but ...
> what's wrong with:
>=20
> "If the Extended Issuer Authorization Set for a domain name is not
> empty, a Certification Authority MUST NOT issue a certificate unless
> it conforms to at least one authorization entry in the Extended
> Issuer Authorization Set."

Because that says something about non-empty when I was talking about =
empty. Suggested wording that appears to conform is:

"If the Extender Issuer Authorisation Set for a domain name is empty =
then the CA does not search any parent domain for a CAA record but =
continues as though no CAA record applies."

I should note that this (and PHB's statement above) implicitly =
contradicts the following from the draft:

> The following example informs CAs that certificates must not be
> issued except under the Default Deny Security 'Example 1' =
Certificate
> Policy (1.3.6.1.4.1.35405.666.1). Since the policy is published at
> the Public Delegation Point, the policy applies to all subordinate
> domains under example.com.

Jay

--=20
Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 678840

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 663A228C133 for ; Thu, 9 Dec 2010 11:31:21 -0800 (PST)
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.328, 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 gMaJZnWdCmJU for ; Thu, 9 Dec 2010 11:31:20 -0800 (PST)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 0A51628C122 for ; Thu, 9 Dec 2010 11:31:19 -0800 (PST)
Received: by yxt33 with SMTP id 33so1740348yxt.31 for ; Thu, 09 Dec 2010 11:32:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=0oGnp59xS7dTSrkPXu7sosgXUgg8Un0NipUBVdhZ1wg=; b=oB/BBWOsm0Zb9Y4IoHHl6EOa10PMcSZl0nxcvRML99j1i0EErFleYdryFgZvqzXPKt w5i6i4e7+L6vXtGzOBKkwlRInC9cTAWaICjfDIppudaNUqtZgY/iKsda0I+uMMwsYSQJ mxoISENGiY14i45NAf6zAtw182MGWz1hDCHck=
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:content-transfer-encoding; b=EoFan7YlUgLlbImNWr68NkODn/MCWzW0l/yrLkn7+zxEyc2Hz3UjGkEvS2Px6PHqtM zeG5OzCjYiJHHjdLhsIgrKSfpLjoetAiVadaCNW/4eGLrvJeGL2ySfmAwzOGzZRSf3XP T6kU4Rs7z2R2NiQf5vWnbvY73A0DbZPW4Y0hk=
MIME-Version: 1.0
Received: by 10.100.167.20 with SMTP id p20mr7159170ane.103.1291923169832; Thu, 09 Dec 2010 11:32:49 -0800 (PST)
Received: by 10.101.103.14 with HTTP; Thu, 9 Dec 2010 11:32:49 -0800 (PST)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Date: Thu, 9 Dec 2010 14:32:49 -0500
Message-ID:
From: Phillip Hallam-Baker
To: Andrew Sullivan
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: [email-masked]
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 09 Dec 2010 19:31:21 -0000

The reason I used the term 'reserved' is that this is the term that
IANA have been using in the registry. If you look you will note that
Stuart's EDNS allocation is marked reserved pending the processing of
the RFC.

I really don't want to get into a debate over the terminology here though.

There are two parts to the proposal. The first is the packaging format
which I think is pretty clear. is going to be sufficient for any
eventually as specified.

Paul has proposed some modifications to that format which I am willing
to agree to for the sake of compromise, provided that nobody else has
an objection and provided that it is stipulated that my willingness to
accept a reasonable compromise does not indicate any uncertainty,
confusion or anything else other than a willingness to be reasonable.

The property entries are extensible via a tag-value mechanism plus a
criticality bit. I think that it is very clear that this is going to
be more than sufficient for the proposed use. We have survived for
almost two decades with this in X.509v3.

So yes, I understand that the minute code goes out that employs the
RR, that this is going to effectively burn it as far as any other
proposed use is concerned.

I do not believe that the 'experimental use' area is appropriate for
this particular experiment since it is an open test and involve action
by CAs and domain name owners. If we use an experimental use code we
will have to work out a transition plan which would be complex and we
have more than enough moving parts already.

In particular, these records have rather more powerful semantics than
your typical Internet trial. I want to make sure that we do not end up
causing future experiments using that range to have unexpected side
effects.

On Thu, Dec 9, 2010 at 11:40 AM, Andrew Sullivan wrote:
> On Thu, Dec 09, 2010 at 10:54:05AM -0500, Phillip Hallam-Baker wrote:
>
>> As I keep saying, my only priority at this stage is to get a RR code
>> reserved so that we can start field trials.
>
> I want to be perfectly clear about this, just in case it wasn't
> before: you're not getting an RRTYPE code "reserved". =A0Under the
> procedures of RFC 5395, you're getting one _assigned_. =A0It means that
> your RRTYPE is defined for the DNS, effectively forever.
>
> I'm not sure if this has been clear to you so far, but if you think
> that dramatic changes to the RRTYPE are going to sail through later in
> the event you move the resulting protocol in the EXPERIMENTAL RFC to
> the standards track, then you need to think again about your strategy.
> The DNS community is notoriously prickly about this.
>
> We have a slightly tricky situation in the case of expert assignment
> for things in I-Ds. =A0But as a practical matter, what has happened is
> that we've treated the final I-D as definitive, and done template
> updates accordingly. =A0This is necessary, because the description
> required by section E is often a link to some I-D. =A0It is whatever
> ends up in E that is the final authority of what the RRTYPE looks
> like, and I-Ds can't be treated as stable references because, in
> principle, they disappear after 6 months.
>
> Once you have an RRTYPE, however, it is hard to change it in
> incompatible ways (which very nearly means "at all"), because of
> deployed software.
>
> There has occasionally been talk of allocating an "experimental use"
> range, but note that 65280-65534 is already private use. =A0If you want
> to experiment with your closest friends, you can do it without an
> RRTYPE assignment.
>
> A
>
> --
> Andrew Sullivan
> [email-masked]
> Shinkuro, Inc.
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01A353A698C for ; Thu, 9 Dec 2010 11:23:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jeHk+GUsJzhH for ; Thu, 9 Dec 2010 11:23:23 -0800 (PST)
Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id C19083A698A for ; Thu, 9 Dec 2010 11:23:22 -0800 (PST)
Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id C55612CE005 for ; Fri, 10 Dec 2010 08:24:54 +1300 (NZDT)
Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGNvpxXti9vV for ; Fri, 10 Dec 2010 08:24:54 +1300 (NZDT)
Received: from [186.113.247.221] (unknown [186.113.247.221]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id E049B2CE004 for ; Fri, 10 Dec 2010 08:24:51 +1300 (NZDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1082)
From: Jay Daley
In-Reply-To:
Date: Thu, 9 Dec 2010 14:24:47 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <[email-masked]>
References: <[email-masked]>
To: [email-masked]
X-Mailer: Apple Mail (2.1082)
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 09 Dec 2010 19:23:29 -0000

On 9/12/2010, at 7:46 AM, Ben Laurie wrote:

>> 1. This would be better as a pointer to where the policy can be =
found rather than the contents of the policy itself, because:
>> - the policy specification can be changed independently of the RR =
spec, thereby reducing the frequency of changes to the RR
>> - it puts an upper boundary on the amount of data added to the DNS =
for any specific host
>>=20
>> (As an aside, a standardised protocol for pulling policy would be =
very useful in a number of places).
>=20
> If you are going to point at the policy then you'll need a way to
> validate that the retrieved policy is indeed the one intended. A hash
> of the policy in the DNS would be one way to achieve this - I am not
> against the idea, but it needs to be optional.

I'm not sure we are talking about the same thing, probably as I was not =
specific enough.

My point was that we do not need to store the policy that an issuer or a =
UA should use (i.e. the Authorisation Entries) in DNS but solely a =
pointer to where it is found. I was not talking about the CP.

Assuming you were talking about that, then I don't agree with the need =
for a hash - we don't provide the hash of the web page pointed to by an =
_http._tcp SRV record. DNSSEC secures the pointer, secure BGP secures =
the route to the IP address and the policy protocol secures the transfer =
of the policy.

>> 2. Given that this list is discussing keys in DNS, shouldn't this =
draft be wider than just CAs and include policy relating to keys in DNS?
>=20
> ?? It does.

If it doesn't then we will have two different RRs for managing the =
policy around certs.

Jay

--=20
Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 678840

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B38428C114 for ; Thu, 9 Dec 2010 08:44:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpinR2a-KaU1 for ; Thu, 9 Dec 2010 08:44:56 -0800 (PST)
Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id 6CD1928C0DD for ; Thu, 9 Dec 2010 08:44:56 -0800 (PST)
Received: from [186.113.244.233] (unknown [186.113.244.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id BCE2122843A8; Thu, 9 Dec 2010 11:43:29 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=utf-8
From: Warren Kumari
In-Reply-To:
Date: Thu, 9 Dec 2010 11:50:27 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <[email-masked]>
References: <[email-masked]> <[email-masked]>
To: Ben Laurie
X-Mailer: Apple Mail (2.1081)
Cc: [email-masked], Paul Hoffman
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 09 Dec 2010 16:45:00 -0000

On Dec 9, 2010, at 10:05 AM, Ben Laurie wrote:

[ SNIP ]

>=20
>> Of course, you could also just get rid of the client restrictions =
altogether and make your protocol cleaner. Kitchen-sink protocols in the =
IETF do not always work as well as we would hope.
>=20
> I would not describe this as kitchen sink. If I get rid of client
> restrictions from this, then where do I get my client restrictions
> from?

We are *almost* a WG -- the last holdup was the name (it was felt that =
KIDNS was to close to KITTENS, and so we are going to be called (great) =
DANE) -- and are just waiting on the "Go" button to be pushed.

One of the primary documents is supposed to be just what you are =
describing (and we have set very aggressive milestones on getting it =
done).

The chairs have already asked Paul Hoffman and Jakob if they would be =
willing to author =E2=88=9200 of the protocol document (starting with =
the ideas from the three documents listed in the charter, augmented by =
the wide discussion that has happened since we submitted the charter) =
and they have agreed to do so.

W

> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 003F128C0DD for ; Thu, 9 Dec 2010 08:39:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.656
X-Spam-Level:
X-Spam-Status: No, score=-102.656 tagged_above=-999 required=5 tests=[AWL=-0.057, 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 KAU7SlOIo2E2 for ; Thu, 9 Dec 2010 08:39:00 -0800 (PST)
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 1BC103A6801 for ; Thu, 9 Dec 2010 08:38:57 -0800 (PST)
Received: from crankycanuck.ca (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 AE2511ECB408 for ; Thu, 9 Dec 2010 16:40:25 +0000 (UTC)
Date: Thu, 9 Dec 2010 11:40:22 -0500
From: Andrew Sullivan
To: [email-masked]
Message-ID: <[email-masked]>
References: <[email-masked]> <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To:
User-Agent: Mutt/1.5.18 (2008-05-17)
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 09 Dec 2010 16:39:07 -0000

On Thu, Dec 09, 2010 at 10:54:05AM -0500, Phillip Hallam-Baker wrote:

> As I keep saying, my only priority at this stage is to get a RR code
> reserved so that we can start field trials.

I want to be perfectly clear about this, just in case it wasn't
before: you're not getting an RRTYPE code "reserved". Under the
procedures of RFC 5395, you're getting one _assigned_. It means that
your RRTYPE is defined for the DNS, effectively forever.

I'm not sure if this has been clear to you so far, but if you think
that dramatic changes to the RRTYPE are going to sail through later in
the event you move the resulting protocol in the EXPERIMENTAL RFC to
the standards track, then you need to think again about your strategy.
The DNS community is notoriously prickly about this.

We have a slightly tricky situation in the case of expert assignment
for things in I-Ds. But as a practical matter, what has happened is
that we've treated the final I-D as definitive, and done template
updates accordingly. This is necessary, because the description
required by section E is often a link to some I-D. It is whatever
ends up in E that is the final authority of what the RRTYPE looks
like, and I-Ds can't be treated as stable references because, in
principle, they disappear after 6 months.

Once you have an RRTYPE, however, it is hard to change it in
incompatible ways (which very nearly means "at all"), because of
deployed software.

There has occasionally been talk of allocating an "experimental use"
range, but note that 65280-65534 is already private use. If you want
to experiment with your closest friends, you can do it without an
RRTYPE assignment.

A

--
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE2E228C0F8 for ; Thu, 9 Dec 2010 08:37:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnWH949NrKbV for ; Thu, 9 Dec 2010 08:37:38 -0800 (PST)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 6E44A3A6B93 for ; Thu, 9 Dec 2010 08:37:38 -0800 (PST)
Received: by wyf23 with SMTP id 23so2507233wyf.31 for ; Thu, 09 Dec 2010 08:39:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=tOS5JwCdj2uDRd8lnaOWT4HqymR0LDiHFMcw4lrVPNE=; b=kA7CAKp5WxQr2wCiZXQ3I/W9kxZVXa24BUl50mg94tnM7pG8rvcRXDtwKnoVLv54xe p2wHVzO8NrSKcxkVOLQb81UJx1I1xtwJIeAhi6fAoCfe0HY6N0cqVmvd4eIcKOzhToMy Ey7Rfmr0TR+dn059cNCpWPeovsuy2uI4uniWU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=YzVd2rhLOLOs+knaWmqEDq7HkE9HZQLsfe5dQQZbF2qzrKmlyqtGLPb4R+op58fK3V V7pHhScOMWhJNrNdVj5alHqa7LdWBjYe6Sd9Pu//jKQk0kjJ67fDtfAytrA6ogxbAP0P nece72DECSbMw7H4SlJB7V/5QjEG0DFtezyiw=
Received: by 10.216.182.8 with SMTP id n8mr2143216wem.41.1291912747637; Thu, 09 Dec 2010 08:39:07 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.183.198 with HTTP; Thu, 9 Dec 2010 08:38:47 -0800 (PST)
In-Reply-To:
References: <[email-masked]> <[email-masked]>
From: Geoff Beier
Date: Thu, 9 Dec 2010 11:38:47 -0500
Message-ID:
To: Phillip Hallam-Baker
Content-Type: text/plain; charset=ISO-8859-1
Cc: [email-masked], Paul Hoffman
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 09 Dec 2010 16:37:39 -0000

On Thu, Dec 9, 2010 at 10:54, Phillip Hallam-Baker wrote:
>
> The issue that we were trying to address with the policy approach is
> that cert paths are not necessarily constant across all browsers due
> to roots being resigned.
>
> There are a bunch of cases in the US federal government PKI where the
> requirement is precisely for a cert that meets the government issue
> policy but does not specify the supplier. But I don't want to get into
> an in depth discussion of bridge CAs.
>

I don't see where a discussion of bridge CAs is required to address
these cases. Isn't the right approach for these to have the record
identify the common policy root along with the acceptable policy?

I don't understand the case for how a record identifying a policy but
no CA has any reliable security meaning.

Geoff

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BA2828C126 for ; Thu, 9 Dec 2010 08:13:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.458
X-Spam-Level:
X-Spam-Status: No, score=-101.458 tagged_above=-999 required=5 tests=[AWL=0.588, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 7MmZdOHKNGgV for ; Thu, 9 Dec 2010 08:13:12 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 1624228C0FB for ; Thu, 9 Dec 2010 08:13:12 -0800 (PST)
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 oB9GEb9t035892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Dec 2010 09:14:38 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References: <[email-masked]> <[email-masked]>
Date: Thu, 9 Dec 2010 08:14:36 -0800
To: Phillip Hallam-Baker , Ben Laurie
From: Paul Hoffman
Content-Type: text/plain; charset="us-ascii"
Cc: [email-masked]
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 09 Dec 2010 16:13:13 -0000

At 10:54 AM -0500 12/9/10, Phillip Hallam-Baker wrote:
>Is there anything in the current spec that suggests that it is not
>ready for trials?

The fact that so few people other than you seem to understand it?

--Paul Hoffman, Director
--VPN Consortium

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A589928C0F3 for ; Thu, 9 Dec 2010 08:11:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.453
X-Spam-Level:
X-Spam-Status: No, score=-101.453 tagged_above=-999 required=5 tests=[AWL=0.593, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 GUA4BYcFq0kB for ; Thu, 9 Dec 2010 08:11:33 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id C4A1E28C0DD for ; Thu, 9 Dec 2010 08:11:24 -0800 (PST)
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 oB9GCpgL035794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Dec 2010 09:12:51 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References: <[email-masked]> <[email-masked]>
Date: Thu, 9 Dec 2010 08:12:50 -0800
To: Ben Laurie
From: Paul Hoffman
Content-Type: text/plain; charset="us-ascii"
Cc: [email-masked]
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 09 Dec 2010 16:11:34 -0000

At 3:05 PM +0000 12/9/10, Ben Laurie wrote:
> > Of course, you could also just get rid of the client restrictions altogether and make your protocol cleaner. Kitchen-sink protocols in the IETF do not always work as well as we would hope.
>
>I would not describe this as kitchen sink. If I get rid of client
>restrictions from this, then where do I get my client restrictions
>from?

The standards-track protocol that this soon-to-be-WG is supposed to produce.

--Paul Hoffman, Director
--VPN Consortium

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8C1B3A6B70 for ; Thu, 9 Dec 2010 08:02:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 5HnnRKFgOnkK for ; Thu, 9 Dec 2010 08:02:18 -0800 (PST)
Received: from mail152.messagelabs.com (mail152.messagelabs.com [216.82.253.19]) by core3.amsl.com (Postfix) with SMTP id 8B0153A6B6C for ; Thu, 9 Dec 2010 08:02:15 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [email-masked]
X-Msg-Ref: server-15.tower-152.messagelabs.com!1291910623!35350478!1
X-StarScan-Version: 6.2.9; banners=-,-,-
X-Originating-IP: [65.242.48.8]
Received: (qmail 8207 invoked from network); 9 Dec 2010 16:03:44 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (65.242.48.8) by server-15.tower-152.messagelabs.com with SMTP; 9 Dec 2010 16:03:44 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Thu, 9 Dec 2010 11:03:42 -0500
Message-ID:
In-Reply-To:
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [keyassure] Revised version of CAA
Thread-Index: AcuXuVXeIwwohhl4Tzi3JV/hICq6YQAALz+w
References: <[email-masked]><[email-masked]>
From: "Carl Wallace"
To: "Phillip Hallam-Baker" , "Ben Laurie"
Cc: [email-masked], Paul Hoffman
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 09 Dec 2010 16:02:19 -0000

> >> See above. Your first example is:
> >>> =A0 $ORIGIN example.com
> >>> =A0 . =A0 =A0 =A0 CAA 1 policy 1.3.6.1.4.1.35405.666.1
> >> That says "absolutely anyone can issue a cert for me, as long as it =
has this
> policy OID in it". That is not the type of thing most people want to =
say. Maybe
> consider putting your second example first, or even getting rid of the
> examples with policy OIDs altogether.
> >
> > As I believe I said before - I am informed (by Phil) that this is
> > equivalent to saying "only WhizzyCA can issue certs" and one of my
> > editorial comments was that we need a section to explain this.
> > Unfortunately it seems we managed to forget to do that, but I agree =
it
> > is confusing.
>=20
> I am pretty sure that is how a reasonable CA would interpet the it.
> But the point of security is to deal with people who are not. I can =
try to make
> it a bit clearer.

This is very confusing. The text you have suggested leaves open the =
possibility that the CA considers its own policy to meet or exceed the =
requested policy. Would a CA exercising that portion of this spec be =
unreasonable? You still haven't answered why a CA should be allowed to =
use a policy it decided is OK.
=20
>=20
> The issue that we were trying to address with the policy approach is =
that cert
> paths are not necessarily constant across all browsers due to roots =
being
> resigned.

What browsers are enforcing policies that are expressed in trust =
anchors? If there are any, how does the proposed mechanism effect that?
=20
> There are a bunch of cases in the US federal government PKI where the
> requirement is precisely for a cert that meets the government issue =
policy
> but does not specify the supplier. But I don't want to get into an in =
depth
> discussion of bridge CAs.
>=20
> >> There is no example with the two things Phil says above (client =
restrictions
> with no issue restrictions, or vice versa). Adding those might help =
people see
> that you can do these two orthogonal things at the same time.
> >
> > I agree.
>=20
> OK we can add in an example in which the issue restrictions are by =
policy but
> the client restrictions are by cert path. I think this would be the =
most
> common case where there would be a desire to have a client =
authorization
> entry that is not an issuer authorization entry (and vice versa).
>=20
> >> Of course, you could also just get rid of the client restrictions =
altogether
> and make your protocol cleaner. Kitchen-sink protocols in the IETF do =
not
> always work as well as we would hope.
>=20
> Kitchen sink proposals do not do well when the people presenting them =
are
> not willing to consider the full range of issues they raise. In this =
case we have
> been discussing designs for both purposes and have concluded that one
> scheme is better than two.
>=20
>=20
> > I would not describe this as kitchen sink. If I get rid of client
> > restrictions from this, then where do I get my client restrictions
> > from?
>=20
> I did start looking at doing these two separately. But this has a real =
risk that
> people will start attempting to enforce records written only for use =
by issuers
> in RPs. In particular, the fact that an Issuer is no longer authorized =
does not
> mean that they were not properly authorized when the cert was issued.
>=20
> Looking at the management processes, it was clear that any issuer =
proposal
> would have to have an indication of whether the records can be used =
for app
> enforcement at the very least. As it happens Ben and I both came to =
the
> realization independently that we could use the unused bits in the =
length
> byte in the way we propose here.
>=20
>=20
> I am very confident that this mechanism is more than capable of =
allowing 99%
> of sites to advertise their current issue restrictions and 90% of =
sites to
> advertise the client enforcement restrictions they would like =
enforced. I am
> also fairly sure that if we remove either of the properties currently =
specified
> that the coverage will be significantly reduced.
>=20
> As I keep saying, my only priority at this stage is to get a RR code =
reserved so
> that we can start field trials.
>=20
>=20
> Is there anything in the current spec that suggests that it is not =
ready for
> trials?
>=20
>=20
> --
> Website: http://hallambaker.com/
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A17B628C0E7 for ; Thu, 9 Dec 2010 07:52:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.259
X-Spam-Level:
X-Spam-Status: No, score=-3.259 tagged_above=-999 required=5 tests=[AWL=0.340, 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 Tt72G5lv6FZs for ; Thu, 9 Dec 2010 07:52:36 -0800 (PST)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 4852128C112 for ; Thu, 9 Dec 2010 07:52:36 -0800 (PST)
Received: by gyd12 with SMTP id 12so1565898gyd.31 for ; Thu, 09 Dec 2010 07:54:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Vpi0t2BeyTVE3FTuoBw/0uiScPK5wbxcLWHQXs/KVcA=; b=bXVCOworpZ9BLbruEPe6R1KszE5cb/PDpv4ZdsWbDqJI9ekl5V29tycKiATAiPmxJd dcLBg6SRPcTxTlrPcKTjGvMqD1RzHS9Iv8cqC/2RDS/XvlcXdQA2tekVstypalfL94la DMiIgKayks1QULBMh3GOK+7JcOApQR4z7x5iQ=
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:content-transfer-encoding; b=KrupUIz/A4TfMvL1GDxQqKO2MePxh9e/Su+5ZThO0szJhN+KdfyD5QAu3I2lxpuJjn LYOQ8jUMhUTjx9ivERpEUMa8N5zlFFL4lvSjkUXwmoIkPa95xgITTzohQXsg5SfQ6V0u hfty3PSHQ1BHHFqIvfZzkwIgsmA1ra+3fR3r0=
MIME-Version: 1.0
Received: by 10.100.96.1 with SMTP id t1mr6551440anb.137.1291910045838; Thu, 09 Dec 2010 07:54:05 -0800 (PST)
Received: by 10.101.103.14 with HTTP; Thu, 9 Dec 2010 07:54:05 -0800 (PST)
In-Reply-To:
References: <[email-masked]> <[email-masked]>
Date: Thu, 9 Dec 2010 10:54:05 -0500
Message-ID:
From: Phillip Hallam-Baker
To: Ben Laurie
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: [email-masked], Paul Hoffman
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 09 Dec 2010 15:52:37 -0000

On Thu, Dec 9, 2010 at 10:05 AM, Ben Laurie wrote:
> On 9 December 2010 14:59, Paul Hoffman wrote:

>> See above. Your first example is:
>>> =A0 $ORIGIN example.com
>>> =A0 . =A0 =A0 =A0 CAA 1 policy 1.3.6.1.4.1.35405.666.1
>> That says "absolutely anyone can issue a cert for me, as long as it has =
this policy OID in it". That is not the type of thing most people want to s=
ay. Maybe consider putting your second example first, or even getting rid o=
f the examples with policy OIDs altogether.
>
> As I believe I said before - I am informed (by Phil) that this is
> equivalent to saying "only WhizzyCA can issue certs" and one of my
> editorial comments was that we need a section to explain this.
> Unfortunately it seems we managed to forget to do that, but I agree it
> is confusing.

I am pretty sure that is how a reasonable CA would interpet the it.
But the point of security is to deal with people who are not. I can
try to make it a bit clearer.

The issue that we were trying to address with the policy approach is
that cert paths are not necessarily constant across all browsers due
to roots being resigned.

There are a bunch of cases in the US federal government PKI where the
requirement is precisely for a cert that meets the government issue
policy but does not specify the supplier. But I don't want to get into
an in depth discussion of bridge CAs.

>> There is no example with the two things Phil says above (client restrict=
ions with no issue restrictions, or vice versa). Adding those might help pe=
ople see that you can do these two orthogonal things at the same time.
>
> I agree.

OK we can add in an example in which the issue restrictions are by
policy but the client restrictions are by cert path. I think this
would be the most common case where there would be a desire to have a
client authorization entry that is not an issuer authorization entry
(and vice versa).

>> Of course, you could also just get rid of the client restrictions altoge=
ther and make your protocol cleaner. Kitchen-sink protocols in the IETF do =
not always work as well as we would hope.

Kitchen sink proposals do not do well when the people presenting them
are not willing to consider the full range of issues they raise. In
this case we have been discussing designs for both purposes and have
concluded that one scheme is better than two.

> I would not describe this as kitchen sink. If I get rid of client
> restrictions from this, then where do I get my client restrictions
> from?

I did start looking at doing these two separately. But this has a real
risk that people will start attempting to enforce records written only
for use by issuers in RPs. In particular, the fact that an Issuer is
no longer authorized does not mean that they were not properly
authorized when the cert was issued.

Looking at the management processes, it was clear that any issuer
proposal would have to have an indication of whether the records can
be used for app enforcement at the very least. As it happens Ben and I
both came to the realization independently that we could use the
unused bits in the length byte in the way we propose here.

I am very confident that this mechanism is more than capable of
allowing 99% of sites to advertise their current issue restrictions
and 90% of sites to advertise the client enforcement restrictions they
would like enforced. I am also fairly sure that if we remove either of
the properties currently specified that the coverage will be
significantly reduced.

As I keep saying, my only priority at this stage is to get a RR code
reserved so that we can start field trials.

Is there anything in the current spec that suggests that it is not
ready for trials?

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

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F8C628C135 for ; Thu, 9 Dec 2010 07:04:10 -0800 (PST)
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 aU6B6mbTvHIe for ; Thu, 9 Dec 2010 07:04:08 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 4E4DF28C117 for ; Thu, 9 Dec 2010 07:04:08 -0800 (PST)
Received: from kpbe16.cbf.corp.google.com (kpbe16.cbf.corp.google.com [172.25.105.80]) by smtp-out.google.com with ESMTP id oB9F5bTG014752 for ; Thu, 9 Dec 2010 07:05:37 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1291907137; bh=uK+ojlMKhnjj5nT/STXmvEoLkGo=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=qO/evhSM+4U8MzHK/yL8TNe3CwjQGfPPAcBV/QghhtQdyYu7jI0T/w2a4+RKMY/Uo 3Lq+T37yKdEAWARjrUneA==
Received: from pwi10 (pwi10.prod.google.com [10.241.219.10]) by kpbe16.cbf.corp.google.com with ESMTP id oB9F5JsT024634 for ; Thu, 9 Dec 2010 07:05:36 -0800
Received: by pwi10 with SMTP id 10so597154pwi.13 for ; Thu, 09 Dec 2010 07:05:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=qvo4GdaUUX585zB6eOpWpUOMBDlWu6Jh50fNBhobX3k=; b=KHoM1jGyOXbhHgkfa67kY1rAxgmiIltpEujkyRDYNcarjqLzVYpdobsOodjMPr3nk8 vg8T7o6CwZT2vDTPLMbQ==
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=BDACJZz9A299re4lHb1GoAIxWoyflZosgV/0l79pBaTC4MHqIWiB9yGRYLuoo97JlO Ff245F8kLQmlIX3ms5iw==
MIME-Version: 1.0
Received: by 10.142.98.3 with SMTP id v3mr4110269wfb.191.1291907135627; Thu, 09 Dec 2010 07:05:35 -0800 (PST)
Received: by 10.142.47.14 with HTTP; Thu, 9 Dec 2010 07:05:35 -0800 (PST)
In-Reply-To:
References: <[email-masked]> <[email-masked]>
Date: Thu, 9 Dec 2010 15:05:35 +0000
Message-ID:
From: Ben Laurie
To: Paul Hoffman
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
Cc: [email-masked]
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 09 Dec 2010 15:04:10 -0000

On 9 December 2010 14:59, Paul Hoffman wrote:
> At 12:48 PM +0000 12/9/10, Ben Laurie wrote:
>>On 9 December 2010 04:33, Jay Daley wrote:
>>>
>>> On 8/12/2010, at 6:39 PM, Phillip Hallam-Baker wrote:
>>>> No, a CA ignores the CAA records unless the Extended Issuer
>>>> Authorization Set is non-empty. So a site can advertise client
>>>> restrictions without CA issue restrictions (or vice-versa)
>>>
>>> Then the draft should say that.
>>
>>I am not sure why people seem to have such difficulty reading this
>>draft, and I welcome suggestions for alternative wording,
>
> I can only speak for myself, but the reason I had such difficulty reading=
the draft is that it mixes up CA issuing policy and end user policy but th=
an says they are not really mixed up but then has no useful examples that s=
how both types of policies.
>
> Further, the emphasis on policy-by-OID is pretty foreign to most people. =
We can understand "if you are not WhizzyCA, don't issue a cert for me", but=
the idea of "even if you are WhizzyCA, don't issue a cert unless it has po=
licy OID 1.2.457.999.33.1" seems a tad foreign. Yet that is what your examp=
les emphasize.
>
>> but ...
>>what's wrong with:
>>
>>"If the Extended Issuer Authorization Set for a domain name is not
>> =A0 empty, a Certification Authority MUST NOT issue a certificate unless
>> =A0 it conforms to at least one authorization entry in the Extended
>> =A0 Issuer Authorization Set."
>
> See above. Your first example is:
>> =A0 $ORIGIN example.com
>> =A0 . =A0 =A0 =A0 CAA 1 policy 1.3.6.1.4.1.35405.666.1
> That says "absolutely anyone can issue a cert for me, as long as it has t=
his policy OID in it". That is not the type of thing most people want to sa=
y. Maybe consider putting your second example first, or even getting rid of=
the examples with policy OIDs altogether.

As I believe I said before - I am informed (by Phil) that this is
equivalent to saying "only WhizzyCA can issue certs" and one of my
editorial comments was that we need a section to explain this.
Unfortunately it seems we managed to forget to do that, but I agree it
is confusing.

> There is no example with the two things Phil says above (client restricti=
ons with no issue restrictions, or vice versa). Adding those might help peo=
ple see that you can do these two orthogonal things at the same time.

I agree.

> Of course, you could also just get rid of the client restrictions altoget=
her and make your protocol cleaner. Kitchen-sink protocols in the IETF do n=
ot always work as well as we would hope.

I would not describe this as kitchen sink. If I get rid of client
restrictions from this, then where do I get my client restrictions
from?

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77AE628C0EA for ; Thu, 9 Dec 2010 06:58:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.447
X-Spam-Level:
X-Spam-Status: No, score=-101.447 tagged_above=-999 required=5 tests=[AWL=0.599, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 C7qTJoR7thur for ; Thu, 9 Dec 2010 06:58:05 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id C207B28C128 for ; Thu, 9 Dec 2010 06:58:04 -0800 (PST)
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 oB9ExTi5032091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Dec 2010 07:59:31 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References: <[email-masked]> <[email-masked]>
Date: Thu, 9 Dec 2010 06:59:28 -0800
To: Ben Laurie , Jay Daley
From: Paul Hoffman
Content-Type: text/plain; charset="us-ascii"
Cc: [email-masked]
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 09 Dec 2010 14:58:06 -0000

At 12:48 PM +0000 12/9/10, Ben Laurie wrote:
>On 9 December 2010 04:33, Jay Daley wrote:
>>
>> On 8/12/2010, at 6:39 PM, Phillip Hallam-Baker wrote:
>>> No, a CA ignores the CAA records unless the Extended Issuer
>>> Authorization Set is non-empty. So a site can advertise client
>>> restrictions without CA issue restrictions (or vice-versa)
>>
>> Then the draft should say that.
>
>I am not sure why people seem to have such difficulty reading this
>draft, and I welcome suggestions for alternative wording,

I can only speak for myself, but the reason I had such difficulty reading the draft is that it mixes up CA issuing policy and end user policy but than says they are not really mixed up but then has no useful examples that show both types of policies.

Further, the emphasis on policy-by-OID is pretty foreign to most people. We can understand "if you are not WhizzyCA, don't issue a cert for me", but the idea of "even if you are WhizzyCA, don't issue a cert unless it has policy OID 1.2.457.999.33.1" seems a tad foreign. Yet that is what your examples emphasize.

> but ...
>what's wrong with:
>
>"If the Extended Issuer Authorization Set for a domain name is not
> empty, a Certification Authority MUST NOT issue a certificate unless
> it conforms to at least one authorization entry in the Extended
> Issuer Authorization Set."

See above. Your first example is:
> $ORIGIN example.com
> . CAA 1 policy 1.3.6.1.4.1.35405.666.1
That says "absolutely anyone can issue a cert for me, as long as it has this policy OID in it". That is not the type of thing most people want to say. Maybe consider putting your second example first, or even getting rid of the examples with policy OIDs altogether.

There is no example with the two things Phil says above (client restrictions with no issue restrictions, or vice versa). Adding those might help people see that you can do these two orthogonal things at the same time.

Of course, you could also just get rid of the client restrictions altogether and make your protocol cleaner. Kitchen-sink protocols in the IETF do not always work as well as we would hope.

--Paul Hoffman, Director
--VPN Consortium

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3A6D28C0EE for ; Thu, 9 Dec 2010 04:46:45 -0800 (PST)
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 EbtfAzR1MAmi for ; Thu, 9 Dec 2010 04:46:45 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 5120028C0EF for ; Thu, 9 Dec 2010 04:46:44 -0800 (PST)
Received: from kpbe18.cbf.corp.google.com (kpbe18.cbf.corp.google.com [172.25.105.82]) by smtp-out.google.com with ESMTP id oB9CmDcK012256 for ; Thu, 9 Dec 2010 04:48:13 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1291898893; bh=Jl0ve9q7YJrESUMmRVfZBowq8Kc=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=P83ymxWCfS6TQUOdJBxiyrM9PBvnPTSxOXsNmLkcJ8XYL4QOmysPZU3A0G/spnqmk kDm/eOSX2Pm94n+mxIa6Q==
Received: from pwj8 (pwj8.prod.google.com [10.241.219.72]) by kpbe18.cbf.corp.google.com with ESMTP id oB9CmB0K020933 for ; Thu, 9 Dec 2010 04:48:12 -0800
Received: by pwj8 with SMTP id 8so836655pwj.22 for ; Thu, 09 Dec 2010 04:48:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=OIaz9/TDcMQ8jZteDUT3l15i+9mY5CSqHqiT5BRfQoM=; b=HnAapoUc0VDUIsnyHnxka/lQ3vNu2Kd2PGo4ub0UHvU9IzlV0eXftR1kaC7//op0Hq 9jFs739IgazA4Vy80vmA==
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; b=EnAAm57Z4UiZpEIzoMYeRlGxoDJPaYtxAn+jPkptepzTHkNXBwTFWkF45r9iEevbPY PDzVQaf3BWS6qLH32cug==
MIME-Version: 1.0
Received: by 10.142.233.6 with SMTP id f6mr3463663wfh.305.1291898891693; Thu, 09 Dec 2010 04:48:11 -0800 (PST)
Received: by 10.142.47.14 with HTTP; Thu, 9 Dec 2010 04:48:11 -0800 (PST)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Date: Thu, 9 Dec 2010 12:48:11 +0000
Message-ID:
From: Ben Laurie
To: Jay Daley
Content-Type: text/plain; charset=ISO-8859-1
X-System-Of-Record: true
Cc: [email-masked]
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 09 Dec 2010 12:46:46 -0000

On 9 December 2010 04:33, Jay Daley wrote:
>
> On 8/12/2010, at 6:39 PM, Phillip Hallam-Baker wrote:
>> No, a CA ignores the CAA records unless the Extended Issuer
>> Authorization Set is non-empty. So a site can advertise client
>> restrictions without CA issue restrictions (or vice-versa)
>
> Then the draft should say that.

I am not sure why people seem to have such difficulty reading this
draft, and I welcome suggestions for alternative wording, but ...
what's wrong with:

"If the Extended Issuer Authorization Set for a domain name is not
empty, a Certification Authority MUST NOT issue a certificate unless
it conforms to at least one authorization entry in the Extended
Issuer Authorization Set."

?

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFAE428C0E5 for ; Thu, 9 Dec 2010 04:45:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.977
X-Spam-Level:
X-Spam-Status: No, score=-109.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_HI=-8, 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 n+TEZqN1WEJT for ; Thu, 9 Dec 2010 04:45:26 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 7845828C0F2 for ; Thu, 9 Dec 2010 04:45:25 -0800 (PST)
Received: from kpbe12.cbf.corp.google.com (kpbe12.cbf.corp.google.com [172.25.105.76]) by smtp-out.google.com with ESMTP id oB9Ckrrk024936 for ; Thu, 9 Dec 2010 04:46:53 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1291898814; bh=hXY6iJdmjau+Wgu+HrpA3IAJ4rE=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=q9nMvcEkF2ar9ewe3KpdG4m/wWKQi5yRSrZ6y75tXeHdpeoxFPXqyye9k6aD/EjQL yCNYT/JDANfS1bRW++W0Q==
Received: from pxi11 (pxi11.prod.google.com [10.243.27.11]) by kpbe12.cbf.corp.google.com with ESMTP id oB9CkpgQ016342 for ; Thu, 9 Dec 2010 04:46:52 -0800
Received: by pxi11 with SMTP id 11so678317pxi.21 for ; Thu, 09 Dec 2010 04:46:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=JiOc/m8POFK7LzWNJwOvGfHVmsdD6f5Qyny4xf5mXUg=; b=qyQSaHoY9n2Cu1Wq+JTlwl+YIi6pZqge3VP3B6bafcUkBQtiVjIa1HZgQlaP0rz4Oi 8GRngMivgmIV6yldaUxQ==
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=C3yz1/qIkKd0RCWQ72NrE7AbNHclyXfrmu0Pw/hIrLKvs1kdrCl+I9s8govbhmpJ3R MCxL9IH2+1j0IM/eelqQ==
MIME-Version: 1.0
Received: by 10.142.98.3 with SMTP id v3mr3913206wfb.191.1291898811294; Thu, 09 Dec 2010 04:46:51 -0800 (PST)
Received: by 10.142.47.14 with HTTP; Thu, 9 Dec 2010 04:46:51 -0800 (PST)
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Thu, 9 Dec 2010 12:46:51 +0000
Message-ID:
From: Ben Laurie
To: Jay Daley
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
Cc: [email-masked]
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 09 Dec 2010 12:45:27 -0000

On 8 December 2010 23:05, Jay Daley wrote:
> On 6/12/2010, at 12:09 PM, Phillip Hallam-Baker wrote:
>> http://tools.ietf.org/html/draft-hallambaker-donotissue-01
>
> Some comments in no particular order:
>
> 1. =A0This would be better as a pointer to where the policy can be found =
rather than the contents of the policy itself, because:
> - the policy specification can be changed independently of the RR spec, t=
hereby reducing the frequency of changes to the RR
> - it puts an upper boundary on the amount of data added to the DNS for an=
y specific host
>
> =A0(As an aside, a standardised protocol for pulling policy would be very=
useful in a number of places).

If you are going to point at the policy then you'll need a way to
validate that the retrieved policy is indeed the one intended. A hash
of the policy in the DNS would be one way to achieve this - I am not
against the idea, but it needs to be optional.

> 2. =A0Given that this list is discussing keys in DNS, shouldn't this draf=
t be wider than just CAs and include policy relating to keys in DNS?

?? It does.

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3C343A69C5 for ; Wed, 8 Dec 2010 20:31:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3r9U6N2VEQAI for ; Wed, 8 Dec 2010 20:31:57 -0800 (PST)
Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id B95A83A69C2 for ; Wed, 8 Dec 2010 20:31:56 -0800 (PST)
Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 737FB2CE005 for ; Thu, 9 Dec 2010 17:33:27 +1300 (NZDT)
Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ti7y4NPIiGl8 for ; Thu, 9 Dec 2010 17:33:27 +1300 (NZDT)
Received: from [192.168.0.216] (cl-col-200-30-70-226.orbitel.net.co [200.30.70.226]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 5F61D2CE004 for ; Thu, 9 Dec 2010 17:33:25 +1300 (NZDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1082)
From: Jay Daley
In-Reply-To:
Date: Wed, 8 Dec 2010 23:33:20 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <[email-masked]>
References: <[email-masked]>
To: [email-masked]
X-Mailer: Apple Mail (2.1082)
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 09 Dec 2010 04:31:58 -0000

On 8/12/2010, at 6:39 PM, Phillip Hallam-Baker wrote:

>> 1. This would be better as a pointer to where the policy can be =
found rather than the contents of the policy itself, because:
>> - the policy specification can be changed independently of the RR =
spec, thereby reducing the frequency of changes to the RR
>> - it puts an upper boundary on the amount of data added to the DNS =
for any specific host
>>=20
>> (As an aside, a standardised protocol for pulling policy would be =
very useful in a number of places).
>=20
> This is not a proposal for providing machine readable policy. The
> Certification Policy is typically 100+ pages of legal text.
>=20
> There really is no value in pulling a CP or CPS automatically.
>=20
> I do have proposals for expressing machine readable protocol security
> policy, this is not such a proposal except to the extent that 'use
> policy X' is itself a security policy.

That's not an answer.

>> 2. Given that this list is discussing keys in DNS, shouldn't this =
draft be wider than just CAs and include policy relating to keys in DNS?
>=20
> As I said when I introduced this draft, some parts of the scheme are
> relevant to this WG, others may not be.

Neither is that.

>> 3. This bit seems particularly scary:
>>=20
>>> Since the policy is published at
>>> the Public Delegation Point, the policy applies to all =
subordinate
>>> domains under example.com.
>>=20
>> where a 'Public Delegation Point' is defined by:
>>=20
>>> Public Delegation Point A Domain Name that is obtained from a =
public
>>> DNS registry as defined by a Certification Policy.
>>=20
>> AFAICT the first quote appears to be saying that if a CA implicitly =
(the implicit nature is important) defines a domain as being a 'Public =
Delegation Point' by virtue of including it in a list of domains for =
whose subdomains certificates will be issued, then this CAA record will =
work at all points downward.
>>=20
>> That means that traversing up the tree only happens if the CP =
implicitly allows it (i.e. by listing an acceptable parent domain in the =
CP), which could be different for each CA. So you would potentially =
need to place multiple CAA records to cope with different CA CPs.
>=20
> Not unless you decided to deal with CAs that do not properly
> understand the structure of the domains in question.
>=20
> We may need to establish procedures to communicate that information
> more effectively between Registries and CAs. But in general, I don't
> think this has caused problems even with events like .co rebranding.

Nor that.

>> Also, what happens if you want to specify no certificate allowed at a =
delegation only domain, something many would consider? That doesn't =
work if there is no CA to specify and therefore no CP to choose. But =
assume for a second that this is not an issue and the CAA is respected - =
that would take out any certificates below that unless they too have a =
CAA that now allows a cert.
>>=20
>> Or are you suggesting that the default is not to issue unless there =
is a CAA record, thereby taking out the whole PKIX until these are =
provisioned?
>=20
> No, a CA ignores the CAA records unless the Extended Issuer
> Authorization Set is non-empty. So a site can advertise client
> restrictions without CA issue restrictions (or vice-versa)

Then the draft should say that.

>> 4. I haven't actually found a specific "no CA allowed" but I presume =
that can be one by a blank/fake OID?
>=20
> We can easily add a null policy if this is a real need.
>=20
> Or it might be better to simply introduce a 'null' property and mark
> it critical and relevant to the issuer.

Either will do.

Jay

--=20
Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 678840

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C3A63A698E for ; Wed, 8 Dec 2010 15:38:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.257
X-Spam-Level:
X-Spam-Status: No, score=-3.257 tagged_above=-999 required=5 tests=[AWL=0.342, 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 evAV2BBCYXNQ for ; Wed, 8 Dec 2010 15:37:59 -0800 (PST)
Received: from mail-gw0-f42.google.com (mail-gw0-f42.google.com [74.125.83.42]) by core3.amsl.com (Postfix) with ESMTP id 72CFE3A68BA for ; Wed, 8 Dec 2010 15:37:59 -0800 (PST)
Received: by gwb20 with SMTP id 20so1625124gwb.15 for ; Wed, 08 Dec 2010 15:39:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=kJtNgpO2tBtRARElWZeuASnOZqJg4yZpFLVK4jBVRNs=; b=L3g9SsxB5BlIaazZTcxvI429E5rDjQiePAwlV+d0SMoeHv8fb4nStrD+fZQX33J3yI A34WW+4Zdml51Q3MqL1sc07D5Fh8JxKxvC3IH4XWUOK1OopZoUwU7s4y3O1K1GJObwky J2JoE+2lFR/zlOuIMT97fUshFBynWNenKoWrs=
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:content-transfer-encoding; b=UV9MDMH8zSrmVkW+jHwyH8wfGC4jcDJnvVnkskKRxcN1SbWyJeM+h6vN+qQn+ETgF+ vgSXtcDBMwI8kz2gTRhosNIAr3MbHy5jpMHzN5ucn05k8INrMJom1/mi1wUUxLZgt7Jo pOVtak5hUV80I692OErubLrPNfldplt6lIDM4=
MIME-Version: 1.0
Received: by 10.100.225.7 with SMTP id x7mr6356486ang.69.1291851566347; Wed, 08 Dec 2010 15:39:26 -0800 (PST)
Received: by 10.101.103.14 with HTTP; Wed, 8 Dec 2010 15:39:26 -0800 (PST)
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Wed, 8 Dec 2010 18:39:26 -0500
Message-ID:
From: Phillip Hallam-Baker
To: Jay Daley
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: [email-masked]
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 08 Dec 2010 23:38:01 -0000

On Wed, Dec 8, 2010 at 6:05 PM, Jay Daley wrote:
> On 6/12/2010, at 12:09 PM, Phillip Hallam-Baker wrote:
>
>> All, a new version of CAA is available. This has been developed with
>> the aid of Ben Laurie and others at Google. This is an EXPERIMENTAL
>> proposal and is not intended to pre-empt or foreclose discussion here.
>>
>> http://tools.ietf.org/html/draft-hallambaker-donotissue-01
>
> Some comments in no particular order:
>
> 1. =A0This would be better as a pointer to where the policy can be found =
rather than the contents of the policy itself, because:
> - the policy specification can be changed independently of the RR spec, t=
hereby reducing the frequency of changes to the RR
> - it puts an upper boundary on the amount of data added to the DNS for an=
y specific host
>
> =A0(As an aside, a standardised protocol for pulling policy would be very=
useful in a number of places).

This is not a proposal for providing machine readable policy. The
Certification Policy is typically 100+ pages of legal text.

There really is no value in pulling a CP or CPS automatically.

I do have proposals for expressing machine readable protocol security
policy, this is not such a proposal except to the extent that 'use
policy X' is itself a security policy.

> 2. =A0Given that this list is discussing keys in DNS, shouldn't this draf=
t be wider than just CAs and include policy relating to keys in DNS?

As I said when I introduced this draft, some parts of the scheme are
relevant to this WG, others may not be.

> 3. =A0This bit seems particularly scary:
>
>> Since the policy is published at
>> =A0 =A0the Public Delegation Point, the policy applies to all subordinat=
e
>> =A0 =A0domains under example.com.
>
> where a 'Public Delegation Point' is defined by:
>
>> =A0 =A0Public Delegation Point =A0A Domain Name that is obtained from a =
public
>> =A0 =A0 =A0 DNS registry as defined by a Certification Policy.
>
> AFAICT the first quote appears to be saying that if a CA implicitly (the =
implicit nature is important) defines a domain as being a 'Public Delegatio=
n Point' by virtue of including it in a list of domains for whose subdomain=
s certificates will be issued, then this CAA record will work at all points=
downward.
>
> That means that traversing up the tree only happens if the CP implicitly =
allows it (i.e. by listing an acceptable parent domain in the CP), which co=
uld be different for each CA. =A0So you would potentially need to place mul=
tiple CAA records to cope with different CA CPs.

Not unless you decided to deal with CAs that do not properly
understand the structure of the domains in question.

We may need to establish procedures to communicate that information
more effectively between Registries and CAs. But in general, I don't
think this has caused problems even with events like .co rebranding.

> Also, what happens if you want to specify no certificate allowed at a del=
egation only domain, something many would consider? =A0That doesn't work if=
there is no CA to specify and therefore no CP to choose. =A0But assume for=
a second that this is not an issue and the CAA is respected - that would t=
ake out any certificates below that unless they too have a CAA that now all=
ows a cert.
>
> Or are you suggesting that the default is not to issue unless there is a =
CAA record, thereby taking out the whole PKIX until these are provisioned?

No, a CA ignores the CAA records unless the Extended Issuer
Authorization Set is non-empty. So a site can advertise client
restrictions without CA issue restrictions (or vice-versa)

> 4. =A0I haven't actually found a specific "no CA allowed" but I presume t=
hat can be one by a blank/fake OID?

We can easily add a null policy if this is a real need.

Or it might be better to simply introduce a 'null' property and mark
it critical and relevant to the issuer.

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

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCE473A69AF for ; Wed, 8 Dec 2010 15:03:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5SmEPU+IBBX8 for ; Wed, 8 Dec 2010 15:03:40 -0800 (PST)
Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id 883F43A69AA for ; Wed, 8 Dec 2010 15:03:40 -0800 (PST)
Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id D9ED52CE005 for ; Thu, 9 Dec 2010 12:05:10 +1300 (NZDT)
Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h54wbzufgA1R for ; Thu, 9 Dec 2010 12:05:10 +1300 (NZDT)
Received: from [192.168.0.250] (cl-col-200-30-70-226.orbitel.net.co [200.30.70.226]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id A7EB92CE004 for ; Thu, 9 Dec 2010 12:05:09 +1300 (NZDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1082)
From: Jay Daley
In-Reply-To:
Date: Wed, 8 Dec 2010 18:05:02 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <[email-masked]>
References:
To: [email-masked]
X-Mailer: Apple Mail (2.1082)
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 08 Dec 2010 23:03:42 -0000

On 6/12/2010, at 12:09 PM, Phillip Hallam-Baker wrote:

> All, a new version of CAA is available. This has been developed with
> the aid of Ben Laurie and others at Google. This is an EXPERIMENTAL
> proposal and is not intended to pre-empt or foreclose discussion here.
>=20
> http://tools.ietf.org/html/draft-hallambaker-donotissue-01

Some comments in no particular order:

1. This would be better as a pointer to where the policy can be found =
rather than the contents of the policy itself, because:
- the policy specification can be changed independently of the RR spec, =
thereby reducing the frequency of changes to the RR
- it puts an upper boundary on the amount of data added to the DNS for =
any specific host

(As an aside, a standardised protocol for pulling policy would be very =
useful in a number of places). =20

2. Given that this list is discussing keys in DNS, shouldn't this draft =
be wider than just CAs and include policy relating to keys in DNS?

3. This bit seems particularly scary:

> Since the policy is published at
> the Public Delegation Point, the policy applies to all subordinate
> domains under example.com.

where a 'Public Delegation Point' is defined by:

> Public Delegation Point A Domain Name that is obtained from a =
public
> DNS registry as defined by a Certification Policy.

AFAICT the first quote appears to be saying that if a CA implicitly (the =
implicit nature is important) defines a domain as being a 'Public =
Delegation Point' by virtue of including it in a list of domains for =
whose subdomains certificates will be issued, then this CAA record will =
work at all points downward.=20

That means that traversing up the tree only happens if the CP implicitly =
allows it (i.e. by listing an acceptable parent domain in the CP), which =
could be different for each CA. So you would potentially need to place =
multiple CAA records to cope with different CA CPs.

Also, what happens if you want to specify no certificate allowed at a =
delegation only domain, something many would consider? That doesn't =
work if there is no CA to specify and therefore no CP to choose. But =
assume for a second that this is not an issue and the CAA is respected - =
that would take out any certificates below that unless they too have a =
CAA that now allows a cert.

Or are you suggesting that the default is not to issue unless there is a =
CAA record, thereby taking out the whole PKIX until these are =
provisioned?

4. I haven't actually found a specific "no CA allowed" but I presume =
that can be one by a blank/fake OID?

Jay

--=20
Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 678840

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5260D3A698C for ; Wed, 8 Dec 2010 10:20:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.181
X-Spam-Level:
X-Spam-Status: No, score=-2.181 tagged_above=-999 required=5 tests=[AWL=0.418, 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 txMDDWisTfbp for ; Wed, 8 Dec 2010 10:19:57 -0800 (PST)
Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id 5C2CB3A6988 for ; Wed, 8 Dec 2010 10:19:54 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=GMZ3CYxFtQOx062xCis+Mt8WBOdTdBggxlsP0Kpl70I3iHE5U1NZW5iw2C6PKgjJ; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.31] (helo=elwamui-chisos.atl.sa.earthlink.net) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1PQOdk-0003kL-Ko for [email-masked]; Wed, 08 Dec 2010 13:21:20 -0500
Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Wed, 8 Dec 2010 12:49:14 -0500
Message-ID: <[email-masked]>
Date: Wed, 8 Dec 2010 11:49:14 -0600 (GMT-06:00)
From: "Jeffrey A. Williams"
To: "[email-masked]"
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e5196068800b0b36215f860ea570e03fe759b9f1c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.31
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: "Jeffrey A. Williams"
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 08 Dec 2010 18:20:36 -0000

Carl and all,

Perhaps there is some interest that ONLY CA's can determine
any or all policies on cert issuance is the only answer I can
think of at the moment. There is some value in such a change
in policy and practice, but I doubt that it would be well
recieved.

-----Original Message-----
>From: Carl Wallace
>Sent: Dec 8, 2010 12:12 PM
>To: Phillip Hallam-Baker
>Cc: [email-masked]
>Subject: Re: [keyassure] Revised version of CAA
>
>Why is it impractical for the CA to issue a certificate with the requested=
policy? It should be no harder to get the policy right than it is to get =
the CA key right. You could simply read the policies from the CA certifica=
te and avoid requesting a policy that the CA can't issue. =20
>
>> -----Original Message-----
>> From: Phillip Hallam-Baker [mailto:[email-masked]]
>> Sent: Wednesday, December 08, 2010 1:07 PM
>> To: Carl Wallace
>> Cc: Ben Laurie; Nicholas Weaver; [email-masked]; PaulHoffman
>> Subject: Re: [keyassure] Revised version of CAA
>>=20
>> I don't want to propagate reliance on lore, but I do want the exit strat=
egy to
>> be as painless as possible.
>>=20
>> In steady state this should be pretty easy to maintain. And I think that=
we will
>> naturally move to making the binding more specific over time. But having
>> gone through similar transitions, I do not want to push for something th=
at
>> ends up being too strict.
>>=20
>> My preference would to be to do RP enforcement on the basis of certs or
>> keys. Getting to the point where that is practical may require building
>> additional support infrastructure such as maintenance protocols. But tha=
t is
>> not something that should be in the critical path here.
>>=20
>>=20
>> On Wed, Dec 8, 2010 at 12:15 PM, Carl Wallace
>> wrote:
>> >> OK, how about the following:
>> >>
>> >> 1) If the policy property is marked for issue, an issuer is entitled
>> > to issue any
>> >> certificate that is consistent with that policy.
>> >
>> > Why is it important to allow the CA to assert a different policy than
>> > the client requested?
>> >
>> >> 2) If marked for client enforcement, the certificate must either
>> > contain the
>> >> specified OID or know it to be consistent with the specified OID by
>> > other
>> >> means.
>> >
>> > I do not understand what this buys the relying party.
>> >
>> >> My preference would be to use the path property for client
>> > enforcement.
>> >> But 'must use EV' is an important subset.
>> >
>> > If you don't want to enforce policy on the relying party, don't. =C2=
=A0At
>> > present, there's an example for doing this.
>> >
>> >> If people really want to dig, it is not difficult to throw up corner
>> > cases on the
>> >> client enforcement side. My belief is that it is going to be
>> > relatively easy to
>> >> deal with these in practice because there is no particular value in a
>> > lot of the
>> >> complexity that has arisen, people just do things in different ways
>> > because
>> >> there was no particular reason not to.
>> >>
>> >> Deployment of CAA will cause issuers to look to rationalize their
>> > activities
>> >> which will in turn make the client enforcement side much easier to
>> > deal with.
>> >
>> > I think this implies an answer to my question above. =C2=A0Maybe there=
's
>> > some way to address composite EV/OV/DV usage during this
>> > rationalization process.
>> >
>> >> Unfortunately, a great deal of the complexity here is lore rather
>> > something
>> >> that is written down in one place. As a CA, I am only really aware of
>> > the lore
>> >> that affects my products. And I am pretty sure that my competitors
>> > don't
>> >> want me to understand the issues that might arise from their lore.
>> >
>> > No need to propagate reliance on lore. =C2=A0This doesn't seem particu=
larly
>> > complicated. =C2=A0There are a set of policy identifiers that indicate=
EV.
>> > An application must recognize these policies, use a trust anchor store
>> > with a set of trust anchors authorized for these policies and validate
>> > server certs to this trust anchor store to ensure it is valid under an
>> > EV policy. =C2=A0This spec provides pre-issuance processing (and possi=
bly
>> > some additional relying party checks), RFC 5280 and RFC 5937 define
>> > path processing from TA through server certificate.
>> >
>> >> So the traditional way we deal with this is to put a proposal on the
>> > table and
>> >> see who squawks. Then we adjust the proposal until everyone can live
>> > with
>> >> it.
>> >
>> > Fair enough.
>> >
>>=20
>>=20
>>=20
>> --
>> Website: http://hallambaker.com/
>_______________________________________________
>keyassure mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/keyassure

Regards,
Jeffrey A. Williams
"Obedience of the law is the greatest freedom" -
Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liabilit=
y
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947]
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Updated 1/26/04
Network Eng. SR. Eng. Network data security
ABA member in good standing member ID 01257402=20
E-Mail [email-masked]
Phone: 214-244-4827

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C38C3A6929 for ; Wed, 8 Dec 2010 10:11:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 vbegVzMfPGwY for ; Wed, 8 Dec 2010 10:11:38 -0800 (PST)
Received: from mail55.messagelabs.com (mail55.messagelabs.com [216.82.241.163]) by core3.amsl.com (Postfix) with SMTP id D046A3A6860 for ; Wed, 8 Dec 2010 10:11:35 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [email-masked]
X-Msg-Ref: server-8.tower-55.messagelabs.com!1291831946!113448563!1
X-StarScan-Version: 6.2.9; banners=-,-,-
X-Originating-IP: [65.242.48.8]
Received: (qmail 14670 invoked from network); 8 Dec 2010 18:12:26 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (65.242.48.8) by server-8.tower-55.messagelabs.com with SMTP; 8 Dec 2010 18:12:26 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Wed, 8 Dec 2010 13:12:24 -0500
Message-ID:
In-Reply-To:
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [keyassure] Revised version of CAA
Thread-Index: AcuXAqhFVk0Eds6iQz+vVMAGkPAoLAAADjmA
References: <[email-masked]>
From: "Carl Wallace"
To: "Phillip Hallam-Baker"
Cc: [email-masked]
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 08 Dec 2010 18:11:48 -0000

Why is it impractical for the CA to issue a certificate with the =
requested policy? It should be no harder to get the policy right than =
it is to get the CA key right. You could simply read the policies from =
the CA certificate and avoid requesting a policy that the CA can't =
issue. =20

> -----Original Message-----
> From: Phillip Hallam-Baker [mailto:[email-masked]]
> Sent: Wednesday, December 08, 2010 1:07 PM
> To: Carl Wallace
> Cc: Ben Laurie; Nicholas Weaver; [email-masked]; PaulHoffman
> Subject: Re: [keyassure] Revised version of CAA
>=20
> I don't want to propagate reliance on lore, but I do want the exit =
strategy to
> be as painless as possible.
>=20
> In steady state this should be pretty easy to maintain. And I think =
that we will
> naturally move to making the binding more specific over time. But =
having
> gone through similar transitions, I do not want to push for something =
that
> ends up being too strict.
>=20
> My preference would to be to do RP enforcement on the basis of certs =
or
> keys. Getting to the point where that is practical may require =
building
> additional support infrastructure such as maintenance protocols. But =
that is
> not something that should be in the critical path here.
>=20
>=20
> On Wed, Dec 8, 2010 at 12:15 PM, Carl Wallace
> wrote:
> >> OK, how about the following:
> >>
> >> 1) If the policy property is marked for issue, an issuer is =
entitled
> > to issue any
> >> certificate that is consistent with that policy.
> >
> > Why is it important to allow the CA to assert a different policy =
than
> > the client requested?
> >
> >> 2) If marked for client enforcement, the certificate must either
> > contain the
> >> specified OID or know it to be consistent with the specified OID by
> > other
> >> means.
> >
> > I do not understand what this buys the relying party.
> >
> >> My preference would be to use the path property for client
> > enforcement.
> >> But 'must use EV' is an important subset.
> >
> > If you don't want to enforce policy on the relying party, don't. =
=A0At
> > present, there's an example for doing this.
> >
> >> If people really want to dig, it is not difficult to throw up =
corner
> > cases on the
> >> client enforcement side. My belief is that it is going to be
> > relatively easy to
> >> deal with these in practice because there is no particular value in =
a
> > lot of the
> >> complexity that has arisen, people just do things in different ways
> > because
> >> there was no particular reason not to.
> >>
> >> Deployment of CAA will cause issuers to look to rationalize their
> > activities
> >> which will in turn make the client enforcement side much easier to
> > deal with.
> >
> > I think this implies an answer to my question above. =A0Maybe =
there's
> > some way to address composite EV/OV/DV usage during this
> > rationalization process.
> >
> >> Unfortunately, a great deal of the complexity here is lore rather
> > something
> >> that is written down in one place. As a CA, I am only really aware =
of
> > the lore
> >> that affects my products. And I am pretty sure that my competitors
> > don't
> >> want me to understand the issues that might arise from their lore.
> >
> > No need to propagate reliance on lore. =A0This doesn't seem =
particularly
> > complicated. =A0There are a set of policy identifiers that indicate =
EV.
> > An application must recognize these policies, use a trust anchor =
store
> > with a set of trust anchors authorized for these policies and =
validate
> > server certs to this trust anchor store to ensure it is valid under =
an
> > EV policy. =A0This spec provides pre-issuance processing (and =
possibly
> > some additional relying party checks), RFC 5280 and RFC 5937 define
> > path processing from TA through server certificate.
> >
> >> So the traditional way we deal with this is to put a proposal on =
the
> > table and
> >> see who squawks. Then we adjust the proposal until everyone can =
live
> > with
> >> it.
> >
> > Fair enough.
> >
>=20
>=20
>=20
> --
> Website: http://hallambaker.com/

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB54C3A6961 for ; Wed, 8 Dec 2010 10:05:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.229
X-Spam-Level:
X-Spam-Status: No, score=-3.229 tagged_above=-999 required=5 tests=[AWL=0.371, 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 rc-s5GtpSbnA for ; Wed, 8 Dec 2010 10:05:08 -0800 (PST)
Received: from mail-gw0-f42.google.com (mail-gw0-f42.google.com [74.125.83.42]) by core3.amsl.com (Postfix) with ESMTP id 3A6AA3A6967 for ; Wed, 8 Dec 2010 10:05:08 -0800 (PST)
Received: by gwb20 with SMTP id 20so1289101gwb.15 for ; Wed, 08 Dec 2010 10:06:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=EFabHLKyi/SEb2itrlvGPCYyyhhP8YYwEwSv/TZ5GPg=; b=ptGA0iLChqgh40MGegOg6Vl9RTU3Mmd+eGNGPiomZLq/bCq6OVcHUUewjH5qDnhojz 8dSG+duK5IvTT2825gre15sLyYhL3asgU26uYVm87pgOWz5mcYt+ncv24ee0k70uKSfv F9joFcRYnNFdRbyCmP/gRj5x6bfg9/5uDGLQI=
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:content-transfer-encoding; b=S2HTK73n4exFKMsSTkD3UDpwL/bij7hLVD+Xunr4UHt02PNAcZuEOvEII8qbKqD7ht J4oQ9auS9N+ER1Yz+h///1Fc9ZfxZSOCPvsz2uwssqQyiaPr4u4VvyNCLhsjC2tR52qK lZ3AURNYg80+nGYDJyv2/wYJdRjnMvLgdMQtk=
MIME-Version: 1.0
Received: by 10.101.163.35 with SMTP id q35mr6130364ano.171.1291831595692; Wed, 08 Dec 2010 10:06:35 -0800 (PST)
Received: by 10.101.103.14 with HTTP; Wed, 8 Dec 2010 10:06:35 -0800 (PST)
In-Reply-To:
References: <[email-masked]>
Date: Wed, 8 Dec 2010 13:06:35 -0500
Message-ID:
From: Phillip Hallam-Baker
To: Carl Wallace
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: PaulHoffman , [email-masked]
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 08 Dec 2010 18:05:09 -0000

I don't want to propagate reliance on lore, but I do want the exit
strategy to be as painless as possible.

In steady state this should be pretty easy to maintain. And I think
that we will naturally move to making the binding more specific over
time. But having gone through similar transitions, I do not want to
push for something that ends up being too strict.

My preference would to be to do RP enforcement on the basis of certs
or keys. Getting to the point where that is practical may require
building additional support infrastructure such as maintenance
protocols. But that is not something that should be in the critical
path here.

On Wed, Dec 8, 2010 at 12:15 PM, Carl Wallace wrote=
:
>> OK, how about the following:
>>
>> 1) If the policy property is marked for issue, an issuer is entitled
> to issue any
>> certificate that is consistent with that policy.
>
> Why is it important to allow the CA to assert a different policy than
> the client requested?
>
>> 2) If marked for client enforcement, the certificate must either
> contain the
>> specified OID or know it to be consistent with the specified OID by
> other
>> means.
>
> I do not understand what this buys the relying party.
>
>> My preference would be to use the path property for client
> enforcement.
>> But 'must use EV' is an important subset.
>
> If you don't want to enforce policy on the relying party, don't. =A0At
> present, there's an example for doing this.
>
>> If people really want to dig, it is not difficult to throw up corner
> cases on the
>> client enforcement side. My belief is that it is going to be
> relatively easy to
>> deal with these in practice because there is no particular value in a
> lot of the
>> complexity that has arisen, people just do things in different ways
> because
>> there was no particular reason not to.
>>
>> Deployment of CAA will cause issuers to look to rationalize their
> activities
>> which will in turn make the client enforcement side much easier to
> deal with.
>
> I think this implies an answer to my question above. =A0Maybe there's som=
e
> way to address composite EV/OV/DV usage during this rationalization
> process.
>
>> Unfortunately, a great deal of the complexity here is lore rather
> something
>> that is written down in one place. As a CA, I am only really aware of
> the lore
>> that affects my products. And I am pretty sure that my competitors
> don't
>> want me to understand the issues that might arise from their lore.
>
> No need to propagate reliance on lore. =A0This doesn't seem particularly
> complicated. =A0There are a set of policy identifiers that indicate EV.
> An application must recognize these policies, use a trust anchor store
> with a set of trust anchors authorized for these policies and validate
> server certs to this trust anchor store to ensure it is valid under an
> EV policy. =A0This spec provides pre-issuance processing (and possibly
> some additional relying party checks), RFC 5280 and RFC 5937 define path
> processing from TA through server certificate.
>
>> So the traditional way we deal with this is to put a proposal on the
> table and
>> see who squawks. Then we adjust the proposal until everyone can live
> with
>> it.
>
> Fair enough.
>

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

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D83E33A6849 for ; Wed, 8 Dec 2010 09:14:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 bloV+NkpNUSC for ; Wed, 8 Dec 2010 09:14:35 -0800 (PST)
Received: from mail165.messagelabs.com (mail165.messagelabs.com [216.82.253.147]) by core3.amsl.com (Postfix) with SMTP id 89C833A681E for ; Wed, 8 Dec 2010 09:14:34 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [email-masked]
X-Msg-Ref: server-9.tower-165.messagelabs.com!1291828559!39967971!1
X-StarScan-Version: 6.2.9; banners=-,-,-
X-Originating-IP: [65.242.48.8]
Received: (qmail 27610 invoked from network); 8 Dec 2010 17:15:59 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (65.242.48.8) by server-9.tower-165.messagelabs.com with SMTP; 8 Dec 2010 17:15:59 -0000
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: Wed, 8 Dec 2010 12:15:56 -0500
Message-ID:
In-Reply-To:
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [keyassure] Revised version of CAA
Thread-Index: AcuW76JLFkoXRQZnR8a1UgCn0Zvu6wACP0CA
References: <[email-masked]>
From: "Carl Wallace"
To: "Phillip Hallam-Baker"
Cc: PaulHoffman , [email-masked]
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 08 Dec 2010 17:14:36 -0000

> OK, how about the following:
>=20
> 1) If the policy property is marked for issue, an issuer is entitled
to issue any
> certificate that is consistent with that policy.

Why is it important to allow the CA to assert a different policy than
the client requested? =20
=20
> 2) If marked for client enforcement, the certificate must either
contain the
> specified OID or know it to be consistent with the specified OID by
other
> means.

I do not understand what this buys the relying party. =20
=20
> My preference would be to use the path property for client
enforcement.
> But 'must use EV' is an important subset.

If you don't want to enforce policy on the relying party, don't. At
present, there's an example for doing this.
=20
> If people really want to dig, it is not difficult to throw up corner
cases on the
> client enforcement side. My belief is that it is going to be
relatively easy to
> deal with these in practice because there is no particular value in a
lot of the
> complexity that has arisen, people just do things in different ways
because
> there was no particular reason not to.
>
> Deployment of CAA will cause issuers to look to rationalize their
activities
> which will in turn make the client enforcement side much easier to
deal with.

I think this implies an answer to my question above. Maybe there's some
way to address composite EV/OV/DV usage during this rationalization
process.
=20
> Unfortunately, a great deal of the complexity here is lore rather
something
> that is written down in one place. As a CA, I am only really aware of
the lore
> that affects my products. And I am pretty sure that my competitors
don't
> want me to understand the issues that might arise from their lore.

No need to propagate reliance on lore. This doesn't seem particularly
complicated. There are a set of policy identifiers that indicate EV.
An application must recognize these policies, use a trust anchor store
with a set of trust anchors authorized for these policies and validate
server certs to this trust anchor store to ensure it is valid under an
EV policy. This spec provides pre-issuance processing (and possibly
some additional relying party checks), RFC 5280 and RFC 5937 define path
processing from TA through server certificate.
=20
> So the traditional way we deal with this is to put a proposal on the
table and
> see who squawks. Then we adjust the proposal until everyone can live
with
> it.

Fair enough.

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B32283A6957 for ; Wed, 8 Dec 2010 07:48:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.217
X-Spam-Level:
X-Spam-Status: No, score=-3.217 tagged_above=-999 required=5 tests=[AWL=0.382, 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 TBxTVNBu5eGq for ; Wed, 8 Dec 2010 07:48:56 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 6CC0C3A6801 for ; Wed, 8 Dec 2010 07:48:56 -0800 (PST)
Received: by ywk9 with SMTP id 9so789026ywk.31 for ; Wed, 08 Dec 2010 07:50:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=xfQBatbc5XUWdZvL7PvpVtseOJRSpq5d1yJMu3WyPIE=; b=irC2PMEBaHBo09tYBXBJG3vVrdad3oxmXMMM+oa+0dFWW9Ap/TLPDV00+pr/M2CPD1 l2wJK5Lyq4IlFW6T7netNxm2q/+IRMQOBeXx4TgepnlMPYdGRlGgzdZhHZWOX/UFSpcV JOunNaKtoqr9n2JFlnbDr/UQNR7/LyF1yVE+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=in3rO0hyrsoyiUgei5KC0gdCczSbS6a/5Yj8AfOe8lPFDAtcic57txvKZ1D04ep6Ya UZeSNVQMyAsFja/+QIqRaIYwgnz7W6j9PUb5Bpsr7m9y4NcMN+rZQfUY+Ay/mwzzCWhd BUnMECXfYsEs75DZyi+juleHOq3cfembe2uMA=
MIME-Version: 1.0
Received: by 10.100.96.1 with SMTP id t1mr5557149anb.137.1291823423707; Wed, 08 Dec 2010 07:50:23 -0800 (PST)
Received: by 10.101.103.14 with HTTP; Wed, 8 Dec 2010 07:50:23 -0800 (PST)
In-Reply-To:
References: <[email-masked]>
Date: Wed, 8 Dec 2010 10:50:23 -0500
Message-ID:
From: Phillip Hallam-Baker
To: Carl Wallace
Content-Type: text/plain; charset=ISO-8859-1
Cc: PaulHoffman , [email-masked]
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 08 Dec 2010 15:48:57 -0000

OK, how about the following:

1) If the policy property is marked for issue, an issuer is entitled
to issue any certificate that is consistent with that policy.

2) If marked for client enforcement, the certificate must either
contain the specified OID or know it to be consistent with the
specified OID by other means.

My preference would be to use the path property for client
enforcement. But 'must use EV' is an important subset.

If people really want to dig, it is not difficult to throw up corner
cases on the client enforcement side. My belief is that it is going to
be relatively easy to deal with these in practice because there is no
particular value in a lot of the complexity that has arisen, people
just do things in different ways because there was no particular
reason not to.

Deployment of CAA will cause issuers to look to rationalize their
activities which will in turn make the client enforcement side much
easier to deal with.

Unfortunately, a great deal of the complexity here is lore rather
something that is written down in one place. As a CA, I am only really
aware of the lore that affects my products. And I am pretty sure that
my competitors don't want me to understand the issues that might arise
from their lore.

So the traditional way we deal with this is to put a proposal on the
table and see who squawks. Then we adjust the proposal until everyone
can live with it.

On Wed, Dec 8, 2010 at 9:44 AM, Carl Wallace wrote:
>> The browsers already have the logic an data required to recognize and
> enforce this.
>
> The browsers do not have the logic to enforce the policy property
> mechanism, which as currently written is not really enforceable (the
> addition of a MUST on the issuance side that Ben suggested would fix
> this).
>
>> If bogocert is trusted in the browser, and issues a cert with the
> Comodo EV oid, it will not be recognized as EV.
>
> You are discussing trust anchor issues that should be in this draft if
> enabling "must be EV" is a goal.
>
>> The prcise mechanisms are comlex and convoluted due to the
> accumulation of 15 years of barnacles and othe cruft. But they do exist.
> Thus it is practical
>> to enforce this specific policy in the client, but possibly not
> others.
>
> Including a reference would be helpful.
>
>> Note that a CA does not need to belong to CABrowser forum to issue EV
> certs, that is an issue with the auditors and coders of RP apps.
>
> It'd be nice if this mechanism were coupled with trust anchor
> constraints to enable folks to assert EV compliance for their own CAs,
> which could address the concern Paul Wouters previously stated.
>

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

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A84F03A6907 for ; Wed, 8 Dec 2010 06:42:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 nAevC-hSzk2i for ; Wed, 8 Dec 2010 06:42:49 -0800 (PST)
Received: from mail75.messagelabs.com (mail75.messagelabs.com [216.82.250.3]) by core3.amsl.com (Postfix) with SMTP id CC0263A6925 for ; Wed, 8 Dec 2010 06:42:49 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [email-masked]
X-Msg-Ref: server-11.tower-75.messagelabs.com!1291819456!59090990!1
X-StarScan-Version: 6.2.9; banners=-,-,-
X-Originating-IP: [65.242.48.8]
Received: (qmail 28330 invoked from network); 8 Dec 2010 14:44:16 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (65.242.48.8) by server-11.tower-75.messagelabs.com with SMTP; 8 Dec 2010 14:44:16 -0000
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: Wed, 8 Dec 2010 09:44:15 -0500
Message-ID:
In-Reply-To: <[email-masked]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [keyassure] Revised version of CAA
Thread-Index: AcuW350lKSbyoI1lTuqO1Q0J32afWgABKZpw
References: <[email-masked]>
From: "Carl Wallace"
To: "Phillip Hallam-Baker"
Cc: PaulHoffman , [email-masked]
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 08 Dec 2010 14:42:50 -0000

> The browsers already have the logic an data required to recognize and
enforce this.

The browsers do not have the logic to enforce the policy property
mechanism, which as currently written is not really enforceable (the
addition of a MUST on the issuance side that Ben suggested would fix
this). =20

> If bogocert is trusted in the browser, and issues a cert with the
Comodo EV oid, it will not be recognized as EV.

You are discussing trust anchor issues that should be in this draft if
enabling "must be EV" is a goal. =20

> The prcise mechanisms are comlex and convoluted due to the
accumulation of 15 years of barnacles and othe cruft. But they do exist.
Thus it is practical=20
> to enforce this specific policy in the client, but possibly not
others.

Including a reference would be helpful.

> Note that a CA does not need to belong to CABrowser forum to issue EV
certs, that is an issue with the auditors and coders of RP apps.

It'd be nice if this mechanism were coupled with trust anchor
constraints to enable folks to assert EV compliance for their own CAs,
which could address the concern Paul Wouters previously stated.

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 840BC3A6938 for ; Wed, 8 Dec 2010 05:54:18 -0800 (PST)
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 jZ4d79d8SaDO for ; Wed, 8 Dec 2010 05:54:17 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 9E2313A6783 for ; Wed, 8 Dec 2010 05:54:17 -0800 (PST)
Received: by ywk9 with SMTP id 9so711915ywk.31 for ; Wed, 08 Dec 2010 05:55:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:in-reply-to :mime-version:content-transfer-encoding:content-type:message-id:cc :x-mailer:from:subject:date:to; bh=cK/ZRdRWPClKpK797e5tBFZnI3sltmOhdVOA1OqHujo=; b=I3QNlNbKpYsT1jwcQOPTfo3uNb2EGxHxuTJr0M/IGVf17fmYTTt4ZXtMt7K3OiMzHH om5+ZGm7G/jAyVSbg1DOjbcN3LGMCfzqqoc6UepB3EpVcja7tcNb8LJyen0VRHG0VpyU XKKm+WdKDnX6ePPV0YUx0skBXSNs2kS/0iu9M=
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=CWTiodnbg6eN/jrfuJD3iPcVvTT+pkNEVSH5MW1Bh8Hh+2iFqej6zrhDv/ubU8Rn2V g0JVrpPQMInSqKYBaMwIQd6E4ZaHZFZIJpplkmFYmqflt84mo8dVG4eDtj62Vf8szOjI aork1AOss28Zw4WDCketeydq1T2yU93oymo0c=
Received: by 10.150.52.8 with SMTP id z8mr4007091ybz.401.1291816543526; Wed, 08 Dec 2010 05:55:43 -0800 (PST)
Received: from [10.51.46.12] (mobile-166-137-139-250.mycingular.net [166.137.139.250]) by mx.google.com with ESMTPS id r6sm921316yba.11.2010.12.08.05.55.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 08 Dec 2010 05:55:42 -0800 (PST)
References: <[email-masked]>
In-Reply-To:
Mime-Version: 1.0 (iPad Mail 8C148)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=us-ascii
Message-Id: <[email-masked]>
X-Mailer: iPad Mail (8C148)
From: Phillip Hallam-Baker
Date: Wed, 8 Dec 2010 08:55:32 -0500
To: Carl Wallace
Cc: PaulHoffman , ""
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 08 Dec 2010 13:54:18 -0000

The browsers already have the logic an data required to recognize and enforc=
e this.

If bogocert is trusted in the browser, and issues a cert with the Comodo EV o=
id, it will not be recognized as EV.

The prcise mechanisms are comlex and convoluted due to the accumulation of 1=
5 years of barnacles and othe cruft. But they do exist. Thus it is practical=
to enforce this specific policy in the client, but possibly not others.

Note that a CA does not need to belong to CABrowser forum to issue EV certs,=
that is an issue with the auditors and coders of RP apps.

Sent from my iPad

On Dec 8, 2010, at 8:33 AM, "Carl Wallace" wrote:

>> Clearly "must use EV" is different from "must use CA X" (where, say, X
> doesn't issue EV certs) in that the certs are ... EV certs. In terms of
> how you
>> express them as CAA RRs they probably look exceedingly similar.
>=20
> How does the "must use EV" feature work? I am assuming this is derived
> from the policy property mechanism but relying party usage of that
> mechanism is not clear to me. Section 2.1 provides the following
> example:
>=20
> In the following example, certificates must not be issued except
> under the Default Deny Security 'Example 1' Certificate Policy and
> Relying Party Applications MAY reject certificates presented that do
> not comply with this requirement:
>=20
> $ORIGIN example.com
> . CAA 3 policy 1.3.6.1.4.1.35405.666.1
>=20
> Section 3.1.2 states the following:
>=20
> The Certificate that is issued MAY incorporate the specified policy
> OID itself but is not required to provided that the issue of the
> certificate is consistent with the requirements of the specified
> policy.
>=20
> Since there is no requirement for the policy to be included in the
> certificate, what should a relying party use to do this enforcement? =20

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76D393A6783 for ; Wed, 8 Dec 2010 05:40:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.977
X-Spam-Level:
X-Spam-Status: No, score=-109.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_HI=-8, 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 htvpNTriBdrr for ; Wed, 8 Dec 2010 05:40:35 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 9BCEC3A6921 for ; Wed, 8 Dec 2010 05:40:35 -0800 (PST)
Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id oB8Dg1eS001002 for ; Wed, 8 Dec 2010 05:42:01 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1291815722; bh=bys8gz1q7bz1GlAeRVcWIcrzV6E=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=hx+r8jSNRBRtc7Zrls44hVHCyvHm2PSH754LL/CVRtBY1JrlX6Ac/MgSKAgrTV4mI xWePY71nKwgjcAFSwEcjA==
Received: from pwj10 (pwj10.prod.google.com [10.241.219.74]) by kpbe14.cbf.corp.google.com with ESMTP id oB8Dfm6H006345 for ; Wed, 8 Dec 2010 05:42:00 -0800
Received: by pwj10 with SMTP id 10so254201pwj.30 for ; Wed, 08 Dec 2010 05:42:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=RcNaGk370GIcFdof/Nqus26aQf19iI+fE++GjGynaPU=; b=W7jyxPC1kskNxE8WFl1m0EBqKT44OjoF07E/L8Dul7VzyeWOT1CrIRZ5hdk7MG6UMP kTnZT6+HYcZtHm/o3igQ==
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=PgyWD/vcw3+8VDJfRhAq3dxrvviC9iWBlNEBrYDKcc5698iL1aqXz0EjQsc9nmGe5l DY7C2onRNdDVRwqAu7jw==
MIME-Version: 1.0
Received: by 10.142.246.11 with SMTP id t11mr2488976wfh.362.1291815719395; Wed, 08 Dec 2010 05:41:59 -0800 (PST)
Received: by 10.143.18.14 with HTTP; Wed, 8 Dec 2010 05:41:59 -0800 (PST)
In-Reply-To:
References: <[email-masked]>
Date: Wed, 8 Dec 2010 13:41:59 +0000
Message-ID:
From: Ben Laurie
To: Carl Wallace
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
Cc: [email-masked], Paul Hoffman , Phillip Hallam-Baker
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 08 Dec 2010 13:40:37 -0000

On 8 December 2010 13:33, Carl Wallace wrote:
>> Clearly "must use EV" is different from "must use CA X" (where, say, X
> doesn't issue EV certs) in that the certs are ... EV certs. In terms of
> how you
>> express them as CAA RRs they probably look exceedingly similar.
>
> How does the "must use EV" feature work? =A0I am assuming this is derived
> from the policy property mechanism but relying party usage of that
> mechanism is not clear to me. =A0Section 2.1 provides the following
> example:
>
> =A0 In the following example, certificates must not be issued except
> =A0 under the Default Deny Security 'Example 1' Certificate Policy and
> =A0 Relying Party Applications MAY reject certificates presented that do
> =A0 not comply with this requirement:
>
> =A0 $ORIGIN example.com
> =A0 . =A0 =A0 =A0 CAA 3 policy 1.3.6.1.4.1.35405.666.1
>
> Section 3.1.2 states the following:
>
> =A0 The Certificate that is issued MAY incorporate the specified policy
> =A0 OID itself but is not required to provided that the issue of the
> =A0 certificate is consistent with the requirements of the specified
> =A0 policy.
>
> Since there is no requirement for the policy to be included in the
> certificate, what should a relying party use to do this enforcement?

Good point. I guess we should change that to a MUST.

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B99583A6948 for ; Wed, 8 Dec 2010 05:32:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, 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 CMAkXUqcagAQ for ; Wed, 8 Dec 2010 05:32:05 -0800 (PST)
Received: from mail73.messagelabs.com (mail73.messagelabs.com [216.82.249.243]) by core3.amsl.com (Postfix) with SMTP id E5A3C3A693D for ; Wed, 8 Dec 2010 05:32:02 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: [email-masked]
X-Msg-Ref: server-6.tower-73.messagelabs.com!1291815203!52654687!1
X-StarScan-Version: 6.2.9; banners=-,-,-
X-Originating-IP: [65.242.48.8]
Received: (qmail 29033 invoked from network); 8 Dec 2010 13:33:23 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (65.242.48.8) by server-6.tower-73.messagelabs.com with SMTP; 8 Dec 2010 13:33:23 -0000
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: Wed, 8 Dec 2010 08:33:22 -0500
Message-ID:
In-Reply-To:
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [keyassure] Revised version of CAA
Thread-Index: AcuWxXpMoNRTD1nHQAyoPwoUAukkFwAE6eGg
References: <[email-masked]>
From: "Carl Wallace"
To: "Ben Laurie" , "Nicholas Weaver"
Cc: Phillip Hallam-Baker , [email-masked], Paul Hoffman
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 08 Dec 2010 13:32:06 -0000

> Clearly "must use EV" is different from "must use CA X" (where, say, X
doesn't issue EV certs) in that the certs are ... EV certs. In terms of
how you
> express them as CAA RRs they probably look exceedingly similar.

How does the "must use EV" feature work? I am assuming this is derived
from the policy property mechanism but relying party usage of that
mechanism is not clear to me. Section 2.1 provides the following
example:

In the following example, certificates must not be issued except
under the Default Deny Security 'Example 1' Certificate Policy and
Relying Party Applications MAY reject certificates presented that do
not comply with this requirement:

$ORIGIN example.com
. CAA 3 policy 1.3.6.1.4.1.35405.666.1

Section 3.1.2 states the following:

The Certificate that is issued MAY incorporate the specified policy
OID itself but is not required to provided that the issue of the
certificate is consistent with the requirements of the specified
policy.

Since there is no requirement for the policy to be included in the
certificate, what should a relying party use to do this enforcement? =20

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7D183A68D4 for ; Wed, 8 Dec 2010 02:47:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.977
X-Spam-Level:
X-Spam-Status: No, score=-109.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_HI=-8, 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 22kbwldexv78 for ; Wed, 8 Dec 2010 02:47:10 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id BD6473A68A4 for ; Wed, 8 Dec 2010 02:47:09 -0800 (PST)
Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id oB8AmZhi029180 for ; Wed, 8 Dec 2010 02:48:35 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1291805316; bh=O15d+fMlZmn+F0vkw1YBklPd5UQ=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=HeLG7T1f6tERSzFpnDgqqhkYt1dRoSZU+N+ilf1IP6lchv2c5flpl2IkFDceR/xNg 05joA6TfZfvhLvFNOK56g==
Received: from pxi11 (pxi11.prod.google.com [10.243.27.11]) by hpaq1.eem.corp.google.com with ESMTP id oB8AmYZ3004316 for ; Wed, 8 Dec 2010 02:48:34 -0800
Received: by pxi11 with SMTP id 11so250474pxi.35 for ; Wed, 08 Dec 2010 02:48:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=tRfXrLepm8dBZiQBYk7owelOw7LqOZ/Kovr8rrsFnVk=; b=yqta5TQJ8dRf6K7HOI96Eb4ASZwUoxEAm2jhYac+KZrkkoKBI4Ama6stvRKkFgl5Nh hGpk7lU6l8CRo9hQpdgg==
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; b=xWxbZquSVnBuoKlzxxmQisdiXz2rLSV0SMOd6nv0m2OG0gbPyUB1DkIW1yVKvguO4J H4PLBVNQjDESysQBSa3w==
MIME-Version: 1.0
Received: by 10.142.199.20 with SMTP id w20mr2217792wff.419.1291805313632; Wed, 08 Dec 2010 02:48:33 -0800 (PST)
Received: by 10.143.18.14 with HTTP; Wed, 8 Dec 2010 02:48:33 -0800 (PST)
In-Reply-To:
References: <[email-masked]>
Date: Wed, 8 Dec 2010 10:48:33 +0000
Message-ID:
From: Ben Laurie
To: Nicholas Weaver
Content-Type: text/plain; charset=ISO-8859-1
X-System-Of-Record: true
Cc: [email-masked], Phillip Hallam-Baker , Paul Hoffman
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 08 Dec 2010 10:47:11 -0000

On 7 December 2010 17:41, Nicholas Weaver wrote:
> Really stupid question:
> How is "Must use EV" really different from "Must have cert issued under one of a particular set of CAs"?
>
> Don't most EV certs use different roots than normal certs for the given CAs?

Presumably. Not sure what you're getting at here?

Clearly "must use EV" is different from "must use CA X" (where, say, X
doesn't issue EV certs) in that the certs are ... EV certs. In terms
of how you express them as CAA RRs they probably look exceedingly
similar.

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A9AD3A688B for ; Wed, 8 Dec 2010 02:43:40 -0800 (PST)
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 SKBYm4L72GlH for ; Wed, 8 Dec 2010 02:43:39 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id B10863A682F for ; Wed, 8 Dec 2010 02:43:39 -0800 (PST)
Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id oB8Aj4Pl001821 for ; Wed, 8 Dec 2010 02:45:04 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1291805106; bh=YO3VcDz4CyJtsIT0mc406MLaKMQ=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=P9gZ94P2s0Qv9m0/hLu1w+EN8BRL5pfwMlito6SS4Df4ogwPdeXNdYyOf2TzZEpHu xAVZaQ5XiKwFmmLYe29Xg==
Received: from pxi15 (pxi15.prod.google.com [10.243.27.15]) by hpaq5.eem.corp.google.com with ESMTP id oB8Aj2VE011223 for ; Wed, 8 Dec 2010 02:45:03 -0800
Received: by pxi15 with SMTP id 15so280284pxi.5 for ; Wed, 08 Dec 2010 02:45:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=Rp8yrhHQUKuJW9zlPIKgAGztIe99c6pM+SCDoLwjEjQ=; b=n8t4CaqL/y3DrrAlt/gsc/rdsl8af+1o4v8ytW0c5T/Ji11oKu6psimVQbCsPQLetP Fpfc6m+OaFVqGwmMlt7Q==
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; b=tKjzkV1mca6zxI9nwy8hzUvaBBnWajGlUWz5HxokarPiJgO7cZfVtnHcQuwuWkxYl1 iYwgxo+tJ60HuFCg6+2g==
MIME-Version: 1.0
Received: by 10.143.11.9 with SMTP id o9mr2221986wfi.134.1291805101972; Wed, 08 Dec 2010 02:45:01 -0800 (PST)
Received: by 10.143.18.14 with HTTP; Wed, 8 Dec 2010 02:45:01 -0800 (PST)
In-Reply-To:
References: <[email-masked]>
Date: Wed, 8 Dec 2010 10:45:01 +0000
Message-ID:
From: Ben Laurie
To: Paul Wouters
Content-Type: text/plain; charset=ISO-8859-1
X-System-Of-Record: true
Cc: [email-masked], Phillip Hallam-Baker , Paul Hoffman
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 08 Dec 2010 10:43:40 -0000

On 7 December 2010 17:21, Paul Wouters wrote:
> I am concerned about specifing the EV cert. I have no objection to it, but
> I'm afraid it will reduce the validity of non-EV certs. That is, we might
> be moving the problem from the popup of "warning: this is an untrusted
> cert" to a popup of "warning: this cert is not EV". Getting keys/certs
> trusted without popups and CA's was one of the goals of KEYASSURE.

Don't shoot the messenger. Is it possible to specify a mechanism that
_cannot_ lead to this outcome? I suspect not.

It is up to implementations to decide what they want to tell users
about certs. Certainly I won't be advocating the UI you suggest in any
implementation I have anything to do with.

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD5573A67FF for ; Tue, 7 Dec 2010 11:58:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.807
X-Spam-Level:
X-Spam-Status: No, score=-100.807 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, SARE_LWSHORTT=1.24, 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 XJJQfsjljf8p for ; Tue, 7 Dec 2010 11:58:03 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 2C28E3A6891 for ; Tue, 7 Dec 2010 11:58:03 -0800 (PST)
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 oB7JxPbL023571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Dec 2010 12:59:27 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References: <[email-masked]>
Date: Tue, 7 Dec 2010 11:59:24 -0800
To: Phillip Hallam-Baker
From: Paul Hoffman
Content-Type: text/plain; charset="us-ascii"
Cc: [email-masked]
Subject: Re: [keyassure] Where to discuss CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 07 Dec 2010 19:58:04 -0000

At 2:39 PM -0500 12/7/10, Phillip Hallam-Baker wrote:
>When discussing the best approach to bringing security policy work
>into IETF process with the Security Area director, he suggested that
>the best approach would be to submit an Experimental proposal and see
>if we can demonstrate the viability of the proposal first.

You keep speaking for that AD, and he never speaks for himself. That's bad. (And, yes, I have asked him, more than once, to speak for himself on the list.)

There is no such thing as an "Experimental proposal" in the IETF. You might have misunderstood what he said.

There are Experimental RFCs. Those can be published in the IETF stream (after getting IETF consensus) or by the Independent Submissions Editor. (We will assume for the moment that this is not an IAB or IRTF document.)

Which of those two streams are intending with this document? If it is the former, then it is appropriate to ask that AD for a mailing list for this document. If it is the latter, you do not need to discuss this on any IETF mailing list, and it is up to the ISE whether or not whatever you hand him is ready to be published.

>We are currently following that advice, but the long term objective is
>clearly to make a consensus proposal when the ADs are willing to let
>me do so.

Is the short term objective to have an Experimental RFC coming through the ISE?

>Clearly any proposal that has far reaching effects across the industry
>will involve discussions that are outside the scope of IETF.

Indeed. The more of those discussions that can happen on open mailing lists, the better.

--Paul Hoffman, Director
--VPN Consortium

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A2A33A69B3 for ; Tue, 7 Dec 2010 11:38:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.208
X-Spam-Level:
X-Spam-Status: No, score=-3.208 tagged_above=-999 required=5 tests=[AWL=0.391, 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 3NrvBsONK7pD for ; Tue, 7 Dec 2010 11:37:56 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id BE63F3A696A for ; Tue, 7 Dec 2010 11:37:47 -0800 (PST)
Received: by ywk9 with SMTP id 9so227969ywk.31 for ; Tue, 07 Dec 2010 11:39:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=AeDjHd2xnbu1FpApltJF8uSZqXLvMyhj09sNIF8dFsU=; b=ubn1TC1WF8rET45z45wrSWYeGyYV778ILxaCDgWzNu56xfrzzmgdIko2MPFDDzRRfH y0PftOaIngHmc93mwjkvXlglm2P9ULqN+q7HsdQqWeguIBvgBXqOjoxnEgFrBXAU1uhY NGP2CH3Q71SZBI568tzRcquN+cgKr0ouW5oB4=
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:content-transfer-encoding; b=EW8ZnxdCHQfy7qcUTD6z2S+HXcc8AQIRUhip7VR6b9BTI/hVefkKreepGM2tld5jas 7kiFuL6zGmBNEGaX1Iv09hN9vcFPkL7Q306Tkhr9Eg7ouVn/UASfLYGW+slbhRTJtn7U 1mHzzDj/EU28uitkMvrfEJjzsfZoVl8gUW4Pg=
MIME-Version: 1.0
Received: by 10.101.67.10 with SMTP id u10mr4384635ank.239.1291750752347; Tue, 07 Dec 2010 11:39:12 -0800 (PST)
Received: by 10.101.103.14 with HTTP; Tue, 7 Dec 2010 11:39:12 -0800 (PST)
In-Reply-To:
References: <[email-masked]>
Date: Tue, 7 Dec 2010 14:39:12 -0500
Message-ID:
From: Phillip Hallam-Baker
To: Paul Hoffman
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: [email-masked]
Subject: Re: [keyassure] Where to discuss CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 07 Dec 2010 19:38:27 -0000

When discussing the best approach to bringing security policy work
into IETF process with the Security Area director, he suggested that
the best approach would be to submit an Experimental proposal and see
if we can demonstrate the viability of the proposal first.

We are currently following that advice, but the long term objective is
clearly to make a consensus proposal when the ADs are willing to let
me do so.

Clearly any proposal that has far reaching effects across the industry
will involve discussions that are outside the scope of IETF.

On Tue, Dec 7, 2010 at 12:38 PM, Paul Hoffman wrote=
:
> At 12:20 PM -0500 12/7/10, Phillip Hallam-Baker wrote:
>>I can raise this when we discuss the draft at the next con call.
>>
>>But I really don't expect to have a great deal of substantive
>>discussion in CAB-Forum until after the technical spec is done.
>
> This deeply concerns me. The technical spec seems to have a lot of accoun=
tability assumptions in it that would affect both CAs and browser vendors.
>
>>And
>>the type of discussion that there would be would most likely be legal
>>rather than technical.
>
> Those seem pretty relevant to the accountability assumptions.
>
>>If there are technical requirements that are raised in those
>>discussions, they would need to be brought to the IETF for action.
>
> To the IETF? Were you meaning for this to be an IETF consensus document?
>
>>But again, we are at this point discussing an EXPERIMENTAL proposal
>>and the point of the experiment is to see if the scheme is complete.
>
> That is a terribly limited view of what an experiment might yield. Anothe=
r likely result would be to see if the scheme's semantics are what the comm=
unity wants. Another would be whether the document is understandable. It se=
ems premature to limit the possible results to "complete" or not.
>
>>We can of course ask CABForum to set up a list as you suggest, but I
>>would see a better solution to be to direct discussion of this
>>proposal to an IETF list, either this one or some other to be created.
>
> If this is meant to be an IETF activity, that makes sense. If it is meant=
to be an independent submission, it would not, but that's why I suggested =
that either Comodo or Google could set up such a list.
>
>>But I don't think we need to get into that consideration now since
>>this is not yet a standards track proposal. And one of the reasons I
>>want to do Experimental ahead of starting the standards track is
>>because this is an accountability mechanism and the IETF has no
>>ability to impose consequences on CAs.
>
> Then why publish the accountability part in an RFC at all? I'm completely=
confused by the authors' intentions. Can you three clarify?
>
> --Paul Hoffman, Director
> --VPN Consortium
>

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

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B0783A6875 for ; Tue, 7 Dec 2010 11:21:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.2
X-Spam-Level:
X-Spam-Status: No, score=-3.2 tagged_above=-999 required=5 tests=[AWL=0.399, 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 cipBgou4Ecqj for ; Tue, 7 Dec 2010 11:21:12 -0800 (PST)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 768723A67FF for ; Tue, 7 Dec 2010 11:21:12 -0800 (PST)
Received: by gyd12 with SMTP id 12so209262gyd.31 for ; Tue, 07 Dec 2010 11:22:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=TDoiTdIOMsOiAZHF/xiUc17pPQ4Y98WVy6nvVX5kzsw=; b=nD1kKJjtfzJyZzhxm+xtZmym6Qy/tu+oD6vEinUQEcRyLtbf0IyqKUMySfYFmYQ3T3 tEejhWHgqYhiY4drWVbDT4968NWsB4+GgEFGUPrjbfWMovsK/iG00I331LA7RKz8XXre Tdsw0quFuJFzdEmr26Mkwy7vpU2NEPIKeSXLg=
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:content-transfer-encoding; b=meJ51fabb5/biR4qdWdkRudJl6PprqPYdtx6zzwM5j6+zXKcMHXxDitxUT/VqGn50d 0hCNX/VGigFI5ixA+FndRktqq7/K87cHsvKD2NLP+pgxWQeFB7zdCs1FWEbkp8v+zSZm AJFBtUeMJmSLugKJ+FSb4ELPFhWbFSuXS3pGY=
MIME-Version: 1.0
Received: by 10.100.225.7 with SMTP id x7mr5190428ang.69.1291749758282; Tue, 07 Dec 2010 11:22:38 -0800 (PST)
Received: by 10.101.103.14 with HTTP; Tue, 7 Dec 2010 11:22:38 -0800 (PST)
In-Reply-To:
References: <[email-masked]>
Date: Tue, 7 Dec 2010 14:22:38 -0500
Message-ID:
From: Phillip Hallam-Baker
To: Zack Weinberg
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: [email-masked], Paul Hoffman
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 07 Dec 2010 19:21:20 -0000

WEBSEC is an IETF working group

http://tools.ietf.org/wg/websec/charters

Here is the presentation I made to that group for the Beijing meeting
which might help set context:
http://www.youtube.com/watch?v=3D2zmJCfUx6Uc

We have something of a problem here with a set of concerns that cut
right across the protocol stack from transport up to application and
beyond.

While some people say 'I don't want to do X here' when they mean 'I
don't want to do X at all', I mean exactly what I say. If I think
something is a bad idea, I come right out and say it. If I say we
should do something in another place then that is precisely what I
mean as well.

The requirements for Web UA are not the same as the requirements for mail U=
A.

On Tue, Dec 7, 2010 at 1:42 PM, Zack Weinberg wr=
ote:
> On Tue, Dec 7, 2010 at 10:31 AM, Phillip Hallam-Baker =
wrote:
>>
>> CAA is designed to support client enforcement and will thus require UA
>> behavior.
>>
>> But that is going to require input and buy in from more than just one
>> browser provider if there is going to be a common standard. The point
>> of making this proposal is to start a conversation as to what the UA
>> implications should be and which forums it would be appropriate to
>> discuss them in.
>>
>> My view is that WebSec would be better suited for that form of
>> discussion since they are apps layer concerns.
>
> I'd be very glad to have that conversation. =A0This is the venue I know
> about, though. =A0Where's "WebSec"?
>
> zw
>

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

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF82F3A683D for ; Tue, 7 Dec 2010 10:40:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHweYR3GqASN for ; Tue, 7 Dec 2010 10:40:43 -0800 (PST)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id BF09E3A6863 for ; Tue, 7 Dec 2010 10:40:42 -0800 (PST)
Received: by wyf23 with SMTP id 23so212241wyf.31 for ; Tue, 07 Dec 2010 10:42:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=LJK6dm+ooBhsBM1sY7/bGDg54w3SmwF82Ss40UNetog=; b=rIaPOqAuDTmtexzn9jslMyMPqD1uF2kLhpDFLdqosGJ0jZsNyl9z33IVpfd830zmzC wTAyp/QmxHC5bwqlXM309h+B14KGsC1JnTl9CY7M4OdvAmzXDLFhcZWGo95wnVRoRFMW tibIpQPyJ7DQFshKnd0gccssyGfeyMt0ZHOso=
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=YSqcVsnHyrhwB4hI1nb2bqcqfnTd0+YOYHkWQr4loruoiggcwg5EVhb2CL1kJy0LYZ 8XdFu3To11f0rqBaIHMk8Lfl4RWUC3raOdyL7kz266AsmousJa57VNF/WWBlzNsRZSdw qLpMDGNKpPXuQxe3KaZ3Kfdysdbhx2IMuFHXs=
MIME-Version: 1.0
Received: by 10.227.136.148 with SMTP id r20mr6041098wbt.99.1291747327833; Tue, 07 Dec 2010 10:42:07 -0800 (PST)
Sender: [email-masked]
Received: by 10.227.133.149 with HTTP; Tue, 7 Dec 2010 10:42:07 -0800 (PST)
In-Reply-To:
References: <[email-masked]>
Date: Tue, 7 Dec 2010 10:42:07 -0800
X-Google-Sender-Auth: b6ggkQ1OrvhLrgjKAqi0ZNxA3fc
Message-ID:
From: Zack Weinberg
To: Phillip Hallam-Baker
Content-Type: text/plain; charset=UTF-8
Cc: [email-masked], Paul Hoffman
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 07 Dec 2010 18:40:44 -0000

On Tue, Dec 7, 2010 at 10:31 AM, Phillip Hallam-Baker wrote:
>
> CAA is designed to support client enforcement and will thus require UA
> behavior.
>
> But that is going to require input and buy in from more than just one
> browser provider if there is going to be a common standard. The point
> of making this proposal is to start a conversation as to what the UA
> implications should be and which forums it would be appropriate to
> discuss them in.
>
> My view is that WebSec would be better suited for that form of
> discussion since they are apps layer concerns.

I'd be very glad to have that conversation. This is the venue I know
about, though. Where's "WebSec"?

zw

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A58AB3A6863 for ; Tue, 7 Dec 2010 10:38:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.19
X-Spam-Level:
X-Spam-Status: No, score=-3.19 tagged_above=-999 required=5 tests=[AWL=0.409, 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 wF4cgLvJ+uIj for ; Tue, 7 Dec 2010 10:38:27 -0800 (PST)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 21DCD3A683D for ; Tue, 7 Dec 2010 10:38:27 -0800 (PST)
Received: by yxt33 with SMTP id 33so183744yxt.31 for ; Tue, 07 Dec 2010 10:39:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=2+Gnc1nRV5A8TnG6/HCmSaFQU+dIVi4TXysPoQslALk=; b=LBJhkwkvo1t7A9ny9W0y17PC1Qh/86jscGg//DTil4uxm9aN+Dy7N39o1KHKp1vdiQ RjPOE8H8t1wOwDXRK6zvDnkYpwkZ84s1ob+jeXP+kg6j7Kf8hCYWjoBjPvJjpMryuXV6 0c1PNq0NPywlzBmT9Q4Oj0dzARiL0Vb4LkuNs=
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=qOX/FDkkPya19m0h1/Q7qDWiJY27SQ3e2rKOCfeft9cZw9vHinyGg1f9i3R6543R3i 41zTQ7DK1+5040quI/RV6lZjynEcw8Zp/Mb3Fc5qY0mcd0mXflFeJgkIvlI9MRvaNFDq Ho+FzsY7thHr/xJh+FIdho6OuOEh7Si5uFgHg=
MIME-Version: 1.0
Received: by 10.100.208.14 with SMTP id f14mr5126220ang.205.1291747192463; Tue, 07 Dec 2010 10:39:52 -0800 (PST)
Received: by 10.101.103.14 with HTTP; Tue, 7 Dec 2010 10:39:52 -0800 (PST)
In-Reply-To:
References: <[email-masked]>
Date: Tue, 7 Dec 2010 13:39:52 -0500
Message-ID:
From: Phillip Hallam-Baker
To: Paul Wouters
Content-Type: text/plain; charset=ISO-8859-1
Cc: [email-masked], Paul Hoffman
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 07 Dec 2010 18:38:29 -0000

On Tue, Dec 7, 2010 at 1:03 PM, Paul Wouters wrote:
> On Tue, 7 Dec 2010, Phillip Hallam-Baker wrote:
>
>> The way that I see it, a browser should accept any certificate
>> whatsoever without complaint. But it should only ever indicate to the
>> user that they are secure if the certificate demonstrates that there
>> is accountability.
>
> The key word is "accountability". You and I have very different views on
> that, coming from very different worlds. And so will many implementers of
> the CAA record type.

Accountability controls are based on the principle of deterrence: the
expectation that unauthorized actions may result in consequences.

I think this is a reasonably objective principle.

EV describes a set of process requirements designed to establish one
form of accountability. CAA is designed to allow a practically
infinite number of such process requirements to be defined if
necessary.

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

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 509E13A6863 for ; Tue, 7 Dec 2010 10:29:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.181
X-Spam-Level:
X-Spam-Status: No, score=-3.181 tagged_above=-999 required=5 tests=[AWL=0.418, 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 8TxysNpIVFvs for ; Tue, 7 Dec 2010 10:29:50 -0800 (PST)
Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by core3.amsl.com (Postfix) with ESMTP id BA1C63A686A for ; Tue, 7 Dec 2010 10:29:49 -0800 (PST)
Received: by gxk8 with SMTP id 8so185867gxk.27 for ; Tue, 07 Dec 2010 10:31:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=cYcYt8Uf8N+WYpDK3Iy4YW/ISuAf1WmUj3uxEmzT5tE=; b=ut1XKrOUphfY/g7ldtUnC3BI2W15fMSbk9DA5biChhC/D0dqP+w57ZLhTYAaE4iuMB dnncKmkBx4SL1IuuDL4zf25qD545TUolCAFmk+B7ciPtPegf3L00i3L0ON/zMtGr+yGM zjsJCeApl4Muz6NG0p9zQKUUBAFYfaRXAOk+8=
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=WXfVh5/ZJxpn6lbGq1x3xL2hYtJ/cgxB+RETFVlDiURWVPxIVpERrs3mLoac1R26eW Ob2BmE+vogQ8b74A7KXJnrW/2j288SARMQrdmSvetJ5KQI59ZS5UGO3k9vfV2JPT1ITo GXwajQFcHIfkUUankBfIWOuxvEhpI33DwkRws=
MIME-Version: 1.0
Received: by 10.100.96.1 with SMTP id t1mr4666939anb.137.1291746675149; Tue, 07 Dec 2010 10:31:15 -0800 (PST)
Received: by 10.101.103.14 with HTTP; Tue, 7 Dec 2010 10:31:15 -0800 (PST)
In-Reply-To:
References: <[email-masked]>
Date: Tue, 7 Dec 2010 13:31:15 -0500
Message-ID:
From: Phillip Hallam-Baker
To: Zack Weinberg
Content-Type: text/plain; charset=ISO-8859-1
Cc: [email-masked], Paul Hoffman
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 07 Dec 2010 18:29:51 -0000

On Tue, Dec 7, 2010 at 1:11 PM, Zack Weinberg wrote:
> On Tue, Dec 7, 2010 at 7:27 AM, Phillip Hallam-Baker wrote:
>>
>> The reason that I do not want to do that right now is that I want to
>> see how much coverage of the requirements I can get from implementing
>> just the two properties given in CAA. And I can only do that with real
>> world experiments and feedback from the organizations who have told me
>> that they are interested in field trials.
>
> If UAs aren't expected to do anything with CAA, then I as UA author
> have no feedback on CAA beyond "this does not solve any problem we
> care about", and won't be participating in field trials.

CAA is designed to support client enforcement and will thus require UA
behavior.

But that is going to require input and buy in from more than just one
browser provider if there is going to be a common standard. The point
of making this proposal is to start a conversation as to what the UA
implications should be and which forums it would be appropriate to
discuss them in.

My view is that WebSec would be better suited for that form of
discussion since they are apps layer concerns.

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

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 130283A6897 for ; Tue, 7 Dec 2010 10:14:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.17
X-Spam-Level:
X-Spam-Status: No, score=-3.17 tagged_above=-999 required=5 tests=[AWL=0.429, 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 Wgy39buYZ5gl for ; Tue, 7 Dec 2010 10:14:26 -0800 (PST)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id ADDE03A6851 for ; Tue, 7 Dec 2010 10:14:26 -0800 (PST)
Received: by yxt33 with SMTP id 33so167211yxt.31 for ; Tue, 07 Dec 2010 10:15:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=PTWW6u9Yi9qOTgXn2JN8DpRgmk5r4gFTJimUOf+3nl4=; b=mS6MwH0MGjr/zXWe/rKKHBGtxProkNHz1GokcMMvfl7HUFTaboy/JiyU/pkrmq14Hc 4yfcVCqb20yZPjWJDKZ3+V6dnVmtU5FjzX7WX87CG92vz/COJz92qvhbJAKrGt5JVZOp /83d1GTfpoCuFiOlclQHk0jxOK8r/SlvBTM2g=
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=UrnZVzc5tW8NNuiBM3WsI0gapAt1NCen1OV82QajKqFU76IMz2DzuDQob63/UDnyzp Zt1YHdhbDwqZXbOT5FyGlPK9c0OmafRpahe+KCzEejEL+chV+5QCVU5aoanPaMWYC2Tj rqLdu1e0Bj/OB2/ne/PjluaQbBAKauSt9Drlk=
MIME-Version: 1.0
Received: by 10.101.67.10 with SMTP id u10mr4327725ank.239.1291745752047; Tue, 07 Dec 2010 10:15:52 -0800 (PST)
Received: by 10.101.103.14 with HTTP; Tue, 7 Dec 2010 10:15:51 -0800 (PST)
In-Reply-To:
References: <[email-masked]>
Date: Tue, 7 Dec 2010 13:15:51 -0500
Message-ID:
From: Phillip Hallam-Baker
To: Nicholas Weaver
Content-Type: text/plain; charset=ISO-8859-1
Cc: [email-masked], Paul Hoffman
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 07 Dec 2010 18:14:28 -0000

There are some companies that have a company wide policy that all
certs must be EV but do not currently have a single vendor or
restricted vendor policy in place for certs.

Once issued, a cert is valid for several years. I doubt that companies
would want to force reissue of every cert to perform trials. Telling
RPs that all your existing certs are EV is much easier than going
round policing every server.

On Tue, Dec 7, 2010 at 12:41 PM, Nicholas Weaver
wrote:
>
> On Dec 7, 2010, at 9:21 AM, Paul Wouters wrote:
>
>> On Tue, 7 Dec 2010, Phillip Hallam-Baker wrote:
>>
>>> At this point we have a mechanism that is perfectly adequate for
>>> enforcing the following restrictions at the RP level:
>>>
>>> * Must use EV.
>>> * Must have cert issued under a particular CA.
>>>
>>> These are actually sufficient for all the key assurance requirements I
>>> have seen here thus far, provided that people who want to do
>>> self-assurance and have larger than minimal needs are willing to
>>> establish a CA root and issue certs under that rather than using
>>> self-signed end-entity certs.
>>
>> I am concerned about specifing the EV cert. I have no objection to it, but
>> I'm afraid it will reduce the validity of non-EV certs. That is, we might
>> be moving the problem from the popup of "warning: this is an untrusted
>> cert" to a popup of "warning: this cert is not EV". Getting keys/certs
>> trusted without popups and CA's was one of the goals of KEYASSURE.
>>
>> Since EV-certs are much more expensive then most domains itself, this
>> is a significant cost problem for large scale deployments, and I would
>> rather see a proposal from the IETF that is purely based on technical
>> merits, instead of cutting of the financially poor or enforce via a legal
>> system to back up a tecnical one.
>
> Really stupid question:
> How is "Must use EV" really different from "Must have cert issued under one of a particular set of CAs"?
>
> Don't most EV certs use different roots than normal certs for the given CAs?
>
>

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

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 608043A686C for ; Tue, 7 Dec 2010 10:10:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CcQx8OvxPr4D for ; Tue, 7 Dec 2010 10:10:36 -0800 (PST)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id CF4023A6823 for ; Tue, 7 Dec 2010 10:10:35 -0800 (PST)
Received: by wwa36 with SMTP id 36so185012wwa.13 for ; Tue, 07 Dec 2010 10:12:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=b3anEoynB0vq/Hya3hGxmJO1R6N1pUIWnGxdn/LaDu0=; b=PcuaqNpAD6NbcrOta+YqE7yy3BqUvBYD4FMbw0tgcAjTGjsCnbDbdWEOLA5CwgLc/B jFuxU5SLvP6kpO3Yhma0gk4ck+tIVnkpTopPfH/tTQBUF3NWgzK/OxaIssb1ktRaf4SW VOQZsEasxsSjKZfiEEjYXdk4asHxBoetmuSkY=
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=USEXa+A3v+lIFxoF/qjC2rgCFqcwshsDTkhgSCXPKUSe790Akzc+ua2LYPoHXyAZFI r2+znmzlZc/rLLDg+v9YgdKfC96wLu5zds0vuYreKZ7ORwdYIZ1YiWdFURVhVB3A4Oqs GehZrxKLWoWhdkhh+mbnvIP+XiZZKyw3BMR9s=
MIME-Version: 1.0
Received: by 10.227.68.143 with SMTP id v15mr7722676wbi.12.1291745516117; Tue, 07 Dec 2010 10:11:56 -0800 (PST)
Sender: [email-masked]
Received: by 10.227.133.149 with HTTP; Tue, 7 Dec 2010 10:11:55 -0800 (PST)
In-Reply-To:
References: <[email-masked]>
Date: Tue, 7 Dec 2010 10:11:55 -0800
X-Google-Sender-Auth: aHoQBOCzbW1UthFIQ9JTlEJBqYA
Message-ID:
From: Zack Weinberg
To: Phillip Hallam-Baker
Content-Type: text/plain; charset=UTF-8
Cc: [email-masked], Paul Hoffman
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 07 Dec 2010 18:10:37 -0000

On Tue, Dec 7, 2010 at 7:27 AM, Phillip Hallam-Baker wrote:
>
> The reason that I do not want to do that right now is that I want to
> see how much coverage of the requirements I can get from implementing
> just the two properties given in CAA. And I can only do that with real
> world experiments and feedback from the organizations who have told me
> that they are interested in field trials.

If UAs aren't expected to do anything with CAA, then I as UA author
have no feedback on CAA beyond "this does not solve any problem we
care about", and won't be participating in field trials.

zw

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 227613A68B7 for ; Tue, 7 Dec 2010 10:01:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9MkJttt8sCPr for ; Tue, 7 Dec 2010 10:01:49 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 3DDD23A6869 for ; Tue, 7 Dec 2010 10:01:49 -0800 (PST)
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 CC0FAC4BE; Tue, 7 Dec 2010 13:03:13 -0500 (EST)
Date: Tue, 7 Dec 2010 13:03:13 -0500 (EST)
From: Paul Wouters
To: Phillip Hallam-Baker
In-Reply-To:
Message-ID:
References: <[email-masked]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: [email-masked], Paul Hoffman
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 07 Dec 2010 18:01:50 -0000

On Tue, 7 Dec 2010, Phillip Hallam-Baker wrote:

> The way that I see it, a browser should accept any certificate
> whatsoever without complaint. But it should only ever indicate to the
> user that they are secure if the certificate demonstrates that there
> is accountability.

The key word is "accountability". You and I have very different views on
that, coming from very different worlds. And so will many implementers of
the CAA record type.

My concern is exactly the misuse of the CAA record effectively blocking
a DNSSEC-only concept of accountability, and a re-introduction of a
mandatory for-pay CA chain to securely "account" for domain names.

Paul

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD8C93A69A7 for ; Tue, 7 Dec 2010 09:40:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 AUkw+Gv-3ji4 for ; Tue, 7 Dec 2010 09:40:29 -0800 (PST)
Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by core3.amsl.com (Postfix) with ESMTP id 40BBD3A6823 for ; Tue, 7 Dec 2010 09:40:29 -0800 (PST)
Received: from gala.icsi.berkeley.edu (gala.ICSI.Berkeley.EDU [192.150.186.168]) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id 2412C36A4E9; Tue, 7 Dec 2010 09:41:55 -0800 (PST)
References: <[email-masked]>
In-Reply-To:
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
Message-Id:
Content-Transfer-Encoding: quoted-printable
From: Nicholas Weaver
Date: Tue, 7 Dec 2010 09:41:54 -0800
To: Paul Wouters
X-Mailer: Apple Mail (2.1082)
Cc: Phillip Hallam-Baker , Paul Hoffman , [email-masked]
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 07 Dec 2010 17:40:31 -0000

On Dec 7, 2010, at 9:21 AM, Paul Wouters wrote:

> On Tue, 7 Dec 2010, Phillip Hallam-Baker wrote:
>=20
>> At this point we have a mechanism that is perfectly adequate for
>> enforcing the following restrictions at the RP level:
>>=20
>> * Must use EV.
>> * Must have cert issued under a particular CA.
>>=20
>> These are actually sufficient for all the key assurance requirements =
I
>> have seen here thus far, provided that people who want to do
>> self-assurance and have larger than minimal needs are willing to
>> establish a CA root and issue certs under that rather than using
>> self-signed end-entity certs.
>=20
> I am concerned about specifing the EV cert. I have no objection to it, =
but
> I'm afraid it will reduce the validity of non-EV certs. That is, we =
might
> be moving the problem from the popup of "warning: this is an untrusted
> cert" to a popup of "warning: this cert is not EV". Getting keys/certs
> trusted without popups and CA's was one of the goals of KEYASSURE.
>=20
> Since EV-certs are much more expensive then most domains itself, this
> is a significant cost problem for large scale deployments, and I would
> rather see a proposal from the IETF that is purely based on technical
> merits, instead of cutting of the financially poor or enforce via a =
legal
> system to back up a tecnical one.

Really stupid question:
How is "Must use EV" really different from "Must have cert issued under =
one of a particular set of CAs"?

Don't most EV certs use different roots than normal certs for the given =
CAs?

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A1F63A69B0 for ; Tue, 7 Dec 2010 09:37:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.195
X-Spam-Level:
X-Spam-Status: No, score=-3.195 tagged_above=-999 required=5 tests=[AWL=0.404, 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 REVTHKANaV-A for ; Tue, 7 Dec 2010 09:37:16 -0800 (PST)
Received: from mail-gw0-f42.google.com (mail-gw0-f42.google.com [74.125.83.42]) by core3.amsl.com (Postfix) with ESMTP id 0C8603A69A1 for ; Tue, 7 Dec 2010 09:37:05 -0800 (PST)
Received: by gwb20 with SMTP id 20so187592gwb.15 for ; Tue, 07 Dec 2010 09:38:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=VVvnCt2H+XQT8ORMQG7jOA++I6f0JG+2Qmb7nl//suU=; b=cHBpAE13CNzJxjKoTgP8hstaZjh7+zS2pRDkTkeej+o1LhKlWF1p/rdIg/axT/9LG+ H+uictPgpyFXiD2cs5bBRp4pNEcf5hGClxkSPXKWW7OooAZmRHQa4uiQu07blYaIjDho 4p7SCM2HMfEC87IgTyIIsXcISuBbj1xHK+pME=
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=jGmNcYwjbi2GTLnsia4M6Ef+6XArDP1iFEYOnj1hkWEi/jgBSOSiIaa154iGzo2SIm jgqPlV2si7IyOK3r57o8UmfgI7sg5AjNjueu0a7epHHJmJqLiXqSMC9A7+xN8o9Fh2I/ tM4wetFe1PHc+LNilx0lMyeg0UF9TSpvjkkEs=
MIME-Version: 1.0
Received: by 10.101.67.10 with SMTP id u10mr4298594ank.239.1291743500093; Tue, 07 Dec 2010 09:38:20 -0800 (PST)
Received: by 10.101.103.14 with HTTP; Tue, 7 Dec 2010 09:38:20 -0800 (PST)
In-Reply-To:
References: <[email-masked]>
Date: Tue, 7 Dec 2010 12:38:20 -0500
Message-ID:
From: Phillip Hallam-Baker
To: Paul Wouters
Content-Type: text/plain; charset=ISO-8859-1
Cc: [email-masked], Paul Hoffman
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 07 Dec 2010 17:38:03 -0000

The purpose of this proposal is to allow sites to express certain
aspects of their security policy to issuers and relying parties.
Always use EV was a frequently cited use case.

The purpose of EV certificates is to establish accountability.

DV certificates do not establish accountability.

There is a competitive market for both types of certificate, they
serve different purposes.

Given that this proposal already crosses the DNS and Security areas, I
really do not want to get too far into a discussion that is relevant
to application design.

My view on popup boxes is that they represent a failure on the part of
the designer. they are always a cop-out. But I have spent several
years discussing that problem with other members of this list in
another place and I would prefer not to open up that particular rat
hole in this particular forum.

The way that I see it, a browser should accept any certificate
whatsoever without complaint. But it should only ever indicate to the
user that they are secure if the certificate demonstrates that there
is accountability. And it should only indicate that there is an error
if there was a reason to believe that TLS should have been used.

So the way I see it, this is an issue that can be addressed if we look
at security policy and 'must use tls'. But that goes beyond the
requirements and use cases we discussed when designing the CAA spec.

I have a presentation on this side of things on YouTube that I made
for the WebSec group.

http://www.youtube.com/user/hallambaker#p/u/0/2zmJCfUx6Uc

On Tue, Dec 7, 2010 at 12:21 PM, Paul Wouters wrote:
> On Tue, 7 Dec 2010, Phillip Hallam-Baker wrote:
>
>> At this point we have a mechanism that is perfectly adequate for
>> enforcing the following restrictions at the RP level:
>>
>> * Must use EV.
>> * Must have cert issued under a particular CA.
>>
>> These are actually sufficient for all the key assurance requirements I
>> have seen here thus far, provided that people who want to do
>> self-assurance and have larger than minimal needs are willing to
>> establish a CA root and issue certs under that rather than using
>> self-signed end-entity certs.
>
> I am concerned about specifing the EV cert. I have no objection to it, but
> I'm afraid it will reduce the validity of non-EV certs. That is, we might
> be moving the problem from the popup of "warning: this is an untrusted
> cert" to a popup of "warning: this cert is not EV". Getting keys/certs
> trusted without popups and CA's was one of the goals of KEYASSURE.
>
> Since EV-certs are much more expensive then most domains itself, this
> is a significant cost problem for large scale deployments, and I would
> rather see a proposal from the IETF that is purely based on technical
> merits, instead of cutting of the financially poor or enforce via a legal
> system to back up a tecnical one.
>
> I understand this is client policy, but often we have no choice on those
> platforms with those clients (Windows, iphone, etc)
>
> Assuming one of the drafst for certifying keys via DNSSEC without any
> CA makes it to RFC, it would be counter-productive if such new RRTYPE's
> are doomed to failure because this CAA RRTYPE is missing from most zones.
>
> Is there some phrasing that can be added that local policy MUST NOT cause
> any of
> these issues in the future? I understand this might be hard to phrase. An
> extra green bar (or lack thereof) might be okay, but a popup claiming this
> might be a rogue CA is not.
>
> Paul
>

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

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69F4B3A69A7 for ; Tue, 7 Dec 2010 09:37:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.421
X-Spam-Level:
X-Spam-Status: No, score=-101.421 tagged_above=-999 required=5 tests=[AWL=0.625, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 Oco+wMKzkiB9 for ; Tue, 7 Dec 2010 09:37:17 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 2D0343A6866 for ; Tue, 7 Dec 2010 09:37:12 -0800 (PST)
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 oB7HcMJC016927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Dec 2010 10:38:24 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References: <[email-masked]>
Date: Tue, 7 Dec 2010 09:38:21 -0800
To: Phillip Hallam-Baker
From: Paul Hoffman
Content-Type: text/plain; charset="us-ascii"
Cc: [email-masked]
Subject: Re: [keyassure] Where to discuss CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 07 Dec 2010 17:38:03 -0000

At 12:20 PM -0500 12/7/10, Phillip Hallam-Baker wrote:
>I can raise this when we discuss the draft at the next con call.
>
>But I really don't expect to have a great deal of substantive
>discussion in CAB-Forum until after the technical spec is done.

This deeply concerns me. The technical spec seems to have a lot of accountability assumptions in it that would affect both CAs and browser vendors.

>And
>the type of discussion that there would be would most likely be legal
>rather than technical.

Those seem pretty relevant to the accountability assumptions.

>If there are technical requirements that are raised in those
>discussions, they would need to be brought to the IETF for action.

To the IETF? Were you meaning for this to be an IETF consensus document?

>But again, we are at this point discussing an EXPERIMENTAL proposal
>and the point of the experiment is to see if the scheme is complete.

That is a terribly limited view of what an experiment might yield. Another likely result would be to see if the scheme's semantics are what the community wants. Another would be whether the document is understandable. It seems premature to limit the possible results to "complete" or not.

>We can of course ask CABForum to set up a list as you suggest, but I
>would see a better solution to be to direct discussion of this
>proposal to an IETF list, either this one or some other to be created.

If this is meant to be an IETF activity, that makes sense. If it is meant to be an independent submission, it would not, but that's why I suggested that either Comodo or Google could set up such a list.

>But I don't think we need to get into that consideration now since
>this is not yet a standards track proposal. And one of the reasons I
>want to do Experimental ahead of starting the standards track is
>because this is an accountability mechanism and the IETF has no
>ability to impose consequences on CAs.

Then why publish the accountability part in an RFC at all? I'm completely confused by the authors' intentions. Can you three clarify?

--Paul Hoffman, Director
--VPN Consortium

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 581A93A6863 for ; Tue, 7 Dec 2010 09:19:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3ECnbZCfgWH for ; Tue, 7 Dec 2010 09:19:50 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 0E6883A6813 for ; Tue, 7 Dec 2010 09:19:48 -0800 (PST)
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 221BEC4C2; Tue, 7 Dec 2010 12:21:12 -0500 (EST)
Date: Tue, 7 Dec 2010 12:21:11 -0500 (EST)
From: Paul Wouters
To: Phillip Hallam-Baker
In-Reply-To:
Message-ID:
References: <[email-masked]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: [email-masked], Paul Hoffman
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 07 Dec 2010 17:19:54 -0000

On Tue, 7 Dec 2010, Phillip Hallam-Baker wrote:

> At this point we have a mechanism that is perfectly adequate for
> enforcing the following restrictions at the RP level:
>
> * Must use EV.
> * Must have cert issued under a particular CA.
>
> These are actually sufficient for all the key assurance requirements I
> have seen here thus far, provided that people who want to do
> self-assurance and have larger than minimal needs are willing to
> establish a CA root and issue certs under that rather than using
> self-signed end-entity certs.

I am concerned about specifing the EV cert. I have no objection to it, but
I'm afraid it will reduce the validity of non-EV certs. That is, we might
be moving the problem from the popup of "warning: this is an untrusted
cert" to a popup of "warning: this cert is not EV". Getting keys/certs
trusted without popups and CA's was one of the goals of KEYASSURE.

Since EV-certs are much more expensive then most domains itself, this
is a significant cost problem for large scale deployments, and I would
rather see a proposal from the IETF that is purely based on technical
merits, instead of cutting of the financially poor or enforce via a legal
system to back up a tecnical one.

I understand this is client policy, but often we have no choice on those
platforms with those clients (Windows, iphone, etc)

Assuming one of the drafst for certifying keys via DNSSEC without any
CA makes it to RFC, it would be counter-productive if such new RRTYPE's
are doomed to failure because this CAA RRTYPE is missing from most zones.

Is there some phrasing that can be added that local policy MUST NOT cause any of
these issues in the future? I understand this might be hard to phrase. An
extra green bar (or lack thereof) might be okay, but a popup claiming this
might be a rogue CA is not.

Paul

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01F373A6862 for ; Tue, 7 Dec 2010 09:19:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.16
X-Spam-Level:
X-Spam-Status: No, score=-3.16 tagged_above=-999 required=5 tests=[AWL=0.439, 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 hHZ2ruJPQf1I for ; Tue, 7 Dec 2010 09:19:13 -0800 (PST)
Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by core3.amsl.com (Postfix) with ESMTP id CA7163A6832 for ; Tue, 7 Dec 2010 09:19:10 -0800 (PST)
Received: by gxk8 with SMTP id 8so125269gxk.27 for ; Tue, 07 Dec 2010 09:20:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=smioHPtYNn8nU5RuPD8aHHJuIIrz7W03F8HZDGbYFWs=; b=Z0Dc7JIFX7doST8EH2t/2jyxzVhQ79W1W+VDajhRcgr+slnEyeXP7//Uj4crhvp+A5 AQy+nUzVtFCNKYunzqgBZ5xULxXWFC8zEjM5mI79DhSQMYCUsru9BYulLzLoiRW2zTmY baRIX9iHuDpeh+G8ekCFM2E4BJvgc93WO1rfQ=
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:content-transfer-encoding; b=ReKB1aMYxyTQPD0W8mccXjhHN7ML7FBqTlT8ztILk3xM2q1IxIU1v5SHky5gATvzD2 ECvBCMqgEOtGR+syOzwEbze1K+kZIQdArgoplcbjGkxRP7F3Fo3qDLNSQ50gh+BePTeA imFFjYBX2V0LMRGzrqPJbtqp2RQtDxdl6jvIo=
MIME-Version: 1.0
Received: by 10.100.195.2 with SMTP id s2mr4031487anf.35.1291742436332; Tue, 07 Dec 2010 09:20:36 -0800 (PST)
Received: by 10.101.103.14 with HTTP; Tue, 7 Dec 2010 09:20:36 -0800 (PST)
In-Reply-To:
References: <[email-masked]>
Date: Tue, 7 Dec 2010 12:20:36 -0500
Message-ID:
From: Phillip Hallam-Baker
To: Paul Hoffman
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: [email-masked]
Subject: Re: [keyassure] Where to discuss CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 07 Dec 2010 17:19:25 -0000

I can raise this when we discuss the draft at the next con call.

But I really don't expect to have a great deal of substantive
discussion in CAB-Forum until after the technical spec is done. And
the type of discussion that there would be would most likely be legal
rather than technical.

If there are technical requirements that are raised in those
discussions, they would need to be brought to the IETF for action.

But again, we are at this point discussing an EXPERIMENTAL proposal
and the point of the experiment is to see if the scheme is complete.

We can of course ask CABForum to set up a list as you suggest, but I
would see a better solution to be to direct discussion of this
proposal to an IETF list, either this one or some other to be created.

But I don't think we need to get into that consideration now since
this is not yet a standards track proposal. And one of the reasons I
want to do Experimental ahead of starting the standards track is
because this is an accountability mechanism and the IETF has no
ability to impose consequences on CAs.

On Tue, Dec 7, 2010 at 11:02 AM, Paul Hoffman wrote=
:
> At 7:57 AM -0500 12/7/10, Phillip Hallam-Baker wrote:
>>There are two modes of security control.
>>
>>Network security has tended to be over-invested in access controls and
>>neglect accountability controls. An effective security system requires
>>both.
>>
>>Access controls explicitly specify what is permitted and what is
>>denied. Since it is rarely possible to specify these exactly, the
>>range of actions allowed in an access control regime will almost
>>always be more than is desirable.
>>
>>Accountability controls address the gaps. I can't stop people sending
>>spam but we can block the IP addresses used by spammers and we can
>>send them to jail if caught.
>>
>>
>>The issuer side of CAA is an accountability control. It does not make
>>mis-issue impossible but it does increase the risk of consequences in
>>the case of default.
>
> I fully agree with this split of functions, and think that the access con=
trol part is appropriate to discuss on the keyassure list. The accountabili=
ty control part is quite outside the scope of this mailing list, but intera=
cts with the access control parts in this document.
>
> I understand from second-hand sources that the accountability control par=
t is being discussed on a closed list in the CA/Browser Forum. Is there a c=
hance that that discussion could happen on an open list? I don't know if th=
e CABForum folks sponsor open lists; if not, maybe Comodo or Google could s=
et one up.
>
> --Paul Hoffman, Director
> --VPN Consortium
>

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

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F5563A682B for ; Tue, 7 Dec 2010 08:04:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.148
X-Spam-Level:
X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[AWL=0.451, 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 Z6e47-Ylyccq for ; Tue, 7 Dec 2010 08:04:52 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id C546B3A6819 for ; Tue, 7 Dec 2010 08:04:51 -0800 (PST)
Received: by ywk9 with SMTP id 9so49990ywk.31 for ; Tue, 07 Dec 2010 08:06:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Sh+XdCZ5S3Fnl0L5aSvBMHARbx4IMOqI/cPCpmj4EEs=; b=axNgwfgLsaG4UxLVi5mfMQJnaeCT8VM5mddH2Y9ycbbmKpWljmQhYJp0LZFJTSB/Ug Q435gk8oMi8MVjDFLJBe5kTsNucg9XuMZv7plR2t06pNlRzaAsqmECOC4nNc+PD+pkrQ 032omYjKVR+oHeai3CloDtXCQDCFklfKREuYU=
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:content-transfer-encoding; b=OIwHt3alZbuKC9i+1lw5+sJ943Vrk4Ut+hX0XW4Icrph5ZBzm9fQxXaPASva/1THXU RBcW9wLrlnWnKQWTH8aKLK2ivXtiIYQZMWW0fpK/2u03Buor+J9n4ML0cysY+CT0dRq9 dwVhyG9AMxqZ1uDnTXjyo/2mjWRNmxUMHo3lg=
MIME-Version: 1.0
Received: by 10.100.167.20 with SMTP id p20mr5039618ane.103.1291737976351; Tue, 07 Dec 2010 08:06:16 -0800 (PST)
Received: by 10.101.103.14 with HTTP; Tue, 7 Dec 2010 08:06:16 -0800 (PST)
In-Reply-To:
References: <[email-masked]>
Date: Tue, 7 Dec 2010 11:06:16 -0500
Message-ID:
From: Phillip Hallam-Baker
To: Ben Laurie
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: [email-masked], Paul Hoffman
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 07 Dec 2010 16:04:53 -0000

I am very confident that the extension mechanism is rich enough to
support anything that we might need.

What I am less confident of is that the two properties defined at the
moment will support everything that people might want.

And the reason I want to try to avoid arguing over this is that I
think that the issue will be very quickly decided by actual
implementation experience.

At this point we have a mechanism that is perfectly adequate for
enforcing the following restrictions at the RP level:

* Must use EV.
* Must have cert issued under a particular CA.

These are actually sufficient for all the key assurance requirements I
have seen here thus far, provided that people who want to do
self-assurance and have larger than minimal needs are willing to
establish a CA root and issue certs under that rather than using
self-signed end-entity certs.

Now in my opinion, that is exactly how people should be advised to
manage self-assurance. There are a few side constraints that we may
have to address however.

For example, consider the case where a site wants to use EV certs for
HTTPS but self-asserted certs for SMTP, POP and IMAP. We might get
into a requirement for protocol specific assertions and addressing
that requirement would require a second RR assignment.

I can see possible justification for such requirements and I can see
reasons for not wanting to make the spec more complex than at present.
Rather than argue the point, I want data from deployment experience.

On Tue, Dec 7, 2010 at 10:32 AM, Ben Laurie wrote:
> On 7 December 2010 15:11, Paul Hoffman wrote:
>> At 2:52 PM +0000 12/7/10, Ben Laurie wrote:
>>> >... this line of thinking even more. =A0If you really don't intend for=
this to be used by UAs, then these should be scrapped as well.
>>>
>>>I do intend for these to be used by UAs.
>>
>> If two of the three co-authors on this draft cannot agree on the semanti=
cs, then it is maybe premature for them to expect the Internet community to=
do so.
>
> I don't think we disagree - the question is whether CAA is rich enough
> to cover everything a UA might need. I think it might be, Phillip is
> less certain.
>

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

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15E2E3A697B for ; Tue, 7 Dec 2010 08:00:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.414
X-Spam-Level:
X-Spam-Status: No, score=-101.414 tagged_above=-999 required=5 tests=[AWL=0.632, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 sTEvCSYS747L for ; Tue, 7 Dec 2010 08:00:51 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 010AD3A6932 for ; Tue, 7 Dec 2010 08:00:50 -0800 (PST)
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 oB7G2A7s011964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Dec 2010 09:02:12 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References: <[email-masked]>
Date: Tue, 7 Dec 2010 08:02:08 -0800
To: Phillip Hallam-Baker , Ben Laurie
From: Paul Hoffman
Content-Type: text/plain; charset="us-ascii"
Cc: [email-masked]
Subject: [keyassure] Where to discuss CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 07 Dec 2010 16:00:52 -0000

At 7:57 AM -0500 12/7/10, Phillip Hallam-Baker wrote:
>There are two modes of security control.
>
>Network security has tended to be over-invested in access controls and
>neglect accountability controls. An effective security system requires
>both.
>
>Access controls explicitly specify what is permitted and what is
>denied. Since it is rarely possible to specify these exactly, the
>range of actions allowed in an access control regime will almost
>always be more than is desirable.
>
>Accountability controls address the gaps. I can't stop people sending
>spam but we can block the IP addresses used by spammers and we can
>send them to jail if caught.
>
>
>The issuer side of CAA is an accountability control. It does not make
>mis-issue impossible but it does increase the risk of consequences in
>the case of default.

I fully agree with this split of functions, and think that the access control part is appropriate to discuss on the keyassure list. The accountability control part is quite outside the scope of this mailing list, but interacts with the access control parts in this document.

I understand from second-hand sources that the accountability control part is being discussed on a closed list in the CA/Browser Forum. Is there a chance that that discussion could happen on an open list? I don't know if the CABForum folks sponsor open lists; if not, maybe Comodo or Google could set one up.

--Paul Hoffman, Director
--VPN Consortium

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 780CB3A680F for ; Tue, 7 Dec 2010 07:31:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.977
X-Spam-Level:
X-Spam-Status: No, score=-109.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_HI=-8, 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 RbWMxUIHrvAX for ; Tue, 7 Dec 2010 07:31:10 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id CC00B3A6808 for ; Tue, 7 Dec 2010 07:31:09 -0800 (PST)
Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id oB7FWYhd013004 for ; Tue, 7 Dec 2010 07:32:34 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1291735954; bh=aaH4HdHCI6Nx3c4rOH7t4wRApBs=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=mVmwogyIyQIfHoQAiUCjOMloHTy+XTgXQoqPTrbHC0v3MoRH8aXPDjvQqEJAAWHCy mQkibDHGvAXGGtfdmHfAQ==
Received: from pwj10 (pwj10.prod.google.com [10.241.219.74]) by wpaz5.hot.corp.google.com with ESMTP id oB7FWWKv020314 for ; Tue, 7 Dec 2010 07:32:33 -0800
Received: by pwj10 with SMTP id 10so22427pwj.30 for ; Tue, 07 Dec 2010 07:32:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/5IqtYCXyA77vhZpQLbGmmgbox/FW3re1DmzBpFVpfY=; b=XUgszNXF2k2rvzPWxzafl7DzDANFIFJ9JrGwxEBSLjnGzv5hkHn0OA9OjUQSDvA2eq Ab+Li3ZvAFeWqPeT//vA==
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=o0F+WD6Sfhp99WK5RC7YInhdMSE0W62Gx5rpSiOaQLXoaP/j4WQhueeJhYJTimVTqA 0dE+xEofsqjDbz+grw3A==
MIME-Version: 1.0
Received: by 10.142.246.11 with SMTP id t11mr968808wfh.362.1291735952603; Tue, 07 Dec 2010 07:32:32 -0800 (PST)
Received: by 10.143.18.14 with HTTP; Tue, 7 Dec 2010 07:32:32 -0800 (PST)
In-Reply-To:
References: <[email-masked]>
Date: Tue, 7 Dec 2010 15:32:32 +0000
Message-ID:
From: Ben Laurie
To: Paul Hoffman
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
Cc: [email-masked], Phillip Hallam-Baker
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 07 Dec 2010 15:31:14 -0000

On 7 December 2010 15:11, Paul Hoffman wrote:
> At 2:52 PM +0000 12/7/10, Ben Laurie wrote:
>> >... this line of thinking even more. =A0If you really don't intend for =
this to be used by UAs, then these should be scrapped as well.
>>
>>I do intend for these to be used by UAs.
>
> If two of the three co-authors on this draft cannot agree on the semantic=
s, then it is maybe premature for them to expect the Internet community to =
do so.

I don't think we disagree - the question is whether CAA is rich enough
to cover everything a UA might need. I think it might be, Phillip is
less certain.

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F9843A6996 for ; Tue, 7 Dec 2010 07:26:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.137
X-Spam-Level:
X-Spam-Status: No, score=-3.137 tagged_above=-999 required=5 tests=[AWL=0.462, 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 xOQO2LFaPzAR for ; Tue, 7 Dec 2010 07:26:26 -0800 (PST)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id C00EA3A696A for ; Tue, 7 Dec 2010 07:26:03 -0800 (PST)
Received: by gyd12 with SMTP id 12so9493gyd.31 for ; Tue, 07 Dec 2010 07:27:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=nFTNU3tB3y6c29QaQ13sWYqHkAjBKxWKaKUqKl0LnMs=; b=K/gsrNW8UZ/yx3R7VpXOP3g8BWsRup2/burpGgVWftXKDrruRwiVvxsmBngxsGC+Hu clwdsRYssrVD8E4WOOan4i8gK3Ih1ZS4stDk0uHdth+BlS/nL8ugZkZxMUN1WF0ZEKDC DrOVa94RRhc3tSuRDALAVNFObgjzG3RXuqAnI=
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:content-transfer-encoding; b=UlBV75a7xAKUxkq8t7Cet8j3z0hMU3OI9SKJSMi/5pb8DafqWOFsv1n5KU/uWmGfbQ d78Y1LU4UaQpkzf82tGHn+zi7YP+x8nY4WEIRctPzb3MizFIJ8KmWxBBCmy1wkMMkuN8 JTP08ejAU/n5wHa3BrsZmNoltKf1QKW3dyYY8=
MIME-Version: 1.0
Received: by 10.100.167.20 with SMTP id p20mr5010397ane.103.1291735635417; Tue, 07 Dec 2010 07:27:15 -0800 (PST)
Received: by 10.101.103.14 with HTTP; Tue, 7 Dec 2010 07:27:15 -0800 (PST)
In-Reply-To:
References: <[email-masked]>
Date: Tue, 7 Dec 2010 10:27:15 -0500
Message-ID:
From: Phillip Hallam-Baker
To: Paul Hoffman
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: [email-masked]
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 07 Dec 2010 15:26:29 -0000

That would be why the draft is marked EXPERIMENTAL.

We are all agreed on what we want to do here. As I mentioned in my
other post, design of an access control is much trickier than design
of an accountability control. And with an access control you may only
get one shot.

So while I am very confident that we have the issuer side completely
covered at this point, I am very cautious and I want to see how this
works in practice on the user agent side.

I suspect that it is likely that we will require more properties to
fully support relying party needs. I have the designs in hand, I can
easily write them up.

The reason that I do not want to do that right now is that I want to
see how much coverage of the requirements I can get from implementing
just the two properties given in CAA. And I can only do that with real
world experiments and feedback from the organizations who have told me
that they are interested in field trials.

On Tue, Dec 7, 2010 at 10:11 AM, Paul Hoffman wrote=
:
> At 7:57 AM -0500 12/7/10, Phillip Hallam-Baker wrote:
>>. . .
>>CAA-01 also presents a mechanism that may prove useful as the basis
>>for an access control. Or it may not. At this point we think we have
>>probably got as far as we can with that approach before we need to
>>attempt some field trials.
>>. . .
>>This is why the design is specified so as to allow sites to turn on
>>issue restrictions independent of client enforcement. It is also why
>>we found it essential to consider the client enforcement at the same
>>time. If the spec did not anticipate client enforcement and allow for
>>orderly introduction, there was a risk that some people would attempt
>>client enforcement on the basis of incomplete data.
>>_______________________________________________
>>keyassure mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/keyassure
>
> At 2:52 PM +0000 12/7/10, Ben Laurie wrote:
>> >... this line of thinking even more. =A0If you really don't intend for =
this to be used by UAs, then these should be scrapped as well.
>>
>>I do intend for these to be used by UAs.
>
> If two of the three co-authors on this draft cannot agree on the semantic=
s, then it is maybe premature for them to expect the Internet community to =
do so.
>
>
>
> --Paul Hoffman, Director
> --VPN Consortium
>

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

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CEDB3A680F for ; Tue, 7 Dec 2010 07:19:58 -0800 (PST)
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.475, 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 XYPgs+k6RMzI for ; Tue, 7 Dec 2010 07:19:57 -0800 (PST)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 1BA2A3A67F1 for ; Tue, 7 Dec 2010 07:19:56 -0800 (PST)
Received: by yxt33 with SMTP id 33so8285yxt.31 for ; Tue, 07 Dec 2010 07:21:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=T11m4eD0dh+OhoJjMC8U6cMunbA5AsMs4mDi6pqMGAQ=; b=Hq6jpAxmGbRWPzQKfglcvEuTfX9zUU901ueKgqXur7U7AGYEZ4F0n2HQYynLCcZQNX r2AG2UunUVqK8XwKXnjxRpnhT20qY/QDurDWCAYEdGgspcoVFgnFYsC7GGzSfDutmBU0 pVpW1tl/pN9p06agPJy2+FPBnmo13+7C8CxII=
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:content-transfer-encoding; b=AcJHjPCDlu0eqcURyJu0jqUdmuzZf+677vqAII1ZnKbcDyJ7k0Asn7Px1ZApqBXr2S Dvmg6oa/rvkeBrhdN6Mlg3dR3Qk8Od3IkFy++rVeyTmx+4bNd49yaN0syRZHCn1xHbXo JNNxQUj8gVjNFLaCRQwXcwtAFWGLrWjv37RiI=
MIME-Version: 1.0
Received: by 10.101.67.10 with SMTP id u10mr4188159ank.239.1291734679830; Tue, 07 Dec 2010 07:11:19 -0800 (PST)
Received: by 10.101.103.14 with HTTP; Tue, 7 Dec 2010 07:11:19 -0800 (PST)
In-Reply-To:
References:
Date: Tue, 7 Dec 2010 10:11:19 -0500
Message-ID:
From: Phillip Hallam-Baker
To: "Richard L. Barnes"
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: [email-masked]
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 07 Dec 2010 15:19:58 -0000

On Mon, Dec 6, 2010 at 11:09 PM, Richard L. Barnes wrote:

> Section 2.1: Specifying constraints by CP OID doesn't seem very effective=
. =A0A CA doesn't have to use only its own policy OIDs -- a bad CA could in=
sert an authorized CP OID into a certificate even if it's in someone else's=
arc. =A0Also, it's not clear whether the CP OID being specified here is re=
quired to be in the CA cert or the EE cert (although the wording makes me s=
uspect the former).

For user agent enforcement, the policy OID approach is not ideal. But
one important case is 'must be EV certificate'. Where there are in
fact mechanisms to enforce issue restrictions.

This is something we can get into further as we look at the relying
party problem in more detail.

> Section 2.1: The "path" property seems underspecified. =A0It seems like y=
ou probably want to constrain the "type" field so that any old OID can't be=
shoved in there. =A0It doesn't seem like it would be meaningful for me to =
specify a path attribute of type 2.5.4.51, id-at-houseIdentifier.

If a domain publishes an OID that a CA does not understand, they
cannot rely on it as an authorization entry.

I did think about adding restrictions there, but they don't matter on
the issue side and on the relying party side they are still going to
come down to 'ignore'.

> Section 2.1: The use of the acronym "ODI" is a little confusing next to "=
OID". =A0A forward reference to Appendix A would be helpful.

ODR? Object Digest Reference?

Pronounced 'Oh Dear'?

Yes, the name of the ODI is the biggest problem we have with it right now.

> Section 2: both "Certificate Policy Statement" and "Certificate Practices=
Statement" should be "Certification Practice Statement"

No, there is an important difference between the two and it is
relevant to this spec.

A CP is a statement of requirements. A CPS is a statement of
implementation that the audit is performed against.

A CP should have constant intent over time. The CPS will tend to vary
according to circumstances. So for example, the VeriSign class 3 CP
has been essentially constant over the years but the CPS has had
numerous revisions to change crypto requirements, describe key
management process changes and so on.

The OID relates to the CP and not to the CPS. But the CPS may have a
specific requirement to check the CAA records in specific ways.

These may have got switched over the course of editing, but that is
the intent at any rate.

> Section 3.1.2: I'm not sure what the phrase "To be honest" is doing there=
:)

It was a chat window by the looks.

I have updated the spec with the other changes so far.
--
Website: http://hallambaker.com/

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FFC33A6817 for ; Tue, 7 Dec 2010 07:10:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.407
X-Spam-Level:
X-Spam-Status: No, score=-101.407 tagged_above=-999 required=5 tests=[AWL=0.639, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 Ty3eOMZ35OPz for ; Tue, 7 Dec 2010 07:10:05 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 608DF3A67F3 for ; Tue, 7 Dec 2010 07:10:05 -0800 (PST)
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 oB7FBNRL009650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Dec 2010 08:11:24 -0700 (MST) (envelope-from [email-masked])
Mime-Version: 1.0
Message-Id:
In-Reply-To:
References: <[email-masked]>
Date: Tue, 7 Dec 2010 07:11:22 -0800
To: Phillip Hallam-Baker , Ben Laurie
From: Paul Hoffman
Content-Type: text/plain; charset="us-ascii"
Cc: [email-masked]
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 07 Dec 2010 15:10:06 -0000

At 7:57 AM -0500 12/7/10, Phillip Hallam-Baker wrote:
>. . .
>CAA-01 also presents a mechanism that may prove useful as the basis
>for an access control. Or it may not. At this point we think we have
>probably got as far as we can with that approach before we need to
>attempt some field trials.
>. . .
>This is why the design is specified so as to allow sites to turn on
>issue restrictions independent of client enforcement. It is also why
>we found it essential to consider the client enforcement at the same
>time. If the spec did not anticipate client enforcement and allow for
>orderly introduction, there was a risk that some people would attempt
>client enforcement on the basis of incomplete data.
>_______________________________________________
>keyassure mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/keyassure

At 2:52 PM +0000 12/7/10, Ben Laurie wrote:
> >... this line of thinking even more. If you really don't intend for this to be used by UAs, then these should be scrapped as well.
>
>I do intend for these to be used by UAs.

If two of the three co-authors on this draft cannot agree on the semantics, then it is maybe premature for them to expect the Internet community to do so.

--Paul Hoffman, Director
--VPN Consortium

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5FA53A6997 for ; Tue, 7 Dec 2010 06:51:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.977
X-Spam-Level:
X-Spam-Status: No, score=-109.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_HI=-8, 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 jPRLoVS+6oMG for ; Tue, 7 Dec 2010 06:51:15 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 943263A699D for ; Tue, 7 Dec 2010 06:51:15 -0800 (PST)
Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id oB7EqeKi030147 for ; Tue, 7 Dec 2010 06:52:40 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1291733560; bh=XK9IHu2lWc6UHbLceWFFG9so6KA=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=o7XJ8UyWDOnBfw7B4R4khgRrCscKoW3Gu5Nf7LvRfMGzsmcaBHmEOZ1PJEnfnwI0T 7fY+tkzB/OEh2DIaSCrTA==
Received: from pvg12 (pvg12.prod.google.com [10.241.210.140]) by kpbe14.cbf.corp.google.com with ESMTP id oB7EqcrF010179 for ; Tue, 7 Dec 2010 06:52:38 -0800
Received: by pvg12 with SMTP id 12so3654052pvg.26 for ; Tue, 07 Dec 2010 06:52:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=SktldNETdhAbjnV6Ggo1U5a7P7nu+dHdcT0J0cdcyUY=; b=dpvuwXbsQlOZXOc0gYwFUrwgsxLwHlQ3drQmDqWaXNdV4NYHf3SWN13xDbt57catA0 X6qqkf51u3KMGGii/awg==
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=wWHGSGXJEix7bNCpLsH6l+mA9oqH9Y+FqHLfFuPjnwxezwPxQqK2RzBFNAuNorH/y2 Z2oPiPMhBMulmmZJN+TQ==
MIME-Version: 1.0
Received: by 10.142.246.11 with SMTP id t11mr903918wfh.362.1291733558226; Tue, 07 Dec 2010 06:52:38 -0800 (PST)
Received: by 10.143.18.14 with HTTP; Tue, 7 Dec 2010 06:52:38 -0800 (PST)
In-Reply-To:
References:
Date: Tue, 7 Dec 2010 14:52:38 +0000
Message-ID:
From: Ben Laurie
To: "Richard L. Barnes"
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
Cc: [email-masked], Phillip Hallam-Baker
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 07 Dec 2010 14:51:17 -0000

On 7 December 2010 04:09, Richard L. Barnes wrote:
> The thing that's troubling me a little here is that it's not clear to me =
that it's possible to separate the CA-Auth part from the UA part, i.e., the=
part where the UA decides what certs to accept.
>
> A CAA record says that a CA is authorized to issue certs for a domain. =
=A0If you interpret this literally, it's a noop for UAs, since the UA knows=
what CAs it's willing to trust, regardless of this record. =A0However, it =
seems like it will be tempting for people to infer the contrapositive, that=
the absence of a record implies that a CA is not authorized -- especially =
if a domain has a CAA record for some other CA.
>
> If I read "relying party" as "UA", then the inclusion of the "Relying Par=
ty Authorization Set" concept and the "Relying Party" flag seem to encourag=
e this line of thinking even more. =A0If you really don't intend for this t=
o be used by UAs, then these should be scrapped as well.

I do intend for these to be used by UAs.

>
> Going beyond my conceptual worries, here are some technical comments and =
nits:
>
> Section 2.1: Specifying constraints by CP OID doesn't seem very effective=
. =A0A CA doesn't have to use only its own policy OIDs -- a bad CA could in=
sert an authorized CP OID into a certificate even if it's in someone else's=
arc. =A0Also, it's not clear whether the CP OID being specified here is re=
quired to be in the CA cert or the EE cert (although the wording makes me s=
uspect the former).

I also wondered about that, but the CA experts assured me it didn't
work like that. I had forgotten that I asked them to add an
explanation to the I-D.

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A4C73A6774 for ; Tue, 7 Dec 2010 04:55:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.154
X-Spam-Level:
X-Spam-Status: No, score=-3.154 tagged_above=-999 required=5 tests=[AWL=0.445, 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 6FRE-mQELPpY for ; Tue, 7 Dec 2010 04:55:56 -0800 (PST)
Received: from mail-gw0-f42.google.com (mail-gw0-f42.google.com [74.125.83.42]) by core3.amsl.com (Postfix) with ESMTP id 7ED703A659C for ; Tue, 7 Dec 2010 04:55:56 -0800 (PST)
Received: by gwb20 with SMTP id 20so10156728gwb.15 for ; Tue, 07 Dec 2010 04:57:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=NovF8IqclpqoGQ00lyn1Wc2hesFwnTy57nf+D3ZYkDA=; b=kbty+29Jzc+u6mRujQP9zyeMWaJot5bpZGUS3iA5NTiZcH0UxIuX7tqK30TyVB6AdY lu/JUDSOOsYxEwLLomTn8YKC/bm3tn8dtOrV8s5gV1E6FW7XFvqEbTAC38Txhu03WEBr K4ispRQOBoW1iCSt2FcensKnabLnbOIR7OU8w=
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=Saz0CWGKgcmUIzxzw2Gq2++Cb5TFa7bD20EoDB4sW29nrb5rq4RsYawa2yWTbPz0eU yifpFlo6XWZWmKRe7NVbEJnX0OTco15HDKuvjdsxBJpLU99WAd/9xbs3FBKMsAH0ekuw cckYbHxn7yMiWksFXm09J3wC1B/OIzzCamHl4=
MIME-Version: 1.0
Received: by 10.101.67.10 with SMTP id u10mr4091864ank.239.1291726641660; Tue, 07 Dec 2010 04:57:21 -0800 (PST)
Received: by 10.101.103.14 with HTTP; Tue, 7 Dec 2010 04:57:21 -0800 (PST)
In-Reply-To:
References: <[email-masked]>
Date: Tue, 7 Dec 2010 07:57:21 -0500
Message-ID:
From: Phillip Hallam-Baker
To: Zack Weinberg
Content-Type: text/plain; charset=ISO-8859-1
Cc: [email-masked]
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 07 Dec 2010 12:55:57 -0000

There are two modes of security control.

Network security has tended to be over-invested in access controls and
neglect accountability controls. An effective security system requires
both.

Access controls explicitly specify what is permitted and what is
denied. Since it is rarely possible to specify these exactly, the
range of actions allowed in an access control regime will almost
always be more than is desirable.

Accountability controls address the gaps. I can't stop people sending
spam but we can block the IP addresses used by spammers and we can
send them to jail if caught.

The issuer side of CAA is an accountability control. It does not make
mis-issue impossible but it does increase the risk of consequences in
the case of default.

As such, the fact that one CA could issue under a policy OID owned by
another is not relevant to the design. Any CA can ignore CAA records
if they are prepared to accept the consequences.

CAA-01 presents what we believe to be a complete specification as far
as the accountability controls for the issuer side are concerned. From
a design point of view this is somewhat easier since accountability
controls do not require the same degree of precision as access
controls.

CAA-01 also presents a mechanism that may prove useful as the basis
for an access control. Or it may not. At this point we think we have
probably got as far as we can with that approach before we need to
attempt some field trials.

I would think that we would almost certainly want to have more
expressive power in an access control design that is suitable for
client enforcement. For example, protocol specific properties. But
that adds some complexity to the design. For example CAA records are
intended to be used with wildcards which means that they cannot be
used as protocol prefixed records as well.

There are many reasons for wanting to do the issuer side first. One of
the most important is that we can get deployment very quickly. All the
CAs need is the RR code assignment and we can start putting that
protection in place.

Another important reason to do the issuer side first is that it is
going to help the larger sites bring their systems under control. A
lot of larger enterprises found DKIM deployment hard because they did
not know where all their mail servers are. The reason CAA is needed is
because sites have the same problem with SSL certs.

This is why the design is specified so as to allow sites to turn on
issue restrictions independent of client enforcement. It is also why
we found it essential to consider the client enforcement at the same
time. If the spec did not anticipate client enforcement and allow for
orderly introduction, there was a risk that some people would attempt
client enforcement on the basis of incomplete data.

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0056F3A68C2 for ; Mon, 6 Dec 2010 22:18:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25ybdzIuAOyj for ; Mon, 6 Dec 2010 22:18:55 -0800 (PST)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 2515C3A6919 for ; Mon, 6 Dec 2010 22:18:51 -0800 (PST)
Received: by wyf23 with SMTP id 23so12086130wyf.31 for ; Mon, 06 Dec 2010 22:20:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=jhQ8WcbUMcnGMcJV9BKJNr14qsbxJBMFM/qgsBM7FVA=; b=m6OS22BmKYhc3IGOQtwLFv0Yo9FN1xjZ2wy8DeKB/t9orG5eZrTUbgK7a0w86DW3x/ PoBXVQf9csv+OJmfbpecmchm9NmFV+GM+o+c23C1u2grM6e+hay/ewO4+20MSsc+OpSQ yKpDT0kmObO0NjRoiQXz4Eg4fMsZFwysUFgK8=
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=srs2deTqijFqw/ahrqRwJZEgUZZI8amI684s5tCBnUFmWx+5GnZtPRf0njcKREC+HT I/Vev9vLRI0ZRb8Ek/mzCaFHqnk+JpC5mCWF42De6Tuqml7ZmWrNFtQNmevDVm5rr4dA AxohsPop7pUmJ6qcYTYHh8CF2sGPdgHIp12WE=
MIME-Version: 1.0
Received: by 10.227.12.8 with SMTP id v8mr6747228wbv.157.1291702816361; Mon, 06 Dec 2010 22:20:16 -0800 (PST)
Sender: [email-masked]
Received: by 10.227.133.149 with HTTP; Mon, 6 Dec 2010 22:20:16 -0800 (PST)
In-Reply-To:
References: <[email-masked]>
Date: Mon, 6 Dec 2010 22:20:16 -0800
X-Google-Sender-Auth: OqwrPper4QPZSlgfhnu324SKeXw
Message-ID:
From: Zack Weinberg
To: Paul Wouters
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: [email-masked]
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 07 Dec 2010 06:18:58 -0000

On Mon, Dec 6, 2010 at 10:16 PM, Paul Wouters wrote:
> On Tue, 7 Dec 2010, Richard L. Barnes wrote:
>
>> To be fair, I think there is a separate problem that this draft is tryin=
g
>> to solve. =C2=A0As I understand it, it seems like it kind of gives CAs a=
way to
>> have their customers provide them a signed statement that they authorize=
the
>> CA to issue a certificate. =C2=A0So it's more about assuring the issuanc=
e process
>> than the UA acceptance process.
>
> Correct. It uses DNSSEC authentication and the path of trust from
> the DNSSEC Root key to the domain to reduce the amount of authorized
> Certificate Agencies that can sign for your record from "a whole lot"
> (I've heard numbers of 1500 but that mighe be an exaggeration) to 1 (or
> perhaps a few, though it is unclear what one would do if the few disagree=
)

But if the UA doesn't check, I see no actual gain in security to the
end user. Ilauri's analysis matches mine.

zw

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 592813A6924 for ; Mon, 6 Dec 2010 22:15:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSUFTNB038Rc for ; Mon, 6 Dec 2010 22:15:26 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 119243A6920 for ; Mon, 6 Dec 2010 22:15:22 -0800 (PST)
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 020FEC4B8; Tue, 7 Dec 2010 01:16:43 -0500 (EST)
Date: Tue, 7 Dec 2010 01:16:43 -0500 (EST)
From: Paul Wouters
To: "Richard L. Barnes"
In-Reply-To: <[email-masked]>
Message-ID:
References: <[email-masked]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: [email-masked]
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 07 Dec 2010 06:15:30 -0000

On Tue, 7 Dec 2010, Richard L. Barnes wrote:

> To be fair, I think there is a separate problem that this draft is trying to solve. As I understand it, it seems like it kind of gives CAs a way to have their customers provide them a signed statement that they authorize the CA to issue a certificate. So it's more about assuring the issuance process than the UA acceptance process.

Correct. It uses DNSSEC authentication and the path of trust from
the DNSSEC Root key to the domain to reduce the amount of authorized
Certificate Agencies that can sign for your record from "a whole lot"
(I've heard numbers of 1500 but that mighe be an exaggeration) to 1 (or
perhaps a few, though it is unclear what one would do if the few disagree)

This CA in turn then, via another trust model, depending on the CA
and the requested cert type, some backed by legal process, vouches your
cert used in your domain. These lists of CA's are preloaded either on a
network/host or on an application level, without much hierarchy. You either
trust what they sign, or you don't. Often the only limit on these is that
they cannot sign another CA. Hence the desire to restrict them via DNSSEC
after such incidents as the false Microsoft cert, the *\0 cert valid for
everything, or the rapidssl crafted certificate signature swap.

Paul

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6185F3A6915 for ; Mon, 6 Dec 2010 22:01:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.197
X-Spam-Level:
X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=0.402, 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 DUtQkq+EGBQV for ; Mon, 6 Dec 2010 22:01:37 -0800 (PST)
Received: from emh05.mail.saunalahti.fi (emh05.mail.saunalahti.fi [62.142.5.111]) by core3.amsl.com (Postfix) with ESMTP id D6E103A6914 for ; Mon, 6 Dec 2010 22:01:36 -0800 (PST)
Received: from saunalahti-vams (vs3-11.mail.saunalahti.fi [62.142.5.95]) by emh05-2.mail.saunalahti.fi (Postfix) with SMTP id 5B5EE8BD9D; Tue, 7 Dec 2010 08:03:00 +0200 (EET)
Received: from emh03.mail.saunalahti.fi ([62.142.5.109]) by vs3-11.mail.saunalahti.fi ([62.142.5.95]) with SMTP (gateway) id A00E82574A7; Tue, 07 Dec 2010 08:03:00 +0200
Received: from LK-Perkele-V2 (a88-112-50-174.elisa-laajakaista.fi [88.112.50.174]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id EDEDC158A65; Tue, 7 Dec 2010 08:02:55 +0200 (EET)
Date: Tue, 7 Dec 2010 08:04:50 +0200
From: Ilari Liusvaara
To: Zack Weinberg
Message-ID: <[email-masked]>
References:
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To:
User-Agent: Mutt/1.5.20 (2009-06-14)
Sender: Ilari Liusvaara
X-Antivirus: VAMS
Cc: [email-masked], Phillip Hallam-Baker
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 07 Dec 2010 06:01:38 -0000

On Mon, Dec 06, 2010 at 09:03:09PM -0800, Zack Weinberg wrote:
> On Mon, Dec 6, 2010 at 8:09 PM, Richard L. Barnes wrote:
>
> From my perspective, this (and all other similar DNS records) are
> *completely useless* unless they do influence which certs a UA
> ultimately decides to accept.

There are three cases:
1) Mistaken issuance by CAA-following CA.
2) Mistaken issuance by non-CAA-following CA.
3) Maliscous issuance.

Non-client-enforceable statement is completely useless against 3),
and would only help against 1). Unfortunately, CAs (and how many there
effectively are, nobody knows!) that mistakenly issue tend to be
those otherwise careless ones that probably wouldn't follow CAA.

Mistaken issuance should be rare. How often maliscous issuance happens
is unknown (mostly because X.509 provodes no provision to audit
certificates used at large scale, making maliscous issuance hard
to detect).

> And exclusive assertions ("these CAs/these specific certs, and no
> others") are enormously more useful than nonexclusive ones
> ("these CAs, or maybe some other CA if you feel like it")
> -- to the point where I'm not sure I would bother adding
> support to a UA for anything *but* exclusive assertions.

I haven't run across case where one would need nonexclusive
assertion, assuming asserting higher-up certificates is possible.

With asserting higher-up certificates, one has to be careful with
bad sub-CA attacks.

-Ilari

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EFDA3A6904 for ; Mon, 6 Dec 2010 21:35:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.421
X-Spam-Level:
X-Spam-Status: No, score=-102.421 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16cewn7x-feZ for ; Mon, 6 Dec 2010 21:35:29 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 2E0E83A6905 for ; Mon, 6 Dec 2010 21:35:26 -0800 (PST)
Received: from [128.89.255.46] (port=54298) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PPqEM-0005cK-Fh; Tue, 07 Dec 2010 00:36:50 -0500
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: "Richard L. Barnes"
In-Reply-To:
Date: Tue, 7 Dec 2010 00:36:45 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <[email-masked]>
References:
To: Zack Weinberg
X-Mailer: Apple Mail (2.1082)
Cc: [email-masked], Phillip Hallam-Baker
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 07 Dec 2010 05:35:37 -0000

To be fair, I think there is a separate problem that this draft is =
trying to solve. As I understand it, it seems like it kind of gives CAs =
a way to have their customers provide them a signed statement that they =
authorize the CA to issue a certificate. So it's more about assuring =
the issuance process than the UA acceptance process.

(Caveat: Not the author, may be misunderstanding.)

--Richard

On Dec 7, 2010, at 12:03 AM, Zack Weinberg wrote:

> On Mon, Dec 6, 2010 at 8:09 PM, Richard L. Barnes =
wrote:
>> The thing that's troubling me a little here is that it's not clear to =
me that it's possible to separate the CA-Auth part from the UA part, =
i.e., the part where the UA decides what certs to accept.
>=20
> =46rom my perspective, this (and all other similar DNS records) are
> *completely useless* unless they do influence which certs a UA
> ultimately decides to accept. And exclusive assertions ("these
> CAs/these specific certs, and no others") are enormously more useful
> than nonexclusive ones ("these CAs, or maybe some other CA if you feel
> like it") -- to the point where I'm not sure I would bother adding
> support to a UA for anything *but* exclusive assertions.
>=20
> I'm a UA guy, so maybe I just don't know about the thing these would
> be useful for if they're not useful to me.
>=20
> zw

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27D2128C0F5 for ; Mon, 6 Dec 2010 21:01:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofdfXaICWFJk for ; Mon, 6 Dec 2010 21:01:45 -0800 (PST)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 19AA63A68FC for ; Mon, 6 Dec 2010 21:01:44 -0800 (PST)
Received: by wwa36 with SMTP id 36so13501369wwa.13 for ; Mon, 06 Dec 2010 21:03:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=EefkDiV/A4730MtyjriTppMna0PuG6agow23Nl997M0=; b=iE56AQ2IvrAH7T7QNawMlmim6bvdb2Uv9dt9a4ENCwasqCLO+y7wS8s1EGEi9eF5qu EKGACVvVRVeldMAxtkp7ZrjFXy6ECeMXSjCnyAmdOw8C970Hx2e7kkphciasjI2K8TKM NhvGhbWk3+dx1Jc2pqUOIaQlNPmT3aCXluhYg=
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=UhLOjSe1bw9NR8x7uk43kaHPNHge9DeG/JnwGMVmHKtoCrls6VuE8gZdz1PAevo/IB YFt7VnAKsmLN6V/2VcFcij5bBBDfqpJnf+H5hRRlvCrrOctw4rTVHaG+H4CnYNy1HE98 tH5pLFhlVcthbA3hTBBI4N3hyBKEQmgXb3q5I=
MIME-Version: 1.0
Received: by 10.227.11.80 with SMTP id s16mr6700290wbs.215.1291698189197; Mon, 06 Dec 2010 21:03:09 -0800 (PST)
Sender: [email-masked]
Received: by 10.227.133.149 with HTTP; Mon, 6 Dec 2010 21:03:09 -0800 (PST)
In-Reply-To:
References:
Date: Mon, 6 Dec 2010 21:03:09 -0800
X-Google-Sender-Auth: R4hpLDITtbvfXBVX1ghFJoRI_Ts
Message-ID:
From: Zack Weinberg
To: "Richard L. Barnes"
Content-Type: text/plain; charset=UTF-8
Cc: [email-masked], Phillip Hallam-Baker
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 07 Dec 2010 05:01:46 -0000

On Mon, Dec 6, 2010 at 8:09 PM, Richard L. Barnes wrote:
> The thing that's troubling me a little here is that it's not clear to me that it's possible to separate the CA-Auth part from the UA part, i.e., the part where the UA decides what certs to accept.

>From my perspective, this (and all other similar DNS records) are
*completely useless* unless they do influence which certs a UA
ultimately decides to accept. And exclusive assertions ("these
CAs/these specific certs, and no others") are enormously more useful
than nonexclusive ones ("these CAs, or maybe some other CA if you feel
like it") -- to the point where I'm not sure I would bother adding
support to a UA for anything *but* exclusive assertions.

I'm a UA guy, so maybe I just don't know about the thing these would
be useful for if they're not useful to me.

zw

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C53A3A68F8 for ; Mon, 6 Dec 2010 20:08:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.413
X-Spam-Level:
X-Spam-Status: No, score=-102.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 1K3ZvJSnHUlJ for ; Mon, 6 Dec 2010 20:08:34 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 0D9F23A683F for ; Mon, 6 Dec 2010 20:08:33 -0800 (PST)
Received: from [128.89.255.46] (port=53962) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PPosG-000JjP-DX; Mon, 06 Dec 2010 23:09:57 -0500
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: "Richard L. Barnes"
In-Reply-To:
Date: Mon, 6 Dec 2010 23:09:51 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id:
References:
To: Phillip Hallam-Baker
X-Mailer: Apple Mail (2.1082)
Cc: [email-masked]
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 07 Dec 2010 04:08:36 -0000

The thing that's troubling me a little here is that it's not clear to me =
that it's possible to separate the CA-Auth part from the UA part, i.e., =
the part where the UA decides what certs to accept.

A CAA record says that a CA is authorized to issue certs for a domain. =
If you interpret this literally, it's a noop for UAs, since the UA knows =
what CAs it's willing to trust, regardless of this record. However, it =
seems like it will be tempting for people to infer the contrapositive, =
that the absence of a record implies that a CA is not authorized -- =
especially if a domain has a CAA record for some other CA.

If I read "relying party" as "UA", then the inclusion of the "Relying =
Party Authorization Set" concept and the "Relying Party" flag seem to =
encourage this line of thinking even more. If you really don't intend =
for this to be used by UAs, then these should be scrapped as well.

Going beyond my conceptual worries, here are some technical comments and =
nits:

Section 2.1: Specifying constraints by CP OID doesn't seem very =
effective. A CA doesn't have to use only its own policy OIDs -- a bad =
CA could insert an authorized CP OID into a certificate even if it's in =
someone else's arc. Also, it's not clear whether the CP OID being =
specified here is required to be in the CA cert or the EE cert (although =
the wording makes me suspect the former).

Section 2.1: The "path" property seems underspecified. It seems like =
you probably want to constrain the "type" field so that any old OID =
can't be shoved in there. It doesn't seem like it would be meaningful =
for me to specify a path attribute of type 2.5.4.51, =
id-at-houseIdentifier.

Section 2.1: The use of the acronym "ODI" is a little confusing next to =
"OID". A forward reference to Appendix A would be helpful.

Section 2: both "Certificate Policy Statement" and "Certificate =
Practices Statement" should be "Certification Practice Statement"

Section 3.1.2: I'm not sure what the phrase "To be honest" is doing =
there :)

--Richard =20

On Dec 6, 2010, at 7:02 PM, Phillip Hallam-Baker wrote:

> OK, consider the word 'anticompetitive' struck.
>=20
>=20
> Given the number of moving parts here, I would really prefer to try to
> avoid making moving ahead on the CA-Auth part dependent on deciding a
> wider scheme.
>=20
> The client side enforcement is a somewhat larger problem and the
> problem there is that once code is deployed it is much harder to dig
> ourselves out if we decide we want to do it differently.
>=20
>=20
> The only parties that need to be involved in the CA-auth part is the
> domains and the CAs. So if we decide that we want to take a different
> approach on the client side enforcement front, we can easily require
> the CAs to check an extra record as well.
>=20
> That said, I am pretty confident that tag-value pairs with a
> criticality flag should be enough to cover what we need. And we can
> use additional RRs if we need to.
>=20
>=20
> On Mon, Dec 6, 2010 at 4:46 PM, Richard L. Barnes =
wrote:
>> Just to be clear about scope/placement, I think this draft is pretty =
clearly within the domain of this working group. I realize that the =
intended audience for these records is CAs, but they could just as =
easily be interpreted by clients and integrated into the TLS certificate =
acceptance process.
>>=20
>> That said, on a quick read, this draft has some good ideas. =
Certainly, the notion of a domain indicating what CA(s) MUST be in the =
chain seems useful. Given that there are other useful constraints that =
are being discussed, however, I would prefer that this document be =
integrated in a more general framework for making statements about what =
certificates will be presented for a domain. (I'm also a little leery =
of the use of words like "anticompetitive" in a specification; "abuse of =
the critical flag" might be a little more appropriate.)
>>=20
>> In any case, though, thanks to the authors for putting the draft =
forward. Looking forward to doing a more thorough review and to more =
discussion,
>>=20
>> --Richard
>>=20
>>=20
>> On Dec 6, 2010, at 12:09 PM, Phillip Hallam-Baker wrote:
>>=20
>>> All, a new version of CAA is available. This has been developed with
>>> the aid of Ben Laurie and others at Google. This is an EXPERIMENTAL
>>> proposal and is not intended to pre-empt or foreclose discussion =
here.
>>>=20
>>> http://tools.ietf.org/html/draft-hallambaker-donotissue-01
>>>=20
>>>=20
>>> This version has significant changes from the last one. Some of =
which
>>> may be relevant to KIDNS depending on what use cases are to be
>>> considered. It should be noted however that the original use case =
for
>>> CAA is outside the scope proposed for KIDNS, although the scheme
>>> proposed is capable of use for purposes that are in scope.
>>>=20
>>> In particular, the Object Digest Identifier is a general purpose
>>> mechanism for providing a cryptographically authenticated reference =
to
>>> an object instance by means of an ASN.1 structure as follows:
>>>=20
>>> DNSCAA DEFINITIONS ::=3D
>>>=20
>>> BEGIN
>>>=20
>>> ObjectDigestIdentifier ::=3D SEQUENCE {
>>> type OBJECT IDENTIFIER,
>>> digestAlgorithm OBJECT IDENTIFIER,
>>> digest OCTET STRING
>>> }
>>>=20
>>> END
>>>=20
>>> Thus the ODI of the certificate used in the example in Base64 format =
is:
>>>=20
>>> MDIGA1UEJQYJYIZIAWUDBAIBBCAXzJgPaoT7FeXaP
>>> zKv6mI2D0yilif+7WhzmhMGLe/oBA=3D=3D
>>>=20
>>> This construction provides protection against a digest substitution
>>> attack and a semantic substitution attack without a major increase =
in
>>> the size of the digest value. While people may argue over the
>>> relevance of such attacks to specific applications, it is the type =
of
>>> issue that I much prefer to simply anticipate and dispose of in
>>> advance.
>>>=20
>>> The use of ASN.1 for this purpose is ideal since it is a very =
compact
>>> format and widely used and supported in crypto libraries. While a =
full
>>> ASN.1 implementation is considerably tedious and complex, the ODI =
only
>>> uses a small subset that can be easily implemented without much
>>> additional code. In effect the type and digestAlgorithm fields only
>>> add a fixed constant string to the front of the items in question.
>>>=20
>>>=20
>>> It would be rather nice if ODI digests could be emitted by
>>> cryptographic applications as a general purpose 'fingerprint' that =
is
>>> usable in multiple contexts. So the emitted digest can just be cut =
and
>>> pasted from one place to another.
>>>=20
>>> For example, it would be nice if we could have something like the
>>> following in an HTML file:
>>>=20
>>> >> =
odi=3D"digest:MDIGA1UEJQYJYIZIAWUDBAIBBCAXzJgPaoT7FeXaPzKv6mI2D0yilif+7Whz=
mhMGLe/oBA=3D=3D"/>
>>>=20
>>> We have just created a transcluded reference to the object blah.jpg
>>> which is authenticated by a secure digest value. The client could
>>> reject the content if it does not match.
>>>=20
>>>=20
>>> This approach is slightly less efficient space wise than the use of
>>> DNSSEC code points for this purpose but has the advantage that there
>>> is no need for additional registry maintenance effort when adding =
new
>>> algorithms. There are very good reasons for wanting to keep the set =
of
>>> digest algorithms used in DNSSEC small. There are less good reasons
>>> for applying that to certificates. So I would not be surprised if =
the
>>> DNSEXT group would end up preferring this approach on consideration.
>>>=20
>>> --
>>> Website: http://hallambaker.com/
>>> _______________________________________________
>>> keyassure mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/keyassure
>>=20
>>=20
>=20
>=20
>=20
> --=20
> Website: http://hallambaker.com/

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D8F928C0DB for ; Mon, 6 Dec 2010 16:00:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.111
X-Spam-Level:
X-Spam-Status: No, score=-3.111 tagged_above=-999 required=5 tests=[AWL=0.488, 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 Vg72v1GsO19s for ; Mon, 6 Dec 2010 16:00:44 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id B338D3A68D5 for ; Mon, 6 Dec 2010 16:00:44 -0800 (PST)
Received: by ywk9 with SMTP id 9so319040ywk.31 for ; Mon, 06 Dec 2010 16:02:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=CIglLGerMBztcgjQ3HNfBkgfL190JA/OZNzMgXQoe0U=; b=Vf6sUmRG+9fXOM806WhAXZwkjc1Af72CAzJC2A7vJ7Ul0aVClgWSRP2eS6MX1Wpcfi 4HpildUGWaAxQoDwFUKEjcrPE6Vp+L4ebKm8S0fJ5fsN59SMy0eIQKga66fgLQNEjVeY ftnQN54IGHcwGUZ3tDMNtUitYZY78uWpqXy8g=
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:content-transfer-encoding; b=gL0d1UwADI/PmAbwxsWbGmOOL0cpBR8hu5/8/342P91Fq8fX6IhQjPDfxBM8JmG+cV Q767E4fD1JlpCJdnbiGu+jmtYnl9hr0RKs496St9NkMLQ5BmeCFBfOofFEdrPYGEWO2C ahOWvJ+t/WtRL3pBAFlBCq/zS3nndLyP38/Tw=
MIME-Version: 1.0
Received: by 10.100.96.1 with SMTP id t1mr3916783anb.137.1291680128887; Mon, 06 Dec 2010 16:02:08 -0800 (PST)
Received: by 10.101.103.14 with HTTP; Mon, 6 Dec 2010 16:02:08 -0800 (PST)
In-Reply-To:
References:
Date: Mon, 6 Dec 2010 19:02:08 -0500
Message-ID:
From: Phillip Hallam-Baker
To: "Richard L. Barnes"
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: [email-masked]
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 07 Dec 2010 00:00:47 -0000

OK, consider the word 'anticompetitive' struck.

Given the number of moving parts here, I would really prefer to try to
avoid making moving ahead on the CA-Auth part dependent on deciding a
wider scheme.

The client side enforcement is a somewhat larger problem and the
problem there is that once code is deployed it is much harder to dig
ourselves out if we decide we want to do it differently.

The only parties that need to be involved in the CA-auth part is the
domains and the CAs. So if we decide that we want to take a different
approach on the client side enforcement front, we can easily require
the CAs to check an extra record as well.

That said, I am pretty confident that tag-value pairs with a
criticality flag should be enough to cover what we need. And we can
use additional RRs if we need to.

On Mon, Dec 6, 2010 at 4:46 PM, Richard L. Barnes wrote:
> Just to be clear about scope/placement, I think this draft is pretty clea=
rly within the domain of this working group. =A0I realize that the intended=
audience for these records is CAs, but they could just as easily be interp=
reted by clients and integrated into the TLS certificate acceptance process=
.
>
> That said, on a quick read, this draft has some good ideas. =A0Certainly,=
the notion of a domain indicating what CA(s) MUST be in the chain seems us=
eful. =A0Given that there are other useful constraints that are being discu=
ssed, however, I would prefer that this document be integrated in a more ge=
neral framework for making statements about what certificates will be prese=
nted for a domain. =A0(I'm also a little leery of the use of words like "an=
ticompetitive" in a specification; "abuse of the critical flag" might be a =
little more appropriate.)
>
> In any case, though, thanks to the authors for putting the draft forward.=
=A0Looking forward to doing a more thorough review and to more discussion,
>
> --Richard
>
>
> On Dec 6, 2010, at 12:09 PM, Phillip Hallam-Baker wrote:
>
>> All, a new version of CAA is available. This has been developed with
>> the aid of Ben Laurie and others at Google. This is an EXPERIMENTAL
>> proposal and is not intended to pre-empt or foreclose discussion here.
>>
>> http://tools.ietf.org/html/draft-hallambaker-donotissue-01
>>
>>
>> This version has significant changes from the last one. Some of which
>> may be relevant to KIDNS depending on what use cases are to be
>> considered. It should be noted however that the original use case for
>> CAA is outside the scope proposed for KIDNS, although the scheme
>> proposed is capable of use for purposes that are in scope.
>>
>> In particular, the Object Digest Identifier is a general purpose
>> mechanism for providing a cryptographically authenticated reference to
>> an object instance by means of an ASN.1 structure as follows:
>>
>> =A0 DNSCAA DEFINITIONS ::=3D
>>
>> =A0 BEGIN
>>
>> =A0 =A0ObjectDigestIdentifier ::=3D SEQUENCE {
>> =A0 =A0 =A0type =A0 =A0 =A0 =A0 =A0 =A0 OBJECT IDENTIFIER,
>> =A0 =A0 =A0digestAlgorithm =A0OBJECT IDENTIFIER,
>> =A0 =A0 =A0digest =A0 =A0 =A0 =A0 =A0 OCTET STRING
>> =A0 =A0}
>>
>> =A0 END
>>
>> Thus the ODI of the certificate used in the example in Base64 format is:
>>
>> MDIGA1UEJQYJYIZIAWUDBAIBBCAXzJgPaoT7FeXaP
>> =A0 zKv6mI2D0yilif+7WhzmhMGLe/oBA=3D=3D
>>
>> This construction provides protection against a digest substitution
>> attack and a semantic substitution attack without a major increase in
>> the size of the digest value. While people may argue over the
>> relevance of such attacks to specific applications, it is the type of
>> issue that I much prefer to simply anticipate and dispose of in
>> advance.
>>
>> The use of ASN.1 for this purpose is ideal since it is a very compact
>> format and widely used and supported in crypto libraries. While a full
>> ASN.1 implementation is considerably tedious and complex, the ODI only
>> uses a small subset that can be easily implemented without much
>> additional code. In effect the type and digestAlgorithm fields only
>> add a fixed constant string to the front of the items in question.
>>
>>
>> It would be rather nice if ODI digests could be emitted by
>> cryptographic applications as a general purpose 'fingerprint' that is
>> usable in multiple contexts. So the emitted digest can just be cut and
>> pasted from one place to another.
>>
>> For example, it would be nice if we could have something like the
>> following in an HTML file:
>>
>> > odi=3D"digest:MDIGA1UEJQYJYIZIAWUDBAIBBCAXzJgPaoT7FeXaPzKv6mI2D0yilif+7W=
hzmhMGLe/oBA=3D=3D"/>
>>
>> We have just created a transcluded reference to the object blah.jpg
>> which is authenticated by a secure digest value. The client could
>> reject the content if it does not match.
>>
>>
>> This approach is slightly less efficient space wise than the use of
>> DNSSEC code points for this purpose but has the advantage that there
>> is no need for additional registry maintenance effort when adding new
>> algorithms. There are very good reasons for wanting to keep the set of
>> digest algorithms used in DNSSEC small. There are less good reasons
>> for applying that to certificates. So I would not be surprised if the
>> DNSEXT group would end up preferring this approach on consideration.
>>
>> --
>> Website: http://hallambaker.com/
>> _______________________________________________
>> keyassure mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/keyassure
>
>

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

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97BEB3A68D6 for ; Mon, 6 Dec 2010 13:57:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.122
X-Spam-Level:
X-Spam-Status: No, score=-2.122 tagged_above=-999 required=5 tests=[AWL=0.477, 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 0ZUk4hcffPSr for ; Mon, 6 Dec 2010 13:57:32 -0800 (PST)
Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id 305B53A68CB for ; Mon, 6 Dec 2010 13:57:32 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=EvceqpSEiexd/BQFpy/PCFsQUM9Up1sMfBTPLScvx+3pjQofGP0j2PD9HPv5Wf7x; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.45] (helo=elwamui-polski.atl.sa.earthlink.net) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1PPj5E-0007Cd-Al for [email-masked]; Mon, 06 Dec 2010 16:58:56 -0500
Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Mon, 6 Dec 2010 16:58:53 -0500
Message-ID: <[email-masked]>
Date: Mon, 6 Dec 2010 15:58:54 -0600 (GMT-06:00)
From: "Jeffrey A. Williams"
To: [email-masked]
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e5196068841e8deb4db2c1a4649d3f0a54ccf5eb2350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.45
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: "Jeffrey A. Williams"
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 06 Dec 2010 21:57:33 -0000

Richard and Phillip,

I agree with Rich's evaluation and one critical replacement
for 'anticompetitive' as well. Nicely done Phillip and Ben,
ect.!

-----Original Message-----
>From: "Richard L. Barnes"
>Sent: Dec 6, 2010 3:46 PM
>To: Phillip Hallam-Baker
>Cc: [email-masked]
>Subject: Re: [keyassure] Revised version of CAA
>
>Just to be clear about scope/placement, I think this draft is pretty clearly within the domain of this working group. I realize that the intended audience for these records is CAs, but they could just as easily be interpreted by clients and integrated into the TLS certificate acceptance process.
>
>That said, on a quick read, this draft has some good ideas. Certainly, the notion of a domain indicating what CA(s) MUST be in the chain seems useful. Given that there are other useful constraints that are being discussed, however, I would prefer that this document be integrated in a more general framework for making statements about what certificates will be presented for a domain. (I'm also a little leery of the use of words like "anticompetitive" in a specification; "abuse of the critical flag" might be a little more appropriate.)
>
>In any case, though, thanks to the authors for putting the draft forward. Looking forward to doing a more thorough review and to more discussion,
>
>--Richard
>
>
>On Dec 6, 2010, at 12:09 PM, Phillip Hallam-Baker wrote:
>
>> All, a new version of CAA is available. This has been developed with
>> the aid of Ben Laurie and others at Google. This is an EXPERIMENTAL
>> proposal and is not intended to pre-empt or foreclose discussion here.
>>
>> http://tools.ietf.org/html/draft-hallambaker-donotissue-01
>>
>>
>> This version has significant changes from the last one. Some of which
>> may be relevant to KIDNS depending on what use cases are to be
>> considered. It should be noted however that the original use case for
>> CAA is outside the scope proposed for KIDNS, although the scheme
>> proposed is capable of use for purposes that are in scope.
>>
>> In particular, the Object Digest Identifier is a general purpose
>> mechanism for providing a cryptographically authenticated reference to
>> an object instance by means of an ASN.1 structure as follows:
>>
>> DNSCAA DEFINITIONS ::=
>>
>> BEGIN
>>
>> ObjectDigestIdentifier ::= SEQUENCE {
>> type OBJECT IDENTIFIER,
>> digestAlgorithm OBJECT IDENTIFIER,
>> digest OCTET STRING
>> }
>>
>> END
>>
>> Thus the ODI of the certificate used in the example in Base64 format is:
>>
>> MDIGA1UEJQYJYIZIAWUDBAIBBCAXzJgPaoT7FeXaP
>> zKv6mI2D0yilif+7WhzmhMGLe/oBA==
>>
>> This construction provides protection against a digest substitution
>> attack and a semantic substitution attack without a major increase in
>> the size of the digest value. While people may argue over the
>> relevance of such attacks to specific applications, it is the type of
>> issue that I much prefer to simply anticipate and dispose of in
>> advance.
>>
>> The use of ASN.1 for this purpose is ideal since it is a very compact
>> format and widely used and supported in crypto libraries. While a full
>> ASN.1 implementation is considerably tedious and complex, the ODI only
>> uses a small subset that can be easily implemented without much
>> additional code. In effect the type and digestAlgorithm fields only
>> add a fixed constant string to the front of the items in question.
>>
>>
>> It would be rather nice if ODI digests could be emitted by
>> cryptographic applications as a general purpose 'fingerprint' that is
>> usable in multiple contexts. So the emitted digest can just be cut and
>> pasted from one place to another.
>>
>> For example, it would be nice if we could have something like the
>> following in an HTML file:
>>
>> > odi="digest:MDIGA1UEJQYJYIZIAWUDBAIBBCAXzJgPaoT7FeXaPzKv6mI2D0yilif+7WhzmhMGLe/oBA=="/>
>>
>> We have just created a transcluded reference to the object blah.jpg
>> which is authenticated by a secure digest value. The client could
>> reject the content if it does not match.
>>
>>
>> This approach is slightly less efficient space wise than the use of
>> DNSSEC code points for this purpose but has the advantage that there
>> is no need for additional registry maintenance effort when adding new
>> algorithms. There are very good reasons for wanting to keep the set of
>> digest algorithms used in DNSSEC small. There are less good reasons
>> for applying that to certificates. So I would not be surprised if the
>> DNSEXT group would end up preferring this approach on consideration.
>>
>> --
>> Website: http://hallambaker.com/
>> _______________________________________________
>> keyassure mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/keyassure
>
>_______________________________________________
>keyassure mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/keyassure
Regards,
Jeffrey A. Williams
"Obedience of the law is the greatest freedom" -
Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
Network Eng. SR. Eng. Network data security
ABA member in good standing member ID 01257402
E-Mail [email-masked]
Phone: 214-244-4827

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52D7928C0D9 for ; Mon, 6 Dec 2010 13:45:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.404
X-Spam-Level:
X-Spam-Status: No, score=-102.404 tagged_above=-999 required=5 tests=[AWL=0.195, 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 3-hHAcWTDQlf for ; Mon, 6 Dec 2010 13:45:22 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 043EF28C0D7 for ; Mon, 6 Dec 2010 13:45:22 -0800 (PST)
Received: from dhcp89-089-014.bbn.com ([128.89.89.14]:53107) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PPitR-000Gje-U1; Mon, 06 Dec 2010 16:46:45 -0500
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: "Richard L. Barnes"
In-Reply-To:
Date: Mon, 6 Dec 2010 16:46:36 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id:
References:
To: Phillip Hallam-Baker
X-Mailer: Apple Mail (2.1082)
Cc: [email-masked]
Subject: Re: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 06 Dec 2010 21:45:24 -0000

Just to be clear about scope/placement, I think this draft is pretty =
clearly within the domain of this working group. I realize that the =
intended audience for these records is CAs, but they could just as =
easily be interpreted by clients and integrated into the TLS certificate =
acceptance process. =20

That said, on a quick read, this draft has some good ideas. Certainly, =
the notion of a domain indicating what CA(s) MUST be in the chain seems =
useful. Given that there are other useful constraints that are being =
discussed, however, I would prefer that this document be integrated in a =
more general framework for making statements about what certificates =
will be presented for a domain. (I'm also a little leery of the use of =
words like "anticompetitive" in a specification; "abuse of the critical =
flag" might be a little more appropriate.)

In any case, though, thanks to the authors for putting the draft =
forward. Looking forward to doing a more thorough review and to more =
discussion,

--Richard

On Dec 6, 2010, at 12:09 PM, Phillip Hallam-Baker wrote:

> All, a new version of CAA is available. This has been developed with
> the aid of Ben Laurie and others at Google. This is an EXPERIMENTAL
> proposal and is not intended to pre-empt or foreclose discussion here.
>=20
> http://tools.ietf.org/html/draft-hallambaker-donotissue-01
>=20
>=20
> This version has significant changes from the last one. Some of which
> may be relevant to KIDNS depending on what use cases are to be
> considered. It should be noted however that the original use case for
> CAA is outside the scope proposed for KIDNS, although the scheme
> proposed is capable of use for purposes that are in scope.
>=20
> In particular, the Object Digest Identifier is a general purpose
> mechanism for providing a cryptographically authenticated reference to
> an object instance by means of an ASN.1 structure as follows:
>=20
> DNSCAA DEFINITIONS ::=3D
>=20
> BEGIN
>=20
> ObjectDigestIdentifier ::=3D SEQUENCE {
> type OBJECT IDENTIFIER,
> digestAlgorithm OBJECT IDENTIFIER,
> digest OCTET STRING
> }
>=20
> END
>=20
> Thus the ODI of the certificate used in the example in Base64 format =
is:
>=20
> MDIGA1UEJQYJYIZIAWUDBAIBBCAXzJgPaoT7FeXaP
> zKv6mI2D0yilif+7WhzmhMGLe/oBA=3D=3D
>=20
> This construction provides protection against a digest substitution
> attack and a semantic substitution attack without a major increase in
> the size of the digest value. While people may argue over the
> relevance of such attacks to specific applications, it is the type of
> issue that I much prefer to simply anticipate and dispose of in
> advance.
>=20
> The use of ASN.1 for this purpose is ideal since it is a very compact
> format and widely used and supported in crypto libraries. While a full
> ASN.1 implementation is considerably tedious and complex, the ODI only
> uses a small subset that can be easily implemented without much
> additional code. In effect the type and digestAlgorithm fields only
> add a fixed constant string to the front of the items in question.
>=20
>=20
> It would be rather nice if ODI digests could be emitted by
> cryptographic applications as a general purpose 'fingerprint' that is
> usable in multiple contexts. So the emitted digest can just be cut and
> pasted from one place to another.
>=20
> For example, it would be nice if we could have something like the
> following in an HTML file:
>=20
> =
odi=3D"digest:MDIGA1UEJQYJYIZIAWUDBAIBBCAXzJgPaoT7FeXaPzKv6mI2D0yilif+7Whz=
mhMGLe/oBA=3D=3D"/>
>=20
> We have just created a transcluded reference to the object blah.jpg
> which is authenticated by a secure digest value. The client could
> reject the content if it does not match.
>=20
>=20
> This approach is slightly less efficient space wise than the use of
> DNSSEC code points for this purpose but has the advantage that there
> is no need for additional registry maintenance effort when adding new
> algorithms. There are very good reasons for wanting to keep the set of
> digest algorithms used in DNSSEC small. There are less good reasons
> for applying that to certificates. So I would not be surprised if the
> DNSEXT group would end up preferring this approach on consideration.
>=20
> --=20
> Website: http://hallambaker.com/
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5D233A682C for ; Mon, 6 Dec 2010 09:08:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.105
X-Spam-Level:
X-Spam-Status: No, score=-3.105 tagged_above=-999 required=5 tests=[AWL=0.494, 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 YLHLoeaaEEmk for ; Mon, 6 Dec 2010 09:08:15 -0800 (PST)
Received: from mail-gw0-f42.google.com (mail-gw0-f42.google.com [74.125.83.42]) by core3.amsl.com (Postfix) with ESMTP id 0ECCE3A681D for ; Mon, 6 Dec 2010 09:08:14 -0800 (PST)
Received: by gwb20 with SMTP id 20so9760481gwb.15 for ; Mon, 06 Dec 2010 09:09:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=FNnSCR71YaNClWBB+17rhEEpKTSVp4VJ2ICLVMwP2os=; b=eq+EKmcEisCxiNkxiNfLREuuH0tyjtDf2d6t6mYAW+76Bzj1ZNixdCEgJaiIyMRgmf lAHBqu5KcnDY5DGuw4ibLJCchEFPVUVm7Cf+EBVMrvdnZM1H0X3eU4gsEcp1FjF9qsaO 0VlXPL9/CgGoxeWnF/q5G2lV28wSIKC3ZcGEY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Iqvf95FyxaPSVN2h3KPLeF8M7B7Vax+zALeNUopoUgVAMAgsdHyIZfv/kOwLxhIIKO AtFCv2QTR+UsXYVSp5/1/O0D3ZYUXyxCXF+41ahdDSQxwhCNl7dUPWd6O0xJuRc1fyDi cZX/9fEECvMtW2u53eG8EPD5t+ewMtNEgwy6s=
MIME-Version: 1.0
Received: by 10.101.163.35 with SMTP id q35mr4093348ano.171.1291655378323; Mon, 06 Dec 2010 09:09:38 -0800 (PST)
Received: by 10.100.196.13 with HTTP; Mon, 6 Dec 2010 09:09:38 -0800 (PST)
Date: Mon, 6 Dec 2010 12:09:38 -0500
Message-ID:
From: Phillip Hallam-Baker
To: [email-masked]
Content-Type: text/plain; charset=ISO-8859-1
Subject: [keyassure] Revised version of CAA
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Mon, 06 Dec 2010 17:08:17 -0000

All, a new version of CAA is available. This has been developed with
the aid of Ben Laurie and others at Google. This is an EXPERIMENTAL
proposal and is not intended to pre-empt or foreclose discussion here.

http://tools.ietf.org/html/draft-hallambaker-donotissue-01

This version has significant changes from the last one. Some of which
may be relevant to KIDNS depending on what use cases are to be
considered. It should be noted however that the original use case for
CAA is outside the scope proposed for KIDNS, although the scheme
proposed is capable of use for purposes that are in scope.

In particular, the Object Digest Identifier is a general purpose
mechanism for providing a cryptographically authenticated reference to
an object instance by means of an ASN.1 structure as follows:

DNSCAA DEFINITIONS ::=

BEGIN

ObjectDigestIdentifier ::= SEQUENCE {
type OBJECT IDENTIFIER,
digestAlgorithm OBJECT IDENTIFIER,
digest OCTET STRING
}

END

Thus the ODI of the certificate used in the example in Base64 format is:

MDIGA1UEJQYJYIZIAWUDBAIBBCAXzJgPaoT7FeXaP
zKv6mI2D0yilif+7WhzmhMGLe/oBA==

This construction provides protection against a digest substitution
attack and a semantic substitution attack without a major increase in
the size of the digest value. While people may argue over the
relevance of such attacks to specific applications, it is the type of
issue that I much prefer to simply anticipate and dispose of in
advance.

The use of ASN.1 for this purpose is ideal since it is a very compact
format and widely used and supported in crypto libraries. While a full
ASN.1 implementation is considerably tedious and complex, the ODI only
uses a small subset that can be easily implemented without much
additional code. In effect the type and digestAlgorithm fields only
add a fixed constant string to the front of the items in question.

It would be rather nice if ODI digests could be emitted by
cryptographic applications as a general purpose 'fingerprint' that is
usable in multiple contexts. So the emitted digest can just be cut and
pasted from one place to another.

For example, it would be nice if we could have something like the
following in an HTML file:

We have just created a transcluded reference to the object blah.jpg
which is authenticated by a secure digest value. The client could
reject the content if it does not match.

This approach is slightly less efficient space wise than the use of
DNSSEC code points for this purpose but has the advantage that there
is no need for additional registry maintenance effort when adding new
algorithms. There are very good reasons for wanting to keep the set of
digest algorithms used in DNSSEC small. There are less good reasons
for applying that to certificates. So I would not be surprised if the
DNSEXT group would end up preferring this approach on consideration.

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

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB0813A6803 for ; Wed, 1 Dec 2010 14:44:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLGRZJ+864pB for ; Wed, 1 Dec 2010 14:44:47 -0800 (PST)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id F2E813A6802 for ; Wed, 1 Dec 2010 14:44:45 -0800 (PST)
Received: by gyb13 with SMTP id 13so4200075gyb.31 for ; Wed, 01 Dec 2010 14:46:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=kqXZ+Rz5vu9ZA27Eo0fJKhLgUmzMJTNShkOdOCEpoB0=; b=N4kdYAtxPRLwNIoFp/1pAZH/fPFeddXkYW4oOdViLpyt4giNgIIVtVDntKsw1mL8MJ taer2mKweAowD1nGLTXAbHF3dEW3Y2jH2m1gx/YCHm8NsGhxtIFhG4BWLs6xtswx4dRG zFFiBDlRtlO7iOY/etFmLqiYoPSxALRgmSzs8=
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=sAaW60cQ4mO8EiRhJ1iHpoNwOt4SE+BpJTS3fs1Yye5FMzwzpH1wdwuJOjk+7AHgtr 8UujTRKQzDmIqTqTezS5UisS/FAwrO4vWynsd/EJJ0hRbVhvG3NwaGmdyLmr7YT0DaS5 2KMf17Q9iiuFiFoEG/stMftMgPW/PjlPjOAr8=
MIME-Version: 1.0
Received: by 10.42.173.71 with SMTP id q7mr1934751icz.331.1291243559677; Wed, 01 Dec 2010 14:45:59 -0800 (PST)
Sender: [email-masked]
Received: by 10.42.227.193 with HTTP; Wed, 1 Dec 2010 14:45:59 -0800 (PST)
In-Reply-To:
References: <[email-masked]>
Date: Wed, 1 Dec 2010 17:45:59 -0500
X-Google-Sender-Auth: IKzAxLO78VieUXcbKr1JA_uq_Jo
Message-ID:
From: Adam Langley
To: Paul Wouters
Content-Type: text/plain; charset=UTF-8
Cc: [email-masked]
Subject: Re: [keyassure] Chrome and DNSSEC-TLS
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 01 Dec 2010 22:44:48 -0000

On Wed, Dec 1, 2010 at 5:25 PM, Paul Wouters wrote:
> Apparently the test code can be enabled if you start Chrome wih
> --enable-dnssec-certs
> and you will see requests for TXT RR's with the DO bit set.

You used to, but I broke the code. I'm waiting for an RR type
assignment for CAA before fixing it.

AGL

--
Adam Langley [email-masked] http://www.imperialviolet.org

Return-Path:
X-Original-To: [email-masked]
Delivered-To: [email-masked]
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B8F63A67D3 for ; Wed, 1 Dec 2010 14:23:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YzpPsJy3rwe6 for ; Wed, 1 Dec 2010 14:23:54 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 10B653A67DA for ; Wed, 1 Dec 2010 14:23:53 -0800 (PST)
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 C0249C3EF for ; Wed, 1 Dec 2010 17:25:05 -0500 (EST)
Date: Wed, 1 Dec 2010 17:25:05 -0500 (EST)
From: Paul Wouters
To: [email-masked]
In-Reply-To: <[email-masked]>
Message-ID:
References: <[email-masked]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Subject: [keyassure] Chrome and DNSSEC-TLS
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 01 Dec 2010 22:23:55 -0000

FYI, I had not seen this myself before

http://www.imperialviolet.org/2010/08/16/dnssectls.html

Apparently the test code can be enabled if you start Chrome wih --enable-dnssec-certs
and you will see requests for TXT RR's with the DO bit set.

Paul