Re: [secdir] secdir review of draft-ietf-websec-x-frame-options-07

"Joseph Salowey (jsalowey)" <jsalowey@cisco.com> Mon, 12 August 2013 04:19 UTC

Return-Path: <jsalowey@cisco.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF24A21F9DFB; Sun, 11 Aug 2013 21:19:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -111.599
X-Spam-Level:
X-Spam-Status: No, score=-111.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 UsryJkrcrFVp; Sun, 11 Aug 2013 21:19:48 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id EB1DF21E80DC; Sun, 11 Aug 2013 21:12:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5891; q=dns/txt; s=iport; t=1376280772; x=1377490372; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ohW23QCSgTwH3OQ8Ko2lMoLGlk1gDtfeWFxLXB36TPQ=; b=Xg57BdOtAD71Gli/X1HNBE1UR/HCS0/Z5bCXPZJ3QK2yhAgXFkhz/92n TNsbjacujMsqBgU21+6YiQRn1Q9R92vyaZSsrQYDEOXBvLm2Am7/D1VKd mSfQaETlnN/eHPlqIqlsNIATcl8Ap6gQerNikuVL5GLDczxrjPg1zWynt o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ag8FAO5fCFKtJV2b/2dsb2JhbABagwY1UL5VgRsWdIIkAQEBAwF5BQsCAQgYCiQyJQIEDgUIiAIGtWKQCAIxB4MbdgOIdaBAgxuCKg
X-IronPort-AV: E=Sophos;i="4.89,859,1367971200"; d="scan'208";a="246107938"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 12 Aug 2013 04:12:51 +0000
Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r7C4CpTw011986 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Aug 2013 04:12:51 GMT
Received: from xmb-rcd-x09.cisco.com ([169.254.9.235]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Sun, 11 Aug 2013 23:12:50 -0500
From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
To: Tobias Gondrom <tobias.gondrom@gondrom.org>
Thread-Topic: secdir review of draft-ietf-websec-x-frame-options-07
Thread-Index: AQHOlsLTCIsxukwZF0auP9vgLBoZD5mQzjkAgAB86oA=
Date: Mon, 12 Aug 2013 04:12:49 +0000
Message-ID: <A95B4818FD85874D8F16607F1AC7C628DBAC1A@xmb-rcd-x09.cisco.com>
References: <A95B4818FD85874D8F16607F1AC7C628DB98BB@xmb-rcd-x09.cisco.com> <5207F854.6070706@gondrom.org>
In-Reply-To: <5207F854.6070706@gondrom.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.33.248.54]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <FADBF46903754943BF5A111BEEF2EC66@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "<draft-ietf-websec-x-frame-options.all@tools.ietf.org>" <draft-ietf-websec-x-frame-options.all@tools.ietf.org>, "<iesg@ietf.org>" <iesg@ietf.org>, "<secdir@ietf.org>" <secdir@ietf.org>
Subject: Re: [secdir] secdir review of draft-ietf-websec-x-frame-options-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Aug 2013 04:19:54 -0000

Hi Tobias,

Thanks for the quick response.  Your responses and modifications look good.   I still lean towards wanting to say something about a policy on which pages should use XFO, however I can see how this can go beyond the scope of the document.   The appendix B does provide some useful examples which are probably sufficient.  

Cheers,

Joe


On Aug 11, 2013, at 1:47 PM, Tobias Gondrom <tobias.gondrom@gondrom.org>;
 wrote:

> Dear Joseph,
> 
> thank you very much for the review.
> I revised the document to version-08 (also including feedback from other
> reviews) accordingly including most of your feedback.
> Answers inline.
> Best regards, Tobias
> 
> On 11/08/13 19:44, Joseph Salowey (jsalowey) wrote:
>> Do not be alarmed. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.
>> 
>> This document is ready with issues.  
>> 
>> The document is generally well written and covers an important topic. It describes existing options that can be included in an HTTP header to to prevent the HTTP content from being embedded in the frame of another page.   The document describes the existing options and therefore meets its main goal.     The main issue I see with the document is in the lack of guidance on  when to use the options.   
>> 
>> Issues:
>> 
>> 1.  Section 2.1: It seems that  RFC6454 should be first referenced in the SAMEORIGIN section.   Also, shouldn't the note about port not considered as a defining component of origin apply to SAMEORIGIN as well?
> 
> Hm. I am afraid that would be counterproductive.
> Although the name of the directive ("SAMEORIGIN") may suggest that this
> refers directly to RFC6454, it does not. As you can see from the next
> paragraph after the list, most current implementations do not follow
> RFC6454 to the letter as they do not consider the port as a defining
> component of the origin.
> That is the reason why we felt that it would be better to have the
> reference in the section below together with this explanation.
> 
>> 2.  Section 2.3.1: I'm not sure what section 2.3.1 is trying to say.    Is it saying that the X-FRAME-OPTIONS should apply to all of these embedding mechanisms?   If this is the case then I think this section should explicitly say so.  
> Ok. Done. Added a sentence that "browser implementations cover all of
> them".
> 
> 
>> 3.  Section 5:   
>> 
>> - The security considerations states that the X-FRAME-OPTIONS "it is not self-sufficient on its own, but must be used in conjunction with other security measures like secure coding and the Content Security Policy."  This statement leads me to believe that more guidance is necessary.  For example, does the reference to "secure coding" a general statement, or are there specific coding considerations that are specific to clickjacking protection?   If its general then it doesn't really add anything so I think it would be better to be more specific.   The same comment applies to CSP.   
> Thanks. I can see your point and adjusted the text a bit accordingly.
> I understand that the terms are generic, on the other hand we want to
> avoid that people feel unnecessarily safe and think everything is fine,
> just because they are using this one header. E.g. if a page is
> vulnerable to XSS, you may be able to escape your frame otherwise.
> 
>> - Should pages also employ framebusting since the header options are not uniformly implemented?
> No. We intentionally did not refer to framebusting as in addition to XFO
> in the security section, because:
> 1. today all major browsers support a minimum of x-frame-options,
> although with variations. So even with their variations, framebusting
> would not add much more capabilities. (note: in special use cases
> framebusting could still make sense, but describing these would not be
> adding value to the ID about XFO.)
> 2. framebusting has unfortunately been proven as not reliable against
> sophisticated attackers. (see reference in the ID).
> 
>> - Perhaps the second paragraph should explicitly say that because of this developers must be aware that embedding content from other sites may leave them vulnerable to clickjacking if the SAMEORIGIN directive is used. 
> 
> Yes. Added text.
> 
>> - What pages should include this header option?   More guidance here would be good.  Right now its necessarily clear which pages should include this header especially given the uncertainty with SAMEORIGIN described in the second paragraph.  Should all pages on a site deny being framed unless their content needs to be embedded in another site? 
>> 
> 
> Hm. I felt uncomfortable speaking in too much detail about which web
> pages should use X-FRAME-OPTIONS and which may not need to, as there is
> a huge variety of web applications.
> 
> In general, you should obviously use it for anything that is vulnerable
> against clickjacking as given by the abstract and introduction (i.e.
> anything with buttons or links that you can click on with anything
> happening as a result of that click). Overall I would prefer to not go
> deeper into this in the draft, as IMHO the driving factor where to
> deploy XFO should be driven by the context of the web application and
> its risks.
> It could be useful and simplify things to just deploy it everywhere,
> even though some pages may not be at risk by clickjacking. But I don't
> see a lot of benefit in adding more text about this.
> 
>