Re: [websec] FYI: related drafts on securing TSL and certificates

Chris Palmer <palmer@google.com> Thu, 15 December 2011 20:03 UTC

Return-Path: <palmer@google.com>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1ED21F84F9 for <websec@ietfa.amsl.com>; Thu, 15 Dec 2011 12:03:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.777
X-Spam-Level:
X-Spam-Status: No, score=-102.777 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNiuv9q-s4pb for <websec@ietfa.amsl.com>; Thu, 15 Dec 2011 12:03:37 -0800 (PST)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8421221F8557 for <websec@ietf.org>; Thu, 15 Dec 2011 12:03:37 -0800 (PST)
Received: by wgbdr13 with SMTP id dr13so3592255wgb.13 for <websec@ietf.org>; Thu, 15 Dec 2011 12:03:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:x-system-of-record:content-type; bh=J34eZ6jJ4Bp3scr5QUIzdPN79GHKAL5rvAiM9/r/dD4=; b=hqhPezuwXzLHYDAsOSGPtVHVbD6i1D7wujNL510u7pyjw2AT9wE/etBtNRhgI6birX +kXWsKxJQSbuT+T+Pcyg==
Received: by 10.227.208.13 with SMTP id ga13mr4434966wbb.4.1323979416611; Thu, 15 Dec 2011 12:03:36 -0800 (PST)
MIME-Version: 1.0
Received: by 10.227.208.13 with SMTP id ga13mr4434946wbb.4.1323979416464; Thu, 15 Dec 2011 12:03:36 -0800 (PST)
Received: by 10.216.227.94 with HTTP; Thu, 15 Dec 2011 12:03:36 -0800 (PST)
In-Reply-To: <4EE98A18.3010101@gondrom.org>
References: <4EE98A18.3010101@gondrom.org>
Date: Thu, 15 Dec 2011 12:03:36 -0800
Message-ID: <CAOuvq233ADfb8wTJC5R1Epo=OF6wGqgphveDVybAwfAKxsxrXQ@mail.gmail.com>
From: Chris Palmer <palmer@google.com>
To: Tobias Gondrom <tobias.gondrom@gondrom.org>
X-System-Of-Record: true
Content-Type: text/plain; charset="UTF-8"
Cc: websec@ietf.org
Subject: Re: [websec] FYI: related drafts on securing TSL and certificates
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Dec 2011 20:03:38 -0000

On Wed, Dec 14, 2011 at 9:48 PM, Tobias Gondrom
<tobias.gondrom@gondrom.org> wrote:

> www.links.org/files/CertificateAuthorityTransparencyandAuditability.pdf
>
> https://www.eff.org/deeplinks/2011/11/sovereign-keys-proposal-make-https-and-email-more-secure
>
> From my perspective this does not conflict with but could complement the
> current pinning and HSTS approach.

I have been tangentially involved in the SK proposal (I worked with
Peter at EFF), and CT is partly motivated by SK. I *think* I speak for
all of us when I say that we regard public key pinning as a useful
short-term mitigation, but that some kind of public log system is The
Real Solution. I agree there is no conflict, and that the approaches
are complementary. Once The Real Solution is in place, we should be
able to let go of short-term mitigations like pinning.

Whether or not HSTS is "merely" a short-term mitigation that would be
superceded by The Real Solution, I don't know. It might well turn out
that we will always need to distinguish between "HTTPS is available,
and make sure you use the right public keys" and "HTTPS is mandatory,
and make sure you use the right public keys". Obviously, HTTPS should
be universal, making the available/mandatory distinction meaningless.
But until then...