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...
- [websec] FYI: related drafts on securing TSL and … Tobias Gondrom
- Re: [websec] FYI: related drafts on securing TSL … Chris Palmer
- Re: [websec] FYI: related drafts on securing TSL … Adam Langley