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