Re: [websec] Consensus call: Issue #57 (max-max-age)
Chris Palmer <palmer@google.com> Wed, 29 May 2013 00:23 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 A4A9D11E80BA for <websec@ietfa.amsl.com>; Tue, 28 May 2013 17:23:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
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 U4Rq0SL8bvHr for <websec@ietfa.amsl.com>; Tue, 28 May 2013 17:23:54 -0700 (PDT)
Received: from mail-ve0-x236.google.com (mail-ve0-x236.google.com [IPv6:2607:f8b0:400c:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id E4EE111E80A4 for <websec@ietf.org>; Tue, 28 May 2013 17:23:48 -0700 (PDT)
Received: by mail-ve0-f182.google.com with SMTP id ox1so2061473veb.13 for <websec@ietf.org>; Tue, 28 May 2013 17:23:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=OA5vk52GsDE4rChTVfh4kLjcvXIA5kc39K5vz8Ehic4=; b=f6ouJUTQLTM1TaIg/wrCWf0MdPOp5o/3SBPsoogyQ8llQNY2FS5xLJ5NmqB61S1wrk 8DLLlsurHNsvDmdZ5CeLNGVY3YQkY415nE738o9Xy8nhIIzA+CNdYOocSittDDqt9rFm QPVS7j87oco1bds+J6lZzF2ISC8JJTQ2IhfnYJkoT13PZBexx5pKUn5ruRhHtX4F5v5Y L7tuvVyt5ki4X/ZsBH8mpNsnwDjOn7fvAUQAXSCTO/1Nigro5O+9seh8IUoYv70B95/J 7tb/KP5YdqrAisdkpfY/ps4MWkwvSVhyL9R3qObISzYoV8rHyY8eL0gqzrl9HiOWnRku z1BA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=OA5vk52GsDE4rChTVfh4kLjcvXIA5kc39K5vz8Ehic4=; b=I5mZgyGwomIvLPNZg5d3lkXS/WZx2mFiTjMBjTEEJrAg3y2IRInfUPwM34w6lYWecq 5f3LxDC98lUieFYeNGx39ep/hFRq6QZ2F4riDAiwqpgxxOrRk4ZBo5yCJsrWCb1cqPpL w8rXGYHyxIIynagGrfowD6eC5h/CNyj88qjpHpf2O/GvHhIx6VPeYCgOgfhxweZXTuV7 or8x8VW8Ec86YlwTAVNP+jwS4yYR27vK2wSEqlFQLYJuGQDrcM/zAOorHpRFXnVfVLdx 7dsMKHoaN/s50ZkBPaBfgUtod/jm1U+vEK3z+auykanV1c5nU6BUQ4OQpSJss/UtWi1Y 4VtQ==
MIME-Version: 1.0
X-Received: by 10.220.192.3 with SMTP id do3mr180655vcb.16.1369787028333; Tue, 28 May 2013 17:23:48 -0700 (PDT)
Received: by 10.220.75.138 with HTTP; Tue, 28 May 2013 17:23:48 -0700 (PDT)
In-Reply-To: <51A49A5C.5080002@gondrom.org>
References: <43C5DE99-43EB-42FC-8F61-24F9A9429FD1@checkpoint.com> <CA+cU71=Q_QkHqiQ95AZgw8Bi7U_mgCi4icMypwFUp1C6i=apUA@mail.gmail.com> <518EE510.9060600@it.aoyama.ac.jp> <8450797E-818C-445C-ABD2-1B8F9AE1DBB9@checkpoint.com> <5194918A.7030300@gondrom.org> <CAGZ8ZG0SWZD9e-NP2RhQMQ-=F5JUCCytF2NYTdWH7u13hhBqqQ@mail.gmail.com> <519D3254.1040508@gondrom.org> <CAGZ8ZG15ZbjfDcu+bpetvfZxKG1ycW9t1AGuQ+A5cfpfkUAfnw@mail.gmail.com> <CAOuvq237_B1h6mBryP3UHh=auqtUhs93-_oKMSsHOjqSX977bQ@mail.gmail.com> <51A49A5C.5080002@gondrom.org>
Date: Tue, 28 May 2013 17:23:48 -0700
Message-ID: <CAOuvq20_zACXraV9iN6mUbDwML8GkSCwh9w2Cuow818YOLL-Sw@mail.gmail.com>
From: Chris Palmer <palmer@google.com>
To: Tobias Gondrom <tobias.gondrom@gondrom.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQndc2lxyyu9ISHQe1e11HjB0zi9n6JlslMJP6fE+YiHPEvSvJl9FFkV/VoFsWRTP6iN2GfMZasT+/CGHtMH7/zXNbhKZrOACbi1RcPV8FuVMAiAwjKOHKGwZpMs6eteD/9ZTpl9ZynT473K+OGGEqy6p6Fj3L4WWlvuUx2NIY3DDuP3y+qaLR5OdJrgA/0bU+75eXju
Cc: IETF WebSec WG <websec@ietf.org>
Subject: Re: [websec] Consensus call: Issue #57 (max-max-age)
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: Wed, 29 May 2013 00:23:54 -0000
On Tue, May 28, 2013 at 4:51 AM, Tobias Gondrom <tobias.gondrom@gondrom.org> wrote: > It seems like the majority of the WG would not share my concerns. So I > will shut up soon. ;-) Thanks for raising your concerns, and for sticking the conversation and with pinning in general! > 1. user choice is a bad idea when it comes to security. > Just remember the many SSL cert "click to proceed anyway pop-up > windows/issues..." > In most cases the user is not qualified to fully understand the > consequences of his choice. Yes. But, in this case, the choice is between status-quo HTTPS and extra-happy pinned HTTPS. That's a very different proposition than clearly-broken HTTPS vs. status-quo HTTPS, for example. Also, failing closed would probably be a deal-breaker for deployment, at least at this time. Finally, for sites that people use regularly — Facebook, Gmail, Twitter — users will still get good protection. Arguably, these are the sites that are mature and most likely to be able to deploy pinning; it's the banks and other occasionally-visited sites that should probably stick to Report-Only mode anyway, because they are less mature *as web technology companies*. Thus I would argue that, at least for now, the sites that would most likely fail open due to limit son the max-max-age are sites that should fail open anyway, for other reasons. However, that's a bit of a tangent. As it is, many sites that really need pinning protection can get it under this I-D, and others can gain nice information from Report-Only mode, and others do no worse than the status quo. > 2. as you seem to advocate a hard limit of 30 days. Not exactly; I find Trevor's call for simple clarity compelling, but I also like a browser-determined limit past which we fail open (for the reasons described above). I could happily go either way, which doesn't really help, I realize. :) Ryan and I can just make a call one way or the other and write it up, is that OK? > Could you think of > browsers refreshing their PINs before expiry automatically? (i.e. > without the user actually visiting the site?) > And question to all: would this open Pandora's box in terms of privacy > etc. as we would leak the list of pinned sites to servers in the middle? Right, exactly. I don't want to have browsers unilaterally leaking information by proactively pre-scanning particular sites. However, an oft-updated master list, like Chrome's CRLSets but for pins culled by crawling sites and looking for pin updates, might be workable. But I'd consider that a nice-to-have that is out of the I-D's immediate scope.
- Re: [websec] Consensus call: Issue #57 (max-max-a… Yoav Nir
- [websec] Consensus call: Issue #57 (max-max-age) Yoav Nir
- Re: [websec] Consensus call: Issue #57 (max-max-a… Trevor Perrin
- Re: [websec] Consensus call: Issue #57 (max-max-a… Tom Ritter
- Re: [websec] Consensus call: Issue #57 (max-max-a… Martin J. Dürst
- Re: [websec] Consensus call: Issue #57 (max-max-a… Tobias Gondrom
- Re: [websec] Consensus call: Issue #57 (max-max-a… Tobias Gondrom
- Re: [websec] Consensus call: Issue #57 (max-max-a… Trevor Perrin
- Re: [websec] Consensus call: Issue #57 (max-max-a… Yoav Nir
- Re: [websec] Consensus call: Issue #57 (max-max-a… Tobias Gondrom
- Re: [websec] Consensus call: Issue #57 (max-max-a… Yoav Nir
- Re: [websec] Consensus call: Issue #57 (max-max-a… Tobias Gondrom
- Re: [websec] Consensus call: Issue #57 (max-max-a… Trevor Perrin
- Re: [websec] Consensus call: Issue #57 (max-max-a… Ryan Sleevi
- Re: [websec] Consensus call: Issue #57 (max-max-a… Trevor Perrin
- Re: [websec] Consensus call: Issue #57 (max-max-a… Chris Palmer
- Re: [websec] Consensus call: Issue #57 (max-max-a… Daniel Veditz
- Re: [websec] Consensus call: Issue #57 (max-max-a… Trevor Perrin
- Re: [websec] Consensus call: Issue #57 (max-max-a… Tobias Gondrom
- Re: [websec] Consensus call: Issue #57 (max-max-a… Tobias Gondrom
- Re: [websec] Consensus call: Issue #57 (max-max-a… Chris Palmer
- Re: [websec] Consensus call: Issue #57 (max-max-a… Yoav Nir
- Re: [websec] Consensus call: Issue #57 (max-max-a… Tobias Gondrom
- Re: [websec] Consensus call: Issue #57 (max-max-a… Chris Palmer
- Re: [websec] Consensus call: Issue #57 (max-max-a… Yoav Nir
- Re: [websec] Consensus call: Issue #57 (max-max-a… Trevor Perrin
- Re: [websec] Consensus call: Issue #57 (max-max-a… Tobias Gondrom
- Re: [websec] Consensus call: Issue #57 (max-max-a… Yoav Nir
- Re: [websec] Consensus call: Issue #57 (max-max-a… Tobias Gondrom
- Re: [websec] Consensus call: Issue #57 (max-max-a… Sheehe, Charles J. (GRC-DPC0)
- Re: [websec] Consensus call: Issue #57 (max-max-a… Trevor Perrin
- Re: [websec] Consensus call: Issue #57 (max-max-a… Trevor Perrin
- Re: [websec] Consensus call: Issue #57 (max-max-a… Trevor Perrin
- Re: [websec] Consensus call: Issue #57 (max-max-a… Sheehe, Charles J. (GRC-DPC0)
- Re: [websec] Consensus call: Issue #57 (max-max-a… Trevor Perrin