Re: [websec] Consensus call: Issue #57 (max-max-age)
Trevor Perrin <trevp@trevp.net> Wed, 22 May 2013 23:09 UTC
Return-Path: <trevp@trevp.net>
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 2EEB511E814E for <websec@ietfa.amsl.com>; Wed, 22 May 2013 16:09:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.806
X-Spam-Level:
X-Spam-Status: No, score=-0.806 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619, RDNS_NONE=0.1]
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 CYfUA2Q8gdWd for <websec@ietfa.amsl.com>; Wed, 22 May 2013 16:09:20 -0700 (PDT)
Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 65EC711E814B for <websec@ietf.org>; Wed, 22 May 2013 16:09:20 -0700 (PDT)
Received: by mail-wi0-f177.google.com with SMTP id hr14so1705398wib.10 for <websec@ietf.org>; Wed, 22 May 2013 16:09:19 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=DbXphFPKjl8mzpi8CpMbCFEhQL3x6tMEMY7VIe1oJvM=; b=fzcydp/g/ohX0MMa1/SJOBSZXtq83pW4OPFvl9wXvWrog8p4BqiFaKh/eQIJKDz4++ d3w9GtthXH4BZ4LSCDw89AwtzPxQUfsl4VCFo6qiZ25DSGvLXSgQc+8Y49VtLD9a0OQt XNP1goYVHWvUl7oQCK2/P+DBOs41ugxhkVnEiBl/ecbhdgk14RMx1uYTklOjQjGivoJ+ Ig0G95kK/DQCjJ4YoIuvRzsXo1BTGuamkMX5HJeCXbX7136gqujULPMakGlKwUALe0u2 jQfEtdLTK1xSkKo3xAlNeNZ74/mfLSNkAHMrsJMLYESzdAcnq0W1uAAvLxbGOvnXWGBF Lsvg==
MIME-Version: 1.0
X-Received: by 10.180.99.232 with SMTP id et8mr38229289wib.17.1369264159393; Wed, 22 May 2013 16:09:19 -0700 (PDT)
Received: by 10.217.110.129 with HTTP; Wed, 22 May 2013 16:09:19 -0700 (PDT)
X-Originating-IP: [208.70.28.214]
In-Reply-To: <519D3254.1040508@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>
Date: Wed, 22 May 2013 16:09:19 -0700
Message-ID: <CAGZ8ZG15ZbjfDcu+bpetvfZxKG1ycW9t1AGuQ+A5cfpfkUAfnw@mail.gmail.com>
From: Trevor Perrin <trevp@trevp.net>
To: Tobias Gondrom <tobias.gondrom@gondrom.org>
Content-Type: multipart/alternative; boundary="f46d041825acd31e7604dd56a7c7"
X-Gm-Message-State: ALoCoQm01Q8h3qSt651GyWc1Q+sbTs63bOgxr9+hojLwe3Pl8A67llqEVLl2iJ5UfRCh9U7f5k4p
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, 22 May 2013 23:09:27 -0000
On Wed, May 22, 2013 at 2:02 PM, Tobias Gondrom <tobias.gondrom@gondrom.org>wrote: > > And maybe a question to go a step further: > Would you agree that if we would do a 30-day hard limit as you propose, > this would basically mean that all less frequent banking/paypal/... users > MUST (or a very strong SHOULD) use such a web crawler to make sure that > their pin has not expired before they come back? > Pins created by the UA itself won't protect initial connections, or provide security when expired. These are inherent limits of UA-derived pins. So I don't think a spec-limit makes these problems dramatically worse, or requires new mandates for UAs. You could, however, note the deficiences of UA-derived pins in the Security Considerations, and say something something like: "Clients are advised to make use of 3rd-party trust infrastructure so that pins can be aggregated and shared. This will require additional protocols outside the scope of this document." > This would be a big problem in my eyes, as IMHO this assumption can not be > guaranteed nor expected to be rolled out consistently. > > > >> And regarding some of the concerns of pro-longed malicious bricking by >> an attacker after an attack has been resolved: >> Two scenarios: >> 1. I believe if we have a time limit of more than 1 month we need a >> different mechanism (e.g. user actively flushing the key cache) anyway. >> 2. in the case of high frequency sites (like you mentioned Facebook), >> imagine even a 1 month brick time would already be considered >> unacceptable too long by most users (in fact probably everything above a >> few hours would be considered too long) and trigger user action to flush >> the cache. >> > > Agreed that a 30-day limit is not, by itself, sufficient mitigation > against "malicious bricking by an attacker after an attack". I suspect > pinning will need several additional mechanisms to prevent, limit, and > recover from such attacks. "Pin activation" is one mechanism I think is > particularly helpful, for this case. > > A 30-day spec limit is more important for other reasons: > 1) Domain name transfers (sales, disputes, reclaiming hijacked domains, > etc.) > 2) Preventing long-term lock-in. E.g. you are pinned to CA keys which > you lose trust in and suspect might be participating in MITM attacks; you > are not bricked, but you are unable to change to a different CA and assert > new CA pins until the old pins expire. > 3) Pruning the amount of pin history you must keep your site consistent > with (Do you remember what pins you or the previous domain owner asserted 6 > month ago? 6 years ago? ever? They might still be out there, waiting to > trip you up). > > > Hm, in my view case #2 and #3 are about your own pinning time frames and > should be ok with recommendations, but would not require hard limits in the > draft. And in fact as we have multiple pins in the header we have a > migration path from A to B during that transition. > Being able to assert multiple pins in the header doesn't avoid lock-in problems. In a lock-in scenario there could be extant pins in clients to the set of keys (X,Y,Z). Thus you *cannot* safely stop using one of keys (X,Y,Z) until those pins expire. Advertising new pins doesn't fix the problem, cause you can't be guaranteed of reaching all existing clients. > Reading your cases, it feels to me #1 the malicious domain name transfer > is the strongest case. > Is that in your opinion as well? > Not sure. Trevor
- 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