Re: [websec] draft-ietf-websec-key-pinning

Tobias Gondrom <tobias.gondrom@gondrom.org> Fri, 05 September 2014 12:08 UTC

Return-Path: <tobias.gondrom@gondrom.org>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAD3F1A06DC for <websec@ietfa.amsl.com>; Fri, 5 Sep 2014 05:08:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -97.322
X-Spam-Level:
X-Spam-Status: No, score=-97.322 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HELO_EQ_D_D_D_D=1.597, HELO_DYNAMIC_IPADDR=1.951, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eqdulwasKvl5 for <websec@ietfa.amsl.com>; Fri, 5 Sep 2014 05:08:29 -0700 (PDT)
Received: from lvps5-35-241-16.dedicated.hosteurope.de (www.gondrom.org [5.35.241.16]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFB411A06D9 for <websec@ietf.org>; Fri, 5 Sep 2014 05:08:28 -0700 (PDT)
Received: from [192.168.0.13] (5ec3983d.skybroadband.com [94.195.152.61]) by lvps5-35-241-16.dedicated.hosteurope.de (Postfix) with ESMTPSA id BA1B362D14; Fri, 5 Sep 2014 14:08:23 +0200 (CEST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=w+xuFdrh7uwfrhxA6KLM0FIW93Rl8BeIO1cWe2+rHq44GRr7eDq7GVVLCZKxDeeuX8epkE2IL07Fae1HHdiuR/qgMtIThDmjMf22/ss5di/iO1CpSz3aZbMFdZ+fNlYgBHvVXBiVHMPz8jkr0lFW6h5qWoRUh1ZMtICKXHmexmc=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type;
Message-ID: <5409A7B7.5040206@gondrom.org>
Date: Fri, 05 Sep 2014 13:08:23 +0100
From: Tobias Gondrom <tobias.gondrom@gondrom.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: sleevi@google.com, trevp@trevp.net
References: <CACvaWvZNpAepBmWchLMirfPdxu4ed=vH1qwMppAjw1P9S+4quw@mail.gmail.com> <BAY169-DS311951F23960F4605A0CB0AEDA0@phx.gbl> <35F981DA-46C4-44D7-8582-25BF8BF1B31A@gmail.com> <BAY169-DS421419C50B5700132829BBAEDA0@phx.gbl> <CAGZ8ZG2S5XxyAkL=vr2VbCzKA2bfGk2FxK9RYGiBtMmG7UPraA@mail.gmail.com> <CACvaWvY3-6LMECBsobpgi-Uj2iUz0PNTsqZdiHUeuw-J9Tu_KQ@mail.gmail.com> <CAGZ8ZG1ohK0CH=ss+ynjpaedEGUTA_GwuSoueh2X2YQ7J-T=4w@mail.gmail.com> <CACvaWvYTFEN2bm3FAENZHKFyWAx1hmzB4-NN4VB3=x1PXSLRCw@mail.gmail.com>
In-Reply-To: <CACvaWvYTFEN2bm3FAENZHKFyWAx1hmzB4-NN4VB3=x1PXSLRCw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------010203050207060607000906"
Archived-At: http://mailarchive.ietf.org/arch/msg/websec/YkrRqYmaZGuTZqasPAKSXWi_7QE
Cc: draft-ietf-websec-key-pinning@tools.ietf.org, websec@ietf.org
Subject: Re: [websec] draft-ietf-websec-key-pinning
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 05 Sep 2014 12:08:32 -0000

Hi Ryan,

just to balance this:
yes, we are in IESG review and we should focus on giving the draft the 
last touches.

With one remark: even in IESG review, if we find a major security 
problem, we need to go back to WGLC.
But so far I am not convinced that this problem is that big in this case 
here and had the perception that we had a WG discussion about this 
before with rough WG consensus (albeit quite rough) as is. (And I admit, 
the long latency times in the WG discussions between emails and draft 
iterations did not make things easier.)

But if anyone thinks this problem will be major, please say so now and 
we could have a quick (5-day) discussion window in the WG whether this 
needs to go back to the WG or whether the chairs did misjudge WG consensus.

Just my personal view, but with hat of WG chair on.

Best wishes, Tobias




On 05/09/14 01:06, Ryan Sleevi wrote:
> I wish you would have raised this during WGLC, which would have 
> benefited from the review and discussion now being paid.
>
> I guess echoing Yoav's earlier remarks that:
>
>     "At this stage, we can make editorial changes, but we cannot make
>     significant changes on our own. We can withdraw the request to
>     publish, and take it back to the working group, but I think that
>     would be inadvisable.
>     I think we should proceed, making only editorial changes, and
>     changes resulting from discussion with IESG members."
>
>
> that it's probably not worth discussing much further.
>
> If the WG feels strongly about this, we can certainly withdraw from 
> publication. If so, I think the Chris' and myself would need to recuse 
> ourselves from being able to edit this document any further, so the WG 
> would need to find a new set of editors to proceed with this draft.
>
> Other than that, either we accept these as ERRATA, or we accept them 
> as being what they are.
>
> That is, my understanding is that this is a bit like discovering a 
> possible issue after you've shipped your gold master to 100K stores. 
> Yes, it's awful, but either it's a recall or you fix it in post. My 
> gut is that it's for post. However, based on Yoav's remarks, I'm not 
> sure that there's very much we can do editorially to address these. It 
> appears my proposed suggestion does not address your concerns, so I 
> will not be added it to the next (and hopefully final) draft.
>
>
>
> On Thu, Sep 4, 2014 at 4:53 PM, Trevor Perrin <trevp@trevp.net 
> <mailto:trevp@trevp.net>> wrote:
>
>     On Thu, Sep 4, 2014 at 4:09 PM, Ryan Sleevi <sleevi@google.com
>     <mailto:sleevi@google.com>> wrote:
>     >
>     >
>     >
>     > On Thu, Sep 4, 2014 at 4:02 PM, Trevor Perrin <trevp@trevp.net
>     <mailto:trevp@trevp.net>> wrote:
>     >>
>     >> I agree with Eric and Joe that the current definition of PKP-RO
>     is not
>     >> that useful and potentially surprising to deployers.
>     >>
>     >> Ryan argues that storing PKP-RO is dangerous because a TLS MITM who
>     >> could set pins for a lot of clients for a lot of sites could
>     flood a
>     >> victim with reports.
>     >>
>     >>
>     >> Couldn't the MITM also set PKP pins with report-uri, or set cached
>     >> redirects or other cached resources to generate traffic toward a
>     >> victim?
>     >
>     >
>     > Yes, and that's a user visible effect, rather than transparent.
>
>     Hmm, there's nothing clever that can be done with cached javascript or
>     html to also generate silent traffic toward a victim?
>
>
>     > It also
>     > requires that a connection be validated first, whereas the very
>     definition
>     > of PKP-RO is that you send it when a connection is not validated.
>
>     I'd expect stored PKP-RO to follow the same rules as PKP and be stored
>     only if it meets the bullet points in 2.5 (error-free TLS connection,
>     backup pins, etc.).
>
>     It would make sense for any report-uri header (PKP or PKP-RO) that
>     fails the 2.5 checks, or has some other invalid syntax (eg bad
>     base64), to *also* generate a different sort of report and not be
>     stored.
>
>     Would it be reasonable to add a reporting message for 2.5 failure or
>     syntax failure?  Otherwise, when asserting a report-uri pin you can't
>     distinguish pin-not-stored errors from
>     pin-stored-and-validation-successful.
>
>
>     >> Ryan argues PKP-RO is worse because it's "conceptually and
>     practically
>     >> silent to the user".  But once the browser has sent junk
>     traffic to a
>     >> victim, I don't really see how seeing how displaying a pinning
>     error
>     >> makes things better.
>     >
>     >
>     > First, the attacker can only mount the hostile attack after
>     having first
>     > established a good connection.
>
>     Debateable per above.
>
>
>     > PKP-RO allows an attacker to perpetually
>     > mount a hostile attack.
>     > Second, the presence of a pinning error is an inherently
>     rate-limiting
>     > factor to the user experience. You're not going to be able to
>     trigger 100
>     > reports if you're causing the user 100 error pages.
>
>     Rate-limiting is already proposed:
>     """
>     UAs SHOULD limit the rate at which they send reports.  For example,
>        it is unnecessary to send the same report to the same
>     report-uri more
>        than once per distinct set of declared Pins.
>     """
>
>     Wouldn't that take care of it?
>
>
>     > Third, it seems like you're arguing for removing report-uri
>     altogether,
>     > given the privacy and DoS risks identified. That is, the more
>     that  you
>     > establish RO is similar to PKP in level of what an attacker can
>     do, the more
>     > it argues for removing report-URI entirely.
>
>     Dunno.  I'm still trying to understand these risks, whether they're
>     really different for PKP-RO vs PKP, and for HPKP versus other web
>     technologies.
>
>     Trevor
>
>
>
>
> _______________________________________________
> websec mailing list
> websec@ietf.org
> https://www.ietf.org/mailman/listinfo/websec