Re: [TLS] Cert Enumeration and Key Assurance With DNSSEC

Phillip Hallam-Baker <hallam@gmail.com> Mon, 04 October 2010 18:51 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2320C3A7060; Mon, 4 Oct 2010 11:51:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.969
X-Spam-Level:
X-Spam-Status: No, score=-1.969 tagged_above=-999 required=5 tests=[AWL=-0.271, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHf4tMwDf4tV; Mon, 4 Oct 2010 11:51:43 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 3A9DD3A7003; Mon, 4 Oct 2010 11:51:42 -0700 (PDT)
Received: by wwj40 with SMTP id 40so3258969wwj.13 for <multiple recipients>; Mon, 04 Oct 2010 11:52:37 -0700 (PDT)
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=I3lUvKSRyItTF2en5jtBOjGAwODcJJq0hzJkFtdzR/g=; b=AwsG807XXqD5nOiqjUBgw4UQSAo3wPVYp0a8tZP3jJiFLIL/fEuWUg4UwuD1xMWw8Z m9yVCw/kwfgW/fEFWN8BgVNU3h2019W8YDS0sxymSK3jTsI9Soz0h9afqSLFYkVJkH5B OVDPfNT4AG8VLoteuqBQfa6NMqON2YBGRxDJA=
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=S5lApjMLl+Eoqz+LBQBAGRdu4hGHMxAPVuzxqqAznwP/iP+QqeMeyuftqn3VoQ4Wd5 H0kkEHV6Pr3L5HcjIvAAMAdD9KyAeSMrojgjNnbcV4xBaDeb2Ij+06oUy1vKuMMse0V5 sHqMHDpErxhS/dyb420uZjzAtxjc54gTfZXUk=
MIME-Version: 1.0
Received: by 10.216.0.76 with SMTP id 54mr8106423wea.49.1286218357526; Mon, 04 Oct 2010 11:52:37 -0700 (PDT)
Received: by 10.216.166.9 with HTTP; Mon, 4 Oct 2010 11:52:37 -0700 (PDT)
In-Reply-To: <4CAA00EF.2040107@nic.cz>
References: <AANLkTinRWJZr7huuG+Ovh3sCCUnVZAghggAzmq7g6ERx@mail.gmail.com> <4CAA00EF.2040107@nic.cz>
Date: Mon, 4 Oct 2010 14:52:37 -0400
Message-ID: <AANLkTimGcQ3MwaBpdXJDxBJkG0JZACEB8e-QatHtr8S_@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: =?ISO-8859-2?Q?Ond=F8ej_Sur=FD?= <ondrej.sury@nic.cz>
Content-Type: multipart/alternative; boundary=001485f626f04dd22d0491cf0cd1
Cc: pkix@ietf.org, dnsop@ietf.org, tls@ietf.org, saag@ietf.org
Subject: Re: [TLS] Cert Enumeration and Key Assurance With DNSSEC
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Oct 2010 18:51:46 -0000

The reason I did so was that I did not believe that the initial presentation
of KEYASSURE to the wider Internet community gave an accurate or full
description of what the intended proposal was.

Since neither of the proposers took any notice of my repeated requests to
correct this situation, I decided that it was time to do so myself.

My original understanding from the announcement made was that 'assurance'
meant to provide additional mechanisms for binding keys to DNS names. It has
since turned out that what is being proposed is very different and has
significant impact across the whole IETF security area.


My problem with KEYASSURE is precisely the fact that people have not been
given the 'full picture'.

Even now after three drafts, the key-linkage draft does not actualy specify
that the purpose of the protocol is to enable a site to specify which
certificates are valid for the site by enumeration of all valid certs. That
is merely an unremarked consequence of the algorithm.


2010/10/4 Ondřej Surý <ondrej.sury@nic.cz>

> Phillip,
>
> you present your views by cross-posting several other IETF mailing list
> without posting this to keyassure@ietf.org.  This doesn't give potential
> readers full picture about what's happening in the keyassure and what is the
> general consensus in the list.
>
> So please all - if you want to respond to Phillip's message, first go to
> keyassure mailing list archive[1], then join the the list[2] and comment
> there.  I don't think we want to fill our inboxes with this discussion
> (which should really happen in keyassure) in several copies.
>
> While we value input from other working groups it is already hard to follow
> the discussion in one mailing list and when it splits to many, it will be
> just a mess.
>
> Ondrej
>
> 1. http://www.ietf.org/mail-archive/web/keyassure/
> 2. https://www.ietf.org/mailman/listinfo/keyassure
>
>
> On 1.10.2010 17:29, Phillip Hallam-Baker wrote:
>
>> For the past month I have been participating in the KEYASSURE discussions.
>>
>> One aspect of those discussions that was not made clear in the original
>> notice sent out is that the group is not only considering key assurance,
>> the proposals made are also intended to have security policy semantics.
>>
>> This was not apparent to me from reading the list announcement, the
>> initial proposed charter or the Internet drafts. I have asked the
>> organizers of the group to clarify the matter in the wider IETF
>> community but they have not done so.
>>
>>
>> In particular I am very concerned about the particular approach being
>> taken to security policy. What the proposers are attempting to do is to
>> create a mechanism that allows a site that only uses one particular high
>> assurance CA to 'protect' themselves against SSL certificates being
>> issued by low assurance CAs.
>>
>> As such, this is an objective I approve of and is one that I would like
>> to see supported in a generalized security policy. It should be possible
>> for a site to make security policy statements of the form 'all valid
>> PKIX certs for example.com <http://example.com> have cert X in the
>>
>> validation path'.
>>
>>
>> What I object to is the approach being taken which is to use DNSSEC to
>> replace PKIX certificate validation entirely.
>>
>> Now the proponents are trying to downplay this by saying that 'all' they
>> are doing is to tell people to 'ignore' PKIX validation. But that
>> approach really offends my sense of layering.
>>
>> Worse still, the proponents refuse to allow any method of shutting this
>> system off. So if I have a site where I want to use DNSSEC validated
>> certificates on the mail server, deployment is going to impact my Web
>> server.
>>
>>
>> Specifically the proposal amounts to using the DNS CERT record to
>> publish a fingerprint of all the certificates permitted for use with TLS
>> at a specific domain:
>>
>> example.com <http://example.com> CERT TLSFP 0 0 <digest cert 1>
>> example.com <http://example.com> CERT TLSFP 0 0 <digest cert 2>
>>
>>
>> It is proposed to replace current TLS certificate processing semantics
>> with the following:
>>
>> 1) Query for CERT record at example.com <http://example.com>
>>
>> 2) If no CERT record with TLSFP certificate type exists then perform
>> normal PKIX validation and return that result
>> 3) Otherwise attempt to match the TLS end entity certificate with one of
>> the fingerprints specified in the published TLSFP RRs
>> 4) If a match is found return VALID, otherwise return INVALID
>>
>> Note here that if there is a TLSFP RR that it takes precedence over PKIX
>> processing rules.
>>
>> There should of course be DNSSEC validation performed in that process as
>> well, but the authors have not explained how that is meant to work in
>> the context of their proposal so I left it out.
>>
>>
>> The defenses made for this approach are of the form 'you have to wear
>> big pants to play this game'. In other words if people are going to
>> administer these systems and not be burned they are going to have to
>> understand what they are doing. I do not consider this a responsible
>> approach to protocol design.
>>
>> What I would prefer is to have systems that do not need to be
>> administered by people at all. That is not possible when the approach
>> has hidden side effects that cannot be anticipated by scripts.
>>
>>
>> I am very much committed to the idea of doing security policy. But this
>> is not an approach I can support. Any policy mechanism has to be
>> orthogonal to the key validation strategy in my view. I should be able
>> to use any DNS security policy mechanism that the IETF endorses with
>> PKIX certificate processing semantics.
>>
>> I have proposed an alternative approach in
>>
>> http://tools.ietf.org/html/draft-hallambaker-esrv-00
>>
>> This does not currently contain a mechanism to express trust
>> restrictions but is designed to be extensible to support such. When I
>> proposed ESRV I was unaware that the KEYASSURE proposal was intended to
>> have a security policy aspect at all. It is still not made explicit in
>> their draft.
>>
>>
>> Using the revised version of ESRV I am currently writing, a security
>> policy of the form 'always use TLS with any protocol at example.com
>> <http://example.com>' would have the form:
>>
>> example.com <http://example.com> ESRV "tls=required"
>>
>>
>> A security policy that was specific to http would be expressed as:
>>
>> example.com <http://example.com> ESRV "prefix=_http._tcp"
>> _http._tcp.example.com <http://tcp.example.com> ESRV "tls=required"
>>
>> or
>>
>> example.com <http://example.com> ESRV "prefix=*"
>> _http._tcp.example.com <http://tcp.example.com> ESRV "tls=required"
>>
>>
>> The reason for this change from the -00 version is that this approach
>> supports CNAMEs.
>>
>>
>> The reason that I started with the requirement to use SSL is that
>> security policy relating to trust criteria is meaningless until you have
>> a statement that use of SSL is required.
>>
>>
>> I have no objection to doing security policy. But I do have a real
>> objection to an approach that negates PKIX semantics as the TLSFP
>> approach does.
>>
>>
>>    -------- Original Message --------
>>    Subject: New Non-WG Mailing List: keyassure -- Key Assurance With
>> DNSSEC
>>    Date: Tue, 17 Aug 2010 11:36:02 -0700 (PDT)
>>    From: IETF Secretariat <ietf-secretariat@ietf.org
>>    <mailto:ietf-secretariat@ietf.org>>
>>    To: IETF Announcement list <ietf-announce@ietf.org
>>    <mailto:ietf-announce@ietf.org>>
>>    CC: keyassure@ietf.org <mailto:keyassure@ietf.org>,
>>    ondrej.sury@nic.cz <mailto:ondrej.sury@nic.cz>, warren@kumari.net
>>    <mailto:warren@kumari.net>
>>
>>    A new IETF non-working group email list has been created.
>>
>>    List address: keyassure@ietf.org <mailto:keyassure@ietf.org>
>>
>>    Archive:
>>    http://www.ietf.org/mail-archive/web/keyassure/current/maillist.html
>>    To subscribe: https://www.ietf.org/mailman/listinfo/keyassure
>>
>>    Description: This list is for discussion relating to using
>>    DNSSEC-protected DNS queries to get greater assurance for keys and
>>    certificates that are passed in existing IETF protocols. The main
>>    idea is that a relying party can get additional information about a
>>    domain name to eliminate the need for using a certificate in a
>>    protocol, to eliminate the need for sending certificates in the
>>    protocol if they are optional, and/or to assure that the certificate
>>    given in a protocol is associated with the domain name used by the
>>    application. In all three cases, the application associates the key
>>    or key fingerprint securely retrieved from the DNS with the domain
>>    name that was used in the DNS query.
>>
>>    For additional information, please contact the list administrators.
>>
>>
>>    --
>>      Ondřej Surý
>>      vedoucí výzkumu/Head of R&D department
>>      -------------------------------------------
>>      CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
>>      Americka 23, 120 00 Praha 2, Czech Republic
>>      mailto:ondrej.sury@nic.cz <mailto:ondrej.sury@nic.cz> http://nic.cz/
>>
>>      tel:+420.222745110       fax:+420.222745112
>>      -------------------------------------------
>>    _______________________________________________
>>    saag mailing list
>>    saag@ietf.org <mailto:saag@ietf.org>
>>
>>    https://www.ietf.org/mailman/listinfo/saag
>>
>>
>>
>>
>> --
>> Website: http://hallambaker.com/
>>
>>
>
> --
>  Ondřej Surý
>  vedoucí výzkumu/Head of R&D department
>  -------------------------------------------
>  CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
>  Americka 23, 120 00 Praha 2, Czech Republic
>  mailto:ondrej.sury@nic.cz    http://nic.cz/
>  tel:+420.222745110       fax:+420.222745112
>  -------------------------------------------
>



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