IETF Logo Mail Archive

Re: [websec] Sean Turner's Discuss on draft-ietf-websec-x-frame-options-09: (with DISCUSS and COMMENT)

Ted Lemon <ted.lemon@nominum.com> Wed, 14 August 2013 17:52 UTC

Return-Path: <Ted.Lemon@nominum.com>
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 99B4421E80DD; Wed, 14 Aug 2013 10:52:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 XNN8ZSMdaSbn; Wed, 14 Aug 2013 10:52:50 -0700 (PDT)
Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 130B321E80C7; Wed, 14 Aug 2013 10:52:49 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKUgvD8Gut1Mcfk2DE9X66+5DeFUFUu7jQ@postini.com; Wed, 14 Aug 2013 10:52:49 PDT
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 9F8071B82A7; Wed, 14 Aug 2013 10:52:48 -0700 (PDT)
Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 83A3519006C; Wed, 14 Aug 2013 10:52:48 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 14 Aug 2013 10:52:48 -0700
Content-Type: multipart/alternative; boundary="Apple-Mail=_20733533-2D90-4037-969B-7D939CFD26B8"
MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1793.4\))
From: Ted Lemon <ted.lemon@nominum.com>
In-Reply-To: <520BC148.4010505@gondrom.org>
Date: Wed, 14 Aug 2013 13:52:47 -0400
Message-ID: <E6E3B6B8-2E66-4713-B0BC-EBD32CD723DA@nominum.com>
References: <20130814161444.6218.82572.idtracker@ietfa.amsl.com> <296E0D02-A1FB-4050-9DF6-06C60199AB32@checkpoint.com> <59CD902A-8992-452D-A9F1-C019016F6025@nominum.com> <520BC148.4010505@gondrom.org>
To: Tobias Gondrom <tobias.gondrom@gondrom.org>
X-Mailer: Apple Mail (2.1793.4)
X-Originating-IP: [192.168.1.10]
Cc: draft-ietf-websec-x-frame-options@tools.ietf.org, websec@ietf.org, The IESG <iesg@ietf.org>, Sean Turner <turners@ieca.com>, websec-chairs@tools.ietf.org
Subject: Re: [websec] Sean Turner's Discuss on draft-ietf-websec-x-frame-options-09: (with DISCUSS and COMMENT)
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, 14 Aug 2013 17:52:56 -0000

On Aug 14, 2013, at 1:41 PM, Tobias Gondrom <tobias.gondrom@gondrom.org> wrote:
> it is a balancing act: the depth of advise is proportionate to the correlation of the different implementations. 
> So e.g. where implementations are in sync, the advise is more detailed. 

Right, I get the sense that the goal really is to document, not to advise, at least with respect to browser vendors.   I just posted some comments that speak to this question—I think you are doing the right thing, but you just should be clear that you are documenting existing behavior rather than specifying behavior.  That probably means that there are some bits of text that look normative right now that ought to be reworded.

v2.23.0 | Report a Bug | By Email