Re: [websec] Consensus call: Issue #57 (max-max-age)

Trevor Perrin <trevp@trevp.net> Wed, 08 May 2013 19:02 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 60FA021F9375 for <websec@ietfa.amsl.com>; Wed, 8 May 2013 12:02:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.357
X-Spam-Level: *
X-Spam-Status: No, score=1.357 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_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, 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 P+9nya0Zlb75 for <websec@ietfa.amsl.com>; Wed, 8 May 2013 12:02:07 -0700 (PDT)
Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 595F221F8511 for <websec@ietf.org>; Wed, 8 May 2013 12:01:53 -0700 (PDT)
Received: by mail-wg0-f46.google.com with SMTP id n12so2165334wgh.13 for <websec@ietf.org>; Wed, 08 May 2013 12:01:52 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=Wn3x1VmTapiQsuvFV/fLLbe8Xy0AmZMijqIjbV23tSA=; b=RwUemLc6C8tj7gg6ei6cqkS+B7+c4dznQ4LPB2OytF+zlfRnc731Qo2OPIgdCY+KGj Ij20FEyT2u6DeLG25qzom9+lGGxCwXWxJxLs66jDk6bvDnkmOc/oK0mUm4RHUcfF/NGb StSmBU20HIsANnwM8QqLhLGjx+QuGUQ/LgkH75Ep3qYqWO1uR9lHwT730Yi5d92Tz2q1 Qc+wf9s2zp4bpcwp9NfC9LRa2RO3lQEGxQ89fZqkJ9JmBNA7NyRfcEqB4F9dT3Rx4rjd 4TV5+86OsNfB85yp7QSMmq1SpfpFaTXFGMF6s8uJKmw4UV1J4pfnbdvAxBeQUiPfr00u HNvg==
MIME-Version: 1.0
X-Received: by 10.180.76.230 with SMTP id n6mr24055506wiw.28.1368039712426; Wed, 08 May 2013 12:01:52 -0700 (PDT)
Received: by 10.216.113.7 with HTTP; Wed, 8 May 2013 12:01:52 -0700 (PDT)
X-Originating-IP: [64.134.226.20]
In-Reply-To: <43C5DE99-43EB-42FC-8F61-24F9A9429FD1@checkpoint.com>
References: <43C5DE99-43EB-42FC-8F61-24F9A9429FD1@checkpoint.com>
Date: Wed, 08 May 2013 12:01:52 -0700
Message-ID: <CAGZ8ZG3t5XdnnfNSnfnTPPmB3OfMc0eN=7Qp+YNaCOKzaY_FtQ@mail.gmail.com>
From: Trevor Perrin <trevp@trevp.net>
To: Yoav Nir <ynir@checkpoint.com>
Content-Type: multipart/alternative; boundary="f46d043c7d46191eb504dc3991ba"
X-Gm-Message-State: ALoCoQnILTOhfPDy3jj7kLPHMyxqPwma1O/apiUShAkC4nLj9LeBdxPYTsiShmm/Wql2dkqASof3
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, 08 May 2013 19:02:12 -0000

On Tue, May 7, 2013 at 12:13 AM, Yoav Nir <ynir@checkpoint.com> wrote:

>
> How should we handle the max-max-age issue:
>  (1) No hard limits, but allow UAs to limit the pin time. Suggest a month
>  (2) Set a hard limit of one month in the RFC. Longer pins are truncated.
>  (3) No hard limits, but allow the UA to skip hard-fail if a pin hasn't
> been observed for some time (like a month)
>  (4) Adopt some gradual confidence-building scheme a-la-TACK.
>

Hi Yoav,

I suggest this could be viewed as two separate questions:

 A) Should there be / what is the spec-mandated max pin lifetime?
   - (this is your 1/2/3)

 B) How are pin lifetimes set?
   - server assertion ("max-age")
   - confidence building (eg "pin activation")
   - some combination?  something else?

These questions are somewhat independent: you could have a spec-mandated
max regardless of whether pin lifetimes are set from server assertions *or*
confidence-building.

Anyways, the first question has been discussed a bunch, and I think it's
reasonable to try to get a consensus.  My vote is #2, with "30 days".

The second question hasn't been discussed much, and has some complexity.
 Maybe we should try to encourage more discussion / research of the
options, before trying to pull out a consensus?


Trevor