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

Phillip Hallam-Baker <hallam@gmail.com> Fri, 01 October 2010 16:14 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 96AC53A6BEB; Fri, 1 Oct 2010 09:14:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.26
X-Spam-Level:
X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[AWL=0.338, 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 7tVkwBv1qNhb; Fri, 1 Oct 2010 09:14:13 -0700 (PDT)
Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id A2C483A6ABB; Fri, 1 Oct 2010 09:14:12 -0700 (PDT)
Received: by ewy26 with SMTP id 26so1709648ewy.31 for <multiple recipients>; Fri, 01 Oct 2010 09:15:00 -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=FqE/B5aGA/1LaXPUUcHMvnug5zrpYbDddp7UuNuCXHg=; b=ICZUHN62KPh0ADie7F1A26tX1rvZTbV5k7XIHSieapFYRJXPGmmdFHwbWfLgHYz/x3 cizp1entErFDC/0GDSaeY4mpDNSQp8+ysudg812GirpFzUYAZjkK74bYEA33/OpxYlSF CNLjziPSUNpIGwzlPu7KTLyKRmnKu6fQblyHg=
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=GtF2eMCuvWEqfU8Fda3/G7SYthUI1l+JV4zRf7t6SqxLT3vcCiQk0StJ4EYm1VFPY2 zJXRMG++ehdGIXrxDb1BplI0cInvB4CsSu+lwfw9lerhUFfV5s+uMJ2FWBPZ7aM3Q8EU YcYTnKWXT50piOm11kinrWTQ7NWiSXHIJLsVM=
MIME-Version: 1.0
Received: by 10.216.47.80 with SMTP id s58mr4717009web.15.1285949700189; Fri, 01 Oct 2010 09:15:00 -0700 (PDT)
Received: by 10.216.166.9 with HTTP; Fri, 1 Oct 2010 09:15:00 -0700 (PDT)
In-Reply-To: <AANLkTim6RovNvnPvd5MA9syG-OmgM1HMWJ16YUKR2FVp@mail.gmail.com>
References: <AANLkTinRWJZr7huuG+Ovh3sCCUnVZAghggAzmq7g6ERx@mail.gmail.com> <AANLkTim6RovNvnPvd5MA9syG-OmgM1HMWJ16YUKR2FVp@mail.gmail.com>
Date: Fri, 1 Oct 2010 12:15:00 -0400
Message-ID: <AANLkTi=KpxWzCVUd9U+pdshbxueyLDCEr4=x13LxXcfY@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Ben Laurie <benl@google.com>
Content-Type: multipart/alternative; boundary=001485f28010142d3d0491907f83
Cc: pkix@ietf.org, dnsop@ietf.org, saag@ietf.org, tls@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: Fri, 01 Oct 2010 16:14:15 -0000

On Fri, Oct 1, 2010 at 12:02 PM, Ben Laurie <benl@google.com> wrote:

> On 1 October 2010 08:29, Phillip Hallam-Baker <hallam@gmail.com> wrote:
> > 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 can't agree with this. If a user types an https URL, say, then
> there's every reason security policy should apply despite the lack of
> a statement that SSL is required.


I regard typing https as being a policy statement.

I don't think anyone could use the TLSFP scheme as a substitute for DV
validation for about a decade. As of today 0% of the deployed browsers
support TLSFP so if someone types https and the cert is not DV validated
they are going to see the self-signed cert warning box.


What I would see as being much more practical is a scheme that works
automatically when the user types in http.

If the browser does not support the DNS mechanism then the user goes to the
site unencrypted as they do today.

If the browser and site both support the DNS mechanism, the communication is
encrypted and the user need not know anything about it.


I would like to get rid of the padlock entirely and eventually go to a user
experience when the user is only warned when going to one of the few
remaining sites that does NOT offer free transparent security.

> 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.
>
> Then I'd like to see your proposal for _optionally_ allowing PKIX to
> be overridden.
>

_http._tcp.example.com ESRV "TLS=required CERTFP=required"

This is still a potential shoot-in-foot situation for humans. But I can
write a script that can extract the necessary information to do the job
right.

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