From Jeff.Hodges@KingsMountain.com Mon Jan 2 15:29:46 2012 Return-Path: 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 CFD611F0C56 for ; Mon, 2 Jan 2012 15:29:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.52 X-Spam-Level: X-Spam-Status: No, score=-101.52 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 qh6xvoGnO+J4 for ; Mon, 2 Jan 2012 15:29:46 -0800 (PST) Received: from oproxy4-pub.bluehost.com (oproxy4-pub.bluehost.com [69.89.21.11]) by ietfa.amsl.com (Postfix) with SMTP id 34F871F0C4D for ; Mon, 2 Jan 2012 15:29:46 -0800 (PST) Received: (qmail 3338 invoked by uid 0); 2 Jan 2012 23:29:21 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy1.bluehost.com with SMTP; 2 Jan 2012 23:29:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=w5uftk6SP/XgunPlNogUr+FSQ0sgzZS56QKejc+Jcxg=; b=7H1mX5lUeUsxKPg4ilg8yC2DXVemSi4n56QWUQnJIYEnDH1AIGk2XVsRLS5tgGCJGSrE5jdMfXefJlG4UJxokn5MCY8vGFjkiKadB+dHByppoWBLPguMn/OQSd1DsS3s; Received: from c-24-4-122-173.hsd1.ca.comcast.net ([24.4.122.173] helo=[192.168.11.18]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1RhrJh-0004qX-N9 for websec@ietf.org; Mon, 02 Jan 2012 16:29:21 -0700 Message-ID: <4F023DD0.8060308@KingsMountain.com> Date: Mon, 02 Jan 2012 15:29:20 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: IETF WebSec WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Subject: [websec] default value for max-age ? (was: Re: Strict-Transport-Security syntax redux) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2012 23:29:46 -0000 Julian wondered.. > > wouldn't it make sense to have a default for max-age so it > can be made OPTIONAL? hm ... I lean towards keeping max-age as REQUIRED (without a default value) and thus hopefully encouraging deployers to think a bit about this and its ramifications, and also because its value is so site-specific in terms of a web application's needs, deployment approach, and tolerance for downside risk of breaking itself. =JeffH From palmer@google.com Mon Jan 2 16:35:02 2012 Return-Path: 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 5A9C121F8518 for ; Mon, 2 Jan 2012 16:35:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 fdFviOKTLAZN for ; Mon, 2 Jan 2012 16:35:02 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8511421F8516 for ; Mon, 2 Jan 2012 16:35:01 -0800 (PST) Received: by wibhj6 with SMTP id hj6so10917639wib.31 for ; Mon, 02 Jan 2012 16:35:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:x-system-of-record:content-type; bh=lgjqZFsI0D1PKQQR10mFgSERV1agGywuLrFI/zhIHN0=; b=U3acrWSEs7ASgD1Dsu3jYmo2jgn4YsPPNX/VCWwj+WsIcT01dplW5s3LbmSPQTksJ5 iJzUrHk6pVu4I4r1IRJA== Received: by 10.180.101.35 with SMTP id fd3mr99022806wib.22.1325550900693; Mon, 02 Jan 2012 16:35:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.180.101.35 with SMTP id fd3mr99022792wib.22.1325550900576; Mon, 02 Jan 2012 16:35:00 -0800 (PST) Received: by 10.216.227.94 with HTTP; Mon, 2 Jan 2012 16:35:00 -0800 (PST) In-Reply-To: <4F023DD0.8060308@KingsMountain.com> References: <4F023DD0.8060308@KingsMountain.com> Date: Mon, 2 Jan 2012 16:35:00 -0800 Message-ID: From: Chris Palmer To: "=JeffH" X-System-Of-Record: true Content-Type: text/plain; charset=UTF-8 Cc: IETF WebSec WG Subject: Re: [websec] default value for max-age ? (was: Re: Strict-Transport-Security syntax redux) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 00:35:02 -0000 On Mon, Jan 2, 2012 at 3:29 PM, =JeffH wrote: > hm ... I lean towards keeping max-age as REQUIRED (without a default value) > and thus hopefully encouraging deployers to think a bit about this and its > ramifications, and also because its value is so site-specific in terms of a > web application's needs, deployment approach, and tolerance for downside > risk of breaking itself. I feel the same way for public key pinning, for the same reason. From ietf@adambarth.com Mon Jan 2 16:51:24 2012 Return-Path: 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 17AFE21F8572 for ; Mon, 2 Jan 2012 16:51:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-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 QfdbO-vOFMqR for ; Mon, 2 Jan 2012 16:51:23 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3DC21F857A for ; Mon, 2 Jan 2012 16:51:22 -0800 (PST) Received: by iabz21 with SMTP id z21so8704953iab.31 for ; Mon, 02 Jan 2012 16:51:21 -0800 (PST) Received: by 10.42.147.72 with SMTP id m8mr53281629icv.56.1325551881091; Mon, 02 Jan 2012 16:51:21 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id cv10sm102954308igc.0.2012.01.02.16.51.19 (version=SSLv3 cipher=OTHER); Mon, 02 Jan 2012 16:51:19 -0800 (PST) Received: by iabz21 with SMTP id z21so8704916iab.31 for ; Mon, 02 Jan 2012 16:51:19 -0800 (PST) Received: by 10.50.6.233 with SMTP id e9mr60236933iga.17.1325551879139; Mon, 02 Jan 2012 16:51:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.62.139 with HTTP; Mon, 2 Jan 2012 16:50:48 -0800 (PST) In-Reply-To: <4F023DD0.8060308@KingsMountain.com> References: <4F023DD0.8060308@KingsMountain.com> From: Adam Barth Date: Mon, 2 Jan 2012 16:50:48 -0800 Message-ID: To: "=JeffH" Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF WebSec WG Subject: Re: [websec] default value for max-age ? (was: Re: Strict-Transport-Security syntax redux) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 00:51:24 -0000 On Mon, Jan 2, 2012 at 3:29 PM, =JeffH wrote: > Julian wondered.. >> >> wouldn't it make sense to have a default for max-age so it >> can be made OPTIONAL? > > hm ... I lean towards keeping max-age as REQUIRED (without a default value) > and thus hopefully encouraging deployers to think a bit about this and its > ramifications, and also because its value is so site-specific in terms of a > web application's needs, deployment approach, and tolerance for downside > risk of breaking itself. Makes sense to me. Chrome currently ignores the header if the server doesn't specify a max-age. Adam From trac+websec@trac.tools.ietf.org Mon Jan 2 18:51:25 2012 Return-Path: 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 0845521F8588 for ; Mon, 2 Jan 2012 18:51:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 55qE064P1ePB for ; Mon, 2 Jan 2012 18:51:24 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 7035D21F8583 for ; Mon, 2 Jan 2012 18:51:24 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RhuSb-0004qQ-Am; Mon, 02 Jan 2012 21:50:45 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "websec issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com X-Trac-Project: websec Date: Tue, 03 Jan 2012 02:50:44 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/33 Message-ID: <070.dc46fc06c043a8103369b4b2f8b4d471@trac.tools.ietf.org> X-Trac-Ticket-ID: 33 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com, websec@ietf.org X-SA-Exim-Mail-From: trac+websec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120103025124.7035D21F8583@ietfa.amsl.com> Resent-Date: Mon, 2 Jan 2012 18:51:24 -0800 (PST) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: [websec] #33: HSTS: quoted-string grammar in (extension) directives ? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 02:51:25 -0000 #33: HSTS: quoted-string grammar in (extension) directives ? (extension) directives are defined having this grammar.. token [ "=" ( token | quoted-string ) ] There is an argument against having quoted-string as part of the grammar. Justification is presented primarily in these messages.. https://www.ietf.org/mail-archive/web/websec/current/msg00781.html (Adam Barth) https://www.ietf.org/mail-archive/web/websec/current/msg00920.html (Adam Barth) ..but also in other messages in the same thread. Nominal summary of argument against inclusion of quoted-string is.. * presently-defined STS header directives don't employ quoted-string syntax * supporting use of quoted-string syntax raises questions of handling error conditions such as unbalanced quotation marks. * present HSTS implementations don't parse quoted-string STS directive values (e.g. max-age="13425") Argument for having quoted-string as a part of the grammar is.. * centered around HTTP header field consistency -- the generic header field syntax in RFC2616 (as well as in the in-progress httpbis update) incorporates quoted-string syntax as a part of header field value components. * because the HSTS header field grammar is extensible, and new directives can be defined in the future which may (need to) use quoted-string syntax. ..as noted here.. https://www.ietf.org/mail-archive/web/websec/current/msg00774.html (Julian Reschke) https://www.ietf.org/mail-archive/web/websec/current/msg00933.html (Julian Reschke) -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-websec-strict-transport- jeff.hodges@… | sec@… Type: defect | Status: new Priority: major | Milestone: Component: strict- | Version: transport-sec | Keywords: Severity: Active WG | Document | -------------------------+------------------------------------------------- Ticket URL: websec From trac+websec@trac.tools.ietf.org Mon Jan 2 18:55:29 2012 Return-Path: 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 42AA121F858B for ; Mon, 2 Jan 2012 18:55:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 OpyzxQrRiIp3 for ; Mon, 2 Jan 2012 18:55:28 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id C537A21F8503 for ; Mon, 2 Jan 2012 18:55:28 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RhuX4-0005E6-GN; Mon, 02 Jan 2012 21:55:22 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "websec issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com X-Trac-Project: websec Date: Tue, 03 Jan 2012 02:55:22 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/27#comment:2 Message-ID: <085.23bbbbda8f68e02eeacc4093c11d3cdc@trac.tools.ietf.org> References: <070.4240e75d9bcd1a27acd9fe924417061f@trac.tools.ietf.org> X-Trac-Ticket-ID: 27 In-Reply-To: <070.4240e75d9bcd1a27acd9fe924417061f@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com, websec@ietf.org X-SA-Exim-Mail-From: trac+websec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120103025528.C537A21F8503@ietfa.amsl.com> Resent-Date: Mon, 2 Jan 2012 18:55:28 -0800 (PST) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: Re: [websec] #27: HSTS header ABNF is a hybrid of RFC2616 and httpbis and is overly complex and broken X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 02:55:29 -0000 #27: HSTS header ABNF is a hybrid of RFC2616 and httpbis and is overly complex and broken Comment (by jeff.hodges@…): The portion of Julian's feedback, as identified in (above) that pertains to quoted-string grammar, is now forked off into this separate issue ticket #33.. http://trac.tools.ietf.org/wg/websec/trac/ticket/33 The other portions of his comments are still under this ticket at this time (see any comments below for any changes) -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-websec-strict- jeff.hodges@… | transport-sec@… Type: defect | Status: new Priority: major | Milestone: Component: strict- | Version: transport-sec | Resolution: Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: websec From ynir@checkpoint.com Mon Jan 2 22:26:43 2012 Return-Path: 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 1ED9621F8560 for ; Mon, 2 Jan 2012 22:26:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 ugJcJLaBgMOM for ; Mon, 2 Jan 2012 22:26:42 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id C96F521F84B2 for ; Mon, 2 Jan 2012 22:26:41 -0800 (PST) X-CheckPoint: {4F029D72-0-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q036Qd4F019071; Tue, 3 Jan 2012 08:26:39 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 3 Jan 2012 08:26:38 +0200 From: Yoav Nir To: =JeffH Date: Tue, 3 Jan 2012 08:26:36 +0200 Thread-Topic: [websec] default value for max-age ? (was: Re: Strict-Transport-Security syntax redux) Thread-Index: AczJ4KW7YBXce8SdTxWBYxcMVLRlug== Message-ID: References: <4F023DD0.8060308@KingsMountain.com> In-Reply-To: <4F023DD0.8060308@KingsMountain.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF WebSec WG Subject: Re: [websec] default value for max-age ? (was: Re: Strict-Transport-Security syntax redux) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 06:26:43 -0000 On Jan 3, 2012, at 1:29 AM, =3DJeffH wrote: > Julian wondered.. >>=20 >> wouldn't it make sense to have a default for max-age so it >> can be made OPTIONAL? >=20 > hm ... I lean towards keeping max-age as REQUIRED (without a default valu= e) and=20 > thus hopefully encouraging deployers to think a bit about this and its=20 > ramifications, and also because its value is so site-specific in terms of= a web=20 > application's needs, deployment approach, and tolerance for downside risk= of=20 > breaking itself. I tend to agree, but it's not deployers who are going to do the thinking - = it's the implementers of web servers.=20 So somewhere, in some control panel for IIS, or a config file for Apache, o= r some WebUI for some SSL-VPN, there's going to be a configuration to turn = on HSTS, and that product is going to have a default max-age. The deployers= are just going to check the box. I think we should provide guidance for those implementers as to what is a g= ood default there. Yoav= From julian.reschke@gmx.de Tue Jan 3 00:20:22 2012 Return-Path: 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 99C4D21F84B9 for ; Tue, 3 Jan 2012 00:20:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.27 X-Spam-Level: X-Spam-Status: No, score=-103.27 tagged_above=-999 required=5 tests=[AWL=-0.671, BAYES_00=-2.599, 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 rWbLwMWatyUa for ; Tue, 3 Jan 2012 00:20:21 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id A651B21F84C8 for ; Tue, 3 Jan 2012 00:20:15 -0800 (PST) Received: (qmail invoked by alias); 03 Jan 2012 08:20:13 -0000 Received: from p3EE26838.dip.t-dialin.net (EHLO [192.168.178.36]) [62.226.104.56] by mail.gmx.net (mp062) with SMTP; 03 Jan 2012 09:20:13 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19/dGIRAKF/9B97wah8Cio+WWF8e29ZGZubZEHBWw ejEQKMAOaEzRV7 Message-ID: <4F02BA38.7040904@gmx.de> Date: Tue, 03 Jan 2012 09:20:08 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Adam Barth References: <4F023DD0.8060308@KingsMountain.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: IETF WebSec WG Subject: Re: [websec] default value for max-age ? (was: Re: Strict-Transport-Security syntax redux) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 08:20:22 -0000 On 2012-01-03 01:50, Adam Barth wrote: > On Mon, Jan 2, 2012 at 3:29 PM, =JeffH wrote: >> Julian wondered.. >>> >>> wouldn't it make sense to have a default for max-age so it >>> can be made OPTIONAL? >> >> hm ... I lean towards keeping max-age as REQUIRED (without a default value) >> and thus hopefully encouraging deployers to think a bit about this and its >> ramifications, and also because its value is so site-specific in terms of a >> web application's needs, deployment approach, and tolerance for downside >> risk of breaking itself. Understood. I just wanted to make sure that the simplification was considered. > Makes sense to me. Chrome currently ignores the header if the server > doesn't specify a max-age. Well yes, the spec says that it's invalid. Best regards, Julian From julian.reschke@gmx.de Tue Jan 3 00:22:24 2012 Return-Path: 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 72E6321F849E for ; Tue, 3 Jan 2012 00:22:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.24 X-Spam-Level: X-Spam-Status: No, score=-103.24 tagged_above=-999 required=5 tests=[AWL=-0.641, BAYES_00=-2.599, 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 9PzPUzaoplW0 for ; Tue, 3 Jan 2012 00:22:23 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 22F7A21F84BA for ; Tue, 3 Jan 2012 00:22:22 -0800 (PST) Received: (qmail invoked by alias); 03 Jan 2012 08:22:21 -0000 Received: from p3EE26838.dip.t-dialin.net (EHLO [192.168.178.36]) [62.226.104.56] by mail.gmx.net (mp011) with SMTP; 03 Jan 2012 09:22:21 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19dq9dDgPtdMwoX+GNtQxJy9XDD5afusMMvMGhBwN QkUZ6xlRhpP4S+ Message-ID: <4F02BABA.9070304@gmx.de> Date: Tue, 03 Jan 2012 09:22:18 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Yoav Nir References: <4F023DD0.8060308@KingsMountain.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: IETF WebSec WG Subject: Re: [websec] default value for max-age ? (was: Re: Strict-Transport-Security syntax redux) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 08:22:24 -0000 On 2012-01-03 07:26, Yoav Nir wrote: > On Jan 3, 2012, at 1:29 AM, =JeffH wrote: > >> Julian wondered.. >>> >>> wouldn't it make sense to have a default for max-age so it >>> can be made OPTIONAL? >> >> hm ... I lean towards keeping max-age as REQUIRED (without a default value) and >> thus hopefully encouraging deployers to think a bit about this and its >> ramifications, and also because its value is so site-specific in terms of a web >> application's needs, deployment approach, and tolerance for downside risk of >> breaking itself. > > I tend to agree, but it's not deployers who are going to do the thinking - it's the implementers of web servers. > > So somewhere, in some control panel for IIS, or a config file for Apache, or some WebUI for some SSL-VPN, there's going to be a configuration to turn on HSTS, and that product is going to have a default max-age. The deployers are just going to check the box. > > I think we should provide guidance for those implementers as to what is a good default there. > ... If we know a good default then it should be the default on the wire (IMHO). It would help getting predictable behavior when it's missing. (Right now the spec allows recipients to do anything they want then it's missing, right?) Best regards, Julian From ietf@adambarth.com Tue Jan 3 01:15:15 2012 Return-Path: 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 EC00F21F84BF for ; Tue, 3 Jan 2012 01:15:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-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 6jGQSHg4xIQ8 for ; Tue, 3 Jan 2012 01:15:15 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 51E6421F8472 for ; Tue, 3 Jan 2012 01:15:15 -0800 (PST) Received: by iabz21 with SMTP id z21so9347531iab.31 for ; Tue, 03 Jan 2012 01:15:15 -0800 (PST) Received: by 10.50.42.167 with SMTP id p7mr62510497igl.20.1325582114913; Tue, 03 Jan 2012 01:15:14 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id pb6sm79079148igc.5.2012.01.03.01.15.13 (version=SSLv3 cipher=OTHER); Tue, 03 Jan 2012 01:15:14 -0800 (PST) Received: by iabz21 with SMTP id z21so9347495iab.31 for ; Tue, 03 Jan 2012 01:15:13 -0800 (PST) Received: by 10.50.47.136 with SMTP id d8mr61541361ign.21.1325582113234; Tue, 03 Jan 2012 01:15:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.62.139 with HTTP; Tue, 3 Jan 2012 01:14:42 -0800 (PST) In-Reply-To: <4F02BABA.9070304@gmx.de> References: <4F023DD0.8060308@KingsMountain.com> <4F02BABA.9070304@gmx.de> From: Adam Barth Date: Tue, 3 Jan 2012 01:14:42 -0800 Message-ID: To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF WebSec WG Subject: Re: [websec] default value for max-age ? (was: Re: Strict-Transport-Security syntax redux) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 09:15:16 -0000 On Tue, Jan 3, 2012 at 12:22 AM, Julian Reschke wrote: > On 2012-01-03 07:26, Yoav Nir wrote: >> >> On Jan 3, 2012, at 1:29 AM, =JeffH wrote: >> >>> Julian wondered.. >>>> >>>> >>>> wouldn't it make sense to have a default for max-age so it >>>> can be made OPTIONAL? >>> >>> >>> hm ... I lean towards keeping max-age as REQUIRED (without a default >>> value) and >>> thus hopefully encouraging deployers to think a bit about this and its >>> ramifications, and also because its value is so site-specific in terms of >>> a web >>> application's needs, deployment approach, and tolerance for downside risk >>> of >>> breaking itself. >> >> >> I tend to agree, but it's not deployers who are going to do the thinking - >> it's the implementers of web servers. >> >> So somewhere, in some control panel for IIS, or a config file for Apache, >> or some WebUI for some SSL-VPN, there's going to be a configuration to turn >> on HSTS, and that product is going to have a default max-age. The deployers >> are just going to check the box. >> >> I think we should provide guidance for those implementers as to what is a >> good default there. >> ... > > > If we know a good default then it should be the default on the wire (IMHO). > It would help getting predictable behavior when it's missing. (Right now the > spec allows recipients to do anything they want then it's missing, right?) We should define the behavior in any case, which I guess means I'm advocating an default max-age of zero. Adam From julian.reschke@gmx.de Tue Jan 3 02:00:00 2012 Return-Path: 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 CCE2F21F8597 for ; Tue, 3 Jan 2012 02:00:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.212 X-Spam-Level: X-Spam-Status: No, score=-103.212 tagged_above=-999 required=5 tests=[AWL=-0.613, BAYES_00=-2.599, 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 qvmym5IOoKjM for ; Tue, 3 Jan 2012 02:00:00 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id E986921F8598 for ; Tue, 3 Jan 2012 01:59:59 -0800 (PST) Received: (qmail invoked by alias); 03 Jan 2012 09:59:58 -0000 Received: from p3EE26838.dip.t-dialin.net (EHLO [192.168.178.36]) [62.226.104.56] by mail.gmx.net (mp029) with SMTP; 03 Jan 2012 10:59:58 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18YZFBklWQY8ESeNpuI+McsEsLlZdAR9Z6UJ1LcdY oaYZyKhNCZcBMU Message-ID: <4F02D193.7070400@gmx.de> Date: Tue, 03 Jan 2012 10:59:47 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Adam Barth References: <4F023DD0.8060308@KingsMountain.com> <4F02BABA.9070304@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: IETF WebSec WG Subject: Re: [websec] default value for max-age ? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 10:00:00 -0000 On 2012-01-03 10:14, Adam Barth wrote: > ... > We should define the behavior in any case, which I guess means I'm > advocating an default max-age of zero. > ... That sounds good to me; so the grammar wouldn't need to enforce this, but the effect would be the same. Best regards, Julian From tobias.gondrom@gondrom.org Wed Jan 4 02:05:41 2012 Return-Path: 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 9B21F21F870E for ; Wed, 4 Jan 2012 02:05:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.778 X-Spam-Level: X-Spam-Status: No, score=-96.778 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 6sSCcvufqzdy for ; Wed, 4 Jan 2012 02:05:41 -0800 (PST) Received: from lvps83-169-7-107.dedicated.hosteurope.de (www.gondrom.org [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id 8EEF721F870D for ; Wed, 4 Jan 2012 02:05:39 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=WtR3SgRfa4Sj0cQKwa28i8J67mp6xYw1HglCXhmjtPP+ePCWgDAySnUY8jgultYfT9chN7bkELNu+4WJf8Vx46z4/EcxPdWCaojXK7XtVKPoExhAjzQ+eJPuZGbMgoX7; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 3218 invoked from network); 4 Jan 2012 11:05:26 +0100 Received: from unknown (HELO ?10.5.8.84?) (61.8.220.69) by www.gondrom.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 4 Jan 2012 11:05:26 +0100 Message-ID: <4F042462.9080206@gondrom.org> Date: Wed, 04 Jan 2012 10:05:22 +0000 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: websec@ietf.org References: <4F023DD0.8060308@KingsMountain.com> <4F02BABA.9070304@gmx.de> In-Reply-To: <4F02BABA.9070304@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [websec] default value for max-age ? (was: Re: Strict-Transport-Security syntax redux) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 10:05:41 -0000 On 03/01/12 08:22, Julian Reschke wrote: > On 2012-01-03 07:26, Yoav Nir wrote: >> On Jan 3, 2012, at 1:29 AM, =JeffH wrote: >> >>> Julian wondered.. >>>> >>>> wouldn't it make sense to have a default for max-age so it >>>> can be made OPTIONAL? >>> >>> hm ... I lean towards keeping max-age as REQUIRED (without a default >>> value) and >>> thus hopefully encouraging deployers to think a bit about this and its >>> ramifications, and also because its value is so site-specific in >>> terms of a web >>> application's needs, deployment approach, and tolerance for downside >>> risk of >>> breaking itself. >> >> I tend to agree, but it's not deployers who are going to do the >> thinking - it's the implementers of web servers. >> >> So somewhere, in some control panel for IIS, or a config file for >> Apache, or some WebUI for some SSL-VPN, there's going to be a >> configuration to turn on HSTS, and that product is going to have a >> default max-age. The deployers are just going to check the box. >> >> I think we should provide guidance for those implementers as to what >> is a good default there. >> ... > > If we know a good default then it should be the default on the wire > (IMHO). It would help getting predictable behavior when it's missing. > (Right now the spec allows recipients to do anything they want then > it's missing, right?) > > Best regards, Julian > well, the optimal default may actually be depending on the host. So we might want to describe what good values might be under which circumstances. E.g. long time-spans when using very trusted process and provider, shorter time-spans with less capable / higher risk of bricking yourself / loosing your private key / ... Thinking about the idea default of max-age = 0: AFAIK this would be equivalent to it being disabled, correct? (Not sure I'd like that: imagine in an Admin GUI you enable HSTS/Cert Pinning and then don't set the max-age and have basically disabled it....) On the other hand I believe the optimal value would be host specific, and therefore there SHOULD NOT be a global default value !=0. :-( (=> Thereby vanishing myself in a puff of logic...) Best regards, Tobias From Jeff.Hodges@KingsMountain.com Wed Jan 4 10:02:03 2012 Return-Path: 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 D0EF121F87FD for ; Wed, 4 Jan 2012 10:02:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.707 X-Spam-Level: X-Spam-Status: No, score=-101.707 tagged_above=-999 required=5 tests=[AWL=0.558, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 Ats+4IHC8ntf for ; Wed, 4 Jan 2012 10:02:02 -0800 (PST) Received: from oproxy8-pub.bluehost.com (oproxy8-pub.bluehost.com [69.89.22.20]) by ietfa.amsl.com (Postfix) with SMTP id D311521F87F9 for ; Wed, 4 Jan 2012 10:02:02 -0800 (PST) Received: (qmail 22343 invoked by uid 0); 4 Jan 2012 18:01:40 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy8.bluehost.com with SMTP; 4 Jan 2012 18:01:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=QhJrtqugJdqDe/eacmD0H6Qn0OKOm+qOwJl2mkX9L7I=; b=gphwPBXSXlCF8dfhT6pvguYCJkpkLOzD/Q5Be9b5UzR/SAJIx2QFWL9N1nL4wl9FkJnJuPGB1oMtZ6sMpBYEbBJtV0+t1muRhFQiCFZwOMc1+lA3rAKmMQ0xQJM98k4y; Received: from c-24-4-122-173.hsd1.ca.comcast.net ([24.4.122.173] helo=[192.168.11.18]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1RiV9e-00058A-IR for websec@ietf.org; Wed, 04 Jan 2012 11:01:38 -0700 Message-ID: <4F0493FF.1090804@KingsMountain.com> Date: Wed, 04 Jan 2012 10:01:35 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: IETF WebSec WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Subject: Re: [websec] default value for max-age ? (was: Re: Strict-Transport-Security syntax redux) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 18:02:04 -0000 Yoav Nir said.. > > On Jan 3, 2012, at 1:29 AM, =JeffH wrote: > >> Julian wondered.. >>> >>> wouldn't it make sense to have a default for max-age so it can be made >>> OPTIONAL? >> >> hm ... I lean towards keeping max-age as REQUIRED (without a default >> value) and thus hopefully encouraging deployers to think a bit about this >> and its ramifications, and also because its value is so site-specific in >> terms of a web application's needs, deployment approach, and tolerance for >> downside risk of breaking itself. > > I tend to agree, but it's not deployers who are going to do the thinking - > it's the implementers of web servers. > > So somewhere, in some control panel for IIS, or a config file for Apache, or > some WebUI for some SSL-VPN, there's going to be a configuration to turn on > HSTS, and that product is going to have a default max-age. The deployers are > just going to check the box. > > I think we should provide guidance for those implementers as to what is a > good default there. Yep, very good point, thanks. Adam Barth replied.. > > On Tue, Jan 3, 2012 at 12:22 AM, Julian Reschke wrote: >> On 2012-01-03 07:26, Yoav Nir wrote: >>> >>> On Jan 3, 2012, at 1:29 AM, =JeffH wrote: >>> >>>> Julian wondered.. >>>>> >>>>> >>>>> wouldn't it make sense to have a default for max-age so it >>>>> can be made OPTIONAL? >>>> >>>> >>>> hm ... I lean towards keeping max-age as REQUIRED (without a default >>>> value) and >>>> thus hopefully encouraging deployers to think a bit about this and its >>>> ramifications, and also because its value is so site-specific in terms of >>>> a web >>>> application's needs, deployment approach, and tolerance for downside risk >>>> of >>>> breaking itself. >>> >>> >>> I tend to agree, but it's not deployers who are going to do the thinking - >>> it's the implementers of web servers. >>> >>> So somewhere, in some control panel for IIS, or a config file for Apache, >>> or some WebUI for some SSL-VPN, there's going to be a configuration to turn >>> on HSTS, and that product is going to have a default max-age. The deployers >>> are just going to check the box. >>> >>> I think we should provide guidance for those implementers as to what is a >>> good default there. >>> ... >> >> >> If we know a good default then it should be the default on the wire (IMHO). >> It would help getting predictable behavior when it's missing. (Right now the >> spec allows recipients to do anything they want then it's missing, right?) > > We should define the behavior in any case, which I guess means I'm > advocating an default max-age of zero. Julian followed up.. > > That sounds good to me; so the grammar wouldn't need to enforce this, > but the effect would be the same. sounds fine to me too. I have text in my working copy in (newly numbered section) "10.1. HSTS Policy expiration time considerations" addressing the above. And so did Tobias.. > > well, the optimal default may actually be depending on the host. > So we might want to describe what good values might be under which > circumstances. > E.g. long time-spans when using very trusted process and provider, > shorter time-spans with less capable / higher risk of bricking yourself > / loosing your private key / ... Yes, i've been thinking about such language and will add a stab at it to section 10.1. =JeffH From tobias.gondrom@gondrom.org Wed Jan 4 20:55:20 2012 Return-Path: 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 3DFEC21F84D7 for ; Wed, 4 Jan 2012 20:55:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.778 X-Spam-Level: X-Spam-Status: No, score=-96.778 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 F-Qr481CQ0Xs for ; Wed, 4 Jan 2012 20:55:19 -0800 (PST) Received: from lvps83-169-7-107.dedicated.hosteurope.de (www.gondrom.org [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id 50B1B21F84C3 for ; Wed, 4 Jan 2012 20:55:19 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=ACosOWwRgN+eoUmqRxClbEdywJTYWwJizGiZvAQNQ5Wno1J+eY9yDgtg5ph0/yyzep07DLVfzrgYoW7XIN3XIN5s0sOa4RaPqWZt1RxQUyz4smhQw+eOxXCdOxAbuQb5; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 11380 invoked from network); 5 Jan 2012 05:55:13 +0100 Received: from unknown (HELO ?10.5.8.84?) (61.8.220.69) by www.gondrom.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 5 Jan 2012 05:55:13 +0100 Message-ID: <4F052D2E.5050200@gondrom.org> Date: Thu, 05 Jan 2012 04:55:10 +0000 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: websec@ietf.org References: <4EAB66B3.4090404@KingsMountain.com> <4EABB25E.9000900@gmx.de> <4EFC5F7B.7050304@gmx.de> <4EFCD7E4.5060507@gmx.de> <4EFCDA9C.90308@gmx.de> <4EFCDDD5.6040005@gmx.de> <4EFD73E6.1060506@gmx.de> <4EFD7C09.9050702@gmx.de> <4EFD8BCE.7010909@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [websec] Strict-Transport-Security syntax redux X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 04:55:20 -0000 Hello websec fellows, as it seems there is disagreement on how to resolve this, with only very few people having spoken out so far, I would like to invite comments from other working group members on this topic to see whether we might have missed something. Best regards, Tobias On 30/12/11 18:37, Adam Barth wrote: > It seems we're not in agreement. We can repeat the same arguments > over and over again, but it's not clear that would be productive. > > Adam > > > On Fri, Dec 30, 2011 at 2:00 AM, Julian Reschke wrote: >> On 2011-12-30 10:13, Adam Barth wrote: >>> Using quoted-string in the extension directive is the wrong thing to >>> do. Because none of the actual directives use quoted-string, folks >>> are likely to write parsers that don't handle all the complexities of >>> quoted-string (which are legion). That means when we go to actually >>> use quoted-string in a future directive, it won't actually work in >>> many user agents. >> >> Unless we clarify the syntax, allow q-s everywhere, and have test cases. >> >> >>> On the other hand, if we spec the extension directives without >>> quoted-string, future extensions will work even if folks mistakenly >>> implement quote-string (because DQUOTE is forbidden in the extension >>> syntax I suggested above, so we'll never trigger the mistaken >>> quoted-string parsing code). Everyone lives a happy life. >> >> Absolutely not. >> >> First of all, some implementations will parse q-s, because that's consistent >> with other header fields. Also, not having q-s makes certain values >> impossible to send, in which case you'll need to invent yet another escaping >> syntax. >> >> >>> Anyway, it's all somewhat of a moot point because the above will >>> happen regardless of what we write in the spec. Even if we write >>> quoted-string, when folks attempt to use these extension directives in >>> the future, they'll find that they don't work and they'll update the >>> syntax not to use quoted-string. >> >> Why would they find that? Implementations can be fixed. >> >> Or is this argument based on the fact that you *currently* "own" one >> implementation and claim it can't be fixed? That would be a very strange >> thing to do in the context of an IETF WG trying to reach consensus. >> >> Best regards, Julian >> >> PS: I note that we are in violent agreement that the syntax should be the >> same for all directives, predefined or extension. We just come to different >> conclusions about what that syntax should be. > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From annevk@opera.com Thu Jan 5 00:20:18 2012 Return-Path: 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 E3D2D21F86B4 for ; Thu, 5 Jan 2012 00:20:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.67 X-Spam-Level: X-Spam-Status: No, score=-7.67 tagged_above=-999 required=5 tests=[AWL=-2.929, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] 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 RBWFLeFLtMH7 for ; Thu, 5 Jan 2012 00:20:15 -0800 (PST) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id C75B021F8681 for ; Thu, 5 Jan 2012 00:20:14 -0800 (PST) Received: from annevk-macbookpro.local (5355737B.cm-6-6b.dynamic.ziggo.nl [83.85.115.123]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q058KCVX005471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 5 Jan 2012 08:20:13 GMT Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: websec@ietf.org References: <4EAB66B3.4090404@KingsMountain.com> <4EABB25E.9000900@gmx.de> <4EFC5F7B.7050304@gmx.de> <4EFCD7E4.5060507@gmx.de> <4EFCDA9C.90308@gmx.de> <4EFCDDD5.6040005@gmx.de> <4EFD73E6.1060506@gmx.de> <4EFD7C09.9050702@gmx.de> <4EFD8BCE.7010909@gmx.de> <4F052D2E.5050200@gondrom.org> Date: Thu, 05 Jan 2012 09:20:27 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Anne van Kesteren" Organization: Opera Software Message-ID: In-Reply-To: <4F052D2E.5050200@gondrom.org> User-Agent: Opera Mail/11.60 (MacIntel) Subject: Re: [websec] Strict-Transport-Security syntax redux X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 08:20:18 -0000 On Thu, 05 Jan 2012 05:55:10 +0100, Tobias Gondrom wrote: > as it seems there is disagreement on how to resolve this, with only very > few people having spoken out so far, I would like to invite comments > from other working group members on this topic to see whether we might > have missed something. I don't really get what the advantage of allowing quoted string here is. If we can use a simpler production, what is wrong with using that? -- Anne van Kesteren http://annevankesteren.nl/ From julian.reschke@gmx.de Thu Jan 5 00:54:52 2012 Return-Path: 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 1CB9A21F8749 for ; Thu, 5 Jan 2012 00:54:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.742 X-Spam-Level: X-Spam-Status: No, score=-103.742 tagged_above=-999 required=5 tests=[AWL=-1.143, BAYES_00=-2.599, 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 2aBYso9pYwRi for ; Thu, 5 Jan 2012 00:54:51 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id E02E221F8751 for ; Thu, 5 Jan 2012 00:54:50 -0800 (PST) Received: (qmail invoked by alias); 05 Jan 2012 08:54:48 -0000 Received: from p5DCC2522.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.37.34] by mail.gmx.net (mp065) with SMTP; 05 Jan 2012 09:54:48 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1855NZDF285+AXpQzsQW47t0jsdC6pK/mx3Vx0ri+ tL3w6we8D5J6+q Message-ID: <4F056553.9030409@gmx.de> Date: Thu, 05 Jan 2012 09:54:43 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Anne van Kesteren References: <4EAB66B3.4090404@KingsMountain.com> <4EABB25E.9000900@gmx.de> <4EFC5F7B.7050304@gmx.de> <4EFCD7E4.5060507@gmx.de> <4EFCDA9C.90308@gmx.de> <4EFCDDD5.6040005@gmx.de> <4EFD73E6.1060506@gmx.de> <4EFD7C09.9050702@gmx.de> <4EFD8BCE.7010909@gmx.de> <4F052D2E.5050200@gondrom.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: websec@ietf.org Subject: Re: [websec] Strict-Transport-Security syntax redux X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 08:54:52 -0000 On 2012-01-05 09:20, Anne van Kesteren wrote: > On Thu, 05 Jan 2012 05:55:10 +0100, Tobias Gondrom > wrote: >> as it seems there is disagreement on how to resolve this, with only >> very few people having spoken out so far, I would like to invite >> comments from other working group members on this topic to see whether >> we might have missed something. > > I don't really get what the advantage of allowing quoted string here is. > If we can use a simpler production, what is wrong with using that? The advantages are: - you can express values that you can't express with token syntax; if future extensions need non-token characters they will need invent yet another escaping syntax - principle of least surprise and consistency - if quoted-string works in other header fields with param syntax, why not here? etc. On the other hand, I haven't seen convincing arguments for not allowing q-s. Yes, it adds to the complexity of the parser, but this has been implemented many times before already. Best regards, Julian From paul.hoffman@vpnc.org Thu Jan 5 07:59:58 2012 Return-Path: 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 8C8D821F86E2 for ; Thu, 5 Jan 2012 07:59:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, 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 vsoCtcBYDtme for ; Thu, 5 Jan 2012 07:59:58 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0D321F8582 for ; Thu, 5 Jan 2012 07:59:57 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q05FxvSE078936 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 5 Jan 2012 08:59:57 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Paul Hoffman In-Reply-To: <4F056553.9030409@gmx.de> Date: Thu, 5 Jan 2012 07:59:58 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <553F526C-4433-489B-80B5-4C29E5FB0DC4@vpnc.org> References: <4EAB66B3.4090404@KingsMountain.com> <4EABB25E.9000900@gmx.de> <4EFC5F7B.7050304@gmx.de> <4EFCD7E4.5060507@gmx.de> <4EFCDA9C.90308@gmx.de> <4EFCDDD5.6040005@gmx.de> <4EFD73E6.1060506@gmx.de> <4EFD7C09.9050702@gmx.de> <4EFD8BCE.7010909@gmx.de> <4F052D2E.5050200@gondrom.org> <4F056553.9030409@gmx.de> To: IETF WebSec WG X-Mailer: Apple Mail (2.1251.1) Subject: Re: [websec] Strict-Transport-Security syntax redux X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 15:59:58 -0000 FWIW, I'm with Julian on this, particularly: > - principle of least surprise and consistency - if quoted-string works = in other header fields with param syntax, why not here? "We invented a header that your message-producing software must = special-case" is not a good way to get security. --Paul Hoffman From annevk@opera.com Thu Jan 5 09:50:12 2012 Return-Path: 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 2078D21F8775 for ; Thu, 5 Jan 2012 09:50:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 4jA7bF7VXBHX for ; Thu, 5 Jan 2012 09:50:11 -0800 (PST) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id DE20021F8755 for ; Thu, 5 Jan 2012 09:50:07 -0800 (PST) Received: from annevk-macbookpro.local (a80-127-246-96.mobile.xs4all.nl [80.127.246.96]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q05Ho218031178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 5 Jan 2012 17:50:04 GMT Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: websec@ietf.org References: <4EAB66B3.4090404@KingsMountain.com> <4EABB25E.9000900@gmx.de> <4EFC5F7B.7050304@gmx.de> <4EFCD7E4.5060507@gmx.de> <4EFCDA9C.90308@gmx.de> <4EFCDDD5.6040005@gmx.de> <4EFD73E6.1060506@gmx.de> <4EFD7C09.9050702@gmx.de> <4EFD8BCE.7010909@gmx.de> <4F052D2E.5050200@gondrom.org> <4F056553.9030409@gmx.de> <553F526C-4433-489B-80B5-4C29E5FB0DC4@vpnc.org> Date: Thu, 05 Jan 2012 18:50:01 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Anne van Kesteren" Organization: Opera Software Message-ID: In-Reply-To: <553F526C-4433-489B-80B5-4C29E5FB0DC4@vpnc.org> User-Agent: Opera Mail/11.60 (MacIntel) Subject: Re: [websec] Strict-Transport-Security syntax redux X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 17:50:12 -0000 On Thu, 05 Jan 2012 16:59:58 +0100, Paul Hoffman wrote: > FWIW, I'm with Julian on this, particularly: > >> - principle of least surprise and consistency - if quoted-string works >> in other header fields with param syntax, why not here? > > "We invented a header that your message-producing software must > special-case" is not a good way to get security. If the header-consuming software works that way, it might be the only way. What the right way to go here is kind of depends on how header field values are typically implemented in practice. I suspect it to be rather messy. -- Anne van Kesteren http://annevankesteren.nl/ From julian.reschke@gmx.de Thu Jan 5 10:06:46 2012 Return-Path: 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 90DD021F882D for ; Thu, 5 Jan 2012 10:06:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.87 X-Spam-Level: X-Spam-Status: No, score=-103.87 tagged_above=-999 required=5 tests=[AWL=-1.271, BAYES_00=-2.599, 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 oc-Y540MKcgI for ; Thu, 5 Jan 2012 10:06:46 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id A7B6C21F875F for ; Thu, 5 Jan 2012 10:06:45 -0800 (PST) Received: (qmail invoked by alias); 05 Jan 2012 18:06:44 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp034) with SMTP; 05 Jan 2012 19:06:44 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+A3W9QI3WAgaX3la5ARCfg5RboU7V8NHdcfxhz+m jI/wdt9pOyXaLd Message-ID: <4F05E6B2.8050301@gmx.de> Date: Thu, 05 Jan 2012 19:06:42 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Anne van Kesteren References: <4EAB66B3.4090404@KingsMountain.com> <4EABB25E.9000900@gmx.de> <4EFC5F7B.7050304@gmx.de> <4EFCD7E4.5060507@gmx.de> <4EFCDA9C.90308@gmx.de> <4EFCDDD5.6040005@gmx.de> <4EFD73E6.1060506@gmx.de> <4EFD7C09.9050702@gmx.de> <4EFD8BCE.7010909@gmx.de> <4F052D2E.5050200@gondrom.org> <4F056553.9030409@gmx.de> <553F526C-4433-489B-80B5-4C29E5FB0DC4@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: websec@ietf.org Subject: Re: [websec] Strict-Transport-Security syntax redux X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 18:06:46 -0000 On 2012-01-05 18:50, Anne van Kesteren wrote: > On Thu, 05 Jan 2012 16:59:58 +0100, Paul Hoffman > wrote: >> FWIW, I'm with Julian on this, particularly: >> >>> - principle of least surprise and consistency - if quoted-string >>> works in other header fields with param syntax, why not here? >> >> "We invented a header that your message-producing software must >> special-case" is not a good way to get security. > > If the header-consuming software works that way, it might be the only > way. What the right way to go here is kind of depends on how header > field values are typically implemented in practice. I suspect it to be > rather messy. It is indeed messy. And I think one of the reasons it is that there are too many different formats, and too many special cases within a single format; thus my proposal to allow token/quoted-string for all parameters, and not only some. Best regards, Julian From annevk@opera.com Thu Jan 5 12:22:15 2012 Return-Path: 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 C122021F8719 for ; Thu, 5 Jan 2012 12:22:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.134 X-Spam-Level: X-Spam-Status: No, score=-7.134 tagged_above=-999 required=5 tests=[AWL=-0.535, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 VHSmMiGIuL35 for ; Thu, 5 Jan 2012 12:22:13 -0800 (PST) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 015E621F86F8 for ; Thu, 5 Jan 2012 12:22:11 -0800 (PST) Received: from annevk-macbookpro.local (5355737B.cm-6-6b.dynamic.ziggo.nl [83.85.115.123]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q05KM7hZ004338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 5 Jan 2012 20:22:08 GMT Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Julian Reschke" References: <4EAB66B3.4090404@KingsMountain.com> <4EFCD7E4.5060507@gmx.de> <4EFCDA9C.90308@gmx.de> <4EFCDDD5.6040005@gmx.de> <4EFD73E6.1060506@gmx.de> <4EFD7C09.9050702@gmx.de> <4EFD8BCE.7010909@gmx.de> <4F052D2E.5050200@gondrom.org> <4F056553.9030409@gmx.de> <553F526C-4433-489B-80B5-4C29E5FB0DC4@vpnc.org> <4F05E6B2.8050301@gmx.de> Date: Thu, 05 Jan 2012 21:22:07 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Anne van Kesteren" Organization: Opera Software Message-ID: In-Reply-To: <4F05E6B2.8050301@gmx.de> User-Agent: Opera Mail/11.60 (MacIntel) Cc: websec@ietf.org Subject: Re: [websec] Strict-Transport-Security syntax redux X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 20:22:15 -0000 On Thu, 05 Jan 2012 19:06:42 +0100, Julian Reschke wrote: > It is indeed messy. And I think one of the reasons it is that there are > too many different formats, and too many special cases within a single > format; thus my proposal to allow token/quoted-string for all > parameters, and not only some. Is there some kind of overview of the formats in use and indication of convergence? It seems you have a particular vision and it may be the right one, but without some kind of data it's hard to see where we are. -- Anne van Kesteren http://annevankesteren.nl/ From julian.reschke@gmx.de Thu Jan 5 12:26:04 2012 Return-Path: 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 77F8221F88C1 for ; Thu, 5 Jan 2012 12:26:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, 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 JZkJgtXGv0Zf for ; Thu, 5 Jan 2012 12:26:03 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 400B421F88C2 for ; Thu, 5 Jan 2012 12:26:02 -0800 (PST) Received: (qmail invoked by alias); 05 Jan 2012 20:26:00 -0000 Received: from p5DCC35D2.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.53.210] by mail.gmx.net (mp013) with SMTP; 05 Jan 2012 21:26:00 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+jwe0dF/mjia3ojjC3fAPkW7/siGI5BsuxeDvZeJ CPoqbuxXqSZfWy Message-ID: <4F060755.6080608@gmx.de> Date: Thu, 05 Jan 2012 21:25:57 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Anne van Kesteren References: <4EAB66B3.4090404@KingsMountain.com> <4EFCD7E4.5060507@gmx.de> <4EFCDA9C.90308@gmx.de> <4EFCDDD5.6040005@gmx.de> <4EFD73E6.1060506@gmx.de> <4EFD7C09.9050702@gmx.de> <4EFD8BCE.7010909@gmx.de> <4F052D2E.5050200@gondrom.org> <4F056553.9030409@gmx.de> <553F526C-4433-489B-80B5-4C29E5FB0DC4@vpnc.org> <4F05E6B2.8050301@gmx.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: websec@ietf.org Subject: Re: [websec] Strict-Transport-Security syntax redux X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 20:26:04 -0000 On 2012-01-05 21:22, Anne van Kesteren wrote: > On Thu, 05 Jan 2012 19:06:42 +0100, Julian Reschke > wrote: >> It is indeed messy. And I think one of the reasons it is that there >> are too many different formats, and too many special cases within a >> single format; thus my proposal to allow token/quoted-string for all >> parameters, and not only some. > > Is there some kind of overview of the formats in use and indication of > convergence? It seems you have a particular vision and it may be the > right one, but without some kind of data it's hard to see where we are. Work-in-progress: Best regards, Julian From masinter@adobe.com Sun Jan 8 07:49:59 2012 Return-Path: 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 B71F521F8505 for ; Sun, 8 Jan 2012 07:49:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.254 X-Spam-Level: X-Spam-Status: No, score=-107.254 tagged_above=-999 required=5 tests=[AWL=-2.145, BAYES_05=-1.11, 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 dF1hP3gyKijs for ; Sun, 8 Jan 2012 07:49:58 -0800 (PST) Received: from exprod6og101.obsmtp.com (exprod6og101.obsmtp.com [64.18.1.181]) by ietfa.amsl.com (Postfix) with ESMTP id 4381321F84A1 for ; Sun, 8 Jan 2012 07:49:58 -0800 (PST) Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob101.postini.com ([64.18.5.12]) with SMTP ID DSNKTwm7ES+l/y3XWoi3T6wGGIyaFOLshIxB@postini.com; Sun, 08 Jan 2012 07:49:58 PST Received: from inner-relay-4.eur.adobe.com (inner-relay-4b [10.128.4.237]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id q08FnaPu013584; Sun, 8 Jan 2012 07:49:36 -0800 (PST) Received: from nacas01.corp.adobe.com (nacas01.corp.adobe.com [10.8.189.99]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id q08FnY7o009477; Sun, 8 Jan 2012 07:49:34 -0800 (PST) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nacas01.corp.adobe.com ([10.8.189.99]) with mapi; Sun, 8 Jan 2012 07:49:33 -0800 From: Larry Masinter To: Adam Barth Date: Sun, 8 Jan 2012 07:49:31 -0800 Thread-Topic: [websec] mimesniff feedback, part 2 Thread-Index: AczN0rj3mAMqp3BZTsWNU4WokVvgaQASGHwQ Message-ID: References: <4ED0E230.3010507@gmx.de> <4F068031.3080906@gondrom.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "IETF WebSec WG \(websec@ietf.org\)" Subject: Re: [websec] mimesniff feedback, part 2 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2012 15:49:59 -0000 I've started on editing the sniffing document in earnest.=20 Foolishly, I started going through it from the beginning. Here's a take at= the Abstract to make the scope clearer: HTTP provides a way of labeling content with its Content-Type, an indication of the file format / language by which the content is to be interpreted. Unfortunately, many web servers, as deployed, supply incorrect Content-Type header fields with their HTTP responses. In order to be compatible with these servers, web clients would consider the content of HTTP responses as well as the Content-Type header fields when determining how the content was interpreted (the "effective media type"). Looking at content to determine its type (aka "sniffing") is also used when no Content-Type header is supplied. Overly ambitious sniffing has resulted in a number of security issues in the past. This document specifies methods and options for computing an effective media type, in a way that addresses both security and compatibility considerations. It also discusses the use of sniffing in contexts other than delivery of content via HTTP. I wanted to address the scope by making it clear that the scope of the docu= ment included sniffing outside of content delivered via HTTP. *** Shouldn't sniffed content have a different origin than the content as l= abeled? The only "privilege upgrade" that I've come across seem to be cros= s-origin ones.=20 *** Is sniffing used by servers when clients use file-upload? Doe web serve= rs do sniffing on content to decide what media type to label the content wi= th? Or is sniffing really only scoped to apply to web browsers?
HTTP provides a way of labeling content with its Content-Type, as an indication of the file format / language by which the content is to be interpreted. Unfortunately, many web servers, as deployed, supply incorrect Content-Type header fields with their HTTP responses. In order to be compatible with these servers, web clients would consider the content of HTTP responses as well as the Content-Type header fields when determining how the content was interpreted (the "effective media type"). Looking at content to determine its type (aka "sniffing") is also used when no Content-Type header is supplied. I tried to introduce "effective media type" as it was used before defined. Where is the term "privilege escalation", as used in this document, defined= ? http://en.wikipedia.org/wiki/Privilege_escalation defines the term in general, and then at the end mentions a couple of examp= les under =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Dbegin Wikipedia quote =3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D "Examples of horizontal privilege escalation" This problem often occurs in web applications. Consider the following examp= le: User A has access to his/her bank account in an Internet Banking applicatio= n. User B has access to his/her bank account in the same Internet Banking appl= ication. The vulnerability occurs when User A is able to access User B's bank accoun= t by performing some sort of malicious activity. This malicious activity may be possible due to common web application weakn= esses or vulnerabilities. Potential web application vulnerabilities or situations that may lead to th= is condition include: * Predictable session ID's in the user's HTTP cookie * Session fixation * Cross-site Scripting * Easily guessable passwords * Theft or hijacking of session cookies * Keystroke logging =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Dend Wikipedia quote =3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D But there are no mentions there of sniffing is a source of privilege escala= tion. Surely since this is the main use case the specification is intended to mi= tigate, shouldn't it be described somewhere?=20 The examples given in passing in the document seem to be XSS attacks (which= would be mitigated merely by giving sniffed content a different unique ori= gin, wouldn't it?)=20 The abstract implies there might be other attacks too... are there? what = are they? Larry -- http://larry.masinter.net From masinter@adobe.com Sun Jan 8 09:12:37 2012 Return-Path: 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 5228921F8532 for ; Sun, 8 Jan 2012 09:12:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.926 X-Spam-Level: X-Spam-Status: No, score=-106.926 tagged_above=-999 required=5 tests=[AWL=-0.328, 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 lOfhNKDl7DOj for ; Sun, 8 Jan 2012 09:12:33 -0800 (PST) Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) by ietfa.amsl.com (Postfix) with ESMTP id CE3FE21F8505 for ; Sun, 8 Jan 2012 09:12:32 -0800 (PST) Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP ID DSNKTwnOa3OGhcKIGdnnOuisGaJb4o6JB3qv@postini.com; Sun, 08 Jan 2012 09:12:33 PST Received: from inner-relay-4.eur.adobe.com (inner-relay-4b [10.128.4.237]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id q08HCAPu018321 for ; Sun, 8 Jan 2012 09:12:11 -0800 (PST) Received: from nacas03.corp.adobe.com (nacas03.corp.adobe.com [10.8.189.121]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id q08HC87o019613 for ; Sun, 8 Jan 2012 09:12:09 -0800 (PST) Received: from SJ1SWM219.corp.adobe.com (10.5.77.61) by nacas03.corp.adobe.com (10.8.189.121) with Microsoft SMTP Server (TLS) id 8.3.192.1; Sun, 8 Jan 2012 09:12:08 -0800 Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by SJ1SWM219.corp.adobe.com ([fe80::d55c:7209:7a34:fcf7%12]) with mapi; Sun, 8 Jan 2012 09:12:08 -0800 From: Larry Masinter To: "IETF WebSec WG (websec@ietf.org)" Date: Sun, 8 Jan 2012 09:12:05 -0800 Thread-Topic: more on sniffing Thread-Index: AczOKJtRf8SMofArQ4eEDCCPBpU92w== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C68CB012D9182D408CED7B884F441D4D06123B4E47nambxv01acorp_" MIME-Version: 1.0 Subject: [websec] more on sniffing X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2012 17:12:37 -0000 --_000_C68CB012D9182D408CED7B884F441D4D06123B4E47nambxv01acorp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
HTTP provides a way of labeling content with its Content-Type, as an indication of the file format / language by which the content is to be interpreted. Unfortunately, many web servers, as deployed, supply incorrect Content-Type header fields with their HTTP responses. In order to be compatible with these servers, web clients would consider the content of HTTP responses as well as the Content-Type header fields when determining how the content was interpreted (the "effective media type"). Looking at content to determine its type (aka "sniffing") is also used when no Content-Type header is supplied. Seemed important to define "sniffing". Q: Why doesn't file upload sniff? Q: where is the concept of 'privilege' defined? Why not treat sniffed content as a different origin to prevent XSS? I'm not sure, but at least some of the bigger unaddressed issues could be i= n the document? Probably the "status of this document" should just point to= the tracker and I should enter in things as issues, not sure how the group= wants to track these. However, overly ambitious sniffing has resulted in a number of security issues in the past. For example, consider a simple server which allows users to upload content, which is then served as simple content such as plain text or an images. However, if the content is subsequently 'sniffed' to be active content; for example, a malicious user might be able to leverage content sniffing to mount a cross-site script attack by including JavaScript code in the uploaded file that a user agent treats as text/html. As I noted before, I wish there were more examples of sniffing security iss= ues since that's the main justification for this document, at least as a 'w= ebsec' document. This document describes a method for sniffing that carefully balances the compatibility needs of user agent implementors with the security constraints. I only changed "algorithm" to "method" because of the many unspecified opti= ons (e.g., how long to wait for additional data). Often, sniffing is done in a context where the use of the data retrieved is not merely for independent presentation, but for embedding (as an image, as video) or other uses (as a style sheet, a script). I think this is the crux of some additional material, where you know that y= ou're sniffing a font or a script or a style sheet, and that knowledge inf= luences the sniffing decision. One can consider 'sniffing' in several categories: Content delivered via a channel which does not allow supplying Content-Type Content delivered via HTTP, but No Content-Type supplied= Content-Type is malformed Content-Type is duplicated with different values Content-Type is syntactically legal, but content clearly= does not match constraints of specified content-type. Content-Type is syntactically legal, content may actually match constraints of specified content-type, but the content is intended for use in a limited context, in which the content could also be interpreted as another type. Content matches the specified content-type constraints, and tha= t type is appropriate for the context of use, but there is some other belief that content has been mislabeled. The supplied content-type usually comes from HTTP, but in some situations, the link to the content contains a content-type. (For example, in a style sheet or script.) This is trying to address the question of when sniffing might result in "fa= lse positives". The main issue is that sniffing needs to come up with a d= efinitive answer ("what is this") even in situations where the signature of= the data is consistent with multiple results (data could be interpreted as= application/octet-stream, text/plain, application/xml, application/somethi= ng1+xml, application/something2+xml, and all of those match the signature d= ata; same issue happens with zip-based packaging formats... ftp: and file: resources also examine the file extension. The widget packaging recommendation, which normatively references some vers= ion of sniffing, also uses file extensions for some content and not others,= but I haven't figured out yet where that belongs. The methods described here have been constructed with reference to content sniffing algorithms present in popular user agents, an extensive database of existing web content, and metrics collected from implementations deployed to a sizable number of users . For reasons discussed in http://www.w3.org/2001/tag/doc/mime-respe= ct, sniffing should be avoided when the content could likely be reasonably interpreted as the content-type supplied. If it is necessary to sniff in such situations, it is preferable to do so only with care, e.g., by offering the user an alternative or explicit choice, or by noting and remembering origins which have content that requires sniffing. This should turn into a reference. I know current implementors don't wan= t to bother warning users that their favorite sites actually are sending ou= t incorrect MIME labels, but we should still recommend it. Sniffing is by its nature a heuristic process, because there are many situations where content matches the signatures and capabilities of many different possible content-type values. False positives result in security problems, while inconsistent sniffing results in interoperability problems. For these reasons, implementations of any receiver of content, attempting to follow the guidelines in this document, MUST NOT result in any value other than those permitted in this specification. I'm still not sure what the scope of this document is, insofar as whether i= t is normative for every browser. Perhaps the best thing is to try to explicitly address "scope" by moving th= ose parts of the introduction which address scope into a separate section. Larry --_000_C68CB012D9182D408CED7B884F441D4D06123B4E47nambxv01acorp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

  &nbs= p; <section anchor=3D"intro" title=3D"Introduction"&= gt;

 

      <t>HTTP provides a way of labeli= ng content with its

   &n= bsp;  Content-Type, as an indication of the file format / language by<= o:p>

      which the= content is to be interpreted.  Unfortunately, many web

=

      servers, as deployed, s= upply incorrect Content-Type header

&nbs= p;     fields with their HTTP responses.  In order= to be compatible

   &nbs= p;  with these servers, web clients would consider the content of=

      HTTP response= s as well as the Content-Type header fields when

      determining how the content was int= erpreted (the "effective

 &nbs= p;    media type").  Looking at content to determi= ne its type (aka

    = ;  "sniffing") is also used when no Content-Type header is

      supplied.&= lt;/t>

     =  

 

Seemed important to define “sniffing”.

=

 

 <= /o:p>

      <list style= =3D"symbols">

  &= nbsp;  <t> Q: Why doesn't file upload sniff? </t>

      <t>Q: where= is the concept

    =   of 'privilege' defined?</t>

      <t> Why not treat sniffed content as = a

      d= ifferent origin to prevent XSS? </t>

      </list>

 

I’m not sure, but a= t least some of the bigger unaddressed issues could be in the document? Pro= bably the “status of this document” should just point to the tr= acker and I should enter in things as issues, not sure how the group wants = to track these.

 

 

  &nb= sp;   <t>However, overly ambitious sniffing has resulted in= a number

     = of security issues in the past. For example, consider a simple<= /p>

      server which allows = users to upload content, which is then

&= nbsp;     served as simple content such as plain text o= r an images.

    &nb= sp; However, if the content is subsequently 'sniffed' to be active

      content; for exam= ple, a malicious user might be able to leverage

      content sniffing to mount a cross-si= te script attack by

   &n= bsp;  including JavaScript code in the uploaded file that a user agent=

      treats a= s text/html.</t>

 =

As I noted before, I wish there were more examples= of sniffing security issues since that’s the main justification for = this document, at least as a ‘websec’ document.

<= p class=3DMsoNormal> 

  &= nbsp;   <t>This document describes a method for sniffing th= at carefully

    &nb= sp; balances the compatibility needs of user agent implementors with the

      security co= nstraints.</t>

 

I only changed “algorithm” to “met= hod” because of the many unspecified options (e.g., how long to wait = for additional data).

 <= /p>

 

 &nb= sp;    <t>Often, sniffing is done in a context where t= he use

     &nb= sp; of the data retrieved is not merely for independent presentation,<= /o:p>

        bu= t for embedding (as an image, as video) or other uses

        (as a style = sheet, a script). </t>

 =

I think this is the crux of some additional = material, where you know that you’re sniffing  a font or a scrip= t or a style sheet, and that knowledge influences the sniffing decision.

 

=       <t>One can consider 'sniffing' in seve= ral categories:

 

       <list style=3D&qu= ot;symbols">

   &= nbsp;            &l= t;t>Content delivered via a channel which does not allow

<= p class=3DMsoNormal>          = supplying Content-Type </t>

 =             &nb= sp;  <t>Content delivered via HTTP, but No Content-Type supplie= d</t>

    &nbs= p;           <t>Co= ntent-Type is malformed</t>

 =         <t>Content-Type is duplica= ted with different values</t>

&nbs= p;            &= nbsp;  <t>Content-Type is syntactically legal, but content clea= rly does not

    &nb= sp;      match constraints of specified content-ty= pe. </t>

    &= nbsp;    <t>Content-Type is syntactically legal, conte= nt may actually match

   =         constraints of specified content= -type, but the content

  &nbs= p;        is intended for use in a = limited context, in which the

 &nbs= p;         content could also be in= terpreted as another type.</t>

&nb= sp;        <t>Content matches the = specified content-type constraints, and that

           type is a= ppropriate for the context of use, but there is some

           o= ther belief that content has been mislabeled.</t>

       </list></t>= ;

     

       <= t>The supplied content-type usually comes from HTTP, but in

       some situations= , the link to the content contains a

&nb= sp;      content-type.  (For example, in a st= yle sheet or script.)

   =    </t>

  &nbs= p;  

This is trying to addres= s the question of when sniffing might result in “false positives̶= 1;.   The main issue is that sniffing needs to come up with a def= initive answer (“what is this”) even in situations where the si= gnature of the data is consistent with multiple results (data could be inte= rpreted as application/octet-stream, text/plain, application/xml, applicati= on/something1+xml, application/something2+xml, and all of those match the s= ignature data; same issue happens with zip-based packaging formats…

 

      <t>ftp: and file: resources also exam= ine the file extension.</t>

&= nbsp;

The widget packaging recommendation, wh= ich normatively references some version of sniffing, also uses file extensi= ons for some content and not others, but I haven’t figured out yet wh= ere that belongs.

 

<= p class=3DMsoNormal> 

  &= nbsp;   <t> The methods described here have been constructe= d with

      re= ference to content sniffing algorithms present in popular user

      agents, an extensive = database of existing web content, and

&n= bsp;     metrics collected from implementations deploye= d to a sizable

    &= nbsp; number of users <xref target=3D"BarthCaballeroSong2009" = />.</t>

 

      <t>For reasons disc= ussed in http://www.w3.org/2001/tag/doc/mime-respect,

     sniffing should be avoided when the = content could likely be reasonably

 = ;    interpreted as the content-type supplied.  If it i= s necessary to sniff

   &= nbsp; in such situations, it is preferable to do so only with care, e.g.,

     by offering the = user an alternative or explicit choice, or by noting

     and remembering origins which have co= ntent that requires sniffing.</t>

=  

This should turn into a reference= .   I know current implementors don’t  want to bother = warning users that their favorite sites actually are sending out incorrect = MIME labels, but we should still recommend it.

 

     &= lt;t>Sniffing is by its nature a heuristic process, because there are

     many situations w= here content matches the signatures and capabilities

     of many different possible content-ty= pe values. False positives result

 =     in security problems, while inconsistent sniffing result= s in

     inte= roperability problems. For these reasons, implementations of

=

     any receiver of content, atte= mpting to follow the guidelines in this

=      document, MUST NOT result in any value other than = those permitted

    = in this specification.</t>

&= nbsp;

I’m still not sure what the scope= of this document is, insofar as whether it is normative for every browser.=

 

Perhaps the best thing is to try to explicitly address “scope̶= 1; by moving those parts of the introduction which address scope into a sep= arate section.

 

Larry

 =

 

= --_000_C68CB012D9182D408CED7B884F441D4D06123B4E47nambxv01acorp_-- From ietf@adambarth.com Sun Jan 8 12:46:24 2012 Return-Path: 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 8413D21F8505 for ; Sun, 8 Jan 2012 12:46:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[AWL=-1.228, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_LOW=-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 E4Lt2bSWR7Ow for ; Sun, 8 Jan 2012 12:46:23 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4A621F851C for ; Sun, 8 Jan 2012 12:46:23 -0800 (PST) Received: by iabz21 with SMTP id z21so6281119iab.31 for ; Sun, 08 Jan 2012 12:46:23 -0800 (PST) Received: by 10.43.53.1 with SMTP id vo1mr16407389icb.2.1326055583289; Sun, 08 Jan 2012 12:46:23 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id he16sm33201483ibb.9.2012.01.08.12.46.22 (version=SSLv3 cipher=OTHER); Sun, 08 Jan 2012 12:46:22 -0800 (PST) Received: by iabz21 with SMTP id z21so6281100iab.31 for ; Sun, 08 Jan 2012 12:46:22 -0800 (PST) Received: by 10.50.170.73 with SMTP id ak9mr6895180igc.17.1326055582082; Sun, 08 Jan 2012 12:46:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.62.139 with HTTP; Sun, 8 Jan 2012 12:45:51 -0800 (PST) In-Reply-To: References: <4ED0E230.3010507@gmx.de> <4F068031.3080906@gondrom.org> From: Adam Barth Date: Sun, 8 Jan 2012 12:45:51 -0800 Message-ID: To: Larry Masinter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "IETF WebSec WG \(websec@ietf.org\)" Subject: Re: [websec] mimesniff feedback, part 2 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2012 20:46:24 -0000 On Sun, Jan 8, 2012 at 7:49 AM, Larry Masinter wrote: > I've started on editing the sniffing document in earnest. > > Foolishly, I started going through it from the beginning. =A0Here's a tak= e at the Abstract to make the scope clearer: > > =A0 =A0 =A0HTTP provides a way of labeling content with its > =A0 =A0 =A0Content-Type, an indication of the file format / language by > =A0 =A0 =A0which the content is to be interpreted. =A0Unfortunately, many= web > =A0 =A0 =A0servers, as deployed, supply incorrect Content-Type header > =A0 =A0 =A0fields with their HTTP responses. =A0In order to be compatible > =A0 =A0 =A0with these servers, web clients would consider the content of > =A0 =A0 =A0HTTP responses as well as the Content-Type header fields when > =A0 =A0 =A0determining how the content was interpreted (the "effective > =A0 =A0 =A0media type"). =A0Looking at content to determine its type (aka > =A0 =A0 =A0"sniffing") is also used when no Content-Type header is > =A0 =A0 =A0supplied. =A0Overly ambitious sniffing has resulted in a numbe= r of > =A0 =A0 =A0security issues in the past. =A0This document specifies method= s > =A0 =A0 =A0and options for computing an effective media type, in a way th= at > =A0 =A0 =A0addresses both security and compatibility considerations. > =A0 =A0 =A0It also discusses the use of sniffing in contexts other than > =A0 =A0 =A0delivery of content via HTTP. > =A0 =A0 =A0 > > I wanted to address the scope by making it clear that the scope of the do= cument included sniffing outside of content delivered via HTTP. > > *** Shouldn't sniffed content have a different origin than the content as= labeled? =A0The only "privilege upgrade" that I've come across seem to be = cross-origin ones. Nope. Browsers would not be able to implement that because it would break too many web sites. > *** Is sniffing used by servers when clients use file-upload? Doe web ser= vers do sniffing on content to decide what media type to label the content = with? Or is sniffing really only scoped =A0to apply to web browsers? That seems out of scope for this document. This is a document for user age= nts. > =A0 =A0
> > =A0 =A0 =A0HTTP provides a way of labeling content with its > =A0 =A0 =A0Content-Type, as an indication of the file format / language b= y > =A0 =A0 =A0which the content is to be interpreted. =A0Unfortunately, many= web > =A0 =A0 =A0servers, as deployed, supply incorrect Content-Type header > =A0 =A0 =A0fields with their HTTP responses. =A0In order to be compatible > =A0 =A0 =A0with these servers, web clients would consider the content of > =A0 =A0 =A0HTTP responses as well as the Content-Type header fields when > =A0 =A0 =A0determining how the content was interpreted (the "effective > =A0 =A0 =A0media type"). =A0Looking at content to determine its type (aka > =A0 =A0 =A0"sniffing") is also used when no Content-Type header is > =A0 =A0 =A0supplied. > > I tried to introduce "effective media type" as it was used before defined= . > > Where is the term "privilege escalation", as used in this document, defin= ed? > > http://en.wikipedia.org/wiki/Privilege_escalation > > defines the term in general, and then at the end mentions a couple of exa= mples under > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Dbegin Wikipedia quote =3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > "Examples of horizontal privilege escalation" > > This problem often occurs in web applications. Consider the following exa= mple: > User A has access to his/her bank account in an Internet Banking applicat= ion. > User B has access to his/her bank account in the same Internet Banking ap= plication. > The vulnerability occurs when User A is able to access User B's bank acco= unt by performing some sort of malicious activity. > This malicious activity may be possible due to common web application wea= knesses or vulnerabilities. > Potential web application vulnerabilities or situations that may lead to = this condition include: > * Predictable session ID's in the user's HTTP cookie > * Session fixation > * Cross-site Scripting > * Easily guessable passwords > * Theft or hijacking of session cookies > * Keystroke logging > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Dend Wikipedia quote =3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > But there are no mentions there of sniffing is a source of privilege esca= lation. Sure, but just because the wikipedia article for privilege escalation doesn't call out sniffing an example doesn't mean that it isn't an example. > =A0Surely since this is the main use case the specification is intended t= o mitigate, shouldn't it be described somewhere? It's just a general term of art. If you like, we can add a reference to Section 3.3 of RFC 6454. > The examples given in passing in the document seem to be XSS attacks (whi= ch would be mitigated merely by giving sniffed content a different unique o= rigin, wouldn't it?) Not in all case, but that's not going to happen, so it's somewhat irrelevan= t. > The =A0abstract implies there might be other attacks too... =A0are there?= what are they? There are other attacks, but XSS is the most important one. I'd rather the reader focused on XSS because that's easiest to understand. Adam From ietf@adambarth.com Sun Jan 8 12:55:48 2012 Return-Path: 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 A070A21F857A for ; Sun, 8 Jan 2012 12:55:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.647 X-Spam-Level: X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[AWL=-1.125, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_LOW=-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 sPlXG817SoFJ for ; Sun, 8 Jan 2012 12:55:47 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7146821F8533 for ; Sun, 8 Jan 2012 12:55:45 -0800 (PST) Received: by iabz21 with SMTP id z21so6289975iab.31 for ; Sun, 08 Jan 2012 12:55:45 -0800 (PST) Received: by 10.42.152.65 with SMTP id h1mr13262589icw.50.1326056144563; Sun, 08 Jan 2012 12:55:44 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id va6sm45162425igc.6.2012.01.08.12.55.43 (version=SSLv3 cipher=OTHER); Sun, 08 Jan 2012 12:55:43 -0800 (PST) Received: by iabz21 with SMTP id z21so6289953iab.31 for ; Sun, 08 Jan 2012 12:55:43 -0800 (PST) Received: by 10.50.219.225 with SMTP id pr1mr7004358igc.21.1326056143165; Sun, 08 Jan 2012 12:55:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.62.139 with HTTP; Sun, 8 Jan 2012 12:55:12 -0800 (PST) In-Reply-To: References: From: Adam Barth Date: Sun, 8 Jan 2012 12:55:12 -0800 Message-ID: To: Larry Masinter Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "IETF WebSec WG \(websec@ietf.org\)" Subject: Re: [websec] more on sniffing X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2012 20:55:48 -0000 On Sun, Jan 8, 2012 at 9:12 AM, Larry Masinter wrote: > =A0=A0=A0
> =A0=A0=A0=A0=A0 HTTP provides a way of labeling content with its > =A0=A0=A0=A0=A0 Content-Type, as an indication of the file format / langu= age by > =A0=A0=A0=A0=A0 which the content is to be interpreted.=A0 Unfortunately,= many web > =A0=A0=A0=A0=A0 servers, as deployed, supply incorrect Content-Type heade= r > =A0=A0 =A0=A0=A0fields with their HTTP responses.=A0 In order to be compa= tible > =A0=A0=A0=A0=A0 with these servers, web clients would consider the conten= t of > =A0=A0=A0=A0=A0 HTTP responses as well as the Content-Type header fields = when > =A0=A0=A0=A0=A0 determining how the content was interpreted (the "effecti= ve > =A0=A0=A0=A0=A0 media type").=A0 Looking at content to determine its type= (aka > =A0=A0=A0=A0=A0 "sniffing") is also used when no Content-Type header is > =A0=A0=A0=A0=A0 supplied. > > Seemed important to define =93sniffing=94. > > =A0=A0=A0=A0=A0 > =A0=A0=A0=A0 Q: Why doesn't file upload sniff? Because it hasn't historically. > =A0=A0=A0=A0=A0 Q: where is the concept > =A0=A0=A0=A0=A0 of 'privilege' defined? RFC 6454, but we might want to update the terminology to "authority" to better align with that document. > =A0=A0=A0=A0=A0 Why not treat sniffed content as a > =A0=A0=A0=A0=A0=A0different origin to prevent XSS? I answered this question in my previous mail. > =A0=A0=A0=A0=A0 > > I=92m not sure, but at least some of the bigger unaddressed issues could = be in > the document? Probably the =93status of this document=94 should just poin= t to > the tracker and I should enter in things as issues, not sure how the grou= p > wants to track these. Referencing the tracker seems fine, but I would assume that's true of every working document in every IETF working group. > =A0=A0=A0=A0=A0 However, overly ambitious sniffing has resulted in a n= umber > =A0=A0=A0=A0=A0 of security issues in the past. For example, consider a s= imple > =A0=A0=A0=A0=A0 server which allows users to upload content, which is the= n > =A0=A0=A0=A0=A0 served as simple content such as plain text or an images. > =A0=A0=A0=A0=A0 However, if the content is subsequently 'sniffed' to be a= ctive > =A0=A0=A0=A0=A0 content; for example, a malicious user might be able to l= everage > =A0=A0=A0=A0=A0 content sniffing to mount a cross-site script attack by > =A0=A0=A0=A0=A0 including JavaScript code in the uploaded file that a use= r agent > =A0=A0=A0=A0=A0 treats as text/html. > > As I noted before, I wish there were more examples of sniffing security > issues since that=92s the main justification for this document, at least = as a > =91websec=92 document. Feel free to add a reference to , which contains a number of concrete attacks. > =A0=A0=A0=A0=A0 This document describes a method for sniffing that car= efully > =A0=A0=A0=A0=A0 balances the compatibility needs of user agent implemento= rs with the > =A0=A0=A0=A0=A0 security constraints. > > I only changed =93algorithm=94 to =93method=94 because of the many unspec= ified > options (e.g., how long to wait for additional data). > > =A0=A0=A0=A0=A0 Often, sniffing is done in a context where the use > =A0=A0=A0=A0=A0=A0 of the data retrieved is not merely for independent pr= esentation, > =A0=A0=A0=A0=A0=A0=A0 but for embedding (as an image, as video) or other = uses > =A0=A0=A0=A0=A0=A0=A0=A0(as a style sheet, a script). > > I think this is the crux of some additional material, where you know that > you=92re sniffing=A0 a font or a script or a style sheet, and that knowle= dge > influences the sniffing decision. > > =A0=A0=A0=A0=A0 One can consider 'sniffing' in several categories: > > =A0=A0=A0=A0=A0=A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Content delivered via a = channel which does not allow > =A0=A0=A0=A0=A0=A0=A0=A0=A0 supplying Content-Type > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Content delivered via HT= TP, but No Content-Type > supplied > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Content-Type is malforme= d > =A0=A0=A0=A0=A0=A0=A0=A0 Content-Type is duplicated with different val= ues > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Content-Type is syntacti= cally legal, but content clearly > does not > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 match constraints of specified content-typ= e. > =A0=A0=A0=A0=A0=A0=A0=A0 Content-Type is syntactically legal, content = may actually match > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 constraints of specified content-type, but= the content > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0is intended for use in a limited context= , in which the > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 content could also be interpreted as anoth= er type. > =A0=A0=A0=A0=A0=A0=A0=A0 Content matches the specified content-type co= nstraints, and that > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 type is appropriate for the context of use= , but there is some > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 other belief that content has been mislabe= led. > =A0=A0=A0=A0=A0=A0 I'm not sure what the point of this taxonomy is. > =A0=A0=A0=A0=A0=A0=A0The supplied content-type usually comes from HTTP= , but in > =A0=A0=A0=A0=A0=A0 some situations, the link to the content contains a > =A0=A0=A0=A0=A0=A0 content-type.=A0 (For example, in a style sheet or scr= ipt.) > =A0=A0=A0=A0=A0 > > This is trying to address the question of when sniffing might result in > =93false positives=94.=A0=A0 The main issue is that sniffing needs to com= e up with a > definitive answer (=93what is this=94) even in situations where the signa= ture of > the data is consistent with multiple results (data could be interpreted a= s > application/octet-stream, text/plain, application/xml, > application/something1+xml, application/something2+xml, and all of those > match the signature data; same issue happens with zip-based packaging > formats=85 Why not just say that then. > =A0=A0=A0=A0=A0 ftp: and file: resources also examine the file extensi= on. > > The widget packaging recommendation, which normatively references some > version of sniffing, also uses file extensions for some content and not > others, but I haven=92t figured out yet where that belongs. The widget spec is very confused. I would pay more attention to code that's been widely deployed. > =A0=A0=A0=A0=A0 The methods described here have been constructed with > =A0=A0=A0=A0=A0 reference to content sniffing algorithms present in popul= ar user > =A0=A0=A0=A0=A0 agents, an extensive database of existing web content, an= d > =A0=A0=A0=A0=A0 metrics collected from implementations deployed to a siza= ble > =A0=A0=A0=A0=A0 number of users . > > =A0=A0=A0=A0=A0 For reasons discussed in > http://www.w3.org/2001/tag/doc/mime-respect, > =A0=A0=A0=A0 sniffing should be avoided when the content could likely be = reasonably > =A0=A0=A0=A0 interpreted as the content-type supplied.=A0 If it is necess= ary to sniff > =A0=A0=A0=A0 in such situations, it is preferable to do so only with care= , e.g., > =A0=A0=A0=A0 by offering the user an alternative or explicit choice, or b= y noting > =A0=A0=A0=A0 and remembering origins which have content that requires sni= ffing. I strongly disagree with this last paragraph. If you have your heart set on adding it, let's discuss it in a separate thread first. > This should turn into a reference. =A0=A0I know current implementors don= =92t =A0want > to bother warning users that their favorite sites actually are sending ou= t > incorrect MIME labels, but we should still recommend it. We shouldn't recommend behavior that implementations aren't going to implem= ent. > =A0=A0=A0=A0 Sniffing is by its nature a heuristic process, because th= ere are > =A0=A0=A0=A0 many situations where content matches the signatures and cap= abilities > =A0=A0=A0=A0 of many different possible content-type values. I disagree with this statement as well. The sniffing we're talking about here is not a heuristic. It's a historical anomaly that needs to be corrected for in order for user agents to be compatible with some web sites. > False positives result > =A0=A0=A0=A0 in security problems, while inconsistent sniffing results in > =A0=A0=A0=A0=A0interoperability problems. For these reasons, implementati= ons of > =A0=A0=A0=A0 any receiver of content, attempting to follow the guidelines= in this > =A0=A0=A0=A0 document, MUST NOT result in any value other than those perm= itted > =A0=A0=A0=A0 in this specification. > > I=92m still not sure what the scope of this document is, insofar as wheth= er it > is normative for every browser. It does. > Perhaps the best thing is to try to explicitly address =93scope=94 by mov= ing > those parts of the introduction which address scope into a separate secti= on. Adam From ietf@adambarth.com Sun Jan 8 13:03:59 2012 Return-Path: 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 58C0E21F8602 for ; Sun, 8 Jan 2012 13:03:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[AWL=-1.039, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_LOW=-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 XUvL9fKKYQJw for ; Sun, 8 Jan 2012 13:03:58 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7E72F21F85FA for ; Sun, 8 Jan 2012 13:03:58 -0800 (PST) Received: by iabz21 with SMTP id z21so6298469iab.31 for ; Sun, 08 Jan 2012 13:03:58 -0800 (PST) Received: by 10.50.156.130 with SMTP id we2mr16239835igb.10.1326056638140; Sun, 08 Jan 2012 13:03:58 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id 36sm242480853ibc.6.2012.01.08.13.03.57 (version=SSLv3 cipher=OTHER); Sun, 08 Jan 2012 13:03:57 -0800 (PST) Received: by iabz21 with SMTP id z21so6298448iab.31 for ; Sun, 08 Jan 2012 13:03:57 -0800 (PST) Received: by 10.50.47.136 with SMTP id d8mr16299795ign.21.1326056637140; Sun, 08 Jan 2012 13:03:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.62.139 with HTTP; Sun, 8 Jan 2012 13:03:26 -0800 (PST) From: Adam Barth Date: Sun, 8 Jan 2012 13:03:26 -0800 Message-ID: To: Larry Masinter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "IETF WebSec WG \(websec@ietf.org\)" Subject: [websec] Is sniffing a heuristic? (was Re: more on sniffing) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2012 21:03:59 -0000 On Sun, Jan 8, 2012 at 12:55 PM, Adam Barth wrote: > On Sun, Jan 8, 2012 at 9:12 AM, Larry Masinter wrote= : >> =A0=A0=A0=A0 Sniffing is by its nature a heuristic process, because t= here are >> =A0=A0=A0=A0 many situations where content matches the signatures and ca= pabilities >> =A0=A0=A0=A0 of many different possible content-type values. > > I disagree with this statement as well. =A0The sniffing we're talking > about here is not a heuristic. =A0It's a historical anomaly that needs > to be corrected for in order for user agents to be compatible with > some web sites. Let me expand this point some more. Does you view the HTML5 parsing algorithm a heuristic? The sniffing algorithm is the same sort of thing as the HTML5 parsing algorithm in that it's a somewhat unpleasant algorithm for interpreting responses from servers that's compatible with existing deployments. Adam From derhoermi@gmx.net Sun Jan 8 15:08:33 2012 Return-Path: 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 9B90921F861A for ; Sun, 8 Jan 2012 15:08:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.116 X-Spam-Level: X-Spam-Status: No, score=-1.116 tagged_above=-999 required=5 tests=[AWL=-0.972, BAYES_00=-2.599, FRT_ADOBE2=2.455] 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 uIOjydECwfEf for ; Sun, 8 Jan 2012 15:08:32 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 8361921F8608 for ; Sun, 8 Jan 2012 15:08:31 -0800 (PST) Received: (qmail invoked by alias); 08 Jan 2012 23:08:28 -0000 Received: from dslb-094-223-221-170.pools.arcor-ip.net (EHLO HIVE) [94.223.221.170] by mail.gmx.net (mp072) with SMTP; 09 Jan 2012 00:08:28 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX19TDutiu3NTioMbI4F9J6rqdHcNHpjJ7Z7A/drWJO uPc6M3EFec9LWT From: Bjoern Hoehrmann To: Adam Barth Date: Mon, 09 Jan 2012 00:08:27 +0100 Message-ID: References: In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: "IETF WebSec WG \(websec@ietf.org\)" Subject: Re: [websec] Is sniffing a heuristic? (was Re: more on sniffing) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2012 23:08:33 -0000 * Adam Barth wrote: >On Sun, Jan 8, 2012 at 12:55 PM, Adam Barth wrote: >> On Sun, Jan 8, 2012 at 9:12 AM, Larry Masinter wrote: >>>      Sniffing is by its nature a heuristic process, because there are >>>      many situations where content matches the signatures and capabilities >>>      of many different possible content-type values. >> >> I disagree with this statement as well.  The sniffing we're talking >> about here is not a heuristic.  It's a historical anomaly that needs >> to be corrected for in order for user agents to be compatible with >> some web sites. > >Let me expand this point some more. Does you view the HTML5 parsing >algorithm a heuristic? The sniffing algorithm is the same sort of >thing as the HTML5 parsing algorithm in that it's a somewhat >unpleasant algorithm for interpreting responses from servers that's >compatible with existing deployments. In computer science heuristics are problem-solving techniques that pro- vide good but not neccesarily correct solutions; they are employed as a trade-off between correctness and other desirable properties. Sniffing produces good results that are not always correct in a trade-off between correctness and other properties like "compatibility", so it's a heuris- tic. The "HTML5" parsing algorithm also produces good results, but there is no widely accepted basis for claiming it produces incorrect results. Saying that the sniffing algorithm always generates correct solutions is like saying the Content-Type header in HTTP responses always has correct media type information. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From masinter@adobe.com Sun Jan 8 16:06:13 2012 Return-Path: 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 C073621F8528 for ; Sun, 8 Jan 2012 16:06:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.817 X-Spam-Level: X-Spam-Status: No, score=-106.817 tagged_above=-999 required=5 tests=[AWL=-0.218, BAYES_00=-2.599, 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 PbQT+52OlR0T for ; Sun, 8 Jan 2012 16:06:13 -0800 (PST) Received: from exprod6og114.obsmtp.com (exprod6og114.obsmtp.com [64.18.1.33]) by ietfa.amsl.com (Postfix) with ESMTP id E09AC21F851D for ; Sun, 8 Jan 2012 16:06:12 -0800 (PST) Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob114.postini.com ([64.18.5.12]) with SMTP ID DSNKTwovcfBFx5WrG95pO2BAf54rfyBAE58M@postini.com; Sun, 08 Jan 2012 16:06:12 PST Received: from inner-relay-4.eur.adobe.com (inner-relay-4.adobe.com [193.104.215.14]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id q0904Haa026570; Sun, 8 Jan 2012 16:04:18 -0800 (PST) Received: from nahub02.corp.adobe.com (nahub02.corp.adobe.com [10.8.189.98]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id q090657o006105; Sun, 8 Jan 2012 16:06:05 -0800 (PST) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nahub02.corp.adobe.com ([10.8.189.98]) with mapi; Sun, 8 Jan 2012 16:06:04 -0800 From: Larry Masinter To: Bjoern Hoehrmann , Adam Barth Date: Sun, 8 Jan 2012 16:06:03 -0800 Thread-Topic: When is sniffing heuristic? Thread-Index: AczOYnThWYRE6GV9RBic65DXqdBRWg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "IETF WebSec WG \(websec@ietf.org\)" Subject: [websec] When is sniffing heuristic? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 00:06:13 -0000 There are several different situations where sniffing is of necessity heuri= stic, because you are 'guessing' the intent of the content. These are due to the fact that the set of possible valid Content-Type value= s does not partition the space of possible bodies. There may be other situations where sniffing is heuristic, but in these cas= es, sniffing is *necessarily* heuristic because there are multiple results = which are valid, and knowing the right result requires additional informati= on about the intent of the communication. The heuristic comes presumably fr= om a manual examination of some web material where such information about i= ntent is known, and projecting that the generalization applies to all such = material and cases. a) Specializations: A file which is, for example, application/xhtml+xml is, of necessity, also = a valid file of type application/xml. If you were to "sniff" some content t= hat was valid application/xhtml+xml, you could also legitimately claim it w= as application/xml. Most data types which are 'text' are also text/plain. Every type is a subset of application/octet-stream. There are numerable examples of this, and a large number of failure cases, = e.g., zip-based packaging formats being sniffed as zip when the specializat= ion isn't correctly recognized, image/dng which is sniffed to be image/tif= f, etc. b) "Polyglot": This is a situation where data is intentionally prepared to be interpretabl= e as two different media types, possibly to be served and later processed a= s either, where the intention of the content is to behave similarly for ord= inary processing, but amenable to specialized processing only defined for o= ne or the other media type. The XHTML/HTML polyglot spec http://dev.w3.org/html5/html-xhtml-author-guide/ is of course is the most relevant use case. The same content could be sniff= ed to be either type. This is different from the specialization case becau= se neither of the media types are subsets of the other. c) "Multiview" I don't know exactly what to call this, but it is the situation where the s= ame content is valid as two different media types intentionally, the media = types do not overlap but the treatment as the different types is intentiona= lly different. The use case for multiview I was looking at was one where t= he same content could be viewed as XHTML (for a presentational view) and a= lso as RDF (for a data point of view). This is different from specialization (since the two types overlap but one = is not a subset of the other), and polyglot (since the material is intended= to have different meaning in its ordinary application). From derhoermi@gmx.net Sun Jan 8 16:10:37 2012 Return-Path: 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 0325021F8536 for ; Sun, 8 Jan 2012 16:10:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.246 X-Spam-Level: X-Spam-Status: No, score=-2.246 tagged_above=-999 required=5 tests=[AWL=0.353, BAYES_00=-2.599] 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 4oCOs+xx6EY0 for ; Sun, 8 Jan 2012 16:10:36 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id CA63821F8534 for ; Sun, 8 Jan 2012 16:10:35 -0800 (PST) Received: (qmail invoked by alias); 09 Jan 2012 00:10:15 -0000 Received: from dslb-094-223-221-170.pools.arcor-ip.net (EHLO HIVE) [94.223.221.170] by mail.gmx.net (mp062) with SMTP; 09 Jan 2012 01:10:15 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX18PVw0MsgQPJ97LDfGt6nhU845KboDOVVasIT0WyM 6j0uOfKRHw2tD6 From: Bjoern Hoehrmann To: Tobias Gondrom Date: Mon, 09 Jan 2012 01:10:16 +0100 Message-ID: References: <4EFCDDD5.6040005@gmx.de> <4EFD73E6.1060506@gmx.de> <4EFD7C09.9050702@gmx.de> <4EFD8BCE.7010909@gmx.de> <4F052D2E.5050200@gondrom.org> In-Reply-To: <4F052D2E.5050200@gondrom.org> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: websec@ietf.org Subject: Re: [websec] Strict-Transport-Security syntax redux X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 00:10:37 -0000 * Tobias Gondrom wrote: > >as it seems there is disagreement on how to resolve this, with only very >few people having spoken out so far, I would like to invite comments >from other working group members on this topic to see whether we might >have missed something. It seems to me that all headers defined in RFC 2616 that allow para- meteter lists of the `;name=value` form allow the value to be a quoted string. If the Working Group wishes to disallow quoted strings, then it should use a format that's very different from the existing syntax, like `name=value&name=other%20value` or JSON or whatever. "Similar but slightly different" always translate into bugs. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From ietf@adambarth.com Sun Jan 8 16:26:04 2012 Return-Path: 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 7786B21F85D6 for ; Sun, 8 Jan 2012 16:26:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.714 X-Spam-Level: X-Spam-Status: No, score=-2.714 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-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 gt99CQPAAVET for ; Sun, 8 Jan 2012 16:26:03 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id C0B5121F849C for ; Sun, 8 Jan 2012 16:26:03 -0800 (PST) Received: by iabz21 with SMTP id z21so6488135iab.31 for ; Sun, 08 Jan 2012 16:26:03 -0800 (PST) Received: by 10.50.207.72 with SMTP id lu8mr16956520igc.0.1326068763422; Sun, 08 Jan 2012 16:26:03 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id 36sm244238590ibc.6.2012.01.08.16.26.02 (version=SSLv3 cipher=OTHER); Sun, 08 Jan 2012 16:26:02 -0800 (PST) Received: by iabz21 with SMTP id z21so6488113iab.31 for ; Sun, 08 Jan 2012 16:26:02 -0800 (PST) Received: by 10.42.151.195 with SMTP id f3mr13655565icw.19.1326068762124; Sun, 08 Jan 2012 16:26:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.62.139 with HTTP; Sun, 8 Jan 2012 16:25:31 -0800 (PST) In-Reply-To: References: <4EFCDDD5.6040005@gmx.de> <4EFD73E6.1060506@gmx.de> <4EFD7C09.9050702@gmx.de> <4EFD8BCE.7010909@gmx.de> <4F052D2E.5050200@gondrom.org> From: Adam Barth Date: Sun, 8 Jan 2012 16:25:31 -0800 Message-ID: To: Bjoern Hoehrmann Content-Type: text/plain; charset=ISO-8859-1 Cc: websec@ietf.org Subject: Re: [websec] Strict-Transport-Security syntax redux X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 00:26:04 -0000 On Sun, Jan 8, 2012 at 4:10 PM, Bjoern Hoehrmann wrote: > * Tobias Gondrom wrote: >> >>as it seems there is disagreement on how to resolve this, with only very >>few people having spoken out so far, I would like to invite comments >>from other working group members on this topic to see whether we might >>have missed something. > > It seems to me that all headers defined in RFC 2616 that allow para- > meteter lists of the `;name=value` form allow the value to be a quoted > string. This header isn't defined in RFC 2616 and many headers defined outside of RFC 2616 don't use quoted-string. Adam > If the Working Group wishes to disallow quoted strings, then > it should use a format that's very different from the existing syntax, > like `name=value&name=other%20value` or JSON or whatever. "Similar but > slightly different" always translate into bugs. From julian.reschke@gmx.de Sun Jan 8 16:39:11 2012 Return-Path: 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 1057F21F85D6 for ; Sun, 8 Jan 2012 16:39:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.443 X-Spam-Level: X-Spam-Status: No, score=-103.443 tagged_above=-999 required=5 tests=[AWL=-0.844, BAYES_00=-2.599, 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 SSVuiSMpX3cc for ; Sun, 8 Jan 2012 16:39:10 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 2ACD221F8504 for ; Sun, 8 Jan 2012 16:39:09 -0800 (PST) Received: (qmail invoked by alias); 09 Jan 2012 00:39:09 -0000 Received: from p3EE26BEB.dip.t-dialin.net (EHLO [192.168.178.36]) [62.226.107.235] by mail.gmx.net (mp018) with SMTP; 09 Jan 2012 01:39:09 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+73nJfsDa7ehxcZX+a1+gdbJ2Jcuo+UYpFsg8TcY Z4l8CN2C8sMib7 Message-ID: <4F0A372B.2070407@gmx.de> Date: Mon, 09 Jan 2012 01:39:07 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Adam Barth References: <4EFCDDD5.6040005@gmx.de> <4EFD73E6.1060506@gmx.de> <4EFD7C09.9050702@gmx.de> <4EFD8BCE.7010909@gmx.de> <4F052D2E.5050200@gondrom.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Bjoern Hoehrmann , websec@ietf.org Subject: Re: [websec] Strict-Transport-Security syntax redux X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 00:39:11 -0000 On 2012-01-09 01:25, Adam Barth wrote: > On Sun, Jan 8, 2012 at 4:10 PM, Bjoern Hoehrmann wrote: >> * Tobias Gondrom wrote: >>> >>> as it seems there is disagreement on how to resolve this, with only very >>> few people having spoken out so far, I would like to invite comments >> >from other working group members on this topic to see whether we might >>> have missed something. >> >> It seems to me that all headers defined in RFC 2616 that allow para- >> meteter lists of the `;name=value` form allow the value to be a quoted >> string. > > This header isn't defined in RFC 2616 and many headers defined outside > of RFC 2616 don't use quoted-string. > ... In name/value pairs? Example? (As a matter of fact, not all header fields in 2616 are as consistent as they should, but that's not an excuse for not trying to do better with new header fields) Best regards, Julian From paul.hoffman@vpnc.org Sun Jan 8 18:17:33 2012 Return-Path: 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 D499021F85C6 for ; Sun, 8 Jan 2012 18:17:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, 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 J954gkJyVR4x for ; Sun, 8 Jan 2012 18:17:33 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 667C821F85C0 for ; Sun, 8 Jan 2012 18:17:33 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q092HUBp032957 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 8 Jan 2012 19:17:30 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Sun, 8 Jan 2012 18:17:29 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <5E3D100F-863A-4C78-B432-B2A4104D3DDA@vpnc.org> References: <4EFCDDD5.6040005@gmx.de> <4EFD73E6.1060506@gmx.de> <4EFD7C09.9050702@gmx.de> <4EFD8BCE.7010909@gmx.de> <4F052D2E.5050200@gondrom.org> To: Adam Barth X-Mailer: Apple Mail (2.1251.1) Cc: IETF WebSec WG Subject: Re: [websec] Strict-Transport-Security syntax redux X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 02:17:33 -0000 On Jan 8, 2012, at 4:25 PM, Adam Barth wrote: > This header isn't defined in RFC 2616 and many headers defined outside > of RFC 2616 don't use quoted-string. I haven't completely kept up on new headers, but I think "many" may be = an overstatement (but am happy to be proven wrong). The fact that one or = two got it wrong shouldn't guide us: security robustness should. --Paul Hoffman From tobias.gondrom@gondrom.org Sun Jan 8 20:43:43 2012 Return-Path: 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 9F23721F85E4 for ; Sun, 8 Jan 2012 20:43:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.55 X-Spam-Level: X-Spam-Status: No, score=-95.55 tagged_above=-999 required=5 tests=[AWL=-1.227, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FRT_ADOBE2=2.455, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 xR-aW3zudBx5 for ; Sun, 8 Jan 2012 20:43:42 -0800 (PST) Received: from lvps83-169-7-107.dedicated.hosteurope.de (www.gondrom.org [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id 9893321F8629 for ; Sun, 8 Jan 2012 20:43:41 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=VFj3KpgsuX6ENHzji8tOKFelqq60PeDTOKwKufUNOW+kH3scRqVwcWGRlfWJlqDvCoBTyee5OM4kvoDKulLSXEMISiMPKa5Dd6ndT66HX8GKjH8lFUY88SlUNRW6K2aV; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 22408 invoked from network); 9 Jan 2012 05:43:34 +0100 Received: from unknown (HELO ?10.5.8.84?) (61.8.220.69) by www.gondrom.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 9 Jan 2012 05:43:34 +0100 Message-ID: <4F0A7073.4040905@gondrom.org> Date: Mon, 09 Jan 2012 04:43:31 +0000 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: ietf@adambarth.com References: <4ED0E230.3010507@gmx.de> <4F068031.3080906@gondrom.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: websec@ietf.org Subject: Re: [websec] mimesniff feedback, part 2 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 04:43:43 -0000 On 08/01/12 20:45, Adam Barth wrote: > On Sun, Jan 8, 2012 at 7:49 AM, Larry Masinter wrote: >> I've started on editing the sniffing document in earnest. >> >> Foolishly, I started going through it from the beginning. Here's a take at the Abstract to make the scope clearer: >> >> HTTP provides a way of labeling content with its >> Content-Type, an indication of the file format / language by >> which the content is to be interpreted. Unfortunately, many web >> servers, as deployed, supply incorrect Content-Type header >> fields with their HTTP responses. In order to be compatible >> with these servers, web clients would consider the content of >> HTTP responses as well as the Content-Type header fields when >> determining how the content was interpreted (the "effective >> media type"). Looking at content to determine its type (aka >> "sniffing") is also used when no Content-Type header is >> supplied. Overly ambitious sniffing has resulted in a number of >> security issues in the past. This document specifies methods >> and options for computing an effective media type, in a way that >> addresses both security and compatibility considerations. >> It also discusses the use of sniffing in contexts other than >> delivery of content via HTTP. >> >> >> I wanted to address the scope by making it clear that the scope of the document included sniffing outside of content delivered via HTTP. >> >> *** Shouldn't sniffed content have a different origin than the content as labeled? The only "privilege upgrade" that I've come across seem to be cross-origin ones. > Nope. Browsers would not be able to implement that because it would > break too many web sites. > >> *** Is sniffing used by servers when clients use file-upload? Doe web servers do sniffing on content to decide what media type to label the content with? Or is sniffing really only scoped to apply to web browsers? > That seems out of scope for this document. This is a document for user agents. Well, just to be clear, I would imagine that there might be "user agents" running as a server process and doing sniffing on uploaded content. (e.g. Imagine a user uploading a document and specifying the content-type incorrectly or not at all). If any server would do some sniffing, it would be very likely that they will employ the same rule-set (algorithm?) and/or re-use the existing client libraries for sniffing. And actually, personally I would even strongly recommend to use the same rules, as this would at least avoid inconsistent (and unexpected) results. >>
>> >> HTTP provides a way of labeling content with its >> Content-Type, as an indication of the file format / language by >> which the content is to be interpreted. Unfortunately, many web >> servers, as deployed, supply incorrect Content-Type header >> fields with their HTTP responses. In order to be compatible >> with these servers, web clients would consider the content of >> HTTP responses as well as the Content-Type header fields when >> determining how the content was interpreted (the "effective >> media type"). Looking at content to determine its type (aka >> "sniffing") is also used when no Content-Type header is >> supplied. >> >> I tried to introduce "effective media type" as it was used before defined. >> >> Where is the term "privilege escalation", as used in this document, defined? >> >> http://en.wikipedia.org/wiki/Privilege_escalation >> >> defines the term in general, and then at the end mentions a couple of examples under >> >> ===============begin Wikipedia quote =========================== >> "Examples of horizontal privilege escalation" >> >> This problem often occurs in web applications. Consider the following example: >> User A has access to his/her bank account in an Internet Banking application. >> User B has access to his/her bank account in the same Internet Banking application. >> The vulnerability occurs when User A is able to access User B's bank account by performing some sort of malicious activity. >> This malicious activity may be possible due to common web application weaknesses or vulnerabilities. >> Potential web application vulnerabilities or situations that may lead to this condition include: >> * Predictable session ID's in the user's HTTP cookie >> * Session fixation >> * Cross-site Scripting >> * Easily guessable passwords >> * Theft or hijacking of session cookies >> * Keystroke logging >> ===============end Wikipedia quote ========================== >> >> But there are no mentions there of sniffing is a source of privilege escalation. > Sure, but just because the wikipedia article for privilege escalation > doesn't call out sniffing an example doesn't mean that it isn't an > example. Well, for Wiki: it does not claim completeness, so we just correct/amend the Wiki article. >> Surely since this is the main use case the specification is intended to mitigate, shouldn't it be described somewhere? > It's just a general term of art. If you like, we can add a reference > to Section 3.3 of RFC 6454. > >> The examples given in passing in the document seem to be XSS attacks (which would be mitigated merely by giving sniffed content a different unique origin, wouldn't it?) > Not in all case, but that's not going to happen, so it's somewhat irrelevant. > >> The abstract implies there might be other attacks too... are there? what are they? > There are other attacks, but XSS is the most important one. I'd > rather the reader focused on XSS because that's easiest to understand. Agree with Adam's recommendation on this. Currently XSS is the most prevalent risk for that. So it seems ok to focus on that. The existing example cases should be sufficient to illustrate the problem and principle. > > Adam Best regards, Tobias From gerv@mozilla.org Mon Jan 9 01:13:06 2012 Return-Path: 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 3E12C21F86A5 for ; Mon, 9 Jan 2012 01:13:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 nn-h9Vk5K0Ti for ; Mon, 9 Jan 2012 01:13:05 -0800 (PST) Received: from dm-mail03.mozilla.org (dm-mail03.mozilla.org [63.245.208.213]) by ietfa.amsl.com (Postfix) with ESMTP id ADBF421F866E for ; Mon, 9 Jan 2012 01:13:05 -0800 (PST) Received: from [192.168.0.101] (93.243.187.81.in-addr.arpa [81.187.243.93]) (Authenticated sender: gerv@mozilla.org) by dm-mail03.mozilla.org (Postfix) with ESMTP id 0288B4AEDD4; Mon, 9 Jan 2012 01:13:03 -0800 (PST) Message-ID: <4F0AAF9D.2080006@mozilla.org> Date: Mon, 09 Jan 2012 09:13:01 +0000 From: Gervase Markham User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111214 Thunderbird/9.0 MIME-Version: 1.0 To: Bjoern Hoehrmann References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "IETF WebSec WG \(websec@ietf.org\)" Subject: Re: [websec] Is sniffing a heuristic? (was Re: more on sniffing) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 09:13:06 -0000 On 08/01/12 23:08, Bjoern Hoehrmann wrote: > In computer science heuristics are problem-solving techniques that pro- > vide good but not neccesarily correct solutions; they are employed as a > trade-off between correctness and other desirable properties. (Slightly off-topic) I rather like this definition: http://lwn.net/Articles/461584/ (quote 2) Gerv From sm@resistor.net Mon Jan 9 02:07:07 2012 Return-Path: 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 5AFAE21F86E0 for ; Mon, 9 Jan 2012 02:07:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 uZ-OFrV-bF6f for ; Mon, 9 Jan 2012 02:07:06 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 64CCB21F86DE for ; Mon, 9 Jan 2012 02:07:06 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q09A70OJ010592 for ; Mon, 9 Jan 2012 02:07:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1326103624; i=@resistor.net; bh=hDdn9X8dukegG4rgClffCrsfzWun0q53eJEHivyF0fA=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=ePhcrtvqSWrq6lWHLmBsUNslk7WQDedzuvXBGo+8v+2Uc4CBssFDA6tlF+QjXK2uQ CdVGXnbp+JFxcUTONYlBAKL+6SrTvUh5m2OT0xgauEyRFaQnUyzqHWBruJCA3n1Zmh dRvrKQ24uxFGP5jZYPKnvOe8c84DlH0f45S5yDko= Message-Id: <6.2.5.6.2.20120109014331.0a139690@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 09 Jan 2012 02:02:13 -0800 To: websec@ietf.org From: SM In-Reply-To: <4F0AAF9D.2080006@mozilla.org> References: <4F0AAF9D.2080006@mozilla.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [websec] Is sniffing a heuristic? (was Re: more on sniffing) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 10:07:07 -0000 At 01:13 09-01-2012, Gervase Markham wrote: >(Slightly off-topic) I rather like this definition: >http://lwn.net/Articles/461584/ >(quote 2) "No matter if it is a white cat or a black cat; as long as it can catch mice, it is a good cat." The question is whether the focus should be about catching the mice or determining whether the cat should be white or black. From RFC 4960: "Since there is no explicit identifier that can be used to detect out-of-order SACKs, the data sender must use heuristics to determine if a SACK is new." I'd say that sniffing is a heuristic. Regards, -sm From masinter@adobe.com Wed Jan 11 10:36:57 2012 Return-Path: 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 8E1D011E80AA for ; Wed, 11 Jan 2012 10:36:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.599 X-Spam-Level: X-Spam-Status: No, score=-107.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, 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 uy0KFLj2bjpj for ; Wed, 11 Jan 2012 10:36:56 -0800 (PST) Received: from exprod6ob111.obsmtp.com (exprod6ob111.obsmtp.com [64.18.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id B45E521F8747 for ; Wed, 11 Jan 2012 10:36:56 -0800 (PST) Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob111.postini.com ([64.18.5.12]) with SMTP ID DSNKTw3WuRmxjcNq3ljSX3MvOmo9nIQQKejL@postini.com; Wed, 11 Jan 2012 10:36:56 PST Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id q0BIYoaa029442 for ; Wed, 11 Jan 2012 10:34:51 -0800 (PST) Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id q0BIadL7003411 for ; Wed, 11 Jan 2012 10:36:40 -0800 (PST) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nahub01.corp.adobe.com ([10.8.189.97]) with mapi; Wed, 11 Jan 2012 10:36:39 -0800 From: Larry Masinter To: "websec@ietf.org" Date: Wed, 11 Jan 2012 10:36:37 -0800 Thread-Topic: scope of mimesniff: roles vs. contexts vs. delivery channels Thread-Index: AczQj/N+gIPylIvgSWKoZYFqd9Dq2Q== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [websec] scope of mimesniff: roles vs. contexts vs. delivery channels X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 18:36:57 -0000 Going back to the "scope" question, should the mimesniff document cover sni= ffing in contexts other than browsers, e.g., by web servers during file upl= oad, by proxies or firewalls or gateways, by spiders or search engines, etc= .? Within the browser context, does it cover sniffing in special applications = like font, video, style sheet, script contexts, where more is known about t= he type that is wanted? The dimension of 'roles' is somewhat orthogonal to the dimension we were ta= lking about previously (whether the specification should cover sniffing of = content delivered by means other than HTTP. It seemed that the sentiment previously was to cover a broad scope of deliv= ery channels: sniffing should cover the broad scope of sniffing of content = delivered by FTP or through (mounted) file system access, etc., and that th= e intent was also to cover a broad scope of contexts (including font, video= , style sheet, etc.). =20 But what about the other roles? I think we could address them at least to s= ome degree, if only to lay out what the constraints are, or what, say, a fi= rewall should do (scanning content in a firewall should likely scan the dat= a as it might appear in the likely formats that any recipient might interpr= et the data, for example.) Larry -- http://larry.masinter.net From derhoermi@gmx.net Wed Jan 11 13:29:34 2012 Return-Path: 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 7049411E80BB for ; Wed, 11 Jan 2012 13:29:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 ToFJOIeIL2ps for ; Wed, 11 Jan 2012 13:29:33 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 56E4B11E8074 for ; Wed, 11 Jan 2012 13:29:33 -0800 (PST) Received: (qmail invoked by alias); 11 Jan 2012 21:29:31 -0000 Received: from dslb-094-222-134-172.pools.arcor-ip.net (EHLO HIVE) [94.222.134.172] by mail.gmx.net (mp026) with SMTP; 11 Jan 2012 22:29:31 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX18n57V1lvAn8wF3Gfg57TlgYrN5v8kL13Mk48o992 Z3Nctscc2lIefq From: Bjoern Hoehrmann To: Larry Masinter Date: Wed, 11 Jan 2012 22:29:36 +0100 Message-ID: References: In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: "websec@ietf.org" Subject: Re: [websec] scope of mimesniff: roles vs. contexts vs. delivery channels X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 21:29:34 -0000 * Larry Masinter wrote: >Going back to the "scope" question, should the mimesniff document cover >sniffing in contexts other than browsers, e.g., by web servers during >file upload, by proxies or firewalls or gateways, by spiders or search >engines, etc.? I note that the current draft does not seem to address web browser up- loads (if a browser uploads a GIF as image/jpeg, and the server echoes data and label back verbatim, and then the browser treats that as a GIF even though it just said it's a JPEG, that would seem to be bad), but more generally I would rather have a "web browser only" specification soon and then talk about what other components might be relevant and how to address those, than try and address all of it at once. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From tobias.gondrom@gondrom.org Wed Jan 11 20:11:54 2012 Return-Path: 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 2F3AA21F8510 for ; Wed, 11 Jan 2012 20:11:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.573 X-Spam-Level: X-Spam-Status: No, score=-96.573 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 edOz6qzXQMrj for ; Wed, 11 Jan 2012 20:11:53 -0800 (PST) Received: from lvps83-169-7-107.dedicated.hosteurope.de (www.gondrom.org [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5D421F84F6 for ; Wed, 11 Jan 2012 20:11:52 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=KcE5qCIV3RyJSLwCtXv+V5l274exVwlRjXgQBKnxffSjvUVwzfE0VqZ+izMJ/gZ6R2XFFFAjoqk7P0q89fKnNqtsQNy/y6EZRuekbBnAEBwgibEtOOAWg7MmntD+1s/O; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:X-Priority:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 5992 invoked from network); 12 Jan 2012 05:11:35 +0100 Received: from unknown (HELO ?10.5.8.84?) (61.8.220.69) by www.gondrom.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 12 Jan 2012 05:11:35 +0100 Message-ID: <4F0E5D73.3030904@gondrom.org> Date: Thu, 12 Jan 2012 12:11:31 +0800 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: websec@ietf.org X-Priority: 4 (Low) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [websec] scope of mimesniff: roles vs. contexts vs. delivery channels X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 04:11:54 -0000 Personally I believe we should include in the scope the possibility of other sniffing contexts (web servers, uploads, filesystem, ....) and actually would feel that this should not add a significant burden on the document. However, if it does add a significant burden/delay on the document I would agree with Bjoern, that rather have a web browser document now than getting stuck discussing the other scenarios. So give it a shot, but if you see too much controversy, reduce the scope. (Thinking about human behaviour: In the end I believe even if we go only with web browser context, if other channels sniff, they will most certainly copy the web browser behaviour anyway - no matter what we say in the RFC.) Best regards, Tobias On 12/01/12 02:36, Larry Masinter wrote: > Going back to the "scope" question, should the mimesniff document cover sniffing in contexts other than browsers, e.g., by web servers during file upload, by proxies or firewalls or gateways, by spiders or search engines, etc.? > > Within the browser context, does it cover sniffing in special applications like font, video, style sheet, script contexts, where more is known about the type that is wanted? > > The dimension of 'roles' is somewhat orthogonal to the dimension we were talking about previously (whether the specification should cover sniffing of content delivered by means other than HTTP. > > It seemed that the sentiment previously was to cover a broad scope of delivery channels: sniffing should cover the broad scope of sniffing of content delivered by FTP or through (mounted) file system access, etc., and that the intent was also to cover a broad scope of contexts (including font, video, style sheet, etc.). > > But what about the other roles? I think we could address them at least to some degree, if only to lay out what the constraints are, or what, say, a firewall should do (scanning content in a firewall should likely scan the data as it might appear in the likely formats that any recipient might interpret the data, for example.) > > Larry > -- > http://larry.masinter.net > > > > > > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From Jeff.Hodges@KingsMountain.com Fri Jan 13 16:24:07 2012 Return-Path: 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 C6A4D1F0C46 for ; Fri, 13 Jan 2012 16:24:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.815 X-Spam-Level: X-Spam-Status: No, score=-99.815 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_41=0.6, RDNS_NONE=0.1, 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 a67Sv-t58ycV for ; Fri, 13 Jan 2012 16:24:07 -0800 (PST) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id E69301F0C48 for ; Fri, 13 Jan 2012 16:24:06 -0800 (PST) Received: (qmail 29180 invoked by uid 0); 14 Jan 2012 00:24:06 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy9.bluehost.com with SMTP; 14 Jan 2012 00:24:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=/WgwH9ie7u0xEnp3gO23MjuZ0wnSQnFk/OAOIYxuXNU=; b=qVdGoHmoVD1FI/YbTR9wX8dlLyv5ytyuUYJpXdv3yExbSKX/qW6W9OjrFOe4tXpCt+TqiboH6WZapBsgQzoEiKSAPprgDGIAlwqLiVRAW1BBxIwVpvdju7u5cp7cox83; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.137.162]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1RlrPi-0008RW-87 for websec@ietf.org; Fri, 13 Jan 2012 17:24:06 -0700 Message-ID: <4F10CB26.2000206@KingsMountain.com> Date: Fri, 13 Jan 2012 16:24:06 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: IETF WebSec WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: [websec] of quoted-string header field param value syntax (was: Strict-Transport-Security syntax redux) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2012 00:24:07 -0000 In terms of this question of whether the STS header field directive ABNF should be.. 1) directive = token [ "=" ( token | quoted-string ) ] ..or.. 2) directive = token [ "=" token ] ..I can see both sides of the argument. However, I've been thinking about it and grepping thru specs as well as firefox and chrome code, which has led me to think that from an overall (specification) consistency perspective, I'm leaning towards spec'g it with quoted-string in the ABNF (ie, as (1)). And has been pointed out in the discussion, it is sort of a moot point because the STS header field does not at this time make use of the quoted-string production, nor do we have on the table any extension directives that would do so. In going through the FF and Chrome code, I note that both of their STS header field parsing methods appear to be special-case and AFAICT don't make use of other, more general HTTP header field parsing routines that are available in both implementations, and that are used to parse other HTTP response header fields. These latter more general HTTP header field parsing routines appear to be used for processing various of the other HTTP response and request header fields (and they appear to handle quoted-string). But it isn't clear why they aren't used for STS. It also isn't clear how uniformly these parsing routines are used for the panoply of HTTP header fields -- some other header fields appear to be special-cased as well (tho my c++ foo is wanting and the code is vast..). So yeah, it does seem messy. =JeffH From julian.reschke@gmx.de Sat Jan 14 04:20:31 2012 Return-Path: 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 B6FB621F8600 for ; Sat, 14 Jan 2012 04:20:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.056 X-Spam-Level: X-Spam-Status: No, score=-103.056 tagged_above=-999 required=5 tests=[AWL=-1.057, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, 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 idhpkhReA0KT for ; Sat, 14 Jan 2012 04:20:31 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id D772221F85FD for ; Sat, 14 Jan 2012 04:20:30 -0800 (PST) Received: (qmail invoked by alias); 14 Jan 2012 12:20:29 -0000 Received: from p3EE27592.dip.t-dialin.net (EHLO [192.168.178.36]) [62.226.117.146] by mail.gmx.net (mp026) with SMTP; 14 Jan 2012 13:20:29 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18x0KVIEAwxDOKIGA9KXYOJIV9AtZPg7QDlPaMR8b P4Y5nhBZ5xB8fZ Message-ID: <4F117308.3030501@gmx.de> Date: Sat, 14 Jan 2012 13:20:24 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: =JeffH References: <4F10CB26.2000206@KingsMountain.com> In-Reply-To: <4F10CB26.2000206@KingsMountain.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: IETF WebSec WG Subject: Re: [websec] of quoted-string header field param value syntax (was: Strict-Transport-Security syntax redux) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2012 12:20:31 -0000 On 2012-01-14 01:24, =JeffH wrote: > > In terms of this question of whether the STS header field directive ABNF > should be.. > > 1) directive = token [ "=" ( token | quoted-string ) ] > > ..or.. > > 2) directive = token [ "=" token ] > > ..I can see both sides of the argument. > > However, I've been thinking about it and grepping thru specs as well as > firefox and chrome code, which has led me to think that from an overall > (specification) consistency perspective, I'm leaning towards spec'g it > with quoted-string in the ABNF (ie, as (1)). And has been pointed out in +1 > the discussion, it is sort of a moot point because the STS header field > does not at this time make use of the quoted-string production, nor do > we have on the table any extension directives that would do so. It's not a moot point at all. If you don't spec it now, extensions will not ever be able to use quoted-string, because recipients parsing over those extensions will trip over them. > In going through the FF and Chrome code, I note that both of their STS > header field parsing methods appear to be special-case and AFAICT don't > make use of other, more general HTTP header field parsing routines that > are available in both implementations, and that are used to parse other > HTTP response header fields. These latter more general HTTP header field > parsing routines appear to be used for processing various of the other > HTTP response and request header fields (and they appear to handle > quoted-string). But it isn't clear why they aren't used for STS. It also > isn't clear how uniformly these parsing routines are used for the > panoply of HTTP header fields -- some other header fields appear to be > special-cased as well (tho my c++ foo is wanting and the code is > vast..). So yeah, it does seem messy. It's true what right now there isn't a lot of re-use of header field parsers. This is likely because of historic reasons; different header fields have different parsing quirks. But of course that's not an excuse to add unneeded special cases in the future. Example: just a few weeks ago we discussed the "Prefer" header field in the HTTPbis WG, and we have been able to make it parse exactly like "Expect" (after fixing "Expect" as well, see ). Best regards, Julian From trac+websec@trac.tools.ietf.org Sat Jan 14 18:52:51 2012 Return-Path: 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 87C1621F84AF for ; Sat, 14 Jan 2012 18:52:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 RMC8fDyJsBFa for ; Sat, 14 Jan 2012 18:52:50 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id A9B2C21F84AA for ; Sat, 14 Jan 2012 18:52:50 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RmGCh-0000qO-W8; Sat, 14 Jan 2012 21:52:20 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "websec issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com X-Trac-Project: websec Date: Sun, 15 Jan 2012 02:52:19 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/34 Message-ID: <070.daef625ac2bff2b5e11ec0521f0bc368@trac.tools.ietf.org> X-Trac-Ticket-ID: 34 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com, websec@ietf.org X-SA-Exim-Mail-From: trac+websec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120115025250.A9B2C21F84AA@ietfa.amsl.com> Resent-Date: Sat, 14 Jan 2012 18:52:50 -0800 (PST) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: [websec] #34: HSTS cache manipulation and misuse by server enabled by wildcard cert X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2012 02:52:51 -0000 #34: HSTS cache manipulation and misuse by server enabled by wildcard cert See.. The Double-Edged Sword of HSTS Persistence and Privacy -- by Mikhail Davidov http://haxsys.net/2011/04/the-double-edged-sword-of-hsts-persistence-and- privacy/ summary: This technique allows a web app on one domain to surreptitiously send a message to another web app on another domain via manipulation of the HSTS cache... If server wields a wildcard cert, eg for "*.example.com", then example.com can create any number of subdomains of example.com, with any subdomain name, and then direct user agents to fetch resources from these subdomains. If HSTS Policy is returned for each of these subdomains, and includeSubDomains is not used, then any number of entries will be created in in the user agent's HSTS store. E.g., an web page like the below would accomplish this.. [img]https://charcount-5.example.com/setbit.png[/img] -- this stores the char count of the msg [img]https://0-H.example.com/setbit.png[/img] [img]https://1-E.example.com/setbit.png[/img] [img]https://2-L.example.com/setbit.png[/img] [img]https://3-L.example.com/setbit.png[/img] [img]https://4-O.example.com/setbit.png[/img] These entries can be read back by some other web application under some other domain name by causing the user agent to send HTTP requests to example.com in order to brute-force the character count subdomain name -- the server responds whether the name is available over just http -- which means it is a miss, or over HTTPS, which is a hit.. http://charcount-1.trackingexampledomain.com/getbit.png [ Server: HTTP ] http://charcount-2.trackingexampledomain.com/getbit.png [ Server: HTTP ] http://charcount-3.trackingexampledomain.com/getbit.png [ Server: HTTP ] http://charcount-4.trackingexampledomain.com/getbit.png [ Server: HTTP ] http://charcount-5.trackingexampledomain.com/getbit.png [ Server: HTTPS! ] -- msg char count is 5 Then the web app can brute force each character of the message in a similar fashion. the original message-sending domain web app can clear the cached message by causing the user agent to re-request resources from the same dubdomains and returning a HSTS header for each with max-age=0. For a resolution, Mikhail suggests.. "My proposal is to amend the draft to force the includeSubDomains flag on wildcard certificates. This would limit them to only one entry in the browsers HSTS database and make the technique above prohibitively expensive to non-CA owners as a separate signed SSL certificate would be needed for every bit of information stored and limit encoding options." -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-websec-strict-transport- jeff.hodges@… | sec@… Type: defect | Status: new Priority: major | Milestone: Component: strict- | Version: transport-sec | Keywords: Severity: Active WG | Document | -------------------------+------------------------------------------------- Ticket URL: websec From ynir@checkpoint.com Sat Jan 14 23:13:44 2012 Return-Path: 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 556E821F847F for ; Sat, 14 Jan 2012 23:13:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.461 X-Spam-Level: X-Spam-Status: No, score=-10.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 OB6JejiThNq3 for ; Sat, 14 Jan 2012 23:13:43 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id BF5A121F847C for ; Sat, 14 Jan 2012 23:13:42 -0800 (PST) X-CheckPoint: {4F1279FF-0-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q0F7DePc002090 for ; Sun, 15 Jan 2012 09:13:40 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 15 Jan 2012 09:13:40 +0200 From: Yoav Nir To: IETF WebSec WG Date: Sun, 15 Jan 2012 09:13:23 +0200 Thread-Topic: [websec] #34: HSTS cache manipulation and misuse by server enabled by wildcard cert Thread-Index: AczTVTUfiP0VnLRwRq+hT01unfbUEw== Message-ID: <124D1609-2615-48DC-B130-31C644BA9F74@checkpoint.com> References: <070.daef625ac2bff2b5e11ec0521f0bc368@trac.tools.ietf.org> In-Reply-To: <070.daef625ac2bff2b5e11ec0521f0bc368@trac.tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [websec] #34: HSTS cache manipulation and misuse by server enabled by wildcard cert X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2012 07:13:44 -0000 SW50ZXJlc3RpbmcuIA0KDQpCdXQgSSBkb24ndCBzZWUgaG93IHN1YmRvbWFpbnMgaGVscC4gSWYg SSBoYXZlIGEgd2Vic2l0ZSBjYWxsZWQgY2hhcmNvdW50LTUuZXhhbXBsZS5jb20sIGFuZCBJIHVz ZSBhIHdpbGRjYXJkICouZXhhbXBsZS5jb20gY2VydGlmaWNhdGUsIHRoZSBIU1RTIGVudHJ5IGlz IHN0aWxsIHdyaXR0ZW4gZm9yIGNoYXJjb3VudC01LmV4YW1wbGUuY29tLiBBZGRpbmcgc3ViZG9t YWlucyB3b3VsZCBhZmZlY3QgKi5jaGFyY291bnQtNS5leGFtcGxlLmNvbSwgbm90IDAtSC5leGFt cGxlLmNvbS4NCg0KSSB3b3VsZG4ndCB3YW50IHRvIGZvcmNlIHRoZSBpbmNsdWRlU3ViZG9tYWlu cywgYXMgdGhlcmUgbWF5IGJlIHZhbGlkIHJlYXNvbnMgdG8gaGF2ZSBhIHN1YmRvbWFpbiBvZiBl eGFtcGxlLmNvbSB0aGF0IGlzIEhUVFAsIHdoZXJlYXMgdGhlIGRlY2lzaW9uIG9uIGJ1eWluZyBh IHdpbGRjYXJkIGNlcnRpZmljYXRlIGlzIGEgbWF0dGVyIG9mIGNvc3QgYW5kIGNvbnZlbmllbmNl Lg0KDQpZb2F2DQoNCk9uIEphbiAxNSwgMjAxMiwgYXQgNDo1MiBBTSwgd2Vic2VjIGlzc3VlIHRy YWNrZXIgd3JvdGU6DQoNCj4gIzM0OiBIU1RTIGNhY2hlIG1hbmlwdWxhdGlvbiBhbmQgbWlzdXNl IGJ5IHNlcnZlciBlbmFibGVkIGJ5IHdpbGRjYXJkIGNlcnQNCj4gDQo+IFNlZS4uDQo+IA0KPiBU aGUgRG91YmxlLUVkZ2VkIFN3b3JkIG9mIEhTVFMgUGVyc2lzdGVuY2UgYW5kIFByaXZhY3kgLS0g IGJ5IE1pa2hhaWwNCj4gRGF2aWRvdg0KPiBodHRwOi8vaGF4c3lzLm5ldC8yMDExLzA0L3RoZS1k b3VibGUtZWRnZWQtc3dvcmQtb2YtaHN0cy1wZXJzaXN0ZW5jZS1hbmQtDQo+IHByaXZhY3kvDQo+ IA0KPiBzdW1tYXJ5Og0KPiANCj4gVGhpcyB0ZWNobmlxdWUgYWxsb3dzIGEgd2ViIGFwcCBvbiBv bmUgZG9tYWluIHRvIHN1cnJlcHRpdGlvdXNseSBzZW5kIGENCj4gbWVzc2FnZSB0byBhbm90aGVy IHdlYiBhcHAgb24gYW5vdGhlciBkb21haW4gdmlhIG1hbmlwdWxhdGlvbiBvZiB0aGUgSFNUUw0K PiBjYWNoZS4uLg0KPiANCj4gSWYgc2VydmVyIHdpZWxkcyBhIHdpbGRjYXJkIGNlcnQsIGVnIGZv ciAiKi5leGFtcGxlLmNvbSIsIHRoZW4gZXhhbXBsZS5jb20NCj4gY2FuIGNyZWF0ZSBhbnkgbnVt YmVyIG9mIHN1YmRvbWFpbnMgb2YgZXhhbXBsZS5jb20sIHdpdGggYW55IHN1YmRvbWFpbg0KPiBu YW1lLCBhbmQgdGhlbiBkaXJlY3QgdXNlciBhZ2VudHMgdG8gZmV0Y2ggcmVzb3VyY2VzIGZyb20g dGhlc2UNCj4gc3ViZG9tYWlucy4gSWYgSFNUUyBQb2xpY3kgaXMgcmV0dXJuZWQgZm9yIGVhY2gg b2YgdGhlc2Ugc3ViZG9tYWlucywgYW5kDQo+IGluY2x1ZGVTdWJEb21haW5zIGlzIG5vdCB1c2Vk LCB0aGVuIGFueSBudW1iZXIgb2YgZW50cmllcyB3aWxsIGJlIGNyZWF0ZWQNCj4gaW4gaW4gdGhl IHVzZXIgYWdlbnQncyBIU1RTIHN0b3JlLiBFLmcuLCBhbiB3ZWIgcGFnZSBsaWtlIHRoZSBiZWxv dyB3b3VsZA0KPiBhY2NvbXBsaXNoIHRoaXMuLg0KPiANCj4gICBbaW1nXWh0dHBzOi8vY2hhcmNv dW50LTUuZXhhbXBsZS5jb20vc2V0Yml0LnBuZ1svaW1nXSAgICAgIC0tIHRoaXMNCj4gc3RvcmVz IHRoZSBjaGFyIGNvdW50IG9mIHRoZSBtc2cNCj4gDQo+ICAgW2ltZ11odHRwczovLzAtSC5leGFt cGxlLmNvbS9zZXRiaXQucG5nWy9pbWddDQo+ICAgW2ltZ11odHRwczovLzEtRS5leGFtcGxlLmNv bS9zZXRiaXQucG5nWy9pbWddDQo+ICAgW2ltZ11odHRwczovLzItTC5leGFtcGxlLmNvbS9zZXRi aXQucG5nWy9pbWddDQo+ICAgW2ltZ11odHRwczovLzMtTC5leGFtcGxlLmNvbS9zZXRiaXQucG5n Wy9pbWddDQo+ICAgW2ltZ11odHRwczovLzQtTy5leGFtcGxlLmNvbS9zZXRiaXQucG5nWy9pbWdd DQo+IA0KPiANCj4gVGhlc2UgZW50cmllcyBjYW4gYmUgcmVhZCBiYWNrIGJ5IHNvbWUgb3RoZXIg d2ViIGFwcGxpY2F0aW9uIHVuZGVyIHNvbWUNCj4gb3RoZXIgZG9tYWluIG5hbWUgYnkgY2F1c2lu ZyB0aGUgdXNlciBhZ2VudCB0byBzZW5kIEhUVFAgcmVxdWVzdHMgdG8NCj4gZXhhbXBsZS5jb20g aW4gb3JkZXIgdG8gYnJ1dGUtZm9yY2UgdGhlIGNoYXJhY3RlciBjb3VudCBzdWJkb21haW4gbmFt ZSAtLQ0KPiB0aGUgc2VydmVyIHJlc3BvbmRzIHdoZXRoZXIgdGhlIG5hbWUgaXMgYXZhaWxhYmxl IG92ZXIganVzdCBodHRwIC0tIHdoaWNoDQo+IG1lYW5zIGl0IGlzIGEgbWlzcywgb3Igb3ZlciBI VFRQUywgd2hpY2ggaXMgYSBoaXQuLg0KPiANCj4gICBodHRwOi8vY2hhcmNvdW50LTEudHJhY2tp bmdleGFtcGxlZG9tYWluLmNvbS9nZXRiaXQucG5nIFsgU2VydmVyOiBIVFRQIF0NCj4gICBodHRw Oi8vY2hhcmNvdW50LTIudHJhY2tpbmdleGFtcGxlZG9tYWluLmNvbS9nZXRiaXQucG5nIFsgU2Vy dmVyOiBIVFRQIF0NCj4gICBodHRwOi8vY2hhcmNvdW50LTMudHJhY2tpbmdleGFtcGxlZG9tYWlu LmNvbS9nZXRiaXQucG5nIFsgU2VydmVyOiBIVFRQIF0NCj4gICBodHRwOi8vY2hhcmNvdW50LTQu dHJhY2tpbmdleGFtcGxlZG9tYWluLmNvbS9nZXRiaXQucG5nIFsgU2VydmVyOiBIVFRQIF0NCj4g ICBodHRwOi8vY2hhcmNvdW50LTUudHJhY2tpbmdleGFtcGxlZG9tYWluLmNvbS9nZXRiaXQucG5n IFsgU2VydmVyOiBIVFRQUyENCj4gXSAgIC0tIG1zZyBjaGFyIGNvdW50IGlzIDUNCj4gDQo+IFRo ZW4gdGhlIHdlYiBhcHAgY2FuIGJydXRlIGZvcmNlIGVhY2ggY2hhcmFjdGVyIG9mIHRoZSBtZXNz YWdlIGluIGENCj4gc2ltaWxhciBmYXNoaW9uLg0KPiANCj4gdGhlIG9yaWdpbmFsIG1lc3NhZ2Ut c2VuZGluZyBkb21haW4gd2ViIGFwcCBjYW4gY2xlYXIgdGhlIGNhY2hlZCBtZXNzYWdlDQo+IGJ5 IGNhdXNpbmcgdGhlIHVzZXIgYWdlbnQgdG8gcmUtcmVxdWVzdCByZXNvdXJjZXMgZnJvbSB0aGUg c2FtZSBkdWJkb21haW5zDQo+IGFuZCByZXR1cm5pbmcgYSBIU1RTIGhlYWRlciBmb3IgZWFjaCB3 aXRoIG1heC1hZ2U9MC4NCj4gDQo+IEZvciBhIHJlc29sdXRpb24sIE1pa2hhaWwgc3VnZ2VzdHMu Lg0KPiANCj4gIk15IHByb3Bvc2FsIGlzIHRvIGFtZW5kIHRoZSBkcmFmdCB0byBmb3JjZSB0aGUg aW5jbHVkZVN1YkRvbWFpbnMgZmxhZyBvbg0KPiB3aWxkY2FyZCBjZXJ0aWZpY2F0ZXMuIFRoaXMg d291bGQgbGltaXQgdGhlbSB0byBvbmx5IG9uZSBlbnRyeSBpbiB0aGUNCj4gYnJvd3NlcnMgSFNU UyBkYXRhYmFzZSBhbmQgbWFrZSB0aGUgdGVjaG5pcXVlIGFib3ZlIHByb2hpYml0aXZlbHkNCj4g ZXhwZW5zaXZlIHRvIG5vbi1DQSBvd25lcnMgYXMgYSBzZXBhcmF0ZSBzaWduZWQgU1NMIGNlcnRp ZmljYXRlIHdvdWxkIGJlDQo+IG5lZWRlZCBmb3IgZXZlcnkgYml0IG9mIGluZm9ybWF0aW9uIHN0 b3JlZCBhbmQgbGltaXQgZW5jb2Rpbmcgb3B0aW9ucy4iDQo+IA0KPiAtLSANCj4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+IFJlcG9ydGVyOiAgICAgICAgICAgICAgIHwgICAgICBPd25lcjogIGRyYWZ0 LWlldGYtd2Vic2VjLXN0cmljdC10cmFuc3BvcnQtDQo+ICBqZWZmLmhvZGdlc0DigKYgICAgICAg ICAgfCAgc2VjQOKApg0KPiAgICAgVHlwZTogIGRlZmVjdCAgICAgICB8ICAgICBTdGF0dXM6ICBu ZXcNCj4gUHJpb3JpdHk6ICBtYWpvciAgICAgICAgfCAgTWlsZXN0b25lOg0KPiBDb21wb25lbnQ6 ICBzdHJpY3QtICAgICAgfCAgICBWZXJzaW9uOg0KPiAgdHJhbnNwb3J0LXNlYyAgICAgICAgICB8 ICAgS2V5d29yZHM6DQo+IFNldmVyaXR5OiAgQWN0aXZlIFdHICAgIHwNCj4gIERvY3VtZW50ICAg ICAgICAgICAgICAgfA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IFRpY2tldCBVUkw6IDxo dHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy93ZWJzZWMvdHJhYy90aWNrZXQvMzQ+DQo+IHdl YnNlYyA8aHR0cDovL3Rvb2xzLmlldGYub3JnL3dlYnNlYy8+DQo+IA0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiB3ZWJzZWMgbWFpbGluZyBsaXN0 DQo+IHdlYnNlY0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3dlYnNlYw0KPiBJxqfvv73vv71b77+9KF5yQ++/vXtT77+91qVJ77+9Lu+/vStyGe+/vV7v v73vv70NCg0K From ietf@adambarth.com Sat Jan 14 23:52:14 2012 Return-Path: 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 F2E5121F8468 for ; Sat, 14 Jan 2012 23:52:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.732 X-Spam-Level: X-Spam-Status: No, score=-2.732 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-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 K+CIHo0lzJrr for ; Sat, 14 Jan 2012 23:52:12 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4F51A21F8464 for ; Sat, 14 Jan 2012 23:52:12 -0800 (PST) Received: by iaae16 with SMTP id e16so7330027iaa.31 for ; Sat, 14 Jan 2012 23:52:12 -0800 (PST) Received: by 10.50.77.226 with SMTP id v2mr5065212igw.12.1326613931828; Sat, 14 Jan 2012 23:52:11 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id or2sm13748301igc.5.2012.01.14.23.52.10 (version=SSLv3 cipher=OTHER); Sat, 14 Jan 2012 23:52:10 -0800 (PST) Received: by iaae16 with SMTP id e16so7329985iaa.31 for ; Sat, 14 Jan 2012 23:52:10 -0800 (PST) Received: by 10.50.160.131 with SMTP id xk3mr3231935igb.19.1326613930155; Sat, 14 Jan 2012 23:52:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.62.139 with HTTP; Sat, 14 Jan 2012 23:51:39 -0800 (PST) In-Reply-To: <070.daef625ac2bff2b5e11ec0521f0bc368@trac.tools.ietf.org> References: <070.daef625ac2bff2b5e11ec0521f0bc368@trac.tools.ietf.org> From: Adam Barth Date: Sat, 14 Jan 2012 23:51:39 -0800 Message-ID: To: websec issue tracker Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: websec@ietf.org, draft-ietf-websec-strict-transport-sec@tools.ietf.org Subject: Re: [websec] #34: HSTS cache manipulation and misuse by server enabled by wildcard cert X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2012 07:52:14 -0000 Why not just postMessage of the HTML
element? If you want be more sneaky about it, you can just the HTTP cache. Anyway, web sites are allowed to send messages to each other. Adam On Sat, Jan 14, 2012 at 6:52 PM, websec issue tracker wrote: > #34: HSTS cache manipulation and misuse by server enabled by wildcard cer= t > > =A0See.. > > =A0The Double-Edged Sword of HSTS Persistence and Privacy -- =A0by Mikhai= l > =A0Davidov > =A0http://haxsys.net/2011/04/the-double-edged-sword-of-hsts-persistence-a= nd- > =A0privacy/ > > =A0summary: > > =A0This technique allows a web app on one domain to surreptitiously send = a > =A0message to another web app on another domain via manipulation of the H= STS > =A0cache... > > =A0If server wields a wildcard cert, eg for "*.example.com", then example= .com > =A0can create any number of subdomains of example.com, with any subdomain > =A0name, and then direct user agents to fetch resources from these > =A0subdomains. If HSTS Policy is returned for each of these subdomains, a= nd > =A0includeSubDomains is not used, then any number of entries will be crea= ted > =A0in in the user agent's HSTS store. E.g., an web page like the below wo= uld > =A0accomplish this.. > > =A0 [img]https://charcount-5.example.com/setbit.png[/img] =A0 =A0 =A0-- t= his > =A0stores the char count of the msg > > =A0 [img]https://0-H.example.com/setbit.png[/img] > =A0 [img]https://1-E.example.com/setbit.png[/img] > =A0 [img]https://2-L.example.com/setbit.png[/img] > =A0 [img]https://3-L.example.com/setbit.png[/img] > =A0 [img]https://4-O.example.com/setbit.png[/img] > > > =A0These entries can be read back by some other web application under som= e > =A0other domain name by causing the user agent to send HTTP requests to > =A0example.com in order to brute-force the character count subdomain name= -- > =A0the server responds whether the name is available over just http -- wh= ich > =A0means it is a miss, or over HTTPS, which is a hit.. > > =A0 http://charcount-1.trackingexampledomain.com/getbit.png [ Server: HTT= P ] > =A0 http://charcount-2.trackingexampledomain.com/getbit.png [ Server: HTT= P ] > =A0 http://charcount-3.trackingexampledomain.com/getbit.png [ Server: HTT= P ] > =A0 http://charcount-4.trackingexampledomain.com/getbit.png [ Server: HTT= P ] > =A0 http://charcount-5.trackingexampledomain.com/getbit.png [ Server: HTT= PS! > =A0] =A0 -- msg char count is 5 > > =A0Then the web app can brute force each character of the message in a > =A0similar fashion. > > =A0the original message-sending domain web app can clear the cached messa= ge > =A0by causing the user agent to re-request resources from the same dubdom= ains > =A0and returning a HSTS header for each with max-age=3D0. > > =A0For a resolution, Mikhail suggests.. > > =A0"My proposal is to amend the draft to force the includeSubDomains flag= on > =A0wildcard certificates. This would limit them to only one entry in the > =A0browsers HSTS database and make the technique above prohibitively > =A0expensive to non-CA owners as a separate signed SSL certificate would = be > =A0needed for every bit of information stored and limit encoding options.= " > > -- > -------------------------+-----------------------------------------------= -- > =A0Reporter: =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0Owner: =A0draft-iet= f-websec-strict-transport- > =A0jeff.hodges@=85 =A0 =A0 =A0 =A0 =A0| =A0sec@=85 > =A0 =A0 Type: =A0defect =A0 =A0 =A0 | =A0 =A0 Status: =A0new > =A0Priority: =A0major =A0 =A0 =A0 =A0| =A0Milestone: > Component: =A0strict- =A0 =A0 =A0| =A0 =A0Version: > =A0transport-sec =A0 =A0 =A0 =A0 =A0| =A0 Keywords: > =A0Severity: =A0Active WG =A0 =A0| > =A0Document =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > -------------------------+-----------------------------------------------= -- > > Ticket URL: > websec > From ietf@adambarth.com Sun Jan 15 11:53:13 2012 Return-Path: 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 5A99921F847C for ; Sun, 15 Jan 2012 11:53:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.747 X-Spam-Level: X-Spam-Status: No, score=-2.747 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-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 Zv47eFwAe62j for ; Sun, 15 Jan 2012 11:53:12 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 954C721F8475 for ; Sun, 15 Jan 2012 11:53:12 -0800 (PST) Received: by iaae16 with SMTP id e16so8038163iaa.31 for ; Sun, 15 Jan 2012 11:53:11 -0800 (PST) Received: by 10.43.53.1 with SMTP id vo1mr9909679icb.2.1326657191130; Sun, 15 Jan 2012 11:53:11 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id xu6sm28800309igb.7.2012.01.15.11.53.09 (version=SSLv3 cipher=OTHER); Sun, 15 Jan 2012 11:53:09 -0800 (PST) Received: by iaae16 with SMTP id e16so8038139iaa.31 for ; Sun, 15 Jan 2012 11:53:09 -0800 (PST) Received: by 10.50.214.38 with SMTP id nx6mr7259333igc.19.1326657189101; Sun, 15 Jan 2012 11:53:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.62.139 with HTTP; Sun, 15 Jan 2012 11:52:38 -0800 (PST) In-Reply-To: <20120115195120.GG32205@1wt.eu> References: <20120115195120.GG32205@1wt.eu> From: Adam Barth Date: Sun, 15 Jan 2012 11:52:38 -0800 Message-ID: To: Willy Tarreau Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: websec@ietf.org, ian@hixie.ch Subject: Re: [websec] Minor feedback on draft-ietf-websec-mime-sniff-03 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2012 19:53:13 -0000 The requirement in the spec is what we intend. The rule applies only to that exact octet sequence. Adam On Sun, Jan 15, 2012 at 11:51 AM, Willy Tarreau wrote: > Hello Adam, Ian, > > Today I came across your draft "draft-ietf-websec-mime-sniff-03", and > noticed the point below : > > =A0 2. =A0If the octets were fetched via HTTP and there is an HTTP Conten= t- > =A0 =A0 =A0 Type header field and the value of the last such header field= has > =A0 =A0 =A0 octets that *exactly* match the octets contained in one of th= e > =A0 =A0 =A0 following lines: > > =A0 =A0 =A0+-------------------------------+-----------------------------= ---+ > =A0 =A0 =A0| Bytes in Hexadecimal =A0 =A0 =A0 =A0 =A0| Textual Representa= tion =A0 =A0 =A0 =A0 | > =A0 =A0 =A0+-------------------------------+-----------------------------= ---+ > =A0 =A0 =A0| 74 65 78 74 2f 70 6c 61 69 6e | text/plain =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 | > =A0 =A0 =A0+-------------------------------+-----------------------------= ---+ > =A0 =A0 =A0| 74 65 78 74 2f 70 6c 61 69 6e | text/plain; charset=3DISO-88= 59-1 | > =A0 =A0 =A0| 3b 20 63 68 61 72 73 65 74 3d | =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| > =A0 =A0 =A0| 49 53 4f 2d 38 38 35 39 2d 31 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| > =A0 =A0 .../... > > I was having a doubt about spaces being optional around the semi-colon, > so I just checked and indeed we have OWS before and after it : > > =A0 http://www.ietf.org/id/draft-ietf-httpbis-p3-payload-18.txt > > =A0 2.3. =A0Media Types > > =A0 HTTP uses Internet Media Types [RFC2046] in the Content-Type > =A0 (Section 6.8) and Accept (Section 6.1) header fields in order to > =A0 provide open and extensible data typing and type negotiation. > > =A0 =A0 media-type =3D type "/" subtype *( OWS ";" OWS parameter ) > =A0 =A0 type =A0 =A0 =A0 =3D token > =A0 =A0 subtype =A0 =A0=3D token > > =A0 The type/subtype MAY be followed by parameters in the form of > =A0 attribute/value pairs. > > =A0 =A0 parameter =A0 =A0 =A0=3D attribute "=3D" value > =A0 =A0 attribute =A0 =A0 =A0=3D token > =A0 =A0 value =A0 =A0 =A0 =A0 =A0=3D word > > Also, it is said here that quotes are allowed around the parameter > value : > > =A0 A parameter value that matches the token production can be > =A0 transmitted as either a token or within a quoted-string. =A0The quote= d > =A0 and unquoted values are equivalent. > > So examples below are completely valid : > > =A0 Content-type: text/plain;charset=3D"ISO-8859-1" > > =A0 Content-type: text/plain =A0 ; =A0charset=3DISO-8859-1 > > =A0 Content-type: text/plain ; > =A0 =A0 =A0 =A0 charset=3D"ISO-8859-1" > > Thus the byte matching can only apply to the tokens and values. I think t= he > safest thing to do would be to refer to the HTTP spec to define the heade= r > format then suggest byte matches for each fields, for instance : > > =A0 =A0 =A0 If the octets were fetched via HTTP and there is an HTTP Cont= ent- > =A0 =A0 =A0 Type header field and the value of the last such header *exac= tly* > =A0 =A0 =A0 matches one of the media-types below, then the sniffed-type i= s > =A0 =A0 =A0 defined as the concatenation of the unquoted matching parts : > > =A0 =A0 =A0 media-type =3D type "/" subtype *( OWS ";" OWS parameter ) > =A0 =A0 =A0 sniffed-type =3D type "/" subtype 1*( "; " attribute "=3D" va= lue ) > > =A0 =A0 =A0 All accepted media-types must *exactly* match : > =A0 =A0 =A0 =A0 =A0- type =A0 =A0=3D "text" (hex 74 65 78 74) > =A0 =A0 =A0 =A0 =A0- subtype =3D "plain" (hex 70 6c 61 69 6e) > > =A0 =A0 =A0 If a parameter is present, its attribute must be "charset" > =A0 =A0 =A0 (hex 63 68 61 72 73 65 74) and the value must be one of : > =A0 =A0 =A0 =A0 =A0- "ISO-8859-1" (hex 49 53 4f 2d 38 38 35 39 2d 31) > =A0 =A0 =A0 =A0 =A0- "iso-8859-1" (hex 69 73 6f 2d 38 38 35 39 2d 31) > =A0 =A0 =A0 =A0 =A0- "UTF-8" =A0 =A0 =A0(hex 55 54 46 2d 38) > > Please also note that HTTP indicates that some attributes accept a > case-insensitive value. I have not yet found in the spec if "charset" > accepts a case-insensitive value, but given that you identified two > possible cases for "iso-8859-1", it is likely that "charset" falls into > this case. > > Best regards, > Willy > From ietf@adambarth.com Sun Jan 15 12:53:40 2012 Return-Path: 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 38B6E21F84EA for ; Sun, 15 Jan 2012 12:53:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.76 X-Spam-Level: X-Spam-Status: No, score=-2.76 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-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 bCd0lwkLln3z for ; Sun, 15 Jan 2012 12:53:39 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id C453A21F84D7 for ; Sun, 15 Jan 2012 12:53:33 -0800 (PST) Received: by iaae16 with SMTP id e16so8101494iaa.31 for ; Sun, 15 Jan 2012 12:53:32 -0800 (PST) Received: by 10.43.133.9 with SMTP id hw9mr9640342icc.34.1326660812272; Sun, 15 Jan 2012 12:53:32 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id yg2sm21332894igb.1.2012.01.15.12.53.31 (version=SSLv3 cipher=OTHER); Sun, 15 Jan 2012 12:53:31 -0800 (PST) Received: by iaae16 with SMTP id e16so8101483iaa.31 for ; Sun, 15 Jan 2012 12:53:31 -0800 (PST) Received: by 10.50.47.229 with SMTP id g5mr10092848ign.23.1326660811169; Sun, 15 Jan 2012 12:53:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.62.139 with HTTP; Sun, 15 Jan 2012 12:53:00 -0800 (PST) In-Reply-To: <20120115204154.GH32205@1wt.eu> References: <20120115195120.GG32205@1wt.eu> <20120115204154.GH32205@1wt.eu> From: Adam Barth Date: Sun, 15 Jan 2012 12:53:00 -0800 Message-ID: To: Willy Tarreau Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: websec@ietf.org, ian@hixie.ch Subject: Re: [websec] Minor feedback on draft-ietf-websec-mime-sniff-03 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2012 20:53:40 -0000 On Sun, Jan 15, 2012 at 12:41 PM, Willy Tarreau wrote: > On Sun, Jan 15, 2012 at 11:52:38AM -0800, Adam Barth wrote: >> The requirement in the spec is what we intend. =A0The rule applies only >> to that exact octet sequence. > > But then what are the impacts of not matching the correct content-type ? I'm not sure I understand your question. Can you explain a scenario in which something happens that causes someone to be sad with the current requirements? Adam From julian.reschke@gmx.de Sun Jan 15 13:01:05 2012 Return-Path: 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 5EEEC21F8474 for ; Sun, 15 Jan 2012 13:01:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.596 X-Spam-Level: X-Spam-Status: No, score=-103.596 tagged_above=-999 required=5 tests=[AWL=-0.997, BAYES_00=-2.599, 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 hWRmEpASIw7p for ; Sun, 15 Jan 2012 13:01:05 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 6CB9621F8464 for ; Sun, 15 Jan 2012 13:01:04 -0800 (PST) Received: (qmail invoked by alias); 15 Jan 2012 21:00:45 -0000 Received: from p3EE26642.dip.t-dialin.net (EHLO [192.168.178.36]) [62.226.102.66] by mail.gmx.net (mp018) with SMTP; 15 Jan 2012 22:00:45 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+MxJ0eQCKMtAIIzafjZAv8BswRYyzyHcnmD+BdVW pOfUKkNVCU5aG4 Message-ID: <4F133E75.2000204@gmx.de> Date: Sun, 15 Jan 2012 22:00:37 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Adam Barth References: <20120115195120.GG32205@1wt.eu> <20120115204154.GH32205@1wt.eu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: ian@hixie.ch, websec@ietf.org, Willy Tarreau Subject: Re: [websec] Minor feedback on draft-ietf-websec-mime-sniff-03 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2012 21:01:05 -0000 On 2012-01-15 21:53, Adam Barth wrote: > On Sun, Jan 15, 2012 at 12:41 PM, Willy Tarreau wrote: >> On Sun, Jan 15, 2012 at 11:52:38AM -0800, Adam Barth wrote: >>> The requirement in the spec is what we intend. The rule applies only >>> to that exact octet sequence. >> >> But then what are the impacts of not matching the correct content-type ? > > I'm not sure I understand your question. Can you explain a scenario > in which something happens that causes someone to be sad with the > current requirements? > > Adam Translating Adam: matching only some specific header field instances is intentional, as these are the ones we know misconfigured servers send. (right?) It wouldn't hurt if the spec would explain that choice, if it doesn't right now. Best regards, Julian From ietf@adambarth.com Sun Jan 15 13:06:54 2012 Return-Path: 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 3F2DB21F8498 for ; Sun, 15 Jan 2012 13:06:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.772 X-Spam-Level: X-Spam-Status: No, score=-2.772 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-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 U76wrNHu0UoG for ; Sun, 15 Jan 2012 13:06:53 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id BCA4121F8467 for ; Sun, 15 Jan 2012 13:06:53 -0800 (PST) Received: by iaae16 with SMTP id e16so8115823iaa.31 for ; Sun, 15 Jan 2012 13:06:53 -0800 (PST) Received: by 10.50.197.169 with SMTP id iv9mr7362846igc.7.1326661613380; Sun, 15 Jan 2012 13:06:53 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id or2sm17249955igc.5.2012.01.15.13.06.52 (version=SSLv3 cipher=OTHER); Sun, 15 Jan 2012 13:06:52 -0800 (PST) Received: by iaae16 with SMTP id e16so8115796iaa.31 for ; Sun, 15 Jan 2012 13:06:52 -0800 (PST) Received: by 10.50.47.229 with SMTP id g5mr10128635ign.23.1326661612116; Sun, 15 Jan 2012 13:06:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.62.139 with HTTP; Sun, 15 Jan 2012 13:06:20 -0800 (PST) In-Reply-To: <4F133E75.2000204@gmx.de> References: <20120115195120.GG32205@1wt.eu> <20120115204154.GH32205@1wt.eu> <4F133E75.2000204@gmx.de> From: Adam Barth Date: Sun, 15 Jan 2012 13:06:20 -0800 Message-ID: To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ian@hixie.ch, websec@ietf.org, Willy Tarreau Subject: Re: [websec] Minor feedback on draft-ietf-websec-mime-sniff-03 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2012 21:06:54 -0000 On Sun, Jan 15, 2012 at 1:00 PM, Julian Reschke wro= te: > On 2012-01-15 21:53, Adam Barth wrote: >> On Sun, Jan 15, 2012 at 12:41 PM, Willy Tarreau =A0wrote: >>> On Sun, Jan 15, 2012 at 11:52:38AM -0800, Adam Barth wrote: >>>> The requirement in the spec is what we intend. =A0The rule applies onl= y >>>> to that exact octet sequence. >>> >>> But then what are the impacts of not matching the correct content-type = ? >> >> I'm not sure I understand your question. =A0Can you explain a scenario >> in which something happens that causes someone to be sad with the >> current requirements? > > Translating Adam: matching only some specific header field instances is > intentional, as these are the ones we know misconfigured servers send. > > (right?) > > It wouldn't hurt if the spec would explain that choice, if it doesn't rig= ht > now. I believe there's a ticket about adding that description. We've been focusing more on the introduction/scope editing at the moment, but we'll get to this point. More specifically, this is a workaround for an old (still widely deployed) version of Apache that used that exact octet sequence to identify resources for which it didn't know the MIME type. Apache has since been changed to omit the Content-Type header in these cases, but old Apache installs stay around for a very, very long time. Matching this exact octet sequence is the minimum injury way of dealing with this legacy content. Adam From ietf@adambarth.com Sun Jan 15 13:54:14 2012 Return-Path: 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 DEC4B21F84C3 for ; Sun, 15 Jan 2012 13:54:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=-0.106, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_LOW=-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 nWsjTJXqZIUJ for ; Sun, 15 Jan 2012 13:54:13 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id C4FFD21F845F for ; Sun, 15 Jan 2012 13:54:13 -0800 (PST) Received: by iaae16 with SMTP id e16so8164138iaa.31 for ; Sun, 15 Jan 2012 13:54:13 -0800 (PST) Received: by 10.50.88.129 with SMTP id bg1mr10243290igb.10.1326664453333; Sun, 15 Jan 2012 13:54:13 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id gh9sm21351603igb.3.2012.01.15.13.54.12 (version=SSLv3 cipher=OTHER); Sun, 15 Jan 2012 13:54:12 -0800 (PST) Received: by iaae16 with SMTP id e16so8164111iaa.31 for ; Sun, 15 Jan 2012 13:54:12 -0800 (PST) Received: by 10.50.214.38 with SMTP id nx6mr7563480igc.19.1326664451992; Sun, 15 Jan 2012 13:54:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.62.139 with HTTP; Sun, 15 Jan 2012 13:53:37 -0800 (PST) In-Reply-To: <4F10CB26.2000206@KingsMountain.com> References: <4F10CB26.2000206@KingsMountain.com> From: Adam Barth Date: Sun, 15 Jan 2012 13:53:37 -0800 Message-ID: To: "=JeffH" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF WebSec WG Subject: Re: [websec] of quoted-string header field param value syntax (was: Strict-Transport-Security syntax redux) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2012 21:54:15 -0000 On Fri, Jan 13, 2012 at 4:24 PM, =3DJeffH w= rote: > > In terms of this question of whether the STS header field directive ABNF > should be.. > > 1) =A0directive =A0 =A0 =A0 =A0 =3D token [ "=3D" ( token | quoted-string= ) ] > > ..or.. > > 2) =A0directive =A0 =A0 =A0 =A0 =3D token [ "=3D" token ] > > ..I can see both sides of the argument. > > However, I've been thinking about it and grepping thru specs as well as > firefox and chrome code, which has led me to think that from an overall > (specification) consistency perspective, I'm leaning towards spec'g it wi= th > quoted-string in the ABNF (ie, as (1)). And has been pointed out in the > discussion, it is sort of a moot point because the STS header field does = not > at this time make use of the quoted-string production, nor do we have on = the > table any extension directives that would do so. > > In going through the FF and Chrome code, I note that both of their STS > header field parsing methods appear to be special-case and AFAICT don't m= ake > use of other, more general HTTP header field parsing routines that are > available in both implementations, and that are used to parse other HTTP > response header fields. These latter more general HTTP header field parsi= ng > routines appear to be used for processing various of the other HTTP respo= nse > and request header fields (and they appear to handle quoted-string). But = it > isn't clear why they aren't used for STS. It also isn't clear how uniform= ly > these parsing routines are used for the panoply of HTTP header fields -- > some other header fields appear to be special-cased as well (tho my c++ f= oo > is wanting and the code is vast..). So yeah, it does seem messy. It's definitely messy. I don't think it matters much what we write in this document. Even if we spec quoted-string, I doubt many folks will implement it. However, we can deal with that problem when it comes time to add extension values that actually used quoted-string. Adam From julian.reschke@gmx.de Sun Jan 15 14:11:07 2012 Return-Path: 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 CCCAC21F8474 for ; Sun, 15 Jan 2012 14:11:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.603 X-Spam-Level: X-Spam-Status: No, score=-103.603 tagged_above=-999 required=5 tests=[AWL=-1.004, BAYES_00=-2.599, 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 Pqxnk0HaCKpV for ; Sun, 15 Jan 2012 14:11:06 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 6452B21F8472 for ; Sun, 15 Jan 2012 14:11:05 -0800 (PST) Received: (qmail invoked by alias); 15 Jan 2012 22:11:04 -0000 Received: from p5DCC2944.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.41.68] by mail.gmx.net (mp069) with SMTP; 15 Jan 2012 23:11:04 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/B4IQRNx3BTBVdG4Tkn+IkhEdwHP9u14UwAIV5FW bv/hkFnm1M2+8i Message-ID: <4F134EF6.5050208@gmx.de> Date: Sun, 15 Jan 2012 23:11:02 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Adam Barth References: <4F10CB26.2000206@KingsMountain.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: IETF WebSec WG Subject: Re: [websec] of quoted-string header field param value syntax (was: Strict-Transport-Security syntax redux) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2012 22:11:08 -0000 On 2012-01-15 22:53, Adam Barth wrote: > ... > It's definitely messy. > > I don't think it matters much what we write in this document. Even if > we spec quoted-string, I doubt many folks will implement it. However, > we can deal with that problem when it comes time to add extension > values that actually used quoted-string. > ... Apologies for the direct question: just 14 days ago you stated that you did not implement q-s in Chrome, and that you don't intend to: AB> Chrome does not (and will not) implement quoted-string for the STS AB> header for the reasons I've explained previously. You're welcome to AB> file bugs, but I'm just going to close them WONTFIX. That's somewhat different from what you say now. Is "the extensions do not exist yet" the excuse for not implementing what the spec says? Will you be around for fixing Chrome when the first bug reports because of broken extensions come in? Best regards, Julian From ietf@adambarth.com Sun Jan 15 14:25:23 2012 Return-Path: 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 54D6B21F849C for ; Sun, 15 Jan 2012 14:25:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.778 X-Spam-Level: X-Spam-Status: No, score=-2.778 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-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 Kms32QszGHxd for ; Sun, 15 Jan 2012 14:25:22 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id D019B21F8480 for ; Sun, 15 Jan 2012 14:25:22 -0800 (PST) Received: by iaae16 with SMTP id e16so8197112iaa.31 for ; Sun, 15 Jan 2012 14:25:22 -0800 (PST) Received: by 10.50.10.225 with SMTP id l1mr10327812igb.9.1326666322453; Sun, 15 Jan 2012 14:25:22 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id pb6sm29466476igc.5.2012.01.15.14.25.21 (version=SSLv3 cipher=OTHER); Sun, 15 Jan 2012 14:25:21 -0800 (PST) Received: by iaae16 with SMTP id e16so8197091iaa.31 for ; Sun, 15 Jan 2012 14:25:21 -0800 (PST) Received: by 10.50.194.202 with SMTP id hy10mr10318698igc.23.1326666321126; Sun, 15 Jan 2012 14:25:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.62.139 with HTTP; Sun, 15 Jan 2012 14:24:50 -0800 (PST) In-Reply-To: <4F134EF6.5050208@gmx.de> References: <4F10CB26.2000206@KingsMountain.com> <4F134EF6.5050208@gmx.de> From: Adam Barth Date: Sun, 15 Jan 2012 14:24:50 -0800 Message-ID: To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF WebSec WG Subject: Re: [websec] of quoted-string header field param value syntax (was: Strict-Transport-Security syntax redux) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2012 22:25:23 -0000 On Sun, Jan 15, 2012 at 2:11 PM, Julian Reschke wro= te: > On 2012-01-15 22:53, Adam Barth wrote: >> ... >> >> It's definitely messy. >> >> I don't think it matters much what we write in this document. =A0Even if >> we spec quoted-string, I doubt many folks will implement it. =A0However, >> we can deal with that problem when it comes time to add extension >> values that actually used quoted-string. >> ... > > Apologies for the direct question: just 14 days ago you stated that you d= id > not implement q-s in Chrome, and that you don't intend to: > > AB> Chrome does not (and will not) implement quoted-string for the STS > AB> header for the reasons I've explained previously. =A0You're welcome t= o > AB> file bugs, but I'm just going to close them WONTFIX. > > That's somewhat different from what you say now. > > Is "the extensions do not exist yet" the excuse for not implementing what > the spec says? Will you be around for fixing Chrome when the first bug > reports because of broken extensions come in? I don't plan to implement quoted-string in Chrome. I'm saying that I'm not going to object to writing quoted-string into the spec. I still think it's a bad idea, but I'm dropping my objection to it. Adam From julian.reschke@gmx.de Sun Jan 15 14:28:04 2012 Return-Path: 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 3EB5421F849C for ; Sun, 15 Jan 2012 14:28:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.563 X-Spam-Level: X-Spam-Status: No, score=-103.563 tagged_above=-999 required=5 tests=[AWL=-0.964, BAYES_00=-2.599, 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 HXIrNnccUwpJ for ; Sun, 15 Jan 2012 14:28:03 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 5A06E21F8471 for ; Sun, 15 Jan 2012 14:28:03 -0800 (PST) Received: (qmail invoked by alias); 15 Jan 2012 22:28:01 -0000 Received: from p5DCC2944.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.41.68] by mail.gmx.net (mp022) with SMTP; 15 Jan 2012 23:28:01 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19DwFReRMhDwI8chLO6boB5envisl2oKzXaO+7Ic6 1gxT9u236oMFS2 Message-ID: <4F1352EF.60508@gmx.de> Date: Sun, 15 Jan 2012 23:27:59 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Adam Barth References: <4F10CB26.2000206@KingsMountain.com> <4F134EF6.5050208@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: IETF WebSec WG Subject: Re: [websec] of quoted-string header field param value syntax (was: Strict-Transport-Security syntax redux) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2012 22:28:04 -0000 On 2012-01-15 23:24, Adam Barth wrote: > On Sun, Jan 15, 2012 at 2:11 PM, Julian Reschke wrote: >> On 2012-01-15 22:53, Adam Barth wrote: >>> ... >>> >>> It's definitely messy. >>> >>> I don't think it matters much what we write in this document. Even if >>> we spec quoted-string, I doubt many folks will implement it. However, >>> we can deal with that problem when it comes time to add extension >>> values that actually used quoted-string. >>> ... >> >> Apologies for the direct question: just 14 days ago you stated that you did >> not implement q-s in Chrome, and that you don't intend to: >> >> AB> Chrome does not (and will not) implement quoted-string for the STS >> AB> header for the reasons I've explained previously. You're welcome to >> AB> file bugs, but I'm just going to close them WONTFIX. >> >> That's somewhat different from what you say now. >> >> Is "the extensions do not exist yet" the excuse for not implementing what >> the spec says? Will you be around for fixing Chrome when the first bug >> reports because of broken extensions come in? > > I don't plan to implement quoted-string in Chrome. I'm saying that > I'm not going to object to writing quoted-string into the spec. I > still think it's a bad idea, but I'm dropping my objection to it. So when the bug reports come in, *somebody else* is going to fix Chrome? I really want to know. From julian.reschke@gmx.de Sun Jan 15 14:31:06 2012 Return-Path: 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 0359521F8468 for ; Sun, 15 Jan 2012 14:31:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.526 X-Spam-Level: X-Spam-Status: No, score=-103.526 tagged_above=-999 required=5 tests=[AWL=-0.927, BAYES_00=-2.599, 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 xW-JwWm3ZtKy for ; Sun, 15 Jan 2012 14:31:05 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 06E7D21F845F for ; Sun, 15 Jan 2012 14:31:02 -0800 (PST) Received: (qmail invoked by alias); 15 Jan 2012 22:31:01 -0000 Received: from p5DCC2944.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.41.68] by mail.gmx.net (mp070) with SMTP; 15 Jan 2012 23:31:01 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+sEF5ViHesGNL/OId0br/7+iJj/mkc21sCnkJmpi jXjB2RVE3PTAjx Message-ID: <4F1353A3.6000801@gmx.de> Date: Sun, 15 Jan 2012 23:30:59 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Adam Barth References: <4EFCDDD5.6040005@gmx.de> <4EFD73E6.1060506@gmx.de> <4EFD7C09.9050702@gmx.de> <4EFD8BCE.7010909@gmx.de> <4F052D2E.5050200@gondrom.org> <4F0A372B.2070407@gmx.de> In-Reply-To: <4F0A372B.2070407@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Bjoern Hoehrmann , websec@ietf.org Subject: Re: [websec] Strict-Transport-Security syntax redux X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2012 22:31:06 -0000 On 2012-01-09 01:39, Julian Reschke wrote: > On 2012-01-09 01:25, Adam Barth wrote: >> On Sun, Jan 8, 2012 at 4:10 PM, Bjoern Hoehrmann >> wrote: >>> * Tobias Gondrom wrote: >>>> >>>> as it seems there is disagreement on how to resolve this, with only >>>> very >>>> few people having spoken out so far, I would like to invite comments >>> >from other working group members on this topic to see whether we might >>>> have missed something. >>> >>> It seems to me that all headers defined in RFC 2616 that allow para- >>> meteter lists of the `;name=value` form allow the value to be a quoted >>> string. >> >> This header isn't defined in RFC 2616 and many headers defined outside >> of RFC 2616 don't use quoted-string. >> ... > > In name/value pairs? Example? > > (As a matter of fact, not all header fields in 2616 are as consistent as > they should, but that's not an excuse for not trying to do better with > new header fields) > ... I note you didn't supply examples. Best regards, Julian From ietf@adambarth.com Sun Jan 15 14:55:39 2012 Return-Path: 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 357A021F84F4 for ; Sun, 15 Jan 2012 14:55:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.787 X-Spam-Level: X-Spam-Status: No, score=-2.787 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-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 j6FoARLGZNh2 for ; Sun, 15 Jan 2012 14:55:38 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 97B6121F84F2 for ; Sun, 15 Jan 2012 14:55:37 -0800 (PST) Received: by iaae16 with SMTP id e16so8228332iaa.31 for ; Sun, 15 Jan 2012 14:55:37 -0800 (PST) Received: by 10.42.147.72 with SMTP id m8mr8297732icv.56.1326668137253; Sun, 15 Jan 2012 14:55:37 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id py9sm29613430igc.2.2012.01.15.14.55.36 (version=SSLv3 cipher=OTHER); Sun, 15 Jan 2012 14:55:36 -0800 (PST) Received: by iaae16 with SMTP id e16so8228294iaa.31 for ; Sun, 15 Jan 2012 14:55:36 -0800 (PST) Received: by 10.50.47.229 with SMTP id g5mr10395998ign.23.1326668136106; Sun, 15 Jan 2012 14:55:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.62.139 with HTTP; Sun, 15 Jan 2012 14:55:06 -0800 (PST) In-Reply-To: <4F1352EF.60508@gmx.de> References: <4F10CB26.2000206@KingsMountain.com> <4F134EF6.5050208@gmx.de> <4F1352EF.60508@gmx.de> From: Adam Barth Date: Sun, 15 Jan 2012 14:55:06 -0800 Message-ID: To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF WebSec WG Subject: Re: [websec] of quoted-string header field param value syntax (was: Strict-Transport-Security syntax redux) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2012 22:55:39 -0000 On Sun, Jan 15, 2012 at 2:27 PM, Julian Reschke wro= te: > On 2012-01-15 23:24, Adam Barth wrote: >> >> On Sun, Jan 15, 2012 at 2:11 PM, Julian Reschke >> =A0wrote: >>> >>> On 2012-01-15 22:53, Adam Barth wrote: >>>> >>>> ... >>>> >>>> It's definitely messy. >>>> >>>> I don't think it matters much what we write in this document. =A0Even = if >>>> we spec quoted-string, I doubt many folks will implement it. =A0Howeve= r, >>>> we can deal with that problem when it comes time to add extension >>>> values that actually used quoted-string. >>>> ... >>> >>> >>> Apologies for the direct question: just 14 days ago you stated that you >>> did >>> not implement q-s in Chrome, and that you don't intend to: >>> >>> AB> =A0Chrome does not (and will not) implement quoted-string for the S= TS >>> AB> =A0header for the reasons I've explained previously. =A0You're welc= ome to >>> AB> =A0file bugs, but I'm just going to close them WONTFIX. >>> >>> That's somewhat different from what you say now. >>> >>> Is "the extensions do not exist yet" the excuse for not implementing wh= at >>> the spec says? Will you be around for fixing Chrome when the first bug >>> reports because of broken extensions come in? >> >> I don't plan to implement quoted-string in Chrome. =A0I'm saying that >> I'm not going to object to writing quoted-string into the spec. =A0I >> still think it's a bad idea, but I'm dropping my objection to it. > > So when the bug reports come in, *somebody else* is going to fix Chrome? > > I really want to know. I doubt it will be high on anyone's priority list. If you'd like to implement it, you're welcome to submit a patch. (Of course, I can't promise that the patch will be accepted.) Adam From julian.reschke@gmx.de Sun Jan 15 15:03:35 2012 Return-Path: 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 EF56321F8480 for ; Sun, 15 Jan 2012 15:03:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.492 X-Spam-Level: X-Spam-Status: No, score=-103.492 tagged_above=-999 required=5 tests=[AWL=-0.893, BAYES_00=-2.599, 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 Tvh9PzbypF95 for ; Sun, 15 Jan 2012 15:03:35 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id EF83621F84D7 for ; Sun, 15 Jan 2012 15:03:30 -0800 (PST) Received: (qmail invoked by alias); 15 Jan 2012 23:03:27 -0000 Received: from p5DCC2944.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.41.68] by mail.gmx.net (mp059) with SMTP; 16 Jan 2012 00:03:27 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX194OF4sau941KuFpLlliq18JptRxFPPdQO+danhOI KJzz/+0UMVKi5D Message-ID: <4F135B3C.5080508@gmx.de> Date: Mon, 16 Jan 2012 00:03:24 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Adam Barth References: <4F10CB26.2000206@KingsMountain.com> <4F134EF6.5050208@gmx.de> <4F1352EF.60508@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: IETF WebSec WG Subject: Re: [websec] of quoted-string header field param value syntax (was: Strict-Transport-Security syntax redux) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2012 23:03:36 -0000 On 2012-01-15 23:55, Adam Barth wrote: > On Sun, Jan 15, 2012 at 2:27 PM, Julian Reschke wrote: >> On 2012-01-15 23:24, Adam Barth wrote: >>> >>> On Sun, Jan 15, 2012 at 2:11 PM, Julian Reschke >>> wrote: >>>> >>>> On 2012-01-15 22:53, Adam Barth wrote: >>>>> >>>>> ... >>>>> >>>>> It's definitely messy. >>>>> >>>>> I don't think it matters much what we write in this document. Even if >>>>> we spec quoted-string, I doubt many folks will implement it. However, >>>>> we can deal with that problem when it comes time to add extension >>>>> values that actually used quoted-string. >>>>> ... >>>> >>>> >>>> Apologies for the direct question: just 14 days ago you stated that you >>>> did >>>> not implement q-s in Chrome, and that you don't intend to: >>>> >>>> AB> Chrome does not (and will not) implement quoted-string for the STS >>>> AB> header for the reasons I've explained previously. You're welcome to >>>> AB> file bugs, but I'm just going to close them WONTFIX. >>>> >>>> That's somewhat different from what you say now. >>>> >>>> Is "the extensions do not exist yet" the excuse for not implementing what >>>> the spec says? Will you be around for fixing Chrome when the first bug >>>> reports because of broken extensions come in? >>> >>> I don't plan to implement quoted-string in Chrome. I'm saying that >>> I'm not going to object to writing quoted-string into the spec. I >>> still think it's a bad idea, but I'm dropping my objection to it. >> >> So when the bug reports come in, *somebody else* is going to fix Chrome? >> >> I really want to know. > > I doubt it will be high on anyone's priority list. If you'd like to > implement it, you're welcome to submit a patch. (Of course, I can't > promise that the patch will be accepted.) > ... 14 days ago you said: > Chrome does not (and will not) implement quoted-string for the STS > header for the reasons I've explained previously. You're welcome to > file bugs, but I'm just going to close them WONTFIX. Has this changed? Will patches be closed as WONTFIX no matter how good they are? It *really* would be helpful if you would clearly state your position. And also clarify on whose behalf you are speaking here. Best regards, Julian From ietf@adambarth.com Sun Jan 15 15:13:04 2012 Return-Path: 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 68A1F21F84EC for ; Sun, 15 Jan 2012 15:13:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.796 X-Spam-Level: X-Spam-Status: No, score=-2.796 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-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 HfoWSKZ8wod6 for ; Sun, 15 Jan 2012 15:13:03 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id CC2CE21F84EA for ; Sun, 15 Jan 2012 15:13:03 -0800 (PST) Received: by iaae16 with SMTP id e16so8247216iaa.31 for ; Sun, 15 Jan 2012 15:13:03 -0800 (PST) Received: by 10.50.207.72 with SMTP id lu8mr10478130igc.0.1326669183487; Sun, 15 Jan 2012 15:13:03 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id xu6sm29669272igb.7.2012.01.15.15.13.02 (version=SSLv3 cipher=OTHER); Sun, 15 Jan 2012 15:13:02 -0800 (PST) Received: by iaae16 with SMTP id e16so8247185iaa.31 for ; Sun, 15 Jan 2012 15:13:02 -0800 (PST) Received: by 10.42.161.10 with SMTP id r10mr8488399icx.22.1326669182121; Sun, 15 Jan 2012 15:13:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.62.139 with HTTP; Sun, 15 Jan 2012 15:12:31 -0800 (PST) In-Reply-To: <4F135B3C.5080508@gmx.de> References: <4F10CB26.2000206@KingsMountain.com> <4F134EF6.5050208@gmx.de> <4F1352EF.60508@gmx.de> <4F135B3C.5080508@gmx.de> From: Adam Barth Date: Sun, 15 Jan 2012 15:12:31 -0800 Message-ID: To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF WebSec WG Subject: Re: [websec] of quoted-string header field param value syntax (was: Strict-Transport-Security syntax redux) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2012 23:13:04 -0000 On Sun, Jan 15, 2012 at 3:03 PM, Julian Reschke wro= te: > On 2012-01-15 23:55, Adam Barth wrote: >> On Sun, Jan 15, 2012 at 2:27 PM, Julian Reschke >> =A0wrote: >>> On 2012-01-15 23:24, Adam Barth wrote: >>>> On Sun, Jan 15, 2012 at 2:11 PM, Julian Reschke >>>> =A0wrote: >>>>> On 2012-01-15 22:53, Adam Barth wrote: >>>>>> ... >>>>>> >>>>>> It's definitely messy. >>>>>> >>>>>> I don't think it matters much what we write in this document. =A0Eve= n if >>>>>> we spec quoted-string, I doubt many folks will implement it. =A0Howe= ver, >>>>>> we can deal with that problem when it comes time to add extension >>>>>> values that actually used quoted-string. >>>>>> ... \>>>>> >>>>> Apologies for the direct question: just 14 days ago you stated that y= ou >>>>> did >>>>> not implement q-s in Chrome, and that you don't intend to: >>>>> >>>>> AB> =A0 =A0Chrome does not (and will not) implement quoted-string for= the >>>>> STS >>>>> AB> =A0 =A0header for the reasons I've explained previously. =A0You'r= e >>>>> welcome to >>>>> AB> =A0 =A0file bugs, but I'm just going to close them WONTFIX. >>>>> >>>>> That's somewhat different from what you say now. >>>>> >>>>> Is "the extensions do not exist yet" the excuse for not implementing >>>>> what >>>>> the spec says? Will you be around for fixing Chrome when the first bu= g >>>>> reports because of broken extensions come in? >>>> >>>> >>>> I don't plan to implement quoted-string in Chrome. =A0I'm saying that >>>> I'm not going to object to writing quoted-string into the spec. =A0I >>>> still think it's a bad idea, but I'm dropping my objection to it. >>> >>> >>> So when the bug reports come in, *somebody else* is going to fix Chrome= ? >>> >>> I really want to know. >> >> >> I doubt it will be high on anyone's priority list. =A0If you'd like to >> implement it, you're welcome to submit a patch. =A0(Of course, I can't >> promise that the patch will be accepted.) >> ... > > > 14 days ago you said: > >> Chrome does not (and will not) implement quoted-string for the STS >> header for the reasons I've explained previously. =A0You're welcome to >> file bugs, but I'm just going to close them WONTFIX. > > Has this changed? Will patches be closed as WONTFIX no matter how good th= ey > are? I'll state my opinion about the patch, which hasn't changed. However, it's an open source project. You're welcome to submit whatever patches you like. They'll get reviewed and discussed, just like any other patches. > It *really* would be helpful if you would clearly state your position. An= d > also clarify on whose behalf you are speaking here. Am I not being clear? I'm not going to implemented quoted-string, and I doubt that many other folks will either. I'm no longer objecting to including quoted-string in the spec (although I believe including it is the wrong decision). As is customary at the IETF, I speak for myself. Adam From Jeff.Hodges@KingsMountain.com Sun Jan 15 18:50:20 2012 Return-Path: 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 D241521F8513 for ; Sun, 15 Jan 2012 18:50:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.027 X-Spam-Level: X-Spam-Status: No, score=-99.027 tagged_above=-999 required=5 tests=[AWL=-1.732, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_41=0.6, RDNS_NONE=0.1, 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 U6JfgU1wNTHW for ; Sun, 15 Jan 2012 18:50:20 -0800 (PST) Received: from oproxy6-pub.bluehost.com (oproxy6.bluehost.com [IPv6:2605:dc00:100:2::a6]) by ietfa.amsl.com (Postfix) with SMTP id 1B0DD21F8505 for ; Sun, 15 Jan 2012 18:50:20 -0800 (PST) Received: (qmail 19222 invoked by uid 0); 16 Jan 2012 02:50:18 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy3.bluehost.com with SMTP; 16 Jan 2012 02:50:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=UuaNfvqr36FGsZvBQxqcgr6SGWjERs0di82+cuK85VE=; b=lKh5XTzwwgDQ+UElw48ym/uVFLN8geVJbEqkn4uzQcromEwtm1bkH+sSs0Y0VDQus154XxsKGFuT8sd0AUOI0LAAsD4NkT0Ai4E6arOiBleuMMiz8hIQ8cEhK7b0sKwC; Received: from c-24-4-122-173.hsd1.ca.comcast.net ([24.4.122.173] helo=[192.168.11.18]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1RmceH-0008TI-IU; Sun, 15 Jan 2012 19:50:17 -0700 Message-ID: <4F139068.3030809@KingsMountain.com> Date: Sun, 15 Jan 2012 18:50:16 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: IETF WebSec WG , Adam Barth Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Subject: Re: [websec] of quoted-string header field param value syntax (was: Strict-Transport-Security syntax redux) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 02:50:21 -0000 Thanks for your thoughts, > I don't think it matters much what we write in this document. I overall understand and tend to agree, because I'm doubting we will see much if any further extension work for this header field. > However, > we can deal with that problem when it comes time to add extension > values that actually used quoted-string. agreed. that's why I'm leaning towards spec'g it with quoted-string at this time. It future-proofs the spec at least and we won't have to fight a nit like this in Last Calls. I'm not too worried at this point about user agents not actually implementing parsing for as-yet-unspecified-or-even-discussed extension directives for the STS header field. though, I remain curious as to why the STS parsing in Firefox & Chrome is apparently each a one-off and doesn't use the more generic HTTP header-field parsing routines that are available and which appear to handle quoted-string, arbitrary header field parameter ordering, etc. thanks, =JeffH From Jeff.Hodges@KingsMountain.com Sun Jan 15 18:57:05 2012 Return-Path: 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 78B6221F8469 for ; Sun, 15 Jan 2012 18:57:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.038 X-Spam-Level: X-Spam-Status: No, score=-99.038 tagged_above=-999 required=5 tests=[AWL=-1.143, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, 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 u+wWSo4zXGrx for ; Sun, 15 Jan 2012 18:57:05 -0800 (PST) Received: from oproxy3-pub.bluehost.com (oproxy3.bluehost.com [IPv6:2605:dc00:100:2::a3]) by ietfa.amsl.com (Postfix) with SMTP id DFD7021F8464 for ; Sun, 15 Jan 2012 18:57:04 -0800 (PST) Received: (qmail 28631 invoked by uid 0); 16 Jan 2012 02:57:04 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy3.bluehost.com with SMTP; 16 Jan 2012 02:57:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=lqXW5GPsRcw5y9sIPYmRY8MeCKpNVq+I30J1xnWEKp4=; b=6LThgeN+7OUg6shKPgzw6OvTyPegLVpKORZqv1EQ2jPPFXOIM3ImqZCQIzYv2C3G2B5/UEJyb2pihOvAHQR5nyyy6XCrnwnJyhVQSwDBN8Z+uTAB0Kisew1h1ns1zjJA; Received: from c-24-4-122-173.hsd1.ca.comcast.net ([24.4.122.173] helo=[192.168.11.18]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1Rmckp-000707-W0 for websec@ietf.org; Sun, 15 Jan 2012 19:57:04 -0700 Message-ID: <4F1391FE.9080500@KingsMountain.com> Date: Sun, 15 Jan 2012 18:57:02 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: IETF WebSec WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Subject: Re: [websec] #34: HSTS cache manipulation and misuse by server enabled by wildcard cert X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 02:57:05 -0000 Adam wondered.. > > Why not just postMessage of the HTML element? If you want be > more sneaky about it, you can just the HTTP cache. Anyway, web sites > are allowed to send messages to each other. Yeah. I submitted that item for completeness-sake, it'd gotten shuffled deep in the proverbial pile, and we hadn't discussed it here as yet. =JeffH From w@1wt.eu Sun Jan 15 11:51:37 2012 Return-Path: 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 B4ECA21F847F for ; Sun, 15 Jan 2012 11:51:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.235 X-Spam-Level: X-Spam-Status: No, score=-6.235 tagged_above=-999 required=5 tests=[AWL=-4.192, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] 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 WPzZn8hJvUOB for ; Sun, 15 Jan 2012 11:51:37 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id D516921F847C for ; Sun, 15 Jan 2012 11:51:36 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q0FJpKLW007363; Sun, 15 Jan 2012 20:51:20 +0100 Date: Sun, 15 Jan 2012 20:51:20 +0100 From: Willy Tarreau To: ietf@adambarth.com, ian@hixie.ch Message-ID: <20120115195120.GG32205@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Mailman-Approved-At: Sun, 15 Jan 2012 19:21:26 -0800 Cc: websec@ietf.org Subject: [websec] Minor feedback on draft-ietf-websec-mime-sniff-03 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2012 19:51:37 -0000 Hello Adam, Ian, Today I came across your draft "draft-ietf-websec-mime-sniff-03", and noticed the point below : 2. If the octets were fetched via HTTP and there is an HTTP Content- Type header field and the value of the last such header field has octets that *exactly* match the octets contained in one of the following lines: +-------------------------------+--------------------------------+ | Bytes in Hexadecimal | Textual Representation | +-------------------------------+--------------------------------+ | 74 65 78 74 2f 70 6c 61 69 6e | text/plain | +-------------------------------+--------------------------------+ | 74 65 78 74 2f 70 6c 61 69 6e | text/plain; charset=ISO-8859-1 | | 3b 20 63 68 61 72 73 65 74 3d | | | 49 53 4f 2d 38 38 35 39 2d 31 | | .../... I was having a doubt about spaces being optional around the semi-colon, so I just checked and indeed we have OWS before and after it : http://www.ietf.org/id/draft-ietf-httpbis-p3-payload-18.txt 2.3. Media Types HTTP uses Internet Media Types [RFC2046] in the Content-Type (Section 6.8) and Accept (Section 6.1) header fields in order to provide open and extensible data typing and type negotiation. media-type = type "/" subtype *( OWS ";" OWS parameter ) type = token subtype = token The type/subtype MAY be followed by parameters in the form of attribute/value pairs. parameter = attribute "=" value attribute = token value = word Also, it is said here that quotes are allowed around the parameter value : A parameter value that matches the token production can be transmitted as either a token or within a quoted-string. The quoted and unquoted values are equivalent. So examples below are completely valid : Content-type: text/plain;charset="ISO-8859-1" Content-type: text/plain ; charset=ISO-8859-1 Content-type: text/plain ; charset="ISO-8859-1" Thus the byte matching can only apply to the tokens and values. I think the safest thing to do would be to refer to the HTTP spec to define the header format then suggest byte matches for each fields, for instance : If the octets were fetched via HTTP and there is an HTTP Content- Type header field and the value of the last such header *exactly* matches one of the media-types below, then the sniffed-type is defined as the concatenation of the unquoted matching parts : media-type = type "/" subtype *( OWS ";" OWS parameter ) sniffed-type = type "/" subtype 1*( "; " attribute "=" value ) All accepted media-types must *exactly* match : - type = "text" (hex 74 65 78 74) - subtype = "plain" (hex 70 6c 61 69 6e) If a parameter is present, its attribute must be "charset" (hex 63 68 61 72 73 65 74) and the value must be one of : - "ISO-8859-1" (hex 49 53 4f 2d 38 38 35 39 2d 31) - "iso-8859-1" (hex 69 73 6f 2d 38 38 35 39 2d 31) - "UTF-8" (hex 55 54 46 2d 38) Please also note that HTTP indicates that some attributes accept a case-insensitive value. I have not yet found in the spec if "charset" accepts a case-insensitive value, but given that you identified two possible cases for "iso-8859-1", it is likely that "charset" falls into this case. Best regards, Willy From w@1wt.eu Sun Jan 15 12:42:01 2012 Return-Path: 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 D0ECB21F8489 for ; Sun, 15 Jan 2012 12:42:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.711 X-Spam-Level: X-Spam-Status: No, score=-5.711 tagged_above=-999 required=5 tests=[AWL=-3.668, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] 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 lIMYbXT90gP1 for ; Sun, 15 Jan 2012 12:42:01 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 0D14F21F8487 for ; Sun, 15 Jan 2012 12:42:00 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q0FKfsFG007489; Sun, 15 Jan 2012 21:41:54 +0100 Date: Sun, 15 Jan 2012 21:41:54 +0100 From: Willy Tarreau To: Adam Barth Message-ID: <20120115204154.GH32205@1wt.eu> References: <20120115195120.GG32205@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Mailman-Approved-At: Sun, 15 Jan 2012 19:21:26 -0800 Cc: websec@ietf.org, ian@hixie.ch Subject: Re: [websec] Minor feedback on draft-ietf-websec-mime-sniff-03 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2012 20:42:02 -0000 On Sun, Jan 15, 2012 at 11:52:38AM -0800, Adam Barth wrote: > The requirement in the spec is what we intend. The rule applies only > to that exact octet sequence. But then what are the impacts of not matching the correct content-type ? Willy From w@1wt.eu Sun Jan 15 13:17:12 2012 Return-Path: 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 B286421F8489 for ; Sun, 15 Jan 2012 13:17:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.374 X-Spam-Level: X-Spam-Status: No, score=-4.374 tagged_above=-999 required=5 tests=[AWL=-4.190, BAYES_20=-0.74, HELO_IS_SMALL6=0.556] 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 FYENeTYbHMMX for ; Sun, 15 Jan 2012 13:17:12 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id D945821F8480 for ; Sun, 15 Jan 2012 13:17:11 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q0FLH2oA007630; Sun, 15 Jan 2012 22:17:02 +0100 Date: Sun, 15 Jan 2012 22:17:02 +0100 From: Willy Tarreau To: Adam Barth Message-ID: <20120115211702.GJ32205@1wt.eu> References: <20120115195120.GG32205@1wt.eu> <20120115204154.GH32205@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Mailman-Approved-At: Sun, 15 Jan 2012 19:21:26 -0800 Cc: websec@ietf.org, ian@hixie.ch Subject: Re: [websec] Minor feedback on draft-ietf-websec-mime-sniff-03 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2012 21:17:12 -0000 On Sun, Jan 15, 2012 at 12:53:00PM -0800, Adam Barth wrote: > On Sun, Jan 15, 2012 at 12:41 PM, Willy Tarreau wrote: > > On Sun, Jan 15, 2012 at 11:52:38AM -0800, Adam Barth wrote: > >> The requirement in the spec is what we intend.  The rule applies only > >> to that exact octet sequence. > > > > But then what are the impacts of not matching the correct content-type ? > > I'm not sure I understand your question. Can you explain a scenario > in which something happens that causes someone to be sad with the > current requirements? The draft presents an algorithm to determine a content type based on available information, but ignores some important information such as valid header values when presented in an unexpected form. For instance, if I get a file advertised like this : Content-type: text/plain; charset=us-ascii then it will not be interpreted as text/plain but rather based on what is found in the contents. This can make it impossible to read some documents purposely sent as plain text (eg: HTML or PS source code). It could also also have security impacts such as causing some plugins to be fed with the mis-identified data. For instance, imagine that I'm browsing behind a filtering proxy which checks that PDF documents are exempt of any exploit. This proxy will most likely consider the advertised content-type and won't fire the PDF analyser on text/plain documents. But the browser at the end of the chain ignores the text/plain and decides to launch the plugin. As you know, in general, having multiple components interprete different things from similar contents is dangerous for interoperability and for security. Note that it is possible that I missed something as it's not trivial to get right the way it's written :-/ Best regards, Willy From w@1wt.eu Sun Jan 15 13:25:59 2012 Return-Path: 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 AF99F21F8480 for ; Sun, 15 Jan 2012 13:25:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.885 X-Spam-Level: X-Spam-Status: No, score=-4.885 tagged_above=-999 required=5 tests=[AWL=-2.842, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] 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 3dBbnvSov7IC for ; Sun, 15 Jan 2012 13:25:59 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id D942221F8475 for ; Sun, 15 Jan 2012 13:25:58 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q0FLPpWX007654; Sun, 15 Jan 2012 22:25:51 +0100 Date: Sun, 15 Jan 2012 22:25:51 +0100 From: Willy Tarreau To: Adam Barth Message-ID: <20120115212551.GK32205@1wt.eu> References: <20120115195120.GG32205@1wt.eu> <20120115204154.GH32205@1wt.eu> <4F133E75.2000204@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Mailman-Approved-At: Sun, 15 Jan 2012 19:21:26 -0800 Cc: Julian Reschke , ian@hixie.ch, websec@ietf.org Subject: Re: [websec] Minor feedback on draft-ietf-websec-mime-sniff-03 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2012 21:25:59 -0000 On Sun, Jan 15, 2012 at 01:06:20PM -0800, Adam Barth wrote: > On Sun, Jan 15, 2012 at 1:00 PM, Julian Reschke wrote: > > On 2012-01-15 21:53, Adam Barth wrote: > >> On Sun, Jan 15, 2012 at 12:41 PM, Willy Tarreau  wrote: > >>> On Sun, Jan 15, 2012 at 11:52:38AM -0800, Adam Barth wrote: > >>>> The requirement in the spec is what we intend.  The rule applies only > >>>> to that exact octet sequence. > >>> > >>> But then what are the impacts of not matching the correct content-type ? > >> > >> I'm not sure I understand your question.  Can you explain a scenario > >> in which something happens that causes someone to be sad with the > >> current requirements? > > > > Translating Adam: matching only some specific header field instances is > > intentional, as these are the ones we know misconfigured servers send. > > > > (right?) > > > > It wouldn't hurt if the spec would explain that choice, if it doesn't right > > now. > > I believe there's a ticket about adding that description. We've been > focusing more on the introduction/scope editing at the moment, but > we'll get to this point. > > More specifically, this is a workaround for an old (still widely > deployed) version of Apache that used that exact octet sequence to > identify resources for which it didn't know the MIME type. Apache has > since been changed to omit the Content-Type header in these cases, but > old Apache installs stay around for a very, very long time. Matching > this exact octet sequence is the minimum injury way of dealing with > this legacy content. OK I think I'm getting it now. I assumed that at step 2 of section 4, the matching text was constituting the official-type, which apparently it's not. Getting it wrong at this point causes a jump to the "unknown type" section. Maybe some names should be changed (eg: "content-type" instead of "official-type") to make it easier to read. Confusion is too easy this way and immediately makes code derived from a wrong interpretation to be buggy :-( Regards, Willy From marsh@extendedsubset.com Sun Jan 15 21:38:15 2012 Return-Path: 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 6A8B221F8545 for ; Sun, 15 Jan 2012 21:38:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] 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 n1wz-Xjx1zX7 for ; Sun, 15 Jan 2012 21:38:13 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA1121F846C for ; Sun, 15 Jan 2012 21:38:13 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1RmfGm-000Nvy-St; Mon, 16 Jan 2012 05:38:12 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id C09226067; Mon, 16 Jan 2012 05:38:11 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18erCAnhMovnFeyqrjsupzfwpNGWRXjV1c= Message-ID: <4F13B7C2.5010603@extendedsubset.com> Date: Sun, 15 Jan 2012 23:38:10 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Anne van Kesteren References: <4EAB66B3.4090404@KingsMountain.com> <4EABB25E.9000900@gmx.de> <4EFC5F7B.7050304@gmx.de> <4EFCD7E4.5060507@gmx.de> <4EFCDA9C.90308@gmx.de> <4EFCDDD5.6040005@gmx.de> <4EFD73E6.1060506@gmx.de> <4EFD7C09.9050702@gmx.de> <4EFD8BCE.7010909@gmx.de> <4F052D2E.5050200@gondrom.org> <4F056553.9030409@gmx.de> <553F526C-4433-489B-80B5-4C29E5FB0DC4@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: websec@ietf.org Subject: Re: [websec] Strict-Transport-Security syntax redux X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 05:38:15 -0000 On 01/05/2012 11:50 AM, Anne van Kesteren wrote: > On Thu, 05 Jan 2012 16:59:58 +0100, Paul Hoffman > wrote: >> >> "We invented a header that your message-producing software must >> special-case" is not a good way to get security. > > If the header-consuming software works that way, it might be the only > way. What the right way to go here is kind of depends on how header > field values are typically implemented in practice. I suspect it to be > rather messy. How about: servers generating the header MUST use quoted-string whenever quoted-string is necessary, otherwise they SHOULD use the token production on Mondays, Wednesdays, and Fridays and they SHOULD use quoted-string on Tuesday, Thursday, Saturday, and Sunday. Yes, I'm joking. But only half-way. I have a deep suspicion that something like that might actually yield the best interoperability overall. One thing worse than having arbitrarily-chosen redundant code paths is having protocol grammar that's never ever used - until it's needed. Meredith Patterson, Sergey Bratus, et al. have been talking about the deep logical connections between lanugage expressive power, generator/parser differences, and ... working exploits. http://www.cs.dartmouth.edu/~sergey/langsec/ 28c3: The Science of Insecurity http://www.youtube.com/watch?v=3kEfedtQVOY Worth watching. And of course: Occupy Babel! http://www.cs.dartmouth.edu/~sergey/langsec/occupy/ :-) - Marsh From julian.reschke@gmx.de Mon Jan 16 00:24:12 2012 Return-Path: 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 C26DB21F854F for ; Mon, 16 Jan 2012 00:24:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.46 X-Spam-Level: X-Spam-Status: No, score=-103.46 tagged_above=-999 required=5 tests=[AWL=-0.861, BAYES_00=-2.599, 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 N0FXdZdABIzG for ; Mon, 16 Jan 2012 00:24:12 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id B5EFB21F854E for ; Mon, 16 Jan 2012 00:24:11 -0800 (PST) Received: (qmail invoked by alias); 16 Jan 2012 08:24:10 -0000 Received: from p5DCC2944.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.41.68] by mail.gmx.net (mp008) with SMTP; 16 Jan 2012 09:24:10 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+XIJosEW6X4I8yJyaVhiie3+lpKO9GRW6bKqSr2U r5H3MrcPJxXmJo Message-ID: <4F13DEA2.1000801@gmx.de> Date: Mon, 16 Jan 2012 09:24:02 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: =JeffH References: <4F139068.3030809@KingsMountain.com> In-Reply-To: <4F139068.3030809@KingsMountain.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: IETF WebSec WG Subject: Re: [websec] of quoted-string header field param value syntax (was: Strict-Transport-Security syntax redux) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 08:24:12 -0000 On 2012-01-16 03:50, =JeffH wrote: > ... > though, I remain curious as to why the STS parsing in Firefox & Chrome > is apparently each a one-off and doesn't use the more generic HTTP > header-field parsing routines that are available and which appear to > handle quoted-string, arbitrary header field parameter ordering, etc. > ... Well. One reason for that is that STS is indeed different from other header fields (for instance, things like Content-Type, Expect, or Cache-Control). To enable UAs to re-use code, you need to specify the header field so that code can indeed be re-used. Best regards, Julian From julian.reschke@gmx.de Mon Jan 16 00:26:45 2012 Return-Path: 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 20B1621F84A3 for ; Mon, 16 Jan 2012 00:26:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.43 X-Spam-Level: X-Spam-Status: No, score=-103.43 tagged_above=-999 required=5 tests=[AWL=-0.831, BAYES_00=-2.599, 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 DnGE28gl3KvB for ; Mon, 16 Jan 2012 00:26:44 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 4104421F8463 for ; Mon, 16 Jan 2012 00:26:44 -0800 (PST) Received: (qmail invoked by alias); 16 Jan 2012 08:26:42 -0000 Received: from p5DCC2944.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.41.68] by mail.gmx.net (mp023) with SMTP; 16 Jan 2012 09:26:42 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18/U4wIiXk/K53cimCl7ruua2P7kaIYPFP9T9E3r5 ZmK6MiZP4YrmAM Message-ID: <4F13DF3A.4050504@gmx.de> Date: Mon, 16 Jan 2012 09:26:34 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Marsh Ray References: <4EAB66B3.4090404@KingsMountain.com> <4EABB25E.9000900@gmx.de> <4EFC5F7B.7050304@gmx.de> <4EFCD7E4.5060507@gmx.de> <4EFCDA9C.90308@gmx.de> <4EFCDDD5.6040005@gmx.de> <4EFD73E6.1060506@gmx.de> <4EFD7C09.9050702@gmx.de> <4EFD8BCE.7010909@gmx.de> <4F052D2E.5050200@gondrom.org> <4F056553.9030409@gmx.de> <553F526C-4433-489B-80B5-4C29E5FB0DC4@vpnc.org> <4F13B7C2.5010603@extendedsubset.com> In-Reply-To: <4F13B7C2.5010603@extendedsubset.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: websec@ietf.org Subject: Re: [websec] Strict-Transport-Security syntax redux X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 08:26:45 -0000 On 2012-01-16 06:38, Marsh Ray wrote: > On 01/05/2012 11:50 AM, Anne van Kesteren wrote: >> On Thu, 05 Jan 2012 16:59:58 +0100, Paul Hoffman >> wrote: >>> >>> "We invented a header that your message-producing software must >>> special-case" is not a good way to get security. >> >> If the header-consuming software works that way, it might be the only >> way. What the right way to go here is kind of depends on how header >> field values are typically implemented in practice. I suspect it to be >> rather messy. > > How about: servers generating the header MUST use quoted-string whenever > quoted-string is necessary, otherwise they SHOULD use the token > production on Mondays, Wednesdays, and Fridays and they SHOULD use > quoted-string on Tuesday, Thursday, Saturday, and Sunday. > > Yes, I'm joking. But only half-way. I have a deep suspicion that > something like that might actually yield the best interoperability > overall. One thing worse than having arbitrarily-chosen redundant code > paths is having protocol grammar that's never ever used - until it's > needed. > ... Indeed. Test cases! Examples! (Section 5.2 really needs an example of a header field where an extension parameter using q-s is used) Best regards, Julian From julian.reschke@gmx.de Mon Jan 16 01:56:12 2012 Return-Path: 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 CB15121F84C3 for ; Mon, 16 Jan 2012 01:56:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.573 X-Spam-Level: X-Spam-Status: No, score=-103.573 tagged_above=-999 required=5 tests=[AWL=-0.974, BAYES_00=-2.599, 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 POa1mf7LBGwY for ; Mon, 16 Jan 2012 01:56:12 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id C433221F8478 for ; Mon, 16 Jan 2012 01:56:11 -0800 (PST) Received: (qmail invoked by alias); 16 Jan 2012 09:56:10 -0000 Received: from p3EE264D8.dip.t-dialin.net (EHLO [192.168.178.36]) [62.226.100.216] by mail.gmx.net (mp030) with SMTP; 16 Jan 2012 10:56:10 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/Mq0Js4WzMd0ppIy8ym+wqzFqFKWKAL+Wf7pDgcu CZ5r0MNYyK6ZNq Message-ID: <4F13F436.9040803@gmx.de> Date: Mon, 16 Jan 2012 10:56:06 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: =JeffH References: <4F139068.3030809@KingsMountain.com> <4F13DEA2.1000801@gmx.de> In-Reply-To: <4F13DEA2.1000801@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: IETF WebSec WG Subject: Re: [websec] of quoted-string header field param value syntax (was: Strict-Transport-Security syntax redux) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 09:56:12 -0000 On 2012-01-16 09:24, Julian Reschke wrote: > On 2012-01-16 03:50, =JeffH wrote: >> ... >> though, I remain curious as to why the STS parsing in Firefox & Chrome >> is apparently each a one-off and doesn't use the more generic HTTP >> header-field parsing routines that are available and which appear to >> handle quoted-string, arbitrary header field parameter ordering, etc. >> ... > > Well. One reason for that is that STS is indeed different from other > header fields (for instance, things like Content-Type, Expect, or > Cache-Control). > > To enable UAs to re-use code, you need to specify the header field so > that code can indeed be re-used. > ... Expanding on that... If STS used commas as delimiter (so use the list style), it could be compatible with Expect () and Prefer (), and would be similar to Cache-Control (minus legacy quirks). But it uses semicolon, which makes it more similar to things like Content-Type, Content-Disposition and Link (RFC 5988). These header fields however describe a single item plus parameters, not multiple items. Best regards, Julian From James.H.Manger@team.telstra.com Mon Jan 16 03:43:43 2012 Return-Path: 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 0908C21F85BB for ; Mon, 16 Jan 2012 03:43:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.606 X-Spam-Level: X-Spam-Status: No, score=0.606 tagged_above=-999 required=5 tests=[AWL=-1.507, BAYES_40=-0.185, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_41=0.6, RELAY_IS_203=0.994] 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 MYmhu0-JUUIy for ; Mon, 16 Jan 2012 03:43:42 -0800 (PST) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by ietfa.amsl.com (Postfix) with ESMTP id 5553021F85B9 for ; Mon, 16 Jan 2012 03:43:41 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.71,517,1320584400"; d="scan'208";a="58687080" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipocni.tcif.telstra.com.au with ESMTP; 16 Jan 2012 22:43:37 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6590"; a="48439680" Received: from wsmsg3752.srv.dir.telstra.com ([172.49.40.173]) by ipcani.tcif.telstra.com.au with ESMTP; 16 Jan 2012 22:43:37 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3752.srv.dir.telstra.com ([172.49.40.173]) with mapi; Mon, 16 Jan 2012 22:43:37 +1100 From: "Manger, James H" To: "jeff.hodges@kingsmountain.com" , "websec@ietf.org" , "ietf@adambarth.com" Date: Mon, 16 Jan 2012 22:43:35 +1100 Thread-Topic: [websec] of quoted-string header field param value syntax (was: Strict-Transport-Security syntax redux) Thread-Index: AczURBTp06ClPUVnR4Cr+UQsEDXPLA== Message-ID: <587AC02A-BB93-4260-BBEC-EBB649440F4E@team.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [websec] of quoted-string header field param value syntax (was: Strict-Transport-Security syntax redux) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 11:43:43 -0000 PiBhZ3JlZWQuIHRoYXQncyB3aHkgSSdtIGxlYW5pbmcgdG93YXJkcyBzcGVjJ2cgaXQgd2l0aCBx dW90ZWQtc3RyaW5nIGF0IHRoaXMgdGltZS4gSXQgZnV0dXJlLXByb29mcyB0aGUgc3BlYw0KDQpR dW90ZWQtc3RyaW5nIHByb3ZpZGVzIG5vICJmdXR1cmUtcHJvb2ZpbmciLiA8dG9rZW4+IHN1cHBv cnRzIGFib3V0IDc3IGNoYXJzOyA8cXVvdGVkLXN0cmluZz4gYWRkcyBhYm91dCAxOCBtb3JlIC0t IHRoZXJlIGFyZSBhbm90aGVyIDEwMCwwMDAgY2hhcnMgdG8gc3VwcG9ydCAoYW5kIGV2ZW4gbW9y ZSBjb2RlIHBvaW50cykgaWYgeW91IGFjdHVhbGx5IHdhbnQgZnV0dXJlLSBwcm9vZmluZy4NCg0K U3VwcG9ydGluZyBxdW90ZWQtc3RyaW5nIGlzIGFsbCBhYm91dCBwYXN0IGNvbXByb21pc2VzLiBJ dCBhZGRzIG5vIHZhbHVlIHRvIGEgbmV3IGhlYWRlci4NCg0KQ29uc2lzdGVuY3kgd2l0aCBvdGhl ciBoZWFkZXJzIGlzIHRoZW9yZXRpY2FsbHkgdmFsdWFibGUsIGJ1dCBjb25zaXN0ZW5jeSB3aXRo b3V0IHRoZSBsaW1pdHMgKG5vIHVuaWNvZGUuLi4pIGFuZCBiYWdnYWdlIChJU084ODQ5LTEuLi4p IG9mIHF1b3RlZC1zdHJpbmcgd291bGQgYmUgY29uc2lkZXJhYmx5IGJldHRlci4NCg0KLS0NCkph bWVzIE1hbmdlcg0K From julian.reschke@gmx.de Mon Jan 16 04:22:13 2012 Return-Path: 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 548E621F85AA for ; Mon, 16 Jan 2012 04:22:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.328 X-Spam-Level: X-Spam-Status: No, score=-103.328 tagged_above=-999 required=5 tests=[AWL=-1.329, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, 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 SqO-xK7tjvBC for ; Mon, 16 Jan 2012 04:22:13 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 7808F21F85A8 for ; Mon, 16 Jan 2012 04:22:12 -0800 (PST) Received: (qmail invoked by alias); 16 Jan 2012 12:22:09 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp014) with SMTP; 16 Jan 2012 13:22:09 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/gbahsxAHgxZ3AyitvhTi5InDWJfVWAoI0GF9D6E xhPJ81TT+AvYSA Message-ID: <4F14166A.4090102@gmx.de> Date: Mon, 16 Jan 2012 13:22:02 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "Manger, James H" References: <587AC02A-BB93-4260-BBEC-EBB649440F4E@team.telstra.com> In-Reply-To: <587AC02A-BB93-4260-BBEC-EBB649440F4E@team.telstra.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "websec@ietf.org" Subject: Re: [websec] of quoted-string header field param value syntax (was: Strict-Transport-Security syntax redux) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 12:22:13 -0000 On 2012-01-16 12:43, Manger, James H wrote: >> agreed. that's why I'm leaning towards spec'g it with quoted-string at this time. It future-proofs the spec > > Quoted-string provides no "future-proofing". supports about 77 chars; adds about 18 more -- there are another 100,000 chars to support (and even more code points) if you actually want future- proofing. > > Supporting quoted-string is all about past compromises. It adds no value to a new header. Well, it allows putting in ASCII characters not allowed otherwise, such as whitespace and delimiters such as ";", "," and double quotes. I agree it doesn't help with I18N. > ... Best regards, Julian From julian.reschke@gmx.de Mon Jan 16 06:05:53 2012 Return-Path: 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 81DF221F85F7 for ; Mon, 16 Jan 2012 06:05:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.567 X-Spam-Level: X-Spam-Status: No, score=-103.567 tagged_above=-999 required=5 tests=[AWL=-0.968, BAYES_00=-2.599, 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 boq8GXArLK5B for ; Mon, 16 Jan 2012 06:05:52 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 4CCB821F85F4 for ; Mon, 16 Jan 2012 06:05:52 -0800 (PST) Received: (qmail invoked by alias); 16 Jan 2012 14:05:49 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp069) with SMTP; 16 Jan 2012 15:05:49 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/kaDNQgP/ktCkgu4SMvdqsyBZGv+J8LDGR4Dd85K BSxzNZc9GBWmfl Message-ID: <4F142EB4.2000705@gmx.de> Date: Mon, 16 Jan 2012 15:05:40 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: =JeffH References: <4F139068.3030809@KingsMountain.com> In-Reply-To: <4F139068.3030809@KingsMountain.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: IETF WebSec WG Subject: Re: [websec] of quoted-string header field param value syntax (was: Strict-Transport-Security syntax redux) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 14:05:53 -0000 On 2012-01-16 03:50, =JeffH wrote: > ... > though, I remain curious as to why the STS parsing in Firefox & Chrome > is apparently each a one-off and doesn't use the more generic HTTP > header-field parsing routines that are available and which appear to > handle quoted-string, arbitrary header field parameter ordering, etc. > ... -> Best regards, Julian From stpeter@stpeter.im Tue Jan 17 09:08:00 2012 Return-Path: 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 DE00B1F0C44 for ; Tue, 17 Jan 2012 09:08:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, 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 SGOgkyLWHSw0 for ; Tue, 17 Jan 2012 09:08:00 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA1411E8075 for ; Tue, 17 Jan 2012 09:08:00 -0800 (PST) Received: from dhcp-64-101-72-243.cisco.com (unknown [64.101.72.243]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7A2CE40058 for ; Tue, 17 Jan 2012 10:17:19 -0700 (MST) Message-ID: <4F15AAF3.2040404@stpeter.im> Date: Tue, 17 Jan 2012 10:08:03 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: IETF WebSec WG X-Enigmail-Version: 1.3.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [websec] preparing for Paris X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 17:08:01 -0000 Just a friendly reminder that WG sessions for IETF 83 need to be scheduled less than 2 weeks from now: http://www.ietf.org/meeting/cutoff-dates-2012.html#IETF83 Peter -- Peter Saint-Andre http://stpeter.im/ From ynir@checkpoint.com Tue Jan 17 09:20:17 2012 Return-Path: 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 1660621F85B6 for ; Tue, 17 Jan 2012 09:20:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.472 X-Spam-Level: X-Spam-Status: No, score=-10.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 dVYV8r8DhakA for ; Tue, 17 Jan 2012 09:20:16 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 24AE821F8579 for ; Tue, 17 Jan 2012 09:20:15 -0800 (PST) X-CheckPoint: {4F15AB10-0-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q0HHKDN8001473; Tue, 17 Jan 2012 19:20:13 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 17 Jan 2012 19:20:04 +0200 From: Yoav Nir To: Peter Saint-Andre Date: Tue, 17 Jan 2012 19:20:03 +0200 Thread-Topic: [websec] preparing for Paris Thread-Index: AczVPECQu1MKO5hyRnOujPKAe7ubPw== Message-ID: <77BE5D30-52CA-4D4D-A0B3-A7DB498656EC@checkpoint.com> References: <4F15AAF3.2040404@stpeter.im> In-Reply-To: <4F15AAF3.2040404@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF WebSec WG Subject: Re: [websec] preparing for Paris X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 17:20:17 -0000 I believe that Alexey has requested a session on 19-Dec. On Jan 17, 2012, at 7:08 PM, Peter Saint-Andre wrote: > Just a friendly reminder that WG sessions for IETF 83 need to be > scheduled less than 2 weeks from now: >=20 > http://www.ietf.org/meeting/cutoff-dates-2012.html#IETF83 >=20 > Peter From tobias.gondrom@gondrom.org Tue Jan 17 20:24:36 2012 Return-Path: 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 7B2C721F8486 for ; Tue, 17 Jan 2012 20:24:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.778 X-Spam-Level: X-Spam-Status: No, score=-96.778 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 zvGOHVLJ3wNp for ; Tue, 17 Jan 2012 20:24:36 -0800 (PST) Received: from lvps83-169-7-107.dedicated.hosteurope.de (www.gondrom.org [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD0B21F8691 for ; Tue, 17 Jan 2012 20:24:35 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=JgVl/u5zpMwG0Br82F7VbdEPpxpKsqOe1zUXs9MerDBo9mfXdfh7UarwnKZtdDTBospQQGf938Bhhqga6W4mCzlTsjV/lRRsGWBZ4UybxhM71Xjw0KRbHAp9m0JE/8iW; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 13364 invoked from network); 18 Jan 2012 05:23:51 +0100 Received: from d1-162-57-143-118-on-nets.com (HELO ?10.8.38.105?) (118.143.57.162) by www.gondrom.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 18 Jan 2012 05:23:51 +0100 Message-ID: <4F164953.9010400@gondrom.org> Date: Wed, 18 Jan 2012 12:23:47 +0800 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: websec@ietf.org References: <4F15AAF3.2040404@stpeter.im> <77BE5D30-52CA-4D4D-A0B3-A7DB498656EC@checkpoint.com> In-Reply-To: <77BE5D30-52CA-4D4D-A0B3-A7DB498656EC@checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [websec] preparing for Paris X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 04:24:36 -0000 Hello, yes, we already had the websec slot scheduled for IETF83 in Paris (duration 2 hours). We will work on the agenda in the coming 4-6 weeks. To all authors planning for a new draft version, please consider to publish the next version rather earlier than later, so the WG has more time for pre-meeting reading and discussions on the mailing-list. By the latest, the cutoff dates for new draft versions are: (http://www.ietf.org/meeting/cutoff-dates-2012.html#IETF83) - 2012-02-27 (Monday): Working Group Chair approval for initial document (Version -00) submissions appreciated by 17:00 PT (UTC -8). - 2012-03-02 (Friday): Final agenda to be published. - 2012-03-05 (Monday): Internet Draft Cut-off for initial document (-00) submission by 17:00 PT (UTC -8), upload using IETF ID Submission Tool. - 2012-03-12 (Monday): Internet Draft final submission cut-off by 17:00 PT (UTC -7), upload using IETF ID Submission Tool. Best regards, Tobias (chair of websec) On 18/01/12 01:20, Yoav Nir wrote: > I believe that Alexey has requested a session on 19-Dec. > > On Jan 17, 2012, at 7:08 PM, Peter Saint-Andre wrote: > >> Just a friendly reminder that WG sessions for IETF 83 need to be >> scheduled less than 2 weeks from now: >> >> http://www.ietf.org/meeting/cutoff-dates-2012.html#IETF83 >> >> Peter > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From ian@hixie.ch Tue Jan 17 13:32:05 2012 Return-Path: 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 5674111E80AF for ; Tue, 17 Jan 2012 13:32:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 1-3YKsb5tGsP for ; Tue, 17 Jan 2012 13:32:04 -0800 (PST) Received: from homiemail-a50.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by ietfa.amsl.com (Postfix) with ESMTP id CE1E111E80A2 for ; Tue, 17 Jan 2012 13:32:04 -0800 (PST) Received: from homiemail-a50.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a50.g.dreamhost.com (Postfix) with ESMTP id 2C18B6F8059; Tue, 17 Jan 2012 13:32:04 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=hixie.ch; h=date:from:to:cc :subject:in-reply-to:message-id:references:mime-version: content-type; q=dns; s=hixie.ch; b=Lkf4gBBoF7H+uAB8LCo/NZRWZ5jVq dBx3fRZl5Jl+LKiq0fqO//4H1ZbaiS/JmIB/IPXeJ+6vNkej3nra899X8tZQllm9 f44vF9eRbNbhNRirH+yA8HZRi1wZjmSnkuA6uijtk9jnqLW1Oe1yniuVJHX3W8vg wGp9ofskkXlvdk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hixie.ch; h=date:from:to :cc:subject:in-reply-to:message-id:references:mime-version: content-type; s=hixie.ch; bh=bzOqg1wp9ds6gY8RBU6KocgRJUY=; b=jx2 HPd6L/k62bJ5wiU4K9ScPe2yzsggwAIeTNOgP6wgTH4K3Il7vxCFdZytb0ePn9OO 2qTpKxFjBoRFz3BgD5bpMHis4cnjz2IaEjOS9bW8MLr1YRidZ4hQYXrAZwg6Qr4B Ut4qZCf2huEkLdoxzKcY3o6jkVW8jfEU6DYDsTN0= Received: from ps20323.dreamhostps.com (ps20323.dreamhost.com [69.163.222.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: internal@index.hixie.ch) by homiemail-a50.g.dreamhost.com (Postfix) with ESMTPSA id 205BD6F8058; Tue, 17 Jan 2012 13:32:04 -0800 (PST) Date: Tue, 17 Jan 2012 21:32:03 +0000 (UTC) From: Ian Hickson To: Willy Tarreau In-Reply-To: <20120115211702.GJ32205@1wt.eu> Message-ID: References: <20120115195120.GG32205@1wt.eu> <20120115204154.GH32205@1wt.eu> <20120115211702.GJ32205@1wt.eu> Content-Language: en-GB-hixie Content-Style-Type: text/css MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Tue, 17 Jan 2012 20:25:28 -0800 Cc: websec@ietf.org Subject: Re: [websec] Minor feedback on draft-ietf-websec-mime-sniff-03 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 21:32:05 -0000 On Sun, 15 Jan 2012, Willy Tarreau wrote: > > For instance, if I get a file advertised like this : > > Content-type: text/plain; charset=us-ascii > > then it will not be interpreted as text/plain What makes you think that? As far as I can tell, the algorithm given in the spec requires that such a file be treated as text/plain. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From w@1wt.eu Tue Jan 17 13:39:55 2012 Return-Path: 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 0122011E80BC for ; Tue, 17 Jan 2012 13:39:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[AWL=-2.167, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] 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 et6zGToMRg4T for ; Tue, 17 Jan 2012 13:39:54 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 3D22911E80AF for ; Tue, 17 Jan 2012 13:39:54 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q0HLdn2k020371; Tue, 17 Jan 2012 22:39:49 +0100 Date: Tue, 17 Jan 2012 22:39:48 +0100 From: Willy Tarreau To: Ian Hickson Message-ID: <20120117213948.GB20322@1wt.eu> References: <20120115195120.GG32205@1wt.eu> <20120115204154.GH32205@1wt.eu> <20120115211702.GJ32205@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Mailman-Approved-At: Tue, 17 Jan 2012 20:25:28 -0800 Cc: websec@ietf.org Subject: Re: [websec] Minor feedback on draft-ietf-websec-mime-sniff-03 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 21:39:55 -0000 Hi Ian, On Tue, Jan 17, 2012 at 09:32:03PM +0000, Ian Hickson wrote: > On Sun, 15 Jan 2012, Willy Tarreau wrote: > > > > For instance, if I get a file advertised like this : > > > > Content-type: text/plain; charset=us-ascii > > > > then it will not be interpreted as text/plain > > What makes you think that? As far as I can tell, the algorithm given in > the spec requires that such a file be treated as text/plain. You're right, as I said in the second mail following this one, I found what I misread in the algorithm. In short, I thought we'd jump to the content analysis if the header did not match these exact forms, which is not the case, I conflated official-type and sniffed-type in the text if my memory serves me right. Regards, Willy From Jeff.Hodges@KingsMountain.com Fri Jan 20 10:41:56 2012 Return-Path: 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 DC02621F84D9 for ; Fri, 20 Jan 2012 10:41:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.181 X-Spam-Level: X-Spam-Status: No, score=-100.181 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, 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 B0RbypwWViaa for ; Fri, 20 Jan 2012 10:41:56 -0800 (PST) Received: from oproxy1-pub.bluehost.com (oproxy1.bluehost.com [IPv6:2605:dc00:100:2::a1]) by ietfa.amsl.com (Postfix) with SMTP id 6EAFB21F8518 for ; Fri, 20 Jan 2012 10:41:56 -0800 (PST) Received: (qmail 23553 invoked by uid 0); 20 Jan 2012 18:35:13 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy1.bluehost.com with SMTP; 20 Jan 2012 18:35:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=mUy2U1BpfNYMDd5EKhchuMU7oiyAGNCTZ2DMQcshBKg=; b=KTPCG/+XPr3LmN6yrlI5X/qLJkbTFTEZec8zcYn0YZh/PunejMofSBUHZfSVD8NCtD5t5ndJbD7NALn4pwOS7y2tLeTydDxEoafdXy4BPXt+BkBC7NQnHTEei4Vie2JL; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.136.101]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1RoJIu-0000BZ-TG; Fri, 20 Jan 2012 11:35:12 -0700 Message-ID: <4F19B3DF.5050402@KingsMountain.com> Date: Fri, 20 Jan 2012 10:35:11 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Apps Discuss , IETF WebSec WG , RAI Discuss , Internet Area Discuss Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: [websec] TheRightKey@ietf.org -- next gen broad user-facing internet trust infrastructure discussion X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 18:41:57 -0000 this list, TheRightKey@ietf.org -- where next gen broad user-facing internet trust infrastructure is being discussed, was originally advertised to SAAG, PKIX, TLS, and DANE. Sending to these lists in case any potentially interested parties missed it. HTH, =JeffH ------- Forwarded Message Subject: New Non-WG Mailing List: therightkey Date: Fri, 13 Jan 2012 10:23:58 -0800 (PST) From: IETF Secretariat To: IETF Announcement list CC: therightkey@ietf.org, turners@ieca.com, stephen.farrell@cs.tcd.ie A new IETF non-working group email list has been created. List address: therightkey@ietf.org Archive: http://www.ietf.org/mail-archive/web/therightkey/ To subscribe: https://www.ietf.org/mailman/listinfo/therightkey Purpose: A number of people are interested in discussing proposals that have been developed in response to recent attacks on the Internet security infrastructure, in particular those that affected sites using TLS and other protocols relying on PKI. This list is intended for discussion of those proposals and how they might result in potential work items for the IETF. One short-term outcome may be the holding of a non-wg-forming BoF at IETF-83. For additional information, please contact the list administrators. ------- End of Forwarded Message From trac+websec@trac.tools.ietf.org Fri Jan 20 15:37:44 2012 Return-Path: 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 E352621F8565 for ; Fri, 20 Jan 2012 15:37:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 MrIfgGLXsxPh for ; Fri, 20 Jan 2012 15:37:42 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 451C721F84EE for ; Fri, 20 Jan 2012 15:37:41 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RoO1I-0001O6-0F; Fri, 20 Jan 2012 18:37:20 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "websec issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com X-Trac-Project: websec Date: Fri, 20 Jan 2012 23:37:19 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/websec/trac/ticket/35 Message-ID: <070.f70ee4d09481ba2840593de66b0fd5f4@trac.tools.ietf.org> X-Trac-Ticket-ID: 35 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com, websec@ietf.org X-SA-Exim-Mail-From: trac+websec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120120233742.451C721F84EE@ietfa.amsl.com> Resent-Date: Fri, 20 Jan 2012 15:37:41 -0800 (PST) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: [websec] #35: HSTS spec could be more clear about UA behavior behind proxies X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 23:37:45 -0000 #35: HSTS spec could be more clear about UA behavior behind proxies UA won't note a well-behaving but unknown HSTS Host as an HSTS Host if the UA is behind a proxy such that secure transport warnings/errors exist. overall behavior and design rationale could be better explained in spec. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-websec-strict-transport- jeff.hodges@… | sec@… Type: defect | Status: new Priority: minor | Milestone: Component: strict- | Version: transport-sec | Keywords: Severity: Active WG | Document | -------------------------+------------------------------------------------- Ticket URL: websec From derhoermi@gmx.net Fri Jan 20 15:49:16 2012 Return-Path: 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 94E2221F859A for ; Fri, 20 Jan 2012 15:49:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.235 X-Spam-Level: X-Spam-Status: No, score=-3.235 tagged_above=-999 required=5 tests=[AWL=-0.636, BAYES_00=-2.599] 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 pnFfQKt-4PeL for ; Fri, 20 Jan 2012 15:49:14 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 84F9621F8533 for ; Fri, 20 Jan 2012 15:49:13 -0800 (PST) Received: (qmail invoked by alias); 20 Jan 2012 23:49:11 -0000 Received: from dslb-094-223-223-057.pools.arcor-ip.net (EHLO HIVE) [94.223.223.57] by mail.gmx.net (mp072) with SMTP; 21 Jan 2012 00:49:11 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1+iMV0lAsGi7VStKJBhQ8wInPJV60pkSd5hDsLwOQ oeH07m2CO0n7Ss From: Bjoern Hoehrmann To: Julian Reschke Date: Sat, 21 Jan 2012 00:49:25 +0100 Message-ID: <41vjh7dqmg8kdaa6bkg7v7jgvuuc2ffvo2@hive.bjoern.hoehrmann.de> References: <4EFD73E6.1060506@gmx.de> <4EFD7C09.9050702@gmx.de> <4EFD8BCE.7010909@gmx.de> <4F052D2E.5050200@gondrom.org> <4F0A372B.2070407@gmx.de> In-Reply-To: <4F0A372B.2070407@gmx.de> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: websec@ietf.org Subject: Re: [websec] Strict-Transport-Security syntax redux X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 23:49:16 -0000 * Julian Reschke wrote: >On 2012-01-09 01:25, Adam Barth wrote: >> On Sun, Jan 8, 2012 at 4:10 PM, Bjoern Hoehrmann wrote: >>> It seems to me that all headers defined in RFC 2616 that allow para- >>> meteter lists of the `;name=value` form allow the value to be a quoted >>> string. >> >> This header isn't defined in RFC 2616 and many headers defined outside >> of RFC 2616 don't use quoted-string. >> ... > >In name/value pairs? Example? > >(As a matter of fact, not all header fields in 2616 are as consistent as >they should, but that's not an excuse for not trying to do better with >new header fields) (FWIW, when I wrote my comment, I picked the RFCs that match /rfc2616/ and then filtered the remaining ones for /";"/ and then quickly scanned through the remaining ones, and only the `Cookie` RFCs stood out as ex- amples where this is not the case; not all headers are defined in RFCs, and my ad-hoc method would not necessarily find all instances in RFCS, but there were a number that matched RFC2616 in this, so I found it reasonable to make the argument. And no counter-examples have been pro- vided since, so it is probably fair to assume that this is the dominant pattern.) -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From trac+websec@trac.tools.ietf.org Wed Jan 25 10:16:55 2012 Return-Path: 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 9F82C21F85E9 for ; Wed, 25 Jan 2012 10:16:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 twctpiMupXAI for ; Wed, 25 Jan 2012 10:16:55 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 2F99321F85EA for ; Wed, 25 Jan 2012 10:16:54 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1Rq7Og-00024s-RL; Wed, 25 Jan 2012 13:16:38 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "websec issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com X-Trac-Project: websec Date: Wed, 25 Jan 2012 18:16:38 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/33#comment:1 Message-ID: <085.d884f3e1d04a4e98919c52cc9395f93f@trac.tools.ietf.org> References: <070.dc46fc06c043a8103369b4b2f8b4d471@trac.tools.ietf.org> X-Trac-Ticket-ID: 33 In-Reply-To: <070.dc46fc06c043a8103369b4b2f8b4d471@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com, websec@ietf.org X-SA-Exim-Mail-From: trac+websec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120125181655.2F99321F85EA@ietfa.amsl.com> Resent-Date: Wed, 25 Jan 2012 10:16:54 -0800 (PST) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: Re: [websec] #33: HSTS: quoted-string grammar in (extension) directives ? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 18:16:55 -0000 #33: HSTS: quoted-string grammar in (extension) directives ? Comment (by jeff.hodges@…): Subsequent additional discussion is in thread rooted here.. [websec] of quoted-string header field param value syntax (was: Strict- Transport-Security syntax redux) https://www.ietf.org/mail-archive/web/websec/current/msg00975.html -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-websec-strict- jeff.hodges@… | transport-sec@… Type: defect | Status: new Priority: major | Milestone: Component: strict- | Version: transport-sec | Resolution: Severity: Active WG | Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: websec From trac+websec@trac.tools.ietf.org Wed Jan 25 10:23:46 2012 Return-Path: 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 840FB21F85F1 for ; Wed, 25 Jan 2012 10:23:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 maS2XD9py3nu for ; Wed, 25 Jan 2012 10:23:46 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 5E78D21F85E9 for ; Wed, 25 Jan 2012 10:23:33 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1Rq7VH-0005R7-P1; Wed, 25 Jan 2012 13:23:27 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "websec issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com X-Trac-Project: websec Date: Wed, 25 Jan 2012 18:23:27 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/36 Message-ID: <070.8f650790271f76d19cdc48904c5eb755@trac.tools.ietf.org> X-Trac-Ticket-ID: 36 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com, websec@ietf.org X-SA-Exim-Mail-From: trac+websec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120125182333.5E78D21F85E9@ietfa.amsl.com> Resent-Date: Wed, 25 Jan 2012 10:23:33 -0800 (PST) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: [websec] #36: HSTS: fixup references X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 18:23:46 -0000 #36: HSTS: fixup references see.. [websec] draft-ietf-websec-strict-transport-sec-03 reference nits, Julian Reschke https://www.ietf.org/mail-archive/web/websec/current/msg00919.html -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-websec-strict-transport- jeff.hodges@… | sec@… Type: defect | Status: new Priority: minor | Milestone: Component: strict- | Version: transport-sec | Keywords: Severity: Active WG | Document | -------------------------+------------------------------------------------- Ticket URL: websec From presnick@qualcomm.com Wed Jan 25 14:48:30 2012 Return-Path: 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 AE62B21F8574 for ; Wed, 25 Jan 2012 14:48:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.557 X-Spam-Level: X-Spam-Status: No, score=-106.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, 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 IpQ91BIvgEjP for ; Wed, 25 Jan 2012 14:48:29 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 7DCCB21F8573 for ; Wed, 25 Jan 2012 14:48:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1327531709; x=1359067709; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4F208612.9040006@qualcomm.com>|Date:=20We d,=2025=20Jan=202012=2016:45:38=20-0600|From:=20Pete=20Re snick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20=3DJeffH=20|CC:=20Paul=20Hoffman=20,=20IETF=20WebSec=20WG=20|Subject:=20R e:=20wrt=20IDN=20processing-related=20security=20consider ations=20for=20draft-ietf-websec-strict-transport-sec |References:=20<4EF41A5A.2080109@KingsMountain.com> |In-Reply-To:=20<4EF41A5A.2080109@KingsMountain.com> |Content-Type:=20text/plain=3B=20charset=3D"ISO-8859-1" =3B=20format=3Dflowed|Content-Transfer-Encoding:=207bit |X-Originating-IP:=20[172.30.48.1]; bh=Sy4r9kjGnE8uaWgkx6ZnUDZNBLo+XSNHMc+8Js00OJM=; b=NkrVPZkCzqTLqyCCnMZ5Fo54Py+rKH0NeEl+cozVmeebO1ZnAq0KvOzb XDp49O4gcbpxyPWWWuLvwqK+MnoGcqvgNGOL7uQawAS5arysNyfuvmMVk iAfjYAyJaKSQilsfvXEMaF2dShz794KJax+O7UZe0VAKhzswSMfl1HK9x M=; X-IronPort-AV: E=McAfee;i="5400,1158,6600"; a="157945164" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP; 25 Jan 2012 14:48:29 -0800 X-IronPort-AV: E=Sophos;i="4.71,568,1320652800"; d="scan'208";a="245201158" Received: from nasanexhc05.na.qualcomm.com ([172.30.48.2]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 25 Jan 2012 14:48:29 -0800 Received: from Macintosh-4.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.1.339.1; Wed, 25 Jan 2012 14:45:40 -0800 Message-ID: <4F208612.9040006@qualcomm.com> Date: Wed, 25 Jan 2012 16:45:38 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: =JeffH References: <4EF41A5A.2080109@KingsMountain.com> In-Reply-To: <4EF41A5A.2080109@KingsMountain.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] X-Mailman-Approved-At: Wed, 25 Jan 2012 18:17:49 -0800 Cc: IETF WebSec WG , Paul Hoffman Subject: Re: [websec] wrt IDN processing-related security considerations for draft-ietf-websec-strict-transport-sec X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 22:48:30 -0000 A while back, Jeff Cc'ed me on this message and I promised to give a little feedback. I failed. Here is an attempt, just in case it makes a difference. Since this was posted so long ago, I'll leave all of his text and answer inline. Scroll down to see my comments: On 12/23/11 12:06 AM, =JeffH wrote: > PaulH and PeteR raised some concerns in Taipei over the IDNA-related > language in draft-ietf-websec-strict-transport-sec. > > This message is a reminder to them and an instigator to others for > further review specifically of the IDN aspects of the HSTS spec. > > My initial request for review and summation of the pertinent language, > as sent to the na-update@ list, is here (and attached below).. > > IDN processing-related security considerations for > draft-ietf-websec-strict-transport-sec > > http://www.alvestrand.no/pipermail/idna-update/2011-September/007140.html > > > The above-cited message presaged the -03 HSTS draft, which is > presently (for a little while) current, and is here.. > > HTTP Strict Transport Security (HSTS) > > > > Please review and comment. Thanks, > > =JeffH > ------ > > From: =JeffH > Date: Thu, 29 Sep 2011 20:07:15 -0700 > To: IETF IDNA Update WG > Cc: Pete Resnick , websec-chairs@tools.ietf.org, > Peter Saint-Andre , Adam Barth > > > Hi, > > In working towards completion of.. > > HTTP Strict Transport Security (HSTS) > > > ..and.. > > The Web Origin Concept > https://tools.ietf.org/html/draft-ietf-websec-origin > > ..we are attempting to address the proper way to reference IDNA2008 and > IDNA2003 in terms of stipulating comparisons of domain names (that may > or may > not be IDNs). > > In discussions with our ADs and a few IDNA-literate folks, we've been > informed > that the IDNA-specific language in the recently-released RFC6265 HTTP > State > Management spec isn't quite up to the standards they would like to see > at this > time. > > Thus I've performed some surgery on > draft-ietf-websec-strict-transport-sec and > have included below the specific section portions that are IDNA > specific (this > is from my working copy which isn't quite yet overall ready tonight to > submit > as -03). > > The key context to keep in mind when reviewing the below is that the key > "processing" -- essentially a domain name comparison -- will occur > deep within > the bowels of HTTP clients, well along the processing pipeline for > URIs, and > presumably after IDNA-canonicalization and requisite > validation/testing has > occurred. However, the guidance we've received is that given the > complexities > and subtleties of IDNA processing and considerations, our specs really > should > be more explicit about the foregoing assumption(s) and the downside > risks if > the requisite validation/testing is not performed. > > With that context in mind, thoughts on the below are solicited. > Apologies for > just having these excerpts at this time, but I ought to have > -websec-strict-transport-sec-03 submitted in the next few days at most. > > thanks, > > =JeffH > . > . > . > 7. User Agent Processing Model > > This section describes the HTTP Strict Transport Security processing > model for UAs. There are several facets to the model, enumerated by > the following subsections. > > This processing model assumes that the UA implements IDNA2008 > [RFC5890], or possibly IDNA2003 [RFC3490], as noted in Section 11 > "Internationalized Domain Names for Applications (IDNA): Dependency > and Migration". It also assumes that all domain names manipulated in > this specification's context are already IDNA-canonicalized as > outlined in Section 8 "Domain Name IDNA-Canonicalization" prior to > the processing specified in this section. > > The above assumptions mean that this processing model also > specifically assumes that appropriate IDNA and Unicode validations > and character list testing have occured on the domain names, in > conjunction with their IDNA-canonicalization, prior to the processing > specified in this section. See the IDNA-specific security > considerations in Section 13.2 "Internationalized Domain Names" for > rationale and further details. I think the above is just fine and gives implementers the correct instructions. > 8. Domain Name IDNA-Canonicalization > > An IDNA-canonicalized domain name is the string generated by the > following algorithm, whose input must be a valid Unicode-encoded (in > NFC form [Unicode6]) string-serialized domain name: > > 1. Convert the domain name to a sequence of individual domain name > label strings. > > 2. When implementing IDNA2008, convert each label that is not a Non- > Reserved LDH (NR-LDH) label, to an A-label. See Section 2.3.2 of > [RFC5890] for definitions of the former and latter, refer to > Sections 5.3 through 5.5 of [RFC5891] for the conversion > algorithm and requisite input validation and character list > testing procedures. > > Otherwise, when implementing IDNA2003, convert each label using > the "ToASCII" conversion in Section 4 of [RFC3490] (see also the > definition of "equivalence of labels" in Section 2 of the latter > specification). > > 3. Concatenate the resulting labels, separating each label from the > next with (".") a %x2E character. > > See also Section 11 "Internationalized Domain Names for Applications > (IDNA): Dependency and Migration" and Section 13.2 "Internationalized > Domain Names" of this specification for further details and > considerations. Again, the above is fine. > 11. Internationalized Domain Names for Applications (IDNA): Dependency > and Migration > > Textual domain names on the modern Internet may contain one or more > "internationalized" domain name labels. Such domain names are > referred to as "internationalized domain names" (IDNs). The > specification suites defining IDNs and the protocols for their use > are named "Internationalized Domain Names for Applications (IDNA)". > At this time, there are two such specification suites: IDNA2008 > [RFC5890] and its predecessor IDNA2003 [RFC3490]. > > IDNA2008 obsoletes IDNA2003, but there are differences between the > two specifications, and thus there can be differences in processing > (e.g. converting) domain name labels that have been registered under > one from those registered under the other. There will be a > transition period of some time during which IDNA2003-based domain > name labels will exist in the wild. User agents SHOULD implement > IDNA2008 [RFC5890] and MAY implement [RFC5895] (see also Section 7 of > [RFC5894]) or [UTS46] in order to facilitate their IDNA transition. > If a user agent does not implement IDNA2008, the user agent MUST > implement IDNA2003. I really, truly wish we could avoid all reference to 5895 and UTS46. (And this comes from a co-author of the former.) Basically, those documents are about taking user (or other sorts of "unwashed" input) and doing something 'magic' before handing it to something that expects proper IDNs. Really, I'd like this kind of protocol document to say, "What goes is this field is something that is properly pre-processed by whatever handed it to us and if it's bogus, we're not going to do anything to 'help' it." But I understand that this may be "happy thoughts". If you really can't avoid talking about user input processing in this document, I will hold my nose and say no more about it. > 13.2. Internationalized Domain Names > > Internet security relies in part on the DNS and the domain names it > hosts. Domain names are used by users to identify and connect to > Internet hosts and other network resources. For example, Internet > security is compromised if a user entering an internationalized > domain name (IDN) is connected to different hosts based on different > interpretations of the IDN. > > The processing models specified in this specification assume that the > domain names they manipulate are IDNA-canonicalized, and that the > canonicalization process correctly performed all appropriate IDNA and > Unicode validations and character list testing per the requisite > specifications (e.g., as noted in Section 8 "Domain Name IDNA- > Canonicalization"). These steps are necessary in order to avoid > various potentially compromising situations. > > In brief, some examples of issues that could stem from lack of > careful and consistent Unicode and IDNA validations are things such > as unexpected processing exceptions, truncation errors, and buffer > overflows, as well as false-positive and/or false-negative domain > name matching results. Any of the foregoing issues could possibly be > leveraged by attackers in various ways. > > Additionally, IDNA2008 [RFC5890] differs from IDNA2003 [RFC3490] in > terms of disallowed characters and character mapping conventions. > This situation can also lead to false-positive and/or false-negative > domain name matching results, resulting in, for example, users > possibly communicating with unintended hosts, or not being able to > reach intended hosts. > > For details, refer to the Security Considerations sections of > [RFC5890], [RFC5891], and [RFC3490], as well as the specifications > they normatively reference. Additionally, [RFC5894] provides > detailed background and rationale for IDNA2008 in particular, as well > as IDNA and its issues in general, and should be consulted in > conjunction with the former specifications. Peachy. I hope that helps. pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From internet-drafts@ietf.org Fri Jan 27 16:31:56 2012 Return-Path: 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 14FB321F85FD; Fri, 27 Jan 2012 16:31:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, 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 DGTGap0ogN+b; Fri, 27 Jan 2012 16:31:54 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5298321F85A5; Fri, 27 Jan 2012 16:31:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120128003154.4208.46470.idtracker@ietfa.amsl.com> Date: Fri, 27 Jan 2012 16:31:54 -0800 Cc: websec@ietf.org Subject: [websec] I-D Action: draft-ietf-websec-strict-transport-sec-04.txt X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2012 00:31:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Security Working Group of the IET= F. Title : HTTP Strict Transport Security (HSTS) Author(s) : Jeff Hodges Collin Jackson Adam Barth Filename : draft-ietf-websec-strict-transport-sec-04.txt Pages : 43 Date : 2012-01-27 This specification defines a mechanism enabling Web sites to declare themselves accessible only via secure connections, and/or for users to be able to direct their user agent(s) to interact with given sites only over secure connections. This overall policy is referred to as HTTP Strict Transport Security (HSTS). The policy is declared by Web sites via the Strict-Transport-Security HTTP response header field, and/or by other means, such as user agent configuration, for example. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-websec-strict-transport-sec-= 04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-websec-strict-transport-sec-0= 4.txt From Jeff.Hodges@KingsMountain.com Fri Jan 27 16:56:39 2012 Return-Path: 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 5391821F8572 for ; Fri, 27 Jan 2012 16:56:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.181 X-Spam-Level: X-Spam-Status: No, score=-100.181 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, 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 66PrWNT0kpyH for ; Fri, 27 Jan 2012 16:56:38 -0800 (PST) Received: from oproxy3-pub.bluehost.com (oproxy3.bluehost.com [IPv6:2605:dc00:100:2::a3]) by ietfa.amsl.com (Postfix) with SMTP id 34F8621F8557 for ; Fri, 27 Jan 2012 16:56:38 -0800 (PST) Received: (qmail 30880 invoked by uid 0); 28 Jan 2012 00:56:37 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy3.bluehost.com with SMTP; 28 Jan 2012 00:56:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=8yTGNhBd3zDgkqTOOt3xkwoJD5d1jMA1YBYQhErnz1I=; b=DyYI7pvBkVzeH/V/b5yXUAtfdQPvHHvjPpqW9uJikl7Xravdy7X4zdTv3NqzU7NiJwUoJt93AREB5siKC7n9yaWEjQaUUN2pFBo6CyPO2VZ6V/DzQ/5YPLl0fKMca1kr; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.137.138]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1Rqwar-0002eV-Mj for websec@ietf.org; Fri, 27 Jan 2012 17:56:37 -0700 Message-ID: <4F2347C5.8090406@KingsMountain.com> Date: Fri, 27 Jan 2012 16:56:37 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: IETF WebSec WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: [websec] new rev: draft-ietf-websec-strict-transport-sec-04 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2012 00:56:39 -0000 New rev: http://www.ietf.org/internet-drafts/draft-ietf-websec-strict-transport-sec-04.txt With this rev, all issue tickets are now nominally addressed. Full change log below, and full -04 announcement message at end. Changes from -01 to -02 address: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12 Changes from -02 to -03 address: 14, 26, 27 Changes from -03 to -04 address: 13, 14, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36 full issue ticket list for strict-transport-sec: Diff from previous version: http://tools.ietf.org/rfcdiff?url2=draft-ietf-websec-strict-transport-sec-04 In a separate message I'll propose a workflow for managing websec issue tickets. =JeffH ============================================================== Appendix D. Change Log D.1. For draft-ietf-websec-strict-transport-sec Changes from -03 to -04: 1. Clarified that max-age=0 will cause UA to forget a known HSTS host, and more generally clarified that the "freshest" info from the HSTS host is cached, and thus HSTS hosts are able to alter the cached max-age in UAs. This addresses issue ticket #13. 2. Updated section on "Constructing an Effective Request URI" to remove remaining reference to RFC3986 and reference RFC2616 instead. Further addresses issue ticket #14. 3. Addresses further ABNF issues noted in comment:1 of issue ticket #27. 4. Reworked the introduction to clarify the denotation of "HSTS policy" and added the new Appendix B summarizing the primary characteristics of HSTS Policy and Same-Origin Policy, and identifying their differences. Added ref to [RFC4732]. This addresses issue ticket #28. 5. Reworked language in Section 2.3.1.3. wrt "mixed content", more clearly explain such vulnerability, disambiguate "mixed content" in web security context from its usage in markup language context. This addresses issue ticket #29. 6. Expanded Denial of Service discussion in Security Considerations. Added refs to [RFC4732] and [CWE-113]. This addresses issue ticket #30. 7. Mentioned in prose the case-insensitivity of directive names. This addresses issue ticket #31. 8. Added Section 10.3 "Implications of includeSubDomains". This addresses issue ticket #32. 9. Further refines text and ABNF definitions of STS header field directives. Retains use of quoted-string in directive grammar. This addresses issue ticket #33. 10. Added Section 14.7 "Creative Manipulation of HSTS Policy Store", including reference to [WebTracking]. This addresses issue ticket #34. 11. Added Section 14.1 "Ramifications of HSTS Policy Establishment only over Error-free Secure Transport" and made some accompanying editorial fixes in some other sections. This addresses issue ticket #35. 12. Refined references. Cleaned out un-used ones, updated to latest RFCs for others, consigned many to Informational. This addresses issue ticket #36. 13. Fixed-up some inaccuracies in the "Changes from -02 to -03" section. Changes from -02 to -03: 1. Updated section on "Constructing an Effective Request URI" to remove references to RFC3986. Addresses issue ticket #14. 2. Reference RFC5890 for IDNA, retaining subordinate refs to RFC3490. Updated IDNA-specific language, e.g. domain name canonicalization and IDNA dependencies. Addresses issue ticket #26 . 3. Completely re-wrote the STS header ABNF to be fully based on RFC2616, rather than a hybrid of RFC2616 and httpbis. Addresses issue ticket #27 . Changes from -01 to -02: 1. Updated Section 8.2 "URI Loading and Port Mapping" fairly thoroughly in terms of refining the presentation of the steps, and to ensure the various aspects of port mapping are clear. Nominally fixes issue ticket #1 2. Removed dependencies on [I-D.draft-ietf-httpbis-p1-messaging-15]. Thus updated STS ABNF in Section 6.1 "Strict-Transport-Security HTTP Response Header Field" by lifting some productions entirely from [I-D.draft-ietf-httpbis-p1-messaging-15] and leveraging [RFC2616]. Addresses issue ticket #2 . 3. Updated Effective Request URI section and definition to use language from [I-D.draft-ietf-httpbis-p1-messaging-15] and ABNF from [RFC2616]. Fixes issue ticket #3 . 4. Added explicit mention that the HSTS policy applies to all TCP ports of a host advertising the HSTS policy. Nominally fixes issue ticket #4 5. Clarified the need for the "includeSubDomains" directive, e.g. to protect Secure-flagged domain cookies. In Section 14.2 "The Need for includeSubDomains". Nominally fixes issue ticket #5 6. Cited Firesheep as real-live threat in Section 2.3.1.1 "Passive Network Attackers". Nominally fixes issue ticket #6 . 7. Added text to Section 11 "User Agent Implementation Advice" justifying connection termination due to tls warnings/errors. Nominally fixes issue ticket #7 . 8. Added new subsection Section 8.5 "Interstitially Missing Strict-Transport-Security Response Header Field". Nominally fixes issue ticket #8 . 9. Added text to Section 8.3 "Errors in Secure Transport Establishment" explicitly note revocation check failures as errors causing connection termination. Added references to [RFC5280] and [RFC2560]. Nominally fixes issue ticket #9 . 10. Added a sentence, noting that distributing specific end- entity certificates to browsers will also work for self- signed/private-CA cases, to Section 10 "Server Implementation and Deployment Advice" Nominally fixes issue ticket #10 . 11. Moved "with no user recourse" language from Section 8.3 "Errors in Secure Transport Establishment" to Section 11 "User Agent Implementation Advice". This nominally fixes issue ticket #11 . 12. Removed any and all dependencies on [I-D.draft-ietf-httpbis-p1-messaging-15], instead depending on [RFC2616] only. Fixes issue ticket #12 . 13. Removed the inline "XXX1" issue because no one had commented on it and it seems reasonable to suggest as a SHOULD that web apps should redirect incoming insecure connections to secure connections. 14. Removed the inline "XXX2" issue because it was simply for raising consciousness about having some means for distributing secure web application metadata. 15. Removed "TODO1" because description prose for "max-age" in the Note following the ABNF in Section 6 seems to be fine. 16. Decided for "TODO2" that "the first STS header field wins". TODO2 had read: "Decide UA behavior in face of encountering multiple HSTS headers in a message. Use first header? Last?". Removed TODO2. 17. Added Section 1.1 "Organization of this specification" for readers' convenience. 18. Moved design decision notes to be a proper appendix Appendix A. ======================================================================== Subject: I-D Action: draft-ietf-websec-strict-transport-sec-04.txt From: internet-drafts@ietf.org Date: Fri, 27 Jan 2012 16:31:54 -0800 To: i-d-announce@ietf.org Cc: websec@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Security Working Group of the IETF. Title : HTTP Strict Transport Security (HSTS) Author(s) : Jeff Hodges Collin Jackson Adam Barth Filename : draft-ietf-websec-strict-transport-sec-04.txt Pages : 43 Date : 2012-01-27 This specification defines a mechanism enabling Web sites to declare themselves accessible only via secure connections, and/or for users to be able to direct their user agent(s) to interact with given sites only over secure connections. This overall policy is referred to as HTTP Strict Transport Security (HSTS). The policy is declared by Web sites via the Strict-Transport-Security HTTP response header field, and/or by other means, such as user agent configuration, for example. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-websec-strict-transport-sec-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-websec-strict-transport-sec-04.txt --- end From Jeff.Hodges@KingsMountain.com Fri Jan 27 17:38:09 2012 Return-Path: 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 7195421F85D5 for ; Fri, 27 Jan 2012 17:38:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.206 X-Spam-Level: X-Spam-Status: No, score=-100.206 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, 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 RFrmPkLor+2g for ; Fri, 27 Jan 2012 17:38:08 -0800 (PST) Received: from oproxy3-pub.bluehost.com (oproxy3.bluehost.com [IPv6:2605:dc00:100:2::a3]) by ietfa.amsl.com (Postfix) with SMTP id CF86A21F85D4 for ; Fri, 27 Jan 2012 17:38:08 -0800 (PST) Received: (qmail 29008 invoked by uid 0); 28 Jan 2012 01:38:08 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy3.bluehost.com with SMTP; 28 Jan 2012 01:38:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=KgSORQSUUP9XQfM/61SyXg835A8x2ara9miHJFbLze0=; b=1abkdyOXh6Frscg115vbggV0yqetpxdIws6WM3uIUUTtAs9V/Cip62xcFn015nT4mXtpf2ve/kO4xfByAaLox6GtTwyrwuVhf4pjwmylpeN1T4PLx0bmjsagtsoOHgwO; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.137.138]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1RqxF2-0000li-2y for websec@ietf.org; Fri, 27 Jan 2012 18:38:08 -0700 Message-ID: <4F235180.2030302@KingsMountain.com> Date: Fri, 27 Jan 2012 17:38:08 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: IETF WebSec WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: [websec] proposed workflow for trac issue tickets (HSTS) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2012 01:38:09 -0000 I did some modest checking around, and there is not a ietf-wide process for using the issue tracker aka trac. Each working group is up to their own devices whether they wish to use it, and if they do, for establishing their workflow for such use. trac is installed with a nominal default workflow, and we apparently can't customize things like new additional values for "Status" or state transitions on our own. The default as-installed workflow is illustrated here.. http://trac.tools.ietf.org/wg/websec/trac/wiki/TracWorkflow I /think/ we're using trac >= version 0.11, so the second diagram should apply. I've submitted all the issue tickets for strict-transport-sec with default attribute values (e.g., for status), and it appears no one else has edited the attrs, so the status of all the tickets is "new". for a nominal websec wg workflow for specification bugs, without "reassignment" of tickets, I suggest.. 1. ticket initially submitted, status: "new" 2. ticket addressed in a spec revision, status <- "closed", resolution <- "fixed" 3. folks review the spec a. no objections to ticket's fix, then goto 4. b. if wg consensus (as assessed by co-chairs) is that the ticket's fix needs revision, ticket is "reopened", goto 2. 4. ticket closed, really. So, if there aren't any objections to this workflow, I'll close all the strict-transport-sec as resolution <- "fixed". If issues arise with any of the ticket's fixes in reviewing the spec, we can selectively reopen. If new issues arise, then we submit new ticket(s). =JeffH From alexey.melnikov@isode.com Tue Jan 31 09:30:06 2012 Return-Path: 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 BDCED11E8085 for ; Tue, 31 Jan 2012 09:30:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.116 X-Spam-Level: X-Spam-Status: No, score=-102.116 tagged_above=-999 required=5 tests=[AWL=0.483, BAYES_00=-2.599, 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 PAVoggDfT2Bb for ; Tue, 31 Jan 2012 09:30:05 -0800 (PST) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7656D11E8080 for ; Tue, 31 Jan 2012 09:30:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1328031004; d=isode.com; s=selector; i=@isode.com; bh=1oHcsVix3Js48cz9OKrub87EZlkPM11xFMGLoC5pRts=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=Xi5IQvciGReb95C+LtCqEWs/H4tkHenoLXu/IQ0EnPVY1QRQFmSk23rw/Ac55VpCX45Cyo ksxIcmiG6oyfImeHhOHkUCTFqXN+KtsN0gfZ/1pAfiJp1EVWGaCQ1bS345d8Np/2R+GFHx j+c+7X/sYOOhioCdi5uUGRS1m8f2NhI=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 31 Jan 2012 17:30:04 +0000 Message-ID: <4F282515.5010707@isode.com> Date: Tue, 31 Jan 2012 17:29:57 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 To: websec@ietf.org References: <4F235180.2030302@KingsMountain.com> In-Reply-To: <4F235180.2030302@KingsMountain.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [websec] proposed workflow for trac issue tickets (HSTS) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 17:30:06 -0000 On 28/01/2012 01:38, =JeffH wrote: > I did some modest checking around, and there is not a ietf-wide > process for using the issue tracker aka trac. Each working group is up > to their own devices whether they wish to use it, and if they do, for > establishing their workflow for such use. > > trac is installed with a nominal default workflow, and we apparently > can't customize things like new additional values for "Status" or > state transitions on our own. > > The default as-installed workflow is illustrated here.. > > http://trac.tools.ietf.org/wg/websec/trac/wiki/TracWorkflow > > I /think/ we're using trac >= version 0.11, so the second diagram > should apply. > > > I've submitted all the issue tickets for strict-transport-sec with > default attribute values (e.g., for status), and it appears no one > else has edited the attrs, so the status of all the tickets is "new". > > for a nominal websec wg workflow for specification bugs, without > "reassignment" of tickets, I suggest.. > > 1. ticket initially submitted, status: "new" > > 2. ticket addressed in a spec revision, status <- "closed", resolution > <- "fixed" > > 3. folks review the spec > > a. no objections to ticket's fix, then goto 4. > > b. if wg consensus (as assessed by co-chairs) is that the ticket's > fix needs revision, ticket is "reopened", goto 2. > > 4. ticket closed, really. > > > > So, if there aren't any objections to this workflow, I'll close all > the strict-transport-sec as resolution <- "fixed". If issues arise > with any of the ticket's fixes in reviewing the spec, we can > selectively reopen. If new issues arise, then we submit new ticket(s). Works for me. From julian.reschke@gmx.de Tue Jan 31 12:40:55 2012 Return-Path: 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 40F5D11E80E3 for ; Tue, 31 Jan 2012 12:40:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.082 X-Spam-Level: X-Spam-Status: No, score=-104.082 tagged_above=-999 required=5 tests=[AWL=-1.483, BAYES_00=-2.599, 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 BZhz-8t+2txh for ; Tue, 31 Jan 2012 12:40:54 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id C56BC11E809D for ; Tue, 31 Jan 2012 12:40:53 -0800 (PST) Received: (qmail invoked by alias); 31 Jan 2012 20:40:52 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp010) with SMTP; 31 Jan 2012 21:40:52 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18hHxMxw7IhLw6TO4gbl4QUOuPFW9n0CoUPPfvj0M Wd5YSDUDwIRTn1 Message-ID: <4F2851D1.5040505@gmx.de> Date: Tue, 31 Jan 2012 21:40:49 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: =JeffH References: <4F2347C5.8090406@KingsMountain.com> In-Reply-To: <4F2347C5.8090406@KingsMountain.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: IETF WebSec WG Subject: [websec] STS ABNF, was: new rev: draft-ietf-websec-strict-transport-sec-04 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 20:40:55 -0000 On 2012-01-28 01:56, =JeffH wrote: > ... Hi Jeff, thanks for the update. The ABNF now is: Strict-Transport-Security = "Strict-Transport-Security" ":" directive *( ";" [ directive ] ) directive = token [ "=" ( token | quoted-string ) ] ...and I think this is almost right. It does allow empty directives (thus repeated or trailing semicolons), but not leading semicolons. So STS: foo ; parses, but STS: ; foo does not. This could be fixed by saying: Strict-Transport-Security = "Strict-Transport-Security" ":" *( ";" [ directive ] ) I like the subsequent prose about the additional constraints. For 6.1.1 and 6.1.2, we still need to decide whether a) quoted-string should be legal here (I understand that's ), and if it was, b) how the syntax should be described. Best regards, Julian From trac+websec@trac.tools.ietf.org Tue Jan 31 12:43:39 2012 Return-Path: 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 D628621F84C4 for ; Tue, 31 Jan 2012 12:43:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 hCMDZSdWiJW0 for ; Tue, 31 Jan 2012 12:43:38 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 34F0F21F84B8 for ; Tue, 31 Jan 2012 12:43:36 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RsKXm-00005U-DL; Tue, 31 Jan 2012 15:43:10 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "websec issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com, julian.reschke@gmx.de X-Trac-Project: websec Date: Tue, 31 Jan 2012 20:43:10 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/33#comment:2 Message-ID: <085.a624f58fd0ce3a560750f025863998ea@trac.tools.ietf.org> References: <070.dc46fc06c043a8103369b4b2f8b4d471@trac.tools.ietf.org> X-Trac-Ticket-ID: 33 In-Reply-To: <070.dc46fc06c043a8103369b4b2f8b4d471@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com, julian.reschke@gmx.de, websec@ietf.org X-SA-Exim-Mail-From: trac+websec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120131204338.34F0F21F84B8@ietfa.amsl.com> Resent-Date: Tue, 31 Jan 2012 12:43:36 -0800 (PST) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: Re: [websec] #33: HSTS: quoted-string grammar in (extension) directives ? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 20:43:39 -0000 #33: HSTS: quoted-string grammar in (extension) directives ? Comment (by julian.reschke@…): Related Mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=718409 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-websec-strict- jeff.hodges@… | transport-sec@… Type: defect | Status: new Priority: major | Milestone: Component: strict- | Version: transport-sec | Resolution: Severity: Active WG | Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: websec From Jeff.Hodges@KingsMountain.com Tue Jan 31 16:27:43 2012 Return-Path: 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 8041C11E8096 for ; Tue, 31 Jan 2012 16:27:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.226 X-Spam-Level: X-Spam-Status: No, score=-100.226 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, 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 6dVYcrfpfgCD for ; Tue, 31 Jan 2012 16:27:42 -0800 (PST) Received: from oproxy7-pub.bluehost.com (oproxy7.bluehost.com [IPv6:2605:dc00:100:2::a7]) by ietfa.amsl.com (Postfix) with SMTP id D1E6A11E8095 for ; Tue, 31 Jan 2012 16:27:42 -0800 (PST) Received: (qmail 19008 invoked by uid 0); 1 Feb 2012 00:27:42 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy7.bluehost.com with SMTP; 1 Feb 2012 00:27:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=GfjOBYOaA7MdA9hjwa42alVy8k380ThlO6IenT9kULI=; b=qvnR1LfZSGY/Y4zrq3EfNCzynZa3E9sOxUEky82M7LAC3zo9tKprYI9u1Vh1bM3ZCFbANhxntXmpnTsvQfRK71pbMP5qqaKL3uWW3YEhR5O2gRJ7XWR/9H8mihH53qxc; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.136.48]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1RsO33-0003WA-Kg for websec@ietf.org; Tue, 31 Jan 2012 17:27:41 -0700 Message-ID: <4F288700.3040104@KingsMountain.com> Date: Tue, 31 Jan 2012 16:27:44 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: IETF WebSec WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [websec] #36: HSTS: fixup references X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 00:27:43 -0000 Alexey pointed out to me.. > > BTW, you moved lots of references to Informational (e.g. all IDNA > related), I think this is incorrect - their understanding is required in > order to implement HSTS correctly. So, yes, I did (ruthlessly) move a ton of references to Informational. I wanted to pare down the Normative references to the absolutely necessary ones. Wrt IDNA refs, I'm happy to move them back to Normative if that's what folks think. Note that in typical implementations, all the IDN normalizations have occurred before getting to the actual HSTS implementation. there's this text in Section 8. User Agent Processing Model... This processing model assumes that the UA implements IDNA2008 [RFC5890], or possibly IDNA2003 [RFC3490], as noted in Section 13 "Internationalized Domain Names for Applications (IDNA): Dependency and Migration". It also assumes that all domain names manipulated in this specification's context are already IDNA-canonicalized as outlined in Section 9 "Domain Name IDNA-Canonicalization" prior to the processing specified in this section. The above assumptions mean that this processing model also specifically assumes that appropriate IDNA and Unicode validations and character list testing have occurred on the domain names, in conjunction with their IDNA-canonicalization, prior to the processing specified in this section. See the IDNA-specific security considerations in Section 14.8 "Internationalized Domain Names" for rationale and further details. So, if folks indeed wish IDN refs to be Normative, I'll move 'em back. Also please point out any other refs y'all think should be in the Normative section but aren't. thanks, =JeffH